Mon avis : Maîtriser l’état pour des agents IA complexes

D’accord, les amis, Alex Petrov ici, tout juste sorti d’une lutte avec un LLM en tant que cerveau pour un nouveau projet d’agent. Et cela, mes amis, nous conduit au sujet d’aujourd’hui. Nous ne parlons pas seulement d’agents ; nous nous plongeons profondément dans quelque chose que j’ai vu faire trébucher même des équipes expérimentées : l’art et la science de la gestion des états dans des agents IA complexes.

Ça semble banal, non ? La gestion des états. Comme la plomberie. Mais tout comme une maison avec une mauvaise plomberie finit par être inondée, un agent avec une mauvaise gestion des états devient un désordre chaotique, impossible à déboguer et sujet à des hallucinations ou, pire, à des boucles infinies. J’y ai été, fixant les journaux en essayant de comprendre pourquoi mon agent avait décidé de réévaluer un plan parfaitement bon pour la cinquième fois, pour réaliser qu’il avait oublié sa propre décision d’il y a deux étapes. Frustrant ne commence même pas à le couvrir.

L’actualité autour des grands modèles de langage (LLMs) se concentre souvent sur leurs incroyables capacités de raisonnement, leur capacité à générer un texte semblable à celui d’un humain, ou même leur planification émergente. Tout cela est vrai, tout est incroyable. Mais ce qui est souvent négligé dans l’excitation, c’est le fait que ces modèles sont fondamentalement sans état. Chaque interaction est, pour la plupart, un nouveau départ. Et lorsque vous construisez un agent IA – quelque chose conçu pour effectuer des tâches dans le temps, interagir avec un environnement et maintenir un sens du but – ce manque d’état représente un immense défi architectural.

Je me souviens d’un projet l’année dernière où nous construisions un agent pour automatiser certaines tâches d’analyse de données. Le prototype initial était simple : inviter le LLM, obtenir une réponse, exécuter. Rincer et répéter. Ça fonctionnait pour des cas triviaux. Mais dès que nous avons introduit un raisonnement en plusieurs étapes, des appels à des outils externes et des retours d’utilisateur, cela a commencé à s’effondrer. L’agent perdait le contexte, oubliait les sorties précédentes des outils ou redemandait des informations qu’il avait déjà. C’était comme parler à quelqu’un avec une perte de mémoire à court terme. C’est à ce moment-là que j’ai vraiment commencé à apprécier les nuances de l’état.

Pourquoi la gestion des états n’est pas simplement “mettre des choses dans un dictionnaire”

Si vous pensez, “Il suffit de tout mettre dans un dictionnaire Python et de le passer”, vous avez raison, mais vous n’êtes pas non plus prêt pour des agents qui font quelque chose au-delà d’un simple tour. Le problème avec une approche naïve est que “l’état” dans un agent IA n’est pas juste une collection de variables. C’est multi-couches, dynamique, et souvent doit être interprété, résumé, ou même oublié.

Pensez à un agent conçu pour vous aider à réserver des voyages. Son état pourrait inclure :

• Demande de l’utilisateur : “Je veux voler de Londres à New York le mois prochain.”
• Informations découvertes : “L’utilisateur préfère les vols directs, budget autour de 800 $.”
• Sorties des outils : “Vols disponibles de British Airways, vol BA175, départ le 22 mars, 750 $.”
• Pensées / Raisonnement interne de l’agent : “Je dois confirmer la date de départ avec l’utilisateur.”
• État environnemental : “La date actuelle est le 22 mars 2026.”

Toutes ces informations doivent être accessibles, mais pas nécessairement toutes en même temps, et pas toutes sous forme brute, pour le LLM à différentes étapes. Nourrir l’ensemble de l’historique de conversation brut et chaque sortie d’outil pour chaque invite atteint rapidement les limites de la fenêtre de contexte, sans parler de rendre le LLM inefficace et sujet à la distraction.

Les couches de l’état de l’agent

