Architecture
Une couche d'infrastructure, pas une interface de chat
Venkai n'a pas de surface conversationnelle propre. C'est un pipeline qui transforme les données d'une entreprise en une structure que d'autres IA interrogent — la même forme qu'une base de données ou un fournisseur d'identité, pas un produit dans lequel une équipe se connecte.
Architecture
Sept étapes. Cinq tournent déjà aujourd'hui.
La forme réelle du système, pas une illustration de celui-ci. Opérationnel tourne aujourd'hui et est couvert par le benchmark ci-dessous. Spécifié est spécifié, pas encore construit.
- 01 · ENTRÉEOpérationnel
Sources
Arborescences de code, documents et dossiers structurés, lus là où ils vivent déjà. Rien n'est envoyé ailleurs, rien n'est dupliqué — le moteur tourne sur la machine qui possède les fichiers.
Système de fichiers local · arbre de travail Git
- 02 · ANALYSEOpérationnel
Extraction structurelle
Chaque fichier est parsé en arbre syntaxique concret, jamais scanné comme du texte brut. Symboles, portées, décorateurs et scope englobant sont résolus depuis la grammaire — une méthode garde sa classe, un décorateur reste attaché au symbole qu'il décore.
Parseur AST · résolveur de symboles
- 03 · RELIEROpérationnel
Graphe de symboles & dépendances
Les symboles sont reliés dans un graphe persistant de définitions, références et appels. C'est ce qui transforme une instruction nommant une fonction en un ensemble borné d'endroits qui peuvent légitimement changer.
Graphe de symboles · project_graph.json
- 04 · RAISONNEROpérationnel
Moteur d'opérations sémantiques
Un modèle décrit une intention ; le moteur la transforme en opération typée — remplacer, insérer après, supprimer une plage — et en déduit le plan à coût minimal qui la satisfait. Le modèle n'émet jamais le code lui-même.
Schéma d'opération sémantique · planificateur de patch minimal
- 05 · PROUVEROpérationnel
Vérification & annulation
Avant que quoi que ce soit ne touche le disque : refus sur une ancre ambiguë, refus si un décorateur serait perdu, re-parsing après application, et annulation de la transaction si le fichier ne compile plus. Un échec est un refus, jamais une écriture partielle.
Garde neuro-symbolique · application transactionnelle
- 06 · GÉNÉRALISERSpécifié
Représentation des connaissances
Étend le même graphe au-delà du code, pour que spécifications, schémas et prose participent à la même résolution. L'interface est spécifiée contre le graphe existant ; les extracteurs pour les sources non-code ne sont pas construits.
Spécifié — non implémenté
- 07 · SERVIRSpécifié
Interface agents & applications
Une API agnostique du modèle pour que tout agent puisse décrire un changement plutôt que l'écrire. Aujourd'hui le moteur est piloté en interne par notre propre outillage ; l'interface packagée, l'installeur et la liaison de compte sont en construction.
En développement
Architecture
En quoi cela diffère des approches voisines
vs. RAG classique
La génération augmentée par récupération encode des documents et renvoie, au moment de la requête, les passages les plus proches. Cela fait remonter du texte qui ressemble à la question ; il n'y a aucune représentation de quel passage est à jour, de ce qui l'a remplacé, ou de la relation entre deux passages. Le graphe d'entités de Venkai stocke ces relations explicitement, comme une structure — pas comme l'espoir que la distance d'embedding les encode par hasard.
vs. une base de données vectorielle seule
Une base de données vectorielle est une brique de stockage et de récupération — une recherche par plus proches voisins sur des embeddings. C'est une brique réellement utile, et c'est une couche en dessous de celle où opère Venkai : le graphe d'entités et le moteur de contexte persistant de Venkai reposent sur la brique de récupération déjà en place, en y ajoutant la structure relationnelle que la similarité seule ne peut pas représenter.
vs. simple mémoire de chat
La mémoire d'une application de chat est circonscrite aux conversations d'un utilisateur avec un produit. Le moteur de contexte persistant de Venkai est circonscrit à l'organisation : le même contexte structuré est disponible pour toute IA que l'entreprise utilise, avec les mêmes permissions que les systèmes source, et il ne se réinitialise pas quand une équipe change de produit ou de fournisseur de modèle.
Architecture
Les données, dites sans détour
Où vivent les données
Sur la machine qui les possède déjà. Le moteur tourne sur le système de fichiers local et l'arbre de travail Git — rien n'est envoyé ailleurs, rien n'est dupliqué vers l'infrastructure de Venkai. C'est vrai aujourd'hui pour le moteur SME ; c'est une contrainte de conception portée dans chaque étape future, pas quelque chose qui change avec la croissance du produit.
Stocké vs. temporaire
Aujourd'hui : le graphe de symboles/dépendances est un artefact local par exécution (project_graph.json) — il est reconstruit, pas persisté, entre les sessions. Le stockage persistant, inter-sessions, est l'étape « Représentation des connaissances » du pipeline ci-dessus, et elle est spécifiée, pas construite : l'interface est définie, les extracteurs ne sont pas implémentés.
Comment le contexte évolue / comment plusieurs modèles le partagent
Pas résolu aujourd'hui — c'est l'étape « Interface agents & applications » ci-dessus, elle aussi spécifiée et non construite. La forme visée est une API agnostique du modèle pour que tout agent décrive un changement plutôt que de l'écrire ; aujourd'hui le moteur est piloté en interne, uniquement par l'outillage propre de Venkai.