Freigeben über

Definieren einer Indexprojektion für die Indizierung von über- und untergeordneten Elementen

  • Artikel

Bei Indizes, die aufgeteilte Dokumente enthalten, gibt eine Indexprojektion an, wie über- und untergeordnete Inhalte Feldern in einem Suchindex für die 1:n-Indizierung zugeordnet werden. Über eine Indexprojektion können Sie Inhalte an Folgendes senden:

  • einen einzelnen Index, in dem die übergeordneten Felder für jeden Block wiederholt werden, sich das Grain-Element des Indexes auf der Blockebene befindet. Das RAG-Tutorial ist ein Beispiel für diesen Ansatz.

  • mindestens zwei Indizes, bei denen der übergeordnete Index Felder im Zusammenhang mit dem übergeordneten Dokument enthält, und der untergeordnete Index um Blöcke herum organisiert ist. Der untergeordnete Index ist der primäre Suchkorpus, aber der übergeordnete Index kann für Suchabfragen verwendet werden, wenn Sie die übergeordneten Felder eines bestimmten Blocks abrufen möchten, oder für unabhängige Abfragen genutzt werden.

Bei den meisten Implementierungen handelt es sich um einen einzelnen Index, der um Blöcke herum organisiert ist, wobei übergeordnete Felder, wie der Dateiname des Dokuments, für jeden Block wiederholt werden. Das System ist jedoch so konzipiert, dass separate und mehrere untergeordnete Indizes unterstützt werden, wenn dies Ihre Anforderung ist. Azure KI-Suche unterstützt keine Indexjoins, sodass Ihr Anwendungscode den zu verwendenden Index verarbeiten muss.

Eine Indexprojektion wird in einem Skillset definiert. Es ist für die Koordinierung des Indizierungsprozesses verantwortlich, der Blöcke von Inhalten an einen Suchindex sendet, zusammen mit den übergeordneten Inhalten, die den einzelnen Blöcken zugeordnet sind. Es verbessert die Funktionsweise der nativen Datenblockerstellung, indem Sie weitere Optionen zum Steuern der Indizierung von über- und untergeordneten Inhalten erhalten.

In diesem Artikel wird erläutert, wie Sie das Indexschema und Indexerprojektionsmuster für die 1:n-Indizierung erstellen.

Voraussetzungen

Das Skillset enthält die Indexerprojektion, die die Daten für die 1:n-Indizierung formatiert. Ein Skillset kann auch andere Skills enthalten, z. B. einen Einbettungsskill wie AzureOpenAIEmbedding, wenn Ihr Szenario integrierte Vektorisierung umfasst.

Abhängigkeit von der Indexerverarbeitung

Die 1:n-Indizierung erfordert eine Abhängigkeit von Skillsets und indexerbasierter Indizierung, die die folgenden vier Komponenten umfasst:

  • Datenquelle
  • Mindestens einen Index für Ihre durchsuchbaren Inhalte
  • Ein Skillset, das eine Indexprojektion enthält*
  • Indexer

Ihre Daten können aus einer beliebigen unterstützten Datenquelle stammen. Es wird jedoch davon ausgegangen, dass der Inhalt umfangreich genug für die Blockerstellung ist und der Grund für die Blockerstellung darin besteht, dass Sie ein RAG-Muster implementieren, das Groundingdaten für ein Chatmodell bereitstellt. Oder Sie implementieren die Vektorsuche und müssen die Anforderungen in Bezug auf kleinere Eingaben von Einbettungsmodellen erfüllen.

Indexer laden indizierte Daten in einen vordefinierten Index. Wie Sie das Schema definieren und ob ein oder mehrere Indizes verwendet werden sollen, ist die erste Entscheidung bei einem Szenario mit 1:n-Indizierung. Im nächsten Abschnitt wird der Indexentwurf behandelt.

Erstellen eines Indexes für die 1:n-Indizierung

