De Ce Evals: Problema Vibe-Checks-urilor și Costul Calității Negarantate

Oricine poate lipi un prompt într-un API și obține un răspuns care „pare bun”. Foarte puțini pot demonstra, cu numere, că acel sistem rămâne bun după ce schimbi modelul, ajustezi promptul sau crește traficul. Între cele două lumi stă o întrebare aparent banală, dar surprinzător de greu de răspuns riguros când sistemul e deja în producție: funcționează? — și, mai ales, cum o dovedești în fața unei echipe, a unui client sau a unui auditor care nu se mulțumește cu „mi s-a părut ok”. Disciplina care transformă acea impresie într-un răspuns măsurabil, reproductibil și apărabil se numește evaluare — pe scurt, evals — și este exact terenul pe care intri acum.

În 2026, capacitatea de a proiecta și opera evals a devenit unul dintre cele mai căutate skill-uri pentru AI engineers și product manageri tehnici. Motivul este direct: oricine poate lipi un prompt într-un API și obține un răspuns care „pare bun". Foarte puțini pot demonstra, cu numere, că acel sistem rămâne bun după ce schimbi modelul, ajustezi promptul sau crește traficul. Diferența dintre cele două lumi este exact ceea ce vei învăța aici.

Ce Este, de Fapt, un Eval

Un eval este un experiment structurat care măsoară calitatea unui sistem LLM. La nivelul cel mai abstract, are trei componente care se compun într-un lanț:

input  →  output  →  scor măsurabil

• Input — datele care intră în sistem: o întrebare a utilizatorului, un document de rezumat, o cerere de extragere de date.
• Output — ce produce sistemul tău (modelul plus promptul, plus eventual unelte și context).
• Scor măsurabil — o valoare numerică sau categorială care exprimă cât de bun este acel output, calculată de un scorer (numit și grader).

Crucial: un eval nu este o singură rulare. Este o procedură care rulează același sistem peste un set de exemple și agregă scorurile într-o metrică pe care o poți urmări în timp. Postul oficial Anthropic „Demystifying evals for AI agents" formulează ideea esențială: evals transformă întrebarea subiectivă „pare bine?" într-o întrebare obiectivă „cât de des trece testul, conform unui criteriu pe care l-am scris dinainte?".

Vocabularul de Bază

Înainte de orice, fixăm un vocabular comun pe care îl vom folosi în tot cursul. Notebook-ul building_evals din anthropic-cookbook și documentația OpenAI evals folosesc, cu mici variații, exact aceste concepte:

Vom adăuga termeni noi pe parcurs, dar acești cinci sunt scheletul mental. Dacă îi internalizezi, restul cursului devine asamblare de piese cunoscute.

Problema Vibe-Checks-urilor

Modul implicit prin care majoritatea echipelor „testează" un sistem LLM la început se numește, semi-ironic, vibe-check: deschizi interfața, scrii câteva prompturi, citești răspunsurile, dai din cap aprobator și treci la deploy. Este tentant pentru că este rapid și pentru că, la scară mică, funcționează — îți dă un semnal real în primele minute.

Problema nu e că vibe-check-ul e inutil. Problema e că nu scalează și nu e reproductibil. Iată exact unde se rupe:

1. Nu Acoperă Spațiul de Input

Când testezi manual, încerci 5–10 cazuri pe care ți le imaginezi tu. Utilizatorii reali generează mii de variații pe care nu le anticipezi: greșeli de scriere, întrebări ambigue, limbi amestecate, prompturi adversariale, cazuri-limită. Un vibe-check pe „happy path" nu spune nimic despre coadă-lungă (long tail), care este exact locul unde sistemele LLM eșuează spectaculos.

2. Nu Este Reproductibil

Dacă mâine un coleg întreabă „de unde știi că e mai bun decât săptămâna trecută?", răspunsul „l-am testat și mi s-a părut ok" nu este verificabil. Nu există un artefact pe care altcineva să-l ruleze și să obțină același verdict. În inginerie, un test pe care nu-l poți repeta nu este un test, ci o impresie.

3. Judecata Umană Driftează

Aceeași persoană evaluează diferit luni dimineața față de vineri seara. Două persoane diferite au praguri diferite pentru „suficient de bun". Fără un criteriu scris, evaluarea ta este zgomot, nu semnal.

Analogie utilă: A trimite un sistem LLM în producție pe baza unui vibe-check este ca a livra software fără teste automate, bazându-te că „a mers când l-am rulat eu o dată". Industria software a abandonat acea practică acum decenii. Industria AI face același drum acum, iar evals sunt echivalentul testelor automate pentru sisteme non-deterministe.

Costul Calității Negarantate în Producție

„Calitate negarantată" înseamnă că nu ai un mecanism care să-ți garanteze că sistemul rămâne la nivelul așteptat după o schimbare. Costurile apar sub trei forme principale:

Regresii Tăcute (Silent Regressions)

