RAG (Retrieval-Augmented Generation) combină două componente: un mecanism de căutare/recuperare (retrieval) a informației relevante și un LLM care generează răspunsul pe baza acelei informații. Arhitectura are două fluxuri distincte: unul de pregătire a datelor (offline) și unul de răspuns la întrebări (online, în timp real).
Capitol gratuit
Arhitectura RAG explicată
RAG (Retrieval-Augmented Generation) combină două componente: un mecanism de căutare/recuperare (retrieval) a informației relevante și un LLM care genereaz...
Introducere
Fluxul de ingestie (pregătirea datelor)
Acest flux rulează o dată, apoi periodic la fiecare actualizare de conținut:
1. Documente sursă (PDF, pagini web, FAQ, baza de date)
│
▼
2. Extragere text curat (curățare HTML, tabele, formatare)
│
▼
3. Chunking (împărțire în fragmente mici, cu sens de sine stătător)
│
▼
4. Embedding (fiecare fragment devine un vector numeric)
│
▼
5. Stocare în baza de date vectorială (vector store)Fluxul de interogare (răspunsul în timp real)
1. Utilizatorul pune o întrebare
│
▼
2. Întrebarea este transformată în vector (embedding)
│
▼
3. Căutare de similaritate în vector store (top-K fragmente relevante)
│
▼
4. (opțional) Reranking - reordonare după relevanță reală
│
▼
5. Fragmentele + întrebarea sunt trimise LLM-ului într-un prompt
│
▼
6. LLM generează răspunsul, ancorat în fragmentele primiteComponentele arhitecturii RAG
| Componentă | Rol |
|---|---|
| Loader / extractor | Citește documentele sursă (PDF, HTML, DOCX, baze de date) |
| Text splitter (chunker) | Împarte textul în fragmente de dimensiune gestionabilă |
| Model de embedding | Transformă text în vectori numerici care „codifică" sensul |
| Vector store | Bază de date optimizată pentru căutare de similaritate între vectori |
| Retriever | Logica ce interoghează vector store-ul și returnează cele mai relevante fragmente |
| Reranker (opțional) | Model secundar care reordonează rezultatele după relevanță |
| LLM generator | Modelul care formulează răspunsul final în limbaj natural |
| Orchestrator | Codul/platforma care leagă toate componentele (ex. LangChain, LlamaIndex, n8n) |
Căutare semantică vs. căutare pe cuvinte cheie
Diferența esențială față de căutarea clasică (ex. căutarea din bara de search a unui site): căutarea pe cuvinte cheie găsește doar text care conține exact acele cuvinte, în timp ce căutarea semantică (bazată pe embeddings) găsește text cu sens similar, chiar dacă formularea este complet diferită.
Exemplu: Un client întreabă „Pot să returnez produsul dacă nu-mi place?". Documentul afacerii spune „Politica de retragere din contract permite restituirea bunurilor în 14 zile calendaristice." Nu există niciun cuvânt comun exact între întrebare și document, dar o căutare semantică le potrivește corect pentru că înțelege că se referă la același concept.
Hybrid search - combinația câștigătoare
În practică, cele mai bune sisteme RAG din 2026 nu se bazează exclusiv pe căutare semantică. Folosesc hybrid search: combină căutarea semantică (vectori) cu căutarea clasică pe cuvinte cheie (BM25), pentru a acoperi atât întrebările conceptuale, cât și căutările exacte (coduri de produs, nume proprii, numere de telefon, SKU-uri) pe care vectorii singuri le tratează adesea mai slab.
Sfat: Dacă afacerea dumneavoastră are mult conținut cu coduri exacte (SKU-uri, numere de comandă, coduri de eroare), verificați dacă platforma sau baza de date vectorială aleasă suportă hybrid search - va îmbunătăți sensibil precizia răspunsurilor.
Greșeli frecvente în arhitectura RAG
| Greșeală | Consecință | Soluție |
|---|---|---|
| Chunking prea grosier (fragmente de mii de tokeni) | Căutarea semantică devine imprecisă, se recuperează mult conținut irelevant | Reduceți dimensiunea fragmentului, vezi capitolul 5 |
| Lipsa metadatelor de sursă | Nu puteți cita de unde provine informația, dificil de depanat | Stocați întotdeauna sursa și data actualizării per fragment |
| Fără instrucțiuni clare de ancorare în prompt | Modelul „completează" din cunoștințe generale, nu doar din context | Prompt de sistem explicit, conform capitolului 7 |
| Date neactualizate în vector store | Chatbot-ul răspunde cu informații vechi, cu aceeași încredere ca cele corecte | Proces de reindexare programat la fiecare actualizare de conținut |
| Testare doar pe întrebări „ușoare" | Probleme reale descoperite abia după lansare, de către clienți | Set de testare cu întrebări ambigue, incomplete sau limită (capitolul 11) |
Continuați cu restul cursului
Acesta este capitolul 3 din cele 14 ale cursului, cu 6 lecții din 82. Cumpărați cursul și parcurgeți tot conținutul în cont, cu progres salvat, test final și certificat.
Cumpărați cursul la 130 €