Jak RAG postavit a kde selhává

V předchozí lekci ses naučil, jak počítač najde text podle významu. Teď z toho postavíme celou aplikaci. Celou lekcí nás bude provázet jeden příklad: firma se třemi sty zaměstnanci má HR příručku, desítky směrnic a stovky odpovědí na časté dotazy. Personální oddělení každý den odpovídá na stejné otázky („Kolik mám dovolené?“, „Jak si zažádám o home office?“, „Co když onemocním na služební cestě?“) a chce asistenta, který to zvládne za něj, s odkazem na konkrétní článek příručky.

Je to jeden z nejběžnějších firemních případů použití AI, a přesto se v něm dá pokazit překvapivě mnoho. Projdeme stavbu krok za krokem i s tím, co se kde může zlomit.

Odkud RAG pochází

Zkratku RAG (retrieval-augmented generation, generování doplněné o vyhledávání) zavedl v roce 2020 tým Patricka Lewise z tehdejšího Facebook AI Research, University College London a New York University v článku publikovaném na konferenci NeurIPS. Popsali v něm dva druhy paměti jazykového modelu:

• parametrickou paměť: to, co se model naučil při tréninku a co je uložené v jeho parametrech,
• neparametrickou paměť: vnější sbírku textů (v jejich případě celou Wikipedii převedenou na embeddingy), ve které model před odpovědí vyhledává.

Autoři ukázali, že spojení obou dává konkrétnější a věcně správnější odpovědi než samotný model. A jmenovali dvě výhody, které jsou dodnes hlavním důvodem, proč firmy RAG stavějí: u odpovědi je vidět, z čeho vychází, a znalosti jde aktualizovat výměnou dokumentů, bez nového tréninku.

Lewis a kolegové trénovali vyhledávač a jazykový model společně. Dnešní firemní RAG obvykle jen propojí hotový embeddingový a hotový jazykový model aplikací. Princip zůstal stejný.

Celá cesta ve dvou fázích

RAG má dvě části, které běží v různou dobu:

Kdo RAG vidí poprvé, soustředí se na druhou fázi, protože tam „pracuje AI“. O kvalitě odpovědí se ale z velké části rozhoduje v přípravě: model neodpoví dobře z kousku, který byl špatně vyříznutý nebo zastaralý.

1. Příprava dokumentů

Načtení a úklid

Dokumenty bývají rozházené: SharePoint, sdílený disk, intranet, PDF v e-mailech. První krok je posbírat je a převést na čistý text. Zní to jako technická drobnost, ale tady vzniká hodně chyb:

• Záhlaví a zápatí. Věta „Interní dokument – strana 4 z 12“ na každé stránce zaplevelí vyhledávání.
• Duplicity a staré verze. Ve firmě obvykle koluje příručka 2023, příručka 2024 a „příručka 2024 FINAL opravená“. Když se všechny dostanou do báze, asistent může citovat tu neplatnou.
• Tabulky. Převod tabulky na text často rozbije řádky a sloupce. Z tabulky „Délka praxe / Dny dovolené“ se stane řada čísel bez souvislostí.
• Skenované PDF. Sken je obrázek, ne text. Bez rozpoznání textu (OCR) z něj nevznikne nic, s OCR může vzniknout text s chybami.

Dělení na kousky

Z předchozí lekce víš, že jeden embedding pro celý dlouhý dokument „zprůměruje všechno a nevystihne nic“. Dokumenty se proto dělí na menší části.

Kousek (chunk)(chunk, chunking)

Úsek dokumentu, který se ukládá a vyhledává samostatně, typicky odstavec nebo několik odstavců. Dělení dokumentů na kousky se říká chunking. Každý kousek dostane vlastní embedding.

Jak velké mají kousky být, je kompromis:

• Malé kousky (pár vět) jsou přesné: embedding vystihne jednu konkrétní věc. Jenže kousek může ztratit souvislost. Věta „Nárok se zvyšuje o pět dní.“ sama o sobě neříká, čí nárok a na co.
• Velké kousky (několik stran) souvislost zachovají, ale embedding se rozmaže mezi víc témat a do kontextu modelu se nese spousta zbytečného textu, který stojí tokeny.

Anthropic v návodu ke svému vyhledávání uvádí, že kousky mívají typicky nejvýš několik set tokenů. Univerzální správná velikost ale neexistuje, liší se podle typu dokumentů a nejlépe ji určí test na vlastních otázkách.

Dvě osvědčené techniky pomáhají kompromis zmírnit:

• Překryv (overlap): sousední kousky se o kus překrývají, například o pár vět. Když odpověď leží přesně na hranici dvou kousků, aspoň jeden ji bude obsahovat celou.
• Dělení podle struktury: místo řezání po pevném počtu slov se dokument dělí podle nadpisů a odstavců, takže kousek odpovídá jedné kapitole nebo článku.

