Odpovědi roztroušené po dokumentech
Tým AWS Machine Learning Blog v technickém návodu předvádí, jak postavit konverzačního asistenta pro pojistná plnění nad službou Amazon Bedrock Knowledge Bases. Asistent odpovídá na dotazy v přirozeném jazyce a ke každé odpovědi přikládá citace. Důležité omezení zaznívá hned na začátku: návod pracuje se syntetickými záznamy a nepopisuje nasazení u skutečného zákazníka. Jde tedy o ukázku postupu a základní měření, nikoli o zprávu z provozu.
Problém, který má asistent řešit, autoři popisují takto: odpověď k pojistné události není v jediném prohledávatelném poli. Je rozptýlená v diářích likvidátorů, odhadech oprav, policejních zprávách, platebních knihách i skenovaných přílohách. Pracovník nebo pojistník by tak musel procházet několik typů dokumentů. Návod proto spoléhá na vyhledávání nad celou sadou podkladů a na odpověď, kterou lze dohledat zpět ke zdroji.
Jak je řešení poskládané
Dokumenty v PDF, ve Wordu nebo jako prostý text se ukládají do Amazon S3. Ke každému patří metadatový soubor se stejným názvem a příponou .metadata.json. Znalostní báze dokumenty zpracuje, rozdělí na části, vytvoří z nich embeddingy (číselné reprezentace významu textu) a zaindexuje je i s metadaty ve spravovaném vektorovém úložišti. Znalostní bázi lze vytvořit s typem MANAGED a embeddingovým modelem MANAGED. Model pak vybírá a provozuje Amazon Bedrock a vektorové úložiště není třeba konfigurovat.
Dotazy obsluhuje rozhraní AgenticRetrieveStream. Nejprve naplánuje odpověď, vícečástnou otázku rozloží na dílčí dotazy a provede jedno nebo více kol vyhledávání. Než začne generovat odpověď, ověří, zda našlo dost důkazů. Přes streamování pak posílá trasovací události, text odpovědi i citace. Rozdíl oproti jednorázovému dotazu je tedy v tom, že služba si výsledky může zkontrolovat a hledat znovu, než odpoví.
Požadavek obsahuje konverzační zprávy, až pět retrieverů, tedy znalostních bází, a konfiguraci agentního vyhledávání. V té lze zvolit spravovaný model MANAGED nebo vlastní model přes CUSTOM, parametr maxAgentIteration omezuje počet kol plánování a vyhledávání. Odpověď přichází jako proud tří typů událostí. Událost traceEvent popisuje jednotlivé kroky, responseEvent postupně nese text odpovědi a result obsahuje deduplikované výsledky hledání a hotovou odpověď s citacemi. Každá citace označuje úsek odpovědi a odkazuje na podpůrné zdroje.
Konverzace a filtry
Historii vícekolové konverzace si drží aplikace. Při každém volání posílá celý seznam zpráv, tedy dotazy uživatele i předchozí odpovědi asistenta. Autoři ukazují příklad: po dotazu na stav události CLM-100482 se pojistník zeptá, kdo je k ní přidělený likvidátor. Službě stačí historie, aby zájmeno „it“ v anglické ukázce přiřadila ke správné události. Stav konverzace tak není uložen na straně služby.
Metadatové filtry zužují množinu dokumentů ještě před sémantickým vyhledáváním. Datumy je nutné ukládat jako celá čísla ve tvaru RRRRMMDD, protože filtry porovnávají čísla, nikoli textová data. Podmínky se dají kombinovat pomocí andAll, například typ události, stav, částka a rozmezí data podání. U dotazu, který zasáhne mnoho událostí, autoři nastavují maxNumberOfResults na 50. Nižší limit by podle nich mohl některé shodné případy z shrnutí vynechat.
Co měření ukázalo a co ne
Autoři měřili na 30 syntetických dokumentech a 40 otázkách. Použili však rozhraní Retrieve a RetrieveAndGenerate, nikoli AgenticRetrieveStream, takže výsledky sami označují za základní srovnání pro daný korpus a schéma metadat, ne za benchmark agentního vyhledávání. Odpovědi navíc hodnotil model, proto jsou čísla pouze orientační. Podle tabulky bylo zodpovězeno všech 40 otázek a každá odpověď měla citace, v průměru 3,9. Pokrytí očekávaných zdrojů dosáhlo 90,5 % při vyhledávání a 81,2 % při citování. Žádný blok neodporoval zadanému filtru.
Na 20 adverzních otázkách, tedy záměrně zrádných dotazech, dosáhla úplnost vyhledávání 96,7 % a úplnost citací 90,2 %. Model podle autorů rozlišil podobně pojmenované firmy, zachoval tvrzení jako pouhé tvrzení a ignoroval text v příloze, který se tvářil jako instrukce. Nejlépe vycházely úzké otázky na konkrétní událost, naopak tři nejslabší výsledky daly široké nefiltrované dotazy na přehled. Autoři upozorňují, že citace nezaručují úplnost odpovědi, a doporučují před zpřístupněním pojistníkům lidskou kontrolu na vlastních datech.
Pojistka proti nepodloženým odpovědím
Jako další vrstvu návod doplňuje kontextovou kontrolu v Amazon Bedrock Guardrails. Blokuje odpovědi, které nedosáhnou nastavených prahů zakotvení v nalezených dokumentech a relevance. V příkladu jsou prahy 0,85 a 0,75, přičemž vyšší prahy podle návodu blokují více odpovědí. Při neúspěšné kontrole se odpověď zablokuje a trasovací události zásah zaznamenají. Konečné rozhodnutí o pojistné události má podle autorů zůstat na člověku, který zkontroluje citované důkazy.
Zdroje
- Query claims in natural language with Amazon Bedrock Knowledge Bases | Artificial Intelligence — AWS Machine Learning Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.