Definovat projekci indexu pro indexování typu nadřazený-podřízený

Pokud obsah rozdělujete na bloky pro architekturu RAG nebo pro vektorizaci, můžete zadat projekci indexu a řídit tak indexování typu 1:N, kdy se zdrojový obsah (1) promítá do jednoho nebo více indexů (N). Záměrem projekce indexu je řídit, zda prvky nadřazeného dokumentu, například název souboru nebo datum vytvoření:

• Opakujte pro každý podřízený prvek (blok) v rámci jednoho indexu
• Indexují se jako samostatné vyhledávací dokumenty ve stejném indexu.
• Nebo jsou ukládána do samostatných indexů.

Doporučujeme opakovat nadřazená pole v jednom indexu, protože různé struktury dokumentů nebo rozdělení obsahu do dvou indexů se mohou obtížně dotazovat, zejména v klasickém vyhledávání, kde není podporováno spojování indexů.

V Azure AI Vyhledávač se rozdělování na části provádí pomocí dovedností, a závisí tedy na indexerech. Pokud chcete definovat projekci indexu, zadejte ji v sadě dovedností.

Požadavky

• Azure AI Vyhledávač, jakákoli cenová úroveň nebo oblast.

• Kanál indexování založený na indexeru.

• Podporovaný zdroj dat s obsahem, který chcete rozdělit na části.

• Index (jeden nebo více), který přijímá výstup kanálu indexeru.

• Dovednost, která rozděluje obsah na části, například dovednost Rozdělení textu.

Sada dovedností obsahuje projekci indexeru, která formuje data pro indexování 1:N. Sada dovedností může mít také další dovednosti, jako je například schopnost vkládání, jako je AzureOpenAIEmbedding , pokud váš scénář zahrnuje integrovanou vektorizaci.

Volba přístupu

Projekce indexů generují podřízené dokumenty (bloky) pro každý nadřazený dokument. Zvolte způsob zpracování nadřazeného obsahu:

Pro většinu scénářů RAG použijte první přístup. Viz příklad classic RAG.

Kroky implementace doporučeného přístupu

1. Vytvořte index navržený pro bloky dat s zahrnutými nadřazenými poli.
2. Vytvořte sadu dovedností s dovedností dělení na bloky a indexProjections.
3. Vytvořte indexer odkazující na podporovaný zdroj dat.

Pokud váš zdroj dat podporuje sledování změn, indexer synchronizuje změny automaticky.

Vytvořit index pro indexování one-to-many

Bez ohledu na to, jestli vytvoříte jeden index pro bloky dat, které opakují nadřazené hodnoty, nebo samostatné indexy pro umístění pole nadřazeného-podřízeného, je primární index použitý k vyhledávání navržen kolem bloků dat. Schéma indexu musí mít následující pole:

• Pole s klíčem dokumentu, které jednoznačně identifikuje každý dokument. Musí být definován jako typ Edm.String pomocí analyzátoru keyword .

• Pole, které přiřazuje každý blok jeho nadřazenému objektu. Musí být typu Edm.String. Nemůže to být pole klíče dokumentu a musí být filterable nastavené na hodnotu True. Označuje se jako parent_id v příkladech a jako projektovaná hodnota klíče v tomto článku.

• Další pole pro obsah, například textová nebo vektorizovaná pole bloků dat.

Před vytvořením sady dovedností nebo spuštěním indexeru musí ve vyhledávací službě existovat index. selectors, kterou definujete v sadě dovedností, by měla obsahovat tato pole.

Schéma s jedním indexem včetně nadřazených a podřízených polí

Jeden index navržený kolem bloků dat s nadřazeným obsahem opakujícím se pro každý blok dat je převládající vzor pro scénáře RAG a vektorového vyhledávání. Možnost přidružit správný nadřazený obsah ke každému bloku dat je povolena prostřednictvím projekcí indexu.

Následující schéma je příkladem, který splňuje požadavky pro projekce indexu. V tomto příkladu:

• Nadřazená pole jsou parent_id a title a opakují se pro každou část.
• Podřízená pole jsou vektorové a nevectorové bloky vektorů. Chunk_id je ID dokumentu tohoto indexu.

Pomocí portálu Azure, rozhraní REST API nebo Azure SDK můžete vytvořit 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")  

Přidání projekcí indexu do sady dovedností

Projekce indexů jsou definovány uvnitř definice sady dovedností a jsou primárně definovány jako pole selectors, kde každý selektor odpovídá jinému cílovému indexu ve vyhledávací službě. Tato část začíná syntaxí a příklady pro kontext a následným odkazem na parametry.

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

Referenční informace k parametrům

Parametry mají následující prvky jako součást jejich definice.

Selektory mají následující prvky jako součást jejich definice.

Parametr mappings je důležitý. Musíte explicitně mapovat každé pole v podřízeném indexu s výjimkou polí ID, jako je klíč dokumentu a ID nadřazené položky.

