RAG prakticky: jak nechat AI odpovídat z vlastních dokumentů.

Jazykový model toho ví hodně, ale o tvojí firmě, tvém ceníku a tvých manuálech neví nic. Když ho zeptáš na tvoje konkrétní podmínky, buď přizná, že neví, nebo si něco vymyslí. Řešení se jmenuje RAG a ukážu ti, jak funguje a jak ho prakticky postavit, ať ti AI odpovídá z tvých dokumentů a ne ze vzduchu.

Co je RAG jednoduše

RAG je zkratka pro retrieval augmented generation, tedy generování obohacené o vyhledávání. Princip je jednoduchý a dá se shrnout do jedné věty: než model odpoví, nejdřív mu najdeš relevantní úryvky z tvých dokumentů a přiložíš je k otázce. Model pak neodpovídá z paměti, ale z toho, co jsi mu právě podal.

RAG není kouzlo. Je to chytré vyhledávání, jehož výsledek přilepíš k otázce, aby model odpovídal z faktů, ne z dojmu.

Proč nestačí jen nahrát dokumenty do promptu

Logická námitka: proč prostě nevložit celý manuál do promptu? Protože se tam nevejde a platil bys za to. Modely mají omezený kontext a každý znak něco stojí. Když máš sto stránek dokumentace, nemůžeš je posílat u každé otázky. RAG vybere jen ty tři odstavce, které se k dotazu opravdu hodí. Má to ještě jeden důvod, na který se zapomíná. Když modelu naláduješ sto stránek, jeho odpovědi se zhorší, protože v záplavě textu hůř najde to podstatné. Méně, ale relevantního textu vede k přesnější odpovědi než hora všeho možného. RAG tedy nešetří jen peníze, ale i zvyšuje kvalitu, protože modelu předkládá přesně to, co k odpovědi potřebuje, a nic navíc.

Krok 1: rozsekej dokumenty na kousky

Dokumenty nejdřív rozdělíš na menší úseky, takzvané chunky. Typicky pár set slov, ideálně po logických celcích, ne uprostřed věty. Každý kousek si ponechá informaci, odkud pochází, ať umíš později ukázat zdroj. Velikost kousků je víc umění než věda a vyplatí se ji vyzkoušet na vlastních datech. U strukturovaného textu, jako je ceník nebo seznam podmínek, dávají smysl menší kousky po jednotlivých bodech. U souvislého výkladu se hodí větší celky, aby se neztratil kontext. Nemusíš to vyřešit hned napoprvé. Začni rozumným odhadem, pusť pár testovacích dotazů a podle kvality odpovědí kousky případně zvětši nebo zmenši.

• Příliš velké kousky: vyhledávání je nepřesné, taháš zbytečný balast.
• Příliš malé kousky: ztrácí se kontext, odpověď je útržkovitá.
• Rozumný střed: odstavec až dva, s nadpisem sekce jako vodítkem.

Krok 2: spočítej embeddingy

Každý kousek textu převedeš na takzvaný embedding, což je seznam čísel, který reprezentuje význam textu. Texty s podobným významem mají podobná čísla. Díky tomu umíš hledat podle významu, ne jen podle shody slov. Otázka jak vrátit zboží najde i odstavec nadepsaný reklamace a vrácení, i když se slova neshodují.

// pro každý chunk si necháš spočítat embedding
const res = await fetch("https://api.poskytovatel.tld/v1/embeddings", {
  method: "POST",
  headers: {
    "Authorization": "Bearer " + process.env.AI_API_KEY,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ model: "embedding-model", input: chunk.text })
})
// vrácený vektor uložíš k chunku do databáze

Krok 3: ulož to do vektorové databáze

Embeddingy a texty kousků ulož do databáze, která umí hledat podle podobnosti vektorů. Nemusíš sahat po žádném exotickém nástroji, dnes to zvládne i běžný Postgres s rozšířením pro vektory. Pro malé a střední znalostní báze to bohatě stačí. Lidé často slyší vektorová databáze a představí si nákladnou specializovanou službu. Pro většinu firem to ale není potřeba. Pár tisíc kousků textu zvládne obyčejná databáze, kterou už možná provozuješ, hravě a rychle. Specializované řešení dává smysl až u opravdu velkých objemů. Začni jednoduše a škáluj, teprve až narazíš na strop, ne dřív.

Krok 4: při dotazu najdi a přilož

Když přijde otázka, spočítáš její embedding stejným modelem, najdeš v databázi nejpodobnější kousky a ty přiložíš k promptu. Model dostane otázku i podklady a odpoví jen z nich.

Odpověz na otázku uživatele POUZE z podkladů níže.
Když odpověď v podkladech není, řekni, že to nevíš.
Vždy uveď, z které sekce čerpáš.

Podklady:
"""
{nalezene_useky}
"""

Otázka: {dotaz}

Instrukce odpovídej jen z podkladů je srdcem celé věci. Tím modelu zakážeš vymýšlet a donutíš ho přiznat, když odpověď nemá. To je přesně to, proč je RAG tak užitečný pro chatboty na webu, o kterých píšu v článku AI chatbot za odpoledne. Celý ten proces, najdi a přilož, proběhne během jednoho dotazu a zákazník o něm vůbec neví. Zeptá se obyčejně lidsky, na pozadí proběhne vyhledání a přiložení podkladů a vrátí se odpověď, která vychází z tvých dokumentů. Z venku to vypadá jako kouzlo, uvnitř je to chytré vyhledávání spojené s generováním. A právě tahle nenápadnost dělá z RAG tak silný nástroj pro reálné nasazení.

Na co si dát pozor

1. Kvalita dat: z chaotických dokumentů bude chaotická odpověď. Ukliď zdroje dřív, než je nasypeš dovnitř.
2. Aktualizace: když změníš ceník, musíš přepočítat embeddingy dotčených kousků, jinak bot odpovídá zastaralé.
3. Zdroje v odpovědi: nech boota ukazovat, odkud čerpá. Buduje to důvěru a usnadňuje kontrolu.
4. Citlivá data: hlídej, co do báze dáváš, a kdo se na boota smí ptát.

Srovnání: čistý model versus RAG

Časté dotazy

Potřebuju kvůli RAG drahou infrastrukturu?

Ne. Pro běžnou firemní znalostní bázi stačí jedna databáze s podporou vektorů a volání na API pro embeddingy a odpovědi. Náklady jsou v jednotkách stovek korun měsíčně.

Zabrání RAG úplně všem výmyslům?

Výrazně je omezí, ale stoprocentní záruka neexistuje. Proto dáváš jasnou instrukci odpovídat jen z podkladů a necháváš boota ukazovat zdroje, aby šla odpověď ověřit.

Jak velké dokumenty zvládne?

Prakticky neomezené. Právě proto RAG vznikl. Nesází na to, že se vše vejde do promptu, ale na chytrý výběr relevantních kousků pro každou otázku zvlášť.

Pokud chceš boota nebo asistenta, který opravdu zná tvoje dokumenty a neztrapní tě výmyslem, postavím ti RAG na míru tvým datům. Napiš mi přes kontakt a probereme, co všechno má umět.