Definieren einer Indexprojektion für die Eltern-Kind-Indizierung

Wenn Sie Inhalte für ein RAG-Muster oder zur Vektorisierung aufteilen, können Sie eine Indexprojektion angeben, um die one-to-many-Indizierung zu steuern, bei der Quellinhalt (eins) auf einen oder mehrere Indizes (viele) projiziert wird. Ziel einer Indexprojektion ist es, zu steuern, ob Elemente des übergeordneten Dokuments, wie beispielsweise ein Dateiname oder ein Erstellungsdatum, in einem Index gespeichert werden.

• Wiederholen Sie dies für jedes Kind (jeden Abschnitt) in einem einzelnen Index
• Werden als eigenständige Suchdokumente im selben Index indiziert
• Oder werden in getrennte Indizes aufgenommen

Es wird empfohlen, die übergeordneten Felder in einem einzelnen Index zu wiederholen, da unterschiedliche Dokumentstrukturen oder das Aufteilen von Inhalten in zwei Indizes schwierig abzufragen sein können, insbesondere bei der klassischen Suche, bei der Indexverknüpfungen nicht unterstützt werden.

In Azure KI-Suche wird das Chunking durch Fähigkeiten durchgeführt und hängt daher von Indexern ab. Um eine Indexprojektion zu definieren, geben Sie sie in einem Skillset an.

Voraussetzungen

• Azure KI-Suche, jede Ebene oder Region.

• Eine indexerbasierte Indizierungspipeline.

• Eine unterstützte Datenquelle mit Inhalten, die Sie zu abschnitten möchten.

• Ein Index (ein oder mehrere), der die Ausgabe der Indexer-Pipeline akzeptiert.

• Eine Fähigkeit, die Inhalte gliedert, z. B. die Fähigkeit "Textteilung".

Das Skillset enthält die Indexer-Projektion, die sich auf die Daten für die 1:n-Indizierung auswirkt. Ein Skillset könnte auch andere Fähigkeiten haben, z. B. eine Einbettungskompetenz wie AzureOpenAIEmbedding , wenn Ihr Szenario integrierte Vektorisierung umfasst.

Auswählen eines Ansatzes

Indexprojektionen generieren "untergeordnete" Dokumente (Blöcke) für jedes "übergeordnete" Dokument. Wählen Sie, wie übergeordnete Inhalte behandelt werden sollen:

Verwenden Sie für die meisten RAG-Szenarien den ersten Ansatz. Siehe das beispiel classic RAG.

Implementierungsschritte für den empfohlenen Ansatz

1. Erstellen Sie einen Index , der für Blöcke entwickelt wurde, wobei die übergeordneten Felder enthalten sind.
2. Erstellen Sie ein Skillset mit einer Segmentierungsfertigkeit und indexProjections.
3. Erstellen Sie einen Indexer , der auf Ihre unterstützte Datenquelle zeigt.

Wenn Ihre Datenquelle die Änderungsnachverfolgung unterstützt, synchronisiert der Indexer Änderungen automatisch.

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 übergeordneten und untergeordneten Feldern, ist der primäre Index für die Suche um Datenblöcke herum konzipiert. Das Indexschema muss über die folgenden Felder verfügen:

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

• Ein Feld, das jeden Teil mit seinem übergeordneten Objekt verknüpft. Er muss vom Typ Edm.Stringsein. Es kann nicht das Dokumentschlüsselfeld sein und muss auf "true" festgelegt sein filterable . Es wird in den Beispielen als parent_id und als projizierter Schlüsselwert in diesem Artikel bezeichnet.

• Andere Felder für Inhalte, z. B. Text- oder vektorisierte Blockfelder.

Ein Index muss für den Suchdienst vorhanden sein, bevor Sie das Skillset erstellen oder den Indexer ausführen. Das selectors, das Sie im Skillset definieren, sollte diese Felder umfassen.

Einzelnes Indexschema einschließlich übergeordneter und untergeordneter Felder

