Accueil › Glossaire › Entity Linking

Entity Linking (Liaison d’Entités)

L’entity linking est une tâche de NLP qui consiste à identifier les mentions d’entités nommées dans un texte (personnes, organisations, lieux, produits) et à les relier à leur entrée unique dans une base de connaissances (knowledge base) comme Wikidata, DBpedia ou une ontologie métier. C’est l’étape qui transforme un nom ambigu en une identité précise.

Quand un texte mentionne « Paris », s’agit-il de la capitale de la France, de Paris Hilton, de Paris (Texas) ou du personnage mythologique ? Quand il mentionne « Apple », est-ce l’entreprise technologique ou le fruit ? L’entity linking résout cette ambiguïté en analysant le contexte et en reliant chaque mention à l’entité correcte dans une base de connaissances structurée. C’est la couche d’intelligence qui transforme du texte brut en données exploitables pour les knowledge graphs, la recherche sémantique, l’analyse d’information et le SEO structuré.

Le pipeline d’entity linking

L’entity linking se décompose en trois étapes séquentielles, chacune avec ses propres défis techniques.

Étape 1 : Détection des mentions (NER)

La première étape est la reconnaissance d’entités nommées (NER) : identifier dans le texte les spans (séquences de mots) qui correspondent à des entités. Le système détecte que « Sebastian Thrun » est une personne, « Stanford » une organisation, et « Palo Alto » un lieu. Les modèles modernes utilisent des architectures de type Transformer (BERT, RoBERTa) avec un étiquetage séquentiel BIO (Beginning-Inside-Outside).

C’est une étape critique : si la mention n’est pas détectée, elle ne peut pas être liée. Les erreurs de NER se propagent en cascade dans tout le pipeline. Les textes informels (tweets, messages, forums) sont particulièrement difficiles car ils contiennent des abréviations, des fautes d’orthographe et une ponctuation erratique.

Étape 2 : Génération de candidats

Pour chaque mention détectée, le système génère une liste de candidats depuis la base de connaissances. Pour « Paris », les candidats pourraient être : Paris (ville, France), Paris (Texas), Paris Hilton, Paris (mythologie grecque). La génération de candidats utilise plusieurs stratégies :

Correspondance de surface : Rechercher les entrées de la KB dont le nom correspond (exact ou fuzzy) à la mention. « Paris » matche toutes les entrées contenant « Paris ».

Alias et redirections : Utiliser les alias, acronymes et redirections de Wikipedia/Wikidata. « NYC » → New York City, « OMS » → Organisation mondiale de la Santé.

Prior de popularité : Pondérer les candidats par leur probabilité a priori. « Paris » sans contexte fait référence à la capitale française dans ~95% des cas sur Wikipedia. Ce prior est calculé à partir des statistiques de liens dans Wikipedia.

Encodage dense (BLINK) : Les systèmes modernes comme BLINK (Meta) utilisent un bi-encoder BERT pour encoder la mention avec son contexte et chaque entité candidate en vecteurs denses, puis recherchent les plus proches voisins via FAISS. C’est scalable et efficace, même avec des millions d’entités dans la KB.

Étape 3 : Désambiguïsation

Le cœur de l’entity linking. Parmi les candidats générés, le système doit choisir la bonne entité en analysant le contexte. Trois types de signaux sont exploités :

Contexte local : Les mots autour de la mention. « Paris est la capitale de la France » → le mot « capitale » indique la ville. « Paris a publié un album » → « album » indique une personne.

Cohérence globale : Les autres entités détectées dans le même document doivent être cohérentes. Si le texte mentionne aussi « Tour Eiffel » et « Seine », cela renforce le candidat Paris (ville). Les approches par graphe modélisent cette cohérence collective.

Similarité sémantique : Les modèles Transformer comparent l’embedding du contexte de la mention avec l’embedding de la description de chaque candidat dans la KB. Le candidat le plus similaire sémantiquement est sélectionné.

Entity Linking vs NER : la distinction fondamentale

Le NER est un sous-composant de l’entity linking. Le NER détecte et catégorise (« c’est un lieu »). L’entity linking va plus loin et identifie (« c’est spécifiquement Paris, France, identifiant Wikidata Q90 »). En pratique, les systèmes modernes font souvent les deux en un seul pipeline end-to-end.

Les bases de connaissances (Knowledge Bases)

Le choix de la KB conditionne tout le système. Pour du texte open-domain (articles, web), Wikidata est la référence. Pour du texte médical, UMLS et SNOMED CT sont les standards. Pour un usage métier spécifique, une KB custom (base clients, catalogue produits, taxonomie interne) est souvent nécessaire.

Outils et systèmes d’entity linking

Cas d’usage concrets

Construction de knowledge graphs : L’entity linking est la brique fondamentale pour peupler un knowledge graph à partir de texte. Extraire les entités, les relier à une KB, puis extraire les relations entre elles. C’est le pipeline standard de knowledge base population.

SEO sémantique et Schema.org : Relier les entités de votre contenu à Wikidata via les propriétés Schema.org (sameAs, about, @id) améliore la compréhension de votre contenu par Google. C’est ce qui alimente les Knowledge Panels et les résultats enrichis. L’entity linking automatisé permet de générer ces annotations à grande échelle.

Analyse d’information et veille : Relier les mentions de personnes, d’entreprises et de lieux à des identifiants uniques permet d’agréger les informations sur une même entité provenant de sources différentes. « Anthropic », « la société d’IA Anthropic » et « l’entreprise qui développe Claude » sont trois mentions différentes de la même entité.

