Ce este RAG și De Ce Contează

Un LLM îți va răspunde cu aceeași siguranță și când știe răspunsul, și când îl inventează — iar în producție, un răspuns greșit rostit cu convingere costă mai mult decât un sincer „nu știu". Retrieval-Augmented Generation — prescurtat RAG — atacă exact această problemă. Nu este un model, nu este un framework, nu este o bibliotecă: este un principiu de design prin care, în loc să te bazezi exclusiv pe cunoștințele internalizate de un LLM în timpul antrenamentului, aduci informații relevante din surse externe în momentul generării răspunsului. Fără să înțelegi de ce funcționează acest principiu, tot ce urmează — embeddings, chunking, retrieval, re-ranking — rămâne un exercițiu mecanic, executat fără să știi ce rezolvi de fapt.

De ce halucinează modelele lingvistice mari

Pentru a înțelege de ce RAG există, trebuie să înțelegem mai întâi de ce LLM-urile eșuează în moduri atât de insidioase. Un model precum GPT-5.6 Sol, Claude Opus 5 sau Gemini 3.1 Pro a fost antrenat pe corpusuri masive de text — trilioane de tokeni din cărți, articole științifice, cod sursă, pagini web, conversații. Prin acest antrenament, modelul a învățat distribuții statistice peste secvențe de tokeni. Când generează text, modelul selectează fiecare token următor pe baza probabilităților condiționate de contextul anterior.

Halucinația apare din cel puțin patru mecanisme distincte:

1. Completare probabilistică fără ancoraj factual. Modelul nu „știe" fapte în sensul în care o bază de date stochează înregistrări. El a învățat co-apariții statistice. Dacă în datele de antrenament, expresia „capitala Australiei" a apărut frecvent lângă „Sydney" (din contexte care discutau despre cel mai mare oraș), modelul poate genera „Sydney" cu încredere, deși răspunsul corect este Canberra. Modelul nu verifică — generează.

2. Knowledge cutoff. Antrenamentul unui LLM se încheie la o dată fixă. GPT-5.6 Sol (lansat 9 iulie 2026) are cutoff în februarie 2026, iar Claude Opus 5 (lansat 24 iulie 2026) în mai 2026, dar orice eveniment, produs, lege, sau schimbare care a apărut după această dată pur și simplu nu există în „memoria" modelului. Dacă întrebi despre o reglementare UE adoptată luna trecută, modelul va improviza pe baza reglementărilor anterioare pe care le cunoaște — producând un răspuns plauzibil dar potențial incorect.

3. Lipsa accesului la date private. Chiar și pentru informații contemporane, dacă datele sunt private — regulamente interne, documentație tehnică proprietară, contracte, baze de cunoștințe enterprise — modelul nu le-a văzut niciodată. Și nu are cum. Nu poți include codul sursă proprietar al companiei tale în datele publice de antrenament.

4. Conflicte și suprapuneri în datele de antrenament. Când surse diferite oferă informații contradictorii (ceea ce se întâmplă frecvent pe internet), modelul internalizează ambele perspective. Răspunsul generat poate reflecta fie una, fie cealaltă, fie o combinație, fără nicio garanție de acuratețe.

Aceste mecanisme fac ca halucinația să fie o proprietate emergentă a arhitecturii transformer, nu un bug care poate fi „reparat" prin mai mult antrenament. Este intrinsecă modului în care aceste modele funcționează. RAG nu elimină halucinația — dar o reduce dramatic prin ancorarea generării în surse verificabile.

Problema knowledge cutoff în context enterprise

În mediul academic sau pentru întrebări generale, knowledge cutoff-ul este o inconveniență. În mediul enterprise, este o problemă critică. Să luăm un exemplu concret relevant pentru piața românească.