Unabhängig davon, ob Sie einen Index für Blöcke erstellen, die übergeordnete Werte wiederholen, oder separate Indizes für die Platzierung von über- und untergeordneten Feldern, ist der primäre Index für die Suche um Datenblöcke herum konzipiert. Die folgenden Felder müssen enthalten sein:

  • Ein Dokumentschlüsselfeld, das jedes Dokument eindeutig identifiziert. Es muss als Typ Edm.String mit dem keyword-Analysetool definiert werden.

  • Ein Feld, das jeden Block mit dem übergeordneten Element verknüpft. Das Objekt muss vom Typ Edm.String sein. Es darf sich nicht um das Dokumentschlüsselfeld handeln, und filterable muss auf „true“ festgelegt sein. In diesem Artikel wird in den Beispielen wird darauf als „parent_id“ und als projizierter Schlüsselwert verwiesen.

  • Andere Felder für Inhalte, z. B. Felder für Text oder vektorisierte Blöcke

Ein Index muss für den Suchdienst vorhanden sein, bevor Sie das Skillset erstellen oder den Indexer ausführen.

Einzelnes Indexschema mit über- und untergeordneten Feldern

Ein einzelner Index, der um Blöcke herum organisiert ist, wobei sich der übergeordnete Inhalt für jeden Block wiederholt, ist das vorherrschende Muster für RAG- und Vektorsuchszenarien. Die Fähigkeit, jedem Block den richtigen übergeordneten Inhalt zuzuordnen, wird durch Indexprojektionen ermöglicht.

Das folgende Schema ist ein Beispiel, das die Anforderungen für Indexprojektionen erfüllt. In diesem Beispiel sind übergeordnete Felder „parent_id“ und der Titel. Untergeordnete Felder sind die Blöcke mit und ohne Vektor. „chunk_id“ ist die Dokument-ID dieses Indexes. „parent_id“ und der Titel wiederholen sich für jeden Block im Index.

Zum Erstellen eines Indexes können Sie das Azure-Portal, REST-APIs oder ein Azure SDK verwenden.

{
    "name": "my_consolidated_index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
        {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    }
}

Hinzufügen von Indexprojektionen zu einem Skillset

Indexprojektionen werden in einer Skillsetdefinition und in erster Linie als Array von selectors definiert, wobei jeder Selektor einem anderen Zielindex im Suchdienst entspricht. Dieser Abschnitt beginnt mit Syntax und Beispielen für Kontext, gefolgt von der Parameterreferenz.

Wählen Sie die entsprechende Registerkarte für die API-Syntax aus. Es gibt derzeit keine Portalunterstützung für das Einrichten von Projektionen, außer beim Bearbeiten der JSON-Definition des Skillset. Sehen Sie sich dazu das REST-Beispiel für JSON an.

Indexprojektionen sind allgemein verfügbar. Wir empfehlen die neueste stabile API:

Hier ist eine Beispielnutzlast für eine Indexprojektionsdefinition, mit der Sie einzelne Seiten projizieren können, die vom Textaufteilungsskill als eigene Dokumente im Suchindex ausgegeben werden.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my_consolidated_index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "title",
                    "source": "/document/title",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Parameterreferenz

Indexprojektionsparameter Definition
selectors Parameter für den Hauptsuchkorpus, in der Regel derjenige, der um Blöcke herum organisiert ist
projectionMode Ein optionaler Parameter, der Anweisungen für den Indexer bereitstellt. Der einzige gültige Wert für diesen Parameter ist skipIndexingParentDocuments. Er wird verwendet, wenn der Blockindex der primäre Suchkorpus ist, und Sie müssen angeben, ob übergeordnete Felder als zusätzliche Suchdokumente im aufgeteilten Index indiziert werden. Wenn Sie skipIndexingParentDocuments nicht festlegen, erhalten Sie zusätzliche Suchdokumente in Ihrem Index, die für Blöcke null sind, aber nur mit übergeordneten Feldern aufgefüllt werden. Wenn beispielsweise fünf Dokumente 100 Blöcke zum Index beitragen, beträgt die Anzahl der Dokumente im Index 105. Die fünf erstellten Dokumente oder übergeordneten Felder weisen Nullwerte für Blockfelder (untergeordnete Felder) auf, wodurch sie sich wesentlich vom Großteil der Dokumente im Index unterscheiden. Es wird empfohlen, projectionMode auf skipIndexingParentDocument festzulegen.