Tento požadavek je na rozdíl od jiných konvencí mapování polí v Azure AI Vyhledávač. U některých typů zdrojů dat může indexer implicitně mapovat pole na základě podobných názvů nebo známých charakteristik (například indexery objektů blob používají jedinečnou cestu k úložišti metadat jako výchozí klíč dokumentu). U projekcí indexeru však musíte výslovně zadat každé mapování pole na straně „many“ relace.

Zkontrolovat mapování polí

Indexery jsou přidruženy ke třem různým typům mapování polí. Před spuštěním indexeru zkontrolujte mapování polí a zjistěte, kdy se mají jednotlivé typy používat.

Mapování polí jsou definována v indexeru a slouží k mapování zdrojového pole na pole indexu. Mapování polí se používá pro datové cesty, které přebírají data ze zdroje a předávají je k indexaci, bez mezikroku zpracování pomocí dovedností. Indexer obvykle může automaticky mapovat pole se stejným názvem a typem. Explicitní mapování polí se vyžaduje jenom v případě nesrovnalostí. U indexování jedna k mnoha a u dosud probíraných vzorů možná nebudete potřebovat mapování polí.

Mapování výstupních polí jsou definována v indexeru a slouží k mapování rozšířeného obsahu generovaného sadou dovedností na pole do hlavního indexu. Segmenty se považují za obohacený obsah, protože byly vytvořeny pomocí dovednosti (Text Split), ale mapování výstupního pole nepotřebujete ani pro segmenty, ani pro projekce indexu, které jsou definovány mapováním selektoru.

Selectors.mappings jsou definovány v sadě dovedností a mapují na pole v podřízeném indexu. V případech, kdy podřízený index obsahuje také nadřazená pole (jako v konsolidovaném řešení indexu), byste měli nastavit mapování polí pro každé pole, které obsahuje obsah, včetně pole názvu nadřazené úrovně, za předpokladu, že se má název zobrazit v každém bloku dokumentu. Pokud používáte oddělené nadřazené a podřízené indexy, selektor by měl mít mapování polí pouze pro pole na úrovni podřízených položek.

Spusťte indexer

Jakmile vytvoříte zdroj dat, indexy a sadu dovedností, budete připraveni vytvořit a spustit indexer. Tento krok převede kanál do spuštění.

Po dokončení zpracování můžete zadávat dotazy do indexu vyhledávání a otestovat řešení.

Životní cyklus obsahu

V závislosti na zdroji dat může indexer obvykle poskytovat průběžné sledování změn a detekci odstranění. Tato část vysvětluje životní cyklus obsahu indexování 1:N, protože souvisí s aktualizací dat.

U zdrojů dat, které podporují sledování změn a zjišťování odstranění, může indexer zachytit změny ve zdrojových datech. Při každém spuštění indexeru a sady dovedností se odhady indexu aktualizují, pokud se sada dovedností nebo podkladová zdrojová data změnila. Všechny změny, které indexer zachytí, se prostřednictvím procesu obohacení promítnou do projekcí v indexu, což zajišťuje, že data v projekcích představují aktuální podobu obsahu v původním zdroji dat. Aktivita aktualizace dat se zaznamenává v projektované hodnotě klíče pro každý blok dat. Tato hodnota se aktualizuje při změně podkladových dat.

Aktualizovaný obsah

Pokud do zdroje dat přidáte nový obsah, při příštím spuštění indexeru se do indexu přidají nové bloky nebo podřízené dokumenty.

Pokud upravíte existující obsah ve zdroji dat, bloky dat se v indexu vyhledávání aktualizují přírůstkově, pokud zdroj dat, který používáte, podporuje zjišťování sledování změn a odstraňování. Pokud se například slovo nebo věta v dokumentu změní, blok dat v cílovém indexu, který obsahuje toto slovo nebo větu, se aktualizuje při dalším spuštění indexeru. U existujících polí se nepodporují jiné typy aktualizací, například změna typu pole a některých přisuzování. Další informace o povolených aktualizacích naleznete v tématu Aktualizace schématu indexu.

Některé zdroje dat, jako je Azure Storage podporují sledování změn a odstranění ve výchozím nastavení na základě časového razítka. Jiné zdroje dat, například Microsoft OneLake, Azure SQL nebo Azure Cosmos DB musí být nakonfigurované pro sledování změn.

Odstraněný obsah

Pokud zdrojový obsah již neexistuje (například pokud je text zkrácen tak, aby měl méně bloků dat), odstraní se odpovídající podřízený dokument v indexu vyhledávání. U zbývajících podřízených dokumentů se také aktualizuje klíč tak, aby zahrnoval novou hodnotu hashe, i když se jejich obsah jinak nezměnil.

