Hinzufügen eines Filters zu einer Vektorabfrage in Azure KI-Suche

In Azure AI Search können Sie einen Filterausdruck verwenden, um einer Vektorabfrage Ein- oder Ausschlusskriterien hinzuzufügen. Sie können auch einen Filtermodus angeben, der den Filter anwendet:

• Vor der Abfrageausführung: Dies wird auch als Vorfilterung bezeichnet.
• Nach der Abfrageausführung: Dies wird auch als Nachfilterung bezeichnet wird.
• Nachdem die globalen Top-k-Ergebnisse identifiziert wurden: Dies wird auch als strikte Nachfilterung (Vorschau) bezeichnet.

In diesem Artikel wird REST zur Veranschaulichung verwendet. Codebeispiele in anderen Sprachen und End-to-End-Lösungen, die Vektorabfragen enthalten, finden Sie im GitHub-Repository azure-search-vector-samples.

Sie können auch den Such-Explorer im Azure-Portal verwenden, um Vektorinhalte abzufragen. In der JSON-Ansicht können Sie Filter hinzufügen und den Filtermodus angeben.

Funktionsweise der Filterung in Vektorabfragen

Azure AI Search verwendet den hierarchischen Navigable Small World (HNSW)-Algorithmus für die Suche nach ungefähren Nachbarn (ANN), wobei HNSW-Diagramme über mehrere Shards hinweg gespeichert werden. Jeder Shard enthält einen Teil des gesamten Indexes.

Filter werden auf filterable-Nichtvektorfelder (bei denen es sich entweder um eine Zeichenfolge oder einen numerischen Ausdruck handelt) angewendet, um Suchdokumente basierend auf Filterkriterien ein- oder auszuschließen. Vektorfelder selbst sind nicht filterbar, Sie können jedoch Filter für andere Felder im selben Index verwenden, um die Dokumente einzuschränken, die für die Vektorsuche berücksichtigt werden. Wenn Ihr Index keine geeigneten Text- oder numerischen Felder aufweist, suchen Sie nach Dokumentmetadaten, die bei der Filterung hilfreich sein können, wie z. B. LastModified- oder CreatedBy-Eigenschaften.

Der vectorFilterMode Parameter steuert, wo Filtervorgänge während der Suchphasen angewendet werden, was sich darauf auswirkt, wie die Ergebnisse auf eine Teilmenge von Elementen gefiltert werden (z. B. nach Kategorie, Tag oder anderen Attributen), und wirkt sich auf Latenz, Rückruf und Durchsatz aus. Es gibt drei Modi:

• preFilter wendet den Filter während der HNSW-Durchquerung auf jeden Shard an. Dieser Modus maximiert den Rückruf, kann aber mehr des Diagramms durchlaufen und die CPU- und Latenzzeit für hoch selektive Filter erhöhen.

• postFilter führt HNSW-Durchlauf und -Filterung für jeden Shard unabhängig voneinander durch, schneidet die Ergebnisse auf Shard-Ebene und aggregiert dann die Top-k aus jedem Shard zu einem globalen Top k. Dieser Modus kann falsche Negative für hoch selektive Filter oder kleine k Werte erstellen.

• strictPostFilter (Vorschau) findet die ungefilterte globale Top-k, bevor der Filter angewendet wird. Dieser Modus hat das höchste Risiko, falsch negative Ergebnisse für hoch selektive Filter und kleine k Werte zurückzugeben.

Weitere Informationen zu diesen Modi finden Sie unter Festlegen des Filtermodus.

Definieren eines Filters

Filter bestimmen den Bereich von Vektorabfragen und werden mithilfe von Dokumenten – Search-Post (REST-API) definiert. Wenn Sie keine Previewfunktion verwenden möchten, verwenden Sie die neueste stabile Version der REST-APIs des Suchdiensts, um die Anforderung zu formulieren.

Diese REST-API bietet Folgendes:

• filter für die Kriterien.
• vectorFilterMode um anzugeben, wann der Filter während der Vektorabfrage angewendet wird. Unterstützte Modi finden Sie unter "Festlegen des Filtermodus".

POST https://{search-endpoint}/indexes/{index-name}/docs/search?api-version={api-version}
Content-Type: application/json
api-key: {admin-api-key}
    
{
    "count": true,
    "select": "title, content, category",
    "filter": "category eq 'Databases'",
    "vectorFilterMode": "preFilter",
    "vectorQueries": [
        {
            "kind": "vector",
            "vector": [
                -0.009154141,
                0.018708462,
                . . . // Trimmed for readability
                -0.02178128,
                -0.00086512347
            ],
            "fields": "contentVector",
            "k": 50
        }
    ]
}

In diesem Beispiel zielt die Einbettung des Vektors auf das contentVector-Feld ab, und die Filterkriterien gelten für category, ein filterbares Textfeld. Da der preFilter-Modus verwendet wird, wird der Filter angewendet, bevor die Suchmaschine die Abfrage ausführt, sodass nur Dokumente in der Databases-Kategorie während der Vektorsuche berücksichtigt werden.

Festlegen des Filtermodus

Der vectorFilterMode-Parameter bestimmt, wann und wie der Filter relativ zur Vektorabfrageausführung angewendet wird. Sie können die folgenden Modi verwenden:

• preFilter (empfohlen)
• postFilter
• strictPostFilter (Vorschau)

Vergleichstabelle

Benchmarktests für Vorfilterung und Nachfilterung

Um die Bedingungen zu verstehen, unter denen ein Filtermodus besser funktioniert als der andere, haben wir eine Reihe von Tests durchgeführt, um Abfrageergebnisse für kleine, mittlere und große Indizes auszuwerten.

