Entity linking: come l'AI capisce chi sei

C'è un nome preciso per il problema

Per anni il modo di farsi trovare era posizionarsi tra i dieci link di una pagina di risultati. Oggi un sistema AI risponde in un colpo solo, e prima di rispondere deve compiere una decisione che la ricerca tradicional non gli chiedeva: stabilire a chi, o a cosa, si riferisce un nome. Quella decisione ha un nome nella letteratura, ed è entity linking, chiamato anche named-entity disambiguation. È il compito di assegnare un'identità univoca alle entità menzionate in un testo. L'esempio da manuale è la frase "Paris is the capital of France": il modello deve capire che "Paris" è la città e non Paris Hilton.

Non è un termine che ho coniato io. È una disciplina riconosciuta, con una voce su Wikipedia e un nodo su Wikidata, studiata da oltre vent'anni tra information retrieval, natural language processing e semantic web. E sapere che il problema ha un nome preciso cambia il modo di affrontarlo: non è la vaga aspirazione a "essere più visibili", è una questione tecnica definita, con cause note e leve concrete su cui agire.

Non confonderlo con la deduplica

C'è un quasi omonimo che porta fuori strada: entity resolution. A dispetto del nome simile significa un'altra cosa, cioè decidere se due record diversi sono la stessa entità e fonderli, eliminando i duplicati. È un lavoro da ingegneria dei dati e da master data management, il mondo dell'antiriciclaggio e delle anagrafiche aziendali. L'entity linking va nella direzione opposta: prende una menzione e la risolve all'entità canonica giusta, distinguendola dagli omonimi.

La distinzione conta, e non per pedanteria. Se insegui la parola sbagliata finisci nella conversazione sbagliata, letta dal pubblico sbagliato. Il problema di cui mi occupo non è ripulire database da doppioni, è fare in modo che un nome venga risolto alla persona o all'organizzazione giusta, con i fatti giusti.

Come fa l'AI a decidere

Il processo si compone di tre momenti. Prima il modello riconosce il nome dentro il testo. Poi genera dei candidati, cioè le entità possibili a cui quel nome potrebbe corrispondere, attingendo a una base di conoscenza, di solito Wikipedia o Wikidata. Infine disambigua, sceglie il candidato corretto.

Il punto debole, per te, è il secondo passaggio. Se la tua entità non è in quella base di conoscenza, o c'è ma è descritta in modo confuso, il modello sceglie qualcun altro oppure inventa. Non è malizia, è il comportamento normale di un sistema che riempie i vuoti. L'unico modo di controllare l'esito è rendere la risposta corretta quella più facile da trovare.

Perché riguarda te, non gli ingegneri

Costruire il sistema di entity linking è il lavoro degli ingegneri NLP, e non è il mio. Io sto dall'altra parte del tavolo: sul lato dell'entità che deve essere collegabile. La leva che hai in mano non è l'algoritmo, è l'offerta di dati puliti, verificabili e strutturati su di te o sulla tua organizzazione. Un identificativo stabile, riferimenti che reggono al controllo, una descrizione che una macchina legge senza dover interpretare.

È esattamente la metà del problema che puoi controllare, ed è anche quella su cui non lavora quasi nessuno. Tutti discutono di come le AI sbagliano, pochi preparano la propria entità perché le AI possano fare bene.

Dove vivono le entità: knowledge graph e linked data

Due concetti riconosciuti danno il nome al substrato su cui si lavora. Un knowledge graph è la struttura di entità e relazioni che motori di ricerca e sistemi AI consultano per sapere chi è chi. I linked data sono la pratica di pubblicare i propri dati in forma connessa e leggibile dalle macchine, con identificatori univoci e collegamenti ai nodi canonici, su fondamenta RDF, e nella pratica quotidiana con JSON-LD e Schema.org e con i sameAs verso Wikidata.

Rendersi collegabili significa, in concreto, due cose: esistere come nodo pulito in quel grafo, e puntare ai nodi giusti accanto a te, il tema di cui ti occupi, le organizzazioni a cui appartieni, i luoghi in cui operi. Sono quei collegamenti a dire al modello dove collocarti, e a impedirgli di confonderti con un omonimo.

Cosa fa, qui, un Semantic Entity Architect

A questo punto posso dire senza giri di parole cosa significa il titolo che porto. Non ottimizzo parole chiave e non costruisco intelligenze artificiali. Progetto il modo in cui un'entità è rappresentata, perché quando un modello compie l'entity linking la risolva al nodo giusto, con i fatti giusti, distinta dagli omonimi, e perché quell'entità sia citabile come fonte.

È un mestiere che vive all'incrocio di tre campi riconosciuti, entity linking, knowledge graph e linked data, applicati a un solo obiettivo: essere trovati e descritti correttamente dai sistemi generativi, ciò che il mercato chiama GEO, Generative Engine Optimization. Il nome del ruolo è mio, ma quei nodi dicono cosa contiene. È la disambiguazione applicata a me stesso, prima ancora che ai clienti.

Tre applicazioni dello stesso principio

Tutto il resto di questo sito è questo principio calato su un soggetto specifico. Per un professionista il problema prende la forma dell'omonimia, l'AI che ti fonde con qualcuno che porta il tuo stesso nome, e lo affronto nella nota su omonimia e disambiguazione. Per una PMI è il marchio e l'offerta che devono comparire correttamente nelle risposte su fornitori e soluzioni, ed è il tema di come far comparire la tua azienda nelle risposte dell'AI. Per un ente del terzo settore è una missione intrappolata in PDF che nessuna macchina legge, di cui parlo in GEO per il terzo settore.

Pubblici diversi, lavoro di fondo identico: fare in modo che l'entità venga risolta correttamente. Cambia il soggetto, non il principio.

Da dove si parte

Il primo passo è sempre lo stesso, e lo puoi fare oggi: chiedi a ChatGPT, Gemini e Perplexity chi sei, o cosa fa la tua organizzazione, e osserva cosa è corretto, cosa manca e cosa viene inventato. Quella fotografia ti dice se l'entity linking, su di te, sta funzionando o no. Da lì si decide se e come intervenire.