Projekce indexů ve službě Azure AI Search

Důležité

Projekce indexů jsou ve verzi Public Preview v rámci doplňkových podmínek použití. Je k dispozici prostřednictvím webu Azure Portal, 2023-10-01-Preview rozhraní REST API, webu Azure Portal a beta klientských knihoven, které byly aktualizovány tak, aby zahrnovaly tuto funkci.

Projekce indexu jsou součástí definice sady dovedností, která definuje tvar sekundárního indexu, který podporuje vzor indexu 1:N, kde obsah z kanálu rozšiřování může cílit na více indexů.

Projekce indexů přebírají obsah obohacený o AI vygenerovaný kanálem rozšiřování a indexují ho do sekundárního indexu (liší se od indexeru, který ve výchozím nastavení cílí) ve vaší vyhledávací službě. Projekce indexů také umožňují změnit tvar dat před jejich indexováním způsobem, který jedinečně umožňuje oddělit pole obohacených položek do více vyhledávacích dokumentů v cílovém indexu, jinak označované jako indexování 1:N. Indexování 1:N je užitečné pro scénáře vytváření bloků dat, kde můžete chtít primární index pro nechunkovaný obsah a sekundární index pro blokované bloky dat.

Pokud jste v minulosti používali kognitivní dovednosti, už víte, že sady dovedností vytvářejí obohacený obsah. Sady dovedností přesunou dokument v posloupnosti obohacení, které vyvolávají atomické transformace, jako je rozpoznávání entit nebo překlad textu. Ve výchozím nastavení se jeden dokument zpracovaný v sadě dovedností mapuje na jeden dokument v indexu vyhledávání. To znamená, že pokud provádíte blokování vstupního textu a potom provedete rozšiřování jednotlivých bloků dat, výsledek indexu při mapování pomocí outputFieldMappings je pole vygenerovaných obohacení. Při projekcích indexů definujete kontext, ve kterém chcete namapovat jednotlivé bloky obohacených dat do vlastního vyhledávacího dokumentu. To vám umožní použít mapování 1:N rozšířeného dokumentu na index vyhledávání.

Definice projekce indexu

Projekce indexu jsou definovány uvnitř definice sady dovedností a primárně jsou definovány jako pole selektorů, kde každý selektor odpovídá jinému cílovému indexu ve vyhledávací službě. Každý selektor vyžaduje v rámci své definice následující parametry:

  • targetIndexName: Název indexu ve vyhledávací službě, do které index projekce dat indexu přejde.
  • parentKeyFieldName: Název pole v cílovém indexu, který obsahuje hodnotu klíče pro nadřazený dokument.
  • sourceContext: Poznámka k rozšiřování, která definuje členitost, při 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. Tyto parametry umožňují tvarovat data, která se mají indexovat do polí typu Edm.ComplexType v indexu vyhledávání.

Index definovaný v parametru targetIndexName má následující požadavky:

  • Před vytvořením definice projekcí indexu už musí být v vyhledávací službě vytvořena sada dovedností obsahující definici projekcí indexu.
  • Musí obsahovat pole s názvem definovaným v parametru parentKeyFieldName . Toto pole musí být typu Edm.String, nesmí být pole s klíčem a musí mít filtrovatelné nastaveno na hodnotu true.
  • Klíčové pole musí mít prohledávatelnou hodnotu nastavenou na hodnotu true a musí být definováno pomocí analyzátoru keyword .
  • Musí obsahovat pole definovaná pro každý z namenich definovaných v mappings, z nichž žádné nemůže být klíčové pole.

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

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

Zpracování nadřazených dokumentů

Vzhledem k tomu, že projekce indexů efektivně generují "podřízené" dokumenty pro každý "nadřazený" dokument, který prochází sadou dovedností, máte také následující možnosti, jak zpracovat indexování "nadřazených" dokumentů.

  • Pokud chcete zachovat nadřazené a podřízené dokumenty v samostatných indexech, stačí zajistit, aby definice indexeru targetIndexName byla jiná než targetIndexName definice definovaná v selektoru projekce indexu.

  • Pokud chcete indexovat nadřazené a podřízené dokumenty do stejného indexu, musíte zajistit, aby schéma cílového indexu fungovalo s definicí fieldMappings indexeru i outputFieldMappings s definicí indexeru a selektorem projekce indexu mappings . Pak byste zadali stejnou targetIndexName definici indexeru a selektor projekce indexu.

  • Pokud chcete ignorovat nadřazené dokumenty a jenom podřízené dokumenty indexu, musíte v definici indexeru targetIndexName zadat jenom ty, které jste udělali pro selektor projekce indexu. Pak definujte samostatný parameters objekt vedle definice selectors s klíčem nastaveným projectionMode na skipIndexingParentDocuments, jak je znázorněno zde:

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

Verzi 2023-10-01-Preview rozhraní REST API je možné použít k vytvoření projekce indexu prostřednictvím přidání sady dovedností.

Životní cyklus obsahu

Pokud zdroj dat indexeru podporuje zjišťování sledování změn a odstranění, může proces indexování synchronizovat primární a sekundární indexy, aby tyto změny vyzvedly.

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.

Poznámka:

I když můžete data v projektovaných dokumentech upravit ručně pomocí rozhraní API pro nabízení indexu, všechny úpravy se přepíšou při dalším vyvolání kanálu za předpokladu, že se dokument ve zdrojových datech aktualizuje.

Projected key value

Každý dokument projekce indexu obsahuje jedinečný identifikační klíč, který indexer generuje, aby zajistil jedinečnost a umožnil 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 napříč spuštěními 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 123 na čtyři stránky a každá z těchto stránek se promítá jako vlastní dokument prostřednictvím projekce indexu, klíč třetí stránky textu bude vypadat přibližně jako "01f07abfe7ed_123_pages_2". Pokud se potom nadřazený dokument aktualizuje tak, aby přidal pátou stránku, může být nový klíč třetí stránky například "9d800bdacc0e_123_pages_2", protože náhodná hodnota hash se mezi indexerem spustí, i když se zbytek dat projekce nezměnil.

Změny nebo přidání

Pokud je nadřazený dokument změněn tak, aby se data v projektovém indexovém dokumentu změnila (příkladem by bylo, kdyby se slovo změnilo na konkrétní stránce, ale nebyly přidány žádné čisté nové stránky), data v cílovém indexu pro danou projekci se aktualizují tak, aby odrážely tuto změnu.

Pokud se nadřazený dokument změní tak, aby existovaly nové projektované podřízené dokumenty, které tam nebyly dříve (příkladem by bylo, kdyby se do dokumentu přidala jedna nebo více stránek textu), při příštím spuštění indexeru se tyto nové podřízené dokumenty přidají.

V obou těchtopřípadechch

Deletions

Pokud je nadřazený dokument změněn tak, aby podřízený dokument vygenerovaný projekcemi indexu již neexistuje (příkladem by bylo zkrácení textu tak, aby existovalo méně bloků dat než dříve), 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.