O companie de servicii financiare din București folosește un LLM pentru a răspunde la întrebări despre reglementările BNR. Să presupunem că una dintre reglementările BNR aplicabile a fost actualizată recent cu noi cerințe privind raportarea riscurilor operaționale. Modelul, antrenat pe date până în 2025, cunoaște versiunea veche a reglementării. Un analist care întreabă „Care sunt cerințele actuale de raportare a riscurilor operaționale?" primește un răspuns bazat pe versiunea 2024 — structurat perfect, formulat profesionist, și complet outdated. Dacă analistul nu verifică manual (și de ce ar face-o, dacă a apelat la un asistent AI tocmai pentru eficiență?), compania riscă non-conformitate.

RAG rezolvă exact această problemă. Reglementările actualizate sunt indexate în baza de date vectorială. Când analistul pune întrebarea, sistemul recuperează fragmentele relevante din versiunea 2026 a reglementării și le furnizează modelului ca context. Răspunsul reflectă realitatea curentă, nu memoria fosilizată a antrenamentului.

RAG versus fine-tuning versus context lung: analiza comparativă

Una dintre cele mai frecvente confuzii în domeniul aplicațiilor LLM este distincția între RAG, fine-tuning și utilizarea ferestrelor de context extins. Toate trei sunt mecanisme de adaptare a unui LLM la un domeniu specific, dar funcționează fundamental diferit.

Fine-tuning modifică parametrii interni ai modelului. Prin antrenament suplimentar pe un dataset specific, modelul își ajustează distribuțiile interne de probabilitate. Este ca și cum ai trimite un chirurg generalist la o specializare de doi ani — după, gândește diferit, abordează problemele diferit. Fine-tuning-ul este potrivit pentru: (a) adaptarea stilului și tonului — dacă vrei ca modelul să răspundă ca un consilier juridic, nu ca un asistent general; (b) internalizarea terminologiei specifice unui domeniu; (c) îmbunătățirea performanței pe task-uri specifice (clasificare, extracție de entități). Fine-tuning-ul este costisitor (sute sau mii de dolari per rundă de antrenament), lent (ore sau zile), și rigid — odată antrenat, modelul reflectă datele de la momentul antrenamentului. Dacă informația se schimbă, trebuie re-antrenat.

