Mémoire IA
Pourquoi l'IA d'entreprise oublie encore votre activité
Les connaissances d'un modèle sont figées à l'entraînement, et son contexte est figé à une conversation. Ni l'un ni l'autre n'est un registre de votre entreprise — et la récupération ne corrige que la part du problème qu'elle peut atteindre.
Pourquoi les modèles d'IA oublient les entreprises
Un modèle de langage a exactement deux sources de connaissance : ce sur quoi il a été entraîné, et ce qu'on place dans sa fenêtre de contexte pour la requête en cours. Les données d'entraînement sont figées à une date donnée et proviennent très majoritairement de sources publiques — elles ne peuvent pas contenir la décision tarifaire du trimestre dernier, l'incident qui a changé une politique d'escalade, ou la raison d'une exception précise, parce que rien de tout cela n'a jamais été public et ne le sera jamais. Le contexte pose le problème inverse : il peut contenir exactement ce qu'une personne ou un système place devant le modèle pour un échange, et rien d'autre une fois cet échange terminé.
Aucun des deux n'est un endroit où les connaissances d'une entreprise s'accumulent. La même question, posée dans deux sessions distinctes à six mois d'écart, reçoit donc la même réponse depuis la même base statique les deux fois — non pas parce que le modèle s'est dégradé, mais parce que rien de ces six mois écoulés ne lui a jamais été fourni. Un agent support réexplique une exception de politique à chaque fois qu'elle survient, parce que cette exception vit dans une décision que personne ne resoumet au modèle. Un assistant de code propose un motif que l'équipe a déjà rejeté, parce que ce rejet vit dans un commentaire de pull request que le modèle n'a jamais lu.
Cela mérite d'être dit précisément parce que c'est facile à confondre avec un problème de qualité du modèle, et ce n'en est pas un. Cela se produit à l'identique sur le modèle le plus performant disponible, le jour même de sa sortie, parce que la défaillance est architecturale : aucun composant d'une requête sans état n'a pour rôle de se souvenir de l'entreprise entre deux appels.
Pourquoi le RAG récupère mais ne mémorise pas
La génération augmentée par récupération est le correctif standard, et elle aide réellement dans un cas précis : la réponse à une question existe, presque intacte, dans un document, et la question est formulée assez près du langage de ce document pour qu'une recherche par embedding la trouve. Dans ce cas, le RAG récupère le passage et le modèle le lit comme s'il avait toujours été là.
Le cas où cela n'aide pas est plus fréquent qu'il n'y paraît : la réponse ne se trouve dans aucun document unique, parce qu'elle est le produit d'une relation entre plusieurs d'entre eux. Une règle de tarification existe à cause d'une clause contractuelle, amendée après un incident, ce qui explique pourquoi l'exception que l'équipe support réexplique sans cesse est légitime et non une erreur. Aucun passage unique n'énonce cette chaîne — une recherche par similarité de documents n'a aucun moyen de la faire remonter, parce que la similarité n'est pas la relation qui compte ici. Causalité, séquence et remplacement sont des propriétés structurelles de l'information, pas textuelles, et un système conçu pour trouver du texte qui ressemble à du texte ne les représente pas.
C'est aussi pourquoi les systèmes de récupération sont sujets à une défaillance précise et silencieuse : renvoyer un document topiquement correct mais qui n'est plus vrai. Deux versions d'une politique peuvent être également proches d'une requête dans l'espace des embeddings ; une seule est actuellement en vigueur, et la ressemblance ne peut pas dire laquelle.
Ce que signifie un contexte persistant
Un contexte persistant n'est ni une fenêtre plus grande ni un historique de chat conservé plus longtemps — les deux restent circonscrits à un fil ou à un utilisateur. Cela signifie une représentation de l'entreprise qui existe indépendamment de toute conversation, interrogée à neuf par l'IA qui en a besoin, et mise à jour à mesure que l'entreprise change plutôt que redérivée de zéro à chaque fois.
Concrètement, cette représentation doit capturer des relations, pas seulement des faits : ce qu'une décision a produit, ce qui en dépend, ce qui l'a remplacée, et qui a le droit de la voir. Un stockage plat de faits — même très grand, très bien indexé — ne peut pas répondre à « cette règle est-elle toujours en vigueur, et pourquoi a-t-elle été introduite » parce que cette réponse est une chaîne à travers plusieurs faits, pas un seul. Une structure qui modélise les relations explicitement peut y répondre, parce que la chaîne est précisément ce qui a été stocké.
Comment Venkai aborde la mémoire
Venkai construit et maintient directement cette structure relationnelle, comme une couche entre tout ce qu'une entreprise sait et chaque IA qui travaille pour elle. Il est neutre vis-à-vis des fournisseurs de modèles par conception — un assistant de code, un outil support et un copilote interne peuvent reposer sur des modèles sous-jacents entièrement différents et interroger tous la même structure de contexte pour la même entreprise, car l'interface est une requête de contexte, pas une intégration spécifique à un modèle.
Il tourne sur les systèmes et fichiers qu'une entreprise possède déjà plutôt que d'exiger une copie séparée de tout, hérite des permissions d'accès déjà appliquées par ces systèmes source, et ne sert jamais à entraîner un modèle — la structure existe pour être servie comme contexte au moment de la requête. Les nouvelles connexions démarrent en mode observation : elles enregistrent ce que le système aurait fourni ou refusé, sans agir, pour qu'un écart entre la mémoire et la réalité apparaisse comme un rapport avant d'atteindre une vraie réponse.
Ce qui change quand la mémoire devient une infrastructure
Traitée comme une fonctionnalité, la mémoire est le confort d'un seul produit — une appli de chat qui se souvient de vos dernières questions. Traitée comme une infrastructure, c'est une couche sur laquelle toute IA d'une entreprise peut compter, de la même façon qu'elle compte sur une base de données ou un fournisseur d'identité : quelque chose qui existe une fois, reste à jour, et est interrogé par qui en a besoin plutôt que reconstruit dans chaque nouvel outil.
L'effet pratique est qu'adopter un second outil IA, ou changer de fournisseur de modèle, cesse d'exiger que l'organisation réapprenne son contexte à zéro. Le contexte n'a jamais été à l'intérieur d'un outil pour commencer — c'était une infrastructure que l'outil interrogeait, et le prochain outil interroge la même infrastructure.
FAQ
Est-ce le même problème qu'une fenêtre de contexte trop courte ?
Non. Même une très grande fenêtre de contexte se réinitialise entre les sessions, sauf si quelque chose en dehors du modèle la repeuple. La limite n'est pas la taille, c'est la persistance.
Le fine-tuning résout-il ce problème ?
Le fine-tuning fige un instantané de faits dans les poids du modèle à un moment donné. Cela ne se met pas à jour quand l'entreprise change, et cela ne peut pas représenter qu'un fait est en train d'être révisé — cela devient simplement faux plus tard, comme les données d'entraînement d'origine.