Agendové vyhledávání v Azure AI Vyhledávač

V Azure AI Vyhledávač je agentické načítání vícedotazový kanál navržený pro složité otázky uživatelů nebo agentů v aplikacích pro chat a copilot. Je určená pro systém generování podpořeného vyhledáváním (RAG) a pracovní postupy mezi agenty.

Takto funguje agentní načítání:

• Pomocí plánování dotazů založených na LLM (Preview) můžete rozdělit složitý dotaz na menší, zaměřené poddotazy pro lepší pokrytí proprietárního a externího obsahu. Plánování dotazů může použít historii chatu pro další kontext.

• Spouští poddotazy paralelně. Každý poddotaz se sémanticky přeřadí tak, aby se upřednostnily nejrelevavantnější shody.

• Kombinuje nejlepší výsledky do jednotné odpovědi, kterou může LLM použít ke generování fakticky podložených odpovědí.

• Může vracet zdrojové odkazy a protokol aktivit společně s sloučeným obsahem, takže můžete použít pouze podkladová data nebo je předat LLM pro úplnou odpověď.

Tento vysoce výkonný kanál vám pomůže vygenerovat vysoce kvalitní podkladová data nebo odpovědi pro chatovací aplikaci s možností rychle odpovídat na složité otázky.

Proč používat agentní vyhledávání?

Agentní vyhledávání podporuje spravovaná i vlastní prostředí pro agenty a aplikace. Na portálu Microsoft Foundry využívá Foundry IQ jako spravovanou znalostní vrstvu pro agenty. Můžete také vytvářet vlastní řešení agentního vyhledávání pomocí portálu Azure, rozhraní REST API vyhledávací služby nebo podporované sady Azure SDK.

Agentní vyhledávání použijte, když chcete agentům a aplikacím poskytnout nejrelevantnější obsah k zodpovídání složitějších otázek s využitím kontextu chatu, vašeho proprietárního obsahu a externích zdrojů.

Agentní vyhledávání přidává latenci ve srovnání s pipeline s jedním dotazem, ale zvládá složité dotazy, které jediný dotaz nezvládne. Může například zpracovávat:

• Dotazy s více požadavky, například „najdi mi hotel poblíž pláže, s dopravou na letiště a v pěší vzdálenosti od vegetariánských restaurací.“

• Dotazy, které závisejí na dřívějším kontextu konverzace

• Dotazy, které těží z přepisování s využitím map synonym a parafrází generovaných LLM k rozšíření pokrytí napříč vaším obsahem.

• Pravopisné chyby.

Architektura a pracovní postup

Proces získávání agenturních údajů funguje takto:

1. Inicializace pracovního postupu: Aplikace volá znalostní bázi s akcí načtení, která poskytuje historii dotazů a konverzací.

2. Plánování dotazů: Při úrovni low a medium úsilí o odvozování při vyhledávání odešle znalostní báze váš dotaz a historii konverzace do LLM, který vygeneruje cílené poddotazy. Při úsilí minimal se tento krok přeskočí a dotazy jsou směrovány přímo do zdrojů znalostí. Úroveň uvažování má výchozí hodnotu low a konfiguruje se ve znalostní bázi.

3. Provádění dotazů: Znalostní báze odešle poddotazy do vašich zdrojů znalostí. Všechny poddotazy se spouštějí současně a můžou být klíčové slovo, vektor nebo hybridní vyhledávání. Každý poddotaz prochází sémantickou rerankací, aby se zjistily nejrelevavantnější shody. Odkazy se extrahují a uchovávají pro účely citace.

4. Syntéza výsledků: Systém kombinuje všechny výsledky do sjednocené odpovědi. Sloučený obsah se vždy vrátí. Zdrojové odkazy a protokol aktivit provádění jsou volitelné.

Components

Pro všechny scénáře agentního načítání je vyžadována znalostní báze a alespoň jeden zdroj znalostí. Další komponenty jsou volitelné a závisí na vaší konfiguraci.

Požadavky na integraci

Vaše aplikace řídí kanál voláním znalostní báze a zpracováním odpovědi. Kanál vrací základní data, která můžete předat do LLM pro generování odpovědí nebo použít přímo v rozhraní konverzace. Podrobnosti o implementaci najdete v kurzu: Vytvoření kompletního řešení inteligentního načítání.

Dostupnost funkcí

Agentické vyhledávání podporuje funkce v obecně dostupné verzi i ve verzi Preview. Zvolte verzi rozhraní Search Service REST API, která odpovídá vašemu prostředí pro agentní vyhledávání:

• 2026-04-01 Rozhraní REST API použijte pro produkční úlohy, které používají obecně dostupné typy zdrojů znalostí s minimálním extrahovacím načtením.

• Pomocí rozhraní 2026-08-01-preview REST API můžete používat typy a možnosti zdrojů znalostí ve verzi Preview, jako jsou plánování dotazů na bázi LLM, syntéza odpovědí, vyšší než minimální úsilí uvažování při načítání a vícekolové zprávy. Viz podmínky verze Preview služby Azure AI Vyhledávač.

Portál Azure a portál Microsoft Foundry poskytují přístup ke všem funkcím agentického vyhledávání pouze v režimu Preview. Objekty vytvořené na obou portálech můžou používat schémata preview a vyžadovat migraci, když přejdete na obecně dostupnou verzi rozhraní REST API. Přehled změn podle jednotlivých verzí a pokyny k migraci najdete v článku Migrace kódu agentního vyhledávání na nejnovější verzi.

