Entity Resolution

Tâche NLP consistant à associer une mention textuelle (nom de marque, produit, personne) à un identifiant canonique stable (QID Wikidata, MID Google, GTIN). Étape indispensable pour qu'un LLM relie un mot à une entité connue de son graphe interne.

Étapes du pipeline

L’entity resolution se décompose en trois sous-tâches enchaînées :

Mention detection : repérer dans un texte les segments qui réfèrent à une entité.
Candidate generation : générer une liste courte de candidats du knowledge graph compatibles avec le segment.
Disambiguation : choisir le bon candidat en s’appuyant sur le contexte phrastique et les statements connus.

Les modèles modernes (GENRE, BLINK, ReFinED) fusionnent les trois étapes en une génération séquence-à-séquence du QID.

Pourquoi c’est central pour une boutique

Quand un utilisateur écrit “commande-moi un k-way bleu chez Aurore”, l’agent doit résoudre simultanément trois entités :

“Aurore” → la marque DTC Q... (et pas l’ouvrage cinématographique homonyme).
“k-way” → la catégorie produit (et pas la marque K-Way historique).
“bleu” → la valeur du color schema.

Une seule mauvaise résolution casse la commande. C’est pour cette raison qu’[[ucp]] définit Identity Linking OAuth et que les feeds Shopping intègrent des gtin : ils servent d’ancres déterministes.

Levier rédactionnel

Sur les pages catégorie d’une boutique, expliciter le terme canonique entre parenthèses (“trench coat (manteau imperméable long)”) améliore la précision de la résolution côté agent. Les LLM s’appuient sur ces gloses pour valider leur candidat.

À ne pas confondre avec

[[knowledge-graph]] : la cible de la résolution, pas le processus.
Record linkage SQL : variante interne (dédoublonnage CRM), même algorithme mais hors knowledge graph public.