Résolution Intelligente d'Entités

Que fait Résolution Intelligente d'Entités ?

Résolvez les identités au niveau d'effort le plus bas qui permet d'établir une réponse fiable. Ne montez en niveau que lorsque les identifiants, les correspondances ou les preuves de corroboration existants sont insuffisants. Cette compétence s'applique aux enregistrements de personnes et d'organisations véritablement ambigus, y compris les candidats de profil ou médias concurrents ; les tâches ordinaires de traitement d'image et de jointure d'ID déterministes ne la nécessitent pas.

Principe Fondamental

Considérez la résolution d'entités comme une investigation par étapes, pas comme une simple recherche. La recherche exacte, la recherche par slug, la popularité et le jugement du LLM sont tous des signaux utiles, mais aucun ne doit dominer les autres silencieusement.

Séparez trois questions :

• Couverture : avons-nous énuméré toutes les entités demandées ?
• Identité : ce candidat représente-t-il la personne ou l'organisation demandée ?
• Utilité : ce dossier est-il le meilleur enregistrement utilisable pour la tâche ?

Un enregistrement de haute utilité avec une preuve d'identité faible est un risque de faux positif. L'identité prime sur la popularité, l'exhaustivité du profil, la disponibilité de l'image et le classement dans les recherches.

Niveaux de Résolution

Choisissez le niveau suffisant le plus bas ; un niveau supérieur n'est pas un prérequis obligatoire.

• Niveau 0 — Identification directe : Faites correspondre un ID stable faisant autorité, une URL canonique ou un identifiant de compte vérifié. Arrêtez-vous lorsque cela résout la tâche.
• Niveau 1 — Réconciliation déterministe : Utilisez des correspondances explicites, des alias révisés, des identifiants documentés spécifiques à la source, ou des liens d'identité vérifiés. N'inventez jamais de correspondance.
• Niveau 2 — Identification contextuelle : Corroborez un nom en utilisant l'événement, la session, l'affiliation pertinente dans le temps, le profil personnel, la propriété du projet, ou des identifiants de source vérifiés de manière indépendante. Passez à un niveau supérieur lorsque les candidats ou les preuves sont en conflit.
• Niveau 3A — Découverte de profil officiel : Trouvez des sites web et comptes sociaux auto-contrôlés, des pages officielles d'orateurs, des annuaires d'employeurs, ou des profils d'auteurs et de projets. Privilégiez les profils liés depuis une autre source de confiance.
• Niveau 3B — Corroboration indépendante : Comparez les identifiants, alias, événements, projets, affiliations et dates à travers des sources indépendantes. Les copies syndiquées d'une même biographie ne comptent pas comme une confirmation distincte.
• Niveau 3C — Réconciliation d'alias et historique : Résolvez les noms de scène, les variantes orthographiques, les translittérations, les employeurs historiques, les acquisitions et les apparitions inter-événements en utilisant des correspondances explicites ou une corroboration indépendante. Gardez les affiliations limitées dans le temps.
• Niveau 3D — Récupération de candidats : Recherchez des alias et des noms contextualisés, sondez les ID directs, les URL et les slugs, et utilisez un LLM pour suggérer des sondes de récupération ciblées uniquement lorsque la recherche ordinaire ne trouve pas d'enregistrement plausible. Les candidats générés ne sont pas des identités vérifiées.
• Niveau 3E — Décision haute fidélité : Comparez les preuves d'identité, l'autorité de la source, la cohérence historique, les enregistrements conflictuels et les alternatives significatives. Un LLM peut résumer ou reclasser les candidats mais ne peut pas remplacer une identification basée sur des sources.
• Niveau 4 — Sensible ou non résolu : Exigez un examen explicite lorsque les identités restent ambiguës, que des fusions durables ou des publications auraient des conséquences, que des informations privées seraient exposées, ou qu'une identification biométrique serait autrement nécessaire. Renvoyez ambiguous, needs_review ou unresolved.

Sources Préférées

Pour l'identité et l'auto-présentation actuelle, priorisez les sources auto-contrôlées :

1. Site web personnel, blog ou domaine personnel vérifié.
2. Compte X/Twitter.
3. Profil LinkedIn.
4. Profil GitHub.
5. Profil Hugging Face.
6. Google Scholar, Semantic Scholar, ORCID ou profil auteur arXiv.
7. Chaîne YouTube personnelle.
8. Profil Substack, Medium ou Dev.to.
9. Compte Bluesky ou Mastodon.

