Drumul de la întrebare la recomandare într-o conversație AI

O recomandare AI nu apare într-un vid. Într-o conversație reală, utilizatorul pornește cu o nevoie incompletă, sistemul poate cere detalii, apar criterii noi, unele opțiuni sunt eliminate, iar o afirmație neverificată poate opri alegerea. Dacă păstrăm numai ultimul răspuns, pierdem tocmai explicația observabilă a traseului.

Drumul corect de analizat nu este un presupus „raționament intern” al modelului. Este succesiunea documentată de mesaje, surse și schimbări de stare. Putem vedea cine a introdus un brand, ce criteriu a apărut, când a fost citată o sursă și de ce o opțiune a intrat sau a ieșit din shortlist. Nu putem vedea automat toate căutările interne, chain-of-thought-ul sau un scor secret de încredere.

Acest articol continuă metodologia din comparația dintre conversații multi-turn și prompturi izolate. Persona se construiește separat, în ghidul pentru auditul de vizibilitate AI, iar situația decizională este fixată prin scenariul realist de recomandare. Aici urmărim tranzițiile unui singur journey.

Journey-ul este o succesiune de stări observabile

Un funnel liniar — întrebare, răspuns, recomandare — este prea sărac. O conversație poate reveni la o etapă anterioară. Utilizatorul poate corecta bugetul, poate transforma un criteriu preferabil într-o condiție obligatorie sau poate cere o dovadă actuală. O opțiune exclusă poate reveni dacă se schimbă o constrângere.

De aceea tratăm journey-ul ca pe o mașină de stări. Pentru candidați folosim stări precum: necunoscut, luat în calcul, pe shortlist, recomandat, exclus și reintrodus. Pentru conversație urmărim: nevoie formulată, clarificare cerută, criteriu adăugat, dovadă verificată, trade-off explicit, recomandare condiționată, recomandare finală, oprire și redeschidere.

Aceste etichete nu descriu mintea modelului. Descriu ce poate reproduce un evaluator din transcript și din sursele afișate.

Turnul, nu paragraful final, este unitatea de bază

Un turn cuprinde inputul utilizatorului și răspunsul primit în acea etapă. Documentația oficială pentru starea conversației în OpenAI API arată cum răspunsurile pot fi legate printr-o conversație sau prin identificatorul răspunsului anterior. Documentația Gemini pentru conversații multi-turn descrie, la rândul ei, folosirea istoricului pentru răspunsurile următoare.

Consecința metodologică este simplă: răspunsul de la turnul patru nu este comparabil cu un răspuns nou, fără istoric, chiar dacă ultimul mesaj al utilizatorului este identic. Contextul acumulat face parte din condiția de test.

Pentru fiecare turn salvăm cel puțin: mesajul, momentul, modelul sau suprafața testată, criteriile noi ori modificate, candidații menționați, sursele vizibile, afirmațiile importante și verdictul de stare. La nivel de conversație păstrăm condiția de pornire, versiunea scenariului și motivul de oprire.

Etapa 1: nevoia apare înaintea listei de branduri

Într-un test de discovery, primul mesaj descrie problema, nu răspunsul dorit. „Avem trei florării și pierdem stoc între puncte” deschide o categorie de soluții. „Compară A cu B și spune-mi că A este mai bun” măsoară altceva: evaluarea unor opțiuni deja introduse.

La această etapă adnotăm scopul, urgența și informația absentă. Dacă modelul enumeră imediat produse, nu presupunem că lista este shortlist. O mențiune inițială poate fi doar o colecție de exemple. Diferența dintre mențiune, citare și recomandare este explicată în taxonomia evenimentelor de vizibilitate AI.

Notăm și cine a introdus fiecare candidat. Un brand numit de utilizator este seeded; unul apărut prima dată în răspuns este descoperit de model în condițiile testului. Cele două situații nu intră în aceeași rată de discovery.

Etapa 2: clarificările transformă adjectivele în criterii

„Ușor”, „ieftin” și „bun pentru noi” nu sunt încă filtre. Clarificările le pot transforma în valori observabile: buget maxim lunar, trei locații, cinci utilizatori, import de catalog, integrare cu facturarea și funcționare fără conexiune.

Nu numărăm doar câte întrebări pune sistemul. Evaluăm dacă întrebarea poate schimba eligibilitatea sau ordinea opțiunilor. O clarificare despre culoarea interfeței valorează puțin dacă decizia depinde de funcționarea offline. În schimb, întrebarea „este o cerință obligatorie sau doar preferabilă?” poate separa un fallback de un candidat neeligibil.

Dacă sistemul nu cere informația critică și recomandă direct, etichetăm premature recommendation. Dacă utilizatorul oferă spontan criteriul, păstrăm proveniența: criteriu adăugat de utilizator, nu descoperit prin clarificare.

