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.

1. La nouvelle mise à jour de Swift est arrivée ! Les développeurs sont impatients de tester les nouvelles fonctionnalités.

2. La nouvelle mise à jour de Swift est arrivée ! Le nouvel album sortira le mois prochain.

Avec ce contexte supplémentaire, nous devrions être en mesure d’associer le nom « Swift » à la bonne entité.

Dans l'article précédent, nous avons constitué notre liste de surveillance et enrichi les entités avec un contexte supplémentaire. En reprenant nos exemples ci-dessus, nous devons disposer au minimum des deux entités suivantes dans la liste : Taylor Swift et le langage de programmation Swift. Nous avons également expliqué comment extraire les mentions d’entités à partir d’un texte. Dans ces deux exemples, la mention extraite serait « Swift ». Avec ces éléments en place — la liste de surveillance enrichie et les entités extraites — nous sommes enfin prêts à introduire la vedette du moment : la mise en correspondance des entités.

Rappel : il s’agit d’un prototype pédagogique conçu pour illustrer les concepts de mise en correspondance d’entités. En production, les systèmes peuvent utiliser différents grands modèles de langage (LLM), des règles de correspondance personnalisées, des pipelines d’évaluation spécialisés ou encore des approches d’ensemble combinant plusieurs stratégies de correspondance.

Le problème : pourquoi la mise en correspondance est complexe

Le langage humain est une chose remarquable. L’une de ses caractéristiques les plus intéressantes est sa créativité sans fin. Nous pouvons générer et comprendre un nombre infini de nouvelles phrases. Dès lors, est-il surprenant que les correspondances exactes soient rares en résolution d’entités ? Les auteurs s’efforcent d’être créatifs dès qu’ils le peuvent. Il serait vite fastidieux de devoir écrire et lire les noms complets chaque fois qu’une entité est mentionnée. Ainsi, si les correspondances exactes sont simples, la réalité est que nous avons besoin d’une approche plus sophistiquée de la résolution d’entités : une approche suffisamment robuste pour gérer au moins une partie de la créativité sans limite des auteurs humains. C’est pourquoi nous décomposons le problème en deux étapes : utiliser Elasticsearch pour récupérer des candidats plausibles à grande échelle, puis recourir à un LLM pour déterminer si ces candidats renvoient réellement à la même entité du monde réel.

La solution : une mise en correspondance en trois étapes avec un jugement LLM transparent

Nous vivons un changement de paradigme dans notre manière d’utiliser les ordinateurs. Tout comme l’essor d’Internet nous a fait passer d’une informatique localisée à un réseau mondialement connecté, l’IA générative transforme en profondeur la façon dont le contenu, le code et l’information sont créés. En réalité, le prototype pédagogique qui accompagne cette série a été presque entièrement « vibe codé » à l’aide d’un LLM, avec des instructions soigneusement rédigées par l’auteur. Cela ne signifie pas que les LLM atteignent — ou atteindront — le niveau de productivité propre au langage humain, mais cela veut dire que nous disposons désormais d’une ressource puissante pour faciliter la résolution d’entités.

Un schéma courant avec l'IA générative est la génération augmentée par récupération (RAG). Ici, récupération signifie que l’on récupère des candidats d’entités (et non que l’on génère des réponses), et que le LLM est utilisé exclusivement pour évaluer les correspondances et en expliquer la logique. Bien que je puisse demander à un LLM de prendre en charge l’ensemble du processus de résolution d’entités, de bout en bout, cette approche serait coûteuse, tant en temps qu’en ressources financières. La RAG aide les LLM à accomplir leur tâche en leur fournissant du contexte de manière plus efficace, ce qui leur permet de contribuer plus efficacement à la résolution d’entités.

Pour la partie récupération de la RAG, nous faisons à nouveau appel à Elasticsearch. Nous identifions d’abord des correspondances potentielles en combinant la correspondance exacte, la correspondance sur des alias et la recherche hybride, qui associe recherche par mots-clés et recherche sémantique. Une fois ces correspondances potentielles identifiées, nous les transmettons à un LLM pour évaluation. Le LLM agit comme évaluateur final des correspondances. Nous demandons également au LLM d’expliquer son raisonnement, un élément différenciant important par rapport à d’autres systèmes de résolution d’entités. Sans ces explications, la résolution d’entités reste une boîte noire ; avec elles, nous pouvons comprendre pourquoi une correspondance est pertinente.

Concepts clés : mise en correspondance en trois étapes, recherche hybride et jugement LLM transparent

Qu’est-ce que la mise en correspondance en trois étapes ? Au début de ce projet, nous avons émis l’hypothèse que la recherche sémantique jouerait un rôle clé dans le système, mais toutes les correspondances ne nécessitent pas un niveau de recherche aussi sophistiqué. Afin de trouver des correspondances efficacement, nous adoptons une approche progressive du problème. Tout d’abord, nous vérifions les correspondances exactes à l’aide de la recherche par mots-clés. Si nous trouvons une telle correspondance, le travail est terminé et nous pouvons passer à l’étape suivante. Si la correspondance exacte échoue, nous passons à la correspondance par alias. Dans le prototype, la correspondance par alias est également effectuée à l’aide d’une correspondance exacte sur des mots-clés, par souci de simplicité. En production, cette étape peut être enrichie par des règles de normalisation, de translittération, de correspondance approximative (fuzzy matching) ou par des tables d’alias maintenues. Si, après ces deux premières étapes, aucune correspondance potentielle n’a été trouvée, nous faisons appel à la recherche sémantique via la recherche hybride d’Elasticsearch, utilisant la méthode Reciprocal Rank Fusion (RRF).

Qu’est-ce que la recherche hybride ? Dans Elasticsearch, nous pouvons utiliser la recherche sémantique pour identifier des correspondances pertinentes en tenant compte du contexte. Elasticsearch est largement utilisé pour la recherche vectorielle et la récupération hybride. La similarité sémantique est puissante pour capter le sens, mais elle ne remplace pas le filtrage structuré (par exemple, par plages temporelles, emplacements ou identifiants). Elle est souvent inutile lorsqu’une correspondance exacte est disponible. Elasticsearch s’est d’abord imposé grâce à la recherche lexicale, particulièrement efficace lorsque la recherche sémantique n’est pas adaptée. Pour tirer pleinement parti des deux approches, nous combinons la recherche lexicale et la recherche sémantique au sein d’une requête hybride unique. Nous fusionnons ensuite les résultats afin d’identifier les correspondances les plus probables à l’aide de la méthode RRF. Dans le prototype, les deux premiers résultats deviennent des correspondances potentielles pouvant être soumises à l’évaluation du LLM.

Pourquoi faire appel au jugement LLM ? Les jugements et explications fournis par le LLM permettent à notre système de gérer l’ambiguïté et le contexte de manière transparente. C’est essentiel pour des cas comme « le président », qui peut désigner plusieurs entités selon le contexte. Cela permet également de gérer efficacement les surnoms et les variations culturelles. Enfin, lorsque nous traitons des tâches critiques — comme l’identification d’entités figurant sur des listes de sanctions — il est indispensable de comprendre pourquoi une correspondance a été acceptée afin de pouvoir faire confiance au système. Point essentiel : le LLM ne parcourt pas l’intégralité du corpus. Il évalue uniquement le petit ensemble de candidats renvoyé par Elasticsearch.

Résultats concrets : mise en correspondance avec raisonnement du LLM

Un défi majeur pour toute tâche de traitement automatique du langage naturel est la création d’un document de référence, une « answer key » indiquant quels sont les résultats attendus. Sans cela, il est quasiment impossible d’évaluer la performance d’un système sur une tâche donnée. Or, la création d’un tel document peut s’avérer laborieuse. Pour le prototype de résolution d’entités, nous avons de nouveau fait appel à l'IA générative afin de générer des données sur lesquelles nous pourrions effectuer des tests.

Nous avons d’abord défini plusieurs types de défis, comme les surnoms et la translittération, puis demandé au LLM de créer une collection hiérarchisée de jeux de données, devenant progressivement plus volumineux et plus complexes pour le système. La création des jeux de données s’est révélée moins simple qu’on aurait pu l’espérer. Le LLM avait une forte tendance à « tricher » en rendant la bonne réponse trop facile à trouver. Par exemple, l’un des types de défis portait sur le contexte sémantique. Ce type incluait des cas tels que faire correspondre « auteur russe » à « Leo Tolstoy ». Le LLM a incorrectement défini « auteur russe » comme un alias de « Leo Tolstoy », ce qui supprimait la nécessité d’une recherche hybride pour identifier la correspondance.

Après plusieurs refactorisations pour corriger ce type de problèmes, nous disposions de cinq niveaux d’ensembles de données. Les niveaux 1 à 4 devenaient progressivement plus volumineux et intégraient davantage de types de défis. Le niveau 5 constituait le « défi ultime », composé des exemples les plus complexes issus de tous les types de défis. L’ensemble des données de test est disponible dans un répertoire d’évaluation complet.

Pour évaluer notre approche de résolution d’entités basée sur des prompts, nous avons concentré notre analyse sur le jeu de données de niveau 4. Il est important de noter que l’évaluation a été menée dans le cadre d’une expérience contrôlée afin de nous concentrer sur la qualité de mise en correspondance des entités. Les données de la liste de correspondances ont été préalablement enrichies avec du contexte, et les entités ont été extraites de l’article en amont. Cela a permis de s’assurer que l’évaluation se concentrait sur la correspondance plutôt que sur la précision de l’extraction. Cela isole la qualité de correspondance ; les performances de bout en bout dépendraient en outre du rappel d'extraction et de la qualité d'enrichissement.

Ensemble de données d’évaluation

L'ensemble de données d'évaluation de niveau 4 fournit un test complet des capacités du système : [1]

• Entités de la liste de surveillance : 66 entités couvrant différents types (personnes, organisations, lieux).

• Articles de test : 69 articles couvrant des scénarios réels de résolution d’entités.

• Correspondances attendues : 206 correspondances attendues pour l'ensemble des articles.

• Types de défis : 15 types de défis différents mettant à l'épreuve divers aspects de la résolution d'entités.

Les types de défis inclus dans l’ensemble de données sont les suivants :

• Surnoms : « Bob Smith » → « Robert Smith » (sept articles).

• Titres et titres honorifiques : « Dr. » Sarah Williams » → « Sarah Williams » (cinq articles).

• Contexte sémantique : « auteur russe » → « Leo Tolstoy » (huit articles).

• Noms multilingues : traitement des noms dans différentes écritures (six articles).

• Entités commerciales : variations de noms d’entreprises (sept articles).

• Références exécutives : « PDG de Microsoft » → « Satya Nadella » (cinq articles).

• Dirigeants politiques : références basées sur un titre (cinq articles).

• Initiales : « J. Smith » → « John Smith » (trois articles).

• Variations dans l’ordre des noms : différentes conventions d’ordre des noms (trois articles).

• Noms tronqués : correspondances partielles de noms (trois articles).

• Découpage des noms : noms séparés dans le texte (trois articles).

• Espaces ou tirets manquants : variations de mise en forme (deux articles).

• Translittération : correspondance de noms entre différents systèmes d’écriture (deux articles).

• Défis combinés : plusieurs défis dans un même article (six articles).

• Cas d’entreprise complexes : relations hiérarchiques entre entités commerciales (cinq articles).

Examinons comment la résolution d’entités basée sur des prompts s’est comportée.

Performance globale

Les résultats montrent un fort potentiel pour l’évaluation des correspondances assistée par LLM, mais ils mettent également en évidence un problème significatif de fiabilité. Chaque paire candidate doit être évaluée par le LLM. Des erreurs dans la sortie structurée peuvent réduire la précision et le rappel, même lorsque la phase de récupération fonctionne correctement.

Métrique

Valeur

Précision

83,8 %

Rappel

62,6 %

Score F1

71,7 %

Nombre total de correspondances trouvées

344

Taux d'acceptation des LLM

44,8 %

Taux d'erreur

30,2 %

Le problème du taux d'erreur

Rappelons que la première étape du prototype consiste à créer des paires de correspondances potentielles à l’aide d’Elasticsearch. Chacune de ces correspondances potentielles doit ensuite être évaluée par le LLM. Pour traiter efficacement l’ensemble de ces correspondances, nous regroupons les appels au LLM par lots. Cela réduit les coûts d’API et la latence, mais augmente également le risque d’obtenir un JSON mal formé en sortie. À mesure que la taille des lots augmente, le JSON devient plus long et plus complexe, ce qui accroît la probabilité que le LLM génère un JSON invalide. C’est de là que provient le taux d’erreur de 30 %. Dans cette évaluation, nous avons utilisé une taille de lot de cinq correspondances par requête. Même avec cette taille de lot conservatrice, nous constatons toujours des échecs d'analyse JSON, ce qui fausse considérablement les résultats de l'évaluation.

Prochaine étape : optimiser l’intégration des LLM

Maintenant que nous avons mis en correspondance des entités à l’aide de la recherche sémantique et du jugement d’un LLM, nous disposons d’un pipeline complet de résolution d’entités. Cependant, cette approche introduit un nouveau mode de défaillance : le jugement du modèle peut être correct, mais sa sortie inutilisable. Nous pouvons optimiser l’intégration du LLM afin d’améliorer la fiabilité et la rentabilité. Dans le prochain article, nous verrons comment utiliser le function calling pour produire une sortie structurée, garantissant une structure et un typage sûrs, tout en réduisant les erreurs et les coûts.

Essayez par vous-même

Envie de voir la mise en correspondance d’entités en action ? Consultez le carnet de notes sur l'appariement des entités pour une présentation complète avec des implémentations réelles, des explications détaillées et des exemples pratiques. Le carnet vous montre exactement comment faire correspondre les entités à l'aide de la recherche en trois étapes, de la recherche hybride avec RRF et du jugement raisonné basé sur le LLM.

Rappel : il s’agit d’un prototype pédagogique conçu pour illustrer les concepts. Lors de la mise en œuvre d’un système en production, tenez compte de facteurs supplémentaires tels que la sélection du modèle, l’optimisation des coûts, les exigences en matière de latence, la validation de la qualité, la gestion des erreurs et la supervision — des aspects qui ne sont pas couverts dans ce prototype à visée pédagogique.

Remarques

1. Ces ensembles de données sont synthétiques et conçus à des fins pédagogiques. Ils reflètent des défis réels, mais ne représentent aucun domaine de production spécifique.