RAG vs Fine-Tuning: Când să folosești fiecare (cu cifre reale)

RAG vs Fine-Tuning: Când să folosești fiecare (cu cifre reale)

Majoritatea sfaturilor despre rag vs fine tuning sar peste singurul experiment care a măsurat ambele abordări pe aceeași sarcină. Balaguer și colaboratorii săi, în arXiv:2401.08406 (citat de 162 de ori), au trecut un set de QA din agricultură prin ambele: fine-tuning-ul a adus peste 6 puncte de acuratețe, iar RAG a mai adăugat 5 peste ele. Tabelul lor 18 arată GPT-4 la 75% brut, 81% după fine-tuning și 86% după fine-tuning cu recuperare. Atunci de ce le spunem în continuare majorității echipelor să înceapă cu RAG? Pentru că prospețimea datelor, citările și calculul de cost de mai jos decid mai multe proiecte decât un decalaj de acuratețe de 1 punct.

Idei principale

• RAG este opțiunea implicită atunci când cunoștințele se schimbă des sau când răspunsurile trebuie să citeze surse; fine-tuning-ul câștigă la format consecvent și latență.
• Costurile fine-tuning-ului se plătesc în avans (antrenament); costurile RAG se plătesc per interogare (embedding-uri plus tokeni de intrare suplimentari).
• Dovezi publicate pe aceeași sarcină: fine-tuning-ul a adăugat 6 puncte de acuratețe, RAG încă 5 pe deasupra, iar hibridul le-a întrecut pe ambele luate separat.
• Rulează cele cinci verificări (prospețimea datelor, exemple etichetate, latență, citări, competențele echipei) înainte să scrii orice cod de antrenament.

Când ar trebui să folosești RAG vs Fine-Tuning? (Verdict rapid)

Alege RAG dacă informațiile tale se schimbă des sau dacă răspunsurile trebuie să poarte citări. Alege fine-tuning dacă ai nevoie de un format de ieșire consecvent și de latență mică și dacă deții sute de exemple etichetate. Folosește-le pe ambele când implementarea se maturizează. RAG modifică contextul pe care îl citește modelul; fine-tuning-ul modifică modelul însuși. Majoritatea echipelor au nevoie de prima variantă, nu de a doua.

O propoziție de reținut: RAG schimbă ce citește modelul; fine-tuning-ul schimbă ce este modelul. Alege în funcție de ce cere de fapt sarcina ta.

Glosarul RAG al NVIDIA definește curat partea de recuperare, dacă vrei varianta din manuale. Definițiile nu-ți aleg însă arhitectura. Dovezile o fac, deci pornește de acolo.

Ce arată dovezile? O sarcină, ambele abordări, măsurate

Singura comparație măsurată pe aceeași sarcină, clasată în top cinci Google pentru această interogare, este Balaguer et al. 2024, un studiu Microsoft Research citat de 162 de ori. Echipa a rulat o sarcină de QA din agricultură printr-un pipeline RAG, printr-un model cu fine-tuning și printr-un hibrid al celor două, apoi a pus GPT-4 să noteze răspunsurile. În configurația lor, fine-tuning-ul singur a întrecut la limită RAG-ul singur, iar combinarea celor două a bătut oricare variantă cu un avans mai mare.

Studiul de caz din agricultură (arXiv:2401.08406)

Studiul, trimis în ianuarie 2024 de Angels Balaguer și 15 coautori, se întreabă ce trebuie pentru a oferi fermierilor informații specifice locației. Pipeline-ul lor extrage informații din PDF-uri, generează perechi întrebare-răspuns din ele și evaluează Llama2-13B, GPT-3,5 și GPT-4 cu și fără recuperare.

Balaguer et al. raportează o creștere de acuratețe de peste 6 puncte procentuale din fine-tuning, cumulativă cu RAG-ul, care a mai adăugat 5 puncte pe deasupra. Pipeline-ul hibrid a întrecut oricare abordare singură. Tabelul lor 18 arată ordinea pentru GPT-4: 75% fără ajutor, 80% cu RAG, 81% cu fine-tuning, 86% cu fine-tuning plus RAG. Observă cât de aproape stau 80% și 81%; decalajul dintre RAG singur și fine-tuning singur este de un punct, în timp ce hibridul este la cinci puncte clar în fața ambelor. Într-un experiment, modelul cu fine-tuning a folosit cunoștințe din alte regiuni geografice ca să răspundă la întrebări specifice regiunii, ridicând similaritatea răspunsurilor de la 47% la 72%.