Les liens réciproques, les identifiants cohérents, les domaines partagés, la propriété du projet et l'historique des publications renforcent l'identité. Un nom d'affichage correspondant ou un badge de plateforme seul n'établit pas la propriété du compte.

Modifiez la priorité des sources lorsque la question change :

• Participation à un événement et affiliation historique : Les identifiants émis par l'organisateur, les pages et horaires officiels des orateurs, les biographies spécifiques à l'événement, les enregistrements Sessionize ou Accelevents, et les supports de présentation contemporains priment sur les profils ultérieurs.
• Rôle actuel ou auto-présentation : Un site web personnel récemment maintenu, un compte social vérifié ou une page d'employeur actuel prime sur une ancienne biographie de conférence.
• Photo de profil canonique : Privilégiez l'image de profil vérifiée et auto-sélectionnée de la personne, une photo officielle approuvée par l'organisateur, ou un portrait officiel d'événement lié à un ID stable. Une URL publique n'accorde pas les droits de redistribution ou d'entraînement d'image.
• Recherche générale : Utilisez les résultats Web pour découvrir des candidats ou corroborer des faits ; ne traitez pas le classement des recherches comme une preuve.

Ne traitez jamais une vignette devinée, une photographie de session à proximité, une similitude faciale ou un embedding biométrique comme une preuve d'identité vérifiée.

Workflow

1. Classez la requête avant de chercher. Détectez s'il s'agit d'une seule entité, d'une liste d'entités, ou d'une requête de groupe flou (membres, casting, équipe, organisation). Les termes comme members, cast, lineup, team, company, subsidiaries et leadership signifient généralement qu'une expansion est nécessaire.

2. Analysez les requêtes de type instruction avant la recherche. Les utilisateurs intègrent souvent des indices d'entité dans le texte de la tâche, comme trouvez les profils complets pour..., devinez le groupe qui inclut... ou résolvez ces noms partiels.... Extrayez la région d'indice d'entité, conservez l'instruction originale comme contexte, et n'envoyez pas la chaîne d'instruction entière comme une requête de base de données littérale.

3. Développez les requêtes floues en groupes d'entités uniquement lorsque l'identification directe ou les correspondances documentées sont insuffisantes. Utilisez un LLM ou des outils de recherche lorsque cela est vraiment nécessaire pour énumérer des individus ou des organisations. Gardez les alias regroupés sous une seule entité.

4. Recherchez largement par groupe d'entités. Pour chaque entité, recherchez plusieurs alias, variantes nettoyées, slug exact ou candidats d'ID direct lorsque la base de données cible les prend en charge, et requêtes de nom court contextualisées comme <groupe> <nom court>. Utilisez un suivi de requête local par entité ; la déduplication globale des requêtes peut affamer les entités ultérieures avec des alias courants.

5. Envisagez un planificateur de récupération LLM lorsque la récupération déterministe est vide ou faible. La planification est distincte du reclassement : demandez des ID directs, des slugs d'URL, des sondes de nom exact, des alias et des recherches contextuelles. Gardez les sondes limitées et de haute précision.

6. Fusionnez les candidats par identité d'enregistrement stable. Dédupliquez par id de profil, slug, URL canonique, id de base de données, ou une autre clé stable. Préservez chaque requête et source qui a trouvé le candidat plutôt que de ne conserver que le chemin le plus score élevé.

7. Enrichissez les candidats avant le reclassement. Rassemblez des preuves conceptuelles en termes d'identité, de provenance, d'utilité, d'ambiguïté et de confiance. Le reclassement ne doit jamais être invité à choisir uniquement à partir de noms.

8. Utilisez le reclassement LLM limité uniquement pour les candidats véritablement concurrents. Continuez uniquement lorsqu'une autre passe peut améliorer matériellement la couverture ou distinguer des identités probables.

9. Affichez des alternatives significatives lorsqu'elles pourraient changer la décision ou permettre une correction ; une correspondance exacte d'ID faisant autorité n'a pas besoin de deuxièmes choix fabriqués.

10. Traitez non résolu et incertain comme des résultats de première classe. Préférez needs review, no plausible match ou ambiguous plutôt que de remplir silencieusement un faux positif de haute utilité.

Noms Partiels Et Instructions Floues

Lorsqu'une requête contient principalement des prénoms, des alias courts, des initiales ou des noms d'organisation partiels, ne considérez pas les résultats bruts de la base de données comme suffisants. Développez ou classifiez lorsque les termes de groupe, l'intention de profil complet ou les noms principalement à un jeton rendent les résultats directs peu fiables.

Conservez deux représentations de la requête :

