Cum construim scenarii realiste de recomandare

Un scenariu realist de recomandare nu este un prompt lung și nici o întrebare care sună natural. Este o situație decizională versionată: cineva are un declanșator, încearcă să aleagă ceva, operează într-un context, are constrângeri și necunoscute, acceptă anumite dovezi și poate ajunge la un rezultat verificabil.

Promptul este doar felul în care o parte din această situație intră într-un răspuns AI. Dacă scenariul este artificial, zece reformulări elegante vor măsura precis o problemă care nu există. Dacă scenariul șoptește brandul sau rezultatul dorit, auditul devine o demonstrație pregătită să confirme concluzia.

În acest ghid construim fixture-ul de scenariu. Persona este tratată separat în ghidul despre personas pentru audit, iar diferența dintre un prompt izolat și o conversație cu istoric este explicată în analiza single-turn versus multi-turn.

Scenariul descrie decizia, promptul descrie o intervenție

Să comparăm două obiecte:

„Recomandă-mi un program bun de facturare.”

Aceasta este o formulare plauzibilă, dar nu știm ce înseamnă „bun”, ce trebuie decis, unde va fi folosit produsul sau ce ar face o recomandare neeligibilă.

Scenariul din spatele ei poate fi: un magazin online din România trebuie să aleagă în două săptămâni o platformă de facturare pentru aproximativ 2.000 de comenzi lunare; integrarea cu magazinul și exportul datelor sunt obligatorii; bugetul exact este încă necunoscut; afirmațiile despre conformitate și integrare trebuie susținute de surse actuale.

Din același scenariu putem genera un prompt inițial scurt, o clarificare sau un test comparativ. Nu inversăm relația: nu inventăm situația după ce vedem ce răspuns a produs promptul.

Anatomia minimă a unui scenariu

Fișa de bază conține nouă elemente:

1. declanșator — ce s-a schimbat și de ce decizia apare acum;
2. decizie — ce categorie de alegere trebuie făcută;
3. context — geografie, canal, industrie, etapă și condiții relevante;
4. constrângeri — cerințe care pot elimina sau reordona opțiunile;
5. miză — costul unei alegeri greșite și toleranța la risc;
6. informație disponibilă — ce știe persoana la început;
7. necunoscute — ce ar trebui clarificat înainte de recomandare;
8. regulă de dovadă — ce afirmații trebuie susținute și de ce surse;
9. succes și oprire — ce comportament trece testul și când nu se recomandă.

Persona poate furniza obiectivul, nivelul de cunoaștere și toleranța la risc. Topic-ul poate fi „facturare”. Scenariul le pune într-un eveniment concret și leagă testul de o decizie observabilă.

Realismul începe din dovezi, nu din imaginația echipei

Sursele utile includ interviuri, conversații de suport, întrebări din vânzări, căutări interne, formulare, trasee de achiziție și date agregate despre motive de abandon. GOV.UK recomandă ca nevoile să provină din cercetare și ca opiniile nesusținute să rămână ipoteze de validat.

Nu copiem o conversație reală cu date personale într-un fixture public. Extragem structura: ce a declanșat nevoia, ce criteriu a schimbat lista, ce informație a lipsit și ce dovadă a fost cerută. Metoda event cards descrisă de GOV.UK este un exemplu de reconstrucție a experienței prin evenimente, actori, acțiuni și gânduri, cu păstrarea unei urme analizabile.

Pentru fiecare câmp notăm proveniența, data, numărul observațiilor și nivelul de încredere. Un scenariu complet sintetic poate fi util pentru explorare, dar trebuie etichetat „ipoteză”, nu „comportament reprezentativ”.

Un scenariu neutru nu conține brandul pe care vrem să-l găsim

Dacă obiectivul este descoperirea organică, scenariul nu include numele brandului, sloganul lui, funcții copiate selectiv din pagina comercială sau criterii construite ca amprentă unică. Formularea „vreau o platformă exact ca X, dar nu spune X” nu este neutră.

Neutralitatea nu înseamnă să eliminăm criteriile reale doar fiindcă avantajează o opțiune. Dacă integrarea cu un sistem existent este obligatorie și confirmată prin cercetare, ea rămâne. Diferența este proveniența: criteriul vine din nevoie, nu din dorința echipei de a produce un câștigător.

Pentru evaluarea unui set cunoscut putem numi opțiunile, dar marcăm scenariul drept branded sau seeded. Nu îl amestecăm cu scenariile în care motorul trebuie să descopere candidatul.

Nu turnăm toate informațiile în primul mesaj

