RAG v praxi: kvalitu neurčuje model, ale retrieval

RAG se ve firmách často prodává jako jednoduchý recept: vezměte dokumenty, rozdělte je na chunky, uložte embeddingy a nechte jazykový model odpovídat nad kontextem. To stačí na demo. Nestačí to na produkci. Skutečná kvalita RAG systému se neláme na tom, zda poslední model umí hezky formulovat odpověď. Lámat se bude na tom, jestli retrieval přinesl správný kontext, ve správném pořadí a s dostatečnou stopou ke zdroji.

Chunking je produktové rozhodnutí

Chunking není technická rutina. Je to rozhodnutí o tom, jakou jednotku významu systém uvidí. Příliš malé chunky ztratí souvislost, příliš velké přinesou šum a sežerou kontextové okno. Právní dokument, servisní manuál, znalostní báze a produktový changelog potřebují jiné dělení. U smluv často dává smysl držet články a odstavce, u manuálů kroky a varování, u support obsahu otázku a odpověď.

Praktický začátek bývá rozsah stovek slov, překryv tam, kde hrozí rozpad věty nebo tabulky, a metadata ke každému chunku: zdroj, verze, datum platnosti, vlastník dokumentu, typ obsahu a oprávnění. Bez metadat neumíte řešit ani citace, ani přístupová práva, ani stárnutí znalostí. To je důvod, proč RAG nad náhodným exportem PDF obvykle vypadá dobře první týden a horší po prvním větším update dokumentace.

Retrieval musí kombinovat signály

Čistý vector search je pohodlný, ale často nestačí. Firemní dotazy obsahují čísla smluv, názvy produktů, zkratky, interní kódy a přesné formulace. Tam je starý BM25 nebo fulltext pořád užitečný. Hybridní retrieval kombinuje sémantickou podobnost s lexikálním signálem. Nad tím má smysl reranker, který se podívá na užší sadu kandidátů a přeuspořádá je podle relevance k dotazu.

Microsoft ve své dokumentaci k RAG evaluátorům v Azure AI Foundry uvádí metriky jako NDCG, XDCG, Max Relevance a Holes a také hodnocení relevance na škále 1 až 5. To je dobrý signál pro praxi: hodnotit se nemá jen finální odpověď, ale i mezikrok retrievalu. Pokud se správný dokument nedostal mezi kandidáty, žádný prompt to spolehlivě nezachrání.

Evaluace není anketa spokojenosti

Nejčastější chyba RAG projektů je hodnotit odpovědi ručním dojmem po několika dotazech. Produkční systém potřebuje eval set: reprezentativní otázky, očekávané zdroje, typy uživatelů a negativní příklady. Měl by měřit zvlášť retrieval recall, přesnost citací, věrnost odpovědi zdroji a schopnost říct nevím. Tyto metriky se pak spouštějí při změně chunkingu, embedding modelu, rerankeru nebo promptu.

Užitečné je rozdělit otázky do tříd. Faktické dotazy s jedním zdrojem, dotazy vyžadující syntézu více dokumentů, dotazy s časovou platností, dotazy mimo rozsah znalostní báze a dotazy s oprávněním jen pro část uživatelů. Teprve tak se ukáže, zda systém opravdu zvládá firemní realitu, nebo jen dobře odpovídá na otázky, které mu tým položil v pilotu.

Reranker má přijít až ve chvíli, kdy baseline ukáže konkrétní slabinu. Někdy dramaticky pomůže, jindy jen přidá latenci a náklady. U interních znalostních bází bývá levnější nejdřív opravit dokumenty: odstranit duplicity, sjednotit názvy produktů, označit neplatné verze a doplnit metadata. Modely se často obviňují z halucinací, které ve skutečnosti vznikly tím, že systém našel tři protichůdné dokumenty a žádný z nich neměl datum platnosti. RAG architektura proto musí mít vlastníka obsahu, ne jen vlastníka infrastruktury.

Dobrá implementace má také odmítnutí jako produktovou funkci. Pokud retrieval vrátí slabý kontext, systém má říct, že odpověď nemá oporu ve zdrojích, a nabídnout cestu k člověku nebo k vyhledání dokumentu. Mnoho firem se bojí odpovědi nevím, ale v regulovaném B2B prostředí je to často nejbezpečnější a nejdůvěryhodnější výstup.

Co to znamená

Proč na tom záleží: RAG je často první enterprise AI projekt, protože slibuje nižší riziko než trénování modelu. To je pravda jen tehdy, pokud je retrieval navržený jako systém, ne jako úložiště embeddingů. Špatný RAG může halucinovat s citací, což je horší než odpověď bez citace, protože působí důvěryhodněji.

Praktický postup je jednoduchý, ale vyžaduje disciplínu. Začněte jednou znalostní doménou, ne celým SharePointem. Vyčistěte zdroje a nastavte vlastníky dokumentů. Udělejte baseline s jednoduchým chunkingem a hybridním vyhledáváním. Přidejte reranker až po měření. Vytvořte eval set před tím, než začnete optimalizovat. A hlavně logujte, které chunky šly do odpovědi. Bez toho budete ladit pocity, ne systém.

RAG není náhrada informační architektury. Je to její zkouška. Pokud firma neví, které dokumenty platí, kdo je vlastní a kdo je smí číst, RAG tuto nepořádnost jen zrychlí. Tam, kde je znalostní báze spravovaná, může být RAG velmi užitečný. Ne proto, že model ví víc, ale proto, že vyhledávání konečně začne vracet to, co lidé ve firmě potřebují k rozhodnutí.