Ein einzelner Index, der um Datenblöcke herum gestaltet wurde, bei denen sich der übergeordnete Inhalt für jeden Block wiederholt, ist das vorherrschende Muster für RAG- und Vektorsuch-Szenarien. Die Möglichkeit, den richtigen übergeordneten Inhalt jedem Block zuzuordnen, wird über Indexprojektionen aktiviert.

Das folgende Schema ist ein Beispiel, das die Anforderungen für Indexprojektionen erfüllt. In diesem Beispiel:

• Übergeordnete Felder sind die parent_id und der Titel, und sie wiederholen sich für jeden Abschnitt.
• Untergeordnete Felder sind die Blöcke mit und ohne Vektor. Die chunk_id ist die Dokument-ID dieses Indexes.

Sie können das Azure-Portal, REST-APIs oder ein Azure-SDK verwenden, um einen Index zu erstellen.

{
    "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": "hnsw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hnsw", "algorithm": "hnsw"}]
    }
}

 # Create a search index  
 index_name = "my_consolidated_index"
 index_client = SearchIndexClient(endpoint=AZURE_SEARCH_SERVICE, credential=credential)  
 fields = [
     SearchField(name="document_id", type=SearchFieldDataType.String, key=True, sortable=True, filterable=True, facetable=True, analyzer_name="keyword"),  
     SearchField(name="parent_id", type=SearchFieldDataType.String, filterable=True),  
     SearchField(name="title", type=SearchFieldDataType.String, searchable=True, sortable=False, filterable=True, facetable=False, retrievable=True), 
     SearchField(name="chunk", type=SearchFieldDataType.String, sortable=False, filterable=False, facetable=False, retrievable=True),  
     SearchField(name="chunk_vector", type=SearchFieldDataType.Collection(SearchFieldDataType.Single, searchable=True, retrievable=False), vector_search_dimensions=1024, vector_search_profile_name="myHnswProfile")
     ]  

 # Configure the vector search configuration  
 vector_search = VectorSearch(  
     algorithms=[  
         HnswAlgorithmConfiguration(name="myHnsw"),
     ],  
     profiles=[  
         VectorSearchProfile(  
             name="myHnswProfile",  
             algorithm_configuration_name="myHnsw",  
             vectorizer_name="myOpenAI",  
         )
     ],  
     vectorizers=[  
         AzureOpenAIVectorizer(  
             vectorizer_name="myOpenAI",  
             kind="azureOpenAI",  
             parameters=AzureOpenAIVectorizerParameters(  
                 resource_url=AZURE_OPENAI_ACCOUNT,  
                 deployment_name="text-embedding-3-large",
                 model_name="text-embedding-3-large"
             ),
         ),  
     ], 
 )  

 # Create the search index
 index = SearchIndex(name=index_name, fields=fields, vector_search=vector_search)  
 result = index_client.create_or_update_index(index)  
 print(f"{result.name} created")  

Hinzufügen von Indexprojektionen zu einem Skillset

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

"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"
    }
}

index_projections = SearchIndexerIndexProjection(  
    selectors=[  
        SearchIndexerIndexProjectionSelector(  
            target_index_name=index_name,  
            parent_key_field_name="parent_id",  
            source_context="/document/pages/*",  
            mappings=[  
                InputFieldMappingEntry(name="chunk", source="/document/pages/*"),  
                InputFieldMappingEntry(name="chunk_vector", source="/document/pages/*/chunk_vector"),
                InputFieldMappingEntry(name="title", source="/document/title")
            ],  
        ),  
    ],  
    parameters=SearchIndexerIndexProjectionsParameters(  
        projection_mode=IndexProjectionMode.SKIP_INDEXING_PARENT_DOCUMENTS  
    ),  
) 

Parameterverweis

Parameter weisen die folgenden Elemente als Teil ihrer Definition auf.

Selektoren weisen die folgenden Elemente als Teil ihrer Definition auf.

Der mappings Parameter ist wichtig. Sie müssen jedes Feld im untergeordneten Index explizit zuordnen, mit Ausnahme der ID-Felder wie dem Dokumentschlüssel und der ID des übergeordneten Elements.

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 (z. B. verwenden BLOB-Indexer den eindeutigen Metadatenspeicherpfad als Standarddokumentschlüssel). Bei Indexer-Projektionen müssen Sie jedoch jede Feldzuordnung auf der n-Seite des Verhältnisses ausdrücklich angeben.

