Indexery ve službě Azure Cognitive Search

Indexer ve službě Azure kognitivní hledání je prohledávací modul, který extrahuje prohledávatelný text a metadata z externího zdroje dat Azure a naplní index vyhledávání pomocí mapování polí mezi zdrojovými daty a vaším indexem. Tento přístup se někdy označuje jako "pull model", protože služba získává data v, aniž byste museli psát kód, který do indexu přidává data. Indexery také zadávají možnosti obohacení AI kognitivní hledání a integrují externí zpracování obsahu en route do indexu.

indexery jsou jenom azure a jednotlivé indexery pro azure SQL, Azure Cosmos DB, azure Table Storage a Blob Storage. Při konfiguraci indexeru zadáte zdroj dat (počátek) a také index (cíl). Několik zdrojů, jako je BLOB Storage, má další konfigurační vlastnosti, které jsou specifické pro daný typ obsahu.

Indexery můžete spouštět na vyžádání nebo podle plánu opakované aktualizace dat, který se spouští tak často, jak každých pět minut. Častější aktualizace vyžadují model push , který současně aktualizuje data v kognitivní hledání Azure i v externím zdroji dat.

Scénáře použití

Indexer můžete použít jako jediný způsob příjmu dat nebo jako součást kombinace techniků, které načítají a volitelně transformují nebo rozšiřují obsah podél. Následující tabulka shrnuje hlavní scénáře.

Scenario Strategie
Jeden zdroj dat Tento model je nejjednodušší: jeden zdroj dat je jediným poskytovatelem obsahu pro index vyhledávání. Ze zdroje určíte jedno pole obsahující jedinečné hodnoty, které bude sloužit jako klíč dokumentu v indexu vyhledávání. Jedinečná hodnota bude použita jako identifikátor. Všechna ostatní zdrojová pole jsou namapována implicitně nebo explicitně na odpovídající pole v indexu.

Důležitou poznatkem je, že hodnota klíče dokumentu pochází ze zdrojových dat. Vyhledávací služba negeneruje klíčové hodnoty. Při dalších spuštěních se přidají příchozí dokumenty s novými klíči, zatímco příchozí dokumenty s existujícími klíči se buď sloučí, nebo přepíší, v závislosti na tom, jestli jsou indexová pole null nebo naplněná.
Více zdrojů dat Index může přijímat obsah z více zdrojů, kde každé spuštění přináší nový obsah z jiného zdroje.

Jedním z výsledků může být index, který po spuštění každého indexeru získává dokumenty, přičemž všechny dokumenty jsou zcela vytvořené z každého zdroje. například dokumenty 1-100 se nacházejí v úložišti objektů Blob, dokumenty 101-200 jsou z Azure SQL a tak dále. Výzvou k tomuto scénáři spočívá v navrhování schématu indexu, který funguje pro všechna příchozí data, a strukturu klíčů dokumentu, která je v indexu vyhledávání jednotná. nativně jsou hodnoty, které jedinečně identifikují dokument, metadata_storage_path v kontejneru objektů blob a v tabulce SQL primární klíč. Můžete si představit, že jeden nebo oba zdroje musí být upraveny tak, aby poskytovaly klíčové hodnoty ve společném formátu bez ohledu na původ obsahu. V tomto scénáři byste měli očekávat, že provedete určitou úroveň předběžného zpracování, aby se data homogenizuje, aby bylo možné je načíst do jediného indexu.

Alternativním výsledkem může být hledání dokumentů, které se částečně vyplňují při prvním spuštění, a potom se dále vyplní následnými běhy, aby se hodnoty z jiných zdrojů vyplnily. například pole 1-10 se nacházejí v úložišti objektů Blob, 11-20 z Azure SQL a tak dále. Výzvou k tomuto vzoru se zajistí, že každý běh indexování bude cílen na stejný dokument. Sloučení polí do existujícího dokumentu vyžaduje shodu s klíčem dokumentu. Ukázku tohoto scénáře najdete v tématu kurz: index z více zdrojů dat.
Více indexerů Pokud používáte více zdrojů dat, můžete také potřebovat více indexerů, pokud potřebujete měnit parametry doby běhu, plán nebo mapování polí. I když může stejný index cílit více sad zdrojů dat indexeru, buďte opatrní při spuštění indexeru, které může přepsat existující hodnoty v indexu. Pokud druhý indexer – zdroj dat cílí na stejné dokumenty a pole, budou přepsány všechny hodnoty z prvního spuštění. Hodnoty polí jsou v plném rozsahu nahrazeny. Indexer nemůže sloučit hodnoty z více běhů do stejného pole.

