Sdílet prostřednictvím

Definování projekce indexu pro indexování nadřazený-podřízený

  • Článek

U indexů obsahujících blokované dokumenty určuje projekce indexu, jak je obsah nadřazený-podřízený mapován na pole v indexu vyhledávání pro index 1:N. Prostřednictvím projekce indexu můžete odeslat obsah do:

  • Jeden index, kde se nadřazená pole opakují pro každý blok dat, ale agregační interval indexu je na úrovni bloku. Kurz RAG je příkladem tohoto přístupu.

  • Dva nebo více indexů, kde nadřazený index obsahuje pole související s nadřazeným dokumentem a podřízený index je uspořádaný kolem bloků dat. Podřízený index je primární hledaný korpus, ale nadřazený index by se dal použít pro vyhledávací dotazy , pokud chcete načíst nadřazená pole konkrétního bloku dat nebo pro nezávislé dotazy.

Většina implementací je jeden index uspořádaný kolem bloků dat s nadřazenými poli, jako je název souboru dokumentu, který se opakuje pro každý blok dat. Systém je ale navržený tak, aby podporoval samostatné a více podřízených indexů, pokud je to váš požadavek. Azure AI Search nepodporuje připojení indexů, takže kód aplikace musí zpracovávat, který index se má použít.

Projekce indexu je definována v sadě dovedností. Zodpovídá za koordinaci procesu indexování, který odesílá bloky obsahu do indexu vyhledávání spolu s nadřazeným obsahem přidruženým ke každému bloku dat. Zlepšuje fungování nativního vytváření bloků dat tím, že poskytuje další možnosti pro řízení indexování obsahu nadřazeného a podřízeného obsahu.

Tento článek vysvětluje, jak vytvořit vzory schématu indexu a projekce indexeru pro indexování 1:N.

Požadavky

  • Kanál indexeru indexování.

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

  • Podporovaný zdroj dat s obsahem, který chcete vytvořit. Může to být vektorový nebo nevectorový obsah.

  • Dovednost, která rozděluje obsah na bloky dat, buď dovednost Rozdělení textu, nebo vlastní dovednost, která poskytuje ekvivalentní funkce.

Sada dovedností obsahuje projekci indexeru, která tvaruje 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.

Závislost na zpracování indexeru

Indexování 1:N závisí na sadách dovedností a indexerech, které zahrnují následující čtyři komponenty:

  • Zdroj dat
  • Jeden nebo více indexů pro prohledávatelný obsah
  • Sada dovedností, která obsahuje projekci indexu*
  • Indexer

Vaše data můžou pocházet z libovolného podporovaného zdroje dat, ale předpokládá se, že obsah je dostatečně velký, že ho chcete zachytnout, a důvodem pro jejich vytvoření je implementace vzoru RAG, který poskytuje základní data do chatovacího modelu. Nebo implementujete vektorové vyhledávání a potřebujete splnit menší požadavky na velikost vstupu vložených modelů.

Indexery načítají indexovaná data do předdefinovaného indexu. Jak definujete schéma a jestli chcete použít jeden nebo více indexů, je prvním rozhodnutím provést ve scénáři indexování 1:N. Následující část se zabývá návrhem indexu.

Vytvoření indexu pro indexování 1:N

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. 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 asociující jednotlivé bloky dat s nadřazeným objektem 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 indexer.

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 jsou nadřazená pole parent_id a název. Podřízená pole jsou vektorové a nevectorové bloky vektorů. Chunk_id je ID dokumentu tohoto indexu. Parent_id a název se opakují pro každý blok dat v indexu.

K vytvoření indexu můžete použít Azure Portal, rozhraní REST API nebo sadu Azure SDK.

{
    "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": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    }
}

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.

Zvolte kartu pro různé syntaxe rozhraní API. V současné době není k dispozici žádná podpora portálu pro nastavení projekcí, kromě úprav definice JSON sady dovedností. Projděte si příklad REST pro JSON.

Projekce indexů jsou obecně dostupné. Doporučujeme nejnovější stabilní rozhraní API:

Tady je příklad datové části pro definici projekcí indexu, kterou můžete použít k promítání jednotlivých stránek pomocí dovednosti Rozdělení textu jako vlastních dokumentů v indexu vyhledávání.

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

Referenční informace k parametrům

