ID sémantiques - Documentation Entity Enricher

ID sémantiques

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.

Le problème : même chose, mots différents

L'identité d'un objet est construite à partir de ses champs clés — il peut y en avoir un ou plusieurs. Deux exemples :

Une seule clé

Un effet de bord indexé par name

Il 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.

Deux clés

Une entreprise identifiée par nom + pays

Acme 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.

Ce qu'est un ID sémantique

Comment ça fonctionne

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 :

1
Composer le texte d'identité
Réunit les champs clés qui identifient l'objet lui-même en une seule chaîne, dans votre langue principale. Un objet imbriqué qui constitue une entité à part entière est exclu : sa clé le désigne lui, et non ce qui y fait référence, et tous les champs voisins renvoyant à la même entité porteraient cette même valeur — deux missions partageant un site de lancement se liraient presque à l'identique et risqueraient d'être fusionnées en une seule. Les objets imbriqués qui se contentent de regrouper des champs y contribuent malgré tout ; de même que la clé d'une entité liée si vous l'ajoutez vous-même. Les éléments contenus dans des tableaux ne sont jamais repris : chaque élément de tableau possède sa propre identité. La liste participants à l'identité de l'éditeur de schéma indique précisément quelles valeurs composent le texte et vous permet de les réordonner ou de les modifier — des schémas qui retiennent les mêmes participants dans le même ordre produisent des ID identiques. Le texte est normalisé (passage en minuscules, suppression des parenthèses, espaces réduits) afin d'atténuer les différences insignifiantes. Si tous ces champs clés reviennent vides, plus rien ne permet d'identifier l'objet et aucun ID ne peut lui être attribué — l'objet est donc supprimé plutôt que conservé sous une forme anonyme, sans possibilité de regroupement, de jointure ou de déduplication : un objet imbriqué devient 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.
2
Rechercher une correspondance exacte
Si ce texte normalisé exact a déjà été rencontré dans votre organisation, son ID existant est réutilisé immédiatement — aucun appel de modèle, aucun coût.
3
Rapprocher sur un code, s'il en existe un
Lorsque l'une des clés d'identité est un code — un champ contraint par un motif, ou dont les exemples ressemblent à des identifiants —, il est composé en premier et comparé isolément. Une correspondance exacte de code tranche immédiatement l'identité, quelle que soit la formulation environnante : 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.
4
Rapprocher sur les mêmes mots, quel que soit l'ordre
Avant de dépenser un embedding, les mots eux-mêmes sont comparés comme des ensembles : si les mots d’un texte sont contenus dans ceux de l’autre, il s’agit de la même identité écrite plus ou moins longuement — « 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.
5
Vectoriser et comparer
Sinon, le texte est vectorisé et comparé, par le sens, aux concepts existants du même type de concept (le nom du type d'entité par défaut — modifiable dans l'éditeur pour que des schémas aux noms différents partagent un même espace de concepts) à l'aide de la similarité vectorielle — de sorte que « Acme Inc. » et « Acme Incorporated » se retrouvent côte à côte.
6
Réutiliser ou créer
Si la correspondance la plus proche dépasse le seuil de similarité (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.

ID d'entrée vs ID générés

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é.

ID déjà présent dans l'entrée → conservé (consultation)

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 ».

Aucun ID dans l'entrée → généré

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.

Comment l'activer

1
Choisissez un modèle d'embedding (une fois par organisation)
Un propriétaire choisit un modèle capable de générer des embeddings dans Paramètres → Organisation → Valeurs par défaut comme modèle d’embedding par défaut de l’organisation (réglage soumis au forfait ; voir Modèles et tarifs pour savoir quels modèles savent générer des embeddings). Les vecteurs stockés ne sont pas comparables d’un modèle à l’autre : dès que des concepts existent, le réglage peut uniquement être effacé — un changement s’effectue sous forme de migration depuis la page ID sémantiques, qui réencode chaque concept en conservant son ID. Sans modèle, les ID sémantiques sont simplement ignorés.
2
Ajouter des ID sémantiques au schéma
Deux façons de faire, toutes deux dans l'Éditeur de workflow :
  • Automatiquement à la génération — cochez « Générer des ID sémantiques pour les types » ; chaque objet doté d'une clé (la sienne, ou celle d'un objet imbriqué en 1-1) en reçoit un, y compris l'entité racine.
  • Manuellement — utilisez le contrôle « + Ajouter un ID sémantique » sur n'importe quel objet ou dans le pied de page de l'entité.

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.

Où apparaissent les ID et comment les utiliser

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 :

Complète la fusion multi-modèles

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.