Dacă alegi un prompt sau un model AI doar după câteva exemple „care par mai bune”, riști să optimizezi după impresii, nu după rezultate reale. În practică, multe echipe ajung să schimbe promptul, modelul și setul de exemple în același timp, iar la final nu mai știu ce a produs cu adevărat îmbunătățirea. O testare A/B corectă reduce exact acest tip de confuzie.
Primul pas este să lucrezi cu un dataset fix. Asta înseamnă un set stabil de exemple, ales înainte de test, care reflectă sarcina reală: întrebări de suport, extragere de informații, sumarizare, clasificare sau redactare asistată. Dacă schimbi exemplele pe parcurs, comparația nu mai este curată. Documentația OpenAI pentru evaluări insistă pe ideea de test inputs și ground truth, tocmai pentru ca rezultatele să poată fi comparate pe aceeași bază. La fel, Google recomandă comparații head-to-head pe propriile date, nu pe impresii izolate.
Un dataset bun nu trebuie să fie uriaș, dar trebuie să fie reprezentativ. Include cazuri ușoare, cazuri ambigue și exemple care contează pentru business. Dacă testezi un asistent pentru clienți, nu folosi doar întrebări simple. Pune și cereri incomplete, formulări neclare și situații în care modelul ar trebui să spună „nu știu” sau să ceară clarificări. Important este să fixezi setul înainte de experiment și să nu elimini exemplele „neplăcute” doar pentru că strică scorul.
Al doilea pas este randomizarea. Dacă varianta A este mereu văzută prima, iar varianta B a doua, evaluarea umană poate fi influențată de ordinea în care apar răspunsurile. De aceea, pentru fiecare exemplu, ordinea A/B ar trebui amestecată aleator, iar evaluatorul să nu știe ce prompt sau ce model a produs răspunsul. Dacă faci evaluare automată, păstrează aceleași condiții pentru ambele variante: aceleași inputuri, aceleași reguli de notare, aceeași temperatură sau același set de parametri, unde platforma permite. Dacă schimbi simultan și promptul, și modelul, și temperatura, nu mai testezi o singură variabilă, ci un pachet întreg.
Al treilea pas este să definești dinainte ce înseamnă „mai bun”. Anthropic recomandă definirea clară a criteriilor de succes și folosește explicit A/B testing față de un baseline, adică o versiune anterioară sau un model de referință. În practică, ai nevoie de o metrică principală și de câteva metrici de siguranță. De exemplu, metrica principală poate fi acuratețea clasificării sau rata de răspunsuri acceptate, iar metricile de siguranță pot fi costul pe răspuns, latența și respectarea politicilor interne. Fără această disciplină, există riscul să alegi o variantă care scrie mai frumos, dar halucinează mai des sau costă dublu.
Abia după aceea vine alegerea statistică a câștigătorului. Dacă ambele variante sunt testate pe aceleași exemple și rezultatul este de tip corect/greșit, o metodă potrivită este un test pereche, cum este testul McNemar. Dacă lucrezi cu scoruri continue, de exemplu note de la 1 la 5 sau un scor compus, poți folosi bootstrap pentru a estima intervalul de încredere al diferenței dintre variante. Ideea nu este să impresionezi cu statistică, ci să eviți concluzia falsă că o diferență mică este o victorie reală. Dacă intervalul de încredere trece prin zero sau dacă avantajul este prea mic față de pragul util pentru business, nu ai încă un câștigător clar.
Într-un proiect mic, procesul poate fi foarte simplu: alegi un dataset fix, rulezi varianta A și varianta B pe exact aceleași exemple, randomizezi ordinea în evaluarea umană, stabilești dinainte metrica principală și verifici dacă diferența rezistă statistic. În plus, păstrezi un baseline. Fără baseline, fiecare test pare „mai bun” decât precedentul, dar nu ai o ancoră reală.
Cele mai frecvente greșeli sunt previzibile: modifici datasetul după primele rezultate, te uiți prea devreme și oprești testul când îți convine scorul, compari variante pe categorii diferite de exemple sau ignori costul și latența. Pentru firme, o variantă ușor mai bună la calitate poate fi totuși alegerea greșită dacă dublează costul sau întârzie fluxul de lucru.
Pe scurt, o testare A/B serioasă pentru AI nu începe cu „care răspuns sună mai bine?”, ci cu o disciplină minimă: același dataset, randomizare, criterii clare și o decizie statistică potrivită tipului de metrică. Așa separi preferințele subiective de îmbunătățirile reale și alegi varianta care merită cu adevărat pusă în producție.
Surse
- https://developers.openai.com/api/docs/guides/evals
- https://developers.openai.com/cookbook/examples/evaluation/getting_started_with_openai_evals
- https://platform.claude.com/docs/en/test-and-evaluate/develop-tests
- https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview
- https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/determine-eval
- https://www.statsmodels.org/stable/generated/statsmodels.stats.contingency_tables.mcnemar.html
- https://scipy.github.io/devdocs/reference/generated/scipy.stats.bootstrap.html
