Cum alegi modelul de generare pentru un sistem RAG

Ai retrieval-ul reglat. Documentele sunt curate, chunk-urile au sens, reranking-ul scoate sus pasajele bune. Rămâne întrebarea de care depinde ce citește omul pe ecran: cum alegi modelul de generare care scrie efectiv răspunsul?

E o decizie tratată de obicei prost. Se alege modelul cu cel mai bun scor pe un clasament public, se scrie prompt-ul în jurul lui, iar peste șase luni furnizorul scoate o versiune nouă, schimbă tarifele sau depreciază endpoint-ul — și nimeni nu mai știe dacă alternativa e la fel de bună, fiindcă nu există niciun set de comparație.

Articolul ăsta tratează exact partea aia: pe ce criterii selectezi modelul de generare, cum îl testezi pe corpusul tău înainte să te legi de el, când un model mic e suficient, cum rutezi mai multe modele într-un singur sistem și ce se rupe la migrarea între furnizori. Nu costul total al sistemului — ăla e altă discuție — ci criteriul de selecție.

Ce alegi, de fapt, când alegi „modelul de generare”

Într-un sistem RAG, modelul de generare primește întrebarea utilizatorului plus pasajele scoase de retrieval și produce răspunsul final. Atât. Nu caută, nu decide ce documente sunt relevante, nu compensează un index prost.

Delimitarea contează, pentru că majoritatea deciziilor proaste de model pornesc din confundarea a trei lucruri diferite.

Modelul nu repară un retrieval slab

Dacă pasajele trimise în prompt nu conțin răspunsul, niciun model nu-l poate produce corect. Ori inventează, ori refuză. Un model mai scump inventează mai elegant — atât.

Testul e banal: ia zece întrebări la care sistemul răspunde greșit și citește manual contextul trimis modelului. Dacă răspunsul nu e acolo, problema e în pregătirea bazei de cunoștințe sau în retrieval, nu în model. Schimbarea modelului nu va face nimic, în afară de a-ți muta bugetul.

Trei decizii care se confundă între ele

• Ce model rulează generarea — subiectul de aici.
• Ce îi ceri modelului: prompt-ul de sinteză, formatul, condițiile de refuz. Tratate separat în cum arată un răspuns bun de RAG.
• Cât context îi dai: câte pasaje, în ce ordine, cu ce buget de tokeni — în fereastra de context la LLM.

Când schimbi două dintre ele simultan și rezultatul se îmbunătățește, nu ai învățat nimic. Ai doar o configurație nouă, cu aceeași lipsă de înțelegere.

Alegerea nu e definitivă, dar e costisitoare de schimbat

Modelul e componenta cel mai ușor de înlocuit pe hârtie — o linie în config — și cel mai greu în practică, fiindcă prompt-ul, formatul de output, pragurile de refuz și așteptările utilizatorilor se calibrează în jurul lui. Cu cât amâni mai mult construirea unui set de comparație, cu atât migrarea devine mai scumpă.

Criteriile care contează la selecție

Nu „care e cel mai bun model”, ci „care model trece pragul pe sarcina mea, la costul și latența pe care le pot susține”.

Fidelitatea față de sursă, nu inteligența generală

Sarcina de generare din RAG e îngustă: rescrie ce e în context, fără să adaugi. Capacitatea asta nu crește automat cu „inteligența” modelului.

Leaderboard-ul de halucinații al Vectara, construit exact pe sarcina de rezumare grounded, a arătat un tipar contraintuitiv după trecerea la un set de documente mai lung și mai greu: modelele de reasoning, cele vândute ca fiind cele mai capabile, ies mai prost decât variantele lor de bază. Explicația propusă de Vectara e simplă — modelele care „gândesc mai mult” adaugă inferențe, conexiuni și concluzii care nu sunt în document. Util la analiză. Halucinație la rezumare.

Cifrele exacte diferă de la un snapshot la altul și de la un agregator la altul, așa că nu te lega de un procent anume. Direcția, însă, se confirmă transversal: capabilitatea generală și fidelitatea față de sursă nu se mișcă împreună. Ce înseamnă practic — modul de reasoning e un parametru de testat pe sarcina ta, nu o îmbunătățire garantată. Fondul teoretic e în cum reduce RAG halucinațiile.