Selektoren enthalten die folgenden Parameter als Teil der Definition.

Selektorparameter Definition
targetIndexName Der Name des Indexes, in den Indexdaten projiziert werden. Es handelt sich entweder um den einzelnen aufgeteilten Index mit wiederholten übergeordneten Feldern oder um den untergeordneten Index, wenn Sie separate Indizes für über- und untergeordnete Inhalte verwenden.
parentKeyFieldName Der Name des Felds, das den Schlüssel für das übergeordnete Dokument angibt
sourceContext Die Anreicherungsanmerkung, welche die Granularität definiert, mit der Daten einzelnen Suchdokumenten zugeordnet werden sollen. Weitere Informationen finden Sie unter Skills-Kontext und Eingabeanmerkungssprache.
mappings Ein Array von Zuordnungen von angereicherten Daten zu Feldern im Suchindex. Jede Zuordnung besteht aus:
name: Der Name des Felds im Suchindex, in das die Daten indiziert werden sollen.
source: Der Anreicherungsanmerkungspfad, aus dem die Daten abgerufen werden sollen.

Jede mapping kann Daten auch rekursiv mit einem optionalen sourceContext- und inputs-Feld definieren, ähnlich wie der Wissensspeicher oder Shaper Skill. Abhängig von Ihrer Anwendung können Sie mit diesen Parametern Daten in Felder des Typs Edm.ComplexType im Suchindex formen. Einige LLMs akzeptieren keinen komplexen Typ in Suchergebnissen. Daher bestimmt das verwendete LLM, ob die Zuordnung eines komplexen Typs hilfreich ist oder nicht.

Der mappings-Parameter ist wichtig. Sie müssen jedes Feld im untergeordneten Index explizit zuordnen, mit Ausnahme der ID-Felder, etwa Dokumentschlüssel und übergeordnete ID.

Diese Anforderung steht im Gegensatz zu anderen Feldzuordnungskonventionen in Azure KI-Suche. Bei einigen Datenquellentypen kann der Indexer Felder implizit basierend auf ähnlichen Namen oder bekannten Merkmalen zuordnen. (Blobindexer verwenden beispielsweise den eindeutigen Metadatenspeicherpfad als Standarddokumentschlüssel.) Bei Indexerprojektionen müssen Sie jedoch explizit jede Feldzuordnung auf der n-Seite der Beziehung angeben.

Erstellen Sie keine Feldzuordnung für das übergeordnete Schlüsselfeld. Dadurch werden die Änderungsnachverfolgung und die synchronisierte Datenaktualisierung unterbrochen.

Behandeln übergeordneter Dokumente

Sie haben nun mehrere Muster für 1:n-Indizierungen gesehen haben. Vergleichen wir jetzt die wichtigsten Unterschiede der einzelnen Optionen. Indexprojektionen generieren effektiv „untergeordnete“ Dokumente für jedes „übergeordnete“ Dokument, das durch ein Skillset ausgeführt wird. Sie haben mehrere Optionen für die Behandlung der „übergeordneten“ Dokumente.

  • Wenn Sie Dokumente mit übergeordneten und untergeordneten Elementen an separate Indizes senden möchten, legen Sie targetIndexName für die Indexerdefinition auf den übergeordneten Index und targetIndexName im Indexprojektionsselektor auf den untergeordneten Index fest.

  • Um übergeordnete und untergeordnete Dokumente im selben Index beizubehalten, legen Sie targetIndexName des Indexers und targetIndexName der Indexprojektion auf denselben Index fest.

  • Um das Erstellen übergeordneter Suchdokumente zu vermeiden und sicherzustellen, dass der Index nur untergeordnete Dokumente eines einheitlichen Grain-Elements enthält, legen Sie targetIndexName sowohl für die Indexdefinition als auch für den Selektor auf denselben Index fest, fügen sie jedoch nach selectors ein zusätzliches parameters-Objekt hinzu. Legen Sie dabei einen projectionMode-Schlüssel auf skipIndexingParentDocuments fest, wie hier gezeigt:

    "indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Überprüfen von Feldzuordnungen