Dovezile economice

Studiul publicat de Snorkel AI (noiembrie 2022) acoperă partea de cost. Pe un benchmark de clasificare juridică cu 100 de clase (LEDGAR, 80.000 de clauze contractuale), un model RoBERTa cu fine-tuning a egalat un GPT-3 cu fine-tuning, fiind în același timp de 1.400× mai mic, folosind sub 1% din etichetele de referință și rulând la 0,1% din costul de inferență în producție al modelului GPT-3 cu fine-tuning, adică aproximativ o miime. Cost total de construcție: $1.915 cu etichetare programatică, față de $7.418 pentru adnotare manuală plus fine-tuning GPT-3. O rezervă: este clasificare, nu QA generativ, deci tratează rapoartele ca orientare.

Interpretarea noastră

Interpretarea noastră: configurația lor este cel mai prietenos caz pe care fine-tuning-ul îl primește vreodată și totuși a câștigat doar cu un punct. Balaguer et al. au antrenat pe un corpus PDF fix și au evaluat pe același corpus înghețat, deci nimic din ce au învățat greutățile nu a avut cum să se perimeze în timpul experimentului. Majoritatea bazelor de cunoștințe din producție nu stau pe loc așa. Un bot de suport care răspunde la întrebări despre lansarea de săptămâna trecută recâștigă cele 6 puncte la fiecare ciclu de reantrenare, în timp ce indexul care alimentează RAG-ul se actualizează în aceeași după-amiază. De aceea citim un avans de acuratețe de 1 punct ca cel mai slab argument al acestei decizii și prospețimea ca cel mai puternic. Unde nu se generalizează dovezile: rezultatul Snorkel este un benchmark de clasificare, iar niciun studiu nu testează controlul tonului sau al formatului, care rămâne cel mai puternic caz al fine-tuning-ului.

Fine-tuning-ul este răspunsul corect mai rar decât cred echipele; majoritatea proiectelor care spun „fine-tuning" vor să spună de fapt „recuperare".

Cum funcționează RAG și când câștigă?

RAG (retrieval-augmented generation) răspunde din documentele pe care le controlezi, nu din ce a memorat modelul în timpul antrenamentului. Propus inițial de Lewis et al. în 2020, a devenit opțiunea implicită pentru lucrul cu cunoștințe, pentru că informațiile trăiesc în afara modelului: actualizezi indexul și toate răspunsurile se schimbă a doua zi, fără reantrenare.

Pipeline-ul are patru pași:

1. Ingestie. Parsezi documentele (PDF-uri, wiki-uri, tichete) într-un corpus.
2. Segmentare și embedding. Imparți în fragmente de câteva sute de tokeni și convertești fiecare fragment într-un vector cu un model de embedding.
3. Recuperare. La momentul interogării, găsești top-K cele mai similare fragmente, plus potriviri pe cuvinte cheie pentru șiruri exacte, precum SKU-uri și coduri de eroare.
4. Augmentare și generare. Îndesi fragmentele în prompt și lași LLM-ul să răspundă cu sursele atașate.

RAG câștigă pe trei axe: prospețime (reindexare în loc de reantrenare), citări (fiecare răspuns indică fragmentul din care provine) și control al datelor (datele clienților nu intră niciodată într-un antrenament). Dacă vrei ghidul complet de construcție, iată cum construiești o aplicație RAG pas cu pas.

O avertizare despre calitatea recuperării: pipeline-ul este doar la fel de bun ca mixul său de embedding și recuperare. Contextual Retrieval de la Anthropic a măsurat o rată de eșec de 5,7% pentru recuperarea top-20 pe configurații simple, care scade la 2,9% cu embedding-uri contextuale plus BM25 și la 1,9% după adăugarea unui reranker. Dacă interogările cu potrivire exactă tot eșuează, căutarea hibridă (BM25 vs vector) este soluția.

Când câștigă fine-tuning? (Și ce este PEFT?)

Fine-tuning-ul câștigă când problema este cum răspunde modelul, nu ce știe: format de ieșire consecvent, ton de brand sau un buget strict de latență, fără dus-întorsul recuperării. Este și pârghia pentru economia modelelor mici. Rezultatul Snorkel de mai sus, calitate GPT-3 la 0,1% din cost, există doar pentru că cineva a făcut fine-tuning pe un model mic în loc să servească unul mare.

Fine-tuning complet vs PEFT (LoRA / QLoRA)