J’ai trouvé utile de penser à l’état de l’agent en plusieurs couches distinctes, mais interconnectées.

1. Contexte éphémère (Le Bloc-notes)

C’est la mémoire à court terme de votre agent, souvent spécifique à un cycle de décision unique ou à une très petite séquence d’étapes. Considérez-le comme le monologue interne du LLM ou un bloc-notes où il élabore une pensée avant de s’engager dans un plan. C’est ici que vous pourriez stocker la sortie immédiate d’un appel d’outil, une variable temporaire pour un calcul, ou l’étape actuelle dans une sous-tâche à plusieurs étapes.

Pourquoi c’est important : Cela garde l’invite immédiate concentrée. Vous ne voulez pas que le LLM relise l’ensemble de l’historique de la conversation chaque fois qu’il doit décider de la prochaine étape dans une boucle serrée. Ma règle empirique : si c’est seulement pertinent pour le tout prochain tour ou deux, cela appartient ici.

2. Historique de conversation (Le Transcription)

C’est l’échange brut ou légèrement traité entre l’utilisateur et l’agent, et parfois même le monologue interne de l’agent. C’est crucial pour maintenir le flux de la conversation et comprendre l’intention de l’utilisateur au fil du temps.

Défis : Cela croît rapidement. Envoyer l’historique brut complet au LLM à plusieurs reprises est une recette pour atteindre les limites de contexte et augmenter les coûts en tokens. Vous avez besoin de stratégies pour gérer sa taille.

3. Connaissance extraite / État résumé (Le Cahier de notes du cerveau)

C’est là que les choses deviennent intéressantes. Au lieu d’envoyer la conversation brute, vous pourriez résumer les points clés, extraire des entités ou tirer des faits confirmés. Par exemple, d’une longue conversation sur la réservation de vols, vous pourriez extraire “destination : New York, date de départ : 22 mars, budget : 800 $.” Ces informations résumées sont beaucoup plus concises et fournissent au LLM les faits essentiels sans le flou de conversation.

Mon approche : J’utilise souvent un appel LLM séparé spécifiquement pour le résumé ou l’extraction d’entités à des points stratégiques. Après quelques tours de conversation, j’enverrai l’historique récent à un LLM avec une invite comme, “Selon la conversation suivante, quelles sont les préférences confirmées de l’utilisateur pour sa réservation de vol ?” La sortie devient une partie de l’état persistant de l’agent.

def summarize_conversation_segment(conversation_history):
 prompt = f"""
 Veuillez résumer les faits clés confirmés et les préférences de l'utilisateur à partir du segment de conversation suivant.
 Concentrez-vous sur les informations exploitables pour un agent essayant de réserver un vol.

 Conversation :
 {conversation_history}

 Résumé (par exemple, "L'utilisateur veut voler de Londres à New York. La date de départ est flexible en mars. Budget autour de 800 $.") :
 """
 # Supposons que 'llm_client' est un client LLM initialisé (par exemple, OpenAI, Anthropic)
 response = llm_client.chat.completions.create(
 model="gpt-4o", # Ou quel que soit le modèle que vous utilisez
 messages=[{"role": "user", "content": prompt}]
 )
 return response.choices[0].message.content.strip()

# Exemple d'utilisation :
# new_summary = summarize_conversation_segment(current_conversation_buffer)
# agent_state['facts'].append(new_summary) # Stockez ceci dans les faits à long terme de votre agent

4. État environnemental (Le Modèle du Monde)

Ceci est l’information sur le monde externe avec lequel l’agent interagit. Cela peut être l’heure actuelle, les résultats d’une requête de base de données, l’état d’un appel API externe, ou même les conditions météorologiques actuelles. Cet état est souvent récupéré via des outils mais doit être stocké et référencé par l’agent.

Exemple : Si votre agent réserve une réunion, l’état environnemental inclurait les créneaux disponibles de l’API de calendrier. S’il gère une maison intelligente, ce sont la température actuelle, les réglages d’éclairage, etc.

