Agentis Memory : Stockage Compatible Redis avec Recherche Vectorielle et Embeddings Locaux

Agentis Memory propose une idée simple mais importante pour le marché des agents IA : une mémoire partagée qui se comporte comme Redis ordinaire. Au lieu d'une base de données vectorielle séparée, d'une API d'embedding externe et de SDK personnalisés, le projet combine le stockage clé-valeur, la recherche sémantique et le calcul local d'embeddings dans un seul processus. Pour les équipes construisant des systèmes multi-agents, c'est une tentative de résoudre l'un des problèmes les plus douloureux : l'échange de contexte entre agents sans couches réseau supplémentaires et latence.

Le problème a émergé dans un scénario réel d'enquête sur un incident de production. Quand plusieurs agents spécialisés travaillent en parallèle étudiant les logs, les métriques, les conversations et l'historique des incidents, chacun ne voit que son propre fragment du tableau global. Un agent peut trouver OOMKilled dans les logs et effectivement retracer la cause racine, mais les autres continuent de construire leurs propres hypothèses : pics de CPU, un déploiement récent, ou toute autre corrélation.

Le synthétiseur finit par collecter plusieurs hypothèses conflictentes, dont beaucoup ne sont que du bruit. Essayer de stocker ces découvertes dans un fichier markdown partagé n'aide pas : les conflits d'écriture commencent, il n'y a pas de TTL, pas de structure et pas de recherche sémantique. Pour un système d'agents, c'est déjà insuffisant.

L'examen des solutions existantes a révélé le même problème sous un autre angle. Mem0 et Zep se positionnent déjà comme des couches de mémoire pour les agents IA, mais ils s'accompagnent d'APIs REST, de SDK séparés, de stockage vectoriel et de services externes pour les embeddings. Redis Stack est plus proche du modèle nécessaire car il maintient la compatibilité avec les clients Redis, mais laisse le calcul vectoriel en dehors du serveur.

Pour la RAG à long terme c'est tolérable, mais pour la mémoire de travail où un agent sauvegarde un fait et un autre doit le trouver en millisecondes, un tel schéma est trop lourd. Chaque hop réseau supplémentaire affecte à la fois la latence et la fiabilité. La première hypothèse d'ingénierie était évidente : prendre Redis lui-même, le forker et embarquer ONNX Runtime et un index vectoriel à l'intérieur.

En pratique, ce chemin s'est rapidement heurté à un travail complexe avec C, les bibliothèques natives, la gestion de la mémoire et l'instabilité sous les requêtes concurrentes. Après un prototype échoué, le projet a été réécrit de zéro en Java 25 en utilisant GraalVM native-image. Cela a donné un seul binaire natif d'environ 150 MB avec un modèle d'embeddings déjà embarqué.

À l'intérieur, il utilise l'API Vector Java pour l'accélération SIMD de la similarité cosinus, Project Loom pour les threads virtuels, ONNX Runtime pour l'inférence locale du modèle all-MiniLM-L6-v2 et la bibliothèque jvector pour la recherche HNSW des voisins les plus proches. De l'extérieur, Agentis Memory se comporte comme un serveur Redis familier. Il supporte plus de 90 commandes standard, TTL, SCAN et pub/sub basique, et peut être accessible via des clients réguliers comme redis-py, Jedis, ioredis ou go-redis.

La différence clé est quatre commandes de mémoire supplémentaires. MEMSAVE prend du texte, le découpe en chunks par phrases, calcule des vecteurs 384-dimensionnels et les indexe de façon asynchrone, généralement en 5-10 millisecondes par chunk. MEMQUERY prend une requête en langage naturel et retourne les enregistrements les plus proches par similarité cosinus.

MEMSTATUS montre si l'index est prêt pour une clé spécifique, et MEMDEL supprime les données simultanément de la couche clé-valeur et de l'index vectoriel. Pour un développeur, cela ressemble à une extension minimale d'un modèle Redis déjà familier, pas une plateforme séparée avec un nouvel écosystème. L'histoire de performance a également été instructive.

La première version Java s'exécutait environ deux fois plus lentement que Redis. Après le passage à GraalVM native-image et la réécriture du chemin critique en utilisant l'API Vector, la situation s'est inversée : les opérations sur strings ont augmenté d'environ 60 mille à 168 mille ops/sec, mettant le projet à environ 1,36x du niveau Redis. En charge mixte le résultat était environ 1,40x.

À profondeur de pipeline 100, le système a atteint 3,19 millions d'opérations par seconde, ou environ 1,71x Redis, grâce à son architecture multi-threadée sans boucle d'événements single-threaded. Mais le compromis persiste : en latence p99 Redis est toujours en avance sur les strings — 3,82 millisecondes contre 6,27 pour Agentis Memory, et c'est le prix payé pour la collecte des ordures. Un accent particulier est mis sur la confidentialité et le coût.

Les embeddings sont calculés localement via ONNX Runtime directement à l'intérieur du processus, sans clés d'API, sans appels à des services externes et sans envoyer les logs, les métriques ou le trafic de service au cloud. Pour les systèmes travaillant avec les incidents et l'infrastructure interne, ce n'est pas une amélioration cosmétique mais une décision architecturale importante. L'inférence locale prend environ 2-5 millisecondes par chunk, ne coûte aucune facture d'embedding séparée et supprime la dépendance au temps de disponibilité d'un tiers.

Plus les données sont sensibles et plus la fréquence d'accès est élevée, plus les avantages de cette approche sont notables. À un niveau plus large, Agentis Memory illustre bien comment l'infrastructure autour des agents IA change. Le marché n'a plus de place pour simplement brancher un LLM, des outils et un orchestrateur.

Le prochain point de concurrence est la mémoire partagée, la vitesse de synchronisation du contexte et la capacité du système à écarter rapidement les fausses hypothèses. Si un modèle compatible Redis avec embeddings locaux gagne du terrain dans les charges réelles, de telles solutions pourraient devenir pour les systèmes d'agents ce que Redis ordinaire est devenu il y a longtemps pour les développeurs backend conventionnels : une couche rapide de coordination, de cache et de mémoire de travail partagée.