Jedna věta, šest otázek
Zdánlivě jednoduchý požadavek na podpůrného asistenta, třeba porovnání dvou produktů ve třech ohledech, v sobě skrývá šest samostatných otázek. Právě tady podle autorů z AWS narážejí aplikace postavené na generování doplněném vyhledáváním (RAG), tedy na kombinaci vyhledávače a jazykového modelu. Klasické jednorázové hledání celý dotaz zpracuje najednou, a nalezené úryvky proto pokryjí jen část toho, na co se uživatel ptal. Jazykový model pak odpovídá jen z toho, co dostal, takže kvalita odpovědi je omezená už kvalitou vyhledání. Amazon Bedrock Managed Knowledge Base nabízí jinou cestu: agentické vyhledávání, které dotaz nejprve naplánuje, rozloží a podle výsledků případně hledá znovu. Blog ukazuje, jak ho použít s knihovnou LangChain, kde pomůže a kde se naopak vyplatí zůstat u levnějšího řešení.
Proč jeden vektor nestačí
Jádrem problému je způsob, jakým funguje vyhledávání podle podobnosti. Dotaz se převede na jediný vektor, tedy číselný otisk významu, a systém k němu hledá nejbližší úryvky v databázi. Podle autorů tento jediný vektor musí zastoupit všechny záměry dotazu najednou. Šest různých otázek se tak slije do jednoho průměrného zadání. Výsledek působí věrohodně, protože nalezené úryvky se tématu skutečně týkají. Jenže podle textu pokrývají jen zlomek toho, na co se uživatel opravdu ptal. Nejde tedy o zjevnou chybu typu zcela nesprávné odpovědi, ale o nenápadnou neúplnost, kterou je těžší odhalit a kterou jazykový model při psaní odpovědi nemá z čeho napravit. Právě tato kombinace věrohodnosti a neúplnosti činí problém záludným: výstup vypadá v pořádku, dokud někdo neověří, které dílčí otázky zůstaly bez opory v nalezených textech.
Ukázka: čtyři ze šesti
Autoři to předvedli na dotazu srovnávajícím dvě služby ve třech oblastech, tedy na šesti dílčích záměrech. Nalezené úryvky pak ohodnotili podle toho, kolik záměrů skutečně pokrývají, takže získali konkrétní míru toho, co jeden vektor dokáže vyzvednout. Standardní vyhledávání s pěti výsledky, které podle textu tvoří zhruba desetinu korpusu, našlo informace jen ke čtyřem ze šesti záměrů. Chyběly údaje o eskalaci pohotovosti u jedné služby a o obnově u druhé. Autoři to shrnují tak, že jeden vektor zastupující šest záměrů při pěti výsledcích dva z nich mine. Po zvýšení počtu výsledků na deset, tedy asi 19 procent korpusu, už byly pokryty všechny záměry. Zaplatilo se za to ale zbytečným balastem: dva záměry byly doložené dvakrát a jeden úryvek neobsahoval nic užitečného. Víc výsledků tedy problém sice zakryje, ale neřeší ho efektivně, protože do odpovědi přibude text, který nic nového nepřináší.
Jak funguje plánování
Agentické vyhledávání v Amazon Bedrock Managed Knowledge Base se místo jednoho hledání chová jako postupný plán. Nejprve rozloží otázku na dílčí dotazy a ty spustí. Potom posoudí, zda získané důkazy stačí. Pokud ne, hledá znovu. Rozdíl oproti klasickému přístupu je tedy v tom, že systém si výsledky sám kontroluje a nespoléhá se na jediný pokus. Pro ukázku s dvěma službami a třemi oblastmi je to přirozený postup: každý z šesti záměrů může dostat vlastní cílený dotaz, takže nezávisí na tom, zda se všechny vejdou do jednoho vektoru. Zdroj ovšem v dodaných pasážích neuvádí, jak přesně plánovač dotazy dělí ani podle jakých kritérií považuje důkazy za dostatečné, a proto tyto detaily nelze posuzovat. Zřejmý je jen princip: plán, provedení, kontrola a případné opakování. Právě ta poslední fáze je odpovědí na situaci, kdy první kolo hledání některý záměr přehlédne.
Zapojení do LangChainu má háčky
Pro vývojáře je důležité, že agentické vyhledávání není klasický retriever pro LangChain. Balíček langchain-aws ho nabízí jako samostatnou funkci agentic_retrieve, protože rozhraní API své výsledky streamuje a nezapadá do synchronního rozhraní BaseRetriever. Do řetězce se proto musí vložit přes RunnableLambda, tedy obálku, která z obyčejné funkce udělá článek řetězce. Pomocná funkce navíc vrací jen konečné úryvky a plán před uživatelem skrývá. Autoři to označují za pohodlné, ale zároveň za omezení, protože plán dotazů nevidíte. Kdo chce vidět trace události s plánem, musí zavolat rozhraní přímo přes boto3. V ukázce se používá klient bedrock-agent-runtime a streamovací volání agentic_retrieve_stream, kterému se předá dotaz, znalostní báze a například horní mez deseti výsledků. Stejné přímé volání je také potřeba, pokud chcete nastavit maximální počet iterací nebo vlastní plánovací model, což pomocná funkce neumožňuje. Pohodlná cesta je tedy méně průhledná než ruční.
Co říká benchmark MuSiQue
AWS uvádí, že agentické vyhledávání vyhodnotilo také na veřejném benchmarku MuSiQue, který testuje vícekrokové otázky. Taková otázka vyžaduje poskládat odpověď z více navazujících informací, takže jedno hledání zpravidla nestačí. Podle AWS se recall, tedy podíl potřebných důkazů, které se podařilo najít, oproti jednorázovému vyhledávání zlepšil. Největší zisk přineslo u nejtěžších otázek. U jednoduchých otázek vyžadujících jediný krok byl zisk menší než pět bodů. Je to logické: kde stačí jedno hledání, plánování mnoho nepřidá. Jde ale o tvrzení výrobce o vlastním řešení a dodané pasáže neobsahují konkrétní čísla pro těžké otázky ani popis nastavení srovnání. Velikost přínosu na vašich datech proto z textu odhadnout nelze. Čtenář by měl výsledek brát jako vodítko ke směru, nikoli jako záruku konkrétního zlepšení.
Cena a latence
Lepší pokrytí má svou cenu. Agentické vyhledávání je dražší na jedno volání, provádí několik volání modelu a má z obou porovnávaných cest vyšší latenci, tedy delší čekání na odpověď. Autoři proto nedoporučují používat jednu variantu pro všechno. Doporučují směrovat dotazy podle jejich podoby: klasifikátor nebo jednoduché pravidlo nad otázkou pošle většinu provozu levnou cestou a plánovač zůstane vyhrazen pro otázky, které ho opravdu potřebují. Kombinace s výsledky benchmarku dává smysl, protože zisk u jednoduchých otázek je malý a u složitých větší. Platit za několik volání modelu u dotazu, který by vyřešilo jediné hledání, by tedy bylo plýtvání. Naopak u složeného dotazu, jako je srovnání dvou služeb ve třech oblastech, může být vyšší cena a delší čekání přijatelným kompromisem. Zdroj ale nepopisuje, jak takové pravidlo navrhnout ani kolik provozu by v praxi skončilo u plánovače.
Co si z toho odnést
Prakticky z ukázky plyne několik kroků. Zjistěte, zda vaši uživatelé kladou složené dotazy, u kterých se jeden vektor snadno minde s některým záměrem. Zvažte, zda jim nepomůže agentické vyhledávání místo pouhého navyšování počtu výsledků, které podle ukázky sice pokrylo všech šest záměrů, ale přidalo i redundanci. Počítejte s tím, že se v LangChainu zapojuje přes RunnableLambda a že plán uvidíte jen přímým voláním boto3. A nakonec rozdělte provoz, aby dražší plánovač řešil jen to, co levná cesta nezvládne. Otevřené zůstává, jak velké zlepšení uvidíte na vlastních datech, protože zdroj uvádí jen jednu ilustrační úlohu a souhrnné tvrzení o benchmarku. Rozumné je proto začít měřením: podobně jako autoři ohodnoťte, kolik dílčích záměrů vaše vyhledávání skutečně pokrývá, a teprve podle toho rozhodněte, zda se složitější a dražší cesta vyplatí.
Zdroje
- Agentic retrieval with LangChain and Amazon Bedrock Knowledge Bases | Artificial Intelligence — AWS Machine Learning Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.