D’accord, les amis, Alex Petrov ici, tout juste revenu d’une lutte avec un LLM-as-a-brain particulièrement têtu pour un nouveau projet d’agent. Et cela, mes amis, nous amène au sujet d’aujourd’hui. Nous ne parlons pas seulement d’agents ; nous entrons 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 d’IA complexes.
Ça a l’air 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 horrible chaos, impossible à déboguer, et sujet à des hallucinations ou, pire encore, à des boucles infinies. J’y ai été, regardant des journaux pour essayer de comprendre pourquoi mon agent avait décidé de réévaluer un plan parfaitement bon pour la cinquième fois, pour finalement réaliser qu’il avait oublié sa propre décision d’il y a deux étapes. Frustrant ne couvre même pas cela.
Le buzz actuel 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 cela est incroyable. Mais ce qui est souvent négligé dans l’excitation, c’est que ces modèles sont fondamentalement sans état. Chaque interaction est, pour la plupart, un nouveau départ. Et lorsque vous construisez un agent d’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. Cela fonctionnait pour des cas triviaux. Mais dès que nous avons introduit un raisonnement multi-étapes, des appels à des outils externes, et des retours d’utilisateur, ça a commencé à tomber en morceaux. L’agent perdait le contexte, oubliait les sorties des outils précédents, ou redemandait des informations qu’il avait déjà. C’était comme parler à quelqu’un ayant des pertes 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 juste “mettre des choses dans un dictionnaire”
Si vous pensez, “Il suffit de tout mettre dans un dictionnaire Python et de le passer,” vous n’avez pas tort, mais vous n’êtes également pas prêt pour des agents qui font plus qu’un simple tour. Le problème avec une approche naïve, c’est que “l’état” dans un agent d’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é.
Considérez un agent conçu pour vous aider à réserver un voyage. 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 d’environ 800 $.”
- Sorties des outils : “Vols disponibles de British Airways, vol BA175, départ le 22 mars, 750 $.”
- Pensées/ Raisonnement internes 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’historique de conversation entier et chaque sortie d’outil pour chaque demande atteint rapidement les limites de la fenêtre contextuelle, sans mentionner que cela rend 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)
Ceci est la mémoire à court terme de votre agent, souvent spécifique à un seul cycle de décision ou à une très petite séquence d’étapes. Pensez-y comme au 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 à un outil, une variable temporaire pour un calcul, ou l’étape actuelle dans une sous-tâche à étapes multiples.
Pourquoi c’est important : Cela maintient la demande immédiate ciblée. Vous ne voulez pas que le LLM relise l’historique de la conversation entière chaque fois qu’il doit décider la prochaine étape dans une boucle serrée. Ma règle : si c’est seulement pertinent pour le tout prochain tour ou deux, cela appartient ici.
2. Historique de conversation (Le Transcription)
Ceci est l’allée et venue 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 grandit rapidement. Envoyer l’historique brut complet au LLM de manière répétée 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 Carnet du Cerveau)
C’est ici 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 discussion sur la réservation de vol, vous pourriez extraire “destination : New York, date de départ : 22 mars, budget : 800 $.” Cette information résumée est beaucoup plus concise et fournit au LLM les faits essentiels sans le superflu conversationnel.
Mon approche : J’utilise souvent un appel LLM séparé spécifiquement pour la résumation ou l’extraction d’entités à des moments stratégiques. Après quelques échanges de conversation, j’enverrai l’historique récent à un LLM avec une demande comme, “Sur la base de la conversation suivante, quelles sont les préférences confirmées de l’utilisateur pour leur 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 principaux faits confirmés et les préférences de l'utilisateur provenant 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 d'environ 800 $.") :
"""
# En supposant 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 cela dans les faits à long terme de votre agent
4. État environnemental (Le Modèle du Monde)
Ceci est des informations sur le monde externe avec lequel l’agent interagit. Cela pourrait être l’heure actuelle, les résultats d’une requête de base de données, le statut d’un appel à une 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 du calendrier API. S’il gère une maison intelligente, c’est la température actuelle, les réglages de lumière, etc.
5. Intentions / Objectif de l’agent (L’Étoile du Nord)
Que cherche à accomplir l’agent ? Cet objectif ou intention de haut niveau est crucial. Cela guide les décisions de l’agent et l’aide à rester sur la bonne voie. Cela provient souvent de la demande initiale de l’utilisateur mais peut être affiné ou décomposé en sous-objectifs par l’agent lui-même.
Mon expérience : Indiquer explicitement l’objectif actuel au LLM dans chaque demande, même si c’est juste “Continuer à réserver le vol pour l’utilisateur,” améliore considérablement l’adhérence à l’objectif. Sans cela, les agents peuvent s’égarer assez facilement.
Stratégies pratiques pour gérer l’état
D’accord, alors nous savons quel type d’état nous gérons. Comment le gérons-nous vraiment sans que notre agent ne devienne un gouffre de mémoire ou un fouillis confus ?
a. Gestion de la fenêtre contextuelle (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 : Conservez seulement les N derniers échanges de l’historique brut de la conversation. Cela fonctionne pour des interactions courtes et ciblées.
- Résumation Dynamique : Comme mentionné ci-dessus, résumez périodiquement les parties plus anciennes de la conversation. Lorsque l’historique de conversation devient trop volumineux, je prendrai le morceau le plus ancien, le résumerai, et remplacerai le morceau brut par son résumé. Cela garde l’information essentielle tout en éliminant les détails verbeux.
- Résumation Basée sur les Événements : Déclenchez une résumation 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 d’informations spécifiques par l’agent.
Par exemple, au lieu d’un champ de “notes” en texte libre, ayez des champs spécifiques pour “destination,” “date_de_départ,” “budget,” “compagnie_aérienne_préférée.” 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) # Chunks résumés
raw_history_buffer: List[dict] = Field(default_factory=list) # Derniers N échanges de chat brut
# Cet objet peut être sérialisé et transmis.
# Le LLM peut être invité à remplir des champs spécifiques ou à s'y référer.
Vous pouvez même inviter votre LLM à mettre à jour directement cet état structuré. 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 les morceaux d’information les plus pertinents en fonction de l’invite ou de l’objectif actuel.
Ceci est particulièrement puissant pour les agents qui opèrent sur de longues durées ou à travers de nombreuses tâches différentes, où garder tout dans le contexte direct du LLM est impossible.
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), retirez-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 pour l’objectif actuel ?” ou “Ce fait a-t-il été remplacé par une nouvelle préférence de l’utilisateur ?”
Une Petite Anecdote sur l’Oubli
Je construisais un agent qui aidait les utilisateurs à configurer des logiciels complexes. Au début, il se souvenait de chaque choix de configuration que l’utilisateur avait fait, même s’il disait plus tard, “En fait, choisissons l’option B au lieu de A.” Le LLM, accablé par des informations contradictoires dans son contexte, revenait parfois au vieux choix ou était confus. Ce n’est que lorsque j’ai 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. Ce n’était pas une question d’ajouter plus de mémoire ; c’était une question de la gérer intelligemment.
Conseils Pratiques pour Votre Prochain Projet d’Agent
- Catégorisez Votre État : Ne vous contentez pas de tout verser dans une grande variable “mémoire”. Pensez aux différentes couches d’état qu’un agent a besoin : éphémère, conversationnel, résumé, environnemental et objectif.
- Priorisez le Contexte : Comprenez quelle information le LLM *a vraiment* besoin pour sa décision actuelle. Évitez d’envoyer des données non pertinentes ou redondantes.
- Mettez en œuvre la Résumé de Bonne Heure : N’attendez pas d’atteindre les limites du contexte. Planifiez le résumé ou l’extraction d’entités comme une composante essentielle du système de mémoire de votre agent. Utilisez les LLMs pour cette tâche.
- L’État Structuré est Votre Ami : Définissez des schémas (modèles Pydantic, structures JSON) pour l’état critique de votre agent. Cela facilite la gestion, la mise à jour et l’interprétation.
- Considérez RAG pour la Mémoire à Long Terme : Si votre agent a besoin de conserver de vastes quantités d’informations sur de longues périodes, explorez l’utilisation de bases de données vectorielles et des techniques RAG.
- N’ayez Pas Peur d’Oublier : Construisez des mécanismes pour élaguer intelligemment ou marquer les informations non pertinentes dans l’état de votre agent.
- 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 échanges, 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 AI n’est pas la partie flashy du travail. Ce n’est pas une question de concevoir une nouvelle architecture de réseau de neurones ou de trouver l’invite parfaite. C’est une question d’ingénierie réfléchie et délibérée qui soutient tout le reste. Mais je vous promets que passer du temps ici vous fera gagner d’innombrables heures de débogage et vous conduira à des agents beaucoup plus capables, fiables et réellement agréables à utiliser. Bonne construction !
Articles Liés
- Maîtriser les Fondamentaux de NVIDIA : Évaluation du Cours de Deep Learning Expliquée
- Dévoiler le Biais dans les Réseaux de Neurones Convolutifs
- Ingénieur Performance en Deep Learning : Maîtriser l’Optimisation de l’IA
🕒 Published: