Persona, topic sau scenariu: ce controlează fiecare

Persona, topicul și scenariul nu sunt sinonime. Află ce controlează fiecare, cum se combină și cum evităm o matrice de audit redundantă sau artificială.

Publicat 6 septembrie 20269 minute

Ilustrație din hârtie decupată cu un profil de utilizator, o hartă de domenii și un traseu cu praguri care converg spre aceeași întrebare — Persona, topicul și scenariul răspund la întrebări diferite; un audit credibil le conectează fără să le confunde.

Persona spune cine ia decizia și ce îi schimbă alegerea. Topicul spune în ce univers de întrebări măsurăm. Scenariul spune ce încearcă persoana să obțină, în ce context, cu ce constrângeri și prin ce traseu. Dacă folosim cele trei cuvinte ca sinonime, auditul produce prompturi multe, dar acoperire greu de explicat.

Separarea nu este doar semantică. Ea decide ce păstrăm fix într-o comparație, ce variabilă schimbăm, cum agregăm rezultatele și cât de departe putem generaliza. O „persona de ecommerce” amestecă o categorie de utilizator cu un domeniu. Un „scenariu ChatGPT” numește platforma, nu decizia. Iar un topic precum „facturare” nu ne spune dacă utilizatorul explorează, migrează urgent sau verifică o obligație.

1. Cele trei întrebări de control

Înainte de a scrie prompturi, completăm trei propoziții:

Persona: pentru cine evaluăm răspunsul și ce atribute relevante îi schimbă nevoia, eligibilitatea sau criteriile?
Topic: despre ce domeniu și familie de întrebări vrem să măsurăm acoperirea?
Scenariu: ce situație declanșează conversația, ce rezultat urmărește utilizatorul și ce condiții trebuie respectate?

Promptul vine după aceste răspunsuri. El este formularea unei intervenții concrete într-un turn, nu un înlocuitor pentru modelul de test.

2. Persona controlează diferențele relevante dintre utilizatori

În audit, persona este un profil bazat pe dovezi, nu o biografie decorativă. Păstrăm doar atribute care pot schimba recomandarea sau modul în care răspunsul ar trebui construit: rolul și autoritatea de decizie, experiența, accesibilitatea, piața, bugetul, toleranța la risc, constrângerile operaționale și informațiile deja disponibile.

Digital.gov descrie personas drept reprezentări fictive bazate pe cercetare și recomandă legarea lor de dovezile care le-au inspirat. Aceeași sursă separă persona de scenariu: scenariul oferă context narativ experienței unui tip de utilizator.

Ghidul complet despre construirea unei personas pentru auditul AI deține validarea, proveniența și protecția împotriva stereotipurilor. Aici ne interesează exclusiv rolul ei în matrice.

3. Topicul controlează universul semantic

Topicul delimitează domeniul în care colectăm întrebările: de exemplu facturare electronică, software CRM, fonduri de investiții sau livrare ecommerce. El include o definiție canonică, termeni și intenții asociate, subtopicuri, vecinătăți, includeri și excluderi.

Topicul nu este doar un cuvânt-cheie. „CRM” poate conține selecție, migrare, integrare, cost, securitate, adopție și înlocuire. Dacă nu precizăm granița, două ediții ale auditului pot măsura universuri diferite sub aceeași etichetă.

În modelul nostru, topicul este o definiție operațională, nu o taxonomie universală. Îi păstrăm ID-ul, versiunea, limba, piața, sinonimele, familiile de intenții și regulile de includere.

4. Scenariul controlează situația de decizie

Scenariul leagă un trigger de un obiectiv: ce s-a întâmplat, ce trebuie decis, în ce etapă se află utilizatorul, ce informații are, ce constrângeri se aplică și ce înseamnă succesul. El poate cuprinde unul sau mai multe turnuri, dar nu trebuie confundat cu scriptul literal.

GOV.UK recomandă ca nevoile să pornească din cercetare și din problema utilizatorului, nu din soluția pe care echipa vrea să o promoveze. Ghidul permite separarea tipului de utilizator, a triggerului, a rezultatului și a constrângerilor — exact componentele pe care un audit trebuie să le poată controla.