Fine-tuning-ul complet actualizează fiecare greutate a modelului. Este scump, lent și rar în afara laboratoarelor mari. Aproape toată lumea livrează în schimb PEFT (parameter-efficient fine-tuning). LoRA (Hu et al. 2021) îngheață greutățile de bază și antrenează un adaptor mic de rang scăzut, de obicei 0,1-1% din numărul de parametri. QLoRA adaugă cuantizare pe 4 biți pe deasupra, astfel că un model de 13B încape pe un singur GPU de consum. Un termen înrudit care merită știut: preantrenarea continuă, în care un model continuă preantrenarea pe un corpus brut din domeniu (nesupervizat), înainte de fine-tuning-ul supervizat pe exemple etichetate.

O configurație LoRA minimă, conform documentației Hugging Face PEFT:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Pentru pregătirea datasetului, numărul de epoci și evaluare, vezi ghidul nostru de fine-tuning pas cu pas.

Riscurile sunt reale: supraînvățare pe dataseturi mici (câteva sute de exemple pot memora în loc să învețe), perimare (greutățile îți îngheață cunoștințele la data limită a antrenamentului) și lipsa atribuirii surselor (un model cu fine-tuning nu-și poate arăta chitanțele). Dacă vreuna dintre aceste trei este un factor decisiv, tocmai te-ai convins singur să te întorci la RAG.

RAG vs Fine-Tuning vs Prompt Engineering: unde se încadrează celelalte?

Cele trei sunt o scară, nu rivale. Prompt engineering-ul schimbă instrucțiunile, RAG-ul schimbă contextul pe care îl citește modelul, iar fine-tuning-ul schimbă greutățile. Ghidul propriu de fine-tuning al OpenAI pune fine-tuning-ul ultimul în buclă: mai întâi evaluări, apoi prompturi, antrenament doar când prompturile nu mai sunt suficiente. Două opțiuni mai noi completează trusa.

O confuzie care merită numită: serverele MCP și framework-urile de agenți sunt orchestrare, nu personalizare. Ele decid la ce instrumente și surse poate ajunge modelul; nu schimbă felul în care răspunde modelul. Poți rula un pipeline RAG în interiorul unui agent și poți face fine-tuning pe modelul de sub el, iar multe sisteme din producție le fac pe ambele. Războaiele autocompletării („vs mcp", „vs agenți") sunt erori de categorie.

Este RAG mai ieftin decât fine-tuning? Modelul real de cost

Răspuns scurt: la volume realiste de interogări, da. Factura fine-tuning-ului sosește în avans (date etichetate plus antrenament), în timp ce factura RAG sosește per interogare (embedding-uri plus tokeni de intrare suplimentari). Documentația de fine-tuning OpenAI taxează antrenamentul per token, dar taxele pe tokeni sunt mărunțiș pe lângă costul uman al exemplelor etichetate. Iată calculul pe prețuri de listă publice.

Întrebarea de prag de rentabilitate: câte interogări trebuie ca taxa cumulativă per interogare a RAG să egaleze investiția în fine-tuning?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

La 50.000 de interogări pe lună, asta înseamnă mai bine de zece ani. Pentru majoritatea produselor, investiția în fine-tuning nu se recuperează niciodată doar din economii pe tokeni; faci fine-tuning pentru format și latență, nu ca să bați RAG-ul la cost. Calculul se inversează după milioane de interogări pe lună sau cu contexte recuperate foarte mari. Și observă asimetria: factura fine-tuning se reînnoiește de fiecare dată când deriva datelor forțează o reantrenare, în timp ce RAG-ul scalează liniar cu volumul ori dimensiunea fragmentelor. Dacă cheltuiala per interogare este îngrijorarea reală, începe cu reducerea costurilor LLM per interogare; dacă totuși mergi pe calea antrenamentului, compară instrumentele de fine-tuning înainte să semnezi cecul.

O notă despre prospețime: din iulie 2026, documentația de fine-tuning OpenAI afirmă că platforma găzduită este în curs de închidere pentru utilizatorii noi, iar utilizatorii existenți păstrează accesul la antrenament în lunile următoare. Este încă un motiv pentru care echipele înclină spre PEFT pe modele deschise sau spre RAG simplu.

5 verificări înainte să alegi

Rulează aceste cinci verificări de tip da sau nu înainte să scrii orice cod de antrenament; tiparul răspunsurilor indică RAG, fine-tuning sau hibrid mai sigur decât orice benchmark. Răspunde sincer, apoi numără.

