Indexování velkých datových sad ve službě Azure AI Vyhledávač

Poznámka:

Azure AI Vyhledávač je k dispozici prostřednictvím portálu Azure, rozhraní REST API a Sady Azure SDK. Podporuje také Foundry IQ, spravovanou znalostní vrstvu, která transformuje podnikový obsah na opakovaně použitelné znalostní báze s podporou oprávnění pro agenty na portálu Microsoft Foundry.

Pokud potřebujete indexovat velké nebo složité datové sady ve vyhledávacím řešení, tento článek popisuje strategie pro zpracování dlouhotrvajících procesů ve službě Azure AI Vyhledávač.

Tyto strategie předpokládají znalost dvou základních přístupů k importu dat: nahrání dat do indexu nebo načtení dat z podporovaného zdroje dat pomocí indexeru vyhledávání. Pokud váš scénář zahrnuje výpočetně náročné rozšiřování AI, vyžadují se indexery vzhledem k závislostem sady dovedností na indexerech.

Tento článek doplňuje tipy pro lepší výkon, který nabízí osvědčené postupy pro návrh indexů a dotazů. Dobře navržený index, který obsahuje jenom pole a atributy, které potřebujete, je důležitým předpokladem pro rozsáhlé indexování.

Pro vyšší úložiště na oddíl použijte vyhledávací službu vytvořenou po 3. dubnu 2024. Můžete také upgradovat starší služby a využívat výhod vyšší kapacity úložiště oddílů.

Poznámka:

Strategie popsané v tomto článku předpokládají jeden velký zdroj dat. Pokud vaše řešení vyžaduje indexování z více zdrojů dat, vyhledejte doporučený postup v tématu Indexování více zdrojů dat ve službě Azure AI Vyhledávač .

Indexujte data pomocí rozhraní push API

Push rozhraní API, jako například REST API rozhraní pro index dokumentů nebo metoda IndexDocuments (Azure SDK pro .NET), jsou nejrozšířenější formou indexování ve službě Azure AI Vyhledávač. Pro řešení, která používají rozhraní API nabízených oznámení, má strategie dlouhodobého indexování jednu nebo obě následující komponenty:

  • Dávkové dokumenty
  • Správa vláken

Zpracovávejte více dokumentů na jednu žádost.

Jednoduchým mechanismem indexování velkého množství dat je odeslání více dokumentů nebo záznamů v jediné žádosti. Pokud je celá datová část pod 16 MB, může požadavek zpracovat až 1 000 dokumentů v rámci operace hromadného nahrávání. Tato omezení platí, ať už používáte buď Documents Index REST API, nebo metodu IndexDocuments v sadě .NET SDK. Pomocí některého rozhraní API můžete v textu každého požadavku zabalit 1 000 dokumentů.

Dávkování dokumentů výrazně zkracuje dobu potřebnou k práci s velkým objemem dat. Určení optimální velikosti dávky pro vaše data je klíčovou součástí optimalizace rychlosti indexování. Optimální velikost dávky ovlivňují dva primární faktory:

  • Schéma indexu
  • Velikost dat

Vzhledem k tomu, že optimální velikost dávky závisí na indexu a vašich datech, nejlepším přístupem je otestovat různé velikosti dávek a určit, která z nich má za následek nejrychlejší rychlost indexování pro váš scénář. Ukázkový kód pro testování velikostí dávek pomocí sady .NET SDK najdete v tématu Kurz: Optimalizace indexování pomocí rozhraní PUSH API.

Správa vláken a strategie opětovného pokusu

Indexery mají integrovanou správu vláken, ale když používáte push API, kód vaší aplikace musí spravovat vlákna. Ujistěte se, že máte dostatek vláken k plnému využití dostupné kapacity, zejména pokud jste nedávno upgradovali službu, přešli na vyšší cenovou úroveň nebo zvýšili oddíly.

  1. Zvyšte počet souběžných vláken v kódu klienta.

  2. Při zprovoznění požadavků do vyhledávací služby můžete narazit na stavové kódy HTTP, které značí, že požadavek nebyl plně úspěšný. Během indexování jsou dva běžné stavové kódy HTTP:

    • 503 Služba není k dispozici: Tato chyba znamená, že systém je zatížený velkým zatížením a v tuto chvíli nelze vaši žádost zpracovat.

    • 207 Multi-Status: Tato chyba znamená, že některé dokumenty byly úspěšné, ale alespoň jeden selhal.

  3. Aby bylo možné zpracovávat chyby, měly by se žádosti opakovat pomocí strategie exponenciálního zpoždění.

