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é
Concaténez les champs clés de l'objet en une seule chaîne, dans votre langue principale. La clé d'une entité imbriquée y contribue aussi, comme élément de désambiguïsation : un film portant un titre que partage un autre film se distingue par le nom de son réalisateur. Revers de la médaille : tous les objets frères qui référencent la même entité liée portent cette même valeur ; lorsqu'une clé liée ne fait que rendre les frères identiques, retirez-la des participants. 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 exactement 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 génèrent des ID identiques. Le texte est normalisé (mise 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 sur laquelle rien ne peut être regroupé, joint ni dédupliqué : 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é propres à l'objet 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 (le code d'une entité liée ne fait jamais l'affaire : tous les objets frères qui référencent cette entité le partagent). Une correspondance exacte de code tranche l'identité immédiatement, quelle que soit la formulation environnante : ainsi LC-39A unifie toutes les façons d'écrire le reste du texte. 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 aux identifiants différents sont deux choses, si 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
Interroger le juge
Les quelques concepts les plus proches sont transmis à un petit modèle de langage, qui répond à une seule question : l'un d'eux désigne-t-il la même chose dans le monde réel ? Il voit chaque désignation sous forme de parties étiquetées — jamais le score de similarité, qui ne ferait que l'inciter à se fier à la géométrie. S'il répond oui, cet ID est réutilisé et la nouvelle formulation est mémorisée comme une graphie de plus du même concept : l'occurrence suivante est alors gratuite. S'il répond non, ou s'il ne peut pas trancher, un ID entièrement nouveau est créé — jamais l'inverse, car deux lignes se fusionnent facilement par la suite, alors qu'une ligne fusionnée à tort, non.

Pourquoi un modèle et non un nombre : la similarité seule se trompe dans les deux sens. Deux graphies d'un même chantier naval peuvent obtenir des scores très éloignés, tandis qu'une affection et son contraire (« aiguë » contre « chronique ») obtiennent des scores presque identiques. Aucun seuil ne les sépare ; seule la connaissance du sens des mots le permet. Le seuil du juge (par défaut 0.5, ajustable par propriété) détermine uniquement jusqu'où chercher des candidats qui méritent une question — il ne décide jamais de l'identité.

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 :

Voici à quoi ressemble un ID résolu côté vocabulaire : plusieurs graphies, un seul concept, un total d'utilisations — et l'étiquette auto signale la forme intégrée par le juge d'identité.

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.

Documentation associée

Concepts clés
Clés de recherche et de fusion, sur lesquelles reposent les identifiants sémantiques
Enrichissement multilingue
Regrouper les graphies multilingues en une seule identité
Fusion multi-modèle
Réconcilier entre les modèles au sein d'une même exécution
Éditeur de workflow
Ajouter des ID sémantiques à n'importe quel objet
La page des ID sémantiques
Parcourir, curer et dédupliquer le vocabulaire obtenu