Aller au contenu
VENKAI
Demander un pilote technique

FAQ

Questions sur Venkai, en détail.

La version courte de ces réponses est sur la page d'accueil. Celle-ci va plus loin — RAG, bases vectorielles, mémoire des chatbots, et ce qui se passe quand la mémoire elle-même se trompe.

Qu'est-ce que Venkai ?

Venkai est une infrastructure de mémoire IA : une couche entre tout ce qu'une entreprise sait et chaque IA qui travaille pour elle. La plupart des entreprises font tourner plusieurs outils IA en parallèle — un assistant de code, un bot support, un copilote interne — et chacun repart de zéro, parce que le modèle lui-même n'a nulle part où garder ce qu'il a appris de l'entreprise la veille. Venkai donne une structure à cet endroit. Il construit les relations qui sous-tendent les connaissances d'une entreprise : quelle décision a produit quelle contrainte, ce qui dépend de quoi, ce qui a changé et ce que ça a cassé, et qui a le droit de voir quoi. Cette structure est servie à l'IA qui la demande, via une interface que ces systèmes interrogent directement — il n'y a ni fenêtre de discussion ni tableau de bord qu'une personne doit tenir à jour. Le moteur de mémoire pour le code, qui applique la même idée à la structure d'un dépôt, tourne aujourd'hui et ses benchmarks sont publics. La couche d'entreprise plus large — la même approche appliquée aux documents, décisions et à l'historique organisationnel — est en bêta privée.

Pourquoi les modèles d'IA oublient-ils les connaissances de l'entreprise ?

Les connaissances d'un modèle viennent de deux endroits : ce sur quoi il a été entraîné, figé à une date donnée et majoritairement public, et ce qu'on lui présente pendant une conversation donnée, qui disparaît dès que cette conversation se termine. Aucun des deux n'est un registre de votre entreprise. Les données d'entraînement précèdent par définition les décisions du dernier trimestre, et la fenêtre de contexte d'une conversation n'est pas un stockage — c'est un espace de travail temporaire dont la session suivante n'hérite pas. Un agent support réexplique donc chaque semaine la même exception de politique, un assistant de code propose un motif que l'équipe a rejeté six mois plus tôt, et un outil de recherche cite un chiffre corrigé dans un document qu'il n'a jamais vu. Ce n'est pas un problème de qualité du modèle : cela se produit à l'identique sur le modèle le plus performant disponible, car la défaillance est architecturale, pas une question d'intelligence. Les systèmes de récupération corrigent une partie du problème en allant chercher des documents au moment de la question, mais la récupération renvoie ce qui ressemble à la question, pas ce que l'entreprise a réellement décidé et pourquoi. Y remédier exige quelque chose qui persiste entre les sessions et représente des relations, pas seulement du texte — c'est précisément le manque que Venkai comble.

Venkai est-il juste du RAG ?

Non, même si les deux sont souvent mobilisés pour le même problème. La génération augmentée par récupération (RAG) encode des documents en vecteurs, puis, au moment de la question, récupère les passages dont le vecteur est le plus proche de la question et les transmet au modèle. Cela fonctionne bien quand la réponse se trouve dans un paragraphe quelque part et que la question est formulée assez près pour le trouver. Cela fonctionne mal quand la réponse dépend d'une relation entre plusieurs éléments — cette règle de tarification existe à cause de cette clause contractuelle, amendée après cet incident, ce qui explique l'exception que l'équipe support réexplique sans cesse. Rien de tout cela n'est récupérable par ressemblance, parce qu'aucun passage unique ne l'énonce ; il faut l'assembler à partir d'une structure. Venkai construit et maintient cette structure directement, sous forme de graphe d'entités et de relations tenu à jour à mesure que l'entreprise évolue, et la sert à l'IA qui en a besoin. En pratique, les deux ne s'excluent pas : la récupération reste souvent le bon outil pour retrouver un document précis, et Venkai est fréquemment la couche qui indique à cette étape de récupération, ou au modèle qui consomme son résultat, lequel de plusieurs documents similaires est réellement encore en vigueur.

Quelle est la différence entre Venkai et une base de données vectorielle ?