• Klein (100.000 Dokumente, 2,5 GB Index, 1.536 Dimensionen)
• Mittel (1 Mio. Dokumente, 25 GB Index, 1.536 Dimensionen)
• Groß (1 Mrd. Dokumente, 1,9 TB Index, 96 Dimensionen)

Für die kleinen und mittleren Workloads haben wir einen S2-Dienst (Standard 2) mit einer einzelnen Partition und einem einzelnen Replikat verwendet. Für die große Workload haben wir einen S3-Dienst (Standard 3) mit 12 Partitionen und einem einzelnen Replikat verwendet.

Die Indizes waren gleich aufgebaut und umfassten ein Schlüsselfeld, ein Vektorfeld, ein Textfeld und ein numerisches filterbares Feld. Der folgende Index wird mithilfe der 2023-11-03-Syntax definiert.

def get_index_schema(self, index_name, dimensions):
    return {
        "name": index_name,
        "fields": [
            {"name": "id", "type": "Edm.String", "key": True, "searchable": True},
            {"name": "content_vector", "type": "Collection(Edm.Single)", "dimensions": dimensions,
              "searchable": True, "retrievable": True, "filterable": False, "facetable": False, "sortable": False,
              "vectorSearchProfile": "defaulthnsw"},
            {"name": "text", "type": "Edm.String", "searchable": True, "filterable": False, "retrievable": True,
              "sortable": False, "facetable": False},
            {"name": "score", "type": "Edm.Double", "searchable": False, "filterable": True,
              "retrievable": True, "sortable": True, "facetable": True}
        ],
      "vectorSearch": {
        "algorithms": [
            {
              "name": "defaulthnsw",
              "kind": "hnsw",
              "hnswParameters": { "metric": "euclidean" }
            }
          ],
          "profiles": [
            {
              "name": "defaulthnsw",
              "algorithm": "defaulthnsw"
            }
        ]
      }
    }

In Abfragen wurde sowohl für Vorfilter- als auch für Nachfiltervorgänge ein identischer Filter verwendet. Wir haben einen einfachen Filter verwendet, um sicherzustellen, dass Leistungsabweichungen auf den Modus und nicht auf die Komplexität des Filters zurückzuführen sind.

Die Ergebnisse wurden in Abfragen pro Sekunde (Queries Per Second, QPS) gemessen.

Wesentliche Punkte

• Die Vorfilterung ist fast immer langsamer als die Nachfilterung (außer bei kleinen Indizes, wo die Leistung ungefähr gleich bleibt).

• Bei größeren Datasets ist die Vorfilterung erheblich langsamer.

• Warum wird als Standard die Vorfilterung verwendet, wenn sie fast immer langsamer ist? Die Vorfilterung sorgt dafür, dass k Ergebnisse zurückgegeben werden, wenn sie im Index vorhanden sind. Dabei haben Abruf und Genauigkeit Vorrang vor Geschwindigkeit.

• Verwenden Sie die Nachfilterung, wenn:

  • Ihnen Geschwindigkeit wichtiger als Auswahl ist (Postfilterung kann weniger als k Ergebnisse zurückgeben).

  • Verwenden Sie Filter, die nicht übermäßig selektiv sind.

  • Sie über Indizes ausreichender Größe verfügen, sodass die Vorfilterleistung nicht akzeptabel ist.

Details

• Bei einem Dataset mit 100.000 Vektoren und 1,536 Dimensionen:

  • Bei der Filterung von mehr als 30 Prozent des Datasets waren Vor- und Nachfilterung vergleichbar.

  • Bei der Filterung von weniger als 0,1 Prozent des Datasets war die Vorfilterung etwa 50 Prozent langsamer als die Nachfilterung.

• Bei einem Dataset mit 1 Mio. Vektoren und 1,536 Dimensionen:

  • Bei der Filterung von mehr als 30 Prozent des Datasets war die Vorfilterung ca. 30 Prozent langsamer.

  • Bei der Filterung von weniger als zwei Prozent des Datasets war die Vorfilterung ca. sieben Mal langsamer.

• Bei einem Dataset mit 1 Mrd. Vektoren und 96 Dimensionen wurden folgende Ergebnisse ermittelt:

  • Bei der Filterung von mehr als fünf Prozent des Datasets war die Vorfilterung ca. 50 Prozent langsamer.

  • Bei der Filterung von weniger als zehn Prozent des Datasets war die Vorfilterung ca. sieben Mal langsamer.

Die folgende Abbildung zeigt die relativen QPS der Vorfilterung (Vorfilter-QPS dividiert durch Nachfilter-QPS).

Die vertikale Achse stellt die relative Leistung der Vorfilterung im Vergleich zur Postfilterung ausgedrückt als Verhältnis von QPS (Queries Per Second, Abfragen pro Sekunde) dar. Beispiel:

• Ein Wert von 0.0 bedeutet, dass die Vorfilterung 100 % langsamer als die Nachfilterung ist.
• Ein Wert von 0.5 bedeutet, dass Vorfilterung 50 % langsamer ist.
• Ein Wert von 1.0 bedeutet, dass Vorfilterung und Nachfilterung gleichwertig sind.

Die horizontale Achse stellt die Filterrate oder den Prozentsatz der Kandidatendokumente nach Anwendung des Filters dar. Eine Rate von 1.00% bedeutet beispielsweise, dass die ausgewählten Filterkriterien ein Prozentwert des Suchkorpus betragen.

Verwandte Inhalte

• Vektorsuche in Azure KI-Suche
• Erstellen eines Vektorindexes
• Erstellen einer Vektorabfrage