Indexprognoser i Azure AI Search

Artikel
11/15/2023

Viktigt!

Indexprognoser är i offentlig förhandsversion under kompletterande användningsvillkor. Den är tillgänglig via Azure-portalen, 2023-10-01-Preview REST API:er, Azure-portalen och betaklientbibliotek som har uppdaterats för att inkludera funktionen.

Indexprojektioner är en komponent i en kompetensuppsättningsdefinition som definierar formen på ett sekundärt index, som stöder ett en-till-många-indexmönster, där innehåll från en berikningspipeline kan riktas mot flera index.

Indexprognoser tar AI-berikat innehåll som genereras av en berikningspipeline och indexeras till ett sekundärt index (skiljer sig från det som en indexerare riktar in sig på som standard) i söktjänsten. Med indexprojektioner kan du också omforma data innan du indexerar dem, på ett sätt som unikt gör att du kan separera en matris med berikade objekt i flera sökdokument i målindexet, även kallat "en-till-många"-indexering. "En-till-många"-indexering är användbart för datasegmenteringsscenarier, där du kanske vill ha ett primärt index för okrypterat innehåll och ett sekundärt index för segmenterat.

Om du har använt kognitiva kunskaper tidigare vet du redan att kunskapsuppsättningar skapar berikat innehåll. Kunskapsuppsättningar flyttar ett dokument genom en sekvens med berikningar som anropar atomiska transformeringar, till exempel att känna igen entiteter eller översätta text. Som standard mappar ett dokument som bearbetas inom en kompetensuppsättning till ett enda dokument i sökindexet. Det innebär att om du utför segmentering av en indatatext och sedan utför berikanden på varje segment, är resultatet i indexet när det mappas via outputFieldMappings en matris med de genererade berikningarna. Med indexprojektioner definierar du en kontext där varje segment med berikade data ska mappas till sitt eget sökdokument. På så sätt kan du använda en en-till-många-mappning av ett dokuments berikade data i sökindexet.

Definition av indexprognoser

Indexprojektioner definieras i en kompetensuppsättningsdefinition och definieras främst som en matris med väljare, där varje väljare motsvarar ett annat målindex i söktjänsten. Varje väljare kräver följande parametrar som en del av definitionen:

targetIndexName: Namnet på indexet på söktjänsten som indexprojektionsdataindexet till.
parentKeyFieldName: Namnet på fältet i målindexet som innehåller värdet för nyckeln för det överordnade dokumentet.
sourceContext: Den berikningsanteckning som definierar kornigheten för att mappa data till enskilda sökdokument. Mer information finns i Kunskapskontext och indataanteckningsspråk.
mappings: En matris med mappningar av berikade data till fält i sökindexet. Varje mappning består av:
- name: Namnet på fältet i sökindexet som data ska indexeras till,
- source: Den berikningsanteckningssökväg som data ska hämtas från.

Var mapping och en kan också rekursivt definiera data med ett valfritt fält och fält, som liknar kunskapsarkivet eller Shaper Skill.Each can also recursively define data with an optional sourceContext and inputs field, similar to the knowledge store or Shaper Skill. Med de här parametrarna kan du forma data som ska indexeras till fält av typen Edm.ComplexType i sökindexet.

Indexet som definieras i parametern targetIndexName har följande krav:

Måste redan ha skapats i söktjänsten innan den kompetensuppsättning som innehåller indexprojektionsdefinitionen skapas.
Måste innehålla ett fält med det namn som definierats i parametern parentKeyFieldName . Det här fältet måste vara av typen Edm.String, kan inte vara nyckelfältet och måste ha filtreringsbart inställt på sant.
Nyckelfältet måste ha sökbart inställt på true och definieras med analysatorn keyword .
Måste ha fält definierade för var och en av de names som definierats i mappings, varav inget kan vara nyckelfältet.

Här är ett exempel på en nyttolast för en indexprojektionsdefinition som du kan använda för att projicera enskilda sidors utdata med Dela färdighet som egna dokument i sökindexet.

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

Hantera överordnade dokument

Eftersom indexprojektioner effektivt genererar "underordnade" dokument för varje "överordnat" dokument som körs via en kompetensuppsättning, har du även följande alternativ för hur du hanterar indexeringen av "överordnade" dokument.

Om du vill behålla överordnade och underordnade dokument i separata index ser du bara till att targetIndexName indexerarens definition skiljer sig från den targetIndexName som definierats i indexprojektionsväljaren.
Om du vill indexera överordnade och underordnade dokument i samma index måste du se till att schemat för målindexet fungerar med både din definierade och outputFieldMappings i indexerarens fieldMappings definition och mappings i indexprojektionsväljaren. Sedan skulle du bara ange samma targetIndexName sak för indexerarens definition och indexprojektionsväljaren.
Om du vill ignorera överordnade dokument och endast indexera underordnade dokument måste du fortfarande ange en targetIndexName i indexerarens definition (du kan bara ange samma som du gör för indexprojektionsväljaren). Definiera sedan ett separat parameters objekt bredvid din selectors definition med en projectionMode nyckel inställd på skipIndexingParentDocuments, som du ser här:
```
"indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}
```

REST
.NET

REST API-versionen 2023-10-01-Preview kan användas för att skapa indexprognoser genom tillägg till en kompetensuppsättning.

Innehållslivscykel

Om indexerarens datakälla stöder identifiering av ändringsspårning och borttagning kan indexeringsprocessen synkronisera de primära och sekundära indexen för att hämta ändringarna.

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.

Kommentar

Du kan redigera data manuellt i de planerade dokumenten med hjälp av index-push-API:et, men alla ändringar skrivs över vid nästa pipelineanrop, förutsatt att dokumentet i källdata uppdateras.

Beräknat nyckelvärde

Varje indexprojektionsdokument innehåller en unik identifieringsnyckel som indexeraren genererar för att säkerställa unikhet och göra 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. Hash-värdet ändras om det överordnade dokumentet uppdateras mellan indexerarens körningar.
Det överordnade dokumentets nyckel.
Den berikningsanteckningssökväg som identifierar den kontext som dokumentet genererades från.

Om du till exempel delar upp ett överordnat dokument med nyckelvärdet "123" i fyra sidor, och var och en av dessa sidor projiceras som ett eget dokument via indexprojektioner, skulle nyckeln för den tredje textsidan se ut ungefär som "01f07abfe7ed_123_pages_2". Om det överordnade dokumentet sedan uppdateras för att lägga till en femte sida kan den nya nyckeln för den tredje sidan till exempel vara "9d800bdacc0e_123_pages_2", eftersom det slumpmässiga hash-värdet ändras mellan indexeraren körs trots att resten av projektionsdata inte ändrades.

Ändringar eller tillägg

Om ett överordnat dokument ändras så att data i ett beräknat indexdokument ändras (ett exempel skulle vara om ett ord ändrades på en viss sida men inga nya nettosidor lades till), uppdateras data i målindexet för den specifika projektionen för att återspegla den ändringen.

Om ett överordnat dokument ändras så att det finns nya projicerade underordnade dokument som inte fanns där tidigare (ett exempel skulle vara om en eller flera sidor med text lades till i dokumentet), läggs de nya underordnade dokumenten till nästa gång indexeraren körs.

I båda dessa fall uppdateras alla planerade dokument så att de har ett nytt hash-värde i nyckeln, oavsett om deras specifika innehåll har uppdaterats.

borttagningar

Om ett överordnat dokument ändras så att ett underordnat dokument som genereras av indexprojektioner inte längre finns (ett exempel skulle vara om en text förkortas så att det finns färre segment än tidigare) 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 annars inte ändrades.

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.

Share via