Indexprojektionen in Azure AI Search

  • Artikel

Wichtig

Indexprojektionen befinden sich in der öffentlichen Vorschau unter ergänzenden Nutzungsbedingungen. Sie sind über das Azure-Portal, 2023-10-01-Vorschauversion-REST-APIs, Azure-Portal und Beta-Clientbibliotheken verfügbar, die aktualisiert wurden, um das Feature einzuschließen.

Indexprojektionen sind eine Komponente einer Skillsetdefinition, welche die Form eines sekundären Indexes definiert und ein 1:n-Indexmuster unterstützt, bei dem Inhalte aus einer Anreicherungspipeline auf mehrere Indizes abzielen können.

Indexprojektionen nehmen KI-angereicherte Inhalte, die von einer Anreicherungspipeline generiert werden, und indizieren sie in einen sekundären Index (anders als der, auf den ein Indexer standardmäßig abzielt) in Ihrem Suchdienst. Indexprojektionen ermöglichen es Ihnen auch, die Daten vor der Indizierung neu zu gestalten. Auf eine Weise, mit der Sie ein Array von erweiterten Elementen in mehrere Suchdokumente im Zielindex trennen können,was auch als „1:n“-Indizierung bezeichnet wird. Die „1:n“-Indizierung eignet sich für Datenabschnittsszenarien, in denen Sie möglicherweise einen Primärindex für nicht unterteilte Inhalte und einen sekundären Index für unterteilte benötigen.

Wenn Sie in der Vergangenheit kognitive Skills verwendet haben, wissen Sie bereits, dass Skillsets angereicherte Inhalte erstellen. Skillsets unterziehen ein Dokument einer Abfolge von Anreicherungen, die atomische Transformationen auslösen, wie etwa das Erfassen von Entitäten oder das Übersetzen von Text. Standardmäßig wird ein Dokument, das in einem Skillset verarbeitet wird, einem einzelnen Dokument im Suchindex zugeordnet. Dies bedeutet, dass das Ergebnis beim Zuordnen über outputFieldMappings ein Array der generierten Anreicherungen ist, wenn Sie eine Aufteilung von Eingabetext durchführen und dann Anreicherungen für jeden Teil ausführen. Mit Indexprojektionen definieren Sie einen Kontext, in dem jeder Teil der erweiterten Daten einem eigenen Suchdokument zugeordnet werden soll. Auf diese Weise können Sie eine 1:n-Zuordnung der erweiterten Daten eines Dokuments auf den Suchindex anwenden.

Definition von Indexprojektionen

Indexprojektionen werden in einer Skillsetdefinition definiert und in erster Linie als Array von Selektoren definiert, wobei jeder Selektor einem anderen Zielindex im Suchdienst entspricht. Jeder Selektor erfordert die folgenden Parameter als Teil der Definition:

  • targetIndexName: Der Name des Indexes für den Suchdienst, in den der Indexprojektionsdatenindex aufgenommen wird.
  • parentKeyFieldName: Der Name des Felds im Zielindex, der den Wert des Schlüssels für das übergeordnete Dokument enthält.
  • 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. Mit diesen Parametern können Sie Shape-Daten in Felder des Typs Edm.ComplexType im Suchindex indiziert werden.

Der im targetIndexName-Parameter definierte Index hat die folgenden Anforderungen:

  • Muss bereits im Suchdienst erstellt worden sein, bevor das Skillset erstellt wurde, das die Definition der Indexprojektionen enthält.
  • Muss ein Feld mit dem im parentKeyFieldName-Parameter definierten Namen enthalten. Dieses Feld muss vom Typ Edm.String sein, darf nicht das Schlüsselfeld sein und filterbar muss auf „true“ eingestellt sein.
  • Das Schlüsselfeld muss durchsuchbar auf „true“ eingestellt haben und mit dem keyword-Analyzer definiert werden.
  • Muss für jeden der in mappings definierten name Felder definiert haben, von denen keines das Schlüsselfeld sein darf.

Hier ist eine Beispielnutzlast für eine Indexprojektionsdefinition, mit der Sie einzelne Seiten projizieren können, die von dem Split-Skill als eigene Dokumente im Suchindex ausgegeben werden.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "myTargetIndex",
            "parentKeyFieldName": "ParentKey",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*"
                }
            ]
        }
    ]
}

Behandeln übergeordneter Dokumente