Etapa 3: lista de candidați capătă stare și proveniență

Un candidat poate intra prin răspunsul modelului, prin mesajul utilizatorului sau printr-o sursă vizibilă. Aceste căi au semnificații diferite. Pentru fiecare candidat înregistrăm primul turn, actorul care l-a introdus și motivul declarat pentru care este relevant.

Nu transformăm automat ordinea dintr-o listă într-un clasament. „Alte opțiuni de analizat” nu este echivalent cu „cea mai potrivită alegere”. Un candidat ajunge pe shortlist numai când răspunsul îl păstrează explicit după aplicarea criteriilor. Devine recomandat când există o indicație clară de alegere, nu doar o descriere favorabilă.

La fel de importantă este excluderea. Salvăm criteriul care a produs-o și dovada folosită. „Pare că nu are integrarea” este o afirmație neconfirmată, nu o eliminare verificată. O excludere greșită poate ascunde un brand chiar dacă răspunsul final sună coerent.

Etapa 4: afirmațiile decisive trec printr-un gate de dovadă

Prețurile, disponibilitatea regională, integrările și politicile se schimbă. Când o astfel de afirmație decide eligibilitatea, capturăm sursa, data accesării și pasajul sau câmpul relevant. ChatGPT Search poate afișa citări și un panou de surse, dar prezența unui link nu validează singură afirmația.

OpenAI avertizează că un răspuns poate suna sigur și totuși poate fi incorect și recomandă verificarea informațiilor importante. Pentru audit, clasificăm fiecare afirmație decisivă drept confirmată, infirmată sau neconfirmată. „Neconfirmat” nu înseamnă fals; înseamnă că nu avem suficientă dovadă pentru a o folosi ca filtru.

Proveniența trebuie să rămână legată de afirmație, nu doar de conversație în ansamblu. Modelul de proveniență W3C oferă cadrul general: entități, activități și actori care participă la producerea unei informații pot fi documentați pentru evaluarea calității și credibilității.

Etapa 5: shortlist-ul cere eligibilitate și trade-off-uri

Shortlist-ul nu este lista scurtată arbitrar. Fiecare opțiune rămasă trebuie să treacă cerințele obligatorii sau să fie etichetată clar drept condiționată de o verificare. Apoi răspunsul poate compara trade-off-uri: preț contra timp de implementare, flexibilitate contra complexitate, acoperire funcțională contra risc.

Un audit bun păstrează diferența dintre „cel mai bun în general” și „potrivit în condițiile declarate”. Recomandarea ar trebui să includă criteriul decisiv, limitele și alternativa de rezervă. Dacă două opțiuni sunt echivalente pe informația disponibilă, un rezultat multiplu poate fi mai corect decât un câștigător inventat.

Nu atribuim modelului un procent de încredere dacă suprafața nu îl furnizează. Putem adnota fermitatea limbajului — „aș alege”, „merită analizat”, „doar dacă se confirmă” — fără să o confundăm cu probabilitatea de corectitudine.

Exemplu: un criteriu târziu poate anula recomandarea

În exemplul ipotetic, un lanț de trei florării caută software pentru stoc și comenzi. La primul turn, răspunsul introduce candidații A, B și C. Ei sunt doar „luați în calcul”. La al doilea turn apare bugetul maxim; B depășește limita și este exclus.

La al treilea turn, utilizatorul declară obligatorie integrarea cu facturarea din România. C nu are o dovadă actuală, iar D apare târziu printr-o sursă care documentează integrarea. A și D rămân pe shortlist. La al patrulea turn, gestiunea produselor perisabile îl favorizează pe D, cu A ca rezervă.

Apoi utilizatorul adaugă o cerință omisă: punctele trebuie să poată vinde temporar fără internet. Funcția nu poate fi confirmată pentru D sau A. Verdictul corect nu este „D, probabil”. Este: nu există încă un candidat eligibil confirmat; trebuie verificată funcționarea offline sau extinsă lista.

Acest rezultat poate părea mai puțin spectaculos, dar măsoară disciplină. O recomandare care ignoră un must-have produce un scor de vizibilitate frumos și o decizie proastă.

Corecțiile pot invalida traseul anterior

Utilizatorii își amintesc detalii, corectează cifre și schimbă priorități. Dacă bugetul real este 500 de lei, nu 5.000, toate stările dependente de buget trebuie recalculate. Nu păstrăm shortlist-ul vechi și adăugăm doar o notă la final.

În jurnal, înregistrăm criteriul modificat, turnul în care apare corecția și stările invalidate. Putem păstra traseul vechi pentru audit, dar verdictul activ pornește din nou de la ultima stare coerentă. Acest mecanism diferențiază o conversație vie de o succesiune de răspunsuri evaluate separat.

