Chaque enrichissement qui résout un ID sémantique réutilise un concept que votre organisation connaît déjà ou en crée un nouveau. La page ID sémantiques est l'endroit où ce vocabulaire grandissant devient consultable : parcourez-le, mesurez la proximité réelle de deux entrées, ajoutez des termes à la main, répondez aux questions que le juge d'identité vous laisse, retirez ce dont vous ne voulez plus, et migrez l'ensemble vers un autre modèle d'embedding.
Elle se trouve à /semantic-ids dans la barre latérale, et n'est utile que lorsque votre organisation dispose d'un modèle d'embedding et d'au moins un schéma portant un ID sémantique — les concepts sont créés par les enrichissements, pas par la page.
Chaque ligne correspond à un concept : son texte canonique (le texte d'identité qui l'a créé à l'origine), son type de concept (l'espace dans lequel il vit — par défaut, le nom du type d'entité), le nombre d'enregistrements qui l'utilisent, et sa date de création. Filtrez par texte, par un nombre quelconque de types de concept, par les schémas qui y écrivent, ou par un nombre minimal d'utilisations pour repérer les entrées qui méritent votre attention. Sélectionner des schémas est un raccourci vers leurs types de concept — et comme un type est partagé, cela affiche aussi les concepts créés par un autre schéma dans ce même type. Exporter la vue télécharge exactement ce que les filtres affichent.
La similarité n'est mesurée qu'au sein d'un seul espace. Les vecteurs ne sont comparables qu'à l'intérieur d'un même type de concept et d'un même modèle d'embedding. Les lignes situées hors de l'espace du concept sélectionné affichent —, ce qui signifie « non comparable » — jamais « 0 % ».
Parfois, vous connaissez le vocabulaire avant l'arrivée des données — une liste de plats, de statuts, de familles de produits. La barre Curation est conçue pour saisir cette liste : limitez-la une fois à un type de concept — la portée est inscrite dans l'adresse de la page, donc /semantic-ids/<type de concept> est un lien direct vers cette sélection — puis répétez saisir une valeur → Vérifier → Ajouter. Entrée vérifie, un second Entrée ajoute, et le champ se vide tout en gardant le focus : un vocabulaire de cinquante termes se saisit en quelques minutes sans toucher la souris.
Vérifier est un essai à blanc de la véritable échelle de résolution — celle-là même qu'exécute un enrichissement — son verdict n'est donc pas une estimation. Et comme vous avez déjà payé ce verdict, il sert aussi de garde-fou contre les doublons : lorsqu'un concept existant couvre votre texte au seuil ou au-delà, Ajouter un concept reste désactivé.
Ce refus est délibéré : un jumeau situé au-dessus du seuil ne pourrait jamais l'emporter lors d'une résolution, et répartirait les correspondances futures de façon imprévisible entre les deux entrées. Le curseur Seuil placé à côté du champ détermine où se situe cette limite pour vos vérifications — augmentez-le pour être plus strict, abaissez-le pour fusionner plus agressivement.
Le vocabulaire n’est pas non plus obligé de partir d’un enrichissement : Nouveau type de concept… (dans la barre d’outils de la page, rôle éditeur et supérieur) nomme un type et choisit le modèle d’embedding dans lequel vivront ses concepts — par défaut celui de votre organisation. La barre de curation lui est aussitôt limitée, et le type rejoint le vocabulaire avec le premier concept que vous ajoutez ; un type déjà existant conserve son modèle, puisque déplacer un vocabulaire d’un modèle à un autre est précisément le rôle de la migration.
Rien n'arrive dans Révision par simple ressemblance. Chaque paire ici résulte d'une décision du juge d'identité qui vous la laisse : il n'a pas pu trancher (Incertain), il a trouvé deux de vos concepts équivalents à un même texte entrant (Semble dupliqué), ou il a séparé deux concepts aux mesures presque identiques (Maintenus distincts) — ce dernier cas vous est soumis pour que vous confirmiez qu'il n'a pas négligé le candidat évident. Chaque ligne comporte la phrase du juge expliquant ce qui a emporté sa décision.
Comparer → revient au tableau avec ce concept sélectionné, afin de voir ce qui se situe à proximité avant de décider. Fusionner… intègre l'un dans l'autre : les graphies du perdant deviennent des alias du gagnant, si bien que la paire converge partout et le reste. Ignorer clôt la question lorsqu'il s'agit réellement de deux choses distinctes. Le nombre d'utilisations indique lequel des deux les données privilégient réellement.
Le panneau de droite affiche l’ID du concept (copiable — c’est sur lui que votre base de données effectue ses jointures), son texte normalisé, le modèle d’embedding sous-jacent et les enregistrements qui y ont été résolus. Le concept sélectionné fait partie de l’adresse de la page : l’URL affichée dans votre barre d’adresse est donc un lien direct vers celui-ci — à partager avec un collègue ou à conserver dans un ticket. Deux vues le situent parmi ses voisins.
Aplatir 1536 dimensions en 3 ne peut pas préserver les distances, et la disposition exagère la compacité des grappes. Les deux vues colorent chaque point selon la même échelle de similarité : lisez donc la couleur, pas l'écart. La première carte d'une session met quelques secondes à se disposer ; les suivantes sont instantanées.
Chaque enregistrement lié affiche le score auquel il s'est résolu ici. Un — signifie que l'ID est arrivé dans l'entrée et a été transmis tel quel : rien n'a donc jamais été comparé — la voie gratuite et sans ambiguïté décrite dans le guide des ID sémantiques.
Importer et résoudre traite toute une colonne CSV avec la même cascade et annote chaque ligne avec ce qui lui arriverait — il n'y a aucune limite de taille de fichier ; les gros fichiers sont résolus par lots de 1000 avec progression en direct. Le fichier est analysé dans votre navigateur — seules les valeurs elles-mêmes sont envoyées.
| Résultat | Ce que cela signifie |
|---|---|
exact | Le même texte, normalisé, existe déjà — gratuit, sans appel au modèle. |
matched | Une formulation différente s'est résolue vers un concept existant au-dessus du seuil. |
would_mint | Rien n'était assez proche ; un enrichissement créerait ici un nouveau concept. |
minted | Le même cas, avec la création activée — le concept existe désormais (propriétaire uniquement). |
Le type de concept se saisit, il ne se choisit pas. Un fichier est une façon tout à fait normale de démarrer un vocabulaire : le champ suggère donc les espaces que vous avez déjà tout en acceptant un nom que vous n'avez pas — et affichenouveau quand c'est le cas. Un nom inédit pose la seule question qui ne pourra plus l'être ensuite : dans quel modèle d'embedding ses concepts vivront. Répondez-y ici et l'espace est créé avec la première valeur générée par l'import ; ensuite, déplacer un vocabulaire d'un modèle à un autre est une migration.
Deux mécanismes empêchent une erreur de devenir un second vocabulaire : saisir le nom d'un espace que vous possédez déjà le sélectionne, quelle que soit la casse, et un nom à une ou deux lettres d'un nom existant est signalé avec une correction en un clic. Face à un espace réellement nouveau, il n'y a rien à comparer : une exécution en mode correspondance seule répond donc « toutes les valeurs seraient créées » sans embedder la moindre ligne — et sans rien facturer.
Les lignes résolues se téléchargent dans leur propre CSV : un import peut donc aussi servir de simple audit — parmi nos 900 noms de fournisseurs, lesquels sont déjà connus, et lesquels ouvriraient une nouvelle identité ? Les exports fonctionnent dans l'autre sens et nomment le fichier d'après les filtres utilisés, si bien qu'un dossier d'exports reste explicite.
La suppression est sûre comme peu de suppressions de données le sont : le vocabulaire se reconstruit de lui-même, car le prochain enrichissement recrée simplement ce dont il a besoin. Ce qui ne revient pas, c'est la convergence avec les ID que vous avez déjà enregistrés, et la boîte de dialogue vous l'indique avec des chiffres réels avant que vous confirmiez.
Après un tel changement, conserver les anciens concepts est le choix risqué, et non le choix prudent : des identités composées à partir des nouvelles clés peuvent tout de même se retrouver à l'intérieur du seuil des anciens vecteurs et être silencieusement absorbées par eux, vous laissant avec des ID qui ne désignent ni l'un ni l'autre.
Les vecteurs issus de deux modèles différents ne sont pas comparables : changer de modèle impose de recalculer l’embedding de chaque concept. Une fois les concepts créés, cette migration est le seul moyen autorisé de le faire — et c’est la raison pour laquelle le paramètre de modèle d’embedding de l’organisation refuse de changer de lui-même.
L'aperçu indique ce que coûtera le ré-embedding, et quelles paires de concepts risquent d'entrer en collision — se retrouver à portée du seuil l'une de l'autre dans le nouvel espace et commencer à se résoudre ensemble. Il mesure les candidats réalistes plutôt que toutes les paires, et le précise.
Les enrichissements continuent de se résoudre dans l'ancien espace pendant que les nouveaux vecteurs sont construits à côté ; les concepts créés entre-temps sont repris par une passe ultérieure. La bascule se fait en une seule étape à la fin, qui change aussi le modèle d'embedding par défaut de votre organisation. L'interrompre est sans danger — en relançant, le processus reprend là où il s'était arrêté.
Les vérifications, ajouts et imports sont facturés comme tout autre usage d'embedding, et les correspondances exactes ne coûtent rien puisqu'elles n'atteignent jamais un modèle. La navigation, la comparaison, l'orbite, la carte 3D, l'export et la suppression sont gratuits. Une journée de dépenses interactives est regroupée en une seule ligne dans votre historique de crédits, afin que le registre reste lisible au lieu de se remplir de fractions de centime.