• originalQuery : l'instruction utilisateur complète et le contexte.
• entityHints : la liste extraite des noms de candidats ou alias à résoudre.

Le modèle d'expansion doit voir les deux. Demandez-lui de déduire le contexte partagé probable et de renvoyer des entités concrètes avec des alias groupés. Pour chaque entité développée, conservez un label plus les alias, puis recherchez ces alias dans cette branche d'entité. Le chemin de recherche directe peut toujours fonctionner pour les noms exacts simples, mais ne doit pas supprimer l'expansion lorsque la couverture dépend de l'inférence d'identités complètes à partir d'indices partiels.

La couverture est distincte du volume de résultats. Cinq indices demandés qui produisent de nombreux candidats bruts ne sont pas résolus tant que chaque indice n'est pas mappé à une entité sélectionnée ou à un résultat explicite non résolu/ambigu. Suivez expectedCount, resolvedCount, ambiguousCount et unresolvedHints ou des champs équivalents.

Planification De Récupération Et Réparation Des Lacunes

Ne comptez pas sur un reclassement pour sauver des enregistrements que la récupération n'a jamais renvoyés. Divisez l'implication du LLM en rôles distincts :

• Modèle d'expansion : « Qui ou quoi sont les entités cibles ? »
• Planificateur de récupération ou modèle de réparation : « Quels ids exacts, slugs, URL directes, alias et sondes de recherche le récupérateur doit-il essayer pour cette cible ? »
• Modèle de reclassement : « Étant donné ces candidats enrichis, lequel est l'enregistrement correct ? »

Utilisez la planification de récupération uniquement lorsque des slugs ou ID directs peuvent récupérer un enregistrement manquant, ou lorsqu'une entité n'a aucun candidat, aucune donnée utilisable, ou seulement des correspondances faibles/noms communs. Donnez au planificateur la requête originale, les alias groupés, les sondes tentées, les échecs de source et les contraintes de source pertinentes. Il doit renvoyer des sondes, pas une décision d'identité.

Gardez la réparation limitée et proportionnée. Exécutez une récupération déterministe sur les sondes utiles, fusionnez les candidats récupérés et marquez une entité comme non résolue lorsqu'une recherche supplémentaire est peu susceptible de changer la réponse.

Journalisation Et Fan-Out

Enregistrez la provenance de la source, les ID sélectionnés, l'ambiguïté et la couverture proportionnellement à la tâche. Évitez les charges utiles privées brutes. Lorsque des groupes d'entités indépendants sont déjà traités simultanément, gardez l'état des branches isolé et fusionnez de manière déterministe ; n'introduisez pas de fan-out, d'infrastructure de télémétrie ou de nouvelles tentatives uniquement pour satisfaire cette compétence.

Modèle De Preuve

Gardez la preuve conceptuelle et portable. Ne vous surajustez pas aux champs d'un seul site.

• Preuve d'identité : correspondance de nom ou d'ID exact(e), alias, noms de scène, noms légaux, variantes de romanisation, tokens partagés, tokens primaires manquants, correspondance contextuelle, relation connue avec une organisation/groupe, et noms conflictuels.
• Preuve de provenance : quelle requête a trouvé le candidat, qu'il provienne d'une recherche, d'un slug exact, d'une URL directe, d'un ID de base de données, d'une recherche API, d'un résultat Web, d'une source fournie par l'utilisateur, d'une sonde du planificateur de récupération, ou d'une passe de récupération.
• Preuve d'utilité : nombre d'images, exhaustivité du profil, activité, popularité, vues, votes, nombre de listes, nombre d'employés, nombre de relations, statut vérifié, récence, et si l'enregistrement a des médias ou métadonnées utilisables pour la tâche.
• Preuve d'ambiguïté : nom court/courant, correspondance de nom de famille uniquement, initiales, enregistrements en double, pages de groupe/projet, pages « and the », enregistrements clairsemés, alias conflictuels, anciens noms, organisations fusionnées, filiales, ou personnalités publiques de nom similaire.
• Preuve de confiance : candidat sélectionné, candidats finalistes, raison du reclassement, statut non résolu, indicateur de nécessité de révision humaine, et statut de couverture pour la requête originale.

Règles De Reclassement

Utilisez le reclassement LLM lorsque l'ambiguïté réelle le justifie, contraint par les preuves de source et un budget adapté à la tâche.

