Définir une projection d’index pour l’indexation parent-enfant

Si vous segmentez du contenu pour un modèle RAG ou une vectorisation, vous pouvez spécifier une projection d’index pour contrôler l’indexation un-à-plusieurs, où le contenu source (un) est projeté sur un ou plusieurs index (plusieurs). L’intention d’une projection d’index est de contrôler si les éléments du document parent, tels qu’un nom de fichier ou une date de création :

• Répéter pour chaque enfant (segment) dans un index unique
• Sont indexés en tant que documents de recherche autonomes dans le même index
• Ou sont ingérés dans des index distincts

Nous vous recommandons de répéter des champs parents dans un seul index, car le fait d’avoir des formes de document différentes ou de fractionner du contenu en deux index peut être difficile à interroger, en particulier dans la recherche classique où les jointures d’index ne sont pas prises en charge.

Dans Recherche Azure AI, la segmentation est effectuée par les compétences et dépend donc des indexeurs. Pour définir une projection d’index, spécifiez-la dans un ensemble de compétences.

Conditions préalables

• Recherche Azure AI, n’importe quel niveau ou région.

• Pipeline d’indexation basé sur un indexeur.

• Une source de données prise en charge ayant du contenu que vous souhaitez segmenter.

• Un index (un ou plusieurs) qui accepte la sortie du pipeline d’indexeur.

• Compétence qui segmente le contenu, telle que la compétence Fractionner du texte.

L'ensemble de compétences techniques contient la projection de l'indexeur qui façonne les données pour une indexation multiple. Un ensemble de compétences peut également avoir d’autres compétences, telles qu’une compétence d’incorporation comme AzureOpenAIEmbedding si votre scénario inclut la vectorisation intégrée.

Choisir une approche

Les projections d’index génèrent des documents « enfants » (segments) pour chaque document « parent ». Choisissez comment gérer le contenu parent :

Pour la plupart des scénarios RAG, utilisez la première approche. Consultez l’exemple classic RAG.

Étapes d’implémentation pour l’approche recommandée

1. Créez un index conçu pour les blocs, avec les champs parents inclus.
2. Créez un ensemble de compétences avec une compétence de segmentation et indexProjections.
3. Créez un indexeur pointant vers votre source de données prise en charge.

Si votre source de données prend en charge le suivi des modifications, l’indexeur synchronise automatiquement les modifications.

Créer un index pour l’indexation un-à-plusieurs

Que vous créez un index pour les blocs qui répètent des valeurs parentes ou des index distincts pour le placement de champs parent-enfant, l’index principal utilisé pour la recherche est conçu autour des blocs de données. Le schéma d’index doit avoir les champs suivants :

• Champ clé de document identifiant de manière unique chaque document. Elle doit être définie comme type Edm.String avec l’analyseur keyword .

• Champ associant chaque bloc à son parent. Il doit être de type Edm.String. Il ne peut pas s’agir du champ clé du document et doit avoir filterable la valeur true. Il est appelé parent_id dans les exemples et comme valeur de clé projetée dans cet article.

• Autres champs pour le contenu, tels que le texte ou les champs de bloc vectorisés.

Un index doit exister sur le service de recherche avant de créer l’ensemble de compétences ou d’exécuter l’indexeur. L’ensemble selectors de compétences que vous définissez doit inclure ces champs.

Schéma d’index unique inclus des champs parent et enfant

Un index unique conçu autour de blocs avec le contenu parent répétitif pour chaque bloc est le modèle prédominant pour les scénarios de recherche rag et vectoriel. La possibilité d’associer le contenu parent approprié à chaque bloc est activée par le biais de projections d’index.

Le schéma suivant est un exemple qui répond aux exigences des projections d’index. Dans cet exemple :

• Les champs parents sont les parent_id et le titre, et ils se répètent pour chaque bloc
• Les champs enfants comprennent les segments vectoriels et les segments non vectoriels. Le chunk_id est l’ID de document de cet index.

Vous pouvez utiliser le portail Azure, les API REST ou un Kit de développement logiciel (SDK) Azure pour créer un index.

{
    "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")  

Ajouter des projections d’index à un ensemble de compétences

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 selectors, où chaque sélecteur correspond à un index cible différent sur le service de recherche. Cette section commence par la syntaxe et les exemples de contexte, suivis de la référence de paramètre.

"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  
    ),  
) 

Informations de référence sur les paramètres

Les paramètres ont les éléments suivants dans le cadre de leur définition.

Les sélecteurs ont les éléments suivants dans le cadre de leur définition.

Le mappings paramètre est important. Vous devez mapper explicitement chaque champ dans l’index enfant, à l’exception des champs d’ID tels que la clé de document et l’ID parent.

