De ce un singur prompt nu este o măsurătoare

Un prompt trimis o dată produce o observație, nu o măsurătoare a vizibilității unui brand în AI. Răspunsul poate fi corect și util. Poate arăta o problemă. Poate genera o ipoteză. Dar nu ne spune singur cât de des apare brandul, în ce scenarii este recomandat sau cum s-ar comporta sistemul într-o populație relevantă de întrebări.

Diferența nu este un joc de cuvinte. O măsurătoare are un obiect explicit, o metodă repetabilă, reguli de clasificare, un numitor, coverage și o concluzie proporțională cu datele. Fără acestea, transformăm o captură de ecran într-un procent imaginar.

1. Mai întâi definim ce vrem să măsurăm

Întrebarea „apare brandul?” poate ascunde obiecte diferite:

• prezența numelui în răspuns;
• citarea unei pagini first-party;
• includerea într-o listă de opțiuni;
• recomandarea explicită pentru un anumit profil;
• acuratețea unei afirmații despre brand;
• poziția relativă într-un set competitiv.

Acesta este measurand-ul: mărimea sau proprietatea pe care vrem să o estimăm. Dacă îl schimbăm după ce vedem răspunsul, rezultatul nu mai răspunde aceleiași întrebări.

Un prompt în care brandul este numit măsoară răspunsul asistat de brand. Un prompt de discovery, fără brand, testează dacă sistemul îl aduce spontan în conversație. Ambele pot fi legitime, dar nu sunt aceeași măsurătoare.

2. Un prompt convenabil introduce bias de selecție

Să presupunem că o firmă vinde software de facturare. Întrebarea „care este cel mai bun program de facturare pentru un SRL românesc cu trei angajați?” reprezintă un scenariu. Nu reprezintă automat toate firmele, toate nevoile sau toate etapele deciziei.

Alți utilizatori pot cere integrare cu un ERP, emitere în mai multe valute, e-Factura, lucru de pe mobil, cost minim sau suport pentru un contabil extern. Brandul poate fi relevant într-un scenariu și nepotrivit în altul.

Dacă alegem după rezultat întrebarea în care brandul apare, estimarea va fi optimistă. Dacă alegem intenționat întrebarea în care lipsește, va fi pesimistă. Repetarea de o sută de ori a unui prompt părtinitor estimează mai precis răspunsul la acel prompt, nu vizibilitatea în întreaga categorie.

3. Aceeași întrebare poate produce rezultate diferite

Sistemele generative pot varia între rulări. Variația poate proveni din eșantionarea răspunsului, din sursele recuperate, din starea instrumentelor, din actualizarea modelului sau din schimbarea infrastructurii. Într-o interfață de consum pot exista și instrucțiuni ori contexte pe care evaluatorul nu le controlează complet.

Exemplul de mai jos nu este un benchmark și nu conține date observate. Arată doar de ce rezultatul unei singure rulări nu poate fi substituit ratei pe care vrem să o estimăm.

Dacă observăm o recomandare într-o singură rulare, rata nu devine 100%. Dacă următoarea rulare nu menționează brandul, rata nu devine 0%. Avem două observații și încă multă incertitudine.

4. Repetările și acoperirea răspund la întrebări diferite

Repetările aceluiași prompt ne ajută să observăm variabilitatea condiționată de acel prompt. Extinderea către mai multe prompturi, personas și scenarii ne ajută să acoperim spațiul decizional.

Un protocol util poate avea două niveluri:

1. mai multe scenarii relevante, stabilite înainte de rezultate;
2. mai multe rulări independente pentru fiecare scenariu.

Nu există un număr universal de rulări care garantează o măsurătoare bună. Necesarul depinde de prevalența evenimentului, variație, precizia dorită, stratificare și cost. Raportăm numărul efectiv de scenarii și rulări, nu ascundem designul în spatele unui scor.

NIST AI 800-3 separă performanța pe un benchmark fix de performanța generalizată la itemi similari. Un set fix poate fi măsurat riguros, dar nu dovedește automat comportamentul pe toate întrebările posibile.

5. „Aceleași condiții” trebuie documentate

Pentru fiecare rulare păstrăm cel puțin:

• textul exact și versiunea promptului;
• persona, scenariul și etapa conversației;
• motorul, modelul afișat și versiunea disponibilă;
• browser, aplicație sau API;
• limba, țara și, dacă este relevant, localizarea;
• instrumentele de căutare ori browsing activate;
• parametrii acceptați de model;
• data, ora, latența și statusul;
• răspunsul brut și citările;
• versiunea rubricii de clasificare.

Nu presupunem că setările rămân stabile. În iulie 2026, documentația Google pentru modelele Gemini recente anunță deprecierea parametrilor de sampling pentru anumite versiuni noi și viitoare. Un protocol care cere un parametru ignorat nu controlează ceea ce pretinde că controlează.

6. Temperatura mică și seed-ul nu rezolvă singure problema

În unele API-uri există controale care pot reduce variația. Ele sunt specifice modelului și interfeței. Nu trebuie transferate automat către aplicația web sau către alt furnizor.

Un exemplu istoric din OpenAI Cookbook arată că aceeași valoare pentru seed, parametri și fingerprint poate produce răspunsuri în mare parte consistente. Documentul spune explicit că determinismul nu este garantat. Exemplul nu este o promisiune pentru fiecare model actual și nici pentru interfața ChatGPT.

