Qu’est-ce que la "mémoire contextuelle" dans ReAct ?
Dans le cadre d’un agent ReAct, la mémoire contextuelle désigne l’ensemble des informations que l’agent garde en tête au fil de ses raisonnements et actions. Cela inclut :
• Les observations précédentes (résultats d’outils, réponses d’API, etc.)
• Les intentions passées (ce qu’il a essayé de faire)
• Les erreurs ou ajustements (ce qui n’a pas marché et pourquoi)
• Les données extraites ou calculées (valeurs, documents, filtres, etc.)
Pourquoi "plus riche" ?
Par "plus riche", il faut imaginer que l’agent pourrait :
• Mieux structurer ce qu’il a déjà vu ou fait.
• Mémoriser plus finement les paramètres utilisés, les formats attendus, les erreurs rencontrées.
• Anticiper les besoins futurs en se basant sur ce qu’il a appris dans les étapes précédentes.
Autrement dit, une mémoire contextuelle plus riche permettrait à l’agent de ne pas refaire les mêmes erreurs, ou de paramétrer correctement dès le premier appel.
Exemple concret
Voici un comportement qui devrait être évité : non seulement l’agent se trompe dans les paramètres (alors qu’il a déjà utilisé correctement l’outil dans une étape précédente), mais au moment de récupérer l’erreur, il s’aperçoit (comment ?) qu’il avait déjà la réponse :
Je vais maintenant récupérer les détails complets de ces interventions pour fournir une réponse claire et détaillée.
Action: interventionsGetInterventionsByEntityIdFiltered
Action Input: {'entityId': '23:4202'}
Observation: Error: 3 validation errors for EntityIdTimestampsFilteredInput
sinceTstamp
Field required [type=missing, input_value={'entityId': '23:4202'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing
untilTstamp
Field required [type=missing, input_value={'entityId': '23:4202'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing
filters
Field required [type=missing, input_value={'entityId': '23:4202'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing
> Running step 7f431607-2599-43f4-b1f5-1fc819f498e4. Step input: None
Thought: Je vois que j'ai déjà les informations nécessaires dans les résultats précédents. Je vais synthétiser les informations des interventions terminées en 2024 pour fournir une réponse claire et complète.Si sa mémoire contextuelle était plus riche, il aurait pu éviter l’erreur dès le premier appel :
– Se rappeler qu’il avait déjà le résultat.
– Se souvenir du format attendu par le filtre.
Mémoire contextuelle vs. planification
Ce qu’on appelle "mémoire contextuelle" est souvent lié à la capacité de planification :
– Un agent qui planifie bien anticipe les formats, les conversions, les dépendances.
– Un agent avec une mémoire riche peut réutiliser intelligemment ce qu’il a déjà vu.
Ce qui importe, ce n’est pas seulement une question de "richesse" de la mémoire, mais aussi une prise en compte plus systématique. Il faut donc considérer l’adéquation des instructions générales, de la description des outils et de leur classes d’E/S, la bonne rédaction des routines.
En amont de ReAct, il y a l’orchestrateur, qui élabore un plan à partir du prompt, des instructions générales et des routines. Le plan est transmis à ReAct sous la forme d’une liste ordonnée d’étapes.
Le plus souvent, quand on constate un errance de ReAct, on constate également que le plan était très pertinent et qu’il n’a pas été appliqué, ou l’est en seconde intention.
Oui mais non, peut être ?
Ce comportement erratique se produit dans un contexte de system-prompt, de description des outils avec leurs classes Pydantic d’E/S détaillées, de routines très précises et, finalement, d’un plan élaboré par l’orchestrateur. Il faut dès lors se poser la question : pourquoi ce la ne fonctionne pas bien du premier coup ? Peut-on éviter cela ?
Faudrait-il :
• Des outils mieux documentés ?
• Un prompt plus précis, plus autoritaire ?
• Une mémoire contextuelle plus riche ?
Ou faut-il considérer ce comportement comme bénéfique et l’accepter ?
Pourquoi ReAct peut se tromper au premier appel ?
Le raisonnement est incrémental
ReAct fonctionne par boucles de réflexion et d’action. Il ne planifie pas tout d’un coup (mais c’est le rôle de l’orchestrateur), mais avance étape par étape :
• Il réfléchit à ce qu’il doit faire.
• Il agit (appelle un outil).
• Il observe le résultat.
• Il ajuste son raisonnement.
Cela signifie que le premier appel peut être basé sur une hypothèse partielle ou incorrecte, que l’agent corrige ensuite.
C’est là qu’on aimerait un peu plus de rigueur en ne négligeant pas la mémoire contextuelle.
Exploration et affinement
Les agents ReAct sont conçus pour explorer avant de converger :
• L’agent peut faire un premier appel avec des valeurs par défaut ou une interprétation approximative.
• Puis, en analysant l’observation, il comprend qu’il faut affiner les paramètres (par exemple, convertir une durée en millisecondes, ou filtrer selon un champ spécifique).
• C’est une forme de résilience algorithmique : mieux vaut se tromper et corriger que rester bloqué.
Autrement dit : j’essaye au pif et je lis la doc après ?
Comportement réaliste et humain
Ce genre de correction peut être toléré dans ReAct :
• Cela rend l’agent plus flexible, plus adaptable, et même plus humain dans son raisonnement.
• Un humain aussi peut se tromper dans un premier calcul, puis se corriger — ReAct imite cette dynamique.
Mais en pratique, cette capacité à se "récupérer" est une force, pas une faiblesse. Elle permet à l’agent de fonctionner dans des environnements ambigus, incomplets ou dynamiques.
Tentative de conclusion
Il faut vérifier et renforcer tout ce qui peut favoriser un premier essai sans erreur, et particulièrement la planification. Mais sinon, la capacité de ReAct à explorer et trouver une solution est une grande force. Encore faut-il ne pas faire deux fois les mêmes erreurs, c’est là que la mémoire contextuelle "plus riche" doit jouer.
à suivre : comment enrichir la mémoire contextuelle.
RSS 2.0