Überprüfen von Feldzuordnungen

Indexer sind mit drei verschiedenen Arten von Feldzuordnungen verbunden. Bevor Sie den Indexer ausführen, überprüfen Sie die Feldzuordnungen und stellen Sie sicher, dass Sie wissen, wann Sie jeden Typ verwenden sollten.

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 Diskrepanzen 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. Chunks gelten aufgrund ihrer Erstellung durch eine Funktion (Text Split) als angereicherter Inhalt, aber Sie benötigen keine Ausgabefeldzuordnung für Chunks oder für Indexprojektionen, die durch eine Selektorzuordnung definiert sind.

Selectors.mappings werden in einem Skillset definiert und Feldern im untergeordneten Index zugeordnet. In Fällen, in denen der untergeordnete Index auch übergeordnete Felder enthält (wie in der konsolidierten Indexlösung), sollten Sie Feldzuordnungen für jedes Feld einrichten, das Inhalte enthält, einschließlich des Titelfelds auf übergeordneter Ebene, vorausgesetzt, dass der Titel in jedem abschnittierten Dokument angezeigt werden soll. Wenn Sie separate übergeordnete und untergeordnete Indizes verwenden, sollte die Auswahl Feldzuordnungen für nur die Felder auf untergeordneter Ebene aufweisen.

Ausführen des Indexers

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

Sie können ihren 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öschungserkennung bereitstellen. In diesem Abschnitt wird der Inhaltslebenszyklus der 1:n-Indizierung im Zusammenhang mit der Datenaktualisierung erläutert.

Bei Datenquellen, die die Erkennung von Änderungen und Löschungen bereitstellen, kann ein Indexerprozess Änderungen in Ihren Quelldaten abrufen. Jedes Mal, wenn Sie den Indexer und das Skillset ausführen, 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 von Inhalten 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.

Aktualisierter Inhalt

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

Wenn Sie vorhandenen Inhalt in der Datenquelle ändern, werden Blöcke inkrementell im Suchindex aktualisiert, wenn die von Ihnen verwendete Datenquelle die Erkennung von Änderungen und Löschungen unterstützt. Wenn sich beispielsweise ein Wort oder ein Satz in einem Dokument ändert, wird der Block im Zielindex, der dieses Wort oder diesen Satz enthält, bei der nächsten Indizierungsausführung aktualisiert. Andere Aktualisierungstypen, z. B. das Ändern eines Feldtyps und einige Zuschreibungen, werden für vorhandene Felder nicht unterstützt. Weitere Informationen zu zulässigen Updates finden Sie unter Aktualisieren eines Indexschemas.

Einige Datenquellen wie Azure Storage unterstützen die Änderungs- und Löschnachverfolgung standardmäßig basierend auf dem Zeitstempel. Andere Datenquellen wie Microsoft 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 auf weniger Blöcke gekürzt wird), wird das entsprechende untergeordnete Dokument im Suchindex gelöscht. Die verbleibenden untergeordneten Dokumente erhalten auch ihren 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 dataDeletionDetectionPolicy definierte Definition der Datenquelle erkannt wird. Wenn Sie kein dataDeletionDetectionPolicy konfiguriert haben und ein übergeordnetes Dokument aus der Datenquelle löschen müssen, sollten Sie die untergeordneten Dokumente manuell löschen, falls 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 Datenimport-Assistenten verwenden, ist der projizierte Schlüsselwert das parent_id-Feld auf einer Chunked- oder "Many"-Seite des Index.

Ein projizierter Schlüsselwert ist ein eindeutiger Bezeichner, den der Indexer für jedes Dokument generiert. Sie stellt Eindeutigkeit sicher 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 Indizierungsläufen aktualisiert wird.
• Der Schlüssel des übergeordneten Dokuments.
• Der Anreicherungsanmerkungspfad, der den Kontext für das generierte Dokument identifiziert.