Indexer sind mit drei verschiedenen Arten von Feldzuordnungen verbunden. Vor dem Ausführen des Indexers sollten Sie die Feldzuordnungen überprüfen und wissen, wann sie die einzelnen Typen verwenden.

Feldzuordnungen werden in einem Indexer definiert und zum Zuordnen eines Quellfelds zu einem Indexfeld verwendet. Feldzuordnungen werden für Datenpfade verwendet, mit denen Daten aus der Quelle entnommen und zur Indizierung übergeben werden, ohne dass ein Zwischenschritt zur Skillverarbeitung erfolgt. In der Regel kann ein Indexer Felder, die denselben Namen und Typ aufweisen, automatisch zuordnen. Explizite Feldzuordnungen sind nur erforderlich, wenn Abweichungen vorliegen. Bei der 1:n-Indizierung und den bisher erläuterten Mustern benötigen Sie möglicherweise keine Feldzuordnungen.

Ausgabefeldzuordnungen werden in einem Indexer definiert und zum Zuordnen von angereicherten Inhalten, die von einem Skillset generiert werden, zu einem Feld im Hauptindex verwendet. In den in diesem Artikel behandelten 1:n-Mustern ist dies der übergeordnete Index in einer Lösung mit zwei Indizes. In den in diesem Artikel gezeigten Beispielen hat der übergeordnete Index nur ein Titelfeld, und dieses Feld wird nicht mit Inhalten aus der Skillsetverarbeitung aufgefüllt, daher ist keine Ausgabefeldzuordnung vorhanden.

Zuordnungen von Indexerprojektionsfeldern werden verwendet, um vom Skillset generierte Inhalte Feldern im untergeordneten Index zuzuordnen. Falls der untergeordnete Index auch übergeordnete Felder enthält (wie in der konsolidierten Indexlösung), sollten Sie Feldzuordnungen für jedes Feld mit Inhalt einrichten, einschließlich des Titelfelds auf übergeordneter Ebene, vorausgesetzt, dass der Titel in jedem aufgeteilten Dokument angezeigt werden soll. Wenn Sie separate übergeordnete und untergeordnete Indizes verwenden, sollten die Indexerprojektionen Feldzuordnungen für nur die Felder auf untergeordneter Ebene aufweisen.

Hinweis

Sowohl Ausgabefeldzuordnungen als auch Zuordnungen von Indexerprojektionsfeldern akzeptieren angereicherte Dokumentstrukturknoten als Quelleingaben. Zum Einrichtn des Datenpfads ist es wichtig zu wissen, wie ein Pfad zu den einzelnen Knoten angegeben wird. Weitere Informationen zur Pfadsyntax erhalten Sie in den Beispielen unter Verweisen auf einen Pfad zu angereicherten Knoten und Skillsetdefinition.

Ausführen des Indexers

Nachdem Sie eine Datenquelle, Indizes und ein Skillset erstellt haben, können Sie den Indexer erstellen und ausführen. In diesem Schritt wird die Pipeline ausgeführt.

Sie können den Suchindex nach Abschluss der Verarbeitung abfragen, um Ihre Lösung zu testen.

Inhaltslebenszyklus

Abhängig von der zugrunde liegenden Datenquelle kann ein Indexer in der Regel fortlaufende Änderungsnachverfolgung und Löscherkennung bereitstellen. In diesem Abschnitt wird der Inhaltslebenszyklus der 1:n-Indizierung im Zusammenhang mit der Datenaktualisierung erläutert.

Bei Datenquellen, die Änderungsnachverfolgung und Löscherkennung bereitstellen, kann ein Indexerprozess Änderungen in Ihren Quelldaten abrufen. Bei jeder Ausführung des Indexers und des Skillsets werden die Indexprojektionen aktualisiert, wenn sich das Skillset oder die zugrunde liegenden Quelldaten geändert haben. Alle vom Indexer übernommenen Änderungen werden über den Anreicherungsprozess an die Projektionen im Index weitergegeben, um sicherzustellen, dass Ihre projizierten Daten eine aktuelle Darstellung des Inhalts in der ursprünglichen Datenquelle sind. Die Datenaktualisierungsaktivität wird in einem projizierten Schlüsselwert für jeden Block erfasst. Dieser Wert wird aktualisiert, wenn sich die zugrunde liegenden Daten ändern.