Schimbi o frază în prompt ca să rezolvi un caz, și fără să-ți dai seama strici trei alte cazuri. Pentru că nu ai un eval care să ruleze automat, nimeni nu observă până când un client se plânge. Regresia este „tăcută" pentru că nu există niciun semnal automat care s-o prindă. Un eval bun este, în primul rând, o plasă de siguranță împotriva regresiilor.

Comportament Non-Determinist

Spre deosebire de o funcție pură din software clasic, un LLM poate produce output-uri diferite pentru același input, mai ales la temperature > 0. Asta înseamnă că o singură rulare nu îți spune cum se comportă sistemul în medie. Vibe-check-ul îți arată o singură realizare dintr-o distribuție; evalul îți arată distribuția.

# Iluzia determinismului: aceeași întrebare, două răspunsuri
prompt = "Care e capitala Australiei?"

# Rularea 1 → "Capitala Australiei este Canberra."          ✅
# Rularea 2 → "Capitala Australiei este Sydney, cel mai..."  ❌
#
# Un vibe-check ar fi putut nimeri exact rularea corectă
# și ar fi ratat complet faptul că sistemul greșește uneori.

Drift la Schimbarea Modelului sau a Promptului

Furnizorii lansează modele noi frecvent. Migrezi de la, să zicem, un model de generație anterioară la Claude Opus 4.8 sau GPT-5.5, te aștepți la o îmbunătățire generală — și în multe privințe o primești — dar comportamentul pe cazurile tale specifice se poate schimbă imprevizibil. Un format de output pe care te bazai poate dispărea; un edge-case pe care vechiul model îl rezolva poate să se strice. Fără un eval pe care să-l rulezi pe ambele modele, migrarea este un salt în întuneric. Evalul îți permite să compari obiectiv două sisteme și să iei decizia de migrare cu date, nu cu speranță.

De Ce Este Acesta Skill-ul Momentului

Există un motiv structural pentru care evals au devenit centrale în 2026. Pe măsură ce modelele de bază se uniformizează la vârf (toți furnizorii majori — OpenAI, Anthropic, Google — oferă modele foarte capabile), avantajul competitiv al unui produs AI nu mai vine din accesul la un model bun, ci din capacitatea de a-l adapta, măsura și îmbunătăți continuu pe un caz de utilizare specific. Iar bucla de îmbunătățire continuă are evalul în centru:

măsoară → identifică eșecuri → schimbă (prompt/model/context) → re-măsoară → repetă

Fără pasul „măsoară", bucla nu se închide. De aceea cartea O'Reilly dedicată evals pentru AI engineers, postul Anthropic și cookbook-ul OpenAI converg toate spre aceeași teză: evalul este infrastructura de bază a oricărui produs LLM serios, nu un lux opțional.

Anatomia unui Eval Minim, în Cod

Ca să nu rămânem la abstract, iată cum arată scheletul concret al unui eval, redus la esență. Observă cum cele trei componente — input, output, scor — devin trei linii de logică, iar harness-ul este bucla care le leagă. Notebook-ul building_evals din anthropic-cookbook urmează exact această structură.

# DATASET: lista de exemple, fiecare cu input și (opțional) răspuns așteptat
dataset = [
    {"input": "Care e capitala Franței?",   "asteptat": "Paris"},
    {"input": "Care e capitala Japoniei?",  "asteptat": "Tokyo"},
    # ... zeci sau sute de exemple reprezentative
]

def task(intrebare: str) -> str:
    """TASK: ce face sistemul tău (model + prompt) cu un input."""
    return apel_model(prompt=f"Răspunde concis: {intrebare}")

def scorer(output: str, asteptat: str) -> bool:
    """SCORER: criteriul scris dinainte. Aici, simplă incluziune."""
    return asteptat.lower() in output.lower()

# HARNESS: orchestrarea care produce metrica agregată
treceri = 0
for ex in dataset:
    out = task(ex["input"])
    if scorer(out, ex["asteptat"]):
        treceri += 1

pass_rate = treceri / len(dataset)
print(f"Pass rate: {pass_rate:.1%}")  # PASS RATE: metrica agregată

Acest schelet de ~20 de linii conține deja tot ADN-ul unui eval: un dataset versionabil, un task izolat (poți schimbă modelul fără să atingi restul), un scorer cu un criteriu explicit, un harness care agregă. Tot restul cursului adaugă rigoare peste aceste piese — scorere mai inteligente, statistică, raportare, integrare în CI — dar forma rămâne aceeași. Dacă recunoști aceste patru elemente în orice sistem de eval pe care îl întâlnești, ai înțeles fundamentul.

Trei Mituri Despre Evals, Demontate

În discuțiile de echipă apar recurent câteva idei greșite care întârzie adoptarea unei practici serioase de evaluare. Le clarificăm din start:

