Definiera en indexprojektion för överordnad-underordnad indexering

Om du segmenterar innehåll för antingen ett RAG-mönster eller en vektorisering kan du ange en indexprojektion för att styra en-till-många-indexering, där källinnehåll (ett) projiceras till ett eller flera index (många). Avsikten med en indexprojektion är att kontrollera om element i huvuddokumentet, till exempel ett filnamn eller skapandedatum 존재:

• Upprepa för varje del (segment) inom ett enda index
• Indexeras som fristående sökdokument i samma index
• Eller ingår i separata indexer

Vi rekommenderar att du upprepar överordnade fält i ett enda index eftersom det kan vara svårt att ha olika dokumentformer eller dela upp innehåll i två index, särskilt i klassisk sökning där indexkopplingar inte stöds.

I Azure AI-sökning utförs segmentering av färdigheter och är därför beroende av indexerare. Om du vill definiera en indexprojektion anger du den i en kompetensuppsättning.

Förutsättningar

• Azure AI-sökning, vilken nivå eller region som helst.

• En indexerarbaserad indexeringspipeline.

• En stödd datakälla med innehåll som du vill dela upp i delar.

• Ett index (ett eller flera) som accepterar utdata från indexerarens pipeline.

• En färdighet som delar upp innehåll, till exempel färdigheten Textdelning.

Färdighetsuppsättningen innehåller indexerprojektionen som formar data för en-till-många-indexering. En kompetensuppsättning kan också ha andra färdigheter, till exempel en inbäddningsfärdighet som AzureOpenAIEmbedding om ditt scenario innehåller integrerad vektorisering.

Välj en metod

Indexprojektioner genererar "barn"-dokument (segment) för varje "förälder"-dokument. Välj hur du ska hantera överordnat innehåll:

I de flesta RAG-scenarier använder du den första metoden. Se det klassiska RAG-exemplet.

Implementeringssteg för den rekommenderade metoden

1. Skapa ett index som är utformat för segment, med överordnade fält inkluderade.
2. Skapa en kompetensuppsättning med en segmenteringsfärdighet och indexProjections.
3. Skapa en indexerare som pekar på din datakälla som stöds.

Om datakällan stöder ändringsspårning synkroniserar indexeraren ändringarna automatiskt.

Skapa ett index för en-till-många-indexering

Oavsett om du skapar ett index för segment som upprepar överordnade värden eller separata index för överordnad-underordnad fältplacering, är det primära index som används för sökning utformat kring datasegment. Indexschemat måste ha följande fält:

• Ett dokumentnyckelfält som unikt identifierar varje dokument. Den måste definieras som typ Edm.String med analysatorn keyword .

• Ett fält som associerar varje segment med dess överordnade segment. Den måste vara av typen Edm.String. Det kan inte vara dokumentets nyckelfält och måste ha filterable angetts till sant. Det kallas parent_id i exemplen och som ett beräknat nyckelvärde i den här artikeln.

• Andra fält för innehåll, till exempel text eller vektoriserade segmentfält.

Det måste finnas ett index i söktjänsten innan du skapar kunskapsuppsättningen eller kör indexeraren. Den selectors du definierar i kunskapsuppsättningen bör innehålla dessa fält.

Ett indexschema inklusive föräldra- och barnfält

Ett enda index som är utformat runt segment med överordnat innehåll som upprepas för varje segment är det dominerande mönstret för RAG- och vektorsökningsscenarier. Möjligheten att associera rätt överordnat innehåll med varje segment aktiveras via indexprojektioner.

Följande schema är ett exempel som uppfyller kraven för indexprognoser. I det här exemplet:

• Överordnade fält är parent_id och rubriken, och de upprepas för varje segment
• Underordnade fält är vektor- och icke-vektorsegmenten. Chunk_id är dokument-ID:t för det här indexet.

Du kan använda Azure-portalen, REST-API:er eller en Azure SDKs för att skapa ett 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")  

Lägga till indexprojektioner i en kompetensuppsättning

Indexprojektioner definieras i en kompetensuppsättningsdefinition och definieras främst som en matris med selectors, där varje väljare motsvarar ett annat målindex i söktjänsten. Det här avsnittet börjar med syntax och exempel för kontext, följt av parameterreferens.

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

Parameterreferens

Parametrarna har följande element som en del av definitionen.

Väljare har följande element som en del av definitionen.

Parametern mappings är viktig. Du måste uttryckligen mappa alla fält i delindexet, förutom ID-fälten, till exempel dokumentnyckeln och det överordnade ID:t.

