Si vous avez suivi la première partie de cette série, vous disposez d'une équipe d'agents fonctionnelle avec des fichiers de mémoire persistante. Cet article explique pourquoi cette architecture de mémoire fonctionne – et pourquoi l’approche par défaut de la plupart des frameworks ne fonctionne pas.
La plupart des frameworks d'agents traitent la mémoire comme un problème de stockage. Le conseil est familier : intégrez tout dans une base de données vectorielles, récupérez ce qui semble pertinent via une recherche de similarité, insérez-le dans la fenêtre contextuelle. RAG-tout.
Cela échoue en pratique pour une raison précise : l'agent ne contrôle pas ce dont il se souvient.
La récupération de vecteurs fait apparaître ce qui est sémantiquement similaire, et non ce qui est important à l'heure actuelle. Un agent commercial a besoin des prix actuels, des remises actives et de l’historique de ce client – et non de tous les documents mentionnant le mot « prix ». Lorsque la récupération s'appuie sur le mauvais contexte, ou lorsqu'un agent ne dispose pas de limites claires quant à ce qu'il peut ou ne peut pas dire, les échecs sont réels.
Fin 2023, le chatbot d'un concessionnaire Chevrolet a été socialement conçu pour accepter de vendre un nouveau Tahoe pour 1 $. Le mécanisme d’échec était une injection rapide – un utilisateur a demandé au robot d’ignorer ses contraintes et de confirmer l’accord – mais le problème sous-jacent était architectural. Le chatbot n’avait pas de mémoire structurée séparant les « choses sur lesquelles je peux accepter » des « choses que je devrais connaître ». Tout résidait dans une seule couche de récupération plate, et l'agent ne pouvait pas distinguer la tarification faisant autorité du contexte conversationnel.
Ce n'est pas un problème d'intelligence de modèle. C'est un problème d'architecture de l'information....
[Courte citation de 8% de l'article original]