Registre d'embeddings

Statut documentaire : architecture — voir Maturité et preuves.

Le registre d'embeddings est le pont entre identité conceptuelle et identité vectorielle.

Pourquoi un registre ?

Un index vectoriel sait comparer des vecteurs, mais il ne sait pas intrinsèquement quel concept un vecteur représente. Le registre rend cette relation explicite et réversible.

Customer#42 <-> [0.12, -0.44, ...]
Document#7 <-> [0.81,  0.03, ...]

La valeur conceptuelle reste l'objet sémantique. Le vecteur reste une représentation numérique.

Invariants actuels

Dans un registre nommé, le moteur courant impose les invariants suivants :

1. une valeur conceptuelle enregistrée résout vers un seul vecteur enregistré ;
2. un vecteur enregistré résout vers une seule valeur conceptuelle ;
3. réenregistrer la même paire est idempotent ;
4. tenter de remapper l'un des côtés vers un partenaire contradictoire est rejeté ;
5. les noms de registre définissent des espaces d'embeddings isolés.

Ces invariants sont importants pour l'explicabilité : un résultat de voisinage peut être rattaché à la valeur conceptuelle exacte qui possède le vecteur.

Espaces nommés

Utilisez des noms de registre différents lorsque les embeddings ont des sémantiques différentes, par exemple :

product-description-v3
support-ticket-v2
concept-structural-embedding

Un nom de registre doit identifier un espace d'embedding, pas simplement une machine de déploiement. Deux registres peuvent contenir des embeddings des mêmes concepts s'ils correspondent à des modèles ou projections différents.

Pont de recherche

Le flux de recherche conceptuelle de base est :

vecteur de requête
 -> voisins HNSW scorés
 -> résolution vecteur-vers-valeur dans le registre
 -> candidats conceptuels

Les vecteurs présents dans HNSW mais absents du registre ne deviennent pas des candidats symboliques. Le moteur actuel les ignore.

Recherche contrainte par Kind

Lorsque l'appelant attend un kind conceptuel, le moteur peut combiner récupération numérique et vérification symbolique d'instance :

récupérer des vecteurs candidats
 -> résoudre les valeurs symboliques
 -> IsInstanceOf(kind attendu)
 -> conserver les valeurs compatibles

C'est un filtre dur, pas un simple indice vectoriel. Une valeur numériquement plus proche peut donc être rejetée au profit d'une valeur plus éloignée dont le kind symbolique est compatible.

Une option de stricte compatibilité contrôle le test d'instance. Considérez-la comme une partie de la définition sémantique de la requête, pas comme un simple réglage de performance.

Mise à jour des embeddings

Comme le remapping contradictoire est rejeté, le changement d'un vecteur doit être traité comme une opération explicite de mise à jour ou reconstruction de l'espace d'embedding. Un flux robuste est :

nouveau modèle/version
 -> créer ou migrer registre/index
 -> générer les vecteurs
 -> enregistrer les identités
 -> construire/tester l'index
 -> basculer les consommateurs
 -> retirer l'ancien espace

Cela évite qu'un index devienne temporairement incohérent avec ses identités conceptuelles.