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.preserve) : toujours une chaîne, jamais une clé, jamais multilingue, au plus un par objet.manufacturer), ou chaque élément d'un tableau (par ex. chaque side_effect).Après que le modèle a renvoyé son résultat, Entity Enricher résout chaque ID sémantique en quatre étapes — en commençant par la moins coûteuse :
« Acme Inc. » et« Acme Incorporated » se retrouvent côte à côte.0.92, ajustable par propriété), l'ID de ce concept est réutilisé. Sinon, un tout nouvel ID est créé et stocké pour la prochaine fois.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 via les quatre é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) et dans les concepts sémantiques du détail de l'enregistrement. 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.