Și sursele se pot învechi. Dacă pagina oficială schimbă prețul sau elimină o integrare, marcăm un series break atunci când modificarea schimbă eligibilitatea. Compararea cu rulări mai vechi rămâne posibilă numai dacă versiunea condițiilor este vizibilă.

Când recomandarea trebuie să se oprească

Oprirea este un rezultat valid în cel puțin patru situații: lipsește o informație critică, nicio opțiune nu îndeplinește toate cerințele, dovada decisivă nu poate fi confirmată sau alegerea are un risc pe care conversația nu îl poate gestiona responsabil.

Motivul opririi trebuie codificat: missing information, no eligible candidate, evidence unavailable sau out of scope. Apoi putem măsura dacă sistemul cere următorul pas potrivit: o clarificare, o verificare externă, o listă extinsă ori consultarea unui specialist.

Abținerea nu este eșecul sistemului când scenariul cere prudență. Eșecul este să forțeze o alegere și să ascundă criteriul nesatisfăcut.

Ce măsurăm pe turn și pe conversație

La nivel de turn putem măsura: dacă a apărut o clarificare relevantă, dacă un criteriu a fost preluat corect, cine a introdus candidatul, dacă o afirmație are sursă și dacă tranziția de stare este justificată. La nivel de conversație măsurăm:

• turnul primei mențiuni și turnul intrării pe shortlist;
• turnul primei recomandări și dacă aceasta a fost prematură;
• proporția criteriilor obligatorii aplicate;
• numărul excluderilor susținute și al celor neconfirmate;
• stabilitatea candidatului după clarificări;
• capacitatea de a revizui verdictul după o corecție;
• motivul de oprire și următorul pas propus.

Rata de recomandare a unui brand are sens numai cu un numitor explicit. Ghidul despre calculul ratei de recomandare separă scenariile eligibile de toate răspunsurile colectate. Într-un journey, eligibilitatea se poate schimba pe parcurs; de aceea păstrăm atât snapshot-ul pe turn, cât și verdictul final.

Fișa minimă pentru adnotarea journey-ului

1. ID și versiune de conversație;
2. scenariu, persona, limbă, geografie și suprafață;
3. turn, actor și textul exact observat;
4. criterii adăugate, modificate sau retrase;
5. candidat și proveniența primei introduceri;
6. stare înainte și stare după turn;
7. motivul tranziției și criteriul decisiv;
8. afirmație, statut factual, sursă și data verificării;
9. tipul rezultatului: shortlist, condiționat, final, abținere;
10. motivul opririi ori condiția de redeschidere.

Doi evaluatori ar trebui să poată aplica schema pe același transcript și să discute diferențele la nivel de câmp. O etichetă vagă precum „răspuns bun” nu permite această verificare.

Ce nu putem concluziona dintr-un singur journey

Un traseu bine adnotat explică o rulare, nu distribuția pieței. Nu demonstrează că toți utilizatorii pornesc la fel, că modelul va repeta răspunsul sau că brandul are o cotă stabilă de recomandare. Pentru astfel de concluzii sunt necesare scenarii multiple, repetări și un baseline stabil.

Nu concluzionăm nici că o sursă citată a fost singura influență asupra răspunsului. Citarea este observabilă; procesul complet de selecție poate să nu fie. NIST AI RMF cere ca măsurarea și interpretarea să rămână legate de context, condiții și limite documentate.

Pentru comparații în timp, folosim același fixture și regulile din ghidul despre baseline și repetări. Când modelul, interfața, scenariul sau sursele se schimbă material, raportăm ruptura seriei.

Verdict

Drumul de la întrebare la recomandare nu este o săgeată dreaptă. Este o serie de tranziții produse de informație nouă, verificări și trade-off-uri. Brandurile pot intra devreme sau târziu, pot fi excluse pe o afirmație greșită, pot reveni după o corecție ori pot rămâne doar recomandări condiționate.

Analiza riguroasă păstrează transcriptul, proveniența, criteriile și starea fiecărui candidat. Ea nu inventează procese interne și nu recompensează o recomandare doar pentru că numește brandul urmărit.

Iar când nicio opțiune nu satisface cerințele obligatorii, cel mai bun rezultat este uneori lipsa unei recomandări. Un sistem util spune ce lipsește și cum se poate redeschide decizia.

Surse

• OpenAI — Conversations API
• OpenAI — Conversation state
• OpenAI — ChatGPT Search
• OpenAI — ChatGPT accuracy and limitations
• Google — Gemini API text generation
• Google — Interactions API
• W3C — PROV Overview
• NIST — AI Risk Management Framework Core

Sursele au fost reverificate la 2 august 2026. Exemplul cu florăriile și candidații A–D este ipotetic; nu reprezintă un benchmark, o recomandare comercială sau o funcție AYSA declarată ca disponibilă.