Respectarea instrucțiunilor și a formatului

Un răspuns de RAG are de obicei un contract: citează sursele într-un anumit fel, refuză când contextul nu acoperă întrebarea, nu depăși o lungime, întoarce JSON valid când e consumat de altă componentă.

Un model care scrie frumos dar ignoră contractul în 5% din cazuri îți dă 5% erori în producție, indiferent cât de bine sună restul. Măsoară rata de conformare cu formatul separat de calitatea conținutului — sunt eșecuri diferite, cu remedii diferite.

Latență: TTFT, nu doar timpul total

Pentru o interfață conversațională, ce contează e time-to-first-token: cât durează până apare primul cuvânt. Un model care scoate primul token în 400 ms și termină în 6 secunde e perceput ca mai rapid decât unul care tace 3 secunde și termină în 4.

Măsoară pe percentile, nu pe medie. P50 arată bine mereu; utilizatorii se plâng de P95. Și măsoară cu prompt-ul tău real, nu cu unul de test — un context de 8.000 de tokeni și unul de 400 nu au același profil.

Cost: unitatea corectă e răspunsul acceptat

Prețul pe milion de tokeni e o unitate proastă de decizie. Unitatea utilă e costul pe răspuns acceptat: prețul rulării, plus retry-urile, plus escaladările, plus corecțiile umane.

Un model ieftin care greșește formatul și cere un retry la fiecare a cincea cerere poate ieși mai scump decât unul cu tarif dublu care nimerește din prima. Pentru structura de costuri pe linii — embeddings, stocare, inferență, operare — vezi cât costă un sistem RAG. Aici te interesează doar comparația între candidați, la aceeași sarcină.

Merită reținut cât de mare e plaja. Lucrarea FrugalGPT (Chen, Zaharia, Zou, 2023) nota încă de atunci că tarifele API-urilor de LLM diferă cu două ordine de mărime între furnizori. Comparațiile publice de prețuri din 2026 se contrazic între ele pe cifrele exacte, așa că nu prelua un tabel de pe internet ca sursă de adevăr — dar spread-ul e real și e cea mai mare pârghie pe care o ai.

Constrângeri care nu se negociază

Ultima categorie nu are nuanțe: ori bifează, ori modelul iese din listă înainte de orice test.

• Rezidență și procesare a datelor — dacă documentele conțin date personale, furnizorul trebuie să fie compatibil cu regimul tău; vezi RAG și GDPR.
• Licență și deployment — poți rula on-prem sau ești obligat pe API? Un model open-weights schimbă complet ecuația.
• Stabilitate și depreciere — cât timp garantează furnizorul versiunea? Un model care dispare în șase luni îți impune o migrare pe care nu ai planificat-o.
• Limbă — dacă răspunzi în română, testează în română. Scorurile în engleză nu se transferă automat.

De ce clasamentele publice nu decid în locul tău

Clasamentele sunt utile ca filtru inițial. Ca decizie finală, sunt înșelătoare.

Fiecare benchmark măsoară altceva

Rezumarea grounded, faithfulness în RAG, factualitate în domeniu deschis, acuratețea citărilor, calibrarea refuzului — sunt sarcini diferite, cu clasamente diferite. Un model care conduce pe unul poate fi la mijloc pe altul. Nu există „modelul cu cele mai puține halucinații”; există modelul cu cele mai puține halucinații pe testul ăla.

Diferența dintre benchmark și sarcina ta se vede și în interiorul aceluiași benchmark: autorii FACTS Grounding au observat variații pe domenii, cu rezultate mai bune pe conținut tehnic și financiar decât pe medical și juridic.

Clasamentul se schimbă la o reformulare a promptului

Aici e argumentul cel mai tare împotriva copierii unui clasament. Brittlebench, un cadru de măsurare a sensibilității la prompt, aplică perturbări care păstrează sensul — reformulări, typo-uri, alte moduri de a pune aceeași întrebare — și raportează degradări de performanță de până la 12%. Partea importantă: o singură perturbare schimbă ordinea relativă a modelelor în 63% din cazuri.

