Než první uživatel položí otázku, mívá návrh RAGu vektorovou databázi, reranker a někdy i několik agentů, kteří si předávají dotaz. Přitom ještě nikdo neověřil, zda potřebný odstavec nenajde obyčejný fulltext. Technická debata tak začíná u řešení, nikoli u chyby, kterou má řešit.
Retrieval-augmented generation se dá pro běžnou aplikaci popsat bez diagramu: systém přijme otázku, vyhledá ve vlastních datech vhodné pasáže a přidá je do kontextu jazykového modelu. Model z nich sestaví odpověď. Původní práce Patricka Lewise a jeho kolegů z roku 2020 používala hustý vektorový index Wikipedie a retriever trénovaný společně s generátorem. Dnešní produktový RAG je však širší označení pro spojení vyhledávání s generováním. Lewis et al., 2020
To je celé jádro.
Právě tady vzniká zbytečná aura mystéria. Z názvu výzkumné architektury se stal pytel, do kterého se hází chunkování, embeddingy, hybridní hledání, přepis dotazu, reranking i agentní orchestrace. Žádná z těch vrstev není povinná jen proto, že aplikace odpovídá nad firemními dokumenty.
RAG začíná dvěma obyčejnými rozhraními
Nejmenší použitelná verze potřebuje dvě věci. Vyhledávač vrátí k dotazu několik textových pasáží. Generátor dostane otázku spolu s těmito pasážemi a má odpovědět jen z nich, případně přiznat, že podklady nestačí. Retriever může být databázový fulltext, webový vyhledávač, volání interního API nebo ručně napsaný filtr nad malou sadou souborů.
Stejné dělení používá RAGAS, akademický rámec pro hodnocení těchto systémů: RAG má vyhledávací a generativní modul. Autoři odděleně posuzují, zda systém našel vhodné pasáže a zda je model použil, zatímco smysluplnost výsledné odpovědi sledují zvlášť. Es et al., EACL 2024
Toto rozdělení je praktické, protože u chybějící odpovědi se tým nejdřív podívá, zda správný dokument vůbec dorazil do kontextu: pokud ano, selhal prompt nebo model, zatímco v opačném případě leží chyba ve vyhledávání. Bez tohoto řezu se každý neúspěch snadno svede na neurčitou „kvalitu RAGu“ a tým začne měnit několik částí naráz.
Fulltext není primitivní předstupeň
Fulltext má jednu vlastnost, kterou firemní vyhledávání potřebuje překvapivě často: bere vážně přesná slova. Číslo faktury, kód chyby, jméno interní služby nebo název ustanovení nejsou sémantické hádanky.
Přesná shoda tu vyhrává.
PostgreSQL umí text rozdělit na tokeny, normalizovat je na lexémy a uložit do struktury tsvector, nad níž lze vyhledávat s indexem. Slovníky mohou sjednotit různé tvary slov, vyřadit stop slova nebo mapovat synonyma. Databázový fulltext jde podstatně dál než LIKE '%slovo%', ke kterému se někdy zjednodušuje. PostgreSQL: Full Text Search
Silný lexikální baseline potvrzuje i výzkum mimo RAGový marketing: benchmark BEIR porovnal deset vyhledávacích systémů na osmnácti datasetech z různých domén. BM25 v něm obecně překonával řadu složitějších metod při přenosu mimo data, na nichž byly natrénovány, a některé vektorové retrievery výrazně ztrácely zejména při změně domény nebo typu úlohy. Autoři zároveň zjistili, že křížový reranker nad kandidáty z BM25 překonal samotný BM25 na šestnácti z osmnácti datasetů. Fulltext je tedy rozumný start, který mohou další metody na konkrétních datech překonat. Thakur et al., BEIR, NeurIPS 2021
Nudný baseline má ještě jednu výhodu: jeho chyby bývají čitelné. Uživatel napsal jiný termín než dokument. Dotaz obsahoval příliš mnoho vaty. Relevantní stránku odfiltrovalo oddělení nebo jazyk. Teprve pojmenovaná chyba dává rozumné zadání další technice.
Nejdřív sada otázek, potom databáze
Prototyp RAGu nepotřebuje hned „AI eval platformu“. Potřebuje malou testovací sadu vytvořenou z práce skutečných uživatelů. Ke každé otázce se přiřadí pasáž nebo dokument, který má vyhledávání vrátit, a určí se přijatelná pozice výsledku. U podpory může být rozhodující první trojice. U rešerše možná prvních dvacet položek.
Pak stačí měřit několik srozumitelných veličin. Recall@k říká, u kolika otázek se správný podklad objevil mezi prvními k výsledky. Mean reciprocal rank zvýhodňuje případy, kdy skončil vysoko. Vedle toho má smysl sledovat latenci a počet pasáží, které se zbytečně posílají modelu. Kvalita finální odpovědi přijde na řadu až potom.
První sada nemusí mít tisíce řádků. Několik desítek poctivě vybraných dotazů odhalí víc než laborování s velikostí chunku na třech ukázkách, které si autor systému napsal sám. Patří do ní přesné identifikátory a parafráze, ale také volné otázky a dotazy, na které ve zdrojích odpověď není. Poslední skupina prověří, zda systém umí říct „nevím“.
Bez takového testu je každá změna architektury jen dojem.
Každá další vrstva má opravovat známou chybu
Rafael Pierre ve svém textu RAG Is Simpler Than You Think navrhuje postupovat od fulltextu ke složitějším variantám až podle provozních potřeb. Směr sedí. Konkrétní hranice pro počty dotazů, latenci nebo změny korpusu však pocházejí z autorovy zkušenosti a nelze je vydávat za obecné technické prahy. Rafael Pierre, 10. června 2026
Užitečnější než univerzální žebříček je mapa příznaků:
| Co ukázaly testy | Nejmenší rozumný zásah |
|---|---|
| Přesné názvy se nacházejí, parafráze ne | doplnit synonyma, přepis dotazu nebo otestovat embeddingy |
| Fulltext i embeddingy mají různé dobré výsledky | spojit je hybridním hledáním |
| Správná pasáž bývá v první padesátce, ale ne v první pětce | přidat reranker |
| Vektorové hledání je přesné, ale při růstu korpusu pomalé | změřit aproximovaný index HNSW či IVFFlat |
| Výsledky obsahují dokumenty cizího týmu nebo zákazníka | opravit oprávnění a metadata filtry, ne model |
Embeddingy pomáhají tam, kde se význam nepotkává ve stejných slovech: „Jak vrátím předchozí verzi?“ může mířit na kapitolu nazvanou „Obnova ze zálohy“. Hybridní hledání pak chrání sémantickou podobnost i přesné termíny. Anthropic ve vlastních experimentech s Contextual Retrieval zjistil, že spojení embeddingů s BM25 a následným rerankingem snižovalo počet případů, kdy správný chunk chyběl v prvních dvaceti výsledcích. Výsledek pochází z konkrétní firemní metodiky a neslibuje stejné zlepšení pro libovolný korpus, ale dobře ukazuje, proč se vrstvy skládají podle naměřeného přínosu. Anthropic, 19. září 2024
Ani vektorové vyhledávání automaticky nevyžaduje samostatnou databázi. Rozšíření pgvector provádí bez indexu přesné hledání nejbližších sousedů s úplným recallem. Až aproximované indexy mění část recallu za rychlost. HNSW má podle dokumentace lepší poměr rychlosti a recallu než IVFFlat, ovšem staví se déle a spotřebuje více paměti. pgvector: Indexing
Chunk není přirozená jednotka vědění
Jakmile systém přejde od celých dokumentů k pasážím, objeví se obtížná otázka: kde text rozříznout. Pevný počet tokenů vzniká provozním rozhodnutím, protože obsah sám žádnou takovou hranici nemá. Odstavec „Tržby vzrostly o 3 %“ je bez názvu firmy a období skoro bezcenný. Totéž platí pro odstavec ze smlouvy, který ztratil nadpis oddílu nebo definici pojmu z předchozí stránky.
Spravovaný Retrieval od OpenAI například používá jako výchozí hodnotu 800 tokenů s překryvem 400. Dokumentace dovoluje tuto hodnotu změnit a nepředepisuje ji jako optimum pro právní smlouvy nebo technické manuály. OpenAI: Retrieval
Právě chunkování bývá první místo, kde původně krátký prototyp začne připomínat výzkumný projekt. Řešení ale zůstává stejné: změnit jednu věc a přeměřit stejnou sadu otázek. Jinak nelze poznat, zda pomohl nový embedding, větší překryv, přidaný nadpis, nebo jen náhoda v několika dotazech.
Dlouhý kontext vyhledávání neruší
Láká jiná zkratka: dokumenty se nebudou hledat, všechny se vloží do velkého kontextového okna. U malého a stabilního korpusu to může být nejjednodušší prototyp. S růstem podkladů však přibývá cena, latence a hlavně rušivý text.
Studie Lost in the Middle ukázala na vícedokumentovém odpovídání výrazný vliv pozice relevantní informace. Zkoumané modely pracovaly nejlépe s podkladem na začátku nebo na konci kontextu a hůře, když ležel uprostřed. V navazujícím experimentu přineslo zvýšení počtu dokumentů z dvaceti na padesát u tehdejších modelů jen malý nárůst výkonu, přestože recall retrieveru dál rostl. Výsledky z roku 2024 nelze mechanicky přenést na každý dnešní model, ale boří představu, že více nalezeného textu vždy znamená lepší odpověď. Liu et al., TACL 2024
Vyhledávání tedy neslouží jen k tomu, aby se dokumenty vešly do limitu. Má do kontextu pustit co nejméně balastu a zachovat dost podkladů pro odpověď.
Produkční potíže neleží ve slově vektor
Jednoduchý mechanismus neznamená bezstarostný provoz. Systém musí respektovat přístupová práva, odstranit smazané dokumenty, poznat zastaralou verzi a ukázat, z čeho odpověď čerpá. Musí také odmítnout odpověď, když vhodný podklad nenašel. Tyto problémy existují u fulltextu i u vektorů.
Ani spravovaná služba je neodnese. OpenAI například uvádí, že vložení souboru do vector store probíhá asynchronně a smazání se projeví se zpožděním: krátce po odstranění se obsah ještě může objevit ve výsledcích. Tento provozní detail přímo ovlivňuje čerstvost a mazání dat. Chytřejší embedding ho neopraví. OpenAI: práce se soubory ve vector store
RAG je ve své podstatě smlouva mezi vyhledávačem a generátorem. Vyhledávač dodá podklady, generátor z nich odpoví a testy ukážou, kde se řetěz rozpadl. Vektorová databáze nebo reranker mohou být správnou opravou a složené dotazy někdy ospravedlní i agenta. Bez naměřené chyby jsou to drahé kulisy kolem fulltextu, který tým vůbec nezkusil.
Zdroje
- Lewis et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020
- Es et al.: RAGAS – Automated Evaluation of Retrieval Augmented Generation, EACL 2024
- Thakur et al.: BEIR – A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021
- Liu et al.: Lost in the Middle, TACL 2024
- PostgreSQL: Full Text Search
- pgvector: dokumentace
- Anthropic: Introducing Contextual Retrieval, 19. září 2024
- OpenAI: Retrieval
- Rafael Pierre: RAG Is Simpler Than You Think, 10. června 2026
