Ce este o entitate pentru AI și motoarele de căutare. Studiu de caz: de ce internetul mă asociază cu porumbul

Alex Matescu · Fondator și coordonator AI Visibility Lab

Publicat: 5 august 2026 · Actualizat: 11 august 2026 · Ultima verificare factuală: 19 august 2026

O identitate digitală devine mai ușor de dezambiguizat atunci când aceeași persoană, aceleași variante legitime de nume, aceleași roluri și aceleași surse sunt legate coerent între ele. Structured data, paginile canonice de identitate și sursele independente pot contribui la această coerență, dar niciuna nu garantează singură felul în care Google sau un sistem AI va reprezenta persoana.

Aceasta este miza corectă a studiului.

Nu pot vedea mecanismul intern prin care Google, ChatGPT sau alt sistem decide cine este „Alex Matescu”. Pot însă observa ce documente apar, ce informații sunt publice, cum sunt legate între ele și unde identitatea mea este coerentă sau fragmentată.

Această diferență dintre observație și mecanism presupus este esențială pentru orice analiză serioasă de entity visibility.

Testul pe propriul meu nume

În august 2026 am căutat propriul nume împreună cu localitatea, pentru a vedea ce informație publică domină rezultatele observabile.

Primele rezultate erau despre un stand de porumb cu arome pe care l-am deschis în Sibiu. Povestea fusese preluată de publicații locale și economice.

În aceeași căutare apăreau și rezultate nerelevante sau doar aproximativ apropiate de numele meu:

• persoane cu nume similare;
• o pagină de dezambiguizare pentru un nume apropiat;
• rezultate influențate de termenul geografic din query.

În schimb, în rezultatele observate atunci apăreau mult mai puține informații despre:

• inginerie de sisteme;
• activitatea de scriere;
• AI Visibility Lab;
• GEO/AEO.

Ce demonstrează această observație

Demonstrează că, pentru query-ul și momentul respectiv, episodul antreprenorial era mai bine reprezentat în rezultatele publice observabile decât alte părți ale identității mele.

Ce NU demonstrează

Nu demonstrează că:

• Google Knowledge Graph mă clasifică intern drept „vânzător de porumb”;
• Google are un singur nod despre mine;
• un LLM folosește exact aceeași reprezentare;
• presa „cântărește” de un anumit număr de ori mai mult decât site-ul propriu;
• numărul brut de mențiuni determină identitatea.

SERP ranking, entity resolution și generarea unui răspuns AI sunt procese diferite și nu trebuie confundate.

De la „strings” la „things”

În 2012, Google a descris Knowledge Graph prin formula devenită celebră „things, not strings”.

Google explica atunci că o interogare precum „Taj Mahal” nu este doar o secvență de caractere: poate indica monumentul, un muzician, un cazinou sau altă entitate. Knowledge Graph a fost prezentat ca un model al entităților din lumea reală și al relațiilor dintre ele.¹

Aici se află diferența esențială.

String

Un string este text:

Alex Matescu

Entitate

Entitatea este persoana reală la care acel text se referă.

Aceeași persoană poate apărea sub:

• nume complet;
• formă scurtă;
• variante istorice;
• username;
• profil social;
• roluri profesionale diferite.

Un matching lexical simplu nu este suficient pentru a decide întotdeauna la care persoană se referă o mențiune ambiguă. Entity-aware systems folosesc context, relații, surse și alte semnale pentru dezambiguizare.

Entity resolution, entity linking și entity disambiguation

În literatura tehnică apar mai mulți termeni apropiați:

• entity recognition — identificarea unei mențiuni de tip persoană, organizație, loc etc.;
• entity linking — legarea mențiunii de o entitate cunoscută;
• entity disambiguation — alegerea entității corecte dintre mai multe candidate;
• entity resolution — termen mai larg folosit pentru reconcilierea înregistrărilor sau mențiunilor care descriu aceeași entitate reală.

În acest articol folosesc rezolvarea entității ca termen umbrelă pentru problema practică:

„Aceste mențiuni, profiluri și roluri aparțin aceleiași persoane sau unor persoane diferite?”

Nu presupun că Google sau OpenAI folosesc exact această taxonomie internă. Definițiile termenilor de bază — entitate, sursă de încredere, citare — sunt reunite și în glosarul GEO/AEO.

Framework AI Visibility Lab: trei tipuri de eșec

AI Visibility Lab folosește trei categorii practice pentru auditarea unei identități digitale:

1. coliziune;
2. fragmentare;
3. contaminare.