Dalším případem použití více indexerů je horizontální horizontální navýšení kapacity kognitivní hledání. Můžete mít kopie stejného indexu hledání v různých oblastech. Chcete-li synchronizovat obsah indexu hledání, můžete mít více indexerů ze stejného zdroje dat, kde každý indexer cílí na jiný index vyhledávání.

Paralelní indexování velmi velkých datových sad vyžaduje také strategii s více indexery. Každý indexer cílí na podmnožinu dat.
Transformace obsahu Kognitivní hledání podporuje volitelná chování rozšíření AI , která přidávají analýzu obrázků a zpracování přirozeného jazyka pro vytváření nových prohledávatelných obsahu a struktury. Rozšíření AI je založené na indexerech prostřednictvím připojeného dovednosti. Aby bylo možné provést rozšíření AI, indexer stále potřebuje index a zdroj dat Azure, ale v tomto scénáři přidá zpracování dovednosti do indexeru.

Podporované zdroje dat

Úložiště dat procházení indexerů v Azure a mimo Azure.

Připojení indexeru ke vzdáleným zdrojům dat se dají provádět pomocí standardních připojení k Internetu (veřejných) nebo šifrovaných privátních připojení, když používáte Azure Virtual Networks pro klientské aplikace. Můžete také nastavit připojení pro ověřování pomocí identity důvěryhodné služby. další informace o zabezpečených připojeních najdete v tématu udělení přístupu prostřednictvím soukromých koncových bodů a Připojení ke zdroji dat pomocí spravované identity.

Fáze indexování

Pokud je index při počátečním spuštění prázdný, načtou se indexer všechna data, která jsou uvedena v tabulce nebo kontejneru. Při následném spuštění může indexer obvykle detekovat a načítat pouze data, která se změnila. V případě dat objektů BLOB je zjišťování změn automatické. u jiných zdrojů dat, jako je Azure SQL nebo Cosmos DB, musí být povolené zjišťování změn.

Pro každý dokument, který obdrží, indexer implementuje nebo koordinuje více kroků od načtení dokumentu do konečného vyhledávacího modulu pro indexování. V případě potřeby indexer také dovednosti provádění a výstupyza předpokladu, že je definována dovednosti.

Fáze indexeru

Fáze 1: trhliny dokumentů

Trhlina dokumentu je proces otevírání souborů a extrahování obsahu. Textový obsah se může extrahovat ze souborů ve službě, řádků v tabulce nebo položek v kontejneru nebo kolekci. Pokud do indexeru přidáte dovednosti a obrazové dovednosti , může se při zařazování dokumentů také extrahovat obrázky a zařadit je do fronty pro zpracování.

V závislosti na zdroji dat se indexer pokusí o extrakci potenciálně indexovaných obsahu jiné operace:

  • když je dokument soubor, jako je PDF nebo jiný podporovaný formát souboru v Azure Blob Storage, indexer otevře soubor a rozbalí text, obrázky a metadata. indexery mohou také otevírat soubory z SharePoint a Azure Data Lake Storage Gen2.

  • když je dokument záznamem v Azure SQL, indexer vyextrahuje nebinární obsah z každého pole v každém záznamu.

  • když je dokument záznamem v Cosmos DB, indexer extrahuje nebinární obsah z polí a podpolí z dokumentu Cosmos DB.

Fáze 2: mapování polí

Indexer extrahuje text ze zdrojového pole a odešle ho do cílového pole v indexu nebo v úložišti znalostí. Pokud se názvy polí a typy shodují, cesta je nejasná. Ve výstupu však můžete chtít jiné názvy nebo typy, v takovém případě je nutné sdělit indexeru, jak pole namapovat.

Tento krok nastane po zaznamenání dokumentu, ale před transformacemi, pokud indexer čte ze zdrojových dokumentů. Při definování mapování políje hodnota pole zdroj odesílána tak, jak je, do cílového pole bez úprav.

Fáze 3: spuštění dovednosti

