Enrichissez le même type d'entité encore et encore, et vous redécouvrez sans cesse les mêmes objets du monde réel — la même entreprise, le même effet secondaire de médicament, la même personne — décrits chaque fois avec des mots légèrement différents. Un ID sémantique est un identifiant stable, propre à l'organisation, qu'Entity Enricher attribue à un objet à partir de ses champs clés, afin que ces quasi-doublons se regroupent en une seule identité sur laquelle vous pouvez grouper, dédupliquer et effectuer des jointures.
L'identité d'un objet est construite à partir de ses champs clés — il peut y en avoir un ou plusieurs. Deux exemples :
nameIl apparaît sous les formes Headache, Céphalée et Cephalalgia selon les exécutions et les langues. Un champ clé, trois graphies, un seul concept réel.
nom + paysAcme Inc. · États-Unis et Acme Incorporated · États-Unis sont la même entreprise — tandis que Acme Inc. · Allemagne en est une différente. La seconde clé lève l'ambiguïté ; c'est pourquoi un objet peut en porter plusieurs.
La correspondance de chaînes brute échoue dans tous ces cas ; un humain sait lesquels sont identiques. Les identifiants sémantiques encodent ce jugement automatiquement.
string sur un objet (nommée id par défaut), contenant un identifiant opaque et stable.manufacturer), ou chaque élément d'un tableau (par ex. chaque side_effect).Une fois que le modèle a renvoyé son résultat, Entity Enricher résout chaque ID sémantique en six étapes — de la moins coûteuse à la plus coûteuse. Les quatre étapes situées avant l'embedding sont de pures comparaisons de texte : une identité tranchée à ce stade ne coûte donc absolument rien :
null dans son parent, et un élément d'une liste est retiré de la liste. L'entité enrichie elle-même n'est jamais supprimée ; elle n'a simplement pas d'ID.LC-39A unifie ainsi toutes les façons dont le reste du texte a été rédigé. Tout aussi important, l'inverse est vrai : un code différent oppose son veto à une fusion que l'étape d'embedding aurait sinon acceptée, car deux choses portant des identifiants différents sont deux choses, aussi semblables soient-elles à la lecture.« Boeing » et « The Boeing Company ». Cela rattrape précisément les écarts de verbosité que les embeddings jugent très éloignés, et cela ne coûte rien : comme à l’étape du texte exact, une correspondance ici évite tout appel d’embedding et toute facturation.« Acme Inc. » et « Acme Incorporated » se retrouvent côte à côte.0.92 par défaut, ajustable par propriété), l'ID de ce concept est réutilisé. Sinon, un tout nouvel ID est créé et conservé pour la suite. Une exception l'emporte sur un score élevé : lorsque les deux textes sont les mêmes mots comptés différemment — « deuxième étage » et« troisième étage » —, ils sont traités comme des choses différentes, car c'est précisément le comptage qui les distingue. Un même nombre écrit de deux façons (2 etII) correspond toujours.Compromis du seuil : un seuil plus élevé est plus strict (moins de fusions accidentelles) ; un seuil plus bas est plus permissif (déduplication plus agressive). Ajustez-le par propriété lorsque la valeur par défaut de 0,92 fusionne trop ou pas assez.
Qu'un ID soit généré dépend de la présence d'un ID déjà fourni dans l'entrée pour cet objet. C'est ce qui permet l'aller-retour : enrichissez une fois pour obtenir les ID, puis renvoyez un ID connu lors des exécutions suivantes pour rattacher de nouveaux faits à la même identité — plus économique et sans ambiguïté.
Si l'objet que vous envoyez porte déjà un ID sémantique, il est traité comme une consultation : l'ID est conservé tel quel, l'enregistrement est lié à ce concept existant, et il n'y a aucun embedding — aucun coût, aucun appariement ni création d'ID. Vous indiquez à la plateforme « cet objet est déjà identifié dans notre base de données ».
Si l'objet n'a pas d'ID sémantique, la plateforme en génère un selon les étapes ci-dessus. Cet ID devient dès lors l'identifiant stable de l'objet dans la base de données de votre organisation.
Une valeur présente mais non reconnaissable (pas un véritable identifiant de concept) est ignorée, et un identifiant est généré à la place.
La résolution consomme une petite quantité d'usage d'embeddings par enrichissement (facturée comme tout appel de modèle). Le cache de correspondance exacte rend les répétitions gratuites, et les ID fournis en entrée ne coûtent rien.
Les ID résolus apparaissent dans le JSON de sortie de l'enrichissement (le champ id de chaque objet), dans les concepts sémantiques du détail de l'enregistrement, et tous ensemble sur la page des ID sémantiques, où le vocabulaire qu'ils forment peut être parcouru et organisé. Utilisez-les pour :
La fusion réconcilie les désaccords entre modèles au sein d'une même exécution ; les ID sémantiques réconcilient la même entité à travers les exécutions et le temps. Les deux fonctionnent de concert.