Cette exigence diffère des autres conventions de mappage de champs dans Recherche Azure AI. Pour certains types de sources de données, l’indexeur peut mapper implicitement des champs basés sur des noms similaires ou des caractéristiques connues (par exemple, les indexeurs d’objets blob utilisent le chemin de stockage de métadonnées unique comme clé de document par défaut). Toutefois, pour les projections d’indexeur, vous devez spécifier explicitement chaque mappage de champ du côté « plusieurs » de la relation.

Passer en revue les mappages de champs

Les indexeurs sont affiliés à trois types différents de mappages de champs. Avant d’exécuter l’indexeur, vérifiez vos mappages de champs et savez quand utiliser chaque type.

Les mappages de champs sont définis dans un indexeur et utilisés pour mapper un champ source à un champ d’index. Les mappages de champs sont utilisés pour les chemins de données qui extraient les données de la source et les transmettent pour l'indexation, sans aucune étape de traitement intermédiaire. En règle générale, un indexeur peut mapper automatiquement des champs portant le même nom et le même type. Les mappages de champs explicites ne sont requis que lorsqu’il y a des différences. Dans l’indexation un-à-plusieurs et les modèles abordés jusqu’à présent, vous n’avez peut-être pas besoin de mappages de champs.

Les mappages de champs de sortie sont définis dans un indexeur et utilisés pour mapper le contenu enrichi généré par un ensemble de compétences à un champ dans l’index principal. Les segments sont considérés comme du contenu enrichi grâce à la création par une compétence (fractionnement de texte), mais vous n’avez pas besoin de définir un mappage de champ de sortie pour les segments, ni pour les projections d’index définies par un mappage de sélecteur.

Les selectors.mappings sont définis dans un ensemble de compétences et mappés aux champs de l’index enfant. Dans les cas où l’index enfant inclut également des champs parents (comme dans la solution d’index consolidé), vous devez configurer des mappages de champs pour chaque champ qui a du contenu, y compris le champ de titre de niveau parent, en supposant que vous souhaitez que le titre s’affiche dans chaque document segmenté. Si vous utilisez des index parents et enfants distincts, le sélecteur doit avoir des mappages de champs uniquement pour les champs au niveau enfant.

Exécuter l’indexeur

Une fois que vous avez créé une source de données, des index et un ensemble de compétences, vous êtes prêt à créer et exécuter l’indexeur. Cette étape déclenche l'exécution du pipeline.

Vous pouvez interroger votre index de recherche après le traitement pour tester votre solution.

Cycle de vie du contenu

Selon la source de données sous-jacente, un indexeur peut généralement fournir un suivi des modifications et une détection de suppression en cours. Cette section explique le cycle de vie du contenu de l’indexation un-à-plusieurs en relation avec l’actualisation des données.

Pour les sources de données qui fournissent le suivi des modifications et la détection de suppression, un processus d’indexeur peut récupérer des modifications dans vos données sources. Chaque fois que vous exécutez l’indexeur et l’ensemble de compétences, les projections d’index sont mises à jour si l’ensemble de compétences ou les données sources sous-jacentes ont changé. Toutes les modifications récupérées par l’indexeur sont propagées par le processus d’enrichissement aux projections de l’index, ce qui garantit que vos données projetées sont une représentation actuelle du contenu dans la source de données d’origine. L’activité d’actualisation des données est capturée dans une valeur de clé projetée pour chaque bloc. Cette valeur est mise à jour lorsque les données sous-jacentes changent.

Contenu mis à jour

Si vous ajoutez du nouveau contenu à votre source de données, de nouveaux blocs ou documents enfants sont ajoutés à l’index lors de l’exécution suivante de l’indexeur.

Si vous modifiez du contenu existant dans la source de données, les blocs sont mis à jour de manière incrémentielle dans l’index de recherche si la source de données que vous utilisez prend en charge le suivi des modifications et la détection de suppression. Par exemple, si un mot ou une phrase change dans un document, le bloc dans l’index cible qui contient ce mot ou phrase est mis à jour lors de l’exécution de l’indexeur suivant. D’autres types de mises à jour, tels que la modification d’un type de champ et certaines attributions, ne sont pas pris en charge pour les champs existants. Pour plus d’informations sur les mises à jour autorisées, consultez Mettre à jour un schéma d’index.

Certaines sources de données telles que stockage Azure prennent en charge le suivi des modifications et des suppressions par défaut, en fonction de l’horodatage. D’autres sources de données telles que Microsoft OneLake, Azure SQL ou Azure Cosmos DB doivent être configurées pour le suivi des modifications.

Contenu supprimé