Dostupnost, limity a fakturace oblastí

Než začnete používat agentní vyhledávání, zkontrolujte jeho regionální dostupnost, omezení služby a fakturační model.

Dostupnost v regionu

Agentické načítání je k dispozici ve vybraných oblastech.

Omezení

Zdroje znalostí a znalostní báze mají maximální limity , které se liší podle cenové úrovně a úsilí o načtení.

Fakturace

Na vyhledávání agentů se účtují poplatky za dvě služby.

• Azure AI Vyhledávač fakturuje za získávání tokenů použitých při provádění poddotazů a sémantického hodnocení. Bezplatný plán (výchozí) poskytuje měsíční příděl tokenů. Standardní plán umožňuje průběžné platby po využití bezplatného příspěvku. Další informace viz Povolení nebo zakázání fakturace pro načítání dat agentem.

• Azure OpenAI účtuje poplatky za vstupní a výstupní tokeny používané při plánování dotazů založeném na LLM a syntéze odpovědí (preview). Cenová politika je vždy formou platby podle skutečné spotřeby a závisí na modelu, který přiřadíte ke znalostní bázi. Poplatky se zobrazí na faktuře za OpenAI Azure. Sazby najdete na stránce Ceny Azure OpenAI.

Následující tabulka porovnává fakturaci mezi klasickým kanálem s jedním dotazem a kanálem vícenásobného načítání agenta. V klasickém potrubí je fakturovatelnou komponentou sémantický třídič.

Příklad: Odhad nákladů

Tento příklad vám pomůže znázornit proces odhadu nákladů pro plánování dotazů a provádění dotazů, ale ne syntézu odpovědí. Vaše náklady můžou být nižší. Aktuální sazby najdete v ceníku Azure AI Vyhledávač a ceníku Azure OpenAI.

Pokud chcete odhadnout náklady na plán dotazů jako průběžné platby v Azure OpenAI, předpokládejme gpt-4o-mini:

• 15 centů za 1 milion vstupních tokenů.
• 60 centů za 1 milion výstupních tokenů.
• 2 000 vstupních tokenů pro průměrnou velikost chatovací konverzace
• 350 tokenů pro průměrnou velikost plánu výstupu.

Odhadované náklady na fakturaci při provádění dotazů

Pokud chcete odhadnout počty tokenů načítání agentů, začněte nápadem, jak vypadá průměrný dokument v indexu. Můžete například odhadnout:

• 10 000 bloků dat, kde každý blok dat je jeden až dva odstavce PDF.
• 500 tokenů na blok dat.
• Každý poddotaz znovu seřadí až 50 bloků dat.
• V průměru existují tři poddotazy na plán dotazu.

Výpočet ceny provedení

1. Předpokládejme, že provádíme 2 000 vyhledávání se třemi poddotazy pro každý plán. To nám dává asi 6 000 celkových dotazů.

2. Pořadí 50 bloků dat na poddotaz, což je celkem 300 000 bloků dat.

3. Průměrný blok je 500 tokenů, takže celkový počet tokenů pro přehodnocení je 150 milionů.

4. Vzhledem k hypotetické ceně 0,022 za token představuje celkové náklady na přehodnotování v amerických dolarech 3,30 USD.

5. Přechod na náklady na plán dotazů: 2 000 vstupních tokenů vynásobených 2 000 agentními načítáními se rovná 4 milionům vstupních tokenů celkem za 60 centů.

6. Odhadněte náklady na výstup na základě průměru 350 tokenů. Pokud vynásobíme 350 krát 2 000 agentních načítání, získáme celkem 700 000 výstupních tokenů v hodnotě celkem 42 centů.

Dohromady byste zaplatili přibližně 3,30 USD za agentní načítání v Azure AI Vyhledávač, 60 centů za vstupní tokeny v Azure OpenAI a 42 centů za výstupní tokeny v Azure OpenAI, celkem tedy 1,02 USD za plánování dotazů. Kombinované náklady na úplnou realizaci jsou 4,32 USD.

Tipy pro řízení nákladů

• Zkontrolujte protokol aktivit v odpovědi a zjistěte, jaké dotazy byly vydány pro které zdroje a použité parametry. Tyto dotazy můžete znovu nasunout na indexy a pomocí veřejného tokenizátoru odhadnout tokeny a porovnat je s využitím hlášeného rozhraní API. Přesné obnovení dotazu nebo odpovědi však není zaručeno. Mezi faktory patří typ zdroje znalostí, jako jsou veřejná webová data nebo vzdálený SharePoint zdroj znalostí, který je predikovaný na identitě uživatele, což může ovlivnit reprodukci dotazů.

• Snižte počet zdrojů znalostí (indexů), konsolidace obsahu může snížit rozvětvení a objem tokenů.

• Snižte úsilí při plánování a rozšiřování dotazů (iterativní vyhledávání) pro snížení využití LLM.

• Uspořádejte obsah tak, aby byly nejrelevantní informace nalezeny s menším počtem zdrojů a dokumentů (například kurátorovanými souhrny nebo tabulkami).

Jak začít

K vytvoření řešení agentního vyhledávání můžete použít portál Azure, nový portál Microsoft Foundry, rozhraní REST API nebo odpovídající balíček sady Azure SDK.

Další krok