Architecture des embeddings d'hypergraphe
Statut documentaire : architecture — voir Maturité et preuves.
Le moteur actuel intègre les représentations vectorielles à la mémoire conceptuelle à travers un registre explicite et un index vectoriel. C'est plus précis que de considérer les embeddings comme de simples tableaux détachés dans une base vectorielle externe.
Quatre couches distinctes
1. identité conceptuelle
|
2. registre d'embeddings
|
3. index vectoriel / recherche HNSW
|
4. filtrage symbolique et reranking numérique
1. Identité conceptuelle
La valeur de l'hypergraphe reste l'identité de référence. Elle porte le type conceptuel, les relations, le contexte et la structure symbolique indépendamment de son embedding.
2. Registre d'embeddings
Un registre matérialise la relation entre une valeur conceptuelle et un vecteur d'embedding. Le moteur conserve des chemins de recherche dans les deux sens :
valeur conceptuelle -> vecteur
vecteur -> valeur conceptuelle
L'implémentation actuelle considère un remapping contradictoire comme une erreur : une valeur symbolique ne peut pas recevoir silencieusement un autre vecteur dans le même registre, et un même vecteur ne peut pas être affecté silencieusement à une autre valeur symbolique. Le remplacement d'un embedding est donc une opération explicite de cycle de vie, pas un écrasement implicite.
Les registres sont nommés. La réouverture du même registre nommé retrouve les associations stockées, tandis que deux noms de registre restent isolés. On peut ainsi maintenir plusieurs espaces d'embeddings sans confondre leurs identités.
3. Index vectoriel HNSW
Les vecteurs enregistrés peuvent être insérés dans un index HNSW. L'index est hiérarchique et approximatif : les couches supérieures localisent une région prometteuse, puis la couche de base développe les candidats. La recherche renvoie les vecteurs ordonnés par distance numérique avec leur score.
Le moteur actuel stocke l'état de l'index dans l'hypergraphe et prend en charge les indexes nommés, ce qui permet à leur identité de survivre à une réouverture et à plusieurs indexes de coexister.
4. Frontière de recherche conceptuelle
Un résultat HNSW n'est exploitable au niveau conceptuel que si son vecteur est enregistré. Le pont de recherche résout donc chaque vecteur vers sa valeur symbolique. Les vecteurs non enregistrés sont ignorés au lieu d'être transformés artificiellement en résultats conceptuels.
Une seconde forme de recherche peut imposer un Kind conceptuel attendu. Le moteur récupère volontairement un ensemble numérique plus large lorsque nécessaire, rejette les candidats qui ne sont pas instances du kind attendu, puis conserve les K premiers résultats compatibles.
La séparation devient explicite :
la proximité HNSW propose
la compatibilité symbolique accepte ou rejette
le reranking ordonne les candidats admis
Sémantique de distance
L'implémentation HNSW utilise une géométrie euclidienne et expose la distance euclidienne au carré dans les résultats scorés. Le code applicatif public doit considérer ce score comme un signal d'ordre tant qu'un modèle d'embedding particulier n'en définit pas une interprétation plus forte.
Ne comparez pas directement des distances brutes provenant d'espaces d'embeddings ou de versions de modèles différents sans politique de calibration explicite.
Cycle de vie et versionnement
Le moteur sait persister les structures de registre et d'index, mais la gouvernance applicative des embeddings reste nécessaire. Une conception de production doit au minimum identifier :
- le modèle/version d'embedding ;
- le nom de registre/index ;
- la dimension et la convention de normalisation ;
- la version ou snapshot conceptuel source ;
- la politique de rafraîchissement/reconstruction ;
- la politique de compatibilité lors d'un changement de modèle.
Le registre actuel empêche les mappings un-à-un contradictoires dans un même espace ; il ne définit pas à lui seul votre politique de migration entre versions de modèles.
Frontière publique
Cette page décrit des comportements vérifiés dans le code actuel. Les layouts internes, noms de classes privées, tables de hachage et détails de stockage ne font volontairement pas partie du contrat public.