Ghidul pentru scenarii realiste de recomandare explică anatomia și validarea lor. C04-005 nu reia biblioteca de scenarii; arată cum o conectăm la personas și topics.

5. Matricea comparativă

Matrice comparativă între persona, topic și scenariu într-un audit de vizibilitate AI — Model operațional Dosinescu.ro: cele trei dimensiuni se leagă, dar nu se substituie una alteia.

Dimensiune	Întrebarea principală	Controlează	Nu dovedește
Persona	Cine și cu ce constrângeri?	Eligibilitate, criterii, nivel de explicație, risc.	Cât de frecvent este profilul în piață.
Topic	Despre ce univers?	Aria semantică, intențiile și întrebările eligibile.	Ce vrea să facă utilizatorul acum.
Scenariu	Ce decizie, în ce context?	Trigger, obiectiv, etapă, traseu și succes.	Comportamentul tuturor utilizatorilor reali.

6. Exemplu: același topic, personas diferite

Topicul este „platforme de facturare pentru companii din România”. Păstrăm același scenariu: migrarea de la un instrument care nu mai satisface cerințele operaționale, cu termen de 30 de zile.

Schimbăm doar persona:

administratorul unui microbusiness fără echipă financiară caută configurare simplă și suport clar;
managerul financiar al unei companii cu mai multe entități caută control, roluri, audit și integrare;
un consultant care operează pentru mai mulți clienți caută separarea conturilor și flux repetabil.

Dacă recomandările diferă, diferența poate fi legată de atributele controlate ale personas, nu de schimbarea simultană a domeniului sau a urgenței. Exemplele sunt pedagogice; nu reprezintă rezultate observate.

7. Exemplu: aceeași persona, scenarii diferite

Păstrăm administratorul microbusinessului și topicul facturării. Schimbăm scenariul:

explorare fără termen, pentru înțelegerea opțiunilor;
migrare urgentă în 30 de zile;
verificarea unei funcții obligatorii înainte de achiziție;
înlocuirea furnizorului după un incident de suport.

Același utilizator poate accepta o listă largă în explorare, dar are nevoie de eligibilitate și dovezi punctuale în scenariul urgent. Scenariul schimbă sarcina și criteriul de succes, nu identitatea persoanei.

8. Exemplu: același scenariu, topics diferite

Scenariul este „înlocuiesc în 30 de zile un furnizor critic și trebuie să mențin continuitatea”. Îl putem aplica separat la facturare, CRM sau livrare. Structura deciziei rămâne comparabilă, dar universul de candidați, dovezile și criteriile specifice aparțin fiecărui topic.

Nu agregăm automat rezultatele într-un singur procent. O recomandare bună la CRM nu spune nimic direct despre acoperirea topicului de livrare. Topicul este stratul care păstrează sensul rezultatului.

9. De ce produsul cartezian complet este o capcană

Dacă avem 8 personas, 12 topics și 10 scenarii, produsul complet înseamnă 960 de celule înainte de variațiile de prompt, platformă, limbă și repetare. Multe combinații nu sunt plauzibile sau nu schimbă decizia.

Selectăm acoperirea după:

frecvența și importanța nevoilor observate;
impactul unei recomandări incorecte;
segmentele insuficient reprezentate;
incertitudinea din măsurările anterioare;
schimbările de piață, produs sau reglementare;
celulele de frontieră și de eșec care testează limitele.

GOV.UK recomandă prioritizarea întrebărilor de cercetare și alegerea grupurilor relevante, nu inventarierea nediferențiată a tuturor combinațiilor posibile.

10. Schimbă o variabilă odată când vrei explicație

Pentru un test pereche, păstrăm platforma, momentul, topicul, scenariul, formularea de bază și criteriul de evaluare; schimbăm doar atributul de persona pe care vrem să-l examinăm. În alt test păstrăm persona și topicul, dar schimbăm urgența scenariului.

Asta nu elimină toate sursele de variație ale sistemului AI, însă împiedică explicațiile fabricate după rezultat. Dacă schimbăm simultan rolul, bugetul, topicul, limba și promptul, nu mai știm ce diferență interpretăm.

11. Promptul este instanța, nu proiectarea testului