Mitul 1: „Evals înseamnă benchmark-uri academice." Fals. Benchmark-urile publice (de tip MMLU și altele) măsoară capabilitatea generală a unui model pe sarcini standardizate. Ele nu îți spun aproape nimic despre cât de bine funcționează sistemul tău pe task-ul tău cu promptul tău. Evalurile despre care vorbim aici sunt specifice produsului: construite de tine, pe datele tale, pentru criteriile tale.

Mitul 2: „Trebuie sute de exemple ca să începi." Fals. Un eval cu 20–30 de exemple bine alese, care acoperă cazurile reprezentative și câteva edge-case-uri cunoscute, este infinit mai valoros decât niciun eval. Începi mic și crești datasetul pe măsură ce descoperi noi moduri de eșec în producție — fiecare bug raportat devine un exemplu nou în suita ta.

Mitul 3: „Evalurile se scriu o dată și gata." Fals. Un eval este un artefact viu. Pe măsură ce produsul evoluează, datasetul crește, criteriile se rafinează, iar suita devine o suită de regresie care te protejează la fiecare schimbare. Un eval abandonat se învechește la fel de repede ca testele neglijate dintr-un proiect software.

De la Eșec la Exemplu: Bucla de Învățare

Cel mai puternic mecanism practic pe care ți-l oferă disciplina evals este transformarea fiecărui eșec într-un activ permanent. Fluxul, folosit de echipele mature, este:

1. Un utilizator raportează un răspuns greșit (sau monitorizarea online îl semnalează).
2. Reproduci cazul și adaugi inputul respectiv în datasetul de eval, cu output-ul corect așteptat.
3. Confirmi că noul exemplu eșuează cu sistemul actual (altfel n-ai prins bug-ul real).
4. Modifici sistemul (prompt, context, model) până când exemplul trece — fără a strica restul suitei.
5. Exemplul rămâne în suită pentru totdeauna, ca gardian împotriva regresiei pe acel mod de eșec.

Acest mecanism este, practic, echivalentul „regression test" din ingineria software clasică, adaptat la sisteme non-deterministe. După câteva luni de operare disciplinată, suita ta de eval devine cea mai valoroasă proprietate intelectuală a produsului: o codificare exactă a ceea ce înseamnă „corect" pentru cazul tău de utilizare, imposibil de replicat de un competitor care nu are istoricul tău de eșecuri.

Ce NU Acoperă Această Lecție (și Unde Vei Găsi)

Pentru a evita confuzia, delimitez clar perimetrul. Această lecție introduce de ce și vocabularul. Nu intră în:

• Taxonomia detaliată a tipurilor de eval (offline/online, determinist/judge) — vine în lecția următoare, Lecția 1.
• Golden datasets — cum construiești seturile de referință — vine în Modulul 1.
• Design de rubrici pentru LLM-as-a-judge — Modulul 2.
• Implementare cu framework-uri specifice (DeepEval, RAGAS, Promptfoo) — Modulele 4–5.

Diferențierea de Alte Cursuri din Catalog

Acest curs se concentrează strict pe evaluarea calității output-ului unui sistem LLM. Ca să nu existe suprapunere mentală cu alte cursuri:

Dacă te interesează cum trimiți date la model, cum aduci context din baza ta de cunoștințe, cum deployezi, sau cum te aperi de atacuri — acelea sunt cursuri-soră. Aici răspundem la întrebarea ortogonală: răspunsul produs este bun, și cum o demonstrezi?

Un Prim Eval Mental

Înainte de a scrie cod, formează reflexul de a gândi în termeni de eval. Pentru orice feature LLM pe care vrei să-l construiești, pune-ți aceste trei întrebări, în ordine:

1. Care este task-ul, în termeni de input → output? Dacă nu poți descrie precis ce intră și ce iese, nu poți evalua.
2. Cum arată un output „bun" versus „rău", concret? Trebuie un criteriu pe care un al treilea om l-ar aplica la fel ca tine.
3. Cum agreg multe verdicte într-o metrică? Un pass rate, o medie de scor, o rată de eroare.

Dacă răspunzi la cele trei, ai deja scheletul unui eval. Restul cursului adaugă rigoare, instrumente și statistică peste acest schelet.

Concluzia Lecției

Vibe-check-urile sunt utile ca prim semnal, dar sunt fundamental inadecvate pentru a garanta calitatea în producție: nu scalează, nu sunt reproductibile, ignoră non-determinismul și nu prind regresiile tăcute. Evals transformă „pare bun" în „trece X% din criteriul pe care l-am scris și pot demonstra asta oricui". Ai acum motivația și vocabularul; ce-ți lipsește este harta — pentru că nu există un singur fel de eval, ci o întreagă familie, iar a alege greșit unealta pentru situație e la fel de costisitor ca a nu evalua deloc. În lecția următoare desenăm acea hartă completă a tipurilor de evaluare, iar de acolo, lecție cu lecție, o umplem cu scorere mai inteligente, statistică și integrare în CI — până când suita ta de eval devine plasa de siguranță pe care te poți baza la fiecare schimbare.