Wenn Sie z. B. ein übergeordnetes Dokument mit dem Schlüsselwert "aa1b22c33" in vier Seiten aufteilen und dann jede dieser Seiten über Indexprojektionen als eigenes Dokument projiziert wird:

• aa1b22c33
• aa1b22c33_pages_0
• aa1b22c33_pages_1
• aa1b22c33_pages_2

Wenn das übergeordnete Dokument in den Quelldaten aktualisiert wird, was möglicherweise zu mehr chunked Seiten führt, ändern sich die zufälligen Hashwerte, es werden weitere Seiten hinzugefügt, und der Inhalt der einzelnen Blöcke wird aktualisiert, um den Inhalt des Quelldokuments widerzuspiegeln.

Beispiel für separate Parent-Child-Indexe

Dieser Abschnitt zeigt ein Beispiel für separate übergeordnete und untergeordnete Indizes. Es ist ein ungewöhnliches Muster, aber es ist möglich, dass Sie anwendungsanforderungen haben, die mit diesem Ansatz am besten erfüllt sind. In diesem Szenario projizieren Sie Inhalte von übergeordneten und untergeordneten Elementen in zwei separate Indizes.

1. Erstellen Sie zwei Indexschemas.

   Jedes Schema enthält die Felder für seine spezifische Granularität, wobei das Feld für die ID des übergeordneten Elements von beiden Indizes in einer Lookup-Abfrage verwendet wird. Der primäre Suchkorpus ist der untergeordnete Index, aber Sie können eine Suchabfrage ausgeben, um die übergeordneten Felder für jede Übereinstimmung im Suchergebnis abzurufen. Azure KI-Suche unterstützt Verknüpfungen zur Abfragezeit nicht, sodass der Anwendungscode oder die Orchestrierungsebene Ergebnisse zusammenführen oder konsolidieren muss, die an eine Anwendung oder einen Prozess übergeben werden können.

   Der übergeordnete Index weist ein parent_id Feld und einen Titel auf. Die parent_id ist der Dokumentschlüssel. Sie benötigen keine Vektorsuchkonfiguration, es sei denn, Sie möchten Felder auf der übergeordneten Dokumentebene vektorisieren.

   {
       "name": "my-parent-index",
       "fields": [
   
           {"name": "parent_id", "type": "Edm.String", "key":true, "filterable": true},
           {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true}
       ]
   }
   

   Der untergeordnete Index enthält die segmentierten Felder sowie das Feld "parent_id". Wenn Sie integrierte Vektorisierung, Bewertungsprofile, semantische Sortierer oder Analysetools verwenden, legen Sie diese im untergeordneten Index fest.

   {
       "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": []
   }
   

2. Aktualisieren Sie den Indexer, um den Parent-Index als Ziel anzugeben.

   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 One-to-Many-Indizierung mit separaten Indizes kann die Indexer-Definition 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,
   }
   

3. Fügen Sie indexProjections dem Skillset hinzu.

   Hier ist ein Beispiel für eine Indexprojektiondefinition, die den Datenpfad angibt, den der Indexer zum Indizieren von Inhalten verwenden soll. Er gibt den Namen des untergeordneten Indexes in der Definition der Indexprojektion sowie die Zuordnungen jedes untergeordneten oder segmentbasierten Felds an. Der Name des untergeordneten Indexes wird nur an dieser Stelle angegeben.

   Beachten Sie, dass parameters null ist und die Standardeinstellung includeIndexingParentDocumentsverwendet wird. Der Indexer füllt den übergeordneten Index auf. Das selectors-Array wird verwendet, um die Blockdokumente in den untergeordneten Index zu projizieren.

   "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": []
                   }
               ]
           }
       ],
       "parameters": {}
   }
   

4. Führen Sie den Indexer aus. Wenn Sie zuvor den Indexer ausgeführt haben, denken Sie daran, ihn zuerst zurückzusetzen.

   Sie sollten zwei Indizes mit dem entsprechenden Inhalt aufgefüllt haben. Fragen Sie die Indizes im Such-Explorer ab, um sicherzustellen, dass jeder über den richtigen Inhalt verfügt.

Nächster Schritt

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