1. Cunoștințele se schimbă mai repede decât ai putea reantrena? Da → RAG. O reantrenare la fiecare actualizare de document nu este un plan operațional.
2. Ai câteva sute de exemple etichetate? Nu → RAG sau prompt engineering. Fine-tuning-ul pe 40 de exemple memorează; nu învață.
3. Există un buget strict de latență? Strâns → înclină spre fine-tuning. Săritura peste dus-întorsul recuperării economisește 50-200 ms.
4. Răspunsurile trebuie să poarte citări sau un traseu de audit? Da → RAG. Modelele cu fine-tuning nu pot indica fragmentul sursă.
5. Echipa are competențe ML plus buget de GPU sau API pentru antrenament? Nu → RAG. Un index pe care îl poți reconstrui bate greutăți pe care nu le poți reantrena.

Majoritar da la 1, 4, 5 → RAG. Majoritar da la 2 și 3, cu un domeniu stabil → fine-tuning. Răspunsuri împărțite sau un produs matur cu trafic real → hibrid (secțiunea următoare). Scopul listei este să decizi pe baza dovezilor, nu pe baza tehnicii la modă în feed-ul tău luna aceasta.

Poți folosi RAG și fine-tuning împreună?

Da, iar pentru implementările mature tiparul hibrid este norma, nu excepția. Fă fine-tuning pentru fluență în domeniu și format de ieșire (partea de „cum"), recuperează pentru faptele de la momentul inferenței (partea de „ce"). Balaguer et al. raportează exact acest lucru pe sarcina lor din agricultură: pipeline-ul hibrid a întrecut oricare abordare singură, cu câștigul de 5 puncte al RAG-ului adăugat peste cele 6 ale fine-tuning-ului.

Calea de maturizare pe care o recomandăm: pornește cu prompt engineering, adaugă RAG în momentul în care răspunsurile au nevoie de date private sau proaspete și adaugă fine-tuning doar când inconsistențele de format sau latența încep să doară în producție. Sari direct la fine-tuning și plătești taxa de antrenament înainte să știi dacă recuperarea a rezolvat deja problema.

Tiparul hibrid nu este un compromis; pentru implementările mature este opțiunea implicită: fine-tuning pentru format, recuperare pentru fapte.

Cum evaluezi câștigătorul?

Alege câștigătorul așa cum ai alege o bază de date: măsoară pe sarcina ta, nu pe baza impresiilor. Rețeta încape într-un paragraf și acoperă cele patru cifre care decid de fapt.

• Set de întrebări reținut. 100-300 de întrebări reale de utilizatori. Nu sintetice, niciodată ceva văzut în timpul antrenamentului sau indexării.
• Fidelitate și corectitudinea răspunsurilor. Fidelitatea întreabă dacă răspunsul se sprijină pe contextul recuperat; corectitudinea răspunsurilor întreabă dacă este de fapt corect. Perechea, popularizată de RAGAS, prinde atât halucinațiile, cât și rateurile de recuperare.
• Latență la p95, nu media. Recuperarea adaugă un dus-întors; măsoară coada.
• Cost per 1.000 de interogări, tokeni plus infrastructură, măsurat, nu ghicit.
• Rerulează la derivă. Documente noi, snapshot nou de model, trimestru nou: rerulează setul.

Defalcarea completă a metricilor, inclusiv instrumentele, se află în ghidul nostru de evaluare LLM.

Despre autor

Mert Batur este co-fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voce/SDR pentru clienți B2B. El scrie despre stiva de instrumente LLM pe care echipa Techsy o folosește efectiv în producție. Conectează-te pe LinkedIn.

Întrebări frecvente

Poți folosi RAG și fine-tuning împreună?

Da. Fă fine-tuning pentru formatul de ieșire și fluența în domeniu și păstrează recuperarea pentru faptele de la momentul inferenței. Balaguer et al. au măsurat acest hibrid pe o sarcină de QA din agricultură și au constatat că a întrecut oricare abordare singură, cu câștigurile de acuratețe cumulându-se. Majoritatea sistemelor mature din producție ajung aici: greutățile pentru „cum", recuperarea pentru „ce".

Când să nu folosești fine-tuning?

Evită fine-tuning-ul când cunoștințele tale se schimbă mai repede decât poți reantrena, când ai mai puțin de câteva sute de exemple etichetate, când răspunsurile trebuie să poarte citări sau trasee de audit sau când nu există buget pentru reantrenare pe măsură ce datele derivă. Aceste patru condiții descriu majoritatea produselor aflate la început de drum, motiv pentru care RAG-ul este de obicei prima mutare corectă.