Din aceeași celulă persona–topic–scenariu putem deriva un prompt izolat, un script multi-turn ori un protocol adaptiv. Promptul trebuie să transporte doar informația disponibilă legitim în acel moment al journey-ului.

Comparația dintre multi-turn și prompturi izolate arată că cele două formate măsoară lucruri diferite. Separarea dimensiunilor rămâne valabilă în ambele: formatul conversației nu transformă topicul în scenariu și nu validează persona.

12. Contextul de evaluare limitează afirmația

Proiectul NIST AI 800-2 cere ca afirmațiile despre evaluare să reflecte scopul și contextul și ca evaluatorul să explice de ce itemii seamănă cu sarcinile reale pe care pretinde că le reprezintă. O listă de prompturi nu primește validitate externă doar pentru că este mare.

NIST AI 800-3 distinge rezultatul pe un set fix de itemi de generalizarea către un univers mai larg. În matricea noastră, fiecare celulă trebuie să spună dacă descrie strict itemii testați sau un eșantion construit pentru o populație definită.

13. Reguli prea vagi sau prea restrictive schimbă ce măsurăm

Un scenariu vag poate permite modelului să inventeze buget, piață sau cerințe. Unul supraîncărcat poate dicta implicit furnizorul „corect”. O persona cu zeci de detalii irelevante adaugă zgomot; un topic fără excluderi lasă evaluatorii să codeze diferit aceeași întrebare.

NIST CAISI arată că regulile ambigue pot face evaluarea să măsoare interpretarea ori exploatarea sarcinii, iar reguli prea restrictive pot elimina strategii legitime. Contractul trebuie să conțină toate și numai condițiile pe care vrem efectiv să le testăm.

14. Cum agregăm fără să pierdem cauza

Raportăm mai întâi pe dimensiunea care a fost variată:

pe persona: diferențe de eligibilitate, recomandare și calitatea explicației;
pe topic: acoperire, citări, acuratețe și goluri semantice;
pe scenariu: performanță pe etape, constrângeri și rezultate de decizie;
pe celulă: numărul de observații, erori, coverage și incertitudine.

Abia după acestea calculăm totaluri ponderate, iar ponderile trebuie să aibă proveniență. O medie generală nu trebuie să ascundă că un segment critic eșuează sau că un topic domină numitorul.

15. Contractul minim al matricei

Câmp	Ce salvăm
Persona	ID, versiune, dovadă, atribute active și excluderi.
Topic	ID, definiție, intenții, includeri, excluderi, limbă și piață.
Scenariu	Trigger, obiectiv, etapă, constrângeri, succes și failure condition.
Protocol	Platformă, suprafață, dată, format, repetări și sesiune.
Evaluare	Codebook, unitate, numitor, reviewer și incertitudine.
Proveniență	Sursa fiecărui câmp, owner și data următoarei revizuiri.

People + AI Guidebook al Google PAIR pornește proiectarea AI de la nevoi și definirea succesului. În audit, acest principiu înseamnă că matricea trebuie să poată explica ce nevoie reprezintă fiecare celulă și ce rezultat ar conta pentru utilizator.

16. Checklist înainte de rulare

Putem spune într-o frază cine, despre ce și în ce situație?
Atributele personas schimbă plauzibil decizia?
Topicul are includeri, excluderi și versiune?
Scenariul are trigger, obiectiv, constrângeri și succes?
Promptul evită introducerea răspunsului dorit?
Știm ce variabilă schimbăm și ce păstrăm fix?
Celulele selectate au justificare prin dovezi, risc sau impact?
Protocolul permite comparație între ediții?
Agregarea păstrează rezultatele pe fiecare dimensiune?
Afirmațiile finale rămân în limitele cohortei testate?

Verdict

Persona, topicul și scenariul nu sunt trei denumiri pentru același prompt. Persona controlează diferențele relevante dintre utilizatori, topicul delimitează universul semantic, iar scenariul definește situația de decizie și traseul către rezultat.

Un audit bun le conectează prin ID-uri și proveniență, selectează celulele după dovezi și risc și schimbă controlat variabilele. Astfel putem explica de ce un rezultat diferă, ce acoperire lipsește și până unde este legitimă generalizarea.