Parametry projekce indexu Definice
selectors Parametry pro hlavní hledaný korpus, obvykle ten navržený kolem bloků dat.
projectionMode Volitelný parametr poskytující pokyny indexeru. Jedinou platnou hodnotou tohoto parametru je skipIndexingParentDocumentsa používá se, když je index bloku dat primárním vyhledávacím souborem a potřebujete určit, zda jsou nadřazená pole indexována jako extra vyhledávací dokumenty v rámci blokovaného indexu. Pokud nenastavíte skipIndexingParentDocuments, získáte ve svém indexu další vyhledávací dokumenty, které mají hodnotu null pro bloky dat, ale naplní se pouze nadřazenými poli. Pokud například pět dokumentů přispívá do indexu 100 bloků dat, bude počet dokumentů v indexu 105. Pět dokumentů vytvořených nebo nadřazených polí má pro pole bloku (podřízené) hodnoty null, takže se podstatně liší od velké části dokumentů v indexu. projectionMode Doporučujeme nastavit .skipIndexingParentDocument

Selektory mají v rámci definice následující parametry.

Parametry selektoru Definice
targetIndexName Název indexu, do kterého se data indexu promítnou. Jedná se o jeden blokovaný index s opakujícími se nadřazenými poli, nebo je podřízeným indexem, pokud pro obsah nadřazený-podřízený používáte samostatné indexy .
parentKeyFieldName Název pole, které poskytuje klíč pro nadřazený dokument.
sourceContext Poznámka k rozšiřování, která definuje členitost, ve které se mají mapovat data do jednotlivých vyhledávacích dokumentů. Další informace najdete v tématu Kontext dovednosti a jazyk pro zadávání poznámek.
mappings Pole mapování obohacených dat na pole v indexu vyhledávání. Každé mapování se skládá z:
name: Název pole v indexu vyhledávání, do kterého se mají data indexovat.
source: Cesta poznámky k rozšiřování, ze které se mají data načíst.

Každá z nich mapping může také rekurzivně definovat data s volitelným sourceContext polem inputs , podobně jako úložiště znalostí nebo dovednost Shaper. V závislosti na vaší aplikaci umožňují tyto parametry tvarovat data do polí typu Edm.ComplexType v indexu vyhledávání. Některé LLM nepřijímají složitý typ ve výsledcích hledání, takže LLM, který používáte, určuje, jestli je mapování komplexního typu užitečné nebo ne.

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

Tento požadavek je na rozdíl od jiných konvencí mapování polí ve službě Azure AI Search. 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 explicitně zadat každé mapování polí na straně N relace.

Nevytvořte mapování polí pro pole nadřazeného klíče. Tím narušíte sledování změn a synchronizaci aktualizace dat.

Zpracování nadřazených dokumentů

Teď, když jste viděli několik vzorů pro indexování 1:N, vám umožní porovnat klíčové rozdíly mezi jednotlivými možnostmi. Projekce indexů efektivně generují "podřízené" dokumenty pro každý "nadřazený" dokument, který prochází sadou dovedností. Máte několik možností pro zpracování "nadřazených" dokumentů.

  • Pokud chcete odesílat nadřazené a podřízené dokumenty do samostatných indexů, nastavte targetIndexName definici indexeru na nadřazený index a nastavte targetIndexName selektor projekce indexu na podřízený index.

  • Pokud chcete zachovat nadřazené a podřízené dokumenty ve stejném indexu, nastavte indexer targetIndexName a projekci targetIndexName indexu na stejný index.

  • Chcete-li zabránit vytváření nadřazených vyhledávacích dokumentů a zajistit, aby index obsahoval pouze podřízené dokumenty jednotného agregace, nastavte targetIndexName definici indexeru i selektor na stejný index, ale přidejte další parameters objekt za selectors, s projectionMode klíčem nastaveným na skipIndexingParentDocuments, jak je znázorněno zde:

    "indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Kontrola 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žívají pro cesty k datům, které přebíjí data ze zdroje a předávají je pro indexování, bez kroku zpracování přechodných 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í. V indexování 1:N a dosud probíraných vzorech 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. V vzorech 1:N popsaných v tomto článku se jedná o nadřazený index v řešení se dvěma indexy. V příkladech zobrazených v tomto článku je nadřazený index zhuštěný, pouze s polem názvu a toto pole není naplněno obsahem ze zpracování sady dovedností, takže nemapujeme výstupní pole.

