Ingénierie de la mémoire et du contexte : défis des IA agentiques

Introduction

Avec l'évolution des agents d'intelligence artificielle (IA) vers des tâches plus longues et des utilisations multi-sessions, un schéma problématique se dessine. Les agents abandonnent parfois des contraintes en cours de tâche, des informations précédemment utilisées réapparaissent de manière inappropriée, et le contexte d'une étape peut influencer indûment la suivante. Identifier la source de ces échecs s'avère complexe, car aucun composant isolé ne semble être en cause.

Le cœur du problème réside souvent dans deux domaines clés : l'ingénierie du contexte et l'ingénierie de la mémoire. Bien que ces deux disciplines soient interconnectées, elles sont distinctes et échouent de manières différentes. Pour les mettre en œuvre correctement, des systèmes spécifiques sont nécessaires.

Cet article explore les décisions critiques derrière chaque discipline et leur point d'interaction :

• Les implications de l'ingénierie du contexte et les décisions qui influencent le raisonnement d'un agent lors d'un appel unique.
• Les aspects de l'ingénierie de la mémoire, y compris la politique d'écriture, le stockage, la récupération et la maintenance, qui affectent la fiabilité à long terme.
• La frontière commune entre ces deux disciplines lors de la récupération d'informations, et les modes d'échec fréquents lorsque cette frontière est mal gérée.

Comprendre ces deux domaines, séparément et ensemble, est essentiel pour garantir qu'un agent fonctionne efficacement dans des environnements de travail réels.

Un aperçu de l'ingénierie du contexte et de la mémoire

L'ingénierie du contexte concerne la conception d'un appel d'inférence unique : déterminer ce qui doit être inclus, compressé, où placer les éléments et ce qui doit être omis. Les informations en jeu sont temporaires ; elles disparaissent une fois l'appel terminé.

À l'inverse, l'ingénierie de la mémoire se concentre sur ce qui persiste au-delà d'une interaction unique avec un modèle. Elle englobe les systèmes et politiques responsables de l'écriture, du stockage, de la récupération, de la mise à jour et de la gouvernance des informations pour que les interactions futures puissent en bénéficier. Lorsqu'un agent se souvient d'informations d'une session antérieure, collabore avec un autre agent ou applique une préférence utilisateur apprise précédemment, il s'appuie sur l'ingénierie de la mémoire plutôt que sur celle du contexte.

Bien que l'ingénierie du contexte détermine quelles informations sont disponibles pour le modèle lors d'une demande spécifique, l'ingénierie de la mémoire détermine quelles informations persistent entre les demandes et comment elles sont maintenues, récupérées et jugées fiables au fil du temps. Voici un aperçu :

| Aspect | Ingénierie du Contexte | Ingénierie de la Mémoire | |-----------------------------|--------------------------------------|---------------------------------------| | Portée | Un appel d'inférence | À travers les appels, sessions, agents| | Où vivent les données | Dans la fenêtre active du modèle | Stockages externes : DB vectoriel, K/V, relationnel | | Problème principal | Que faut-il inclure et comment l'organiser | Que faut-il persister, récupérer et faire confiance | | Échoue lorsque | La fenêtre est pleine, le placement est incorrect, le bruit l'emporte sur le signal | Échecs de récupération, obsolescence, empoisonnement, pas de politique d'écriture | | Surface d'ingénierie | Structure de prompt, compression, budgétisation des tokens | Schéma de stockage, stratégie de récupération, politiques d'écriture et de mise à jour | | Durée de vie des données | Durée d'un appel LLM | Dépend du type de mémoire |

Ingénierie du Contexte : Assemblage de la Fenêtre de Contexte Optimale

Pour un agent exécutant un flux de travail en plusieurs étapes, chaque appel d'inférence assemble une fenêtre de contexte à partir de plusieurs sources : prompt système, description de la tâche, historique de conversation, sorties d'outils, documents récupérés, résumés de sous-agents. L'ingénierie du contexte est l'ensemble des décisions qui déterminent ce que chaque composant contribue, sous quelle forme et à quelle position.

Inclusion Sélective

Tout ce qui est disponible ne doit pas entrer dans le contexte. Par exemple, une requête de base de données renvoyant des centaines de lignes, une recherche web retournant cinq articles complets, ou un exécuteur de code enregistrant des sorties verbeuses peuvent surcharger la fenêtre et réduire la qualité du raisonnement avant d'atteindre la limite de tokens. La décision sur ce qui doit être inclus tel quel, ce qui doit être compressé en faits clés et ce qui doit être écarté est un choix de conception, pas un défaut par défaut.

Placement Structurel

L'emplacement des informations dans la fenêtre affecte la manière dont le modèle les utilise de manière fiable. Les modèles prêtent plus d'attention au contenu au début et à la fin de longs contextes, le matériel au milieu recevant significativement moins de poids. Cela est connu sous le nom d'effet « perdu au milieu ».

Les contraintes strictes et les instructions critiques pour la tâche doivent se trouver en haut de la fenêtre. Les informations récupérées les plus pertinentes pour la tâche actuelle doivent être placées près de la fin de la fenêtre de contexte.

La requête ou la tâche actuelle de l'utilisateur doit généralement suivre les informations récupérées, positionnant à la fois le contexte pertinent et l'objectif immédiat aussi près que possible du point de génération. Cet agencement augmente la probabilité que le modèle utilise efficacement les informations récupérées lors de la production de sa réponse.

