RAG: Retrieval-Augmented Generation Explained
I Velký jazykový model (LLM) představují jednu z technologických novinek nejrušivější za poslední roky: GPT-4, Claude, Gemini a Llama umí psát kód, shrnout dokumenty, odpovědět na složité otázky a dokonce uvažovat o abstraktních problémech. Přesto trpí strukturální vadou, která drasticky omezuje jejich použitelnost profesní souvislosti: halucinace.
Když LLM nezná odpověď, neřeknou „nevím“. Místo toho vygenerujte věrohodný text ale zcela nepravdivé, stejně sebevědomě jako předkládá ověřitelná fakta. V obchodním, právním nebo lékařském prostředí je toto chování nepřijatelné. Řešení účinnější a zralejší k tomuto problému se nazývá Retrieval-Augmented Generation (RAG).
V tomto prvním článku seriálu AI Engineering a Advanced RAG, odejdeme od základů: co je RAG, jak funguje, proč řeší problém halucinací a jak vybudovat fungující RAG systém od nuly. Až skončíte, budete mít pochopení solidní znalost celé architektury a budete připraveni ponořit se hlouběji do každé jednotlivé komponenty v následujících článcích.
Přehled série
| # | Položka | Soustředit |
|---|---|---|
| 1 | Jste zde - RAG Explained | Základy a kompletní architektura |
| 2 | Vložení a sémantické vyhledávání | Jak se texty stávají vektory |
| 3 | Vektorové databáze v hloubce | Ukládání, indexování, vyhledávání podobností |
| 4 | RAG s LangChainem a Pythonem | Praktická end-to-end implementace |
| 5 | Hybridní vyhledávání a reranking | Hybridní klíčové slovo + sémantické vyhledávání |
| 6 | Kontextové okno a rychlé inženýrství | Optimalizujte kontext pro LLM |
| 7 | RAG ve výrobě | Škálování, monitorování, vyhodnocování |
| 8 | Znalostní grafy a RAG | Znalostní grafy + vyhledávání |
| 9 | Multiagentní systémy | Kolaborativní agenti AI |
| 10 | Budoucnost RAG | Trendy, výzkum a další kroky |
Co se naučíte
- Co je RAG a jaký zásadní problém pro LLM řeší
- Kompletní architektura: od přípravy dokumentu po generování odpovědi
- Jak fungují vkládání, vektorová úložiště a vyhledávání podobností
- Chunking strategie a jejich kompromisy
- Jak vytvořit minimálně fungující RAG systém s Pythonem
- Rozdíly mezi Naive RAG a Advanced RAG
- Kdy použít RAG versus jemné doladění versus rychlé inženýrství
1. Problém halucinací v LLM
Abychom pochopili, proč je RAG nezbytný, musíme nejprve porozumět problému, který řeší. Velké jazykové modely jsou v podstatě pravděpodobnostní modely jazyka: vzhledem k vstupnímu textu předpovídají nejpravděpodobnější sekvenci tokenů jako pokračování. Tato architektura, založená na mechanismu Pozor z Transformers, vyrábí mimořádné výsledky, ale má své vnitřní omezení: model „neví“ nic v lidském smyslu termínu. Vytvářejte statisticky věrohodný text na základě naučených vzorů školení.
Tři strukturální problémy LLM
| Problém | Popis | Praktický dopad |
|---|---|---|
| Hranice znalostí | Znalosti jsou zmrazeny v den školení | Žádné informace o nedávných událostech ani vlastnická data |
| Halucinace | Vytvářejte věrohodné, ale zcela vymyšlené odpovědi | Nepravdivé informace prezentované s vysokou spolehlivostí |
| Žádné uvozovky | Nemůže uvést zdroj svých prohlášení | Nelze ověřit správnost odpovědí |
| Žádná soukromá data | Nezná interní dokumentaci firmy | Nepoužitelné pro konkrétní případy použití bez kontextu |
Halucinace nejsou jednorázovou chybou: jsou přímým důsledkem architektury. Když model nemá dostatek informací k odpovědi, nevrací chybu. Místo toho generuje nejpravděpodobnější pokračování textu, které může být úplně vynalezl. Model byl vycvičen tak, aby vytvářel plynulý, souvislý text, nikoli aby být fakticky přesný.
Konkrétní příklady halucinací
Abychom pochopili závažnost problému, uvažujme skutečné scénáře halucinací mít významné důsledky:
- Právní rozsah: LLM může citovat neexistující rozhodnutí nebo nikdy nepřijaté zákony s důvěryhodnými, ale vymyšlenými čísly položek
- Lékařský obor: Může naznačovat nesprávné dávkování léků nebo nezdokumentované lékové interakce
- Technická dokumentace: Může popisovat rozhraní API s parametry, které neexistují, nebo funkcemi, které nebyly nikdy implementovány
- Zákaznická podpora: Mohou vymýšlet firemní zásady, postupy vrácení nebo neexistující záruky
Statistiky potvrzují rozsah problému: míra halucinací se liší významně podle domény, se specializovanými obory, jako je medicína a právo, které zaznamenávají sazby 10-20 % i u nejpokročilejších modelů. RAG představuje techniku nejúčinnější při zmírňování tohoto problému, s dokumentovaným snížením až o 71 %.
2. Co je RAG: Definice a původ
Retrieval-Augmented Generation (RAG) je to architektonické paradigma, že kombinuje systém vyhledávání informací (obnovení dokumentu) pomocí šablony generativní (LLM) k vytváření odpovědí založených na skutečných datech. Koncept byl formalizován v roce 2020 Patrick Lewis a kolegové z Meta AI v základním článku „Generace rozšířeného získávání pro znalostně náročné úkoly NLP“.
Klíčový poznatek je jednoduchý: místo toho, abychom modelku požádali, aby si vše "pamatovala". informace z jeho školení, poskytujeme mu příslušné dokumenty v době generace. Tento proces se nazývá základy: generace kotvy ke konkrétním a ověřitelným zdrojům.
LLM TRADIZIONALE:
Domanda utente ──────────────────> [LLM] ──> Risposta
|
Basata SOLO su training data
Rischio allucinazione: ALTO
RAG (Retrieval-Augmented Generation):
Domanda utente ──> [RETRIEVAL] ──> Documenti rilevanti
| |
| v
└───────> [LLM + Contesto] ──> Risposta con citazioni
|
Basata su DATI REALI recuperati
Rischio allucinazione: BASSO
Analogie: Zkouška z otevřené knihy
Představte si univerzitní zkoušku. Tradiční LLM je jako student, který musí odpovídat nazpaměť: ví hodně, ale může se splést nebo vymýšlet detaily. RAG je jako a zkouška otevřená kniha: student může nahlížet do svých poznámek a knih před odpovědí. Odpověď bude přesnější a ověřitelnější, protože je založena na konkrétních zdrojích.
Koncept uzemnění je zásadní: každý výrok v generované odpovědi může být vysledovat zpět ke konkrétnímu dokumentu ve znalostní bázi. To znamená, že:
- Odpovědi jsou ověřitelný: Můžete zkontrolovat zdrojový dokument
- Odpovědi jsou aktualizovatelné: Aktualizací dokumentů se odpovědi automaticky změní
- Odpovědi jsou ovladatelný: vy rozhodujete, které dokumenty může systém nahlížet
- Odpovědi jsou dohledatelné: Můžete uvést citace s odkazem na zdroj
3. Jak RAG funguje: Kompletní potrubí
Systém RAG se skládá ze dvou makrofází: indexovací potrubí, která připravuje dokumenty jednorázově (nebo periodicky) a kanál dotazů, který zpracovává uživatelské dotazy v reálném čase.
3.1 Indexovací kanál (fáze offline)
Fáze indexování transformuje nezpracované dokumenty do optimalizované struktury pro sémantické vyhledávání. Skládá se ze čtyř po sobě jdoucích kroků:
[Documenti Sorgente]
| PDF, HTML, Markdown, CSV, database, API, email...
v
[1. DOCUMENT LOADING]
| Estrazione del testo grezzo dai formati sorgente
| Preservazione dei metadati (autore, data, titolo)
v
[2. CHUNKING (Text Splitting)]
| Divisione in frammenti di dimensione gestibile
| Strategie: fixed-size, semantic, recursive
| Overlap tra chunk per preservare contesto
v
[3. EMBEDDING]
| Trasformazione di ogni chunk in un vettore numerico
| Modelli: OpenAI, Sentence Transformers, Cohere
| Dimensioni tipiche: 384, 768, 1536, 3072
v
[4. VECTOR STORE]
| Salvataggio dei vettori in un database specializzato
| Indexing per ricerca veloce (HNSW, IVF)
| ChromaDB, Pinecone, Weaviate, Milvus, Qdrant
v
[Knowledge Base Pronta per le Query]
3.2 Průběh dotazů (fáze online)
Když uživatel položí otázku, kanál dotazů se spustí a vyhledá nejrelevantnější dokumenty a vygenerujte dobře podloženou odpověď:
[Domanda dell'Utente]
| "Come configuro l'autenticazione OAuth nella nostra app?"
v
[1. QUERY EMBEDDING]
| La domanda viene trasformata in vettore
| Stesso modello usato nell'indicizzazione!
v
[2. SIMILARITY SEARCH]
| Ricerca dei chunk più simili nel vector store
| Metriche: cosine similarity, L2, dot product
| Restituisce i top-k risultati (tipicamente k=3..10)
v
[3. CONTEXT ASSEMBLY]
| I chunk recuperati vengono assemblati in un contesto
| Ordinamento per rilevanza, deduplicazione
v
[4. PROMPT CONSTRUCTION]
| Costruzione del prompt con contesto + domanda
| Template: "Basandoti sui seguenti documenti, rispondi..."
v
[5. LLM GENERATION]
| Il modello genera la risposta basandosi sul contesto
| Può includere citazioni ai documenti sorgente
v
[Risposta Fondata + Citazioni]
Základní pravidlo: Konzistence vložení
E' povinný použijte stejný model vkládání v obou indexování než ve fázi dotazu. Různé modely vytvářejí vektorové prostory nekompatibilní: vektory generované modelem nejsou srovnatelné s těmi jiného. Změna modelu vkládání vyžaduje kompletní opětovné indexování všech dokumentů.
4. Zpracování dokumentu: Dělení a příprava
Il trhání je to jedna z nejkritičtějších fází celého ropovodu RAG. Kvalita výsledků do značné míry závisí na tom, jak jsou dokumenty rozděleny. Příliš velké bloky rozmělňují sémantický signál a plýtvají místem v kontextovém okně společnosti LLM. Příliš malé kousky ztrácejí kontext potřebný k tomu, aby byly srozumitelné.
4.1 Rozdělení pevné velikosti
Nejjednodušší strategie: rozdělte text do bloků pevné velikosti (např. 500 tokenů) s volitelným překrytím mezi po sobě jdoucími bloky.
Parametry Chunking s pevnou velikostí
| Parametr | Popis | Typická hodnota |
|---|---|---|
| chunk_size | Maximální velikost každého bloku v tokenech nebo znacích | 300-500 žetonů |
| chunk_overlap | Překrytí mezi po sobě jdoucími bloky | 10–20 % velikosti_chunk_size |
| oddělovač | Znak/řetězec používaný k rozdělení | "\n\n", "\n", " " |
Documento originale (1500 token):
"Lorem ipsum dolor sit amet... [1500 token di testo]"
Con chunk_size=500 e overlap=50:
Chunk 1: token 1-500 ────────────┐
Chunk 2: token 451-950 ──┐ overlap │
Chunk 3: token 901-1400 ──┘ │
Chunk 4: token 1351-1500 │
────────────┘
L'overlap garantisce che il contesto ai bordi non venga perso.
4.2 Rekurzivní dělení znaků
Propracovanější strategie, která se snaží rozdělovat při respektování struktury dokumentu. Použijte hierarchii oddělovačů: nejprve zkuste dělení podle odstavců ("\n\n"), pak po řádcích ("\n"), poté po větách (". "), nakonec po slovech (" "). To zachovává sémantický kontext lépe než pevná velikost.
4.3 Sémantické rozdělení
Nejpokročilejší strategie: pomocí samotných vložení určete, kde se má rozdělit. Vypočítejte podobnost mezi po sobě jdoucími větami a při podobnosti vytvořte nový blok klesne pod práh, což naznačuje změnu tématu. Produkuje kusy velikosti variabilní, ale sémanticky koherentní.
Srovnání strategií chunkingu
| Strategie | kvalitní | Složitost | Kdy jej použít |
|---|---|---|---|
| Pevná velikost | Základní | Minimální | Prototypování, homogenní dokumenty |
| Rekurzivní | Dobrý | Nízký | Univerzální, strukturované dokumenty |
| Sémantika | Vynikající | Vysoký | Požadovaná vysoká kvalita, heterogenní dokumenty |
Význam metadat
Každý kus by s sebou měl nést bohy metadata: název dokumentu, autor, datum, sekce, stránka. Tato metadata jsou kritická pro filtrování během vyhledávání a generovat přesné citace ve vaší odpovědi. Kousek bez metadata jsou jako odstavec bez kontextu.
5. Vložení: Transformace textu do vektorů
The vložení jsou matematickým srdcem RAG. Vložení je a číselná reprezentace (vektor desetinných čísel), která zachycuje sémantický význam textu. Dvě věty s podobným významem budou mít "blízké" vektory ve vícerozměrném prostoru, bez ohledu na použitá slova.
INPUT: Frase di testo
OUTPUT: Vettore di numeri decimali (es. 1536 dimensioni)
Esempio:
"Il gatto dorme sul divano" --> [0.23, -0.45, 0.67, 0.12, -0.89, ...]
"Il felino riposa sul sofa" --> [0.22, -0.44, 0.68, 0.11, -0.88, ...]
^^ Vettori molto SIMILI (stesso significato)
"Il prezzo dell'oro sale" --> [-0.56, 0.78, -0.12, 0.91, 0.34, ...]
^^ Vettore molto DIVERSO (significato diverso)
Model vkládání je neuronová síť trénovaná na obrovské množství textu naučit se sémantické vztahy mezi slovy, větami a pojmy. Prostě nevyrábí syntaktická reprezentace (jako bag-of-words nebo TF-IDF), ale zachycuje význam hloubka textu.
Hlavní modely vkládání (2025–2026)
| Model | Rozměry | Poskytovatelé | Orientační cena |
|---|---|---|---|
text-embedding-3-small |
1536 | OpenAI | ~0,02 $ / 1 milion tokenů |
text-embedding-3-large |
3072 | OpenAI | ~0,13 $ / 1 milion tokenů |
voyage-3-large |
1024 | Voyage AI | ~0,06 $ / 1 milion tokenů |
all-MiniLM-L6-v2 |
384 | Objímání tváře | Zdarma (vlastně hostované) |
nomic-embed-text |
768 | Ollama (místní) | Zdarma (místní) |
embed-v4 |
1024 | Cohere | ~0,10 $ / 1 milion tokenů |
Výběr modelu vložení závisí na případu použití: největší modely (3072 rozměry) nabízejí bohatší zastoupení, ale stojí více úložiště a výpočet. Pro mnoho případů použití jsou k dispozici modely velikosti 768-1536 skvělý kompromis mezi kvalitou a cenou.
6. Vector Store: Databáze pro vkládání
Un vektorový obchod (neboli vektorová databáze) je specializovaná databáze pro ukládat, indexovat a prohledávat vysokorozměrné vektory. Na rozdíl od tradiční databáze, které hledají přesné shody (SQL WHERE), vektorové úložiště vyhledat více dopravců podobný k tomu dotazu.
6.1 Metriky podobnosti
Vyhledávání obchodů s vektory je založeno na metrikách vzdálenosti/podobnosti mezi vektory. Tři nejběžnější metriky jsou:
Porovnání metrik podobnosti
| Metrický | Rozsah | Popis | Kdy jej použít |
|---|---|---|---|
| Kosinová podobnost | [-1, 1] | Měří úhel mezi dvěma vektory, ignoruje velikost | Výchozí pro většinu případů (doporučeno) |
| Euklidovská vzdálenost (L2) | [0, +inf) | Geometrická vzdálenost v prostoru, citlivá na velikost | Když je velikost vektorů významná |
| Dot Product | (-inf, +inf) | Skalární součin, kombinuje směr a velikost | Již normalizované vektory, Maximum Inner Product Search |
6.2 Přehled vektorových databází
Trh s vektorovými databázemi explodoval s přijetím RAG. Zde je přehled z hlavních dostupných nástrojů:
Porovnání vektorové databáze
| Databáze | Typ | Jazyk | Ideální pro |
|---|---|---|---|
| ChromaDB | Embedded / Server | Krajta | Prototypování, místní vývoj, malé datové sady |
| Borová šiška | Spravováno cloudem | Vícejazyčné | Výroba, automatické škálování, nulové operace |
| Weaviate | Vlastní hostování / Cloud | Go | Hybridní vyhledávání, multi-tenancy, GraphQL |
| Milvus | Vlastní hostování / Cloud | Přejít / C++ | Velké objemy, vysoký výkon, podnik |
| Qdrant | Vlastní hostování / Cloud | Rez | Výkon, pokročilé filtrování, REST API |
| pgvector | Rozšíření PostgreSQL | C | Stávající zásobník PostgreSQL, relační + vektorová data |
| FAISS | Knihovna v paměti | C++ / Python | Výzkum, benchmark, maximální optimalizace |
Chcete-li začít, ChromaDB je to nejjednodušší volba: je instalován s pip, funguje v paměti nebo trvale na disku a nativně se integruje s LangChain. Pro výrobu jsou mezi možnostmi Pinecone (spravované) a Qdrant (samohoštěné). nejoblíbenější.
7. Vyhledávání: Vyhledávání relevantních dokumentů
Fáze vyhledávání je okamžik, kdy přichází uživatelova otázka transformovány do vektoru a porovnány se všemi vektory ve vektorovém úložišti, aby byly nalezeny nejrelevantnější kousky. Tento proces probíhá v milisekundách i u milionů indexované dokumenty díky přibližným indexovacím algoritmům, jako je HNSW (Hierarchický splavný malý svět).
Query: "Come configuro OAuth nella nostra app?"
|
v
[1] Embedding della query ──> [0.34, -0.21, 0.56, ...]
|
v
[2] Similarity Search nel Vector Store
| Confronta il vettore della query con tutti i vettori salvati
| Usa cosine similarity come metrica
|
v
[3] Top-K Results (es. k=5)
|
| Score: 0.92 - "Configurazione OAuth 2.0 per applicazioni web..."
| Score: 0.87 - "Guida ai flussi di autenticazione OAuth..."
| Score: 0.83 - "Impostazione dei redirect URI per OAuth..."
| Score: 0.76 - "Confronto tra OAuth e SAML per SSO..."
| Score: 0.71 - "Sicurezza delle API con token JWT..."
|
v
[4] Filtering e Reranking (opzionale)
| Filtra per metadati (data, categoria, fonte)
| Reranking con modello cross-encoder
|
v
[Chunk Rilevanti Pronti per il Prompt]
7.1 Parametr Top-K
Parametr top-k určuje, kolik kusů se obnoví. Výběr je to kompromis:
- K příliš nízké (1-2): Riziko chybějících relevantních informací
- K příliš vysoké (20+): Příliš mnoho hluku v kontextu, plýtvání tokeny, riziko záměny modelu
- Optimální K (3-7): Dobrá rovnováha mezi pokrytím a přesností
7.2 Hodnocení relevance
Každý výsledek má a skóre relevance (skóre relevance). Kousky s nízkým skóre by měly být filtrovány, protože přidávají bezcenný šum. Společný práh je 0,7 pro kosinusovou podobnost: vše níže se zahodí. V praxi optimální práh závisí na doméně a musí být kalibrován experimentálně.
8. Generování: Budování odezvy pomocí LLM
Konečná fáze potrubí RAG: získané kusy jsou sestaveny do a strukturovaný kontext a vloží se do výzvy LLM spolu s příponou uživatelská otázka. Model generuje odpověď pouze na základě (nebo převážně) na poskytnutém kontextu.
8.1 Šablona výzvy
Dobrá šablona výzvy RAG by měla dát modelu pokyn:
- Použití Sám informace z poskytnutého kontextu
- Přiznejte se, když v dokumentech nenajdete odpověď
- Kdykoli je to možné, citujte zdroje
- Nevymýšlejte si informace, které nejsou v kontextu
Sei un assistente tecnico. Rispondi alle domande SOLO basandoti
sul contesto fornito. Se la risposta non è presente nel contesto,
rispondi "Non ho trovato informazioni sufficienti nei documenti
disponibili."
CONTESTO:
---
{context}
---
DOMANDA: {question}
ISTRUZIONI:
1. Rispondi in modo chiaro e conciso
2. Cita il documento sorgente tra parentesi quadre [Fonte: nome_doc]
3. Se il contesto non contiene la risposta, dillo esplicitamente
4. Non inventare informazioni non presenti nel contesto
RISPOSTA:8.2 Sledování citací
Jednou z nejcennějších funkcí RAG je schopnost sledovat citace. Každý blok v kontextu může být označen identifikátorem (např. [DOC-1], [DOC-2]) a model je instruován, aby na tyto identifikátory odkazoval v odpovědi. Toto umožňuje uživateli ověřit každé prohlášení nahlédnutím do původního dokumentu.
Kontextové okno a limity
Množství kontextu, které můžete vložit, je omezeno kontextové okno modelu LLM. Pokud obnovené bloky překročí limit, budete muset vybrat pouze nejrelevantnější nebo je shrnout. Moderní modely jako GPT-4o (128K token) a Claude 3.5 (200 000 tokenů) mají velmi velká kontextová okna, ale i tak vkládají příliš mnoho kontextu irelevantní zhoršuje kvalitu odpovědí (tzv. problém „ztraceno uprostřed“).
9. Kompletní RAG architektura: Přehled
Nyní, když jsme se podívali na každou komponentu jednotlivě, pojďme sestavit architekturu kompletní s end-to-end systémem RAG:
FASE OFFLINE (Indicizzazione)
┌──────────────────────────────────────────────────────┐
│ │
│ [Documenti] ──> [Loader] ──> [Chunker] │
│ PDF, HTML Estrazione Divisione │
│ MD, CSV testo in frammenti │
│ │ │
│ v │
│ [Embedding Model] │
│ Testo ──> Vettore │
│ │ │
│ v │
│ [Vector Store] │
│ ChromaDB, Pinecone │
│ Weaviate, Qdrant │
│ │
└──────────────────────────────────────────────────────┘
FASE ONLINE (Query)
┌──────────────────────────────────────────────────────┐
│ │
│ [Domanda Utente] │
│ │ │
│ v │
│ [Query Embedding] ──> [Similarity Search] │
│ Stesso modello Top-K chunk │
│ dell'indicizzazione │ │
│ v │
│ [Context Assembly] │
│ Chunk + Metadati │
│ │ │
│ v │
│ [Prompt Template + Contesto + Domanda] │
│ │ │
│ v │
│ [LLM] │
│ GPT-4, Claude │
│ Llama, Gemini │
│ │ │
│ v │
│ [Risposta con Citazioni] │
│ │
└──────────────────────────────────────────────────────┘
Členové a odpovědnosti
| Komponent | Odpovědnost | Typické nástroje |
|---|---|---|
| Zavaděč dokumentů | Nahrajte dokumenty z různých zdrojů | Nakladače LangChain, nestrukturované, LlamaIndex |
| Rozdělovač textu | Rozdělte dokumenty na optimální části | RecursiveCharacterTextSplitter, SemanticChunker |
| Model vkládání | Transformace textu do sémantických vektorů | OpenAI Embeddings, Sentence Transformers, Cohere |
| Vektorový obchod | Ukládat a indexovat vektory | ChromaDB, Pinecone, Qdrant, pgvector |
| Retrívři | Vyhledejte nejrelevantnější kousky | Vyhledávání podobností, MMR, hybridní vyhledávání |
| LLM | Vygenerujte konečnou odpověď z kontextu | GPT-4o, Claude 3.5, Llama 3, Gemini Pro |
10. Praktický příklad: Minimální RAG s Pythonem
Pojďme vybudovat fungující RAG systém s minimálním potřebným kódem. Budeme používat LangChain jako orchestrační rámec, OpenAI pro vkládání a generování, např ChromaDB jako místní vektorový obchod.
10.1 Nastavení projektu
# Crea un ambiente virtuale
python -m venv rag-env
source rag-env/bin/activate # Linux/Mac
# Installa le dipendenze
pip install langchain langchain-openai langchain-community
pip install chromadb
pip install pypdf # Per caricare PDF10.2 Indexovací potrubí
import os
from langchain_community.document_loaders import (
PyPDFLoader,
TextLoader,
DirectoryLoader
)
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
# Configura la API key
os.environ["OPENAI_API_KEY"] = "sk-..."
# 1. DOCUMENT LOADING
# Carica tutti i PDF da una cartella
loader = DirectoryLoader(
"./documenti/",
glob="**/*.pdf",
loader_cls=PyPDFLoader
)
documents = loader.load()
print(f"Caricati {len(documents)} documenti")
# 2. CHUNKING
# Divisione ricorsiva con overlap
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # 500 caratteri per chunk
chunk_overlap=50, # 50 caratteri di overlap
length_function=len,
separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = text_splitter.split_documents(documents)
print(f"Creati {len(chunks)} chunk")
# 3. EMBEDDING + 4. VECTOR STORE
# Crea gli embeddings e salvali in ChromaDB
embedding_model = OpenAIEmbeddings(
model="text-embedding-3-small"
)
vectorstore = Chroma.from_documents(
documents=chunks,
embedding=embedding_model,
persist_directory="./chroma_db",
collection_name="documenti_aziendali"
)
print("Vector store creato e salvato su disco")10.3 Kanál dotazů
import os
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate
os.environ["OPENAI_API_KEY"] = "sk-..."
# Carica il vector store esistente
embedding_model = OpenAIEmbeddings(
model="text-embedding-3-small"
)
vectorstore = Chroma(
persist_directory="./chroma_db",
embedding_function=embedding_model,
collection_name="documenti_aziendali"
)
# Configura il retriever
retriever = vectorstore.as_retriever(
search_type="similarity",
search_kwargs={"k": 5} # Recupera i 5 chunk più simili
)
# Definisci il prompt template
prompt_template = PromptTemplate(
template="""Sei un assistente tecnico esperto.
Rispondi alla domanda basandoti SOLO sul contesto fornito.
Se non trovi la risposta nel contesto, dillo esplicitamente.
CONTESTO:
{context}
DOMANDA: {question}
RISPOSTA (con citazioni ai documenti fonte):""",
input_variables=["context", "question"]
)
# Crea la chain RAG
llm = ChatOpenAI(
model="gpt-4o",
temperature=0 # Deterministic per risposte fattuali
)
rag_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff", # Inserisci tutti i chunk nel prompt
retriever=retriever,
return_source_documents=True,
chain_type_kwargs={
"prompt": prompt_template
}
)
# Esegui una query
result = rag_chain.invoke(
{"query": "Come configuro l'autenticazione OAuth?"}
)
# Stampa la risposta
print("RISPOSTA:")
print(result["result"])
print("\nFONTI:")
for doc in result["source_documents"]:
print(f" - {doc.metadata.get('source', 'N/A')}"
f" (pagina {doc.metadata.get('page', 'N/A')})")Očekávaný výstup
RISPOSTA:
Per configurare l'autenticazione OAuth nella nostra applicazione,
segui questi passaggi:
1. Registra l'app nel provider OAuth (Google, GitHub, etc.)
2. Configura i redirect URI nel file config.yaml [Fonte: guida-oauth.pdf]
3. Implementa il flusso Authorization Code [Fonte: architettura-auth.pdf]
...
FONTI:
- documenti/guida-oauth.pdf (pagina 12)
- documenti/architettura-auth.pdf (pagina 5)
- documenti/faq-sicurezza.pdf (pagina 3)
10.4 Struktura projektu
rag-project/
├── documenti/ # I tuoi documenti sorgente
│ ├── guida-oauth.pdf
│ ├── architettura.pdf
│ └── faq.pdf
├── chroma_db/ # Vector store persistente (generato)
├── indexing.py # Script di indicizzazione
├── query.py # Script di query
├── requirements.txt # Dipendenze
└── .env # API keys (mai committare!)
11. Naivní RAG versus Advanced RAG
Systém, který jsme doposud vybudovali, je tím, čemu komunita říká Naivní RAG: přímočará a jednoduchá implementace, která překvapivě dobře funguje pro mnoho případů použití. Nicméně, tam jsou omezení, že techniky Pokročilý RAG hledají překonat.
11.1 Omezení Naivního RAG
- Neshoda dotaz-dokument: Vaše otázka může používat jiné termíny než dokumenty. "Jak resetovat heslo?" vs dokument „Postup obnovy pověření“
- Problémy s hranicemi bloku: Relevantní informace lze rozdělit mezi dva po sobě jdoucí bloky
- Ztraceni uprostřed: LLM má tendenci přikládat větší váhu kouskům na začátku a na konci kontextu, přičemž zanedbává ty centrální
- Omezení jednoho skoku: Nemůže odpovědět na otázky, které vyžadují souhrny z více dokumentů
11.2 Pokročilé techniky RAG
Evoluce od naivního k pokročilému RAG
| Technika | Problém vyřešen | Jak to funguje |
|---|---|---|
| Přepisování dotazu | Nejednoznačné nebo špatně formulované dotazy | LLM přepíše dotaz do formy vhodnější pro vyhledání |
| HyDE | Neshoda mezi dotazem a dokumentem | Vygenerujte hypotetický dokument z dotazu a poté vyhledejte podobné dokumenty |
| Změna pořadí | Výsledky nejsou optimálně seřazeny | Model křížového kodéru mění pořadí výsledků podle relevance |
| Multi-Query | Jediný výzkumný pohled | Generujte varianty dotazů pro rozšíření pokrytí |
| Self-RAG | Když vyhledávání není nutné | Model se autonomně rozhoduje, zda a kdy načíst |
| Multi-Hop RAG | Složité otázky o více krocích | Řetězec iterativních vyhledávání pro sestavení složeného uvažování |
| Hybridní vyhledávání | Limity samotného sémantického vyhledávání | Kombinujte sémantické (vektorové) vyhledávání s klíčovými slovy (BM25) |
| Graf RAG | Složité vztahy mezi entitami | Použijte znalostní grafy k navigaci ve strukturovaných vztazích a kontextech |
NAIVE RAG:
Query ──> Embedding ──> Search ──> Top-K ──> LLM ──> Risposta
ADVANCED RAG:
Query ──> [Query Analysis]
│
├──> Query Rewriting ──> Embedding ──> Search ─┐
├──> HyDE Generation ──> Embedding ──> Search ─┤
└──> Multi-Query ──────> Embedding ──> Search ─┘
│
[Merge + Deduplica]
│
[Reranker Model]
│
[Context Compression]
│
[LLM + Citazioni]
│
[Risposta Verificata]
Každou z těchto technik se budeme hlouběji zabývat v následujících článcích série, zejména v článku o Hybridní vyhledávání a reranking.
12. Kdy použít RAG: Rozhodovací rámec
RAG není odpovědí na všechny problémy. Existují tři hlavní přístupy přizpůsobit chování LLM, každý s odlišnými výhodami a omezeními. Výběr závisí na konkrétním případu použití.
RAG vs jemné ladění vs rychlé inženýrství
| Kritérium | Prompt Engineering | HADR | Jemné doladění |
|---|---|---|---|
| Počáteční náklady | Minimální | Střední | Vysoký |
| Potřebné údaje | Nikdo | Znalostní základna | Tréninkový datový soubor |
| Aktualizovat | Okamžitě (rychlá změna) | Rychlé (aktualizace dokumentů) | Pomalé (přetrénování) |
| Latence | Nízký | Média (načítání + generování) | Nízký |
| Faktická přesnost | Záleží na modelu | Vysoká (na základě dokumentu) | Průměr (závisí na tréninku) |
| Citovatelné | Žádný | Vysoká (zdroje skladeb) | Žádný |
| Složitost | Nízký | Průměrný | Vysoký |
12.1 Praktický rozhodovací strom
Hai bisogno di personalizzare un LLM?
│
├── I dati cambiano frequentemente? (documenti, policy, catalogo)
│ └── SI ──> RAG
│ (I dati si aggiornano senza re-training)
│
├── Serve citare le fonti?
│ └── SI ──> RAG
│ (Tracciabilita delle risposte)
│
├── Il dominio è stabile e ben definito?
│ ├── Hai un grande dataset di training?
│ │ └── SI ──> Fine-Tuning
│ │ (Personalizzazione profonda del comportamento)
│ └── NO ──> RAG oppure Prompt Engineering
│
├── Serve solo cambiare tono/formato/stile?
│ └── SI ──> Prompt Engineering
│ (Nessuna infrastruttura aggiuntiva)
│
└── Serve ragionamento complesso su dati proprietari?
└── SI ──> RAG + Fine-Tuning (Approccio Ibrido)
(Il meglio di entrambi i mondi)
Zlaté pravidlo
Přístup doporučený komunitou inženýrů umělé inteligence se řídí stupnicí složitosti vzestupně: začněte inženýrskou výzvou, pak přejde na HADR pokud jsou potřeba externí data nebo citace, a zvažte dolaďování jen když první dva přístupy jsou nedostatečné. Tento postup minimalizuje náklady a složitost, maximalizující návratnost investic.
12.2 Ideální případy použití pro RAG
- Obchodní chatboti: Reagují na základě interní dokumentace
- Sémantické vyhledávání: Najděte dokumenty relevantní pro význam, nejen klíčová slova
- Otázky a odpovědi znalostní báze: Dynamické časté dotazy, které se aktualizují pomocí dokumentů
- Právní asistenti: Odpovědi na základě předpisů a judikatury
- Technická podpora: Rozlišení na základě předchozích a manuálních tiketů
- Dokumentární analýza: Extrahujte poznatky ze zpráv, smluv, vědeckých prací
12.3 Kdy NEPOUŽÍVAT RAG
- Kreativní úkoly: Kreativní psaní, brainstorming, generování nápadů (šablona musí být zdarma)
- Obecná konverzace: Sociální chatboti, kde nejsou potřeba konkrétní data
- Úkoly s malým množstvím dat: Pokud máte pouze několik dokumentů, může stačit rychlé inženýrství
- Těsné reakce v reálném čase: Pokud je latence načítání nepřijatelná (méně než 50 ms)
13. Trh RAG: čísla a trendy
RAG již není akademický koncept: stal se přijatou produkční architekturou ve velkém měřítku. Tržní čísla potvrzují její strategický význam.
RAG v číslech (2024–2030)
| Metrický | Dáno |
|---|---|
| Globální trh RAG (2024) | ~1,2 miliardy USD |
| Projekce trhu (2030) | ~11 miliard USD |
| Roční míra růstu (CAGR) | 49,1 % (2025–2030) |
| Podniková adopce | 30–60 % případů použití LLM používá RAG |
| Snížení halucinací | Až 71 % s dobře implementovaným RAG |
| Dominantní rámce | 80,5 % používá FAISS nebo Elasticsearch |
Odvětví, která řídí přijetí, jsou právní, lékařská, zákaznická podpora a služby finanční, tedy všechny ty oblasti, kde je faktická přesnost a citovatelnost zdrojů jsou nesmlouvatelné požadavky. Trend v letech 2025-2026 se mění od experimentování k velkovýrobě, se stále větším důrazem na dodržování, monitorování a kvalita dat.
14. Závěry a další kroky
V tomto článku jsme vybudovali komplexní porozumění RAG: z problému který řeší (halucinace LLM) na end-to-end architekturu, procházející skrz každý jednotlivý komponent potrubí. Viděli jsme funkční praktickou implementaci a porovnávali jsme RAG s alternativami (jemné doladění, rychlé inženýrství).
Shrnutí klíčových pojmů
- HADR kombinuje vyhledávání a generování a vytváří odpovědi založené na skutečných datech
- La indexovací potrubí transformovat dokumenty do vektorů: načítání, dělení, vkládání, ukládání
- La kanál dotazů najít a používat relevantní dokumenty: Vkládání, Vyhledávání, Montáž, Generování
- Il trhání je to jedno z nejkritičtějších rozhodnutí: přímo ovlivňuje kvalitu vyhledávání
- The vložení zachycují sémantický význam textu v číselných vektorech
- I vektorový obchod umožňují podobnostní vyhledávání v milionech dokumentů
- Pokročilý RAG zavádí techniky jako reranking, HyDE a multi-hop k překonání omezení Naive RAG
- RAG je ideální v případě potřeby aktualizované, ověřitelné a citovatelné odpovědi
Další článek: Vkládání a sémantické vyhledávání
V dalším článku série se ponoříme hlouběji do nejfascinující složky RAG: ho vložení. Uvidíme, jak fungují interně, jak si vybrat správný model, jak vyhodnotit jeho kvalitu a jak optimalizovat sémantické vyhledávání. Prozkoumáme také vyhodnocovací metriky a techniky benchmarkingu pro měření výkon vašeho vyhledávacího systému.
AI Engineering Series a Advanced RAG
| Položka | Podrobit |
|---|---|
| 01 - Jste zde | RAG: Retrieval-Augmented Generation Explained |
| 02 - Další | Vložení a hloubkové sémantické vyhledávání |
| 03 | Vektorová databáze: Architektura a osvědčené postupy |
| 04 | Vytváření systému RAG pomocí LangChain a Python |
| 05 | Hybridní vyhledávání: klíčové slovo + sémantika + změna pořadí |
| 06 | Kontextové okno a rychlé inženýrství pro RAG |
| 07 | RAG ve výrobě: monitorování, hodnocení, škálování |
| 08 | Znalostní grafy a strukturované vyhledávání |
| 09 | Multiagentní systémy a organizovaný RAG |
| 10 | Budoucnost RAG: Trendy a výzkum |