Projections d’index dans Recherche Azure AI

Article
11/15/2023

Important

Les projections d’index sont en préversion publique et soumises à des conditions d'utilisation supplémentaires. Elles sont disponibles via le portail Microsoft Azure, l’API REST 2023-10-01-Preview, le portail Microsoft Azure et les bibliothèques clientes bêta qui ont été mises à jour pour inclure la fonctionnalité.

Les projections d’index sont un composant d’une définition d’ensemble de compétences qui définit la forme d’un index secondaire, prenant en charge un modèle d’index un-à-plusieurs, où le contenu d’un pipeline d’enrichissement peut cibler plusieurs index.

Les projections d’index prennent le contenu enrichi par l’IA généré par un pipeline d’enrichissement et l’indexent dans un index secondaire (différent de celui qu’un indexeur cible par défaut) sur votre service de recherche. Les projections d’index vous permettent également de remodeler les données avant de les indexer, de manière unique, ce qui vous permet de séparer un tableau d’éléments enrichis en plusieurs documents de recherche dans l’index cible, sinon appelé indexation « un-à-plusieurs ». L’indexation « un-à-plusieurs » est utile pour les scénarios de segmentation de données, où vous souhaiterez peut-être un index principal pour le contenu non segmenté et un index secondaire pour le contenu segmenté.

Si vous avez utilisé des compétences cognitives dans le passé, vous savez déjà que les ensembles de compétences crée du contenu enrichi. Les ensembles de compétences font passer un document à travers une séquence d’enrichissements qui appellent des transformations atomiques, comme la reconnaissance d’entités ou la traduction de texte. Par défaut, un document traité dans un ensemble de compétences est mappé à un seul document dans l’index de recherche. Cela signifie que si vous effectuez une segmentation d’un texte d’entrée, puis effectuez des enrichissements sur chaque bloc, le résultat de l’index lorsqu’il est mappé via outputFieldMappings est un tableau des enrichissements générés. Avec les projections d’index, vous définissez un contexte auquel mapper chaque segment de données enrichies à son propre document de recherche. Cela vous permet d’appliquer un mappage un-à-plusieurs des données enrichies d’un document à l’index de recherche.

Définition des projections d’index

Les projections d’index sont définies à l’intérieur d’une définition d’ensemble de compétences et sont principalement définies en tant que tableau de sélecteurs, où chaque sélecteur correspond à un index cible différent sur le service de recherche. Chaque sélecteur requiert les paramètres suivants dans le cadre de sa définition :

targetIndexName : nom de l’index sur le service de recherche dans lequel les données de projection d’index sont indexées.
parentKeyFieldName : nom du champ dans l’index cible qui contient la valeur de la clé pour le document parent.
sourceContext : annotation d’enrichissement qui définit la granularité à laquelle mapper des données dans des documents de recherche individuels. Pour plus d’informations, consultez Langage d’annotation du contexte et des entrées de compétences.
mappings : tableau de mappages de données enrichies aux champs de l’index de recherche. Chaque mappage se compose des éléments suivants :
- name : nom du champ dans l’index de recherche dans lequel les données doivent être indexées.
- source : chemin d’annotation d’enrichissement à partir duquel les données doivent être extraites.

Chaque mapping peut également définir de manière récursive des données avec un champ facultatif sourceContext et inputs, similaire à la base de connaissances ou à la compétence Shaper. Ces paramètres vous permettent de mettre en forme les données à indexer dans des champs de type Edm.ComplexType dans l’index de recherche.

L’index défini dans le paramètre targetIndexName dispose des exigences suivantes :

Doit déjà avoir été créé sur le service de recherche avant la création de l’ensemble de compétences contenant la définition des projections d’index.
Doit contenir un champ portant le nom défini dans le paramètre parentKeyFieldName. Ce champ doit être de type Edm.String, il ne peut pas être le champ clé et il doit avoir la valeur « Filtrable » définie sur « true ».
Le champ clé doit avoir la valeur « Possibilité de recherche » définie sur « true » et être défini avec l’analyseur keyword.
Doit avoir des champs définis pour chacun des name définis dans mappings, dont aucun ne peut être le champ clé.

Voici un exemple de charge utile pour une définition de projection d’index que vous pouvez utiliser pour projeter une sortie de pages individuelles par la compétence Fractionner en tant que documents propres dans l’index de recherche.

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

Gestion des documents parents

Étant donné que les projections d’index génèrent efficacement des documents « enfants » pour chaque document « parent » qui s’exécute via un ensemble de compétences, vous avez également les choix suivants pour gérer l’indexation des documents « parents ».