Mapování polí projekce indexeru slouží k mapování obsahu generovaného sadou dovedností na pole v podřízeného 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 samostatné nadřazené a podřízené indexy, měly by projekce indexeru obsahovat mapování polí pouze pro pole podřízené úrovně.

Poznámka:

Mapování výstupních polí i mapování polí projekce indexeru přijímají jako zdrojové vstupy rozšířené uzly stromu dokumentů. Znalost způsobu určení cesty k jednotlivým uzlům je pro nastavení cesty k datům nezbytná. Další informace o syntaxi cesty najdete v tématu Odkazování na cestu k obohaceným uzlům a definici sady dovedností pro příklady.

Spuštění indexeru

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 dotazovat index vyhledávání a otestovat řešení.

Životní cyklus obsahu

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

U zdrojů dat, které poskytují zjišťování sledování změn a odstraňování, může proces indexeru vyzvednout 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 vyzvedne, se rozšíří procesem rozšiřování do projekcí v indexu, čímž zajistíte, že vaše projektovaná data představují aktuální reprezentaci obsahu ve zdrojové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.

Poznámka:

I když můžete data v projektovaných dokumentech upravit ručně pomocí rozhraní API pro nabízení indexu, měli byste se tomu vyhnout. Ruční aktualizace indexu se přepíšou při vyvolání dalšího kanálu za předpokladu, že se dokument ve zdrojových datech aktualizuje a zdroj dat má povolené sledování změn nebo detekci odstranění.

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 slovo nebo věta v dokumentu změní, aktualizuje se blok dat v cílovém indexu obsahujícím toto slovo nebo větu při příští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 odstraňování ve výchozím nastavení na základě časového razítka. Jiné zdroje dat, jako je 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í. Zbývající podřízené dokumenty také zaktualizují svůj klíč tak, aby zahrnovaly novou hodnotu hash, i když se jejich obsah jinak nezměnil.

Pokud je nadřazený dokument zcela odstraněn ze zdroje dat, odpovídající podřízené dokumenty se odstraní pouze v případě, že odstranění zjistí dataDeletionDetectionPolicy definice 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.

Projected key value

Aby se zajistila integrita dat pro aktualizovaný a odstraněný obsah, aktualizace dat v indexování 1:N závisí na plánované hodnotě klíče na straně N. Pokud používáte integrovanou vektorizaci nebo průvodce importem a vektorizací dat, je parent_id projektovaná hodnota klíče polem v bloku dat nebo na straně N indexu.

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 odstraně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 poznámky rozšiřování, která identifikuje kontext, ze kterého byl dokument vygenerován.

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 se nadřazený dokument aktualizuje ve zdrojových datech, což může způsobovat další blokované stránky, náhodné změny hodnoty hash, přidání dalších stránek a aktualizace obsahu jednotlivých bloků dat tak, aby odpovídala obsahu zdrojového dokumentu.

Příklad samostatných indexů nadřazený-podřízený

Tato část ukazuje příklady 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ů.

Každé schéma má pole pro konkrétní agregační interval s polem nadřazeného ID, které je společné pro oba indexy pro použití ve vyhledávacím dotazu. Primární vyhledávací korpus je podřízený index, ale pak zadejte vyhledávací dotaz, který načte nadřazená pole pro každou shodu ve výsledku. Azure AI Search 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", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
    ]
}

Podřízený index obsahuje blokovaná pole a pole parent_id. Pokud používáte integrovanou vektorizaci, bodovací profily, sémantické rankery nebo analyzátory, nastavili byste 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": []
}

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 je zadaný název 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": []
                }
            ]
        }
    ]
}

Definice indexeru určuje komponenty kanálu. V definici indexeru je název indexu, který se má zadat, nadřazený index. Pokud potřebujete mapování polí pro pole nadřazené úrovně, definujte je ve outputFieldMappings. U indexování 1:N, které používá samostatné indexy, může definice indexeru vypadat jako v následujícím příkladu.

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

Další krok

Indexování dat a indexování 1:N jsou součástí vzoru RAG ve službě Azure AI Search. Pokračujte k následujícímu kurzu a ukázce kódu a získejte další informace o něm.

Vytvoření řešení RAG pomocí služby Azure AI Search