Pokud je nadřazený dokument zcela smazán ze zdroje dat, odpovídající podřízené dokumenty se smažou pouze tehdy, pokud je toto smazání detekováno prvkem dataDeletionDetectionPolicy, který je definován v definici zdroje dat. Pokud nemáte nakonfigurovaný dataDeletionDetectionPolicy a potřebujete odstranit nadřazený dokument ze zdroje dat, měli byste podřízené dokumenty odstranit ručně , pokud už nechcete.

Projektovaná klíčová hodnota

Aby byla zajištěna integrita dat u aktualizovaného a odstraněného obsahu, obnovení dat při indexování typu one-to-many spoléhá na projektovanou hodnotu klíče na straně „many“. Pokud používáte integrovanou vektorizaci nebo průvodce Import data, je hodnota promítaného klíče pole parent_id v indexu rozděleném na bloky nebo na straně „many“.

Hodnota projektovaného klíče je jedinečný identifikátor, který indexer generuje pro každý dokument. Zajišťuje jedinečnost a umožňuje správné fungování sledování změn a odstraňování. Tento klíč obsahuje následující segmenty:

• Náhodná hodnota hash, která zaručuje jedinečnost. Tato hodnota hash se změní, pokud se nadřazený dokument aktualizuje při následných spuštěních indexeru.
• Klíč nadřazeného dokumentu.
• Cesta k anotačnímu rozšíření, která určuje kontext pro vygenerovaný dokument.

Pokud například rozdělíte nadřazený dokument s hodnotou klíče aa1b22c33 na čtyři stránky a pak se každá z těchto stránek promítá jako vlastní dokument prostřednictvím projekce indexu:

• aa1b22c33
• aa1b22c33_pages_0
• aa1b22c33_pages_1
• aa1b22c33_pages_2

Pokud je nadřazený dokument ve zdrojových datech aktualizován, může to vést k vytvoření více stránkových segmentů, změní se náhodně generovaný hash, přidají se další stránky a obsah každého segmentu se aktualizuje tak, aby odpovídal tomu, co je ve zdrojovém dokumentu.

Příklad oddělených indexů nadřazeného a podřízeného

Tato část ukazuje příklad samostatných nadřazených a podřízených indexů. Je to neobvyklý vzor, ale je možné, že při použití tohoto přístupu budete mít požadavky na aplikace, které jsou nejlépe splněné. V tomto scénáři projektujete obsah nadřazený-podřízený do dvou samostatných indexů.

1. Vytvořte dvě schémata indexu.

   Každé schéma obsahuje pole odpovídající jeho konkrétní úrovni podrobnosti, přičemž pole ID nadřazeného objektu je společné pro oba indexy a používá se v lookup query. Primární prohledávaný korpus tvoří podřízený index, ale můžete spustit dotaz typu lookup, který u každé shody ve výsledcích vrátí pole nadřazeného objektu. Azure AI Vyhledávač nepodporuje spojení v době dotazu, takže kód aplikace nebo vrstva orchestrace by potřebovala sloučit nebo kompletovat výsledky, které je možné předat aplikaci nebo procesu.

   Nadřazený index má parent_id pole a název. Parent_id je klíč dokumentu. Konfiguraci vektorového vyhledávání nepotřebujete, pokud nechcete vektorizovat pole na úrovni nadřazeného dokumentu.

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

   Podřízený index obsahuje pole rozdělená na bloky a navíc pole parent_id. Pokud používáte integrovanou vektorizaci, bodovací profily, sémantické řazení nebo analyzátory, nastavíte je v podřízeném indexu.

   {
       "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. Aktualizujte indexer tak, aby jako cíl určil nadřazený index.

   Definice indexeru určuje komponenty kanálu. V definici indexeru je třeba zadat název nadřazeného indexu. Pokud potřebujete mapování polí pro pole nadřazené úrovně, definujte je ve outputFieldMappings. Pro indexování typu 1:N, které používá oddělené indexy, může definice indexeru vypadat například takto.

   {
     "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. Přidejte indexProjections do sady dovedností.

   Tady je příklad definice projekce indexu, která určuje cestu k datům, kterou má indexer použít k indexování obsahu. Určuje název podřízeného indexu v definici projekce indexu a určuje mapování každého podřízeného pole nebo pole na úrovni bloku. Toto je jediné místo, kde se zadává název podřízeného indexu.

   Všimněte si, že parameters je null a používá výchozí includeIndexingParentDocuments. Indexer naplní nadřazený index. Pole selectors se používá k promítání dokumentů bloku do podřízeného indexu.

   "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. Spusťte indexer. Pokud jste indexer spustili dříve, nezapomeňte ho napřed resetovat.

   Měli byste mít dva indexy naplněné příslušným obsahem. Zadejte dotaz na indexy v Průzkumníku služby Search a ověřte, že každý z nich má správný obsah.

Další krok

Dělení dat na části a indexování typu one-to-many jsou součástí klasického vzoru RAG v Azure AI Vyhledávač. Pokračujte k následujícímu kurzu a ukázce kódu a získejte další informace o něm.