Context lung (long context) profită de faptul că modelele moderne au ferestre de context enorme. Până în 2026, fereastra de 1M tokeni a devenit default pe toate variantele relevante: Claude Opus 5 expune 1M prin model ID-ul claude-opus-5[1m] (cu output 128K), iar GPT-5.6 Sol oferă ~1M nativ. Poți, teoretic, să inserezi zeci de mii de pagini direct în prompt. Avantajul este simplitatea: nu ai nevoie de baze de date vectoriale, embeddings, chunking — inserezi documentele și întrebi. Dezavantajele sunt: (a) costul: plătești per token procesat — Opus 5 costă $5/$25 per milion tokeni input/output, GPT-5.6 Sol $5/$30 — iar 500.000 de tokeni de context la fiecare întrebare adaugă costuri semnificative; (b) latența: procesarea unui context de 1M tokeni durează semnificativ mai mult decât procesarea a 5.000; (c) degradarea performanței: studii empirice (inclusiv lucrarea „Lost in the Middle" — Liu et al., 2024) arată că modelele tind să acorde mai puțină atenție informațiilor din mijlocul contextului, chiar și pe ferestre 1M; (d) scalabilitate: dacă ai 10 milioane de documente, nu le poți insera pe toate.

Notă importantă pentru 2026 — RAG vs long-context tradeoff: Cu Opus 5 oferind prompt caching la reducere semnificativă pentru prefixul stabil și GPT-5.6 Sol fiind eficient pe consumul de tokeni, granița dintre „stuff" (inserează tot) și „retrieve" (RAG clasic) s-a deplasat. Pentru baze de cunoștințe sub ~500K tokeni stabile (KB internă, documentație produs), o strategie eficientă devine: indexezi întreaga KB ca cached prefix la Opus 5, iar partea de input cached a query-ului devine mult mai ieftină. Pentru corpusuri mai mari, frecvent actualizate sau cu acces granular per-utilizator, RAG rămâne soluția corectă — iar Opus 5 ca synthesizer peste candidates retrieved este foarte capabil pentru cross-document reasoning, reducând adesea nevoia de re-ranking complex. Atenție însă la tokenizer-ul nou din generația Opus 4.x: poate produce un număr diferit de tokeni decât generațiile anterioare pentru același text (recalibrarea tokenizerului afectează costul efectiv) — re-calibrează bugetele de context în RAG pe un sample reprezentativ.

RAG este complementar ambelor. RAG nu modifică modelul (ca fine-tuning-ul) și nu inserează tot corpusul în context (ca long context). RAG selectează doar fragmentele relevante din corpusul de documente și le inserează în context. Este eficient din punct de vedere al costurilor (plătești doar pentru tokenii relevanți), rapid (retrieval-ul durează milisecunde), dinamic (dacă documentele se schimbă, actualizezi indexul, nu modelul), și scalabil (poți indexa miliarde de documente).

Tabelul de comparație:

Combinația cea mai puternică în 2026: fine-tuning pentru stil și comportament + RAG pentru cunoștințe factuale actualizate.

Arhitectura RAG: Retrieve → Augment → Generate

Arhitectura RAG operează în două faze distincte cu scopuri și timpi de execuție complet diferiți.

Faza offline — Indexare (Ingestion Pipeline):

Documente brute → Parsare → Curățare → Chunking → Embedding → Stocare în vector DB

Această fază se execută înainte ca vreun utilizator să pună vreo întrebare. Poate dura ore pentru colecții mari (zeci de mii de documente), dar se execută o singură dată, cu actualizări incrementale ulterioare. Fiecare document parcurge pipeline-ul: este parsat din formatul nativ (PDF, HTML, DOCX), curățat de artefacte (headere, footere, elemente de navigare), segmentat în fragmente (chunks) de dimensiune controlată, transformat în vectori numerici (embeddings) și stocat într-o bază de date vectorială alături de textul original și metadate.

Faza online — Interogare (Query Pipeline):

Întrebare utilizator → Query Embedding → Vector Search → Context Assembly → Prompt Augmentation → LLM Generation → Răspuns

Această fază se execută în timp real. Secvența completă:

1. Query Embedding — întrebarea utilizatorului este transformată în vector numeric folosind exact același model de embedding utilizat la indexare. Aceasta este o cerință critică: vectorii trebuie să fie în același spațiu matematic.
2. Vector Search — vectorul întrebării este comparat cu vectorii din baza de date. Se returnează top-k cele mai similare fragmente (tipic k=5 până la k=20).
3. Context Assembly — fragmentele recuperate sunt ordonate, deduplicate, și asamblate într-un context coerent.
4. Prompt Augmentation — contextul este inserat în prompt-ul trimis către LLM, alături de instrucțiuni și întrebarea originală.
5. LLM Generation — modelul generează un răspuns bazat pe informația din context.

Implementarea minimală demonstrativă:

from openai import OpenAI

client = OpenAI()

def rag_pipeline(user_question: str, vector_db, top_k: int = 5) -> str:
    """Pipeline RAG complet — de la întrebare la răspuns."""

    # Pas 1: Transformăm întrebarea în vector
    query_embedding = client.embeddings.create(
        input=user_question,
        model="text-embedding-3-large"
    ).data[0].embedding

    # Pas 2: Căutare vectorială — recuperăm cele mai relevante fragmente
    relevant_chunks = vector_db.similarity_search(
        query_vector=query_embedding,
        top_k=top_k
    )

    # Pas 3: Asamblăm contextul
    context_parts = []
    for i, chunk in enumerate(relevant_chunks, 1):
        context_parts.append(
            f"[Fragment {i} — Sursă: {chunk.metadata.get('source', 'N/A')}]\n"
            f"{chunk.text}"
        )
    context = "\n\n---\n\n".join(context_parts)

    # Pas 4: Prompt augmentat cu instrucțiuni stricte
    system_prompt = """Ești un asistent care răspunde EXCLUSIV pe baza
contextului furnizat. Dacă informația nu se află în context, spune
explicit că nu ai suficiente informații. Nu inventa niciodată."""

    user_prompt = f"""Context din documente:
{context}

Întrebarea utilizatorului: {user_question}

Răspunde precis, citând fragmentele relevante."""

    # Pas 5: Generăm răspunsul
    response = client.chat.completions.create(
        model="gpt-5.6-sol",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.1  # Scăzut — fidelitate maximă față de context
    )

    return response.choices[0].message.content

Observați temperature=0.1. Aceasta nu este o preferință stilistică — este o decizie arhitecturală. Pentru sisteme RAG factuale, temperatura trebuie să fie între 0.0 și 0.2. O temperatură ridicată (0.7-1.0) încurajează diversitate și creativitate, ceea ce în contextul RAG se traduce prin: modelul improvizează în loc să rămână fidel contextului furnizat. Rezultatul? Halucinații mascate sub un stil fluent.

Lewis et al. 2020: lucrarea fondatoare

Termenul „Retrieval-Augmented Generation" a fost formalizat în lucrarea „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" de Patrick Lewis et al. (Facebook AI Research, UCL — publicată în NeurIPS 2020). Această lucrare este piatra de temelie a întregului domeniu și merită o analiză detaliată.

Contextul: În 2020, modelele lingvistice pre-antrenate (BERT, GPT-2, T5) arătau performanțe impresionante pe task-uri lingvistice, dar eșuau la sarcini „knowledge-intensive" — întrebări care necesitau cunoștințe factuale specifice. Fine-tuning-ul pe dataset-uri de QA ajuta, dar modelele tot halucinau când informația nu era în parametrii lor.

Contribuția cheie: Lewis et al. au propus un model end-to-end care combină un retriever parametric (DPR — Dense Passage Retriever) cu un generator parametric (BART). Retriever-ul caută pasaje relevante dintr-o bază de cunoștințe (Wikipedia), iar generatorul produce răspunsul condiționat de pasajele recuperate. Esențial, ambele componente sunt antrenate joint — retriever-ul învață ce să caute, iar generatorul învață cum să utilizeze ce i se furnizează.

Două variante arhitecturale:

• RAG-Sequence: același set de documente este folosit pentru a genera întregul răspuns. Retriever-ul selectează documente o singură dată, iar generatorul le folosește pentru toată secvența de output.
• RAG-Token: retriever-ul poate selecta documente diferite pentru fiecare token generat. Mai flexibil, dar mai costisitor computațional.

Rezultate: RAG a depășit modelele fine-tuned pe mai multe benchmark-uri de QA (Natural Questions, TriviaQA, WebQuestions), demonstrând că accesul la informații externe la inference-time poate fi mai eficient decât memorizarea prin antrenament.

Moștenirea din 2026: Deși arhitectura specifică din lucrarea originală (DPR + BART) este depășită tehnic, principiul RAG a devenit ubicuu. Orice sistem modern care combină retrieval cu generare este un descendent conceptual al acestei lucrări.

Naive RAG vs Advanced RAG vs Modular RAG

Taxonomia modernă a sistemelor RAG, cristalizată în lucrări precum Gao et al. (2024) — „Retrieval-Augmented Generation for Large Language Models: A Survey" — identifică trei generații:

Naive RAG (Generația 1): Pipeline-ul liniar descris mai sus — indexare → retrieval → generare. Simplu de implementat, dar suferă de trei probleme principale: (a) retrieval-ul poate fi imprecis (garbage in → garbage out); (b) chunk-urile recuperate pot conține informații redundante sau contradictorii; (c) modelul poate ignora contextul sau îl poate interpreta greșit.

Advanced RAG (Generația 2): Adaugă tehnici de îmbunătățire la fiecare etapă. Pre-retrieval: query expansion (reformularea întrebării în multiple variante), HyDE (Hypothetical Document Embeddings — generarea unui document ipotetic care ar răspunde la întrebare, apoi căutarea după embedding-ul acestuia), query routing (dirijarea întrebărilor către surse specifice). Post-retrieval: re-ranking (reordonarea rezultatelor cu un model cross-encoder mai precis), compression (eliminarea pasajelor irelevante din context), fusion (combinarea rezultatelor din surse multiple).

# Exemplu: HyDE — Hypothetical Document Embeddings
def hyde_retrieval(question: str, vector_db, client) -> list:
    """Generăm un document ipotetic, apoi căutăm după el."""

    # Pas 1: LLM-ul generează un răspuns ipotetic (poate fi imprecis)
    hypothetical = client.chat.completions.create(
        model="gpt-5.6-sol",
        messages=[{
            "role": "user",
            "content": f"Scrie un paragraf care ar răspunde la: {question}"
        }],
        temperature=0.7
    ).choices[0].message.content

    # Pas 2: Embedding-ul documentului ipotetic
    hyde_embedding = client.embeddings.create(
        input=hypothetical,
        model="text-embedding-3-large"
    ).data[0].embedding

    # Pas 3: Căutare cu embedding-ul ipotetic (nu cu întrebarea)
    return vector_db.similarity_search(
        query_vector=hyde_embedding,
        top_k=10
    )

Modular RAG (Generația 3, starea curentă 2026): Descompune pipeline-ul într-un graf de module interșanjabile. Fiecare modul (routing, retrieval, re-ranking, generation, verificare) poate fi implementat independent, combinat diferit pentru scenarii diferite, și orchestrat de un controller (adesea un agent LLM). Exemplu: un sistem modular poate decide că pentru întrebări simple nu are nevoie de retrieval (răspunde direct din cunoștințele modelului), pentru întrebări factuale folosește retrieval standard, iar pentru întrebări complexe face retrieval iterativ cu rafinare progresivă.

Cazuri reale de utilizare în 2026

RAG nu mai este o curiozitate academică — este infrastructură de producție. Iată cazuri concrete, validate în piață:

1. Customer Support Enterprise: Companii precum Klarna, Zendesk, Intercom integrează RAG în asistenți de suport. Baza de cunoștințe (articole help center, istoricul de tickete rezolvate, documentație produse) este indexată. Când un client scrie o întrebare, sistemul recuperează fragmentele relevante și generează un răspuns personalizat. Companiile care au adoptat astfel de asistenți au comunicat public reduceri semnificative ale timpului mediu de rezolvare și creșteri ale ratei de auto-rezolvare.

2. Asistență Juridică: Sistemul de RAG indexează coduri legislative, jurisprudență, interpretări oficiale. Un avocat poate întreba „Ce spune jurisprudența recentă despre dreptul la uitare digitală în România?" și primește un răspuns ancorat în decizii reale, cu citări precise. Tot mai multe platforme de LegalTech din România și UE folosesc o arhitectură similară.

3. Asistență Medicală (cu supervizare umană): Baze de cunoștințe medicale (UpToDate, ghiduri clinice NICE/WHO, studii PubMed) sunt indexate. Medicii folosesc sisteme RAG pentru a verifica rapid interacțiuni medicamentoase sau protocoale de tratament. Esențial, aceste sisteme funcționează ca asistență, nu ca decizie autonomă — supervizarea umană rămâne obligatorie.

4. Documentație Tehnică și Developer Experience: Companiile cu produse software complexe (Stripe, Vercel, Supabase) folosesc RAG pentru a construi asistenți care răspund la întrebări despre API-uri, SDK-uri, configurări. Baza de date este indexul documentației oficiale, iar răspunsurile includ exemple de cod relevante.

5. Aplicații pentru piața românească: Asistent pentru legislația fiscală ANAF (care se schimbă frecvent — TVA 21% din 2025), chatbot pentru Codul Muncii actualizat, asistent pentru ghiduri PNRR, sisteme de Q&A pentru universități bazate pe regulamentele interne.

Când să folosești RAG versus alternative

Decizia de a implementa RAG nu este universală. Iată un framework decizional:

Folosește RAG când:

• Corpusul de documente se actualizează periodic (săptămânal, lunar).
• Ai date private care nu pot fi incluse în antrenament.
• Ai nevoie de răspunsuri verificabile, cu surse citabile.
• Domeniul este factual și precis (juridic, medical, tehnic, reglementări).
• Corpusul este prea mare pentru context window (>100.000 de documente).
• Costul per query trebuie controlat (vs. inserarea a sute de mii de tokeni în context).

Folosește Long Context în loc de RAG când:

• Corpusul este mic (<50 de documente scurte).
• Nu ai infrastructură pentru baze de date vectoriale.
• Simplitatea de implementare este prioritară peste eficiența costurilor.
• Ai nevoie de o soluție rapidă, prototip, MVP.

Folosește Fine-tuning în loc de (sau alături de) RAG când:

• Modelul trebuie să adopte un stil specific (ton juridic, limbaj medical).
• Ai nevoie de performanță superioară pe task-uri specifice (clasificare, extracție).
• Terminologia domeniului este specializată și modelul general o tratează incorect.

Nu folosește RAG când:

• Task-ul este creativ (generare de conținut, brainstorming).
• Problema nu depinde de informații factuale din documente.
• Latența adăugată de retrieval este inacceptabilă (sisteme real-time sub 100ms).

Analiza cost-beneficiu

Implementarea RAG implică costuri reale. Un calcul orientativ pentru un sistem de producție mediu (100.000 de documente, 10.000 de query-uri pe zi):

Costuri de setup:

• Embedding-uri la indexare: ~100.000 documente × 5 chunks/doc × $0.00013/1K tokeni (text-embedding-3-large) ≈ $30-50 (o singură dată).
• Bază de date vectorială managed (Pinecone, Weaviate Cloud): $70-300/lună.
• Dezvoltare pipeline: 2-4 săptămâni inginer senior.

Costuri recurente per query:

• Embedding query: ~$0.0001 per întrebare.
• LLM generation cu context: ~$0.01-0.06 per query (GPT-5.6 Sol la $5/$30, ~2000 tokeni context + răspuns; Opus 5 similar la $5/$25 — cu prompt caching pentru context static, costul efectiv scade considerabil).
• Total per query: ~$0.01-0.06.
• 10.000 queries/zi: ~$100-600/lună.

Comparație cu long context (fără RAG):

• Inserarea a 200.000 tokeni de context per query: ~$0.50-1.00 per query.
• 10.000 queries/zi: ~$5.000-10.000/lună.
• RAG oferă economii de 10-100x pe query.

Aplicații pentru piața românească

România prezintă oportunități unice pentru sisteme RAG, date fiind:

• Legislație în continuă schimbare: Codul Fiscal se modifică anual (TVA 21% din 2025, noi praguri pentru microîntreprinderi). Un RAG indexat pe legislație fiscală actualizată este o necesitate pentru firme de consultanță.
• Multilingvism: Documente oficiale UE în română, corespondență în engleză, terminologie tehnică mixtă. Embeddings multilingve (BGE-M3, multilingual-e5-large) permit căutarea cross-lingvistică.
• Sector public digitalizat: SPV, ANAF, Registrul Comerțului — toate generează documente care pot fi indexate pentru asistenți de ghidare a cetățenilor.
• Domeniul juridic: Codul Civil, Codul Penal, Codul Muncii, jurisprudență ÎCCJ — un corpus imens cu actualizări frecvente, ideal pentru RAG.

Ai acum harta întreagă — de ce RAG există, cum se compară cu alternativele, când are sens și când nu, cât costă și ce valoare produce. Dar între a înțelege de ce funcționează RAG și a construi un sistem care chiar recuperează informația potrivită la momentul potrivit stă mecanica fină a fiecărei componente — și tocmai acolo se decide dacă sistemul tău răspunde cu surse sau halucinează cu încredere. Din lecția următoare intrăm în acea mecanică, începând cu embeddings și reprezentări vectoriale — piesa fără de care nimic din retrieval nu funcționează — iar fiecare lecție adaugă un strat până când vei putea proiecta singur un pipeline RAG complet.