A fost fine-tuning demontat?

Nu, dar teritoriul lui s-a micșorat. Ferestrele lungi de context și RAG-ul ieftin au absorbit cazuri de utilizare care cereau fine-tuning în 2023. Ce rămâne este real: format de ieșire strict, ton de brand, bugete de latență fără dus-întorsul recuperării și economia modelelor mici. Dacă problema ta este cum răspunde modelul, nu ce știe, fine-tuning-ul este încă instrumentul potrivit.

Când folosești RAG vs fine-tuning?

Folosește RAG când răspunsurile depind de cunoștințe private sau actualizate frecvent sau când ai nevoie de citări. Folosește fine-tuning când ai nevoie de format, ton sau latență consecvente și deții suficiente exemple etichetate. Folosește-le pe ambele când produsul se maturizează. Dacă nu ești sigur, pornește cu RAG: este mai ieftin de anulat decât un antrenament.

Este RAG mai ieftin decât fine-tuning?

La început, da. Costul RAG este per interogare (embedding-uri plus tokeni de intrare suplimentari), în timp ce fine-tuning-ul taxează o dată pentru antrenament și date etichetate, apoi se reînnoiește la fiecare reantrenare. La prețuri de listă publice, pragul de rentabilitate se situează în jur de 6,4 milioane de interogări în exemplul nostru calculat, deci la volume tipice RAG-ul rămâne mai ieftin pe toată durata de viață a produsului.

Este RAG mai bun decât fine-tuning pentru halucinații?

De obicei, dar nu gratuit. RAG-ul sprijină răspunsurile pe fragmente recuperate, deci poți cita surse și audita eșecuri. Recuperarea proastă otrăvește însă răspunsul: Anthropic a măsurat o rată de eșec de 5,7% pentru recuperarea top-20 pe configurații simple, redusă la 1,9% cu recuperare contextuală plus reranking. Fine-tuning-ul, în schimb, poate coace erorile în greutăți fără nicio cale de a le urmări.

RAG vs fine-tuning vs prompt engineering: care este diferența?

Prompt engineering-ul schimbă instrucțiunile pe care le trimiți. RAG-ul schimbă contextul pe care îl citește modelul la momentul interogării. Fine-tuning-ul schimbă greutățile modelului. Fiecare este o intervenție mai mare decât precedenta: încearcă mai întâi prompturile, adaugă recuperare când cunoștințele sunt blocajul și antrenează doar când formatul, tonul sau latența încă dor.

Cum evaluezi performanța RAG vs fine-tuning?

Construiește un set reținut de 100-300 de întrebări reale de utilizatori și notează ambele abordări pe el: fidelitate (se sprijină pe surse?), corectitudinea răspunsurilor (este corect?), latență p95 și cost per 1.000 de interogări. Rerulează setul de fiecare dată când documentele sau snapshot-ul modelului se schimbă. Întrebările sintetice măgulesc ambele sisteme; cele reale le diferențiază.

Fine-tuning vs RAG pentru întrebări multi-hop pe cunoștințe noi?

RAG, cu recuperare mai bună. Mecanismul decide acest punct: un model cu fine-tuning poate raționa doar peste ce au absorbit greutățile lui, deci cunoștințele pe care nu le-a văzut niciodată sunt inaccesibile, oricât de bine ar fi fost antrenat. Recuperarea îi înmânează piesele lipsă la momentul interogării. Captura este că o singură trecere de recuperare adună rar fiecare hop, deci planifică descompunerea interogării sau recuperare iterativă plus un reranker, nu o singură căutare top-K.

Concluzie

Recapitularea, fără ezitări:

• RAG-ul este opțiunea implicită pentru cunoștințe care se schimbă și răspunsuri citate. Fine-tuning-ul este specialistul pentru format, ton și latență.
• Dovezile pe aceeași sarcină (Balaguer et al.) dau fine-tuning-ului +6 p.p. și RAG-ului încă +5 p.p. pe deasupra, hibridul fiind cel mai bun dintre cele trei. Sfatul nostru de a începe cu RAG se sprijină pe prospețime, citări și cost, nu pe acel tabel de scor.
• Calculul de cost înclină în favoarea RAG-ului la volume realiste: pragul de rentabilitate s-a situat în jur de 6,4 milioane de interogări în exemplul nostru calculat.
• Decizi cu cele cinci verificări, nu din obișnuință.

Ai ales RAG? Vezi lista noastră clasată de instrumente RAG pentru stiva din jurul pipeline-ului.