Hybrid-Suche mit Vektor- und Textfeldern in Azure AI Search konfigurieren

1. Index-Schema-Definition mit Vektor- und Textfeldern

Zunächst wird ein Azure AI Search-Index erstellt, der sowohl reguläre Textfelder für Volltextsuche als auch Vektorfelder für semantische Suche enthält. Vektorfelder speichern numerische Embeddings, die aus Dokumententexten abgeleitet werden. Der Index muss mindestens ein suchbares Textfeld und ein Vektorfeld enthalten. Bei Erstellung über Portal oder REST-API werden Vektorfelder mit dem Typ "Edm.Single" und der Eigenschaft "searchable": true deklariert, jedoch werden sie nicht für gewöhnliche Volltextsuche verwendet; ihre Rolle liegt in der Vektorsimilarität.

Ein Beispiel aus Microsoft Learn-Dokumentation zeigt eine Hybridabfrage, bei der der Suchparameter mit vectorQueries auf DescriptionVector und Description_frVector-Felder verweist. Dadurch ist es möglich, in einer einzigen Abfrage sowohl Keyword-Suche als auch semantische Suche durchzuführen, wobei die Ergebnisse mittels RRF-Algorithmus zusammengeführt werden.

Wichtig: Vektorfelder können nicht direkt in Filtern verwendet werden. Für Metadaten (z. B. Kategorie, Geografie) ist ein separates Text- oder Zahlenfeld erforderlich, das mit den Attributen filterable und/oder facetable markiert ist.

POST https://my-service.search.windows.net/indexes/hotels-vector-quickstart/docs/search?api-version=2026-04-01\ncontent-type: application/JSON\n{\n  "count": true,\n  "search": "historic hotel walk to restaurants and shopping",\n  "select": "HotelId, HotelName, Category, Description, Address/City, Address/StateProvince",\n  "filter": "geo.distance(Location, geography'POINT(-77.03241 38.90166)') le 300",\n  "vectorFilterMode": "postFilter",\n  "facets": ["Address/StateProvince"],\n  "vectorQueries": [{\n    "kind": "vector",\n    "vector": [0.1,0.2,…],\n    "k": 50,\n    "fields": "DescriptionVector",\n    "exhaustive": true,\n    "oversampling": 20\n  }],\n  "skip": 0,\n  "top": 10,\n  "queryType": "semantic",\n  "queryLanguage": "en-us",\n  "semanticConfiguration": "my-semantic-config"\n}

2. Generierung oder Import von Embeddings für Textfelder

Embeddings können auf zwei Arten generiert werden: über die integrierten Fähigkeiten von Azure AI Search (Indexer-Pipeline mit Azure OpenAI) oder externe Modelle (OpenAI Embeddings, SBERT usw.) und anschließend direkt in den Index geladen. Im ersten Fall wird ein Skillset konfiguriert, das den Text automatisch in Blöcke aufteilt und den Embedding-Modell aufruft. Im zweiten Fall werden Vektoren extern erzeugt und über API bei Erstellung oder Aktualisierung von Dokumenten übergeben.

Die Dokumentation empfiehlt die Verwendung von Azure OpenAI für die Embedding-Generierung, insbesondere des Modells text-embedding-ada-002. Embeddings müssen dieselbe Dimensionalität haben (z. B. 1536 für Ada), und dieser Wert wird beim Erstellen des Vektorfeldes angegeben.

Beim Import von Daten über das „Import data“-Wizard kann eine Option zur Vektorisierung ausgewählt werden, und das System generiert automatisch Embeddings für den geladenen Inhalt, wenn eine geeignete Datenquelle und Skillset konfiguriert sind.

/* Example call to Azure OpenAI for obtaining an embedding */\nPOST https://my-openai-resource.openai.azure.com/openai/deployments/text-embedding-ada-002/embeddings?api-version=2024-02-15\nHeaders: api-key: YOUR_API_KEY\n{\n  "input": "historic hotel walk to restaurants and shopping"\n}

3. Konfiguration von Vektorsuchparametern (k, Oversampling, Exhaustive)

Der Parameter k in vectorQueries gibt an, wie viele nächstgelegene Nachbarn für jeden Vektor zurückgegeben werden sollen. Es wird empfohlen, k >= 50 festzulegen, wenn ein semantischer Reranker verwendet wird, damit genügend Kandidaten für die Neubewertung vorhanden sind.

Der Oversampling-Parameter legt einen zusätzlichen Prozentsatz von Kandidaten fest, der über k hinaus extrahiert wird, was die Ergebnisqualität verbessert, wenn HNSW-Indizes verwendet werden. Typische Werte von 10 bis 50 bieten einen guten Kompromiss zwischen Latenz und Genauigkeit.