Hinweis

Sie können die Daten in den projizierten Dokumenten zwar manuell mithilfe der Index-Push-API- bearbeiten, sollten dies jedoch vermeiden. Manuelle Aktualisierungen eines Indexes werden beim nächsten Pipelineaufruf überschrieben, vorausgesetzt, das Dokument in den Quelldaten wird aktualisiert, und für die Datenquelle ist die Änderungsnachverfolgung oder Löscherkennung aktiviert.

Aktualisierter Inhalt

Wenn Sie Ihrer Datenquelle neue Inhalte hinzufügen, werden dem Index bei der nächsten Ausführung des Indexers neue Blöcke oder untergeordnete Dokumente hinzugefügt.

Wenn Sie vorhandene Inhalte in der Datenquelle ändern, werden Blöcke inkrementell im Suchindex aktualisiert, wenn die von Ihnen verwendete Datenquelle Änderungsnachverfolgung und Löscherkennung unterstützt. Wenn sich ein Wort oder Satz in einem Dokument ändert, wird der Block im Zielindex, der dieses Wort oder diesen Satz enthält, bei der nächsten Indexerausführung aktualisiert. Andere Arten der Aktualisierung, z. B. Ändern eines Feldtyps und einiger Zuordnungen, werden für vorhandene Felder nicht unterstützt. Weitere Informationen zu zulässigen Updates finden Sie unter Aktualisieren von Indexschemas.

Einige Datenquellen wie Azure Storage unterstützen Änderungs- und Löschnachverfolgung standardmäßig basierend auf dem Zeitstempel. Andere Datenquellen wie OneLake, Azure SQL oder Azure Cosmos DB müssen für die Änderungsnachverfolgung konfiguriert werden.

Gelöschter Inhalt

Wenn der Quellinhalt nicht mehr vorhanden ist (z. B. wenn Text gekürzt wird, um weniger Blöcke zu haben), wird das entsprechende untergeordnete Dokument im Suchindex gelöscht. Bei den verbleibenden untergeordneten Dokumenten wird auch der Schlüssel aktualisiert, um einen neuen Hashwert einzuschließen, auch wenn sich der Inhalt sonst nicht geändert hat.

Wenn ein übergeordnetes Dokument vollständig aus der Datenquelle gelöscht wird, werden die entsprechenden untergeordneten Dokumente nur gelöscht, wenn der Löschvorgang durch eine auf der Datenquellendefinition definierte dataDeletionDetectionPolicy erkannt wird. Wenn Sie keine konfigurierte dataDeletionDetectionPolicy haben und ein übergeordnetes Dokument aus der Datenquelle löschen müssen, sollten Sie die untergeordneten Dokumente manuell löschen, wenn sie nicht mehr benötigt werden.

Projizierter Schlüsselwert

Um die Datenintegrität für aktualisierte und gelöschte Inhalte sicherzustellen, basiert die Datenaktualisierung in der 1:n-Indizierung auf einem projizierten Schlüsselwert auf der n-Seite. Wenn Sie die integrierte Vektorisierung oder den Assistenten zum Importieren und Vektorisieren von Daten verwenden, ist der Wert des projizierten Schlüssels das Feld parent_id auf einer aufgeteilten Seite oder n-Seite des Indexes.

Der Wert eines projizierten Schlüssels ist ein eindeutiger Bezeichner, den der Indexer für jedes Dokument generiert. Er gewährleistet Eindeutigkeit und ermöglicht die ordnungsgemäße Funktionsweise der Änderungs- und Löschnachverfolgung. Dieser Schlüssel enthält die folgenden Segmente:

  • Ein zufälliger Hash zur Gewährleistung der Eindeutigkeit. Dieser Hash ändert sich, wenn das übergeordnete Dokument bei nachfolgenden Indexerausführungen aktualisiert wird.
  • Der Schlüssel des übergeordneten Dokuments.
  • Der Anreicherungsanmerkungspfad, der den Kontext identifiziert, aus dem das Dokument generiert wurde.