Sada Azure .NET SDK automaticky opakuje 503 a další neúspěšné požadavky, ale pro opakování 207 je potřeba implementovat vlastní logiku. K implementaci strategie opakování je možné použít také open-source nástroje, jako Polly.

Použití indexerů a pull API

Indexery nabízejí několik funkcí, které jsou užitečné pro dlouhotrvající procesy:

  • Dávkové dokumenty
  • Paralelní indexování nad dělenými daty
  • Plánování a detekce změn pro indexování pouze nových a změněných dokumentů v průběhu času

Plány indexeru mohou pokračovat ve zpracování v posledním známém zastavovacím bodu. Pokud data nejsou během časového okna zpracování zcela indexována, indexer při dalším spuštění naváže tam, kde skončil, pokud používáte zdroj dat s podporou detekce změn.

Rozdělení dat do menších jednotlivých zdrojů dat umožňuje paralelní zpracování. Ve službě Azure Blob Storage můžete rozdělit zdrojová data, například do několika kontejnerů, vytvořit zdroj dat pro každý oddíl a pak spustit indexery paralelně, a to v závislosti na počtu jednotek vyhledávání ve vyhledávací službě.

Zkontrolujte velikost šarže indexátoru

Stejně jako u rozhraní push API, indexery umožňují nakonfigurovat počet položek na dávku. U indexerů založených na rozhraní REST API pro vytvoření indexeru nastavte batchSize argument tak, aby toto nastavení přizpůsobil, aby lépe odpovídalo charakteristikám vašich dat.

Výchozí velikosti dávek jsou specifické pro zdroj dat. Azure SQL Database a Azure Cosmos DB mají výchozí velikost dávky 1 000. Naproti tomu se u indexování Azure Blob a SharePointu (preview) nastavuje velikost dávky na 10 dokumentů s ohledem na větší průměrnou velikost dokumentů.

Plánování indexerů pro dlouhotrvající procesy

Plánování indexeru je důležitým mechanismem pro zpracování velkých datových sad a pro přizpůsobení se pomalu probíhajícím procesům, jako je analýza obrázků ve zpracovatelském toku.

Zpracování indexeru se obvykle spouští během dvouhodinového intervalu. Pokud úloha indexování trvá spíše dny než hodiny, můžete nastavit indexer na nepřetržitý a opakující se plán, který se spouští každé dvě hodiny. Za předpokladu, že je u zdroje dat povolené sledování změn, indexer obnoví zpracování tam, kde naposledy skončil. V tomto tempu může indexer procházet backlog dokumentů po celou řadu dnů, dokud nebudou zpracovány všechny nezpracované dokumenty. Tento vzor je zvlášť důležitý při počátečním spuštění nebo při indexování velkých kontejnerů objektů blob, kde samotná fáze výpisu objektů blob může trvat několik hodin nebo dnů. Během této doby indexer nezobrazuje žádné objekty blob, které se zpracovávají, ale pokud se neohlásí chyba, pravděpodobně stále prochází seznamem objektů blob. Zpracování a rozšiřování dokumentů začíná až po dokončení této fáze a očekává se toto chování.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Pokud už ve zdroji dat nejsou žádné nové nebo aktualizované dokumenty, historie spouštění indexeru hlásí 0/0 zpracovaných dokumentů a žádné zpracování neprobíhá.

Další informace o nastavení plánů najdete v tématu Vytvoření rozhraní REST API indexeru nebo v tématu Plánování indexerů pro Azure AI Vyhledávač.

Poznámka:

Maximální okno zpracování závisí na tom, zda má indexer sadu dovedností. Indexátory se sadami dovedností běží v interně spravovaném multitenantním prostředí s maximální dobou běhu 2 hodiny. Indexery nakonfigurované k použití sdílených privátních odkazů mohou běžet maximálně 24 hodin. Indexery bez skillsetů mohou běžet maximálně 24 hodin.