O fișă completă nu trebuie copiată integral într-un prompt de 300 de cuvinte. Oamenii pornesc adesea cu o cerere scurtă și adaugă informații când sistemul întreabă sau când observă o limită.

Scenariul separă:

• informația declarată de la început;
• informația oferită dacă este cerută;
• informația pe care persoana nu o cunoaște;
• informația care trebuie verificată extern;
• informația pe care testul nu are voie să o inventeze.

Această distribuție permite să verificăm dacă răspunsul cere clarificarea decisivă. Nu dezvoltăm aici întregul journey multi-turn; stabilim doar bugetul informațional al situației.

Criteriul de succes e comportamentul, nu numele ales

Un test contaminat spune: „trece dacă recomandă Brandul A”. Un test valid întreabă dacă răspunsul:

• recunoaște informația insuficientă;
• cere clarificările care pot schimba eligibilitatea;
• exclude opțiunile incompatibile cu cerințele obligatorii;
• separă faptele verificate de presupuneri;
• arată trade-off-urile, nu inventează un câștigător universal;
• citează surse potrivite pentru afirmațiile sensibile la timp;
• formulează recomandarea condiționat când dovezile sunt incomplete;
• refuză alegerea finală dacă lipsește o condiție critică.

OpenAI recomandă în ghidul pentru evaluări obiective și criterii specifice sarcinii, date apropiate de distribuțiile reale și calibrarea evaluatorilor automați cu feedback uman. Același principiu se aplică unui audit de recomandare: rubrica trebuie să măsoare conduita dorită, nu impresia generală.

Construim variante pereche, nu zeci de scenarii fără legătură

O variantă pereche păstrează toate câmpurile constante și schimbă un singur factor cu efect așteptat asupra deciziei. De exemplu:

• scenariul de bază: migrarea poate dura șase săptămâni;
• varianta: migrarea trebuie finalizată în șapte zile.

Dacă lista se schimbă, putem investiga sensibilitatea la termen. Dacă modificăm simultan bugetul, țara, volumul și integrarea, nu știm ce a produs diferența.

Alte perechi utile schimbă geografia, o cerință obligatorie, disponibilitatea unei echipe tehnice sau toleranța la risc. Nu alegem variabila pentru a favoriza un brand; o alegem pentru că cercetarea arată că modifică eligibilitatea ori ordinea criteriilor.

Biblioteca are cazuri tipice, de frontieră și de eșec

Un set format numai din happy paths supraestimează calitatea. OpenAI recomandă includerea cazurilor tipice, edge și adversarial și extinderea continuă a setului cu situații observate în utilizare.

Pentru un audit de recomandare folosim cel puțin:

• core — nevoi frecvente, bine documentate;
• boundary — o valoare aflată chiar lângă pragul de eligibilitate;
• edge — combinație rară, dar plauzibilă și importantă;
• missing critical information — recomandarea ar trebui amânată;
• conflicting constraints — nu există o opțiune care satisface tot;
• stale evidence — prețul, disponibilitatea sau compatibilitatea nu pot fi confirmate;
• unsafe or ineligible — recomandarea ar produce un risc ori ar încălca o cerință.

„Adversarial” nu înseamnă că toate scenariile trebuie să fie atacuri. Înseamnă că verificăm și condițiile în care o metrică superficială ar arăta bine, deși răspunsul ar trebui să se oprească.

Acoperirea nu este produsul cartezian al tuturor variabilelor

Dacă avem cinci roluri, patru bugete, șase țări, trei niveluri de urgență și patru etape, obținem 1.440 de combinații înainte să adăugăm topicuri sau limbi. Majoritatea nu sunt la fel de plauzibile ori importante.

Construim o matrice de acoperire și prioritizăm celulele după frecvență estimată, valoarea deciziei, riscul unei recomandări greșite și incertitudinea actuală. Google PAIR recomandă verificarea potrivirii datelor cu utilizatorii și use case-ul, proveniența, transformările, ipotezele și reprezentativitatea.

Raportăm ce parte din spațiul țintă este acoperită și ce rămâne necunoscut. Nu numim „piață” o bibliotecă aleasă numai de echipa care o măsoară.

Exemplu complet: alegerea unei platforme de facturare