• Donnez au reclassement la requête originale, le label de l'entité résolue, les alias, les noms/ID/URL des candidats, la provenance, les preuves d'identité, les preuves d'utilité et les avertissements d'ambiguïté.
• Demandez-lui de choisir l'identité avant l'utilité. Il ne doit pas choisir un candidat riche en images ou populaire si la preuve d'identité est faible.
• Pour les candidats plausiblement de la même identité, laissez l'utilité décider. Les enregistrements publics de nom de scène ou de marque peuvent être meilleurs que les enregistrements de nom légal s'ils ont des preuves plus solides pour la tâche.
• Traitez les alias à un seul jeton comme ambigus, sauf s'ils sont soutenus par le contexte, un ID/slug exact(e), un chevauchement d'alias plus riche, ou des preuves externes fortes.
• Évitez les règles d'acceptation dure. Un hit d'alias direct est un signal, pas une preuve.
• Évitez les règles de rejet dure. Les enregistrements romanisés, renommés, clairsemés ou de nom de scène peuvent sembler incomplets mais peuvent encore être corrects.
• Si un candidat tout aussi bien soutenu a une utilité de tâche substantiellement meilleure, exposez-le ou effectuez une comparaison justifiée supplémentaire plutôt que de passer silencieusement outre la preuve d'identité.
• Journalisez ou affichez la raison du candidat sélectionné et gardez les alternatives visibles.

Modes D'Échec

Utilisez-les comme des vérifications de révision lorsqu'un résolveur « fonctionne généralement » mais semble erroné.

• La recherche exacte dans la base de données peut manquer des enregistrements réels. Sondez les slugs exacts, les URL directes, les ids ou les points de terminaison alternatifs lorsqu'ils sont disponibles.
• Les noms courts créent des faux positifs. Lisa, Rose, Sunny, Tiffany, Yuri et autres noms à un jeton nécessitent des recherches contextuelles et des avertissements d'ambiguïté.
• Les noms légaux peuvent être des enregistrements de moins bonne utilité. Les noms publics/de scène ou de marque peuvent avoir le profil plus complet, plus d'images ou des métadonnées plus actuelles.
• Les signaux d'utilité sont puissants mais dangereux seuls. Les comptes, votes, vues et la popularité ne devraient départager qu'après plausibilité de l'identité.
• Les alias composites sont un contexte utile mais souvent de mauvaises chaînes de recherche littérales. Divisez-les en alias tout en préservant l'identité du groupe.
• La logique d'acceptation directe dure est fragile. Elle peut saisir un doublon générique simplement parce qu'un alias correspondait.
• Les barrières d'identité dures sont fragiles. Elles peuvent cacher des enregistrements corrects lorsque les noms sont rares, traduits, romanisés, renommés ou uniquement de nom de scène.
• Le nombre de couverture n'est pas l'exactitude. Trouver 6 entités sur 6 n'est pas un succès si un enregistrement sélectionné est la mauvaise personne ou organisation.
• La déduplication globale des requêtes peut affamer les entités ultérieures. Les alias courants doivent être suivis par groupe d'entités.
• L'instabilité des sources fait partie du résultat. Les timeouts, 403, 404, les nouvelles tentatives et les données partielles doivent être exposés dans les logs de provenance ou de débogage.
• Les reclassements ne peuvent pas corriger les candidats manquants. Si une branche cible a zéro candidat, insérez une planification de récupération ou une réparation avant le reclassement au lieu de vous attendre à ce que le reclassement déduise un enregistrement caché.
• Le texte d'instruction peut empoisonner la recherche littérale. Supprimez les phrases de tâche de la requête de recherche tout en les conservant comme contexte pour l'expansion et le reclassement.
• Les résultats directs rapides peuvent supprimer les indices contextuels nécessaires à la désambiguïsation. Validez toujours la couverture, l'identité et l'utilité avant de finaliser une sélection.

Directives D'Implémentation

• Utilisez un cadre de résolution d'entités modulaire qui sépare les préoccupations : analyse de la requête, expansion, récupération, enrichissement, reclassement et décision.
• Pour chaque entité, suivez les métriques de couverture et d'ambiguïté tout au long du pipeline.
• Lorsque vous utilisez des API ou bases de données externes, gérez les erreurs avec élégance et dégradez-vous plutôt que d'échouer sur une seule source indisponible.
• Testez avec un mélange de noms simples, de listes, de noms partiels et de requêtes d'instructions pour vous assurer que le comportement d'expansion et de reclassement est correct.

Propriété Et Licence

Cette compétence est fournie à titre informatif et d'utilisation. Adaptez-la si nécessaire à votre plateforme d'agent spécifique (Claude Code, Cursor, Codex, etc.). Assurez-vous que toute implémentation respecte les conditions d'utilisation des sources de données utilisées (API, bases de données, services Web).