A hlavně: ke kousku se ukládá, odkud pochází. Název dokumentu, cesta nadpisů („HR příručka › Dovolená › Zaměstnanci s praxí nad 5 let“), datum platnosti, vlastník dokumentu a kdo k němu má přístup. Nadpisy se často přidávají přímo na začátek textu kousku, aby se promítly i do embeddingu. Anthropic tento nápad rozvinul do techniky, kterou nazval kontextové vyhledávání (contextual retrieval): jazykový model ke každému kousku napíše krátké vysvětlení, z jakého dokumentu a části pochází, a to se uloží spolu s ním.

Indexování

Hotové kousky projdou embeddingovým modelem a uloží se do vektorové databáze i s metadaty. Často se zároveň uloží i do klasického fulltextového indexu pro hledání podle slov (proč, uvidíš za chvíli). Když se dokument změní, musí se jeho kousky přepočítat a staré smazat. Na tohle se rádo zapomíná, a pak asistent cituje směrnici, která už rok neplatí.

2. Vyhledávání

Zaměstnanec napíše: „Můžu si vzít home office, když jsem ve zkušební době?“ Systém spočítá embedding otázky a najde nejbližší kousky. Kolik jich vezme, se označuje jako top-k: top-5 znamená pět nejpodobnějších.

Hybridní vyhledávání(hybrid search)

Kombinace hledání podle významu (embeddingy) a hledání podle slov (například BM25). Výsledky obou metod se sloučí do jednoho pořadí. Zachytí tak jak dotazy psané jinými slovy, tak přesné kódy, názvy a čísla.

Hybridní vyhledávání je dnes v praxi běžný standard, protože embeddingy mají slepá místa popsaná v minulé lekci: přesné kódy, čísla smluv, jména. Když se zaměstnanec zeptá na „formulář HR-07“, hledání podle slov ho najde spolehlivě, hledání podle významu nemusí.

Druhé zlepšení je přeřazení.

Přeřazení (reranking)(reranking)

Druhé kolo výběru. Vyhledávání vrátí širší sadu kandidátů (třeba desítky až stovky kousků) a samostatný model, takzvaný reranker, posoudí každý z nich znovu, tentokrát přímo spolu s otázkou. Nejlepší pak postoupí do promptu.

Proč dvě kola? Embeddingy jsou rychlé, protože dokument se zakóduje předem, bez znalosti otázky. Reranker čte otázku a kousek společně, posoudí je přesněji, ale je pomalejší a dražší.

Jak velký rozdíl to dělá? Anthropic na svých testovacích sadách (zdrojové kódy, beletrie a odborné články) měřil, jak často mezi 20 nalezenými kousky chyběl ten správný. Se samotnými embeddingy to bylo v průměru 5,7 % dotazů. S kontextovým vyhledáváním a přidaným hledáním podle slov 2,9 %, a když přidali ještě přeřazení, 1,9 %. To jsou výsledky jedné firmy na jejích datech, ne zákon přírody. Ukazují ale směr: každá vrstva odstraní část chyb, žádná všechny.

3. Generování s citacemi

Teprve teď přichází na řadu jazykový model. Aplikace sestaví prompt (jak se model volá z aplikace, vysvětluje lekce Model přes API) ze tří částí: pokynů, nalezených kousků a otázky.

Citace nejsou ozdoba. Uživateli dávají možnost odpověď ověřit (přesně podle zásad z lekce Jak výstupy ověřovat) a tobě jako provozovateli ukazují, kde se systém pokazil, když odpoví špatně.

def odpovez(otazka, uzivatel):
    # 1) hledání: jen v dokumentech, ke kterým má uživatel přístup
    filtr = {"pristup": uzivatel.skupiny, "platne": True}
    kandidati = hledej_vektorove(otazka, k=50, filtr=filtr) + hledej_slovy(otazka, k=50, filtr=filtr)

    # 2) přeřazení: reranker čte otázku a kousek společně
    nejlepsi = prerad(otazka, odstran_duplicity(kandidati))[:10]

    # 3) prompt s očíslovanými podklady
    podklady = "\n".join(
        f"[{i+1}] {k.dokument} › {k.nadpisy}: {k.text}" for i, k in enumerate(nejlepsi)
    )
    return zavolej_model(system=POKYNY, zprava=f"Podklady:\n{podklady}\n\nOtázka: {otazka}")

Proč RAG halucinace snižuje, ale neodstraní

V lekci Halucinace zaznělo, že nejúčinnější obrana je dát modelu podklady. RAG je přesně tohle, jen automatizované. Model nemusí lovit fakta ze svých parametrů, má je přímo před sebou.

Halucinace ale nezmizí, jen změní podobu. Model může:

• doplnit „obvyklé“ pravidlo, které v podkladech není (třeba standardní výpovědní lhůtu místo té vaší),
• spojit dva kousky, které spolu nesouvisejí, například pravidlo pro jednu pobočku vztáhnout na celou firmu,
• uvést správné tvrzení se špatnou citací, nebo naopak citovat kousek, který tvrzení nepodporuje,
• odpovědět sebevědomě, i když vyhledávání nenašlo nic relevantního, protože dostal „nějaké“ podklady.

