Cum identifică AI concurenții unui brand

Un sistem AI nu ne oferă, de regulă, acces la o listă internă și stabilă de concurenți. Ceea ce putem observa este mai concret: pentru o întrebare, o limbă, o locație, o suprafață și un moment, răspunsul introduce anumite entități în aceeași decizie cu brandul analizat.

Aceste entități sunt candidați competitivi, nu verdicte. Unele sunt substituenți direcți, altele rezolvă doar o parte din problemă, iar altele sunt surse citate, distribuitori, companii-mamă sau exemple fără rol de cumpărare.

Identificarea serioasă înseamnă să păstrăm răspunsul brut, să rezolvăm identitatea fiecărui nume, să clasificăm rolul în scenariu și să verificăm observația prin repetări. Abia după acest pas putem construi un set competitiv pentru măsurare.

Ce înseamnă, de fapt, că AI „identifică” un concurent

Folosim verbul „identifică” ca prescurtare pentru un rezultat observabil: o entitate este prezentată drept opțiune, alternativă, substitut sau termen de comparație pentru aceeași nevoie. Nu afirmăm că modelul păstrează o bază de date internă etichetată „concurenții Brandului X”.

Diferența este importantă. Un răspuns poate proveni din cunoștințele modelului, din informații oferite în conversație, din rezultate web recuperate în acel moment sau dintr-o combinație. Documentația ChatGPT Search spune că întrebarea poate fi rescrisă în una sau mai multe interogări țintite și că pot urma căutări suplimentare. Google descrie query fan-out ca emiterea mai multor căutări conexe pe subteme și surse.

Prin urmare, lista observată este dependentă de context și de traseul de căutare. Ea ne arată cine a intrat în răspuns, nu toate relațiile competitive posibile și nici o taxonomie secretă a sistemului.

Concurența este relativă la nevoia utilizatorului

Două companii nu sunt pur și simplu „concurente” în vid. Ele concurează pentru o nevoie, un buget, o geografie, un tip de client și o etapă de decizie. Un produs poate fi substitut direct pentru echipe mici, dar doar o componentă complementară într-o achiziție enterprise.

Înainte de colectare definim un contract de scenariu:

• problema pe care utilizatorul încearcă să o rezolve;
• categoria și rezultatul urmărit, fără a introduce inutil brandul țintă;
• persona, industria, bugetul și nivelul de maturitate;
• limba, țara sau orașul relevante;
• momentul deciziei: explorare, listă scurtă, validare sau cumpărare;
• suprafața AI, modul de căutare și data observației.

Fișa din articolul despre construirea unei persona pentru audit ajută la menținerea acestei coerențe. Dacă schimbăm simultan limba, bugetul și intenția, nu mai știm care factor a schimbat lista.

De ce aceeași întrebare poate produce alți candidați

Sistemele cu acces la web pot descompune întrebarea, recupera rezultate și sintetiza răspunsul. Ghidul Google pentru funcțiile generative descrie atât retrieval-augmented generation, cât și query fan-out. Documentația Anthropic arată că o solicitare poate declanșa mai multe căutări și filtrarea rezultatelor înainte de răspuns. Perplexity Search API expune căutări multiple și filtre de limbă, regiune și domeniu.

Aceste mecanisme nu sunt identice între produse, dar susțin aceeași regulă de audit: consemnăm suprafața și configurația, deoarece retrieval-ul disponibil poate schimba pool-ul de candidați. O recomandare locală în română poate selecta alte entități decât o analiză globală în engleză.

Și răspunsurile fără căutare pot varia. Generarea nu este un registru determinist. De aceea, articolul despre de ce un singur prompt nu este o măsurătoare rămâne regula de bază pentru eșantionare.

De la nume brut la entitate verificată

Prima extracție păstrează exact forma din răspuns. Nu înlocuim imediat un produs cu firma-mamă și nu unim două nume asemănătoare. Pentru fiecare șir brut creăm o înregistrare separată.

Apoi efectuăm entity resolution:

1. identificăm numele canonic și tipul: organizație, marcă, produs, serviciu sau domeniu;
2. adăugăm aliasuri, abrevieri și variante ortografice;
3. separăm produsul de companie când decizia se poartă între produse;
4. verificăm domeniul oficial și geografia;
5. marcăm omonimele și cazurile insuficient documentate pentru revizuire.

Google Knowledge Graph Search API ilustrează distincția dintre un șir de căutare și entități tipizate. Nu trebuie să folosim acel API ca dependență critică; lecția metodologică este că potrivirea numelui nu dovedește identitatea.

Cinci roluri pe care trebuie să le separăm

După normalizare, clasificăm relația cu nevoia. O taxonomie practică pornește cu cinci roluri:

• substitut direct — poate îndeplini aceeași sarcină pentru același tip de cumpărător;
• substitut parțial — acoperă doar o parte relevantă a rezultatului;
• soluție alternativă — rezolvă nevoia prin alt proces, de exemplu serviciu în loc de software;
• adjacent sau complementar — funcționează împreună cu produsul și nu îl înlocuiește în scenariul respectiv;
• referință fără rol competitiv — sursă citată, marketplace, integrator, companie-mamă sau exemplu istoric.

O a șasea stare este obligatorie: neclar. Dacă propoziția nu arată de ce entitatea este relevantă, nu forțăm clasificarea pentru a completa un tabel. Revizuirea umană și coverage-ul incomplet sunt mai credibile decât precizia inventată.

Mențiunea, citarea și recomandarea sunt evenimente diferite

Un domeniu poate fi folosit ca sursă pentru o afirmație fără ca produsul să fie propus utilizatorului. O companie poate fi menționată într-un avertisment sau exclusă explicit. Un marketplace poate grupa opțiuni fără să fie el însuși alternativă.

Pentru fiecare candidat salvăm verbul relației și pasajul-suport: „alternativă la”, „potrivit pentru”, „se integrează cu”, „sursă”, „nu este recomandat pentru”. Nu clasificăm pe baza simplului fapt că două nume apar în același paragraf.

În răspunsurile cu web, deschidem citările și verificăm dacă sursa susține relația. OpenAI recomandă verificarea informațiilor importante deoarece modelele pot produce afirmații sau citări incorecte; aceeași precauție apare în ghidul oficial despre acuratețe. Pentru a înțelege sursele separat de brandurile recomandate, folosim cadrul din analiza surselor folosite de motoarele AI.

Exemplu: cinci nume într-un răspuns, doar două opțiuni comparabile

Presupunem un scenariu anonim: „Ce soluție ar putea folosi o echipă mică din România pentru a centraliza solicitările clienților, cu buget redus și implementare rapidă?”. Răspunsul conține cinci etichete brute:

Etichetă brută	Dovada din context	Clasificare provizorie	Decizie
Produsul A	propus pentru aceeași echipă și același rezultat	substitut direct	candidat competitiv valid
Produsul B	acoperă doar colectarea mesajelor, nu fluxul complet	substitut parțial	păstrat cu rol distinct
Agenția C	poate prelua operațional întreaga activitate	soluție alternativă	nu se amestecă cu software-ul
Directorul D	pagină citată pentru listarea furnizorilor	referință	exclus din setul competitiv
Numele E	nume ambiguu, fără domeniu sau descriere	neclar	revizuire manuală

Dacă am fi extras automat toate substantivele proprii, am fi raportat cinci concurenți. După verificare avem un substitut direct, unul parțial și o alternativă de alt tip. Aceasta este diferența dintre o listă de mențiuni și o hartă competitivă utilizabilă.

Fișa minimă de dovadă pentru fiecare candidat

O înregistrare auditabilă conține cel puțin:

• ID-ul scenariului și textul promptului;
• suprafața, modul, limba, locația declarată și data;
• răspunsul brut sau un identificator către arhiva sa;
• numele brut și entitatea normalizată;
• tipul entității și relația competitivă;
• pasajul care justifică relația și poziția în răspuns;
• URL-urile citate, dacă există, plus rezultatul verificării lor;
• starea: validat, respins, neclar;
• autorul și data revizuirii, versiunea regulilor de clasificare.