Da Indexprojektionen effektiv „untergeordnete“ Dokumente für jedes „übergeordnete“ Dokument, das über ein Skillset ausgeführt wird, generieren, haben Sie auch die folgenden Möglichkeiten, wie die Indizierung der „übergeordneten“ Dokumente behandelt werden soll.

  • Um übergeordnete und untergeordnete Dokumente in separaten Indizes beizubehalten, stellen Sie einfach sicher, dass sich targetIndexName für Ihre Indexerdefinition vom in der Indexprojektion definierten targetIndexName unterscheidet.

  • Um übergeordnete und untergeordnete Dokumente in denselben Index zu indizieren, müssen Sie sicherstellen, dass das Schema für den Zielindex sowohl mit Ihrer definierten fieldMappings als auch outputFieldMappings in Ihrer Indexerdefinition und mappings in Ihrer Indexprojektionsauswahl funktioniert. Sie würden dann nur die gleiche targetIndexName für Ihre Indexerdefinition und den Indexprojektionsmarkierer bereitstellen.

  • Um übergeordnete Dokumente und nur untergeordnete Indexdokumente zu ignorieren, müssen Sie trotzdem eine targetIndexName in Ihrer Indizierungsdefinition angeben (Sie können einfach die gleiche angeben, die Sie für die Indexprojektionsauswahl benutzen). Definieren Sie dann ein separates parameters-Objekt neben ihrer selectors-Definition mit einem projectionMode-Schlüsselsatz auf skipIndexingParentDocumentseingestellt, wie hier gezeigt:

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

Rest-API-Version 2023-10-01-Preview kann verwendet werden, um Indexprojektionen durch Ergänzungen zu einem Skillset zu erstellen.

Inhaltslebenszyklus

Wenn die Indexerdatenquelle die Erkennung von Änderungen zur Nachverfolgung und Löschung unterstützt, kann der Indizierungsprozess die primären und sekundären Indizes synchronisieren, um diese Änderungen aufzunehmen.

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.

Hinweis

Während Sie die Daten in den projizierten Dokumenten mithilfe der Index-Push-APImanuell bearbeiten können, werden alle Bearbeitungen im nächsten Pipelineaufruf überschrieben, vorausgesetzt, das Dokument in den Quelldaten wird aktualisiert.

Projizierter Schlüsselwert

Jedes Indexprojektionsdokument enthält einen eindeutigen Identifikationsschlüssel, den der Indexer generiert, um die Eindeutigkeit sicherzustellen und die ordnungsgemäße Funktionsweise der Änderungs- und Löschnachverfolgung zu ermöglichen. 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 über den Indexer hinweg aktualisiert wird.
  • Der Schlüssel des übergeordneten Dokuments.
  • Der Anreicherungsanmerkungspfad, der den Kontext identifiziert, aus dem das Dokument generiert wurde.

Wenn Sie beispielsweise ein übergeordnetes Dokument mit dem Schlüsselwert „123“ in vier Seiten aufteilen und dann jede dieser Seiten als eigenes Dokument über Indexprojektionen projiziert wird, würde der Schlüssel für die dritte Seite des Texts etwa wie folgt aussehen: „01f07abfe7ed_123_pages_2“. Wenn das übergeordnete Dokument dann aktualisiert wird, um eine fünfte Seite hinzuzufügen, kann der neue Schlüssel für die dritte Seite z. B. „9d800bdacc0e_123_pages_2“ lauten, da sich der zufällige Hashwert bei Indexeraktualiserungen ändert, auch wenn sich der Rest der Projektionsdaten nicht geändert hat.

Änderungen oder Ergänzungen

Wenn ein übergeordnetes Dokument so geändert wird, dass sich die Daten in einem projizierten Indexdokument ändern (ein Beispiel wäre, wenn ein Wort auf einer bestimmten Seite, aber keine neue Seite hinzugefügt wurde), werden die Daten im Zielindex für diese bestimmte Projektion aktualisiert, um diese Änderung widerzuspiegeln.

Wenn ein übergeordnetes Dokument so geändert wird, dass es neue projizierte untergeordnete Dokumente gibt, die noch nicht vorhanden waren (ein Beispiel wäre, wenn dem Dokument mindestens eine ganze Seite Text hinzugefügt wurde), werden diese neuen untergeordneten Dokumente beim nächsten Ausführen des Indexers hinzugefügt.

In beiden Fällen werden alle projizierten Dokumente aktualisiert, um einen neuen Hashwert in ihrem Schlüssel zu haben, unabhängig davon, ob der jeweilige Inhalt aktualisiert wurde.

Löschungen

Wenn ein übergeordnetes Dokument so geändert wird, dass ein untergeordnetes Dokument, das durch Indexprojektionen generiert wurde, nicht mehr vorhanden ist (ein Beispiel wäre, wenn ein Text gekürzt wird, sodass weniger Blöcke als zuvor vorhanden sind), 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.