Sie teilen beispielsweise ein übergeordnetes Dokument mit dem Schlüsselwert „aa1b22c33“ in vier Seiten auf, und jede dieser Seiten wird dann als eigenes Dokument über Indexprojektionen projiziert:

  • aa1b22c33
  • aa1b22c33_pages_0
  • aa1b22c33_pages_1
  • aa1b22c33_pages_2

Wenn das übergeordnete Dokument in den Quelldaten aktualisiert wird, was möglicherweise zu mehr aufgeteilten Seiten führt, ändert sich der zufällige Hash, weitere Seiten werden hinzugefügt, und der Inhalt der einzelnen Blöcke wird aktualisiert, um dem Inhalt des Quelldokuments zu entsprechen.

Beispiel für separate über- und untergeordnete Indizes

Dieser Abschnitt enthält Beispiele für separate übergeordnete und untergeordnete Indizes. Es ist zwar ein ungewöhnliches Muster, aber es ist möglich, dass Anwendungsanforderungen vorliegen, die mit diesem Ansatz am besten erfüllt werden. In diesem Szenario projizieren Sie über- und untergeordnete Inhalte in zwei separate Indizes.

Jedes Schema weist die Felder für sein bestimmtes Grain-Element auf, wobei das Feld der übergeordneten ID für beide Indizes gilt und in einer Suchabfrage verwendet werden kann. Der primäre Suchkorpus ist der untergeordnete Index, gibt dann aber eine Suchabfrage aus, um die übergeordneten Felder für jede Übereinstimmung im Ergebnis abzurufen. Azure KI-Suche unterstützt Verknüpfungen zur Abfragezeit nicht, sodass der Anwendungscode oder die Orchestrierungsebene Ergebnisse zusammenführen oder zuordnen muss, die an eine App oder einen Prozess übergeben werden können.

Der übergeordnete Index weist das Feld „parent_id“ und einen Titel auf. „parent_id“ ist der Dokumentschlüssel. Eine Vektorsuchkonfiguration ist nicht erforderlich, es sei denn, Sie möchten Felder auf der Ebene des übergeordneten Dokuments vektorisieren.

{
    "name": "my-parent-index",
    "fields": [

        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
    ]
}

Der untergeordnete Index enthält die in Blöcke aufgeteilten Felder sowie das Feld „parent_id“. Wenn Sie integrierte Vektorisierung, Bewertungsprofile, semantische Sortierer oder Analysetools verwenden, würden Sie diese im untergeordneten Index festlegen.

{
    "name": "my-child-index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
         {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    },
    "scoringProfiles": [],
    "semanticConfiguration": [],
    "analyzers": []
}

Hier sehen Sie ein Beispiel für eine Indexprojektionsdefinition, die den Datenpfad angibt, den der Indexer zum Indizieren von Inhalten verwenden soll. Sie gibt den Namen des untergeordneten Indexes in der Indexprojektionsdefinition und die Zuordnungen aller untergeordneten Felder bzw. aller Felder auf Blockebene an. Dies ist der einzige Ort, an dem der Name des untergeordneten Indexes angegeben wird.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my-child-index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ]
}

Die Indexerdefinition gibt die Komponenten der Pipeline an. In der Indexerdefinition ist der anzugebende Indexname der übergeordnete Index. Wenn Sie Feldzuordnungen für die Felder auf übergeordneter Ebene benötigen, definieren Sie sie in „outputFieldMappings“. Bei der 1:n-Indizierung, die separate Indizes verwendet, kann die Indexerdefinition wie im folgenden Beispiel aussehen:

{
  "name": "my-indexer",
  "dataSourceName": "my-ds",
  "targetIndexName": "my-parent-index",
  "skillsetName" : "my-skillset"
  "parameters": { },
  "fieldMappings": (optional) Maps fields in the underlying data source to fields in an index,
  "outputFieldMappings" : (required) Maps skill outputs to fields in an index,
}

Nächster Schritt

Datenblöcke und 1:n-Indizierung sind Teil des RAG-Musters in Azure KI-Suche. Fahren Sie mit dem folgenden Tutorial und dem folgenden Codebeispiel fort, um mehr darüber zu erfahren.

Erstellen einer RAG-Lösung mit Azure KI-Suche