Aceasta este o taxonomie proprie de lucru, nu terminologie oficială Google sau OpenAI.

1. Coliziunea

Coliziunea apare atunci când aceeași mențiune sau mențiuni foarte apropiate pot indica mai multe persoane reale.

Exemple:

• două persoane cu același nume;
• forme ortografice apropiate;
• transliterări;
• inițiale;
• variații istorice ale numelui.

În cazul meu, rezultatele observate includeau persoane cu nume apropiate și rezultate nerelevante.

Ce putem spune

Există ambiguitate în spațiul public al numelui.

Ce nu putem spune

Nu putem afirma că sistemul:

• „fuzionează obligatoriu” persoanele;
• „alege automat persoana cu cele mai multe mențiuni”;
• aplică o regulă simplă de popularitate.

Sistemele pot păstra mai multe candidate, pot folosi contextul query-ului și pot ajunge la rezultate diferite în suprafețe diferite.

Obiectivul practic

Nu poți elimina existența omonimilor.

Poți însă reduce ambiguitatea propriei identități prin:

• nume consecvent;
• pagină de profil;
• relații explicite între profiluri;
• roluri descrise clar;
• structured data corectă;
• surse externe care identifică neechivoc persoana.

2. Fragmentarea

Fragmentarea este cazul în care informațiile despre aceeași persoană există, dar relațiile dintre ele sunt insuficient de clare.

De exemplu, aceeași persoană poate apărea public ca:

• inginer;
• antreprenor;
• autor;
• consultant;
• participant la un proiect.

Faptul că aceste roluri există separat nu este o problemă în sine.

O persoană poate avea multe roluri legitime.

Problema apare atunci când paginile și profilurile nu oferă suficiente legături pentru a arăta că toate descriu aceeași persoană.

Formulare corectă

Dacă sursele prezintă roluri diferite fără legături suficiente între ele, unui sistem îi poate fi mai greu să stabilească faptul că toate mențiunile descriu aceeași persoană.

Nu există o metrică publică de tip:

„cinci roluri separate valorează mai puțin decât un rol repetat de cinci ori”.

Acea formulare ar inventa o unitate de „entity authority” care nu este documentată.

3. Contaminarea

Contaminarea este situația în care un sistem atribuie unei persoane o informație aparținând altei persoane.

Exemplu ipotetic:

un răspuns combină ocupația unei persoane cu compania sau biografia unui omonim.

Fenomenul poate apărea în sisteme de search, knowledge extraction sau generare atunci când dezambiguizarea eșuează.

Important:

contaminarea este un rezultat observabil; mecanismul exact care a produs-o nu poate fi dedus automat din răspuns.

De ce episodul cu porumbul apare atât de clar

În cazul observat, numele meu era asociat cu episodul antreprenorial în mai multe articole publice.

Alte roluri aveau o prezență publică mai redusă sau mai fragmentată.

Această diferență este compatibilă cu faptul că rezultatele despre afacerea respectivă dominau căutarea.

Dar nu pot transforma observația într-o formulă de weighting.

Nu pot afirma:

„un articol de presă valorează cât 50 de postări proprii.”

Nu există o astfel de regulă publică.

Ce aduce totuși o sursă independentă

O sursă independentă are o proprietate importantă:

poate corobora extern o asociere pe care persoana o declară despre sine.

Dacă propriul site spune:

„Alex Matescu lucrează în AI Visibility”

aceasta este auto-descriere.

Dacă o publicație independentă îl descrie în același context, avem a doua sursă care confirmă asocierea.

Asta este important epistemic.

Nu înseamnă că putem calcula un multiplicator algoritmic.

Co-apariția: utilă ca semnal editorial, nu ca formulă

Co-apariția dintre:

• nume;
• rol;
• organizație;
• proiect;
• locație;

poate face o propoziție mai puțin ambiguă.

Exemplu:

„Alex Matescu, autorul AI Visibility Lab”

este mai explicit decât:

„Alex a spus că...”

Dar nu există o regulă publică de tip:

„dacă numele apare de N ori lângă termenul GEO, GEO devine atributul entității.”

Co-apariția trebuie tratată ca clarificare semantică, nu ca hack algoritmic.

Sistemele sintetizează — dar nu după o formulă publică

Când întrebi:

„Cine este X?”

un răspuns scurt nu poate enumera fiecare episod din viața unei persoane.

Sistemul selectează o parte din informația disponibilă.

Dar nu știm că selecția se face după:

• număr de mențiuni;
• „corroboration weight”;
• autoritatea domeniului;
• o formulă fixă de „rol primar”.

Formularea defensabilă este:

Dacă rolul pe care vrei să îl comunici este slab reprezentat sau dificil de legat de identitatea ta, el poate lipsi din sintezele produse de sisteme.

De aceea consistența identității publice contează. Semnalele mai largi care influențează ce surse selectează sistemele generative — dincolo de identitatea unei persoane — sunt tratate separat în cum aleg motoarele AI ce citează.

Ce poți controla

Nu poți controla complet reprezentarea pe care un motor extern o construiește despre tine.

Poți controla însă o parte din dovezile publice.

1. Definește o descriere principală pentru comunicare

Aceasta este o decizie de branding, nu o cerință a entity resolution.

O persoană poate avea simultan mai multe roluri.

Dar o descriere principală consecventă poate face comunicarea mai clară.

Exemplu:

rol principal → activitatea pe care vrei să o comunici acum
roluri secundare → experiența care explică traiectoria

Nu este nevoie să ștergi trecutul sau să ascunzi roluri reale.

2. Folosește o formă canonică a numelui

Alege forma principală folosită public și păstreaz-o consecvent.

Variantele legitime pot fi declarate explicit.

De exemplu:

{
  "@type": "Person",
  "name": "Alex Matescu",
  "alternateName": [
    "Alexandru Matescu",
    "Alexandru-Costi Matescu"
  ]
}

alternateName trebuie folosit numai pentru variante reale ale identității, nu pentru grafii inventate în scop SEO.

3. Construiește o pagină canonică de identitate

În loc de „pagină de dezambiguizare”, termenul mai potrivit pentru site-ul propriu este:

pagină canonică de identitate / pagină About

Ea poate lega într-un singur loc:

• numele;
• variantele legitime;
• biografia;
• rolurile;
• proiectele;
• cronologia;
• profilurile externe;
• publicațiile;
• organizațiile relevante.

Această pagină nu obligă Google sau un LLM să o folosească.

Dar oferă o sursă centrală, coerentă și crawlabilă care explică explicit relațiile dintre informațiile de pe propriul domeniu.

4. Folosește structured data Person corect

Google spune că structured data oferă indicii explicite despre semnificația conținutului și că datele trebuie să descrie ceea ce este efectiv prezent pe pagină.²

Pentru autorii articolelor, Google recomandă:

• @type: Person;
• name;
• url sau sameAs;

pentru a ajuta Google să înțeleagă mai bine cine este autorul.³

Google spune explicit că poate înțelege atât url, cât și sameAs pentru dezambiguizarea autorilor.³

Ce NU face structured data

Nu:

• garantează Knowledge Panel;
• garantează citarea AI;
• obligă Google să accepte toate afirmațiile;
• înlocuiește conținutul vizibil.

Google cere ca structured data să descrie conținutul real al paginii și nu garantează apariția unui rezultat special chiar dacă markupul este valid.²⁴

5. Folosește sameAs numai pentru identități neechivoce

sameAs nu este o listă de linkuri promoționale.

Folosește-l pentru URL-uri care identifică aceeași persoană.

Google recomandă URL-uri valide către pagini care oferă mai multe informații despre autor și poate utiliza sameAs în structured data.³²

Exemple potrivite pot include:

• profil profesional real;
• profil social public real;
• pagină de autor;
• profil într-o organizație;
• alte pagini care identifică neechivoc persoana.

6. Sursele externe pot corobora — fără garanții

Interviurile, articolele, paginile de speaker, profilele profesionale și mențiunile legitime pot face identitatea mai ușor de verificat din mai multe surse.

Dar nu urmări artificial aceeași formulă peste tot.

Obiectivul este:

coerență factuală, nu repetare mecanică.

O sursă externă valoroasă spune adevărul despre persoană în propriul context editorial.

7. Wikidata: identificator suplimentar, nu buton magic

Wikidata este un knowledge graph public.

Un item Wikidata poate oferi:

• un identificator public;
• aliases;
• relații;
• afirmații structurate;
• referințe;
• legături către proiecte Wikimedia.

Dar nu există o sursă care să permită afirmația:

„Wikidata este sursa primară de dezambiguizare pentru toate motoarele majore.”

Google nu a documentat o astfel de dependență. La lansarea Knowledge Graph, Google menționa mai multe surse, inclusiv Freebase, Wikipedia, CIA World Factbook și informații găsite pe web.¹

Notabilitatea Wikidata

Politica Wikidata nu se reduce la:

„trebuie să ai articole independente despre tine”.

Politica actuală permite mai multe căi de notabilitate și este formulată intenționat suficient de flexibil. În 2026 există și o discuție activă privind reformarea politicii.⁵⁶

Prin urmare:

creează sau editează un item numai dacă subiectul îndeplinește politica actuală Wikidata; nu trata Wikidata ca instrument de SEO care trebuie obținut cu orice preț.

Chiar și atunci când există un item valid, el oferă o sursă suplimentară de identificare. Nu garantează ce va face Google, OpenAI sau alt sistem cu informația.

8. Măsoară în timp

Definește un set fix de întrebări:

• cine este [nume];
• ce face [nume];
• cu ce este cunoscut [nume];
• ce proiecte are [nume].

Rulează-le periodic pe sistemele relevante.

Salvează:

• data;
• produsul;
• modul de search;
• răspunsul;
• sursele/citările;
• ce rol apare;
• eventualele confuzii.

Repetă rulările, deoarece sistemele generative sunt nedeterministe.

Scopul nu este să descoperi un „entity score”.

Scopul este să vezi dacă reprezentarea observabilă se schimbă.

Ce nu funcționează ca strategie

Ștergerea trecutului

Dacă informația este reală și legitim publicată, încercarea de a rescrie identitatea prin negarea ei nu construiește coerență.

Mai util este să oferi context.

Un episod antreprenorial poate deveni:

parte din traiectorie,

nu neapărat:

identitatea principală.

Volumul fără accesibilitate

O sută de postări nu au aceeași valoare dacă sistemul analizat nu poate accesa sau recupera conținutul respectiv.

Dar afirmația:

„platformă cu login = zero semnal”

este prea absolută.

Unele platforme au:

• profiluri publice;
• snippets;
• pagini indexabile;
• distribuție prin alte servicii.

Trebuie verificat per platformă și per crawler.

Auto-declarația fără consistență

Poți declara pe propriul site un rol.

Acea afirmație poate fi adevărată și utilă.

Dar dacă restul informațiilor publice:

• folosesc alt nume;
• descriu alte roluri;
• nu leagă proiectele între ele;

identitatea rămâne mai greu de interpretat.

Sursele externe pot adăuga coroborare, dar nu există o formulă publică de weighting.

Ce schimb în propriul caz

Pentru studiul de caz, intervenția coerentă este:

1. folosirea aceleiași entități Alex Matescu;
2. declararea variantelor reale prin alternateName;
3. folosirea aceluiași @id pe site;
4. o pagină About care leagă rolurile și proiectele;
5. sameAs doar către profiluri reale;
6. structured data care reflectă textul vizibil;
7. surse externe obținute prin activitate reală, nu prin fabricarea de mențiuni;
8. măsurarea periodică a rezultatelor.

Aceasta nu garantează schimbarea răspunsurilor AI.

Este însă o strategie coerentă de reducere a ambiguității. Un exemplu concret de măsurare periodică — după ce metadata unei pagini a fost actualizată — este documentat în metadata și citarea AI: studiu de caz.

De ce public studiul

Partea interesantă a cazului nu este că un sistem „m-a înțeles greșit”.

Mai precis:

internetul public documenta disproporționat un episod al identității mele, iar rezultatele observabile reflectau acest dezechilibru.

Asta poate fi urmărit în timp.

Dacă peste luni:

• pagina About devine mai clară;
• rolurile sunt legate mai coerent;
• apar surse externe relevante;
• răspunsurile și rezultatele se schimbă;

vom avea o evoluție observabilă.

Tot nu vom putea spune că o singură intervenție a „cauzat” schimbarea fără un design experimental adecvat.

Dar vom avea un studiu longitudinal mai bun decât o fotografie de moment.

Întrebări frecvente

Ce este o entitate în SEO și AI Search?

Este un lucru identificabil din lumea reală — de exemplu o persoană, o organizație sau un loc — distinct de textul folosit pentru a-l menționa. Google a descris Knowledge Graph ca un model al entităților reale și al relațiilor dintre ele, sub formula „things, not strings”.¹

De ce apar alte persoane când îmi caut numele?

Pentru că același nume sau nume apropiate pot indica mai multe persoane, iar rezultatele depind de context și de informațiile disponibile. AI Visibility Lab numește această situație „coliziune”. Nu există o regulă publică prin care sistemul alege automat persoana cu cele mai multe mențiuni.

Ce este fragmentarea identității?