Une base de données vectorielle est une brique de stockage et de récupération : elle conserve des embeddings et, pour un embedding de requête donné, renvoie les plus proches par distance. C'est une brique réellement utile, et Venkai ne la concurrence ni ne la remplace. La différence tient au type de question que chacun peut résoudre. Une recherche par plus proches voisins répond à « quel texte ressemble à ce texte » — elle n'a aucune notion de causalité, de séquence, de propriété ou de remplacement, parce que la distance vectorielle est une mesure de similarité, pas une relation. La structure de Venkai est explicitement relationnelle : elle enregistre qu'une décision a produit une contrainte, qu'une décision ultérieure l'a annulée, qu'une politique s'applique à une équipe et pas à une autre, et elle tient ce graphe à jour à mesure que l'information arrive. Une question comme « cette règle est-elle toujours en vigueur, et pourquoi a-t-elle été introduite » n'est pas répondable par distance de plus proches voisins, aussi bon que soit le modèle d'embedding, parce que la réponse n'est pas un document similaire — c'est une chaîne de relations entre plusieurs documents, dont certains peuvent ne partager aucun mot en commun. La recherche vectorielle reste souvent un composant à l'intérieur d'un système que Venkai sert ; c'est une couche en dessous de celle qu'occupe Venkai, pas une alternative.

En quoi Venkai diffère-t-il de la mémoire intégrée à ChatGPT ou Claude ?

Les fonctions de mémoire intégrées aux produits de chat grand public retiennent des éléments sur les conversations d'une personne avec un produit — préférences, questions passées, résumé courant d'un fil. C'est utile pour ce produit, et c'est circonscrit à lui : cela ne suit pas l'utilisateur vers un autre outil IA, ce n'est pas partagé au sein d'une équipe, et cela n'a aucune notion de structure organisationnelle, de permissions, ni de savoir lequel de deux faits contradictoires est actuellement correct. Venkai s'attaque à un problème différent, à une échelle différente. Il est conçu pour porter ce qu'une entreprise entière sait — décisions, contraintes, propriété, historique — comme une structure que toute IA utilisée par l'entreprise peut interroger, qu'il s'agisse d'un assistant de code, d'un outil support, ou d'un copilote interne d'un tout autre fournisseur. L'accès suit les mêmes permissions que celles déjà appliquées par les systèmes source, donc ce qu'une personne ne peut pas voir, une IA agissant pour elle ne peut pas non plus s'en souvenir. Là où la mémoire d'un chatbot personnalise un assistant pour un utilisateur, Venkai donne aux IA d'une organisation, collectivement, une compréhension cohérente et à jour de l'entreprise — c'est pourquoi il fonctionne sous plusieurs produits IA à la fois plutôt que d'être la fonctionnalité d'un seul.

Venkai peut-il fonctionner avec les modèles d'IA que nous utilisons déjà ?

Oui, et il s'agit d'une contrainte de conception délibérée plutôt que d'une fonctionnalité accessoire. Venkai ne fournit ni modèle propre, ni interface de chat, ni assistant vers lequel une équipe devrait migrer — c'est une couche de contexte qui se place sous les IA déjà déployées par une entreprise, quel qu'en soit le fournisseur. Un assistant de code, un outil de support client et un copilote de recherche interne peuvent reposer sur des modèles sous-jacents entièrement différents et interroger tous les trois la même couche Venkai pour le contexte de la même entreprise, car l'interface entre eux est une requête de contexte structurée, pas une intégration spécifique à un modèle. Cela compte en pratique pour deux raisons. D'abord, la plupart des entreprises font déjà tourner plusieurs produits IA de plusieurs fournisseurs, et une couche de mémoire qui ne fonctionnerait qu'avec l'un d'eux ne résoudrait qu'une partie du problème. Ensuite, le choix de modèle change — une équipe monte de version, change de fournisseur, ou en ajoute un second pour une autre tâche — et reconstruire le contexte organisationnel à zéro à chaque fois est exactement le coût que Venkai existe pour supprimer. L'exigence pratique n'est donc pas « remplacez ce que vous avez » mais « connectez ce que vous avez » — les systèmes déjà en production continuent de tourner sans modification, tout en gagnant l'accès à un contexte d'entreprise persistant et structuré.

Où vivent nos données d'entreprise ?