5. Intention / Objectif de l’agent (L’Étoile Polaire)

Quel est l’objectif que l’agent essaie d’atteindre ? Cet objectif ou cette intention de haut niveau est critique. Il guide les décisions de l’agent et l’aide à rester sur la bonne voie. Cela provient souvent de l’invite initiale de l’utilisateur mais peut être précisé ou décomposé en sous-objectifs par l’agent lui-même.

Mon expérience : Déclarer explicitement l’objectif actuel au LLM dans chaque invite, même si c’est juste “Continuer la réservation du vol pour l’utilisateur”, améliore considérablement l’adhésion à cet objectif. Sans cela, les agents peuvent facilement s’égarer étonnamment.

Stratégies pratiques pour gérer l’état

D’accord, donc nous savons quel type d’état nous gérons. Comment gérons-nous réellement cela sans que notre agent ne devienne une vraie gouffre à mémoire ou un désordre confus ?

a. Gestion de la fenêtre de contexte (La Fenêtre Glissante & Résumé)

C’est probablement le défi le plus courant. Les LLM ont des fenêtres de contexte finies. Vous ne pouvez pas juste tout déverser. J’utilise une combinaison de stratégies :

• Fenêtre Glissante : Gardez seulement les N derniers tours de l’historique de conversation brut. Cela fonctionne pour des interactions courtes et ciblées.
• Résumé Dynamique : Comme mentionné ci-dessus, résumez périodiquement les anciennes parties de la conversation. Lorsque l’historique de conversation devient trop volumineux, je prendrai le plus ancien morceau, le résumerai et remplacerai le morceau brut par son résumé. Cela conserve les informations essentielles tout en éliminant les détails verbeux.
• Résumé Basé sur les Événements : Déclenchez le résumé après des événements clés, comme un point de décision majeur, une exécution d’outil, ou un changement significatif dans l’intention de l’utilisateur.

b. Représentation Structurée de l’État (Basée sur un Schéma)

Au lieu de simplement du texte libre, essayez d’extraire et de stocker l’état de manière structurée. Cela facilite la requête et la mise à jour de morceaux spécifiques d’information par l’agent.

Par exemple, au lieu d’un champ de “notes” en texte libre, ayez des champs spécifiques pour “destination”, “date_de_depart”, “budget”, “compagnie_aerienne_preferee”. Vous pouvez utiliser des modèles Pydantic ou de simples dictionnaires pour cela.

from pydantic import BaseModel, Field
from typing import Optional, List
from datetime import date

class FlightBookingState(BaseModel):
 user_id: str
 current_goal: str = "Réserver un vol"
 origin: Optional[str] = None
 destination: Optional[str] = None
 departure_date: Optional[date] = None
 return_date: Optional[date] = None
 num_passengers: int = 1
 budget_usd: Optional[float] = None
 preferred_airlines: List[str] = Field(default_factory=list)
 confirmed_flights: List[dict] = Field(default_factory=list)
 conversation_summary: List[str] = Field(default_factory=list) # Morceaux résumés
 raw_history_buffer: List[dict] = Field(default_factory=list) # Dernières N tournées de conversation brute

# Cet objet peut être sérialisé et transmis.
# Le LLM peut être amené à remplir des champs spécifiques ou à s'y référer.

Vous pouvez même demander à votre LLM de mettre à jour cet état structuré directement. Par exemple, « Étant donné le dernier message de l’utilisateur, mettez à jour l’objet JSON FlightBookingState avec toute nouvelle information ou information modifiée. »

c. Génération Augmentée par Récupération (RAG pour l’État)

Pour des états très grands ou complexes (par exemple, un agent gérant de nombreux projets en cours, chacun avec une documentation extensive), vous pouvez traiter des parties de votre état comme une base de connaissances. Intégrez des résumés, des plans précédents ou des sorties d’outils dans une base de données vectorielle. Ensuite, lorsque le LLM a besoin de contexte, interrogez la base de données vectorielle pour obtenir les informations les plus pertinentes en fonction de la demande actuelle ou de l’objectif.

