Cum detectăm afirmațiile incorecte despre un brand în răspunsurile AI

O afirmație incorectă despre un brand poate suna perfect plauzibil. Poate avea o dată, un procent și chiar o citare. Fluența, precizia aparentă și încrederea tonului nu sunt dovezi.

Detectarea începe înainte de verdict. Capturăm răspunsul, fixăm entitatea, izolăm propozițiile verificabile, aplicăm reguli potrivite tipului de informație și trimitem cazurile semnalate către surse și experți. Scopul nu este un detector „infailibil”, ci o investigație repetabilă care găsește erorile înainte să devină decizii.

1. Ce înseamnă „detectare” în acest audit

A detecta înseamnă a găsi un semnal suficient pentru verificare. Nu înseamnă că un script, un scor sau un al doilea model a stabilit adevărul final.

NIST AI 600-1 folosește termenul confabulation pentru conținut eronat sau fals prezentat cu încredere și include contradicțiile față de input ori față de alte afirmații din același context. Documentul avertizează că și logica sau citările produse pentru justificare pot fi fabricate.

De aceea construim două niveluri:

• semnalare: regula găsește o posibilă problemă;
• adjudecare: un reviewer compară afirmația cu dovezi potrivite și documentează decizia.

Articolul despre ce spune AI despre brand și cum verificăm descrie procesul general. Aici intrăm în mecanismul de detecție.

2. Capturăm observația înainte să o prelucrăm

Dacă păstrăm numai propoziția suspectă, putem pierde negarea, întrebarea, sursa sau o limitare din paragraful anterior. Pentru fiecare rulare salvăm:

• promptul și mesajele anterioare relevante;
• răspunsul integral, fără rescriere;
• citările și adresele exacte afișate;
• motorul și suprafața observată;
• limba, țara și setările cunoscute;
• data, ora și ID-ul intern al rulării;
• captura strict necesară, fără date de cont.

Fișierul brut rămâne imuabil. Extracția, normalizarea și adnotările sunt versiuni derivate. Această separare permite altui reviewer să reconstruiască motivul pentru care un caz a fost semnalat.

Familia W3C PROV tratează proveniența prin entitățile, activitățile și agenții implicați în producerea datelor și susține atribuirea, derivarea, reproducibilitatea și versionarea. Nu trebuie implementată integral pentru a folosi principiul: fiecare transformare trebuie să poată fi urmărită înapoi la observația originală.

3. Fixăm entitatea înainte să verificăm faptele

Multe erori nu sunt invenții pure, ci coliziuni:

• două companii au nume similare;
• marca este confundată cu firma-mamă;
• un produs vechi este tratat ca oferta actuală;
• o funcție disponibilă într-o țară este generalizată global;
• un partener este prezentat drept proprietar;
• un fondator este confundat cu directorul actual.

Fixture-ul de identitate conține numele oficial, aliasurile valide, domeniul, entitatea juridică, produsele, geografiile și perioadele. Nu include toate textele de marketing. Rolul lui este să spună despre cine sau ce discutăm.

O regulă simplă poate semnala un domeniu, oraș sau produs incompatibil. Reviewerul decide apoi dacă răspunsul a greșit entitatea sau dacă întrebarea a fost ambiguă.

4. Izolăm numai afirmațiile care pot fi verificate

Un răspuns conține fapte, opinii, recomandări, comparații și limbaj promoțional. Nu încercăm să verificăm „brandul este interesant”. Putem verifica „serviciul este disponibil în România din luna X”.

La extracție păstrăm:

• subiectul și predicatul;
• negarea;
• data sau perioada;
• valoarea și unitatea;
• geografia, planul sau segmentul;
• verbele modale: „poate”, „trebuie”, „este disponibil”;
• citarea asociată;
• poziția exactă în răspuns.

Fraza „produsul costă 100 lei și include suport în toate planurile” conține cel puțin două afirmații, posibil cu surse și perioade diferite. Divizarea este operațională, dar păstrăm și propoziția originală pentru a nu pierde sensul.

5. Semnale deterministe: verificăm întâi ce poate fi exact

Pentru valori structurate, regulile simple sunt adesea mai ușor de auditat decât un evaluator generativ:

• date: răspunsul folosește o dată în afara perioadei valabile;
• numere: valoarea, moneda sau unitatea nu corespunde sursei;
• intervale: cifra cade în afara limitelor documentate;
• liste: apare o țară, certificare sau funcție absentă;
• URL-uri: adresa este invalidă, redirecționează nepotrivit sau nu conține pasajul;
• versiuni: o funcție dintr-un plan vechi este atribuită planului curent;
• contradicții: două răspunsuri din aceeași cohortă dau valori incompatibile.

Regula trebuie să salveze inputul, referința, operatorul și rezultatul. „Preț diferit” este prea vag; „149 RON în output vs 199 RON, în vigoare de la data X, în pagina oficială Y” poate fi revizuit.

Ghidul OpenAI pentru graders separă verificările exacte, similaritatea textuală și scorarea cu un model. Distincția este utilă metodologic: un fuzzy match poate găsi formulări apropiate, dar nu decide dacă o cifră sau o condiție este adevărată. OpenAI anunță în prezent retragerea treptată a graderelor din fluxurile Evals și fine-tuning pe care le deserveau, deci exemplul ilustrează tipuri de evaluare, nu o recomandare de arhitectură permanentă.

6. Semnale semantice care cer context

Alte probleme nu pot fi reduse la egalitate de șiruri:

• dispare o excepție care schimbă eligibilitatea;
• „poate” devine „face automat”;
• o corelație este rescrisă ca relație cauzală;
• o afirmație despre un plan enterprise este extinsă tuturor clienților;
• un rezultat de laborator este prezentat drept performanță universală;
• o comparație subiectivă este prezentată ca fapt măsurat;
• răspunsul omite condiția fără de care afirmația este înșelătoare.

Un evaluator semantic poate prioritiza aceste cazuri, însă trebuie să returneze motivul, pasajele comparate și incertitudinea. Un scor fără evidență nu este suficient pentru corectarea unei afirmații publice.

7. Groundedness nu este sinonim cu adevărul

Dacă răspunsul reproduce fidel un document vechi, poate fi bine ancorat în context și totuși greșit pentru prezent. Dacă sursa afirmă ceva fals, evaluatorul de groundedness poate confirma corespondența, nu realitatea externă.

Microsoft separă groundedness, relevance, response completeness și retrieval quality. Această separare previne o eroare comună: o citare sau o potrivire cu fragmentul nu dovedește automat că afirmația este actuală, completă și adevărată.

Pentru un claim despre brand întrebăm succesiv:

1. este susținut de contextul citat;
2. contextul citat este sursa potrivită pentru acel tip de fapt;
3. sursa este actuală și aplicabilă entității, pieței și perioadei;
4. există surse primare mai noi sau contradicții;
5. formularea păstrează limitele dovezii.

8. Verificăm citarea la nivel de afirmație și pasaj

Nu este suficient ca domeniul să pară credibil. Pentru fiecare citare verificăm:

• URL-ul se deschide și este versiunea relevantă;
• pagina conține pasajul care susține afirmația;
• pasajul nu spune opusul sau ceva mai limitat;
• data publicării și data efectivă sunt compatibile;
• autorul are competența potrivită pentru acel fapt;
• nu există o sursă primară care actualizează informația.

Articolul despre sursele motoarelor AI explică de ce o citare este un semnal observabil, nu o expunere completă a mecanismului intern. Pentru detecție, citarea este o pistă de verificat.

9. De ce un al doilea model nu poate fi singurul judecător

Un alt model poate ajuta la extragere, grupare și triere, dar poate repeta aceeași eroare, poate prefera o formulare fluentă sau poate inventa propria justificare. A cere „este adevărat?” fără sursă de referință mută problema, nu o rezolvă.

Dacă folosim un evaluator model-based:

• îi furnizăm afirmația, contextul și sursele autorizate;
• cerem citarea pasajului pe care se bazează;
• permitem răspunsul „insuficient pentru decizie”;
• testăm evaluatorul pe exemple etichetate de oameni;
• urmărim false positive și false negative;
• nu escaladăm automat o acuzație publică.

NIST avertizează și asupra automation bias: oamenii pot acorda o încredere nejustificată conținutului automat. Un scor cu două zecimale nu elimină acest risc.

10. Fluxul complet de detectare

Ordinea contează. Dacă extragem înainte să păstrăm outputul brut, pierdem proveniența. Dacă verificăm înainte să fixăm entitatea, putem confirma corect un fapt despre compania greșită. Dacă raportăm înainte de adjudecare, transformăm un detector sensibil într-o sursă de false alarme.