Pokud váš indexer používá sadu dovedností s ukládáním do mezipaměti pro rozšiřování, před povolením mezipaměti pro velké úlohy si projděte následující informace.

Caution

U pracovních úloh s dlouho běžícími dovednostmi, opakovanými přerušeními nebo častými selháními může mezipaměť obohacení zvýšit celkový objem opětovného zpracování během počáteční ingestace nebo obnovení. Mezipaměť obohacení není záloha a neeviduje, u kterých dokumentů bylo zpracování dokončeno.

Paralelní spouštění indexerů

Pokud rozdělíte svá data do částí, můžete vytvořit několik kombinací indexeru a zdroje dat, které budou čerpat z každého zdroje dat a zapisovat do stejného vyhledávacího indexu. Vzhledem k tomu, že každý indexer je odlišný, můžete je spustit současně, takže index vyhledávání naplnit rychleji, než kdybyste je spustili postupně.

Ujistěte se, že máte dostatečnou kapacitu. Jedna jednotka vyhledávání ve vaší službě může kdykoli spustit jeden indexer. Vytváření více indexerů je užitečné jenom v případě, že se můžou spouštět paralelně.

Počet úloh indexování, které se dají spustit současně, se liší pro indexování založené na textu a na základě dovedností. Další informace naleznete v tématu Spuštění indexeru.

Pokud je zdrojem dat kontejner Azure Blob Storage nebo Azure Data Lake Storage Gen2, může vytvoření výčtu velkého počtu objektů blob trvat dlouhou dobu (i hodiny), než se tato operace dokončí. V důsledku toho se může zdát, že se počet úspěšně zpracovaných dokumentů indexeru během této doby nezvyšuje a že indexer ve skutečnosti nijak nepostupuje, i když postupuje. Pokud chcete, aby zpracování dokumentů bylo rychlejší pro velký počet objektů blob, zvažte rozdělení dat do několika kontejnerů a vytvoření paralelních indexerů odkazujících na jeden index.

  1. Na webu Azure Portal přejděte do vyhledávací služby.

  2. Zkontrolujte počet jednotek vyhledávání používaných vyhledávací službou. Výběrem možnosti Nastavení>Měřítko zobrazíte číslo v horní části stránky. Počet indexerů, které běží paralelně, se přibližně rovná počtu jednotek hledání.

  3. Rozdělte zdrojová data mezi více kontejnerů nebo více virtuálních složek uvnitř stejného kontejneru.

  4. Vytvořte několik zdrojů dat, jeden pro každý oddíl spárovaný s vlastním indexerem.

  5. V každém indexeru zadejte stejný cílový index vyhledávání.

  6. Naplánujte indexery.

  7. Zkontrolujte stav indexeru a historii spuštění pro ověření.

K paralelnímu indexování jsou spojená určitá rizika. Nejprve si připomeňme, že indexování neběží na pozadí, což zvyšuje pravděpodobnost, že dotazy budou omezeny nebo zahazovány.

Za druhé, Azure AI Vyhledávač nezamkne index aktualizací. Souběžné zápisy se spravují vyvoláním opakování, pokud se při prvním pokusu nepodaří provést konkrétní zápis, ale můžete si všimnout zvýšení počtu selhání indexování.

Přestože více sad zdrojů dat indexeru může cílit na stejný index, buďte opatrní při spuštění indexeru, která můžou přepsat existující hodnoty v indexu. Pokud druhý indexer-zdroj dat cílí na stejné dokumenty a pole, všechny hodnoty z prvního spuštění se přepíšou. Hodnoty polí jsou nahrazeny v plném rozsahu; indexer nemůže sloučit hodnoty z více běhů do stejného pole.

Indexování velkých objemů dat ve Sparku

Pokud máte architekturu velkých objemů dat a vaše data jsou v clusteru Spark, použijte SynapseML k načítání a indexování dat. Tento kurz obsahuje kroky pro volání Foundry Tools pro rozšiřování AI, ale k indexování textu můžete použít také rozhraní API AzureSearchWriter.

Související obsah

  • Last updated on