W3C PROV tratează proveniența ca informație despre entitățile, activitățile și agenții implicați în producerea datelor și o leagă de evaluarea calității și reproductibilității. Nu este obligatoriu să implementăm ontologia integral; putem aplica principiul printr-un registru versionat.

Repetarea transformă observația în semnal

Un candidat devine mai interesant când reapare în scenarii eligibile, pe zile diferite sau pe suprafețe diferite, păstrând un rol similar. Totuși, frecvența nu transformă automat relația în adevăr comercial. Poate reflecta surse web dominante, popularitate generală sau formularea prompturilor.

Separăm trei niveluri:

1. observat — apare o dată cu un rol competitiv explicit;
2. recurent — reapare în observații independente din cohorta definită;
3. validat pentru business — un expert confirmă că poate concura realist pentru aceeași nevoie și cumpărător.

NIST recomandă ca măsurarea sistemelor AI să fie legată de contextul de utilizare, să documenteze rezultatele și să includă incertitudinea și evaluarea riguroasă. Aceste principii sunt sintetizate în funcția Measure din AI RMF.

False pozitive și false negative

O falsă pozitivă apare când clasificăm drept concurent o sursă, un partener sau o entitate cu nume similar. O falsă negativă apare când ratăm un produs din cauza aliasului, a unei greșeli de scriere, a unei referințe indirecte sau a faptului că modelul descrie categoria fără nume.

Controlul de calitate include un eșantion revizuit de două persoane, o listă de aliasuri versionată și o matrice de confuzie pentru clasificatorul automat. Dezacordurile nu sunt șterse: ele arată unde taxonomia este prea vagă.

Nu folosim confidence-ul verbal al modelului drept probabilitate. Formulări precum „cea mai bună alternativă” pot suna ferme, dar nu oferă o măsură calibrată și nici o dovadă că toate opțiunile au fost evaluate.

Când putem construi setul competitiv

Setul pentru raportare se construiește numai din entități validate și păstrează rolurile separate. Putem avea un set de substituenți direcți, unul extins cu substitute parțiale și o listă de alternative structurale. Nu le însumăm într-un singur clasament fără să declarăm regula.

Abia aici trecem la măsurare. Articolul despre share of voice în AI explică de ce procentul depinde de unitate, numitor și setul competitiv. Dacă setul conține citări și parteneri tratați ca rivali, orice SOV calculat ulterior este precis doar aritmetic, nu și conceptual.

Checklist înainte să numim o entitate „concurent AI”

• scenariul, persona, limba, geografia și etapa deciziei sunt declarate;
• răspunsul brut și data sunt păstrate;
• numele brut este legat de o entitate verificată, nu doar de un șir similar;
• există un pasaj care arată rolul în aceeași nevoie;
• mențiunea, citarea, integrarea și recomandarea sunt separate;
• sursele sunt deschise și verificate când răspunsul le oferă;
• cazurile neclare rămân neclare până la revizuire;
• observația este repetată într-o cohortă, nu generalizată dintr-un prompt;
• setul final este validat de cineva care cunoaște piața;
• versiunea taxonomiei și modificările setului sunt documentate.

Concluzia utilă nu este „AI crede că acestea sunt toate firmele concurente”. Concluzia corectă este: „în cohorta și condițiile documentate, aceste entități au fost observate și validate în roluri competitive precise”. Această formulare este mai modestă, dar poate fi verificată, repetată și folosită pentru decizii.

Surse

• OpenAI — ChatGPT Search
• OpenAI — Acuratețea și verificarea răspunsurilor ChatGPT
• Google Search Central — AI features and your website
• Google Search Central — Generative AI optimization guide
• Anthropic — Web search tool
• Perplexity — Search API
• Google — Knowledge Graph Search API
• W3C — PROV Overview
• NIST AI RMF Core — Measure

Sursele au fost reverificate la 2 august 2026. Articolul descrie o metodă editorială de identificare și validare a candidaților competitivi; nu afirmă acces la taxonomii interne ale modelelor și nu afirmă existența unei funcții AYSA deja lansate.