Aperçu de l'Ingénierie du Contexte

Compression à l'Arrivée

Les sorties d'outils doivent être compressées après le retour d'un appel, et non après que la fenêtre soit pleine. Une réponse API brute contenant 3 000 tokens, dont l'agent n'a besoin que de 150, doit être résumée avant d'entrer dans le contexte pour l'étape suivante. Attendre que la fenêtre soit pleine et ensuite se précipiter pour tronquer est une gestion réactive d'un problème que la compression à la source prévient.

Gestion de l'Historique de Conversation

L'historique de conversation croît plus rapidement que tout autre composant de contexte. Pour les agents à long terme, transporter l'historique complet dans chaque appel rend chaque inférence subséquente plus coûteuse et moins fiable. Une stratégie de compression – fenêtre glissante, résumés hiérarchiques ou extraction d'état structuré – doit être appliquée à des intervalles définis, et non lorsque la fenêtre déborde.

Ingénierie de la Mémoire : Conception de Systèmes de Mémoire Persistante pour l'IA

Une fois qu'un appel d'inférence est terminé, l'ingénierie de la mémoire détermine ce qui mérite de persister et dans quelles conditions il sera réutilisé. Cela couvre quatre préoccupations distinctes : quoi écrire, où le stocker, comment le récupérer et comment le maintenir précis au fil du temps.

Conception de la Politique d'Écriture

La conception de la politique d'écriture est l'un des aspects les plus négligés de l'ingénierie de la mémoire, mais elle a un impact disproportionné sur la qualité de la mémoire au fil du temps. Bien que les systèmes de récupération reçoivent souvent le plus d'attention, la qualité de récupération est finalement contrainte par ce qui entre dans le stockage de mémoire en premier lieu.

Une politique d'écriture bien définie spécifie :

• Quels événements déclenchent une écriture en mémoire
• Quelles informations sont éligibles pour le stockage
• Le format dans lequel les informations sont stockées, comme du texte brut, des enregistrements structurés, des faits extraits ou des résumés
• Les exigences de confiance ou de validation pour accepter de nouvelles entrées
• Quels agents, outils ou composants système sont autorisés à écrire dans des espaces de mémoire spécifiques
• Comment les mises à jour, corrections et informations conflictuelles sont gérées
• Les règles de conservation, politiques d'expiration et exigences de durée de vie (TTL) pour différents types de mémoire

Sans politiques d'écriture explicites, les systèmes ont souvent tendance à stocker trop d'informations, à attribuer une confiance égale à toutes les entrées et à conserver des données indéfiniment. Au fil du temps, des souvenirs de faible valeur et obsolètes s'accumulent, les rapports signal/bruit diminuent et la qualité de récupération se dégrade. Le résultat est un système de mémoire qui croît continuellement tout en devenant progressivement moins utile.

Sélection du Niveau de Stockage

Différents types de mémoire servent différents objectifs et nécessitent différents backends de stockage. Le choix du backend contraint également les stratégies de récupération disponibles.

• Type de Mémoire : Ce qu'il Stocke
  • Mémoire de Travail : État de tâche actif, résultats intermédiaires
  • Mémoire Épisodique : Interactions passées, exécutions de tâches, décisions
  • Mémoire Sémantique : Faits persistants, préférences utilisateur, connaissances de domaine
  • Mémoire Procédurale : Flux de travail appris, modèles d'action réussis

Le livre de recettes de personnalisation de contexte d'OpenAI fait une distinction utile entre la mémoire basée sur la récupération et la mémoire basée sur l'état pour les cas d'utilisation nécessitant une continuité. La mémoire basée sur la récupération traite les interactions passées comme des documents faiblement liés et est fragile face aux variations de formulation et aux mises à jour conflictuelles. L'extraction d'état structurée – écriture de faits typés et validés plutôt que d'incorporer des morceaux de conversation bruts – produit des résultats plus cohérents pour les faits qui doivent être appliqués de manière fiable à travers les sessions.

Aperçu de l'Ingénierie de la Mémoire

Stratégie de Récupération

Lire à partir de la mémoire n'est pas une opération unique. Une couche de récupération bien conçue vérifie d'abord la mémoire de travail (rapide, peu coûteuse, recherche par clé exacte), se rabat sur la recherche sémantique dans la mémoire épisodique ou sémantique lorsque rien de pertinent n'émerge, applique des filtres de métadonnées pour la récence et le niveau de confiance avant de retourner les résultats, et injecte uniquement ce dont l'étape actuelle a besoin.

Maintenance de la Mémoire

Un stockage sans politique de maintenance se dégrade au fil du temps. Les entrées s'accumulent, des faits obsolètes rivalisent avec les faits actuels, et la qualité de récupération chute à mesure que le rapport signal/bruit diminue. Les routines de maintenance suivantes sont importantes en pratique : dégradation de la confiance sur les faits volatils, dé-duplication des entrées sémantiquement similaires, expiration basée sur TTL de la mémoire de travail et des données sensibles au temps, et compression périodique des anciens enregistrements épisodiques en résumés au niveau de session.

Un schéma MemoryEntry qui encode directement ces préoccupations rend la logique d'écriture et de maintenance plus efficace.