Det här kravet står i kontrast till andra fältmappningskonventioner i Azure AI-sökning. För vissa typer av datakällor kan indexeraren implicit mappa fält baserat på liknande namn eller kända egenskaper (till exempel använder blobindexerare den unika lagringssökvägen för metadata som standarddokumentnyckel). För indexerareprojektioner måste du dock uttryckligen ange varje fältmappning på "många"-sidan av relationen.

Granska fältmappningar

Indexerare är kopplade till tre olika typer av fältmappningar. Innan du kör indexeraren kontrollerar du fältmappningarna och vet när du ska använda varje typ.

Fältmappningar definieras i en indexerare och används för att mappa ett källfält till ett indexfält. Fältmappningar används för datasökvägar som lyfter data från källan och skickar in dem för indexering, utan mellanliggande kompetensbearbetningssteg. Vanligtvis kan en indexerare automatiskt mappa fält som har samma namn och typ. Explicita fältmappningar krävs bara när det finns avvikelser. I en-till-många-indexering och de mönster som diskuterats hittills kanske du inte behöver fältmappningar.

Mappningar av utdatafält definieras i en indexerare och används för att mappa berikat innehåll som genereras av en kompetensuppsättning till ett fält till huvudindexet. Segment anses vara berikat innehåll på grund av skapande av en färdighet (textdelning), men du behöver inte en utdatafältmappning för segment eller för indexprojektioner som definieras av en väljaremappning.

Selectors.mappings definieras i en kompetensuppsättning och mappas till fält i det underordnade indexet. Om det underordnade indexet även innehåller överordnade fält (som i den konsoliderade indexlösningen) bör du konfigurera fältmappningar för varje fält som har innehåll, inklusive rubrikfältet på överordnad nivå, förutsatt att du vill att rubriken ska visas i varje segmenterat dokument. Om du använder separata förälder- och barnindex bör väljverktyget ha fältmappningar för endast de fält på barnnivå.

Kör indexeraren

När du har skapat en datakälla, index och kompetensuppsättning är du redo att skapa och köra indexeraren. Det här steget sätter igång pipelinen.

Du kan köra frågor mot ditt sökindex när bearbetningen har slutförts för att testa lösningen.

Innehållslivscykel

Beroende på den underliggande datakällan kan en indexerare vanligtvis tillhandahålla löpande spårning av ändringar och upptäckt av borttagningar. I det här avsnittet beskrivs innehållslivscykeln för en-till-många-indexering när det gäller datauppdatering.

För datakällor som tillhandahåller ändringsspårning och borttagningsdetektering kan en indexeringsprocess hämta ändringar i dina källdata. Varje gång du kör indexeraren och kunskapsuppsättningen uppdateras indexprognoserna om kunskapsuppsättningen eller underliggande källdata har ändrats. Alla ändringar som hämtas av indexeraren sprids genom berikningsprocessen till projektionerna i indexet, vilket säkerställer att dina beräknade data är en aktuell representation av innehåll i den ursprungliga datakällan. Datauppdateringsaktiviteten samlas in i ett beräknat nyckelvärde för varje segment. Det här värdet uppdateras när underliggande data ändras.

Uppdaterat innehåll

Om du lägger till nytt innehåll i datakällan läggs nya segment eller underordnade dokument till i indexet vid nästa indexeringskörning.

Om du ändrar befintligt innehåll i datakällan uppdateras segment stegvis i sökindexet om datakällan som du använder stöder identifiering av ändringsspårning och borttagning. Om till exempel ett ord eller en mening ändras i ett dokument uppdateras segmentet i målindexet som innehåller ordet eller meningen vid nästa indexeringskörning. Andra typer av uppdateringar, till exempel att ändra en fälttyp och vissa attribut, stöds inte för befintliga fält. Mer information om tillåtna uppdateringar finns i Uppdatera ett indexschema.

Vissa datakällor som Azure Storage stöder ändrings- och borttagningsspårning som standard, baserat på tidsstämpeln. Andra datakällor som Microsoft OneLake, Azure SQL eller Azure Cosmos DB måste konfigureras för ändringsspårning.

Borttaget innehåll

Om källinnehållet inte längre finns (till exempel om texten förkortas till att ha färre segment) tas motsvarande underordnade dokument i sökindexet bort. De återstående underordnade dokumenten uppdateras också för att inkludera ett nytt hash-värde, även om deras innehåll inte har ändrats i övrigt.

