Résolution d'entités avec Elasticsearch, partie 4 : le défi ultime

Nous avons maintenant vu la résolution intelligente des entités implémentée de deux manières. Les deux approches commencent de la même manière : préparation et extraction des entités, suivies de la récupération des candidats avec Elasticsearch. À partir de là, nous évaluons ces candidats en utilisant un grand modèle de langage (LLM), soit par génération JSON basée sur des invites, soit par appel de fonction, et nous demandons au modèle de fournir une explication transparente de son jugement.

Comme nous l’avons vu dans l’article précédent, cette régularité, permise par l’appel de fonctions, constitue la pierre angulaire de la fiabilité du système, bien au-delà d’un simple gain d’efficacité. Une fois que nous avons éliminé les erreurs structurelles de la boucle d'évaluation, les résultats sur les scénarios standards (tels que ceux du jeu de données de niveau 4) se sont considérablement améliorés.

Il reste cependant une interrogation manifeste à laquelle il nous faut répondre :

Cette méthode est-elle toujours viable lorsque les données et les processus s’avèrent véritablement désordonnés ?

En pratique, ce ne sont pas les cas élémentaires qui mettent en défaut les systèmes de réconciliation d’entités. La résolution d’entités s’effondre dès que les noms se heurtent à la diversité des langues, des contextes culturels, des alphabets, des périodes historiques ou des structures administratives différentes. Le système s’effondre quand l’identification repose sur des titres honorifiques, des changements de noms de sociétés ou des translittérations aléatoires, et que seul le contexte environnant permet d’identifier l’entité physique derrière la mention textuelle.

Donc, pour le dernier billet de cette série, nous avons soumis le système à ce que nous avons appelé le défi ultime.

Qu’est-ce qui fait de ce test le « défi ultime » ?

Nous avons soumis le système à des tests progressifs, en employant des ensembles de données de plus en plus sophistiqués au fil des étapes de validation. Au moment d’atteindre le palier 4, le système gérait déjà des données hybrides mêlant appellations familières, titres honorifiques et variantes linguistiques, exigeant une analyse contextuelle fine. Les tests ont prouvé la pertinence de l’architecture globale, tout en révélant que des erreurs de structure de données, comme des syntaxes JSON incorrectes, bridaient artificiellement les performances de récupération.

Avec les appels de fonctions en place, nous avions enfin une base stable. Cela nous a donné l'occasion de poser une question plus intéressante :

Un pipeline unifié peut-il gérer plusieurs types de problèmes de résolution d'entités simultanément ?

Cet ensemble de données de test a été élaboré spécifiquement pour mettre à l’épreuve cette variable critique, en ne laissant aucune place à l’approximation.

Au lieu de se concentrer sur une seule difficulté (comme les surnoms ou la translittération), cet ensemble de données combine plus de 50 types de défis distincts, notamment :

• Conventions de dénomination culturelles.
• Références basées sur les titres.
• Relations commerciales et changements historiques de nom.
• Mentions multilingues et systèmes d’écriture croisés.
• Des défis complexes qui combinent plusieurs des éléments ci-dessus.

L'essentiel, ce n'est pas d'optimiser pour un cas d'utilisation restreint. Il s'agit de vérifier si le modèle de conception tient la route lorsque les règles changent d'une entité à l'autre.

L'ensemble de données en un coup d’œil

L'ensemble de données du défi ultime consiste en :

• 50 entités, couvrant des personnes, des organisations et des institutions.
• ~60 articles, dont la structure et la complexité linguistique varient.
• 51 catégories de défis distinctes, regroupées globalement en :
  • Conventions de dénomination culturelles.
  • Titres et contexte professionnel.
  • Relations commerciales et organisationnelles.
  • Les défis du multilinguisme et de la translittération.
  • Scénarios combinés et cas limites.

Plus tôt dans cette série, nous avons vu que l’utilisation de l’IA générative (GenAI) pour créer des jeux de données peut s’avérer être une arme à double tranchant. Sans elle, il serait extrêmement difficile de rassembler des données de test suffisamment vastes et diversifiées. Toutefois, sans un contrôle rigoureux, le modèle incline naturellement vers la simplification des cas de test.

On a remarqué, lors d’un premier passage de génération, que l’IA avait inséré des mentions telles que « le président russe » comme synonymes directs dans la fiche d’identité de Vladimir Poutine. Bien que cela paraisse logique à première vue, une telle approche invalide le test en supprimant la nécessité de comprendre le contexte pour identifier l’entité. Que se passe-t-il si l’article traite de la Russie des années 1990 ? L’objectif est que l’intelligence du moteur réside dans sa capacité d’inférence contextuelle plutôt que dans une simple table de correspondance statique.