Câmp	Valoare ipotetică
Declanșator	Volumul comenzilor s-a dublat, iar procesul manual produce întârzieri.
Decizie	Selectarea unei platforme de facturare pentru magazinul online.
Context	România, aproximativ 2.000 de comenzi/lună, echipă mică.
Must-have	Integrare confirmată cu magazinul, export al datelor și flux compatibil cu obligațiile locale.
Trade-off	Cost mai mare acceptabil dacă migrarea și suportul reduc riscul operațional.
Necunoscute	Bugetul total și resursele disponibile pentru migrare.
Dovezi	Documentație oficială actuală pentru integrare și conformitate; surse independente pentru experiența de suport.
Succes	Cere necunoscutele, păstrează numai opțiuni eligibile, explică trade-off-urile și marchează ce nu poate verifica.
Stop	Nu oferă o alegere finală dacă integrarea obligatorie nu poate fi confirmată.

Promptul inițial poate rămâne natural: „Ce soluție de facturare ar trebui să analizez pentru magazinul meu online din România?” Fișa completă îi spune evaluatorului ce informație poate furniza ulterior și cum clasifică răspunsul, fără să introducă un brand.

Proveniența și versionarea protejează seria

Fiecare scenariu are ID, versiune, owner, surse, data validării, geografie, limbă, statut și legătura cu nevoia pe care o reprezintă. Separăm schimbările cosmetice de cele semantice.

Corectarea unei virgule nu rupe seria. Schimbarea unui must-have, a țării, a criteriului de succes sau a condiției de oprire poate transforma instrumentul de măsurare. Atunci creăm o versiune nouă și marcăm un series break sau rulăm vechea și noua versiune în paralel.

NIST AI RMF leagă evaluarea de contextul de utilizare, documentarea condițiilor și interpretarea rezultatelor în acel context. Un scor nu rămâne comparabil dacă situația pe care o testează s-a schimbat în tăcere.

Controlul calității înainte de rulare

1. scenariul descrie o decizie reală, nu doar un topic;
2. fiecare câmp important are sursă sau eticheta „ipoteză”;
3. brandul țintă nu este introdus în scenariile de discovery;
4. cel puțin o constrângere poate schimba eligibilitatea;
5. necunoscutele pot declanșa o clarificare sau oprirea;
6. criteriul de succes măsoară comportamentul, nu câștigătorul dorit;
7. există o variantă pereche și motivul schimbării ei;
8. datele personale au fost eliminate sau agregate;
9. doi evaluatori pot aplica rubrica pe aceleași exemple;
10. versiunea și limitele de coverage sunt publicabile.

Dacă scenariul nu trece controlul, nu îl multiplicăm în zeci de prompturi. Întâi reparăm fixture-ul.

Ce nu poate demonstra biblioteca de scenarii

Chiar și o bibliotecă atent construită nu reproduce întreaga distribuție a conversațiilor reale și nu estimează automat cota de piață. Ponderile pot proveni din date incomplete, iar oamenii pot formula aceeași nevoie în moduri neașteptate.

Scenariile sintetice măsoară comportamentul în condițiile declarate. Conversațiile reale, folosite legal și anonimizate, pot îmbunătăți realismul, dar aduc propriile bias-uri de selecție. Rezultatele se raportează pe celule înainte de agregare, iar schimbarea după o intervenție nu este automat dovadă de cauzalitate.

Înainte de a interpreta diferențe, folosim protocolul din ghidul despre limitele unei observații izolate și repetări. Pentru clasificarea mențiunii, citării și recomandării folosim taxonomia evenimentelor din răspuns.

Verdict

Un scenariu realist nu începe cu „scrie un prompt”. Începe cu o decizie observată sau plauzibilă, un context documentat, constrângeri care pot schimba alegerea și o regulă de succes stabilită înainte de rezultat.

Promptul poate varia. Fixture-ul păstrează constant ceea ce vrem să comparăm. Variantele pereche ne arată sensibilitatea la o singură schimbare, iar biblioteca echilibrează cazurile frecvente cu frontierele și eșecurile importante.

Când proveniența, coverage-ul și versiunea sunt vizibile, scenariul devine instrument de audit. Fără ele, rămâne o poveste convingătoare aleasă de evaluator.

Surse

• OpenAI — Evaluation best practices
• OpenAI — Working with evals
• NIST — AI Risk Management Framework Core
• Google PAIR — Data Collection + Evaluation
• GOV.UK — Learning about users and their needs
• GOV.UK — Researching user experiences

Sursele au fost verificate la 2 august 2026. Scenariul de facturare este ipotetic și nu reprezintă un benchmark, o recomandare comercială sau o funcție AYSA deja lansată. Platforma OpenAI Evals este în curs de retragere; documentația citată este folosită numai pentru principii metodologice, nu ca recomandare de produs.