Chiar dacă obținem același text de zece ori, rămâne problema selecției: am măsurat un singur prompt. Reproductibilitatea unei observații nu o transformă într-un eșantion reprezentativ.

7. Clasificarea trebuie fixată înainte de rezultate

Două persoane pot interpreta diferit același răspuns. „Poți lua în calcul brandul X” este mențiune, considerație sau recomandare? Răspunsul depinde de rubrica declarată.

Definim etichetele înainte de rulări și păstrăm exemple-limită:

• absent: brandul nu apare;
• menționat: apare fără susținere evaluativă;
• considerat: este prezentat ca opțiune relevantă;
• recomandat: sistemul îl propune pentru contextul dat;
• contraindicat: sistemul recomandă explicit evitarea;
• neclasificabil: răspuns incomplet sau ambiguu.

Evaluatorul ideal nu vede dacă răspunsul provine din valul „înainte” sau „după”. Dacă regulile se schimbă, marcăm o versiune nouă și un posibil series break.

8. Erorile și răspunsurile lipsă fac parte din măsurătoare

Un timeout, un refuz, o eroare de instrument sau un răspuns gol nu dispar din raport. Ele intră în coverage. Eliminarea lor poate face procentul să pară mai bun tocmai când sistemul a devenit mai puțin disponibil.

De exemplu, 12 recomandări din 20 de rulări reușite nu înseamnă același lucru dacă au existat 20 de încercări sau 40. În al doilea caz, jumătate din cohortă nu a produs un răspuns evaluabil.

Convenția completă a numărătorului și numitorului este tratată separat în ghidul despre capcana numitorului în KPI-urile AI.

9. Interfețele nu sunt replici perfecte una ale alteia

Browserul poate avea search, memorie, localizare și instrucțiuni de produs. API-ul poate avea alt model, alt snapshot, alți parametri și alte instrumente. O conversație multi-turn păstrează contextul etapelor anterioare; un prompt izolat nu îl are.

Nu amestecăm rezultatele ca și cum ar proveni din același instrument. Le raportăm pe straturi sau le separăm în studii distincte. Metodologia conversațiilor ramificate este explicată în articolul despre multi-turn versus prompturi izolate.

OpenAI Evals structurează evaluarea prin criterii, sursă de date și configurație de model. Ideea generală este importantă: setul de test și regula de evaluare sunt părți ale măsurătorii.

10. Când este totuși util un singur prompt

O singură rulare este utilă pentru:

• a reproduce o eroare factuală raportată;
• a verifica dacă o interfață funcționează;
• a testa claritatea unui prompt înainte de studiu;
• a descoperi categorii noi pentru rubrică;
• a genera o ipoteză care va fi verificată ulterior.

Formularea corectă este „în această rulare, în aceste condiții, am observat X”. Nu „AI recomandă brandul” și nici „brandul are vizibilitate 100%”.

11. Fișa minimă a măsurătorii

1. întrebarea de măsurare și measurand-ul;
2. populația de utilizatori sau scenarii vizată;
3. regula de selecție a prompturilor;
4. numărul planificat de scenarii și repetări;
5. motor, model, interfață, limbă și geografie;
6. instrumente și configurație acceptată;
7. rubrică versionată și reguli de dezacord;
8. numărător, numitor și coverage;
9. interval sau altă expresie a incertitudinii;
10. limitările și concluzia permisă.

NIST definește incertitudinea de măsurare prin dispersia valorilor atribuite obiectului măsurat și arată că unele componente se estimează din serii de măsurători. O singură observație nu ne arată această dispersie.

12. De la observație la afirmație

Dovadă	Afirmație permisă
o rulare	„Am observat rezultatul X în condițiile documentate.”
repetări ale unui prompt	„În acest prompt, rezultatul X a apărut în n/N rulări.”
cohortă de scenarii	„În setul definit, rata estimată a fost X, cu coverage și incertitudine.”
înainte/după cu control	„Diferența observată față de control a fost X.”

Pentru ultima categorie avem nevoie de protocolul separat despre măsurarea impactului unei intervenții GEO. O serie mai mare nu produce automat cauzalitate.

Verdict

Un prompt este o unitate de observație. Măsurătoarea începe când definim ce estimăm, cum alegem scenariile, câte rulări facem, ce condiții păstrăm, cum clasificăm și ce se întâmplă cu erorile.

Repetările fără acoperire pot fi precise, dar înguste. Acoperirea fără repetări poate rata variabilitatea. Un studiu credibil are nevoie de ambele, în proporția justificată de întrebare și cost.

Cea mai importantă disciplină este formularea concluziei: spunem ce am observat în cohorta definită, cu numitor și incertitudine, nu ce ne-am dori să fie adevărat despre „AI” în general.

Surse

• NIST — Expanding the AI Evaluation Toolbox with Statistical Models
• NIST — Measurement uncertainty
• NIST — Accelerating AI Innovation Through Measurement Science
• OpenAI Cookbook — reproducible outputs and seed
• OpenAI API — Evals
• Google AI for Developers — model metadata
• Google AI for Developers — latest Gemini model changes

Sursele despre produse au fost reverificate la 3 august 2026. Articolul descrie o metodologie editorială și nu afirmă existența unei funcții AYSA de eșantionare sau rulare automată.