Venkai est conçu autour de l'idée que les connaissances d'une entreprise ne devraient pas avoir à se déplacer pour être comprises. Le moteur tourne là où les fichiers et systèmes sous-jacents se trouvent déjà, plutôt que d'exiger une copie intégrale vers un nouvel entrepôt de données séparé avant de pouvoir construire la moindre structure — ce choix de conception est ce qui permet au moteur de mémoire pour le code de tourner aujourd'hui sur un dépôt réel sans étape de migration, et le même principe se retrouve dans la couche d'entreprise plus large à mesure qu'elle se déploie. Deux conséquences en découlent directement. D'abord, le contrôle d'accès existant voyage avec la donnée : les permissions sont héritées des systèmes dont la connaissance provient, donc ce qu'une personne ne peut pas voir dans le système source, une IA agissant en son nom ne peut ni le voir ni s'en souvenir via Venkai — rien n'obtient une portée supplémentaire en passant par la couche de mémoire. Ensuite, rien de tout cela ne sert à entraîner un modèle, ni celui de Venkai ni celui de quiconque ; les relations structurées que Venkai construit existent pour être servies comme contexte au moment de la requête, pas pour être absorbées dans des poids de modèle. Pour une entreprise qui évalue cela, la question pratique n'est pas « où envoyons-nous nos données » mais « à quels systèmes existants cela se connecte-t-il et dans lesquels cela lit-il » — et la réponse est conçue pour être : ceux que vous utilisez déjà.

Que se passe-t-il quand la mémoire elle-même devient fausse ?

Tout système qui mémorise peut mémoriser quelque chose qui n'est plus vrai — une politique change, une décision est annulée, un fait était faux dès le départ — et la question honnête n'est pas de savoir si cela arrive, mais ce qui se passe ensuite. La réponse de Venkai commence avant le déploiement : une nouvelle connexion tourne d'abord en mode observation, enregistrant ce qu'elle aurait fourni ou refusé pour des requêtes réelles sans agir sur aucune d'elles, de sorte que l'écart entre ce que la mémoire croit et ce qui est réellement à jour apparaît comme un rapport mesurable plutôt que comme une mauvaise réponse donnée à un client ou une contrainte erronée appliquée contre une politique. Cette mesure est aussi ce qui transforme un workflow validé en déploiement plus large — le mode existe précisément pour qu'une erreur apparaisse comme un chiffre que votre équipe examine, pas comme un incident. Structurellement, comme la représentation sous-jacente est relationnelle plutôt qu'un stockage plat de faits, une correction apportée à une décision se propage à ce qui en dépendait, au lieu de laisser un doublon obsolète à côté de la version corrigée — c'est le mode de défaillance le plus courant dans les systèmes qui stockent du texte plutôt que des relations. Rien de tout cela ne prétend que la mémoire est infaillible — cela signifie qu'une erreur est visible, attribuable à une décision précise, et corrigible, au lieu d'être un paragraphe silencieux qu'une IA répète avec une confiance totale.

Qui bénéficie réellement de Venkai ?

Quatre groupes en tirent un bénéfice direct et distinct, sans qu'il soit nécessaire d'inventer un cas d'usage qui n'existe pas. Les équipes qui font tourner des assistants IA d'entreprise arrêtent de réexpliquer la même exception de politique à chaque fois qu'elle survient, parce que l'assistant interroge une mémoire qui la possède déjà. Les équipes d'ingénierie logicielle obtiennent des agents de code qui comprennent l'architecture d'une base de code et son historique de décisions, pas seulement son texte actuel — pourquoi un motif a été rejeté, ce dont dépend un module — parce que ce contexte persiste entre les sessions au lieu de se réinitialiser à chaque fois. Les cabinets de conseil en IA arrêtent de perdre les connaissances propres à un client entre deux missions, parce que la mémoire organisationnelle qu'ils construisent pour un client est une structure qui survit à un projet donné ou à un consultant qui change d'affectation. Les équipes de recherche obtiennent une couche sémantique entre un tas fragmenté de documents et les modèles qui les interrogent, de sorte qu'un modèle répondant à partir de ce tas raisonne sur des relations plutôt que de deviner à partir du passage qui correspondait par hasard. Ce qui relie ces quatre groupes n'est pas le secteur — c'est la forme de l'échec : une IA qui doit redériver un contexte qu'une autre session, une autre personne, ou un autre outil avait déjà établi. Venkai est interrogé par celle des IA d'une entreprise qui a besoin de ce contexte, donc la même couche sous-jacente sert plusieurs de ces groupes à la fois, au sein d'une même organisation.