Cu alte cuvinte, clasamentul pe care te bazezi a fost obținut cu un prompt care nu e al tău, pe date care nu sunt ale tale. Ordinea se poate inversa pe cazul tău fără ca nimeni să fi greșit ceva.

La ce sunt totuși bune

La short-list. Iei clasamentele relevante pentru sarcina ta de generare, elimini modelele care nu bifează constrângerile dure, păstrezi trei-patru candidați și îi treci prin bake-off. Clasamentul restrânge spațiul de căutare; nu îl închide.

Protocolul de bake-off pe corpusul tău

Un bake-off e un test controlat: aceleași întrebări, același retrieval, același prompt, modele diferite. Se poate face într-o zi și îți dă singurul argument care contează la ședința de buget.

Setul de întrebări

Construiește-l din trafic real, nu din imaginație. Ia întrebările efectiv puse sistemului (sau tichetele de suport, dacă sistemul nu e încă live) și acoperă patru categorii, în proporții apropiate de realitate:

• Întrebări simple, cu răspunsul într-un singur pasaj.
• Întrebări care cer sinteză din două-trei documente care nu spun exact același lucru.
• Întrebări la care corpusul nu are răspuns — testul de refuz, cel mai des omis.
• Întrebări ambigue sau prost formulate, exact cum le scriu oamenii.

Șaizeci până la o sută de întrebări sunt suficiente ca să separi candidații. Sub douăzeci, zgomotul e mai mare decât diferența dintre modele.

Îngheață tot ce nu testezi

Aceleași chunk-uri, același reranker, același număr de pasaje, același prompt, aceeași temperatură (sau echivalentul ei la furnizorul respectiv). Salvează contextul trimis fiecărui model, nu doar întrebarea — altfel nu vei putea reproduce rezultatul peste o lună.

Un singur lucru variază: modelul. Dacă vrei să testezi și modul de reasoning, tratează-l ca pe un candidat separat, nu ca pe o setare a aceluiași candidat.

Notarea: oarbă, cu rubrică, cu judecător din altă familie

Trei reguli, în ordinea importanței.

Notează orb. Cine notează nu trebuie să știe ce model a produs răspunsul. Altfel notează brandul, nu textul.

Folosește o rubrică, nu o impresie. Minimum: răspunsul e susținut integral de context (da/nu), citează corect (da/nu), respectă formatul (da/nu), refuză când trebuie (da/nu). Definițiile detaliate ale metricilor stau în cum evaluezi un sistem RAG — aici le folosești ca grilă de comparație, nu le redefinești.

Dacă folosești LLM-as-a-judge, nu lăsa un model să se noteze singur. Autorii FACTS Grounding au măsurat exact biasul ăsta: modelele își notează propriile răspunsuri cu +3,23% în medie față de cum notează răspunsurile altor modele — motiv pentru care au folosit trei judecători din familii diferite și au agregat scorurile. Aceiași autori notează că descalificarea răspunsurilor neeligibile (cele care nu adresează cererea) scade scorul final de factualitate cu 1–5%, ceea ce poate schimba ordinea. Regula practică: judecătorul nu vine din familia niciunui candidat, iar un eșantion din verdictele lui se verifică manual.

Ce înseamnă „câștigă”

Nu clasamentul, ci pragul. Definește înainte de test ce e acceptabil: de exemplu, „minimum 95% răspunsuri susținute de context, zero afirmații inventate pe întrebările fără răspuns, sub 2 secunde TTFT la P95”. Apoi alegi cel mai ieftin model care trece pragul, nu pe cel cu scorul maxim.

Fără prag definit dinainte, orice bake-off devine o justificare pentru modelul pe care îl preferai deja.

Când e suficient un model mic

Mai des decât se crede. Sarcina de generare din RAG e, în majoritatea cazurilor, o rescriere fidelă a unui text pe care modelul îl are sub ochi.

Taxonomia sarcinilor de generare

Împarte traficul real pe rândurile astea. Dacă 80% din întrebări cad în primele trei, plătești inutil un model frontier pentru 80% din volum.

Semnale că ai nevoie de un model mare

