Ce este RAG și de ce fiecare dezvoltator ar trebui să-l cunoască
I Model de limbă mare (LLM) au revoluționat modul în care interacționăm cu informații, dar suferă de o problemă fundamentală: cunoștințele lor sunt static, înghețat în momentul antrenamentului. Când întrebați un LLM despre documentația dvs intern, pe produsele tale sau pe date actualizate, răspunsul va fi generic, inventat sau simplu greșit. Acest fenomen se numește halucinaţie.
Recuperare-Augmented Generation (RAG) rezolvă această problemă prin combinarea puterii generatoare de LLM-uri cu precizia unui sistem de regăsire a informațiilor. În loc să te bazezi numai la memoria modelului, RAG caută mai întâi documentele relevante într-o bază de cunoștințe și acolo oferă context modelului pentru a genera răspunsuri precise, bazate pe date.
În acest prim articol al seriei AI pentru dezvoltatori web, vom explora RAG în profunzime: ce este, cum funcționează, când să-l folosești și când să îl eviți. La final vei avea unul înțelegere solidă a arhitecturii RAG și veți fi gata să o implementați în articolul următor.
Prezentare generală a seriei
| # | Articol | Concentrează-te |
|---|---|---|
| 1 | Sunteți aici - Ce este RAG | Fundații și arhitectură |
| 2 | RAG cu TypeScript și LangChain.js | Implementare practică |
| 3 | Baza de date vectorială pentru Web Dev | Stocare și căutare de similaritate |
| 4 | OpenAI și API-uri antropice | Integrarea LLM |
| 5 | LLM Local cu Ollama | Modele on-premise |
| 6 | Reglaj fin vs RAG | Când să folosești ce |
| 7 | Agenți AI: Arhitectură | Sisteme autonome |
| 8 | AI în conducta CI/CD | Automatizare DevOps |
Ce vei învăța
- Ce este RAG și ce problemă rezolvă
- Arhitectura completă a unui sistem RAG (recuperare + generare).
- Cum funcționează înglobările și căutarea de similaritate
- Strategii de fragmentare pentru pregătirea documentelor
- Diferența dintre RAG și reglaj fin
- Cazuri reale de utilizare: chatbot, căutare semantică, întrebări și răspunsuri
- Limitările RAG și când să NU îl folosiți
1. Problema: LLM și cunoștințe statice
Imaginați-vă că doriți să construiți un chatbot pentru asistența clienților companiei dvs. Ai mii de pagini de documentație, întrebări frecvente, manuale tehnice și tichete rezolvate. Folosiți un LLM precum GPT-4 sau Claude, dar rezultatul este dezamăgitor: modelul nu vă cunoaște produsele, inventează caracteristici inexistente și oferă proceduri incorecte cu o certitudine absolută.
Cele trei probleme fundamentale ale LLMs
| Problemă | Descriere | Impact |
|---|---|---|
| Cutofă de cunoștințe | Modelul cunoaște doar datele de antrenament | Nu știe nimic despre datele dvs. de proprietate |
| Halucinații | Generați răspunsuri plauzibile, dar false | Informații incorecte cu mare încredere |
| Fără citare | El nu poate indica sursa informației | Nu se poate verifica corectitudinea |
Aceste probleme nu sunt rezolvate pur și simplu cu un prompt mai bun. Avem nevoie de date reale, actualizat și specific domeniului dvs. Și exact asta face RAG.
2. Ce este RAG: Retrieval-Augmented Generation
CÂRPĂ este o arhitectură care combină două faze distincte: cel regăsire (recuperarea) documentelor relevante dintr-o bază de cunoștințe este generaţie (generație) a unui răspuns bazat pe acele documente. Termenul a fost introdus în 2020 de cercetători de Meta AI în lucrarea „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”.
Ideea este simplă, dar puternică: înainte de a cere modelului să genereze un răspuns, căutați documentele cele mai relevante pentru întrebarea utilizatorului și introduceți-le în prompt ca context suplimentar. Modelul nu mai trebuie să-și „amintească” totul, trebuie doar să raționeze asupra informatiilor furnizate.
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
Analogie practică
Gândiți-vă la RAG ca la unul singur student în timpul unui examen cu carte deschisă. LLM tradițional este un elev care trebuie să răspundă pe de rost: știe multe, dar poate să se încurce sau să inventeze. Cu RAG, elevul își poate consulta notele și cărțile înainte de a răspunde. Răspunsul va fi mai precis deoarece se bazează pe surse concrete.
3. Arhitectura completă a unui sistem RAG
Un sistem RAG este format din două conducte principale: conductă de indexare (efectuate offline, ocazional sau periodic) și conductă de interogări (executat în timp real cu fiecare întrebare utilizator).
3.1 Indexarea conductei (offline)
Această fază pregătește documentele pentru cercetare. Pașii sunt:
[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 Conductă de interogări (online)
Această fază gestionează cererea utilizatorilor în timp real:
[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]
Acordați atenție consistenței înglobărilor
Este esențial să-l folosești același model de încorporare atât în faza de indexare decât în faza de interogare. Dacă utilizați modele diferite, vectorii nu vor fi comparabil și căutarea de similaritate nu va funcționa corect.
4. Embeddings: Inima RAG
The înglobări sunt reprezentări numerice (vectori) de text care surprind sensul semantic. Două propoziții cu înțeles similar vor avea vectori „aproape” în spațiu multidimensional, chiar dacă folosesc cuvinte complet diferite.
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
Șabloane de încorporare populare
| Model | Dimensiuni | Furnizorii | Cost |
|---|---|---|---|
text-embedding-3-small |
1536 | OpenAI | 0,02 USD / 1 milion de jetoane |
text-embedding-3-large |
3072 | OpenAI | 0,13 USD / 1 milion de jetoane |
voyage-3 |
1024 | Voyage AI | 0,06 USD / 1 milion de jetoane |
all-MiniLM-L6-v2 |
384 | HuggingFace (gratuit) | Gratuit (auto-găzduit) |
nomic-embed-text |
768 | Ollama (local) | Gratuit (local) |
La asemănarea cosinusului este cea mai comună metrică pentru compara înglobările. Măsoară unghiul dintre doi vectori: o valoare de 1,0 indică vectori identic, 0,0 indică nicio relație, -1,0 indică sensuri opuse.
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. Strategii de fragmentare
Il în bucăţire este procesul de împărțire a documentelor în fragmente (buncătură) de dimensiuni gestionabile. Această fază este critică: bucăți prea mari se dispersează adică bucățile prea mici pierd contextul.
Parametrii cheie de fragmentare
- Dimensiune bucată: Dimensiunea maximă a fiecărui fragment (în caractere sau jetoane). De obicei, 500-2000 de caractere
- Suprapunere bucăți: Suprapunerea între bucăți consecutive (10-20% din dimensiunea bucăților). Evitați să tăiați conceptele la jumătate
- Separatoare: Punctele în care tăierea este de preferat (paragrafe, propoziții, titluri)
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."
Greșeli obișnuite în chunking
- Bucăți prea mari (>4000 de jetoane): Modelul poate ignora părți din context sau poate depăși limita de simboluri
- Bucăți prea mici (<100 de jetoane): Pierderea contextului, răspunsuri fragmentate
- Suprapunere zero: Conceptele tăiate la jumătate, recuperarea incompletă
- Ignorați metadatele: Pierderea de informații precum titlul, autorul, data documentului
6. RAG vs reglaj fin: când să folosiți ce
Una dintre cele mai frecvente întrebări este: „Ar trebui să folosesc RAG sau să ajustez modelul?”. Răspunsul depinde de tipul de cunoștințe pe care doriți să le adăugați și de modul în care acestea vor fi utilizate.
RAG vs reglaj fin - comparație detaliată
| astept | CÂRPĂ | Reglaj fin |
|---|---|---|
| Tipul de cunoștințe | Fapte specifice, date, documente | Stil, format, comportament |
| Actualizare | Instantaneu (actualizare documente) | Necesită reinstruire |
| Costul initial | Scăzut (infrastructură + încorporare) | Ridicat (GPU, date etichetate, timp) |
| Cost pe interogare | Mediu (recuperare + generare) | Scăzut (numai generație) |
| Trasabilitate | Ridicat (puteți cita surse) | Niciuna (cunoștințe integrate) |
| Halucinații | Redus (date reale în context) | Posibil (cunoștințe învățate) |
| Scalabilitatea datelor | Milioane de documente | Limitat de setul de antrenament |
| Complexitate | Media (conductă + vector DB) | Ridicat (instruire, evaluare, implementare) |
Regulă practică
STATELE UNITE ALE AMERICII CÂRPĂ când doriți ca modelul să „știe” informații specifice (documente, întrebări frecvente, manuale). STATELE UNITE ALE AMERICII reglaj fin cand vrei modelul „se comportă” într-un anumit fel (ton, format, stil de răspuns). În multe cazuri, combinarea celor două abordări produce cele mai bune rezultate.
7. Cazuri reale de utilizare ale RAG
RAG nu este doar teorie: este baza multor produse pe care le folosim zilnic. Iată cele mai frecvente cazuri de utilizare și modul în care RAG le activează.
7.1 Chatbot-uri corporative
Cel mai popular caz de utilizare. Un chatbot care răspunde la întrebările clienților pe baza pe documentația reală a companiei: manuale, întrebări frecvente, tichete rezolvate, politici interne.
// 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 Căutare semantică
Spre deosebire de căutarea tradițională bazată pe cuvinte cheie, căutarea semantică cu RAG include sens a interogării. „Cum să vă resetați parola” găsește rezultate chiar dacă documentul scrie „procedura de recuperare a acreditărilor”.
7.3 Întrebări și răspunsuri despre documente
Permite utilizatorilor să pună întrebări în limbaj natural despre colecții mari de documente: contracte legale, documentație tehnică, lucrări științifice, baze de cunoștințe interne.
7.4 Asistent de cod
Un asistent de cod care vă cunoaște baza de cod specifică. Indexați codul sursă, Documentație API, comentarii și teste pentru a oferi sugestii contextualizate.
Comparație de cazuri de utilizare
| Caz de utilizare | Sursa datelor | Frecvența de actualizare | Complexitate |
|---|---|---|---|
| Asistență Chatbot | Întrebări frecvente, manuale, bilete | Săptămânal | Medie |
| Căutare semantică | Catalog de produse, articole | Zilnic | Scăzut |
| Documente de întrebări și răspunsuri | PDF, contracte, rapoarte | La cerere | Medie |
| Asistent de cod | Cod sursă, documente API | La fiecare comitere | Ridicat |
8. Anatomia unei conducte RAG complete
Să vedem în detaliu fiecare componentă a conductei, cu alegerile tehnologice cu care te vei confrunta în implementare.
+------------------+--------------------------------------------+
| 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 Încărcătoare de documente
Încărcătoarele de documente extrag text din diverse surse. Calitatea extracției influențează direct calitatea răspunsurilor.
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: Dincolo de căutarea similarității
Retrieverul nu găsește doar cele mai asemănătoare bucăți. Există strategii avansate pentru a îmbunătăți calitatea recuperării.
Strategii de recuperare
- Căutare de similaritate: K bucăți cu cel mai mare scor de similaritate. Simplu dar eficient
- MMR (Relevanță marginală maximă): Echilibrați relevanța și diversitatea. Evitați bucățile care sunt prea asemănătoare între ele
- Auto-interogare: Modelul extrage filtre din întrebare (de exemplu, „documente 2024” filtrează după dată)
- Ansamblu: Combinați rezultatele de la mai mulți retriever (de exemplu, cuvinte cheie + semantică) pentru o acoperire mai bună
- Document părinte: Preia fragmentul relevant, dar returnează documentul părinte pentru contextul complet
9. Limitările RAG și când NU-l folosiți
RAG nu este o soluție magică. Ca orice arhitectură, are limitări de care trebuie să fii conștient înainte de a o adopta.
Când RAG NU este alegerea corectă
- Raționament complex: RAG oferă fapte, nu raționament. Pentru analiza în mai multe etape sau deducții logice complexe, modelul trebuie să aibă propriile capacități
- Date structurate: Dacă aveți nevoie de agregări SQL, calcule sau îmbinări între tabele, utilizați o bază de date relațională, nu RAG
- Răspunsuri ultra-rapide în timp real: Conducta de recuperare adaugă latență (100-500 ms). Dacă aveți nevoie de răspunsuri în <50 ms, luați în considerare stocarea în cache
- Baza de cunoștințe prea mică: Cu puține documente (<10 pagini), puteți încadra totul în prompt fără a fi nevoie de preluare
- Date foarte dinamice: Dacă datele se modifică în fiecare secundă (de exemplu, prețurile bursiere), RAG nu este suficient de rapid în actualizare
Probleme și soluții comune
| Problemă | Cauza | Soluţie |
|---|---|---|
| Răspunsuri irelevante | Bucățile prea mari | Reduceți dimensiunea bucăților, măriți suprapunerea |
| El răspunde „nu știu” prea des | Recuperare prea restrictivă | Creșteți k (numărul de rezultate), utilizați MMR |
| Halucinații persistente | Context insuficient sau ambiguu | Îmbunătățiți promptul, adăugați instrucțiuni explicite |
| Latență mare | Prea multe bucăți în context | Reduceți k, folosiți re-clasificarea |
| Costuri mari | Prea multe jetoane per interogare | Comprimați bucăți, folosiți modele mai ieftine |
10. Măsuri de evaluare pentru RAG
Pentru a ști dacă sistemul dvs. RAG funcționează bine, trebuie să îl măsurați. Iată principalele valori.
metrici RAG
| Metric | Ce măsoară | Ţintă |
|---|---|---|
| Relevanța contextului | Sunt documentele preluate relevante pentru cerere? | > 0,8 |
| Fidelitate | Răspunsul se bazează pe documentele furnizate? | > 0,9 |
| Răspuns Relevanța | Este răspunsul relevant pentru întrebare? | > 0,85 |
| Latența | Timp total pentru a răspunde | < 3 secunde |
| Rata halucinațiilor | Procentul de revendicări care nu sunt susținute de documente | < 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
Următorii pași
În acest articol ați dobândit o înțelegere solidă a RAG: ce este, cum funcționează, componentele cheie ale arhitecturii și când să o folosești (sau să nu o folosești). Ai înțeles rolul fundamentale ale înglobărilor, strategiilor de fragmentare și metricilor de evaluare.
În articolul urmator vom trece de la teorie la practică: vom implementa un sistem RAG complet folosind TypeScript și LangChain.js, cu un vector magazin real și o interfață conversațională cu memorie.
Resurse suplimentare
- Hârtie originală RAG: „Generație de recuperare crescută pentru sarcini NLP intensive în cunoștințe” (Lewis et al., 2020)
- Documente LangChain.js: Documentație oficială pentru implementare în TypeScript
- Cartea de bucate OpenAI: Exemple practice de RAG cu API-uri OpenAI
- Centrul de învățare Pinecone: Ghiduri despre baze de date vectoriale și înglobări
- RAGAS: Cadru open-source pentru evaluarea sistemelor RAG