Co je RAG a proč by jej měl znát každý vývojář
I Velký jazykový model (LLM) způsobili revoluci ve způsobu, se kterým komunikujeme informací, ale trpí zásadním problémem: jejich znalosti jsou statický, zmrazené v době tréninku. Když se zeptáte LLM na vaši dokumentaci interně, na vašich produktech nebo na aktualizovaných datech, odpověď bude obecná, vymyšlená nebo jednoduchá špatně. Tento jev se nazývá halucinace.
Retrieval-Augmented Generation (RAG) řeší tento problém kombinací síly generativní LLM s přesností systému vyhledávání informací. Místo spoléhání pouze do paměti modelu, RAG nejprve vyhledává relevantní dokumenty v databázi znalostí a tam poskytuje modelu kontext pro generování přesných odpovědí založených na datech.
V tomto prvním článku seriálu AI pro webové vývojáře, prozkoumáme RAG do hloubky: co to je, jak to funguje, kdy to použít a kdy se tomu vyhnout. Na konci budete mít jeden dobře rozumíte architektuře RAG a budete připraveni ji implementovat v dalším článku.
Přehled série
| # | Položka | Soustředit |
|---|---|---|
| 1 | Jste zde - Co je RAG | Základy a architektura |
| 2 | RAG s TypeScript a LangChain.js | Praktické provedení |
| 3 | Vektorová databáze pro Web Dev | Úložiště a hledání podobnosti |
| 4 | OpenAI a Antropické API | Integrace LLM |
| 5 | LLM Local s Ollamou | On-premise modely |
| 6 | Jemné doladění vs RAG | Kdy co použít |
| 7 | Agenti AI: Architektura | Autonomní systémy |
| 8 | AI v potrubí CI/CD | Automatizace DevOps |
Co se naučíte
- Co je RAG a jaký problém řeší
- Kompletní architektura systému RAG (retrieval + generation).
- Jak funguje vkládání a vyhledávání podobností
- Rozdělovací strategie pro přípravu dokumentů
- Rozdíl mezi RAG a jemným doladěním
- Skutečné případy použití: chatbot, sémantické vyhledávání, otázky a odpovědi
- Omezení RAG a kdy jej NEPOUŽÍVAT
1. Problém: LLM a statické znalosti
Představte si, že chcete vytvořit chatbota pro zákaznickou podporu vaší společnosti. Máte jich tisíce stránky dokumentace, často kladené otázky, technické manuály a vyřešené vstupenky. Používáte LLM jako GPT-4 nebo Claude, ale výsledek je zklamáním: modelka nezná vaše produkty, vymýšlí si neexistující funkce a poskytuje nesprávné postupy s naprostou jistotou.
Tři základní problémy LLM
| Problém | Popis | Dopad |
|---|---|---|
| Hranice znalostí | Model zná pouze tréninková data | Neví nic o vašich proprietárních datech |
| Halucinace | Vytvářejte věrohodné, ale nepravdivé odpovědi | Nesprávné informace s vysokou spolehlivostí |
| Žádná citace | Nemůže uvést zdroj informací | Nelze ověřit správnost |
Tyto problémy nelze jednoduše vyřešit pomocí lepší výzvy. Potřebujeme skutečná data, aktualizované a specifické pro vaši doménu. A to je přesně to, co RAG dělá.
2. Co je RAG: Retrieval-Augmented Generation
HADR je to architektura, která kombinuje dvě odlišné fáze: vyhledávání (vyhledávání) relevantních dokumentů ze znalostní báze je generace (generace) odpověď na základě těchto dokumentů. Termín zavedli vědci v roce 2020 od Meta AI v článku „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks“.
Myšlenka je jednoduchá, ale účinná: než požádáte model, aby vygeneroval odpověď, vyhledejte dokumenty, které se nejvíce týkají otázky uživatele, a vložte je do výzvy jako další kontext. Modelka si už nemusí vše „pamatovat“, musí jen uvažovat na poskytnutých informacích.
LLM TRADIZIONALE:
Domanda utente --> [LLM] --> Risposta (basata solo su training data)
^-- Rischio allucinazione alto
RAG:
Domanda utente --> [Retrieval] --> Documenti rilevanti
|
v
Domanda + Documenti --> [LLM] --> Risposta (basata su dati reali)
^-- Rischio allucinazione basso
Praktická analogie
Představte si RAG jako jeden student při zkoušce s otevřenou knihou. Tradiční LLM je to student, který musí odpovědět zpaměti: ví hodně, ale umí se splést nebo si vymýšlet. S RAG si student může před odpovědí prohlédnout své poznámky a knihy. Odpověď bude přesnější, protože je založena na konkrétních zdrojích.
3. Kompletní architektura systému RAG
Systém RAG se skládá ze dvou hlavních potrubí: indexovací potrubí (prováděno offline, jednorázově nebo pravidelně) a kanál dotazů (prováděno v reálném čase s každou uživatelskou otázkou).
3.1 Indexovací kanál (offline)
Tato fáze připravuje podklady pro výzkum. Postup je následující:
[Documenti Sorgente]
|
v
[1. Document Loader] -- Carica PDF, HTML, Markdown, CSV, database
|
v
[2. Text Splitter] --- Divide in chunk di dimensione gestibile
|
v
[3. Embedding Model] - Trasforma ogni chunk in un vettore numerico
|
v
[4. Vector Store] ---- Salva i vettori in un database vettoriale
3.2 Průběh dotazů (online)
Tato fáze zpracovává požadavky uživatelů v reálném čase:
[Domanda Utente]
|
v
[1. Embedding Model] --- Stessa funzione usata nell'indicizzazione
|
v
[2. Similarity Search] - Cerca i chunk più simili nel vector store
|
v
[3. Context Assembly] -- Assembla i chunk trovati in un contesto
|
v
[4. Prompt Template] --- "Rispondi alla domanda basandoti su: [contesto]"
|
v
[5. LLM Generation] --- Genera la risposta finale
|
v
[Risposta con Citazioni]
Dávejte pozor na konzistenci vložek
Je nezbytné jej používat stejný model vkládání oba ve fázi indexování než ve fázi dotazu. Pokud použijete různé modely, vektory nebudou srovnatelné a vyhledávání podobnosti nebude fungovat správně.
4. Vložení: Srdce RAG
The vložení jsou to číselné reprezentace (vektory) textu, které zachycují sémantický význam. Dvě věty s podobným významem budou mít "blízké" vektory v vícerozměrný prostor, i když používají úplně jiná slova.
Frase: "Il gatto dorme sul divano"
Embedding: [0.23, -0.45, 0.67, 0.12, -0.89, ...] // vettore a 1536 dimensioni
Frase: "Il felino riposa sul sofa"
Embedding: [0.22, -0.44, 0.68, 0.11, -0.88, ...] // vettore molto simile!
Frase: "Il prezzo dell'oro sale"
Embedding: [-0.56, 0.78, -0.12, 0.91, 0.34, ...] // vettore molto diverso
Oblíbené šablony pro vkládání
| Model | Rozměry | Poskytovatelé | Náklady |
|---|---|---|---|
text-embedding-3-small |
1536 | OpenAI | 0,02 $ / 1 milion tokenů |
text-embedding-3-large |
3072 | OpenAI | 0,13 $ / 1 milion tokenů |
voyage-3 |
1024 | Voyage AI | 0,06 $ / 1 milion tokenů |
all-MiniLM-L6-v2 |
384 | HuggingFace (zdarma) | Zdarma (vlastně hostované) |
nomic-embed-text |
768 | Ollama (místní) | Zdarma (místní) |
La kosinusová podobnost je nejběžnější metrikou pro porovnat vložení. Měří úhel mezi dvěma vektory: hodnota 1,0 označuje vektory identické, 0,0 znamená žádný vztah, -1,0 znamená opačné významy.
function cosineSimilarity(a: number[], b: number[]): number {
if (a.length !== b.length) {
throw new Error('I vettori devono avere la stessa lunghezza');
}
let dotProduct = 0;
let normA = 0;
let normB = 0;
for (let i = 0; i < a.length; i++) {
dotProduct += a[i] * b[i];
normA += a[i] * a[i];
normB += b[i] * b[i];
}
return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB));
}
// Esempio d'uso
const embedding1 = [0.23, -0.45, 0.67, 0.12];
const embedding2 = [0.22, -0.44, 0.68, 0.11];
const similarity = cosineSimilarity(embedding1, embedding2);
console.log(similarity); // ~0.999 - molto simili!
5. Strategie trhání
Il trhání je proces rozdělování dokumentů na fragmenty (kus) zvládnutelné velikosti. Tato fáze je kritická: příliš velké kousky se rozptýlí to znamená, že kousky, které jsou příliš malé, ztrácejí kontext.
Klíčové parametry
- Velikost kousku: Maximální velikost každého fragmentu (ve znacích nebo tokenech). Obvykle 500-2000 znaků
- Překrytí částí: Překrytí mezi po sobě jdoucími bloky (10–20 % velikosti bloku). Vyhněte se řezání konceptů napůl
- Oddělovače: Body, ve kterých je lepší řezání (odstavce, věty, nadpisy)
FIXED SIZE CHUNKING:
Testo: "AAAA|BBBB|CCCC|DDDD" (ogni | = taglio ogni N caratteri)
Pro: Semplice e veloce
Contro: Può tagliare a meta frasi e concetti
RECURSIVE CHARACTER SPLITTING:
Testo diviso per: "\n\n" -> "\n" -> "." -> " " -> ""
Pro: Rispetta la struttura del testo
Contro: Chunk di dimensioni variabili
SEMANTIC CHUNKING:
Usa embeddings per trovare i "punti di rottura" semantici
Pro: Chunk coerenti semanticamente
Contro: Più lento e costoso (richiede embeddings)
DOCUMENT-AWARE CHUNKING:
Rispetta la struttura del documento (titoli, sezioni, tabelle)
Pro: Mantiene il contesto strutturale
Contro: Richiede parsing specifico per formato
Documento originale (600 caratteri):
"Angular è un framework TypeScript per applicazioni web.
Supporta il rendering lato server (SSR) per migliorare
le performance. I componenti standalone eliminano la
necessità di NgModule. I Signals offrono reattività
fine-grained senza Zone.js."
Con chunk_size=200, overlap=50:
Chunk 1: "Angular è un framework TypeScript per applicazioni web.
Supporta il rendering lato server (SSR) per migliorare
le performance."
Chunk 2: "per migliorare le performance. I componenti standalone
eliminano la necessità di NgModule."
Chunk 3: "eliminano la necessità di NgModule. I Signals offrono
reattività fine-grained senza Zone.js."
Časté chyby v Chunkingu
- Příliš velké bloky (>4000 tokenů): Model může ignorovat části kontextu nebo překročit limit tokenů
- Bloky jsou příliš malé (<100 tokenů): Ztráta kontextu, roztříštěné odpovědi
- Nulové překrytí: Koncepty rozpůlené, zotavení neúplné
- Ignorovat metadata: Ztráta informací, jako je název, autor, datum dokumentu
6. RAG vs jemné doladění: Kdy použít co
Jednou z nejčastějších otázek je: „Mám použít RAG nebo model doladit?“. Odpověď závisí na typu znalostí, které chcete přidat, a na tom, jak budou použity.
RAG vs Fine-Tuning – podrobné srovnání
| čekám | HADR | Jemné doladění |
|---|---|---|
| Typ znalostí | Konkrétní fakta, data, dokumenty | Styl, formát, chování |
| Aktualizovat | Okamžitě (aktualizace dokumentů) | Vyžaduje rekvalifikaci |
| Počáteční náklady | Nízká (infrastruktura + vložení) | Vysoká (GPU, označená data, čas) |
| Cena za dotaz | Střední (načítání + generování) | Nízká (pouze generace) |
| Sledovatelnost | Vysoká (můžete uvést zdroje) | Žádné (integrované znalosti) |
| Halucinace | Sníženo (skutečná data v kontextu) | Možné (naučené znalosti) |
| Škálovatelnost dat | Miliony dokumentů | Omezeno tréninkovou sadou |
| Složitost | Média (potrubí + vektorová DB) | Vysoká (školení, hodnocení, nasazení) |
Praktické pravidlo
USA HADR když chcete, aby model "znal" konkrétní informace (dokumenty, často kladené dotazy, manuály). USA dolaďování když chcete model "chovat" určitým způsobem (tón, formát, styl odezvy). v mnoha případech kombinace těchto dvou přístupů poskytuje nejlepší výsledky.
7. Skutečné případy použití RAG
RAG není jen teorie: je základem mnoha produktů, které používáme každý den. Zde jsou nejčastější případy použití a jak je RAG umožňuje.
7.1 Firemní chatboti
Nejoblíbenější případ použití. Chatbot, který odpovídá na otázky zákazníků na základě na skutečné dokumentaci společnosti: manuály, často kladené dotazy, vyřešené vstupenky, interní zásady.
// Pseudocodice di un chatbot RAG
async function handleUserQuery(query: string): Promise<string> {
// 1. Cerca documenti rilevanti
const relevantDocs = await vectorStore.similaritySearch(query, 5);
// 2. Costruisci il contesto
const context = relevantDocs
.map(doc => `[Fonte: ${doc.metadata.source}]\n${doc.pageContent}`)
.join('\n\n');
// 3. Genera la risposta con contesto
const response = await llm.invoke(`
Sei un assistente del supporto clienti.
Rispondi SOLO basandoti sulle informazioni fornite.
Se non trovi la risposta nei documenti, dillo esplicitamente.
DOCUMENTI DI RIFERIMENTO:
${context}
DOMANDA DEL CLIENTE:
${query}
RISPOSTA:
`);
return response;
}
7.2 Sémantické vyhledávání
Na rozdíl od tradičního vyhledávání založeného na klíčových slovech sémantické vyhledávání pomocí RAG zahrnuje význam dotazu. "Jak obnovit heslo" najde výsledky i když je v dokumentu uvedeno „postup pro obnovu pověření“.
7.3 Otázky a odpovědi týkající se dokumentů
Umožňuje uživatelům klást otázky v přirozeném jazyce týkající se velkých sbírek dokumentů: právní smlouvy, technická dokumentace, vědecké práce, interní znalostní báze.
7.4 Asistent kódu
Asistent kódu, který zná vaši konkrétní kódovou základnu. Indexujte zdrojový kód, Dokumentace API, komentáře a testy poskytující kontextové návrhy.
Porovnání případů použití
| Use Case | Zdroj dat | Frekvence aktualizace | Složitost |
|---|---|---|---|
| Podpora chatbotů | FAQ, manuály, lístky | Týdně | Průměrný |
| Sémantické vyhledávání | Katalog produktů, články | Denní | Nízký |
| Dokumenty otázek a odpovědí | PDF, smlouvy, zprávy | Na požádání | Průměrný |
| Asistent kódu | Zdrojový kód, dokumenty API | Při každém závazku | Vysoký |
8. Anatomie kompletního RAG potrubí
Podívejme se podrobně na každou komponentu potrubí s technologickými možnostmi kterým budete čelit při realizaci.
+------------------+--------------------------------------------+
| Componente | Opzioni Tecnologiche |
+------------------+--------------------------------------------+
| Document Loader | LangChain loaders, Unstructured, custom |
| Text Splitter | RecursiveCharacter, Semantic, Markdown |
| Embedding Model | OpenAI, Voyage, HuggingFace, Ollama |
| Vector Store | Pinecone, Chroma, Weaviate, pgvector |
| Retriever | Similarity, MMR, Self-Query, Ensemble |
| Prompt Template | LangChain templates, custom |
| LLM | GPT-4, Claude, Llama, Mistral |
| Post-processing | Citation extraction, confidence scoring |
+------------------+--------------------------------------------+
8.1 Zavaděče dokumentů
Nakladače dokumentů extrahují text z různých zdrojů. Kvalita těžby přímo ovlivňuje kvalitu odpovědí.
Formato | Loader Consigliato | Note
-----------------+---------------------------+---------------------------
PDF | PDFLoader, PyPDFLoader | Attenzione a tabelle/immagini
HTML/Web | CheerioWebBaseLoader | Rimuove tag, estrae testo
Markdown | MarkdownTextSplitter | Preserva la struttura
CSV/Excel | CSVLoader | Una riga = un documento
JSON | JSONLoader | Configura il percorso dati
Database SQL | Custom loader | Query -> documenti
Confluence/Notion| API-based loader | Richiede autenticazione
Codice sorgente | TextLoader + filtri | Splitta per funzione/classe
8.2 Retriever: Beyond Similarity Search
Retrívr nenajde jen ty nejpodobnější kusy. Existují pokročilé strategie ke zlepšení kvality regenerace.
Strategie vyhledávání
- Hledání podobnosti: K bloků s nejvyšším skóre podobnosti. Jednoduché, ale účinné
- MMR (maximální okrajová relevance): Vyvážit relevanci a rozmanitost. Vyhněte se kouskům, které jsou si navzájem příliš podobné
- Vlastní dotaz: Model extrahuje filtry z otázky (např. „Dokumenty 2024“ filtry podle data)
- Soubor: Zkombinujte výsledky z více retrieverů (např. klíčová slova + sémantika) pro lepší pokrytí
- Nadřazený dokument: Načte relevantní blok, ale vrátí nadřazený dokument pro úplný kontext
9. Omezení RAG a kdy je NEPOUŽÍVAT
RAG není kouzelné řešení. Jako každá architektura má svá omezení, kterých si musíte být vědomi před jeho přijetím.
Když RAG NENÍ tou správnou volbou
- Složitá úvaha: RAG poskytuje fakta, nikoli úvahy. Pro vícekrokovou analýzu nebo složité logické dedukce musí mít model své vlastní schopnosti
- Strukturovaná data: Pokud potřebujete agregace SQL, výpočty nebo spojení mezi tabulkami, použijte relační databázi, nikoli RAG
- Ultra rychlé odezvy v reálném čase: Průběh vyhledávání zvyšuje latenci (100–500 ms). Pokud potřebujete odpovědi do 50 ms, zvažte ukládání do mezipaměti
- Znalostní báze je příliš malá: S malým počtem dokumentů (<10 stránek) se vám vše vejde do výzvy, aniž byste museli vyhledávat
- Velmi dynamická data: Pokud se data mění každou sekundu (např. ceny na burze), RAG se neaktualizuje dostatečně rychle
Běžné problémy a řešení
| Problém | Příčina | Řešení |
|---|---|---|
| Irelevantní odpovědi | Chunking příliš velký | Zmenšit velikost bloku, zvětšit překrytí |
| Příliš často odpovídá „nevím“. | Načítání je příliš omezující | Zvyšte k (počet výsledků), použijte MMR |
| Přetrvávající halucinace | Nedostatečný nebo nejednoznačný kontext | Vylepšete výzvu, přidejte explicitní pokyny |
| Vysoká latence | Příliš mnoho částí v kontextu | Snižte k, použijte re-ranking |
| Vysoké náklady | Příliš mnoho tokenů na dotaz | Komprimujte kousky, použijte levnější modely |
10. Metriky hodnocení pro RAG
Abyste věděli, zda váš systém RAG funguje dobře, musíte jej změřit. Zde jsou hlavní metriky.
RAG metriky
| Metrický | Co měří | Cíl |
|---|---|---|
| Kontextová relevance | Jsou získané dokumenty relevantní pro aplikaci? | > 0,8 |
| Věrnost | Je odpověď založena na poskytnutých dokumentech? | > 0,9 |
| Odpověď Relevance | Je odpověď relevantní k otázce? | > 0,85 |
| Latence | Celkový čas na odpověď | < 3 sekundy |
| Míra halucinací | Procento nároků nepodložených dokumenty | < 5 % |
Tool di Valutazione:
- RAGAS (Retrieval Augmented Generation Assessment)
- LangSmith (by LangChain) - tracing e valutazione
- Phoenix (by Arize) - osservabilità LLM
- DeepEval - framework di testing per LLM
- TruLens - valutazione feedback-driven
Metriche Composite:
RAG Score = (Context Relevance + Faithfulness + Answer Relevance) / 3
Další kroky
V tomto článku jste získali solidní znalosti o RAG: co to je, jak to funguje, klíčové komponenty architektury a kdy ji použít (či nepoužít). Pochopil jsi roli základy vkládání, rozdělovací strategie a vyhodnocovací metriky.
Nel další článek přejdeme od teorie k praxi: budeme realizovat pomocí kompletního systému RAG TypeScript a LangChain.jss vektorem skutečný obchod a konverzační rozhraní s pamětí.
Další zdroje
- Originální RAG papír: „Generace rozšířená o získávání pro znalostně náročné úkoly NLP“ (Lewis et al., 2020)
- Dokumenty LangChain.js: Oficiální dokumentace pro implementaci v TypeScriptu
- Kuchařka OpenAI: Praktické příklady RAG s OpenAI API
- Výukové centrum šiška: Průvodce vektorovými databázemi a vkládáním
- RAGAS: Open-source framework pro hodnocení RAG systémů