Cela est particulièrement puissant pour les agents qui fonctionnent sur de longues durées ou à travers de nombreuses tâches différentes, où il est impossible de garder tout dans le contexte direct du LLM.

d. Gestion de Mémoire Explicite / Oubli

Parfois, oublier est une fonctionnalité, pas un bug. Si une information n’est plus pertinente (par exemple, l’utilisateur a explicitement changé d’avis, ou une sous-tâche est terminée), supprimez-la de l’état actif. Cela empêche le LLM d’être distrait par des informations obsolètes.

Cela peut impliquer des décisions d’agent : « Cette information est-elle toujours pertinente par rapport à l’objectif actuel ? » ou « Ce fait a-t-il été remplacé par une nouvelle préférence de l’utilisateur ? »

Une Mini-Anecdote sur l’Oubli

Je construisais un agent qui aidait les utilisateurs à configurer des logiciels complexes. Au départ, il se souvenait de chaque choix de configuration effectué par l’utilisateur, même s’ils disaient plus tard : « En fait, choisissons l’option B au lieu de A. » Le LLM, accablé par des informations contradictoires dans son contexte, revenait parfois à l’ancien choix ou s’embrouillait. Ce n’est qu’après avoir mis en place un mécanisme pour marquer explicitement les anciennes préférences comme « remplacées » ou « non pertinentes » que l’agent est devenu fiable. Il ne s’agissait pas d’ajouter plus de mémoire ; il s’agissait de la gérer intelligemment.

Retenues Actionnables pour Votre Prochain Projet d’Agent

1. Catégorisez Votre État : Ne vous contentez pas de tout rassembler dans une grande variable de « mémoire ». Pensez aux différentes couches d’état dont un agent a besoin : éphémère, conversationnel, résumé, environnemental et objectif.
2. Priorisez le Contexte : Comprenez quelles informations le LLM a *vraiment* besoin pour sa décision actuelle. Évitez d’envoyer des données non pertinentes ou redondantes.
3. Mettez en œuvre la Résumé Tôt : N’attendez pas d’atteindre les limites de contexte. Prévoyez la résumé ou l’extraction d’entités comme un composant essentiel du système de mémoire de votre agent. Utilisez des LLM pour cette tâche.
4. L’État Structuré est Votre Ami : Définissez des schémas (modèles Pydantic, structures JSON) pour l’état critique de votre agent. Cela rend la gestion, la mise à jour et l’interprétation plus faciles.
5. Considérez RAG pour la Mémoire à Long Terme : Si votre agent a besoin de conserver d’importantes quantités d’information sur de longues périodes, envisagez d’utiliser des bases de données vectorielles et des techniques RAG.
6. Ne Craignez Pas d’Oublier : Mettez en place des mécanismes pour réduire intelligemment ou marquer les informations non pertinentes dans l’état de votre agent.
7. Testez les Cas Limites de Mémoire : Testez délibérément des scénarios où l’agent doit se souvenir de détails spécifiques sur de nombreux tournées, ou où il doit gérer des informations contradictoires. C’est là que la gestion de l’état brille vraiment (ou échoue).

La gestion de l’état dans les agents IA n’est pas la partie flashy du travail. Ce n’est pas une question de concevoir une nouvelle architecture de réseau neuronal ou de trouver l’invite parfaite. Il s’agit d’une ingénierie minutieuse et délibérée qui soutient tout le reste. Mais je vous promets qu’investir du temps ici vous fera économiser d’innombrables heures de débogage et mènera à des agents bien plus capables, fiables, et un véritable plaisir à utiliser. Bonne construction !

Articles Connexes

• Maîtriser les Fondamentaux de NVIDIA : Évaluation du Cours de Deep Learning Expliquée
• Dévoiler le Biais dans les Réseaux Neuronaux Convolutionnels
• Ingénieur en Performance de Deep Learning : Maîtriser l’Optimisation de l’IA

🕒 Published: March 26, 2026