C'est pourquoi cet ensemble de données a été délibérément conçu pour que les raccourcis ne fonctionnent pas. Les alias ne sont pas explicitement énumérés lorsque le système est censé en déduire la signification. Les phrases descriptives ne sont pas pré-liées à des entités. Les bonnes correspondances dépendent souvent du contexte de l'article, et pas seulement du texte local.

Remarque importante : bien que nous démontrions les capacités du système dans divers scénarios, il s'agit toujours d'un prototype éducatif. Les systèmes de production gérant la surveillance d'entités sanctionnées dans le monde réel nécessiteraient une validation supplémentaire, des contrôles de conformité, des pistes d'audit et une gestion spécialisée pour les cas d'utilisation sensibles.

Pourquoi ces scénarios sont difficiles

Dès le premier article de cette série, nous avons introduit un exemple simple mais ambigu : « La nouvelle mise à jour de Swift est arrivée ! » Le défi réside dans le fait que « Swift » peut renvoyer à plusieurs entités du monde réel, selon le contexte. Cet exemple illustre une vérité plus profonde : le langage naturel est intrinsèquement ambigu.

La résolution d’entités n’est donc pas seulement un problème de correspondance de chaînes de caractères. Nous utilisons instinctivement notre bagage culturel et le contexte immédiat pour interpréter les références, une opération mentale si fluide qu’elle nous semble totalement naturelle.

Voici quelques cas courants :

• L’expression « le président » est une coquille vide si elle n’est pas ancrée dans une géographie et une époque données.
• Le nom d’une entreprise peut désigner une société mère, une filiale ou une ancienne marque, selon la date à laquelle l’article a été rédigé.
• Le nom d’une personne peut apparaître dans des ordres différents, des alphabets variés ou des translittérations diverses, selon la langue et la culture.
• La même phrase peut légitimement faire référence à des entités différentes dans des contextes différents, et le système doit être en mesure de rejeter les correspondances avec autant d'assurance qu'il les accepte.

Aucun système de règles figées ne peut, à lui seul, traiter l’intégralité de ces nuances de manière satisfaisante. Cette approche explique pourquoi ce prototype applique une séparation des préoccupations aussi stricte :

• Elasticsearch réduit l'espace réservé aux candidats de manière efficace et transparente.
• Le LLM n’est utilisé que là où un jugement est requis, et il est contraint de justifier sa décision.
• La récupération et le raisonnement demeurent des étapes distinctes.

Cette distinction devient encore plus importante à mesure que la diversité des types de défis augmente.

Comment le système gère la diversité sans recourir à des cas particuliers

L'un des résultats les plus intéressants de cette évaluation est ce qui n’a pas changé :

• Nous n'avons pas ajouté de logique spéciale pour les noms japonais.
• Nous n'avons pas ajouté de règles personnalisées pour les patronymes arabes.
• Nous n'avons pas ajouté de mapping codé en dur pour les noms d'entreprises historiques.

À la place, le système s’est appuyé sur les mêmes ingrédients fondamentaux présentés plus tôt dans cette série :

• Entités enrichies par le contexte et indexées pour la recherche sémantique.
• La récupération hybride (exacte, alias et sémantique) dans Elasticsearch.
• Un ensemble restreint et bien défini de candidats.
• Le jugement du LLM est contraint par l’appel de fonctions et des schémas minimaux.

Cela suggère que la flexibilité du système provient de la représentation et de l'architecture, et non d'une collection de règles qui ne cesse de croître.

Lorsque le système réussit, c’est parce que les bons candidats ont été récupérés et que le LLM dispose d’assez de contexte pour expliquer pourquoi une référence correspond (ou non) à une entité spécifique.

Résultats : Comment s’est-il comporté ?

Sur l’ensemble de données du défi ultime, le système a produit les résultats globaux suivants :

• Précision : ~91 %
• Rappel : ~86 %
• Score F1 : ~89 %
• Taux d'acceptation des LLM : ~72 %

Performances selon les types de défis

L’analyse des résultats par type de défi révèle des forces et des limites bien précises :

Les performances les plus solides (un score F1 de 100 %) ont été observées dans des domaines tels que :

• Appariement entre différents systèmes d’écriture (entités commerciales en cyrillique, coréen ou chinois).
• Scénarios en hébreu (patronymes, titres professionnels, titres religieux, translittération).
• Hiérarchies d’entreprises (aérospatiale, industrie diversifiée, conglomérats multidivisionnels).
• Titres professionnels (académiques, militaires, politiques, religieux).
• Scénarios japonais combinés impliquant plusieurs systèmes d'écriture.

Une performance solide (score F1 de 80 à 99 %) a été enregistrée dans les catégories suivantes :