• Răspunsul cere combinarea a mai mult de trei-patru surse cu logici diferite.
• Contextul conține contradicții pe care modelul trebuie să le semnaleze, nu să le netezească.
• Sarcina implică numere: comparații, agregări, conversii.
• Instrucțiunile de format sunt complexe și încălcate constant de modelele mici.
• Consecința unui răspuns greșit e mare și nu există revizuire umană.

Modul de reasoning: unde ajută, unde strică

Nu-l activa implicit. Pe sarcini de rescriere fidelă, gândirea suplimentară adaugă material care nu e în sursă — exact tiparul observat pe leaderboard-ul Vectara. Pe raționament în mai mulți pași peste date recuperate, ajută.

Sursele publice se contrazic pe magnitudinea efectului în funcție de tipul de sarcină măsurată, așa că nu prelua nicio cifră ca regulă generală. Testează-l ca pe un candidat separat în bake-off și lasă datele tale să decidă.

Rutarea multi-model într-un singur sistem

Odată ce ai taxonomia de mai sus, întrebarea firească e: de ce un singur model pentru tot?

Trei arhitecturi

Reguli explicite. Rutezi după tipul cererii, tenantul, planul comercial sau lungimea contextului. Rapid, previzibil, ușor de auditat. Rigid și orb la nuanță.

Router învățat. Un clasificator ușor estimează, înainte de generare, dacă modelul mic va rezolva cererea. RouteLLM (Ong et al., 2024) antrenează astfel de routere pe date de preferință, tocmai ca decizia să nu depindă de reguli scrise de mână.

Cascadă cu escaladare. Rulezi întâi modelul ieftin, evaluezi rezultatul și escaladezi doar când nu trece pragul. FrugalGPT a formalizat tiparul: router, estimator de calitate, decizie de oprire. Lucrarea raportează potrivirea performanței celui mai bun model individual cu până la 98% reducere de cost pe sarcinile testate, sau o creștere de 4% a acurateței la același cost.

Nu lua procentele astea ca promisiune pentru sistemul tău — sunt obținute pe benchmark-urile din lucrare. Ia mecanismul: pe un trafic în care majoritatea cererilor sunt ușoare, plata modelului scump doar pentru minoritatea grea schimbă factura substanțial.

Ce plătești pentru rutare

Rutarea nu e gratuită.

• Latență la escaladare: o cerere care trece prin două modele durează cât ambele. Cascada mută costul din bani în timp pentru cazurile grele.
• Două suprafețe de debug: când un răspuns e prost, prima întrebare devine „care model l-a produs?”. Fără logarea deciziei de rutare per cerere, ești orb.
• Două prompturi de întreținut: modelul mic are adesea nevoie de instrucțiuni mai explicite decât cel mare. Deriva între ele e o sursă constantă de bug-uri subtile.
• Un prag de calibrat: estimatorul de calitate e el însuși o componentă care poate greși, în ambele direcții.

Când nu merită

Sub un anumit volum, complexitatea costă mai mult decât economisește. Dacă factura lunară de inferență e mică în raport cu timpul de inginerie, rulează un singur model și revino la rutare când volumul o justifică. Ordinea corectă: un model bun mai întâi, rutare după ce ai date reale de trafic.

Portabilitatea promptului: cum eviți lock-in-ul

Lock-in-ul real nu e contractul cu furnizorul. E prompt-ul, formatul de output și toate ajustările minuscule făcute în șase luni ca să funcționeze cu un anumit model.

Ce se lipește de un furnizor

• Formatul de structured output. Diferențele sunt reale și tăcute. O analiză Requesty pe compatibilitatea structured outputs între furnizori dă un exemplu concret: câmpul name din schemă e cerut de OpenAI, respins de Anthropic și ignorat de Google. Aceeași sursă notează limite de compilare a schemei — la Anthropic, un timeout de 180 de secunde și un plafon de 24 de parametri opționali per cerere.
• Parametrii de generare. Nu se comportă la fel peste tot. O analiză FutureSearch pe diferențele dintre API-uri arată că unele familii de modele nu acceptă deloc temperature, altele cer valoarea 1 când e activat modul de gândire extinsă, iar altele o acceptă dar descurajează valorile diferite de 1.
• Prompt caching. Regulile de cache diferă ca structură și ca preț. Un prompt optimizat pentru cache-ul unui furnizor poate rata complet cache-ul altuia.
• Ambalajul de instrucțiuni. Marcaje, secțiuni, ordinea system/user — convenții care s-au dovedit utile la un model și nu se transferă.