Dovednosti provádění je volitelný krok, který vyvolá integrované nebo vlastní zpracování AI. Je možné, že ho budete potřebovat pro optické rozpoznávání znaků (OCR) ve formě analýzy obrázků, pokud jsou zdrojová data binárním obrázkem, nebo pokud je obsah v různých jazycích, může být nutné překlad jazyka.

Bez ohledu na transformaci dovednosti provádění je místo, kde dojde k obohacení. Pokud indexer je kanál, můžete si dovednosti představit jako "kanál v rámci kanálu".

Fáze 4: mapování polí výstupu

Pokud zahrníte dovednosti, budete pravděpodobně muset zahrnout mapování výstupních polí. Výstupem sady dovedností je ve skutečnosti strom informací nazývaný obohacený dokument. Mapování výstupních polí umožňuje vybrat, které části tohoto stromu se mají mapovat na pole v indexu. Naučte se definovat mapování výstupních polí.

Zatímco mapování polí přidružují doslovné hodnoty ze zdroje dat k cílovým polím, mapování výstupních polí sdělují indexeru, jak přidružit transformované hodnoty v obohaceném dokumentu k cílovým polím v indexu. Na rozdíl od mapování polí, která se považují za nepovinná, budete vždy muset definovat mapování výstupních polí pro libovolný transformovaný obsah, který se musí nacházet v indexu.

Následující obrázek ukazuje ukázkovou reprezentaci ladicí relace indexeru fází indexeru: prolomení dokumentů, mapování polí, provádění sady dovedností a mapování výstupních polí.

ukázková ladicí relace

Základní pracovní postup

Indexery můžou nabízet funkce, které jsou jedinečné pro daný zdroj dat. Z toho důvodu se budou některé aspekty konfigurace indexeru nebo zdroje dat lišit podle typu indexeru. Všechny indexery ale sdílejí stejné základní složení a požadavky. Níže najdete popis kroků společných pro všechny indexery.

Krok 1: Vytvoření zdroje dat

Indexery vyžadují objekt zdroje dat, který poskytuje připojovací řetězec a případně přihlašovací údaje. Pokud chcete vytvořit prostředek, zavolejte třídu Create Data Source (REST) nebo SearchIndexerDataSourceConnection.

Zdroje dat se konfigurují a spravují nezávisle na indexerech, které je používají, což znamená, že několik indexerů může používat zdroj dat k načtení více indexů současně.

Krok 2: Vytvoření indexu

Indexer automatizuje některé úkoly související s příjmem dat, ale vytváření indexu k nim obvykle nepatří. K základním požadavkům patří předdefinovaný index s poli, která odpovídají polím v externím zdroji dat. Pole se musí shodovat podle názvu a datového typu. Pokud ne, můžete definovat mapování polí a vytvořit tak přidružení. Další informace o strukturování indexu najdete v tématu Vytvoření indexu (REST) nebo třídy SearchIndex.

Tip

Přestože indexery nedokážou vygenerovat index za vás, může vám pomoct průvodce importem dat na portálu. Ve většině případů dokáže průvodce odvodit schéma indexu ze stávajících metadat ve zdroji a zobrazit předběžné schéma indexu, které můžete upravit přímo v aktivním průvodci. Po vytvoření indexu ve službě jsou další úpravy na portálu omezené hlavně na přidávání nových polí. K vytvoření, ale ne revidování, indexu zvažte použití průvodce. Praktickou výuku najdete v průvodci portálem.

Krok 3: Vytvoření a spuštění (nebo naplánování) indexeru

Indexer se spustí při prvním vytvoření indexeru ve vyhledávací službě. Pouze když indexer vytvoříte nebo spustíte, zjistíte, jestli je zdroj dat přístupný nebo jestli je sada dovedností platná. Po prvním spuštění ho můžete znovu spustit na vyžádání pomocí nástroje Run Indexernebo můžete definovat opakovaný plán.

Stav indexeru můžete monitorovat na portálu nebo prostřednictvím rozhraní API Get Indexer Status . Měli byste také spustit dotazy na index, abyste ověřili, že výsledek je to, co jste očekávali.

Další kroky

Teď, když jste se seznámili, je dalším krokem kontrola vlastností a parametrů indexeru, plánování a monitorování indexeru. Další informace o konkrétním zdroji najdete také v seznamu podporovaných zdrojů dat.