Este situația în care informațiile despre aceeași persoană există în mai multe roluri, grafii sau surse, dar relațiile dintre ele nu sunt suficient de clare. Este un model practic AI Visibility Lab, nu o metrică oficială Google.

Structured data Person rezolvă problema?

Nu singură. Structured data oferă informație machine-readable și Google recomandă url sau sameAs pentru a ajuta la înțelegerea autorilor, dar markupul trebuie să reflecte conținutul real și nu garantează reprezentarea finală în Search.³²

Contează sursele independente?

Pot conta ca surse suplimentare de coroborare, pentru că nu sunt controlate de persoana descrisă. Nu există însă un raport public de tipul „un articol de presă valorează cât N postări proprii”.

Wikidata rezolvă entity resolution?

Nu automat. Un item Wikidata poate oferi un identificator public și relații structurate dacă subiectul îndeplinește politica platformei. Nu există dovadă că Wikidata este sursa primară pentru toate motoarele sau că un item garantează dezambiguizarea externă.⁵

Metodologie și niveluri de certitudine

Observație proprie

Cazul cu rezultatele despre standul de porumb este o observație efectuată în august 2026 asupra propriului nume.

El descrie:

• query-ul;
• momentul;
• rezultatele observabile.

Nu descrie direct:

• structura internă a Google Knowledge Graph;
• candidate scoring;
• entity confidence;
• weightingul surselor;
• mecanismul unui LLM.

Surse primare

Pentru afirmațiile generale au fost folosite:

• Google Blog pentru lansarea Knowledge Graph;
• Google Search Central pentru structured data și author markup;
• Schema.org ca vocabular;
• politica oficială Wikidata.

Framework propriu

Termenii:

• coliziune;
• fragmentare;
• contaminare;

sunt folosiți în acest articol ca taxonomie practică AI Visibility Lab.

Nu sunt prezentați drept taxonomie Google, OpenAI sau Wikidata.

Surse

1. Google, Amit Singhal — „Introducing the Knowledge Graph: things, not strings", 16 mai 2012, verificat la 19 august 2026. Google descrie Knowledge Graph ca un model care înțelege entități din lumea reală și relațiile dintre ele, cu surse inițiale precum Freebase, Wikipedia și CIA World Factbook: blog.google/…/introducing-knowledge-graph-things-not
2. Google Search Central — „Introduction to structured data markup in Google Search", actualizat 10 decembrie 2025, verificat la 19 august 2026. Google spune că structured data oferă indicii explicite despre sensul unei pagini și că datele trebuie să descrie conținutul efectiv prezent pe pagină: developers.google.com/…/intro-structured-data
3. Google Search Central — „Article structured data", verificat la 19 august 2026. Google recomandă pentru autori @type, url sau sameAs și spune explicit că poate înțelege atât url, cât și sameAs la dezambiguizarea autorilor: developers.google.com/…/structured-data/article
4. Google Search Central — „General structured data guidelines", verificat la 19 august 2026. Google nu garantează afișarea unui rezultat special chiar dacă markupul e valid: „using structured data enables a feature to be present, it does not guarantee that it will be present": developers.google.com/…/sd-policies
5. Wikidata — „Wikidata:Notability", politica curentă, verificată la 19 august 2026. Politica definește trei căi independente de notabilitate (sitelink Wikimedia valid, entitate identificabilă descrisă de surse serioase și public disponibile, sau necesitate structurală) — un item trebuie să îndeplinească doar una dintre ele: wikidata.org/wiki/Wikidata:Notability
6. Wikidata — „Requests for comment/Notability policy reform", 2026, verificat la 19 august 2026. Documentează o discuție activă a comunității (comentarii recente din iulie 2026) privind reformarea criteriilor de notabilitate, formulate inițial în 2013: wikidata.org/wiki/…/Notability_policy_reform

Notă de volatilitate

Politicile Wikidata și documentația Google pot fi actualizate. Afirmațiile despre acestea descriu starea verificată la 19 august 2026, dată la care sursele de mai sus au fost reverificate live, fără schimbări față de starea consemnată inițial la 11 august 2026. Observația despre propriul nume rămâne o fotografie a rezultatelor văzute în august 2026 și nu a fost repetată pentru această verificare — rezultatele de căutare personalizate se pot schimba de la o rulare la alta.

Articol publicat de AI Visibility Lab, proiect independent de cercetare aplicată și documentare în AI Visibility, GEO și AEO, fondat și coordonat de Alex Matescu. Ultima verificare factuală și a surselor: 19 august 2026.