In der Azure KI-Suche verfügt ein Vektorspeicher über ein Indexschema, das Vektor- und Nichtvektorfelder definiert, eine Vektorkonfiguration für Algorithmen, die den Einbettungsraum erstellen, und Einstellungen für Vektorfelddefinitionen, die in Abfrageanforderungen verwendet werden. Die API zum Erstellen oder Aktualisieren eines Index erstellt den Vektorspeicher.
Führen Sie die folgenden Schritte aus, um Vektordaten zu indizieren:
Definieren eines Schemas mit Vektoralgorithmen für die Indizierung und Suche
In diesem Artikel wird der Workflow erläutert und REST verwendet, um jeden Schritt zu veranschaulichen. Jede aktuelle Version der REST-API fügt neue Funktionen hinzu. Sobald Sie den grundlegenden Workflow und die bereitgestellten API-Versionen verstanden haben, fahren Sie mit den Azure SDK-Codebeispielen im Repository azure-search-vector-samples fort, um Anleitungen zur Verwendung dieser Features im Test- und Produktionscode zu erhalten.
Azure AI Search, in jeder Region und auf jeder Ebene. Die meisten vorhandenen Dienste unterstützen die Vektorsuche. Für Dienste, die vor Januar 2019 erstellt wurden, gibt es eine kleine Teilmenge, die keinen Vektorindex erstellen kann. In dieser Situation muss ein neuer Dienst erstellt werden.
Bereits vorhandene Vektoreinbettungen in Ihre Quelldokumente, wenn Sie die allgemein verfügbare Version der Azure SDKs und REST-APIs verwenden. Weitere Informationen finden Sie im Artikel zum Generieren von Einbettungen. Eine Alternative ist integrierte Vektorisierung (Vorschau).
Sie sollten die Größeneinschränkung des Modells kennen, das zum Erstellen der Einbettungen und zur Berechnung der Ähnlichkeit verwendet wird. In Azure OpenAI beträgt die Länge des numerischen Vektors 1536 für text-embedding-ada-002. Ähnlichkeit wird mithilfe von cosine berechnet. Gültige Werte sind 2 bis 3072 Dimensionen.
Sie sollten mit der Erstellung eines Index vertraut sein. Das Schema muss ein Feld für den Dokumentschlüssel, andere Felder, die Sie durchsuchen oder filtern möchten, und weitere Konfigurationen für Verhaltensweisen enthalten, die während der Indizierung und Abfragen erforderlich sind.
Vorbereiten von Dokumenten für die Indizierung
Erstellen Sie vor der Indizierung eine Dokumentnutzlast, die Felder mit Vektor- und Nicht-Vektordaten enthält. Die Dokumentstruktur muss dem Indexschema entsprechen.
Stellen Sie für Ihre Dokumente Folgendes sicher:
Sie enthalten ein Feld oder eine Metadateneigenschaft, die jedes Dokument eindeutig identifiziert. Für alle Suchindizes ist ein Dokumentschlüssel erforderlich. Um die Anforderungen des Dokumentschlüssels zu erfüllen, muss ein Quelldokument über ein Feld oder eine Eigenschaft verfügen, mit dem bzw. der es im Index eindeutig identifiziert werden kann. Dieses Quellfeld muss einem Indexfeld vom Typ Edm.String und key=true im Suchindex zugeordnet werden.
Sie enthalten Vektordaten (ein Array von Gleitkommazahlen mit einfacher Genauigkeit) in Quellfeldern.
Vektorfelder enthalten numerische Daten, die durch Einbettungsmodelle generiert werden (eine Einbettung pro Feld). Wir empfehlen die Einbettungsmodelle in Azure OpenAI (z. B. text-embedding-ada-002) für Textdokumente bzw. die Bildabruf-REST-API für Bilder. Es werden nur Indexvektorfelder der obersten Ebene unterstützt: Untergeordnete Vektorfelder werden derzeit nicht unterstützt.
Sie enthalten weitere Felder mit von Menschen lesbaren alphanumerischen Inhalten für die Abfrageantwort und für Hybridabfrageszenarien, die Volltextsuche oder semantische Rangfolge in derselben Anforderung enthalten.
Ihr Suchindex sollte Felder und Inhalte für alle Abfrageszenarien enthalten, die Sie unterstützen möchten. Angenommen, Sie möchten nach Produktnamen, Versionen, Metadaten oder Adressen suchen oder filtern. In diesem Fall ist die Ähnlichkeitssuche nicht besonders hilfreich. Schlüsselwortsuche, Geosuche oder Filter wären eine bessere Wahl. Ein Suchindex, der eine umfassende Feldauflistung von Vektor- und Nicht-Vektordaten enthält, bietet maximale Flexibilität für die Abfrageerstellung und Antwortkomposition.
Ein kurzes Beispiel für eine Dokumentnutzlast, die Vektor- und Nicht-Vektorfelder enthält, finden Sie im Abschnitt Laden von Vektordaten dieses Artikels.
Hinzufügen einer Vektorsuchkonfiguration
Eine Vektorkonfiguration gibt den Vektorsuchalgorithmus und Parameter an, die während der Indizierung zum Erstellen von Informationen zum „nächsten Nachbarn“ (Nearest Neighbor) zwischen den Vektorknoten verwendet werden:
Hierarchical Navigable Small World (HNSW)
Umfassende KNN
Wenn Sie HNSW für ein Feld auswählen, können Sie sich zur Abfragezeit für umfassende KNN entscheiden. Anders herum funktioniert es jedoch nicht: Wenn Sie umfassende KNN wählen, können Sie später keine HNSW-Suche anfordern, da die zusätzlichen Datenstrukturen, welche die ungefähre Suche ermöglichen, nicht vorhanden sind.
Suchen Sie nach einer Anleitung für die Migration von der Vorschau zur stabilen Version? Weitere Informationen für Schritte finden Sie unter Upgrade von REST-APIs.
Name der Konfiguration. Der Name muss innerhalb des Index eindeutig sein.
profiles fügt eine Abstraktionsebene für umfangreichere Definitionen hinzu. Ein Profil wird in vectorSearch definiert, und anschließend wird für jedes Vektorfeld anhand des Namens darauf verwiesen.
"hnsw" und "exhaustiveKnn" sind die ANN-Algorithmen (Approximate Nearest Neighbors, ungefähre nächste Nachbarn), die zum Organisieren von Vektorinhalten während der Indizierung verwendet werden.
Der Standardwert für "m" (Anzahl bidirektionaler Verknüpfungen) beträgt 4. Der Bereich liegt zwischen 4 und 10. Niedrigere Werte sollten zu einer geringeren Anzahl falscher Ergebnisse führen.
Der Standardwert für "efConstruction" ist 400. Der Bereich liegt zwischen 100 und 1.000. Dies ist die Anzahl der nächsten Nachbarn, die während der Indizierung verwendet werden.
Der Standardwert für "efSearch" ist 500. Der Bereich liegt zwischen 100 und 1.000. Dies ist die Anzahl der nächsten Nachbarn, die während der Suche verwendet werden.
"metric" muss „Kosinus“ sein, wenn Sie Azure OpenAI verwenden. Verwenden Sie andernfalls die Ähnlichkeitsmetrik, die dem verwendeten Einbettungsmodell zugeordnet ist. Folgende Werte werden unterstützt: cosine, dotProduct, euclidean.
2024-05-01-Vorschau ist die neueste Version. Sie erweitert die Codierungsoptionen, aber die Vektorsuchkonfiguration (vectorSearch Struktur) ist größtenteils identisch mit 2024-03-01-Vorschau.
Erweitert die integrierte Vektorisierung mit mehr Einbettungsmodelloptionen. Um von dieser Funktion zu profitieren, müssen Sie eine Abhängigkeit von einem Indexer und einem Skillset annehmen. Eine Liste der neuen Einbettungsfertigkeiten finden Sie unter Laden von Vektordaten und im Abschnitt Pull-APIs.
Fügen Sie einen vectorSearch-Abschnitt im Index hinzu, der Komprimierungseinstellungen und die Suchalgorithmen angibt, die zum Erstellen des Einbettungsraums verwendet werden. Weitere Informationen finden Sie unter Konfigurieren der Vektorquantisierung und des reduzierten Speichers.
vectorSearch.compressions.kind muss den Wert scalarQuantization haben.
rerankWithOriginalVectors verwendet die ursprünglichen, nicht komprimierten Vektoren, um Die Ähnlichkeit neu zu berechnen und die top-Ergebnisse zu reranken, die von der ursprünglichen Suchabfrage zurückgegeben werden. Die nicht komprimierten Vektoren sind im Suchindex vorhanden, auch wenn stored "false" ist. Diese Eigenschaft ist optional. Der Standardwert ist korrekt.
defaultOversampling betrachtet eine breitere Reihe potenzieller Ergebnisse, um die Verringerung der Informationen aus der Quantisierung zu verrechnen. Die Formel für potenzielle Ergebnisse besteht aus der k Abfrage mit einem Oversampling-Multiplikator. Wenn die Abfrage beispielsweise einen k Wert von 5 angibt und die Oversampling 20 ist, fordert die Abfrage effektiv 100 Dokumente für die Verwendung in Reranking an, wobei der ursprüngliche nicht komprimierte Vektor zu diesem Zweck verwendet wird. Es werden nur die top rerangierten k Ergebnisse zurückgegeben. Diese Eigenschaft ist optional. Der Standardwert ist 4.
quantizedDataType muss auf int8 festgelegt werden. Dies ist der einzige Grundtyp, der derzeit unterstützt wird. Diese Eigenschaft ist optional. Der Standardwert ist int8.
2023-10-01-Vorschau fügt interne Vektorisierung hinzu, die Vektorsuchkonfiguration (vectorSearch Struktur) ist jedoch größtenteils identisch mit der Version 2023-11-01.
Name der Konfiguration. Der Name muss innerhalb des Index eindeutig sein.
profiles sind neu in dieser Vorschauversion. Sie fügen eine Abstraktionsebene für umfangreichere Definitionen hinzu. Ein Profil wird in vectorSearch definiert und anschließend als Eigenschaft für jedes Vektorfeld festgelegt.
hnsw und "exhaustiveKnn" sind die ANN-Algorithmen (Approximate Nearest Neighbors, ungefähre nächste Nachbarn), die zum Organisieren von Vektorinhalten während der Indizierung verwendet werden.
Der Standardwert für m (Anzahl bidirektionaler Verknüpfungen) beträgt 4. Der Bereich liegt zwischen 4 und 10. Niedrigere Werte sollten zu einer geringeren Anzahl falscher Ergebnisse führen.
Der Standardwert für efConstruction ist 400. Der Bereich liegt zwischen 100 und 1.000. Dies ist die Anzahl der nächsten Nachbarn, die während der Indizierung verwendet werden.
Der Standardwert für efSearch ist 500. Der Bereich liegt zwischen 100 und 1.000. Dies ist die Anzahl der nächsten Nachbarn, die während der Suche verwendet werden.
metric muss „Kosinus“ sein, wenn Sie Azure OpenAI verwenden. Verwenden Sie andernfalls die Ähnlichkeitsmetrik, die dem verwendeten Einbettungsmodell zugeordnet ist. Folgende Werte werden unterstützt: cosine, dotProduct, euclidean.
Wichtig
2023-07-01-Vorschau war die erste REST-API-Version zur Unterstützung von Vektoren. Es verwendet veraltete Strukturen, die in neueren Vorschauen ersetzt wurden. Es wird empfohlen, zu einer neueren REST-API zu migrieren.
Diese Vorschau hat Folgendes hinzugefügt:
vectorSearch.algorithmConfigurations zum Angeben des HNSW-Algorithmus.
Nearest Neighbor-Algorithmus vom Typ hnsw zum Indizieren von Vektorinhalten.
Name der Konfiguration. Der Name muss innerhalb des Index eindeutig sein.
hnsw ist der ANN-Algorithmus (Approximate Nearest Neighbors, ungefähre nächste Nachbarn), der zum Erstellen des Näherungsdiagramms während der Indizierung verwendet wird. In dieser API-Version wird nur HNSW (Hierarchical Navigable Small World) unterstützt.
Der Standardwert für m (Anzahl bidirektionaler Verknüpfungen) beträgt 4. Der Bereich liegt zwischen 4 und 10. Niedrigere Werte sollten zu einer geringeren Anzahl falscher Ergebnisse führen.
Der Standardwert für efConstruction ist 400. Der Bereich liegt zwischen 100 und 1.000. Dies ist die Anzahl der nächsten Nachbarn, die während der Indizierung verwendet werden.
Der Standardwert für efSearch ist 500. Der Bereich liegt zwischen 100 und 1.000. Dies ist die Anzahl der nächsten Nachbarn, die während der Suche verwendet werden.
metric muss „Kosinus“ sein, wenn Sie Azure OpenAI verwenden. Verwenden Sie andernfalls die Ähnlichkeitsmetrik, die dem verwendeten Einbettungsmodell zugeordnet ist. Folgende Werte werden unterstützt: cosine, dotProduct, euclidean.
Hinzufügen eines Vektorfelds zur Felderauflistung
Die Felderauflistung muss ein Feld für den Dokumentschlüssel, Vektorfelder und alle anderen Felder enthalten, die Sie für Hybridsuchszenarien benötigen.
Vektorfelder zeichnen sich durch ihren Datentyp aus, eine dimensions-Eigenschaft basierend auf dem Einbettungsmodell, das zum Ausgeben der Vektoren und eines Vektorprofils verwendet wird.
Definieren Sie ein Vektorfeld mit den folgenden Attributen. Sie können eine generierte Einbettung pro Feld speichern. Für jedes Vektorfeld:
type muss in dieser API-Version Collection(Edm.Single) sein.
dimensions ist die Anzahl der Dimensionen, die vom Einbettungsmodell generiert werden. Für „text-embedding-ada-002“ ist dieser Wert 1536.
vectorSearchProfile ist der Name eines Profils, das an anderer Stelle im Index definiert ist.
searchable muss den Wert „true“ haben.
retrievable kann true oder false sein. „true“ gibt die unformatierten Vektoren (1536) als Nur-Text zurück und verbraucht Speicherplatz. Legen Sie diese Einstellung auf „true“ fest, wenn Sie ein Vektorergebnis an eine nachgeschaltete App übergeben.
filterable, facetable und sortable müssen den Wert „false“ haben.
Fügen Sie der Auflistung filterbare Nicht-Vektorfelder hinzu, z. B. „title“, und legen Sie dabei filterable auf „true“ fest, wenn Sie Vorfilterung oder Nachfilterung für die Vektorabfrage aufrufen möchten.
Fügen Sie weitere Felder hinzu, die den Inhalt und die Struktur des Textinhalts definieren, den Sie indizieren. Sie benötigen mindestens einen Dokumentschlüssel.
Sie sollten auch Felder hinzufügen, die in der Abfrage oder in ihrer Antwort nützlich sind. Das folgende Beispiel zeigt Vektorfelder für Titel und Inhalt („titleVector“, „contentVector“), die Vektoren entsprechen. Außerdem werden Felder für äquivalente Textinhalte („title“, „content“) bereitgestellt, die beim Sortieren, Filtern und Lesen in einem Suchergebnis hilfreich sind.
Vektorfelddefinitionen sind mit Version 2024-03-01-Vorschau identisch, mit Ausnahme eines neuen binären Datentyps. Weitere Informationen finden Sie unter Indizieren von Binärdaten für die Vektorsuche.
Fügen Sie Vektorfelder zur Felderauflistung hinzu. Sie können eine generierte Einbettung pro Dokumentfeld speichern. Für jedes Vektorfeld:
type kann Collection(Edm.Single), Collection(Edm.Half), Collection(Edm.Int16), Collection(Edm.SByte) sein
dimensions ist die Anzahl der Dimensionen, die vom Einbettungsmodell generiert werden. Für „text-embedding-ada-002“ ist dieser Wert 1536.
vectorSearchProfile ist der Name eines Profils, das an anderer Stelle im Index definiert ist.
searchable muss den Wert „true“ haben.
retrievable kann true oder false sein. „true“ gibt die unformatierten Vektoren (1536) als Nur-Text zurück und verbraucht Speicherplatz. Legen Sie diese Einstellung auf „true“ fest, wenn Sie ein Vektorergebnis an eine nachgeschaltete App übergeben. False ist erforderlich, wenn stored „false“ ist.
stored ist eine neue boolesche Eigenschaft, die nur für Vektorfelder gilt. True speichert eine Kopie von Vektoren, die in Suchergebnissen zurückgegeben werden. False verwirft diese Kopie während der Indizierung. Sie können nach Vektoren suchen, aber keine Vektoren in Ergebnissen zurückgeben.
filterable, facetable und sortable müssen den Wert „false“ haben.
Im folgenden REST-API-Beispiel enthalten „title“ und „content“ Textinhalte, die in der Volltextsuche und semantischen Rangfolge verwendet werden, während „titleVector“ und „contentVector“ Vektordaten enthalten. In dieser API-Version können Sie Indexer und ein Skillset verwenden, um das Vektorfeld mithilfe der integrierten Vektorisierung aufzufüllen. Die Indexdefinition ändert sich nicht, Aber Sie können Ihrer Lösung Indexer und Fähigkeiten hinzufügen, um die Felder aufzufüllen.
Fügen Sie Vektorfelder zur Felderauflistung hinzu. Sie können eine generierte Einbettung pro Dokumentfeld speichern. Für jedes Vektorfeld:
type muss den Wert Collection(Edm.Single) haben.
dimensions ist die Anzahl der Dimensionen, die vom Einbettungsmodell generiert werden. Für „text-embedding-ada-002“ ist dieser Wert 1536.
vectorSearchProfile ist der Name eines Profils, das an anderer Stelle im Index definiert ist.
searchable muss den Wert „true“ haben.
retrievable kann true oder false sein. „true“ gibt die unformatierten Vektoren (1536) als Nur-Text zurück und verbraucht Speicherplatz. Legen Sie diese Einstellung auf „true“ fest, wenn Sie ein Vektorergebnis an eine nachgeschaltete App übergeben.
filterable, facetable und sortable müssen den Wert „false“ haben.
Fügen Sie der Auflistung filterbare Nicht-Vektorfelder hinzu, z. B. „title“, und legen Sie dabei filterable auf „true“ fest, wenn Sie Vorfilterung oder Nachfilterung für die [Vektorabfrage](vector-search-how-to-query.md) aufrufen möchten.
Fügen Sie weitere Felder hinzu, die den Inhalt und die Struktur des Textinhalts definieren, den Sie indizieren. Sie benötigen mindestens einen Dokumentschlüssel.
Sie sollten auch Felder hinzufügen, die in der Abfrage oder in ihrer Antwort nützlich sind. Das folgende Beispiel zeigt Vektorfelder für Titel und Inhalt („titleVector“, „contentVector“), die Vektoren entsprechen. Außerdem werden Felder für äquivalente Textinhalte („title“, „content“) bereitgestellt, die beim Sortieren, Filtern und Lesen in einem Suchergebnis hilfreich sind.
2023-07-01-Vorschau war die erste REST-API-Version zur Unterstützung von Vektorszenarien.
Im folgenden REST-API-Beispiel enthalten „title“ und „content“ Textinhalte, die in der Volltextsuche und semantischen Rangfolge verwendet werden, während „titleVector“ und „contentVector“ Vektordaten enthalten, die extern generiert wurden.
Fügen Sie Vektorfelder zur Felderauflistung hinzu. Sie können eine generierte Einbettung pro Dokumentfeld speichern. Für jedes Vektorfeld:
Weisen Sie den Datentyp Collection(Edm.Single) zu.
Geben Sie den Namen der Konfiguration für den Vektorsuchalgorithmus an.
Geben Sie die Anzahl der Dimensionen an, die vom Einbettungsmodell generiert werden.
Legen Sie Attribute fest:
„searchable“ muss auf „true“ festgelegt werden.
Wenn Sie „retrievable“ auf „true“ festlegen, können Sie die unformatierten Vektoren (z. B. als Überprüfungsschritt) anzeigen. Dadurch wird jedoch mehr Speicherplatz benötigt. Legen Sie diesen Wert auf „false“ fest, wenn Sie keine unformatierten Vektoren zurückgeben müssen. Sie müssen keine Vektoren für eine Abfrage zurückgeben, aber wenn Sie ein Vektorergebnis an eine Downstream-App übergeben, legen Sie „retrievable“ auf „true“ fest.
Die Attribute „filterable“, „facetable“, „sortable“ müssen auf „false“ festgelegt werden. Legen Sie sie nicht auf „true“ fest, da diese Verhaltensweisen nicht im Kontext von Vektorfeldern gelten und die Anforderung dann nicht erfolgreich ist.
Fügen Sie weitere Felder hinzu, die den Inhalt und die Struktur des Textinhalts definieren, den Sie indizieren. Sie benötigen mindestens einen Dokumentschlüssel.
Sie sollten auch Felder hinzufügen, die in der Abfrage oder in ihrer Antwort nützlich sind. Das folgende Beispiel zeigt Vektorfelder für Titel und Inhalt („titleVector“, „contentVector“), die Vektoren entsprechen. Außerdem werden Felder für äquivalente Textinhalte („title“, „content“) bereitgestellt, die beim Sortieren, Filtern und Lesen in einem Suchergebnis hilfreich sind.
Eine Indexdefinition mit den beschriebenen Elementen sieht wie folgt aus:
Inhalte, die Sie für die Indizierung bereitstellen, müssen dem Indexschema entsprechen und einen eindeutigen Zeichenfolgenwert für den Dokumentschlüssel enthalten. Vorab vektorisierte Daten werden in Vektorfelder geladen, die neben anderen Feldern vorhanden sein können, die alphanumerische Inhalte enthalten.
Verwenden Sie Dokumente – Index, um Vektor- und Nichtvektordaten in einen Index zu laden. Die Push-APIs für die Indizierung sind in allen stabilen und Vorschauversionen identisch. Verwenden Sie eine der folgenden APIs zum Laden von Dokumenten:
POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/index?api-version=2023-11-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
"value": [
{
"id": "1",
"title": "Azure App Service",
"content": "Azure App Service is a fully managed platform for building, deploying, and scaling web apps. You can host web apps, mobile app backends, and RESTful APIs. It supports a variety of programming languages and frameworks, such as .NET, Java, Node.js, Python, and PHP. The service offers built-in auto-scaling and load balancing capabilities. It also provides integration with other Azure services, such as Azure DevOps, GitHub, and Bitbucket.",
"category": "Web",
"titleVector": [
-0.02250031754374504,
. . .
],
"contentVector": [
-0.024740582332015038,
. . .
],
"@search.action": "upload"
},
{
"id": "2",
"title": "Azure Functions",
"content": "Azure Functions is a serverless compute service that enables you to run code on-demand without having to manage infrastructure. It allows you to build and deploy event-driven applications that automatically scale with your workload. Functions support various languages, including C#, F#, Node.js, Python, and Java. It offers a variety of triggers and bindings to integrate with other Azure services and external services. You only pay for the compute time you consume.",
"category": "Compute",
"titleVector": [
-0.020159931853413582,
. . .
],
"contentVector": [
-0.02780858241021633,
. . .
],
"@search.action": "upload"
}
. . .
]
}
Alle neueren Vorschauversionen verwenden Pull-APIs (Indexer und Skillsets) für die integrierte Vektorisierung während der Indizierung und Abfragezeit.
Indexer können Vektorfelder in Quelldokumenten abrufen und indizieren. Dabei werden ein Indexschema, das Vektorfeldanforderungen erfüllt, und die Vorschau-REST-API vorausgesetzt. Datenquellen stellen die Vektoren in dem von der Datenquelle unterstützten Format bereit (z. B. Zeichenfolgen in JSON). Der Indexer geht davon aus, dass Felder, die als Collection(Edm.Single) eingegeben wurden, Vektoren enthalten, und indiziert diese Inhalte als Vektorindizes.
Es gibt keine Änderungen am Feldzuordnungsverhalten oder an der Änderungserkennung für Vektoren. Die Verhaltensweisen für die Textindizierung gelten auch für Vektoren.
Wenn Vektordaten aus Dateien stammen, empfehlen wir basierend auf der Form der Daten einen nicht standardmäßigen Analysemodus (parsingMode) wie json, jsonLines oder csv.
Azure SQL bietet keine Möglichkeit, eine Auflistung nativ als einzelne SQL-Spalte zu speichern. Zurzeit gibt es keine Problemumgehung.
Die Dimensionen aller Vektoren aus der Datenquelle müssen identisch sein und der Indexdefinition für das Feld entsprechen, dem sie zugeordnet sind. Der Indexer löst einen Fehler für alle Dokumente aus, die nicht übereinstimmen.
Fähigkeiten und Vektorisierer werden verwendet, um Einbettungen zu generieren. Wählen Sie für die Vektorisierung während der Indizierung die folgenden Skills aus:
Zu Überprüfungszwecken können Sie den Index mithilfe des Suchexplorers im Azure-Portal oder eines REST-API-Aufrufs abfragen. Da Azure KI Search einen Vektor nicht in lesbaren Text konvertieren kann, versuchen Sie, Felder aus demselben Dokument zurückzugeben, die Nachweise für die Übereinstimmung liefern. Wenn die Vektorabfrage z. B. auf das Feld „titleVector“ ausgerichtet ist, können Sie „title“ für die Suchergebnisse auswählen.
Felder müssen durch das Attribut „retrievable“ gekennzeichnet sein, damit sie in die Ergebnisse einbezogen werden.
Sie können den Suchexplorer verwenden, um einen Index abzufragen. Der Suchexplorer verfügt über zwei Ansichten: Abfrageansicht (Standard) und JSON-Ansicht.
Verwenden Sie die Standardabfrageansicht, um schnell zu bestätigen, dass der Index Vektoren enthält. Die Abfrageansicht ist für die Volltextsuche vorgesehen. Obwohl Sie sie nicht für Vektorabfragen verwenden können, können Sie eine leere Suche (search=*) senden, um nach Inhalten zu suchen. Die Inhalte aller Felder, einschließlich Vektorfeldern, werden als Nur-Text zurückgegeben.
Das folgende REST-API-Beispiel ist eine Vektorabfrage, gibt jedoch nur Nicht-Vektorfelder (Titel, Inhalt, Kategorie) zurück. Nur die als „retrievable“ markierten Felder können in Suchergebnissen zurückgegeben werden.
Um einen Vektorspeicher zu aktualisieren, ändern Sie das Schema und laden Sie gegebenenfalls die Dokumente neu, um die neuen Felder zu füllen. APIs für das Aktualisieren eines Schemas umfassen Create or Update Index (REST), CreateOrUpdateIndex im Azure SDK für .NET, create_or_update_index im Azure SDK für Python und ähnliche Methoden in anderen Azure SDKs.
Das Verwerfen und Neuerstellen ist häufig für Aktualisierungen und das Löschen bestehender Felder erforderlich.
Sie können jedoch ein bestehendes Schema mit den folgenden Änderungen aktualisieren, ohne dass eine Neuerstellung erforderlich ist:
Fügen Sie neue Felder zu einer Feldsammlung hinzu.
Fügen Sie neue Vektorkonfigurationen hinzu, die neuen Feldern zugewiesen werden, aber nicht bestehenden Feldern, die bereits vektorisiert wurden.
Ändern Sie die Option „abrufbar“ (Werte sind true oder false) für ein bestehendes Feld. Vektorfelder müssen durchsuchbar und abrufbar sein. Wenn Sie jedoch den Zugriff auf ein Vektorfeld in Situationen deaktivieren möchten, in denen das Ablegen und Wiederherstellen nicht möglich ist, können Sie „abrufbar“ auf „false“ setzen.
Codebeispiele im Repository azure-search-vector veranschaulichen End-to-End-Workflows, die Schemadefinition, Vektorisierung, Indizierung und Abfragen enthalten.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.