Pour conserver les documents parents et enfants dans des index distincts, vous devez simplement vous assurer que la targetIndexName de votre définition d’indexeur est différente de la targetIndexName définie dans votre sélecteur de projection d’index.
Pour indexer les documents parents et enfants dans le même index, vous devez vous assurer que le schéma de l’index cible fonctionne avec vos fieldMappings et vos outputFieldMappings définis dans votre définition d’indexeur et les mappings dans votre sélecteur de projection d’index. Vous devez ensuite simplement fournir la même targetIndexName pour votre définition d’indexeur et votre sélecteur de projection d’index.
Pour ignorer les documents parents et indexer uniquement les documents enfants, vous devez tout de même fournir une targetIndexName dans votre définition d’indexeur (vous pouvez simplement fournir la même que celle pour le sélecteur de projection d’index). Définissez ensuite un objet parameters distinct en regard de votre définition de selectors avec une clé projectionMode définie sur skipIndexingParentDocuments, comme illustré ici :
```
"indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}
```

REST
.NET

Vous pouvez utiliser la version 2023-10-01-Preview de l’API REST pour créer des projections d’index via des ajouts à un ensemble de compétences.

Cycle de vie du contenu

Si la source de données de l’indexeur prend en charge le suivi des modifications et la détection de suppression, le processus d’indexation peut synchroniser les index principaux et secondaires pour récupérer ces modifications.

Chaque fois que vous exécutez l’indexeur et l’ensemble de compétences, les projections d’index mises à jour si l’ensemble de compétences ou les données sources sous-jacentes ont changé. Les changements détectés par l’indexeur sont propagés via le processus d’enrichissement aux projections d’index, ce qui permet de garantir que les données projetées sont une représentation actualisée du contenu de la source de données d’origine.

Remarque

Bien que vous puissiez modifier manuellement les données dans les documents projetés à l’aide de l’API Push d’index, les mises à jour sont remplacées au prochain appel du pipeline, en supposant que le document présent dans les données sources soit mis à jour.

Valeur de clé projetée

Chaque document de projection d’index contient une clé d’identification unique générée par l’indexeur afin de garantir l’unicité et d’autoriser le suivi des modifications et des suppressions à fonctionner correctement. Cette clé contient les segments suivants :

Hachage aléatoire pour garantir l’unicité. Ce hachage change si le document parent est mis à jour entre les exécutions de l’indexeur.
Clé du document parent.
Chemin d’annotation d’enrichissement qui identifie le contexte à partir duquel ce document a été généré.

Par exemple, si vous fractionnez un document parent avec la valeur clé « 123 » en quatre pages, puis que chacune de ces pages est projetée comme son propre document via des projections d’index, la clé de la troisième page de texte ressemble à « 01f07abfe7ed_123_pages_2 ». Si le document parent est ensuite mis à jour pour ajouter une cinquième page, la nouvelle clé de la troisième page peut, par exemple, être « 9d800bdacc0e_123_pages_2 », car la valeur de hachage aléatoire change entre les exécutions de l’indexeur même si le reste des données de projection n’a pas changé.

Modifications ou ajouts

Si un document parent est modifié de telle sorte que les données d’un document d’index projeté changent (par exemple, si un mot a été modifié dans une page particulière, mais qu’aucune nouvelle page nette n’a été ajoutée), les données de l’index cible pour cette projection particulière sont mises à jour pour refléter cette modification.

Si un document parent est modifié de sorte qu’il existe de nouveaux documents enfants projetés qui n’étaient pas présents avant (par exemple, si une ou plusieurs pages de texte ont été ajoutées au document), ces nouveaux documents enfants sont ajoutés la prochaine fois que l’indexeur s’exécute.

Dans ces deux cas, tous les documents projetés sont mis à jour pour avoir une nouvelle valeur de hachage dans leur clé, indépendamment de la mise à jour de leur contenu particulier.

Suppressions

Si un document parent est modifié de telle sorte qu’un document enfant généré par des projections d’index n’existe plus (par exemple, si un texte est raccourci afin qu’il y ait moins de blocs que précédemment), le document enfant correspondant dans l’index de recherche est supprimé. La clé des documents enfants restants est également mise à jour pour inclure une nouvelle valeur de hachage, même si leur contenu n’a pas changé autrement.

Si un document parent est complètement supprimé de la source de données, les documents enfants correspondants sont supprimés uniquement si la suppression est détectée par un dataDeletionDetectionPolicy défini sur la définition de source de données. Si vous n’avez pas configuré de dataDeletionDetectionPolicy et que vous devez supprimer un document parent de la source de données, vous devez supprimer manuellement les documents enfants s’ils ne sont plus souhaités.

Partage via