• Personnalités politiques internationales (98 %).
• Changements de noms historiques (90 %).
• Hiérarchies d’entreprise complexes (89 %).
• Noms de sociétés japonais (93 %).
• Translittération entre différents systèmes d’écriture (86 %).
• Patronymes arabes (86 %).

Les domaines les plus difficiles sont les suivants :

• Translittération avancée (chinois, coréen) : 0 % F1.
• Certains scénarios japonais (titres honorifiques, ordre des noms, variations du système d’écriture) : ~67 % F1.
• Quelques scénarios en arabe (noms d'entreprises, références institutionnelles) : ~40 % F1.

Ce qui importe ici, c’est de comprendre pourquoi le système a éprouvé des difficultés dans ces cas précis. Les échecs n’étaient pas dus à une défaillance de l’approche globale, mais à des limitations de composants spécifiques, tout particulièrement le modèle de vecteurs denses utilisé pour la recherche sémantique dans certains scénarios multilingues.

La recherche et le jugement étant clairement séparés, il n’est pas nécessaire de réécrire le système pour améliorer les performances. L’intégration d’un modèle d’embedding multilingue plus performant, l’enrichissement du contexte des entités ou l’affinement des stratégies de récupération amélioreraient les résultats dans ces catégories sans modifier l’architecture de noyau.

Du point de vue architectural, c’est le véritable indicateur de réussite.

Ce que ces résultats nous révèlent sur l'architecture du système

Si l'on considère l'ensemble de la série, quelques tendances se dégagent :

• La préparation est plus importante qu'une combinaison intelligente. L’enrichissement des entités avec leur contexte dès le départ réduit considérablement l’ambiguïté par la suite.
• Les LLM sont bien plus précieux en tant que juges qu’en tant qu’outils de recherche. Leur demander d'expliquer pourquoi une correspondance est logique est bien plus efficace que de leur demander de rechercher.
• La fiabilité permet la précision. L'appel de fonction n'a pas seulement nettoyé le JSON ; il a débloqué la récupération qui était déjà latente dans l'étape de récupération.
• La généralisation l’emporte sur la spécialisation. Un petit nombre d’abstractions bien choisies a permis de gérer des dizaines de types de défis sans avoir recours à une logique personnalisée.

Cette approche explique pourquoi le prototype s’appuie nativement sur Elasticsearch tout en limitant l’usage des modèles de langage à une stricte nécessité. L’objectif n’est pas de se substituer aux moteurs de recherche classiques, mais d’apporter une couche d’explication quand la compréhension du contexte est cruciale.

Conclusions

L’enjeu final n’était pas d’atteindre des statistiques idéales, mais de s’attaquer à une interrogation bien plus essentielle :

Une architecture transparente, axée sur rechercher et assistée par LLM, peut-elle gérer l'ambiguïté des entités du monde réel sans s'effondrer en règles ou en boîtes noires ?

Pour ce prototype pédagogique, la réponse est oui, avec des réserves explicites concernant la mise en production, la conformité, la surveillance et la qualité des données. Si vous concevez des systèmes devant justifier pourquoi une correspondance d’entités a été établie, ce modèle mérite une attention toute particulière. J’espère que cette série de publications a démontré que la résolution d’entités n’a rien d’un processus mystérieux. Avec une séparation adéquate des responsabilités, la résolution d’entités devient un processus que l’on peut analyser, mesurer et améliorer.

Ce travail suggère également un modèle d’architecture plus large. On voit apparaître ici un glissement méthodologique important par rapport à l’architecture RAG classique. Au lieu de laisser la recherche alimenter directement la génération, nous introduisons une étape d’évaluation explicite. Le LLM est d’abord utilisé pour juger et vérifier la pertinence des candidats récupérés, et seuls les résultats approuvés sont autorisés à enrichir la génération. Vous pouvez voir cela comme un « Generation-Augmented Retrieval-Augmented Generation with Evaluation », ou GARAGE, parce que tout le monde adore les bons acronymes.

Quels autres cas d'utilisation pourraient bénéficier de ce modèle ? Les systèmes exigeant de la confiance, de la transparence et un raisonnement défendable sont des candidats naturels pour ce modèle. Les travaux futurs dans ce domaine s’annoncent tout aussi passionnants que les résultats présentés ici, et j’ai hâte de voir comment la communauté s’en emparera pour la suite.

Prochaines étapes : À vous de jouer

Envie de voir comment ce système relève le défi le plus complexe ? Consultez le carnet de notes Ultimate Challenge pour une présentation complète avec des implémentations réelles, des explications détaillées et des exemples pratiques.

Le pipeline complet de résolution d'entités démontre les concepts fondamentaux et l'architecture nécessaires à une utilisation en production. Cette structure sert de fondation pour bâtir des outils de veille médiatique capables d’identifier des entités et de justifier chaque correspondance, garantissant ainsi la traçabilité des informations extraites.