„Chceme AI nad našimi dokumenty“ je dnes jedna z nejčastějších poptávek na trhu s AI řešeními. RAG (Retrieval-Augmented Generation) je na to obvyklá odpověď, ale zdaleka ne vždy ta správná. Tady je rozhodovací strom, který používáme, než začneme cokoli stavět.

Co RAG je a co neřeší

RAG znamená: dotaz uživatele se použije k vyhledání relevantních pasáží ve vašich datech (typicky přes vektorové embeddingy), nalezené pasáže se vloží do promptu a LLM z nich složí odpověď. Model tedy nemusí vaše data „znát“, dostane je v kontextu.

Co RAG neřeší: kvalitu vašich dat (zastaralé dokumenty → zastaralé odpovědi), přístupová práva (kdo smí vidět co), strukturované dotazy („kolik jsme fakturovali v Q2?“) ani halucinace, jen jim dává lepší podklad.

Rozhodovací strom

  1. Jsou data strukturovaná? Čísla, tabulky, záznamy v DB → nechcete RAG, chcete SQL/API vrstvu, případně LLM, které generuje dotazy nad schématem.
  2. Kolik toho je? Pokud se celý korpus vejde do kontextového okna (dnes stovky stran), nepotřebujete retrieval, pošlete dokumenty rovnou do kontextu. Žádný index, žádná infrastruktura.
  3. Hledají lidé odpovědi, nebo dokumenty? Pokud uživatelé potřebují najít správný dokument (smlouvu, směrnici), často stačí pořádný fulltext s dobrými filtry. Search je řádově levnější a jeho výsledky se dají auditovat.
  4. Jde o styl, nebo o fakta? Fine-tuning učí model styl, formát a doménový žargon, ne fakta. Na fakta, která se mění, je fine-tuning nejhorší možný nástroj: každá změna znamená přetrénování.
  5. Mění se data průběžně a je jich hodně? Teprve tady začíná dávat RAG opravdu smysl.

Kdy RAG dává smysl

  • Velký, živý korpus (tisíce dokumentů, průběžné změny), který se nevejde do kontextu.
  • Odpovědi musí citovat zdroj: RAG umí vrátit, ze kterých pasáží odpověď vychází, což je klíčové pro důvěru i audit.
  • Dotazy jsou formulované přirozeným jazykem a odpověď je syntéza z více míst.

Kdy je lepší jiná cesta

  • Lepší search. Když uživatelé znají doménu a potřebují rychle najít dokument. Zkuste nejdřív vylepšit vyhledávání; je to často 20 % nákladů a 80 % užitku.
  • Celý korpus do kontextu. Malé znalostní báze (FAQ, ceník, pár směrnic). Jednodušší, levnější, bez indexu, který může být zastaralý.
  • Strukturovaná vrstva. Reporty a čísla přes SQL/API, ne přes embeddingy.
  • Fine-tuning. Jednotný tón, formát výstupů, doménový jazyk. V kombinaci s RAG, ne místo něj.

Na co si dát pozor, když RAG stavíte

  • Přístupová práva. Retrieval musí respektovat oprávnění uživatele na úrovni dokumentů. Jinak si zaměstnanec „vyhledá“ mzdovou tabulku vedení. Tohle je nejčastější bezpečnostní díra RAG nasazení.
  • Chunking. Jak dokumenty rozřežete, určuje kvalitu odpovědí víc než výběr modelu. Řezat podle struktury dokumentu, ne po pevných délkách.
  • Aktualizace indexu. Dokument se změnil, index o tom neví, AI odpovídá podle staré verze. Potřebujete pipeline na re-indexaci, ne jednorázový import.
  • Evaluace. Sada testovacích otázek se známými odpověďmi, měřená při každé změně (model, chunking, prompt). Bez ní ladíte poslepu.
  • Halucinace s citací. Model umí odpověď „doplnit“ i mimo nalezené pasáže. Instruujte odpovídat jen z kontextu a přiznat „nevím“, a měřte to v evaluaci.

Shrnutí

  • RAG je nástroj pro velké, živé, nestrukturované korpusy s potřebou citací.
  • Pro strukturovaná data, malé báze a „najdi mi dokument“ existují levnější a spolehlivější cesty.
  • Největší rizika nasazení: přístupová práva, zastaralý index a chybějící evaluace.

Nejlepší první krok: vezměte deset skutečných otázek vašich uživatelů a zkuste je zodpovědět ručně nad svými daty. Kde jste hledali a jak dlouho, to vám o správné architektuře řekne víc než jakýkoli benchmark.