Implémentation d'une mémoire persistante pour agents avec NVIDIA NeMo et AWS S3 Vectors
Un guide technique détaille comment construire une mémoire à long terme évolutive et cohérente pour les agents IA en utilisant le NVIDIA NeMo Agent Toolkit et Amazon S3 Vectors sur EKS.
Traduit automatiquement depuis l'original anglais.
Les ingénieurs qui développent des systèmes multi-agents disposent désormais d'une voie concrète pour implémenter une mémoire partagée et persistante grâce au NVIDIA NeMo Agent Toolkit (NAT) adossé à Amazon S3 Vectors. Publié en octobre 2026, ce guide technique démontre comment déployer ces composants sur Amazon Elastic Kubernetes Service (EKS) afin de résoudre les défis de cohérence et de mise à l'échelle dans les environnements de production.
Ce qui s'est passé
L'article fournit une stratégie d'implémentation étape par étape pour créer un fournisseur de mémoire personnalisé au sein de NAT. Bien que NAT prenne en charge des backends existants tels que Redis et Zep, le guide soutient qu'Amazon S3 Vectors est mieux adapté aux systèmes multi-agents de production nécessitant une évolutivité élastique et une forte cohérence en écriture. Les auteurs détaillent la création de l'infrastructure nécessaire, l'écriture d'un plugin personnalisé et la configuration du flux de travail de l'agent.
Le cœur de l'implémentation repose sur la définition d'une interface MemoryEditor, qui sert de contrat de plugin pour les backends personnalisés. Les développeurs doivent implémenter trois méthodes spécifiques : add_items(), search() et remove_items(). Ce plugin permet aux agents de stocker l'historique des conversations, les préférences utilisateur et les connaissances à long terme sous forme d'objets MemoryItem, qui incluent des champs de métadonnées pour filtrer et limiter les requêtes.
Le déploiement s'appuie sur Amazon EKS pour assurer un contrôle opérationnel sur le cycle de vie de l'agent. L'architecture utilise le HorizontalPodAutoscaler pour faire évoluer le nombre de répliques d'agents en fonction de l'utilisation du CPU. Chaque réplique se connecte au même index S3 Vectors via les IAM Roles for Service Accounts (IRSA). Cette configuration garantit que tout pod traitant une requête peut accéder aux mémoires les plus récentes sans nécessiter de stratégies d'invalidation de cache.
Comment cela fonctionne
Le système opère en enveloppant les agents standards avec un composant auto_memory_agent. Cet encapsulateur gère automatiquement la capture et la récupération du contexte, éliminant ainsi le besoin pour le grand modèle de langage d'invoquer explicitement les outils de mémoire à chaque tour. Lorsqu'un agent génère une réponse, le système intègre le contenu à l'aide d'un modèle comme Amazon Titan Text Embeddings V2 et le stocke dans l'index S3 Vectors.
S3 Vectors agit comme le backend durable, supportant jusqu'à deux milliards de vecteurs par index. Il offre une récupération sémantique utilisant des métriques de distance configurables telles que la similarité cosinus ou euclidienne. Crucialement, il propose une forte cohérence en écriture, ce qui signifie que lorsqu'un pod d'agent écrit une mémoire, tous les autres pods la voient immédiatement. Cela élimine les conditions de course courantes dans les bases de données à cohérence éventuelle lorsque plusieurs agents coordonnent une tâche unique.
Le filtrage par métadonnées permet aux agents de cibler efficacement leurs recherches. Chaque vecteur peut porter des métadonnées de type chaîne, nombre, booléen ou liste, permettant des requêtes visant des utilisateurs, des sessions ou des sujets spécifiques. Cette structure prend en charge différents types de mémoire, y compris épisodique, sémantique et procédurale, permettant au système de récupérer uniquement le contexte le plus pertinent pour une interaction donnée.
Détails clés
- Interface Plugin : Les backends de mémoire personnalisés doivent implémenter l'interface abstraite
MemoryEditoravec les méthodesadd_items,searchetremove_items. - Modèle de cohérence : Amazon S3 Vectors fournit une forte cohérence en écriture, assurant une visibilité immédiate des nouvelles mémoires sur tous les pods d'agents sans gestion de cache.
- Mécanisme de mise à l'échelle : Les répliques d'agents sur Amazon EKS évoluent via le
HorizontalPodAutoscalerbasé sur l'utilisation du CPU, toutes les instances partageant un seul index S3 Vectors. - Métriques d'évaluation : Le harnais d'évaluation NAT (
nat eval) mesure les améliorations en matière de véracité factuelle (groundedness), d'utilisation de tokens, de latence et de réduction du travail dupliqué. - Limites d'infrastructure : S3 Vectors supporte jusqu'à deux milliards de vecteurs par index, sans planification de capacité requise et avec une tarification à l'usage pour le stockage et les requêtes.
- Contrôle d'accès : La sécurité est gérée via des politiques AWS IAM par bucket et par index, permettant une isolation stricte entre les locataires ou les équipes.
Pourquoi c'est important
Pour les équipes logicielles construisant des flux de travail complexes basés sur des agents, la gestion de la mémoire constitue souvent un goulot d'étranglement. Sans une couche de mémoire partagée et cohérente, les agents répètent le travail, perdent le contexte entre les sessions et peinent à se coordonner. En déchargeant la mémoire vers S3 Vectors, les développeurs obtiennent un système qui évolue de manière élastique sans gérer des ressources de calcul inactives. Cela réduit la charge opérationnelle tout en améliorant la fiabilité des collaborations multi-agents.
La capacité à quantifier l'impact de la mémoire est également significative. Le guide souligne que l'activation de la mémoire améliore généralement la véracité factuelle en fournissant un contexte source vérifiable et réduit l'utilisation de tokens en évitant la re-dérivation de faits connus. Bien que la latence augmente légèrement en raison des requêtes vectorielles, cet compromis aboutit souvent à des sorties de meilleure qualité et à des coûts globaux inférieurs pour les tâches répétitives. Cette approche basée sur les données aide les ingénieurs à ajuster des paramètres tels que top_k et les seuils de similarité pour équilibrer coût et performance.
Ce que vous pouvez faire
- Installez NVIDIA NeMo Agent Toolkit version 1.6 ou ultérieure et assurez-vous que votre environnement exécute Python 3.11 ou 3.12.
- Créez un bucket et un index Amazon S3 Vectors avec un schéma de métadonnées correspondant aux exigences de mémoire de votre agent, en utilisant 1024 dimensions pour les embeddings Titan.
- Implémentez l'interface
MemoryEditoren Python pour connecter NAT à votre index S3 Vectors, en gérant la génération d'embeddings et l'étiquetage des métadonnées. - Configurez l'encapsulateur
auto_memory_agentdans votre configuration YAML NAT pour activer la capture et la récupération automatiques de la mémoire pour vos agents. - Exécutez des évaluations comparatives en utilisant
nat evalavec et sans mémoire activée pour mesurer les changements en termes d'exactitude, de véracité factuelle et de consommation de tokens. - Nettoyez les ressources en supprimant le namespace EKS, l'index S3 Vectors et les rôles IAM une fois les tests terminés afin d'éviter des frais continus.