Poslední bod je zvlášť zrádný. Vyhledávání vrátí top-k kousků vždycky, i když žádný z nich na otázku neodpovídá. Proto patří do pokynů výslovné „pokud odpověď v podkladech není, řekni to“, a proto je dobré tuto situaci cíleně testovat.

Kde RAG typicky selhává

Když firemní asistent odpoví špatně, je skoro vždy užitečné zjistit, ve kterém kroku se chyba stala. Nejčastější případy:

1. Našel se špatný kousek. Otázka zněla jinak než dokument, kousek byl vyříznutý bez nadpisu, nebo vyhrál tématicky podobný, ale nesprávný text. Řešení leží ve vyhledávání: hybridní hledání, lepší dělení, přeřazení.
2. Odpověď je rozprostřená přes mnoho dokumentů. „Kolik zaměstnanců na všech pobočkách má nárok na stravenky?“ nemá odpověď v žádném jednom kousku. RAG je dobrý v hledání jehly v kupce sena, ne v počítání celé kupky. Na takové dotazy se hodí spíš databáze, ke které model přistupuje přes nástroje (viz lekce Volání nástrojů).
3. Zastaralé a duplicitní dokumenty. Stará a nová verze směrnice si jsou podobné, takže vyhledávání najde obě a model si vybere. Pomáhá úklid, metadata platnosti a filtr na platné verze.
4. Tabulky a skeny. Pokud se tabulka při převodu rozpadla, nejlepší vyhledávání ani model ji neposkládají zpátky. Tady se vyplatí kontrolovat, jak převedený text skutečně vypadá.
5. Oprávnění. Asistent nad celou firemní dokumentací může zaměstnanci ochotně odcitovat platy kolegů nebo zápis z jednání představenstva. Ochrana musí být ve vyhledávání: hledat jen v dokumentech, které daný uživatel smí vidět (filtr podle metadat). Pokyn v promptu „neprozrazuj důvěrné informace“ ochranou není, protože model ten text už viděl. Víc v lekci Oprávnění a lidská kontrola.
6. Dokument s nebezpečným obsahem. Zaindexovaný e-mail nebo web může obsahovat pokyny, které model poslechne. Tomu se říká prompt injection.

Jak poznat, jestli RAG funguje

Hodnocení RAG má dvě vrstvy a je důležité je oddělit:

• Kvalita vyhledávání. Byl mezi nalezenými kousky ten, který odpověď obsahuje? Tohle jde měřit poměrně snadno, pokud máš sadu otázek, u kterých víš, ve kterém článku příručky je odpověď.
• Kvalita odpovědi. Je odpověď správná, opírá se jen o podklady (výzkumníci tomu říkají věrnost, faithfulness), jsou citace správné a odpovídá na to, na co se uživatel ptal?

Proč oddělit? Protože každá kombinace vede k jiné opravě:

Pro HR asistenta to v praxi znamená: posbírej sto až dvě stě skutečných otázek, které HR dostává (s ohledem na ochranu osobních údajů), ke každé zapiš správnou odpověď a článek, kde ji najít. Přidej i otázky, na které příručka odpověď nemá, a ověř, že asistent přizná, že neví. Tuhle sadu pak pouštěj při každé změně: novém modelu, jiném dělení dokumentů, nové verzi příručky. Jak takovou sadu postavit a jak hodnotit odpovědi ve velkém (třeba i pomocí jiného modelu), rozebírají lekce Měření kvality a Testovací sady. Existují pro to i hotové nástroje, například open-source knihovna Ragas, jejíž autoři hodnocení RAG rozdělili právě na kvalitu vyhledaných pasáží, věrnost a kvalitu odpovědi.

RAG, fine-tuning, nebo dlouhý kontext

RAG není jediný způsob, jak dostat do AI vlastní znalosti. Tři hlavní možnosti:

Nejčastější omyl je „vytrénujeme si model na našich dokumentech“. Fine-tuning (o tréninku a dolaďování víc v lekci Jak se model trénuje) mění, jak model odpovídá, ale není spolehlivý způsob, jak do něj uložit fakta. Model si je zapamatuje nepřesně, neřekne, odkud je má, a po změně směrnice musíš trénovat znovu. Pro firemní znalosti je proto obvyklou volbou RAG, u malé báze dlouhý kontext: kdyby šlo jen o šedesátistránkovou příručku, nejjednodušší je vložit ji modelu celou. Fine-tuning přichází na řadu, když chceš změnit chování, a přístupy jdou kombinovat. Rozhodnutí, jestli takové řešení koupit, nebo stavět, rozebírá lekce Koupit, nebo postavit.

Zdroje a další čtení

• Lewis a kol.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020) – původní článek, který zavedl pojem RAG.
• Anthropic: Introducing Contextual Retrieval – dělení na kousky, hybridní vyhledávání, přeřazení a naměřená čísla (anglicky).
• Es a kol.: Ragas: Automated Evaluation of Retrieval Augmented Generation (2023) – jak hodnotit vyhledávání, věrnost a kvalitu odpovědí RAG systému.
• Anthropic: Embeddings – embeddingy a přeřazovací modely v praxi, s odkazem na návod na RAG (anglicky).