Der exhaustive-Parameter gibt an, ob eine vollständige Suche zur Bestimmung der nächsten Nachbarn durchgeführt werden soll. Wenn exhaustive: true gesetzt ist, wird garantiert, dass die tatsächlichen k nächstgelegenen Nachbarn gefunden werden, was jedoch die Latenz erhöht. Standardmäßig ist false, und für die meisten Szenarien ist HNSW ausreichend.

Im Beispiel aus dem hybrid-search-overview-Dokument werden zwei vectorQueries gezeigt: eine mit exhaustive=true und oversampling=20, eine andere mit exhaustive=false und oversampling=10. Die Konfiguration hängt von der Indexgröße und den Relevanzanforderungen ab.

Hinweis: Erhöhen von k und Oversampling verbessert die Genauigkeit, aber auch die Abfrage-Latenz. Testen Sie immer Werte anhand einer repräsentativen Datensammlung.

"vectorQueries": [{\n    "kind": "vector",\n    "vector": <array> ,\n    "k": 50,\n    "fields": "DescriptionVector",\n    "exhaustive": true,\n    "oversampling": 20\n }]

4. Erstellung einer Hybridabfrage mit search und vectorQueries

Eine Hybridabfrage kombiniert den Suchparameter (Volltextabfrage) und eine oder mehrere vectorQueries. Die Anfrage wird als einzelner HTTP POST-Nachricht an den Index-Endpunkt gesendet, mit api-version=2026-04-01 (oder aktueller Version).

Der Server führt Volltext- und Vektorsuche parallel aus und fusioniert die Ergebnisse mittels dem Reciprocal Rank Fusion (RRF)-Algorithmus. RRF weist jedem Dokument eine kombinierte Rangfolge zu, basierend auf seiner Position in beiden Ergebnislisten, wodurch eine Kombination präziser Keyword-Suche und semantischer Ähnlichkeit erreicht wird.

In der Abfrage kann queryType: semantic festgelegt werden, um den semantischen Reranker zu aktivieren, der maschinelles Lesen auf die gefusionierten RRF-Ergebnisse anwendet und diese basierend auf semantischer Übereinstimmung zur Abfrage neu rangiert. Dies ist besonders nützlich für konzeptionelle Abfragen, bei denen Bedeutung wichtiger ist als Wortübereinstimmung.

Filter und Facetten werden auf Feldern angewendet, die keine Vektorfelder sind. Zum Beispiel funktionieren geospatial Filter wie geo.distance oder Kategorienfilter auf dem gefusionierten Ergebnis nach RRF. Es ist wichtig, das Verhalten von vectorFilterMode zu testen (preFilter vs postFilter), da die Reihenfolge der Filteranwendung Auswirkungen auf Leistung und zurückgegebene Dokumentensätze hat.

Ein vollständiges Abfragebeispiel wird in Abschnitt 1 vorgestellt und beinhaltet Facetten, Filter, vectorQueries und semanticConfiguration.

POST https://my-service.search.windows.net/indexes/hotels-vector-quickstart/docs/search?api-version=2026-04-01\ncontent-type: application/JSON\n{\n  "count": true,\n  "search": "historic hotel walk to restaurants and shopping",\n  "select": "HotelId, HotelName, Category, Description, Address/City, Address/StateProvince",\n  "filter": "geo.distance(Location, geography'POINT(-77.03241 38.90166)') le 300",\n  "vectorFilterMode": "postFilter",\n  "facets": ["Address/StateProvince"],\n  "vectorQueries": [{\n    "kind": "vector",\n    "vector": [0.1,0.2,…],\n    "k": 50,\n    "fields": "DescriptionVector",\n    "exhaustive": true,\n    "oversampling": 20\n  }],\n  "skip": 0,\n  "top": 10,\n  "queryType": "semantic",\n  "queryLanguage": "en-us",\n  "semanticConfiguration": "my-semantic-config"\n}

5. Anwendung von Filtern und Facetten auf Nicht-Vektorfeldern

Nach der RRF-Fusion werden Filter und Facetten auf dem endgültigen Dokumentensatz angewendet. Dies ermöglicht die Erhaltung bestehender Suchfunktionen: geospatial Filter, Attributefilter, Facetten-Körbe für Navigation.

Filter in einer Hybridabfrage werden nach Durchführung von Volltext- und Vektorsuche angewendet (Standard: postFilter), können jedoch als vectorFilterMode: preFilter konfiguriert werden, wenn Dokumente vor der Vektorsuche ausgeschlossen werden müssen. Tests zeigen, dass postFilter oft bessere Relevanz liefert, da der Filter nicht vor der Vektorsuche Kandidaten einschränkt.

Facetten (facets) können verwendet werden, um Ergebnisse nach Feldern zu unterteilen, z. B. Address/StateProvince, wie im Beispiel gezeigt. Facetten-Ergebnisse spiegeln die Verteilung unter den gefusionierten Ergebnissen wider, nicht nur unter einem Suchkomponenten.