Om ett överordnat dokument tas bort helt från datakällan tas motsvarande underordnade dokument bara bort om borttagningen identifieras av en dataDeletionDetectionPolicy definierad i datakällans definition. Om du inte har konfigurerat dataDeletionDetectionPolicy och behöver ta bort ett överordnat dokument från datakällan bör du ta bort de underordnade dokumenten manuellt om de inte längre är önskade.

Beräknat nyckelvärde

För att säkerställa dataintegriteten för uppdaterat och borttaget innehåll förlitar sig datauppdateringen i en-till-många-indexering på ett beräknat nyckelvärde på "många"-sidan. Om du använder integrerad vektorisering eller guiden Importera data är det projekterade nyckelvärdet det fält som återfinns på den delade eller "många" sidan av indexet.

Ett beräknat nyckelvärde är en unik identifierare som indexeraren genererar för varje dokument. Det säkerställer unikhet och gör det möjligt för spårning av ändringar och borttagning att fungera korrekt. Den här nyckeln innehåller följande segment:

• En slumpmässig hash för att garantera unikhet. Denna hash ändras om det överordnade dokumentet uppdateras vid efterföljande indexerarekörningar.
• Huvuddokumentets nyckel.
• Den berikningsanteckningssökväg som identifierar kontexten för det genererade dokumentet.

Om du till exempel delar upp ett överordnat dokument med nyckelvärdet "aa1b22c33" i fyra sidor, och var och en av dessa sidor projiceras som ett eget dokument via indexprojektioner:

• aa1b22c33
• aa1b22c33_pages_0
• aa1b22c33_pages_1
• aa1b22c33_pages_2

Om det överordnade dokumentet uppdateras i källdata, vilket kanske resulterar i fler segmenterade sidor, ändras de slumpmässiga hash-ändringarna, fler sidor läggs till och innehållet i varje segment uppdateras så att det matchar det som finns i källdokumentet.

Exempel på separata förälder- och barnindex

Det här avsnittet visar ett exempel på separata huvud- och underindex. Det är ett ovanligt mönster, men det är möjligt att du har programkrav som bäst uppfylls med den här metoden. I det här scenariot indexerar du föräldrar-barn-innehåll i två separata index.

1. Skapa två indexscheman.

   Varje schema har fälten för sin specifika detaljnivå, med det överordnade ID-fältet gemensamt för båda indexen för användning i en sökfråga. Den primära sökkorpus är det underordnade indexet, men du kan göra en sökfråga för att hämta de överordnade fält för varje matchning i resultatet. Azure AI-sökning stöder inte kopplingar vid frågetillfället, så programkoden eller orkestreringslagret måste sammanfoga eller sortera resultat som kan skickas till en app eller process.

   Det överordnade indexet har ett parent_id fält och rubrik. Parent_id är dokumentnyckeln. Du behöver inte konfigurera vektorsökning om du inte vill vektorisera fält på den överordnade dokumentnivån.

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

   Barnindexet har de segmenterade fälten, plus fältet parent_id. Om du använder integrerad vektorisering, bedömningsprofiler, semantisk rankning eller analysverktyg anger du dessa i det underordnade indexet.

   {
       "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. Uppdatera indexeraren för att ange överordnat index som mål.

   Indexerarens definition anger komponenterna i pipelinen. I indexerarens definition är det indexet vars namn ska anges det överordnade indexet. Om du behöver fältmappningar för de överordnade fälten definierar du dem i outputFieldMappings. För en-till-många-indexering som använder separata index kan indexerardefinitionen se ut som i följande exempel.

   {
     "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. Komplettera indexProjections i kompetensen.

   Här är ett exempel på en indexprojektionsdefinition som anger den datasökväg som indexeraren ska använda för att indexeras innehåll. Den anger namnet på det underordnade indexet i indexprojektionsdefinitionen och specificerar mappningarna för varje under- eller chunknivåfält. Det här är den enda platsen där indexnamnet för barn har specificerats.

   Observera att parameters är null och använder standardvärdet includeIndexingParentDocuments. Indexeraren fyller i det överordnade indexet. Matrisen selectors används för att projicera segmentdokumenten till det underordnade indexet.

   "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. Kör indexeraren. Om du tidigare körde indexeraren måste du återställa den först.

   Du bör ha två index ifyllda med lämpligt innehåll. Fråga indexen i Sökutforskaren för att kontrollera att var och en har rätt innehåll.

Nästa steg

Datasegmentering och en-till-många-indexering är en del av det klassiska RAG-mönstret i Azure AI-sökning. Fortsätt till följande självstudie och kodexempel om du vill veta mer om det.