Si le contenu source n’existe plus (par exemple, si le texte est raccourci pour avoir moins de blocs), le document enfant correspondant dans l’index de recherche est supprimé. Les documents enfants restants obtiennent également leur clé mise à jour pour inclure une nouvelle valeur de hachage, même si leur contenu n’a pas changé par ailleurs.

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 une dataDeletionDetectionPolicy définition définie sur la définition de source de données. Si vous n’avez pas configuré 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.

Valeur de clé projetée

Pour garantir l’intégrité des données pour le contenu mis à jour et supprimé, l’actualisation des données dans l’indexation un-à-plusieurs s’appuie sur une valeur de clé projetée côté « plusieurs ». Si vous utilisez la vectorisation intégrée ou l’Assistant Importation de données, la valeur de clé projetée est le parent_id champ d’un côté segmenté ou « plusieurs » de l’index.

Une valeur de clé projetée est un identificateur unique généré par l’indexeur pour chaque document. Il garantit l’unicité et permet le suivi des modifications et des suppressions pour 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 lors des exécutions ultérieures de l’indexeur.
• Clé du document parent.
• Chemin d’annotation d’enrichissement qui identifie le contexte du document généré.

Par exemple, si vous fractionnez un document parent avec la valeur clé « aa1b22c33 » en quatre pages, puis chacune de ces pages est projetée comme son propre document via des projections d’index :

• aa1b22c33
• aa1b22c33_pages_0
• aa1b22c33_pages_1
• aa1b22c33_pages_2

Si le document parent est mis à jour dans les données sources, ce qui peut entraîner des pages plus segmentées, les modifications de hachage aléatoires, d’autres pages sont ajoutées et le contenu de chaque bloc est mis à jour pour correspondre à ce qui se trouve dans le document source.

Exemple d’index parent-enfant distincts

Cette section présente un exemple pour les index parents et enfants distincts. Il s’agit d’un modèle rare, mais il est possible que vous ayez des exigences d’application qui sont les mieux remplies à l’aide de cette approche. Dans ce scénario, vous projetez du contenu parent-enfant en deux index distincts.

1. Créez deux schémas d’index.

   Chaque schéma possède les champs de son grain particulier, avec le champ ID parent commun aux deux index à utiliser dans une requête de recherche. Le corpus de recherche principal est l’index enfant, mais vous pouvez émettre une requête de recherche pour récupérer les champs parents pour chaque correspondance dans le résultat. Recherche Azure AI ne prend pas en charge les jointures au moment de la requête. Votre code d'application ou couche d'orchestration doit donc fusionner ou rassembler les résultats qui peuvent être passés à une application ou à un processus.

   L’index parent a un champ et un titre parent_id. La parent_id est la clé de document. Vous n’avez pas besoin de configuration de recherche vectorielle, sauf si vous souhaitez vectoriser des champs au niveau du document parent.

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

   L’index enfant a les champs segmentés, ainsi que le champ parent_id. Si vous utilisez des vectorisations intégrées, des profils de scoring, un ranker sémantique ou des analyseurs, vous devez les définir dans l’index enfant.

   {
       "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. Mettez à jour l’indexeur pour spécifier l’indexeur parent comme cible.

   La définition de l’indexeur spécifie les composants du pipeline. Dans la définition de l’indexeur, le nom de l’index à fournir est l’index parent. Si vous avez besoin de mappages de champs pour les champs de niveau parent, définissez-les dans outputFieldMappings. Pour l’indexation un-à-plusieurs qui utilise des index distincts, la définition de l’indexeur peut ressembler à l’exemple suivant.

   {
     "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. Ajouter indexProjections à l’ensemble de compétences.

   Voici un exemple de définition de projection d’index qui spécifie le chemin d’accès aux données que l’indexeur doit utiliser pour indexer le contenu. Il spécifie le nom d’index enfant dans la définition de projection d’index et spécifie les mappages de chaque champ enfant ou de niveau segment. C'est le seul endroit où le nom de l'index enfant est spécifié.

   Notez que parameters est nul et utilise la valeur par défaut includeIndexingParentDocuments. L’indexeur remplit l’index parent. Le tableau selectors permet de projeter les documents de segments vers l’index enfant.

   "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. Exécutez l’indexeur. Si vous avez déjà exécuté l’indexeur, n’oubliez pas de le réinitialiser en premier.

   Vous devez avoir deux index renseignés avec le contenu approprié. Interrogez les index dans l’Explorateur de recherche pour vérifier que chacun possède le contenu approprié.

Étape suivante

La segmentation des données et l’indexation un-à-plusieurs font partie du modèle RAG classique dans Recherche Azure AI. Passez au tutoriel suivant et à l’exemple de code pour en savoir plus.