Es ist wichtig zu beachten, dass Vektorfelder nicht direkt gefiltert werden können. Jede Auswahlbedingung durch Metadaten muss auf separate Text- oder Zahlenfelder zurückgreifen, die beim Erstellen des Indexes mit entsprechenden Attributen markiert sind.

"filter": "geo.distance(Location, geography'POINT(-77.03241 38.90166)') le 300",\n  "facets": ["Address/StateProvince"]

6. Optional: Aktivierung des Semantischen Rerankers zur Neubewertung

Der semantische Reranker ist verfügbar, wenn queryType: semantic und semanticConfiguration in der Anfrage angegeben werden. Der Reranker verwendet maschinelles Lesen, um die gefusionierten RRF-Ergebnisse zu analysieren und diese basierend auf semantischer Übereinstimmung zur Abfrage neu zu rangieren.

Dies verbessert die Suchqualität für Abfragen, bei denen konzeptionelle Nähe relevant ist (z. B. Synonyme, multilinguale Suche). Benchmark-Tests zeigen, dass Hybrid-Suche mit semantischem Reranker gegenüber reinem Vektorsuch- oder Keyword-Suchverfahren eine signifikante Verbesserung der Relevanz bietet.

Die Konfiguration des semantischen Rerankers erfolgt auf Indexebene (Abschnitt „semantic configurations“). In der Anfrage wird der Konfigurationsname angegeben, sowie die Abfragesprache (queryLanguage).

Wenn kein semantischer Reranker benötigt wird, kann die Anfrage ohne queryType: semantic gesendet werden. In diesem Fall werden die Ergebnisse nur auf Basis von RRF gerangiert, wobei BM25 (für Text) und HNSW/eKNN (für Vektoren) kombiniert werden.

 "queryType": "semantic",\n  "queryLanguage": "en-us",\n  "semanticConfiguration": "my-semantic-config"

7. Testen und Iterieren von k, Oversampling und Filterverhalten

Nach Bereitstellung ist es notwendig, experimentell mit k, Oversampling und Filterverhalten (preFilter/postFilter) zu arbeiten, um das optimale Geschwindigkeits-Accuracy-Verhältnis für Ihr Domänenfeld zu finden.

Testen Sie verschiedene k-Werte (z. B. 10, 50, 100) und Oversampling-Werte (10, 20, 50) anhand einer repräsentativen Abfrageprobe. Beachten Sie Änderungen in @search.rerankerScore und die Dokumentreihenfolge in der Antwort.

Vergleichen Sie Ergebnisse mit und ohne semantischen Reranker. Wenn k zu klein ist, erhält der semantische Reranker nicht genügend Kandidaten, und die Neubewertung wird weniger wirksam.

Überwachen Sie die Abfragelatenz: Erhöhung von k und Oversampling erhöht die Antwortzeit. Finden Sie das minimale k, das bei Verwendung des semantischen Rerankers akzeptable Relevanz bietet.

Verwenden Sie Azure Portal oder REST-API-Debugging-Tools: Der Parameter count: true ermöglicht die Anzeige der Gesamtanzahl der Treffer, und das Feld @search.rerankerScore zeigt die Bewertung des semantischen Rerankers an.

/* Example checking results with count */\n{\n  "count": true,\n  "search": "...",\n  "vectorQueries": [{"kind": "vector", "vector": [...], "k": 50, ...}],\n  "top": 10\n}

8. Bereitstellung und Überwachung von Vektorindex-Quoten und Kosten

Stellen Sie sicher, dass Ihr Suchdienst nach dem 3. April 2024 erstellt wurde - solche Dienste bieten höhere Vektorindex-Quoten an. Falls der Dienst älter ist, kann er aktualisiert werden, um größere Quoten zu erhalten.

Die Generierung von Embeddings über Azure OpenAI oder andere Modelle verursacht Gebühren vom Modellanbieter. Diese Kosten sollten bei der Planung der Datenvolumina und der Aktualisierungsrate berücksichtigt werden.

Überwachen Sie die Nutzung von Vektorindizes über Azure Monitor-Metriken: Anzahl der Vektorfelder, Dimensionalität, Dokumentanzahl. Überschreitung von Quoten kann zu Indexierungs- oder Abfragefehlern führen.

Für Hybrid-Suche überwachen Sie die Abfragelatenz: Große k- und Oversampling-Werte erhöhen die Last. Wenn die Latenz unannehmbar wird, reduzieren Sie den Oversampling oder überprüfen Sie die HNSW-Konfiguration erneut.

Es wird empfohlen, Warnungen bei Überschreitung von Quoten einzustellen und regelmäßig den Indexzustand zu überprüfen, insbesondere nach großen Dokumentenbatchs.

/* Checking service version and quotas */\nGET https://my-service.search.windows.net?api-version=2026-04-01\nHeaders: api-key: YOUR_API_KEY