11. Reviewerul uman și regula de adjudecare

Reviewerul nu votează după intuiție. Primește claim-ul, contextul, sursele, rezultatele regulilor și întrebările deschise. Pentru fapte juridice, medicale, financiare sau de securitate, reviewerul trebuie să aibă competența relevantă ori să escaladeze.

Când doi evaluatori nu sunt de acord, păstrăm ambele justificări și apelăm la o regulă stabilită înainte: sursă primară mai nouă, expert de domeniu sau stare „neadjudecat”. Dezacordul nu se șterge din raport.

NIST AI RMF Measure cere metode documentate și repetabile, măsuri ale incertitudinii, monitorizare în context și implicarea experților relevanți. Acest lucru este mai important decât complexitatea detectorului.

12. Fișa unei erori detectate

Registrul minim conține:

• ID-ul observației și al afirmației;
• textul exact și poziția în răspuns;
• entitatea, produsul, piața și perioada;
• regula care a declanșat flag-ul;
• sursa și pasajul de referință;
• data efectivă și data verificării;
• decizia, justificarea și reviewerul;
• severitatea și proximitatea față de decizie;
• frecvența în cohortă;
• remedierea propusă și data retestării.

Nu publicăm date personale din conversații și nu păstrăm mai mult context decât este necesar. Pentru capturi folosim sesiuni separate, fără cont și fără sidebar sau istoric.

13. Eșantionarea care găsește erori, nu doar exemple

Testăm mai multe familii de scenarii:

• identitate și descriere generală;
• preț, planuri și disponibilitate;
• funcții și limitări;
• geografii și limbi;
• comparații și recomandări;
• întrebări cu premisă falsă;
• conversații în care informația apare treptat.

Rulăm aceeași cohortă în mai multe momente și raportăm numitorul. Nu amestecăm branded prompts cu discovery nebranduit și nu alegem numai răspunsurile spectaculoase.

14. Metricile detectorului și metricile brandului

Avem două sisteme de măsură:

1. calitatea detecției: precision, recall pe set etichetat, rata dezacordului, timp de adjudecare;
2. starea observată a brandului: rata afirmațiilor confirmate incorecte, severitate, frecvență, persistență și suprafețe afectate.

Un detector care semnalează tot poate avea recall mare și valoare practică mică. Un detector conservator poate rata erori rare, dar grave. Pragurile se stabilesc după costul fiecărui tip de eroare și se revizuiesc.

NIST AI RMF Playbook recomandă documentarea seturilor, metricilor, uneltelor și proceselor, precum și reevaluarea capacității metricilor de a identifica și elimina erori.

15. Criterii de acceptanță

1. outputul brut și contextul pot fi reconstruite;
2. entitatea și perioada sunt fixate;
3. faptele sunt separate fără pierderea calificatorilor;
4. fiecare flag indică regula și dovada brută;
5. groundedness nu este raportat drept adevăr global;
6. citările sunt verificate la nivel de pasaj;
7. un model evaluator nu este singurul judecător;
8. reviewerul și dezacordurile sunt documentate;
9. metoda este testată pe exemple etichetate;
10. cohorta și fereastra de retestare sunt stabile.

Verdict

Afirmațiile incorecte nu se detectează după cât de ciudat sună răspunsul. Cele mai riscante pot fi exact cele mai fluente.

Protocolul robust păstrează observația, fixează entitatea, izolează faptele, folosește reguli exacte unde poate, tratează evaluarea semantică drept triere, verifică sursele și cere adjudecare umană. Fiecare decizie rămâne legată de un pasaj, o dată și un responsabil.

Rezultatul nu este o listă de „halucinații” adunate pentru efect. Este o serie măsurabilă de erori confirmate, cazuri încă neclare și remedieri care pot fi retestate.

Surse

• NIST AI 600-1 — Generative Artificial Intelligence Profile
• NIST AI RMF Core — Measure și Manage
• NIST AI RMF Playbook — Measure
• W3C — PROV Overview
• Microsoft Foundry — RAG evaluators
• OpenAI API — ghidul Graders

Sursele au fost reverificate la 2 august 2026. Articolul descrie un protocol editorial și nu afirmă existența unei funcții AYSA de detectare, fact-checking sau monitorizare automată.