Biomédecine et clinical NLP : Relier les mentions de maladies, médicaments et gènes à des codes standardisés (UMLS, SNOMED CT, MeSH). Indispensable pour l’analyse de dossiers médicaux, la pharmacovigilance et la recherche clinique.

Analyse juridique : Relier les références à des lois, des jurisprudences et des parties prenantes à des entrées normalisées. « L.225-37 du Code de commerce » → identifiant législatif précis.

RAG et recherche sémantique : L’entity linking enrichit les documents avant l’indexation dans un pipeline RAG. Relier « Apple » à l’entité correcte améliore la qualité du retrieval en éliminant l’ambiguïté en amont.

Approches modernes

BLINK : l’approche bi-encoder

BLINK (Meta, 2020) utilise un bi-encoder BERT pour encoder séparément la mention (avec son contexte) et chaque entité candidate (sa description dans la KB) en vecteurs denses. La recherche des candidats les plus proches se fait via FAISS (ANN). Optionnellement, un cross-encoder reclasse les top candidats pour affiner la sélection. BLINK atteint des accuracies supérieures à 90% en zero-shot et fonctionne sur des KB de millions d’entités.

Systèmes end-to-end

Les architectures récentes intègrent NER, génération de candidats et désambiguïsation dans un seul modèle neural. Des modèles comme GENRE (Meta) utilisent des architectures encoder-decoder (BART) qui génèrent directement l’identifiant de l’entité sous forme de texte. L’avantage : plus de pipeline séquentiel, les erreurs ne se propagent plus d’une étape à l’autre.

Entity linking multilingue

Un défi majeur. Les systèmes entraînés sur Wikipedia anglais ne généralisent pas bien aux autres langues, surtout les langues à faibles ressources. Les approches cross-lingual utilisent des modèles multilingues (mBERT, XLM-R) pré-entraînés sur des corpus parallèles pour transférer les capacités de linking entre langues. Wikidata, avec ses labels multilingues, est la KB de choix pour l’entity linking cross-lingual.

Exemple avec spaCy

import spacy

# Charger le modèle avec entity linker
nlp = spacy.load("en_core_web_lg")
# Ajouter le composant entity linker si disponible
# nlp.add_pipe("entity_linker")  # nécessite une KB configurée

# Alternative : utiliser un service comme DBpedia Spotlight
import requests

text = "Apple CEO Tim Cook announced new products at the event in Cupertino."

# NER avec spaCy
doc = nlp(text)
for ent in doc.ents:
    print(f"{ent.text} → {ent.label_}")
# Apple → ORG
# Tim Cook → PERSON
# Cupertino → GPE

# Entity linking via DBpedia Spotlight API
response = requests.get(
    "https://api.dbpedia-spotlight.org/en/annotate",
    params={"text": text, "confidence": 0.5},
    headers={"Accept": "application/json"}
)
entities = response.json().get("Resources", [])
for e in entities:
    print(f"{e['@surfaceForm']} → {e['@URI']}")
# Apple → http://dbpedia.org/resource/Apple_Inc.
# Tim Cook → http://dbpedia.org/resource/Tim_Cook
# Cupertino → http://dbpedia.org/resource/Cupertino,_California

DBpedia Spotlight est l’API la plus simple pour expérimenter avec l’entity linking. Pour la production, BLINK ou REL offrent de meilleures performances et plus de contrôle.

Limites et défis

Dépendance à la qualité de la KB. Le système ne peut lier qu’aux entités présentes dans la KB. Si l’entité n’y figure pas (startup récente, personne peu connue), le système doit prédire NIL, ce qui reste un défi. La couverture de la KB est un facteur limitant majeur.

Ambiguïté extrême. Certaines mentions sont très ambiguës : « Washington » peut désigner l’état, la ville, l’université, le président ou le film. La désambiguïsation dépend entièrement du contexte disponible. Sur les textes courts (tweets, requêtes de recherche), le contexte est souvent insuffisant.

Cascade d’erreurs. Dans un pipeline séquentiel, les erreurs de NER se propagent : si « Tim Cook » n’est pas détecté comme entité, il ne peut pas être lié. Les modèles end-to-end atténuent ce problème mais sont plus complexes à mettre en place.

Scalabilité multilingue. Les KB et les modèles NER sont nettement moins développés pour les langues autres que l’anglais. L’entity linking en français ou en arabe nécessite des ressources spécifiques (modèles NER multilingues, KB avec labels dans la langue cible).

Coût de maintenance de la KB. Les KB doivent être régulièrement mises à jour pour refléter les nouvelles entités, les changements (fusions d’entreprises, changements de nom) et les évolutions du monde réel. C’est un coût opérationnel significatif.

Verdict

L’entity linking est la couche d’intelligence qui transforme des noms ambigus en identités précises. C’est un composant essentiel pour la construction de knowledge graphs, le SEO sémantique, l’analyse biomédicale et tout système qui a besoin de comprendre de qui ou de quoi on parle. Les systèmes modernes (BLINK, GENRE) atteignent des performances remarquables (>90% accuracy en zero-shot) et les LLM offrent une flexibilité inédite pour les cas non standard.

Pour démarrer, DBpedia Spotlight est la solution la plus simple (API gratuite, résultats corrects). Pour la production, BLINK ou REL offrent un meilleur contrôle et de meilleures performances. Et pour les domaines spécialisés (médical, juridique), une KB métier couplée à un modèle fine-tuné est indispensable. L’entity linking n’est pas un luxe, c’est ce qui sépare le NLP « basique » (il y a un lieu mentionné) du NLP « intelligent » (le lieu est Paris, France, coordonnées 48.8566°N, 2.3522°E, population 2,1 millions).