Contractul de prompt: separă instrucțiunea de ambalaj

Ține instrucțiunea într-un singur loc, în text neutru: ce sarcină are modelul, ce reguli de citare, când refuză, ce format. Ambalajul specific fiecărui furnizor (marcaje, câmpuri de schemă, parametri) stă într-un adaptor, separat.

Regulă simplă: dacă schimbarea furnizorului te obligă să rescrii instrucțiunea, nu doar adaptorul, ai amestecat cele două straturi.

Testul de portabilitate

Rulează periodic setul de bake-off pe un al doilea model, de la alt furnizor. Nu ca să migrezi — ca să știi cât te-ar costa. Un sistem care nu poate fi rulat pe un model alternativ fără o săptămână de muncă are un cost de ieșire pe care nu l-a măsurat nimeni.

Migrarea între furnizori: ce se rupe și în ce ordine

Migrarea e rareori dramatică. E o serie de lucruri mici care nu mai merg, descoperite pe rând, în producție, dacă nu le cauți dinainte.

Ce se rupe primul

Migrare în paralel, nu big-bang

Rulează ambele modele pe același trafic, o perioadă. Modelul nou răspunde în umbră; răspunsul lui se logează și se compară, dar nu ajunge la utilizator. Când distribuția scorurilor e comparabilă și nu apar regresii pe categoriile importante, comuți — pe un procent din trafic mai întâi.

Costul e o perioadă de dublă inferență. Beneficiul e că descoperi problemele pe date reale, nu prin tichete de la clienți. Tiparele clasice de eșec în producție sunt strânse în de ce eșuează un sistem RAG în producție.

Întrebări frecvente

Ce model de generare e cel mai bun pentru RAG?

Nu există un răspuns valabil în afara contextului tău. Sarcina de generare din RAG e rescriere fidelă, iar fidelitatea nu urmează automat capabilitatea generală — un model mai „inteligent” poate adăuga inferențe care nu sunt în sursă. Fă un bake-off pe 60-100 de întrebări din traficul tău, cu notare oarbă, și alege cel mai ieftin model care trece pragul.

Cât de des ar trebui să reevaluez modelul?

La fiecare schimbare majoră de versiune la furnizorul curent, la fiecare lansare relevantă a unui concurent și cel puțin o dată pe trimestru. Dacă setul de bake-off e automatizat, reevaluarea costă câteva ore de calcul și îți spune imediat dacă merită să schimbi.

Un model mai mare rezolvă halucinațiile?

Nu. Halucinația într-un sistem RAG apare cel mai des când contextul nu conține răspunsul sau când prompt-ul nu cere explicit refuzul. Un model mai mare poate reduce frecvența, dar nu schimbă cauza. Verifică întâi retrieval-ul și instrucțiunile de grounding.

Merită să antrenez propriul model în loc să aleg unul existent?

Rar, și aproape niciodată ca prim pas. Diferența dintre cele două strategii — și condițiile în care fine-tuning-ul chiar câștigă — sunt tratate în RAG vs fine-tuning. Pentru majoritatea sistemelor de întrebări-răspunsuri pe documente, selecția plus un prompt bun ajung mai departe.

Pot folosi modele diferite pentru limbi diferite?

Da, și e unul dintre cele mai raționale motive de rutare. Performanța pe română nu se deduce din scorurile în engleză. Dacă ai trafic în mai multe limbi, testează separat pe fiecare și rutează pe baza rezultatelor, nu a reputației modelului.

Cum știu că un model nou e mai bun, nu doar mai nou?

Prin același set de comparație, rulat identic. Dacă nu poți răspunde la întrebarea asta cu un tabel de scoruri pe corpusul tău, răspunsul onest e că nu știi.

Alegerea modelului de generare e o decizie de inginerie, nu de marketing: praguri definite dinainte, un set de comparație pe date reale și un cost de ieșire măsurat. Restul fundamentelor — de la embeddings la evaluare — sunt strânse în Fundamentele RAG, iar arhitecturile complete stau pe hub-ul de soluții AI și RAG.