D’accord, les amis, Alex Petrov ici, de retour sur agntai.net. Nous sommes en mars 2026, et si vous êtes comme moi, vos chaînes Slack et vos fils Twitter bourdonnent de discussions sur les agents d’IA. Pas seulement des abstractions du type « et si », mais les très réelles et très chaotiques modalités de faire en sorte que ces choses accomplissent réellement quelque chose d’utile sans se transformer en un presse-papiers coûteux et halluciné.
Aujourd’hui, je veux parler de quelque chose qui me tracasse, et honnêtement, quelques-uns de mes clients en conseil aussi : le tueur silencieux de la performance des agents d’IA – la gestion de la fenêtre contextuelle. Nous sommes tous tellement concentrés sur le choix du meilleur LLM, la création du prompt parfait ou la conception de systèmes multi-agents élaborés, que nous négligeons souvent le travail de base nécessaire pour garder nos agents concentrés et efficaces. Ce n’est pas glamour, mais croyez-moi, c’est là où une grande partie de votre performance (et de votre budget) vit ou meurt.
J’ai récemment eu un client, appelons-le « Acme Corp », qui voulait un agent pour analyser les transcriptions du support client, identifier les problèmes récurrents et rédiger des rapports sommaires. Cela semblait assez simple. Ils ont commencé avec un LLM assez puissant, lui ont donné accès à un tas de données historiques et s’attendaient à de la magie. Ce qu’ils ont obtenu, c’est beaucoup de « Et ce n’est pas seulement à propos de la limite brute de tokens de votre LLM choisi. C’est une question de la façon dont vous *structurez* les informations que vous lui fournissez, comment vous *les récupérez*, et surtout, comment vous *les résumez et filtrez* pour garder l’agent opérant dans son point d’optimisation cognitive.
Le Coût Caché de Trop d’Informations
Nous y avons tous été. Vous construisez un agent, vous voulez qu’il soit intelligent, alors vous lui balancez tout sauf l’évier. « Voici tout le manuel du produit, les 500 questions fréquentes du support client, et chaque conversation précédente pour le contexte ! »
Ma première tentative avec un agent interne pour l’idéation de messages de blog a été un désastre à cause de cela. Je lui ai donné l’intégralité de mes archives de blog, pensant qu’il « apprendrait mon style. » Ce qu’il a appris, c’est à divaguer, à se perdre et à suggérer fréquemment des sujets que j’avais déjà couverts trois fois. C’était comme essayer d’avoir une conversation cohérente avec quelqu’un qui lit simultanément chaque livre d’une bibliothèque. Le trop plein d’informations n’est pas seulement un problème humain ; c’est un problème d’agent d’IA aussi.
Il y a deux problèmes principaux ici :
- Limites de Tokens : C’est l’évident. Chaque LLM a une fenêtre contextuelle maximum. Si vous la dépassez, vous obtenez soit une erreur, soit le modèle tronque silencieusement votre entrée, perdant des informations précieuses.
- Charge Cognitive (pour le LLM) : Même dans la limite de tokens, un contexte plus large rend plus difficile pour le LLM de se concentrer sur les éléments véritablement pertinents. C’est comme demander à un humain de trouver une aiguille dans une meule de foin ; plus la meule est grande, plus cela prend de temps, et plus le risque de la manquer est élevé. Cela impacte directement la qualité des réponses et souvent, la capacité de l’agent à suivre des instructions complexes.
Et n’oublions pas le coût. Ces tokens ne sont pas gratuits ! Nourrir votre agent avec de grandes quantités de texte de manière répétée peut rapidement rendre votre agent économiquement non viable.
Stratégies pour une Gestion du Contexte plus Intelligente
Alors, comment corrigeons-nous cela ? Il ne s’agit pas de priver votre agent d’informations ; il s’agit de fournir les *bonnes* informations, au *bon* moment, dans le *bon* format. Voici quelques stratégies pratiques que j’ai utilisées, souvent en combinaison, pour garder mes agents légers et concentrés.
1. Révélation Progressive des Informations
Au lieu de tout déverser d’un coup, pensez à votre agent comme à un détective. Donnez-lui les détails immédiats de l’affaire, laissez-le demander plus d’informations si nécessaire, ou fournissez des détails supplémentaires au fur et à mesure que la tâche évolue. C’est un principe fondamental dans de nombreux cadres d’agents, mais il est souvent mal mis en œuvre.
Exemple : Agent de Support Client
Au lieu de lui donner l’ensemble de l’historique client et le manuel du produit au début de chaque interaction, vous pourriez commencer par :
- La demande actuelle du client.
- Un bref résumé de leur dernière interaction (si disponible et pertinent).
- Un accès aux outils pour consulter les informations sur le produit ou les anciens tickets *uniquement au besoin*.
Si le client demande « Comment réinitialiser mon mot de passe ? », l’agent n’a pas besoin de connaître la politique de garantie ou la dernière mise à jour logicielle. Il a besoin de la procédure de réinitialisation de mot de passe, qu’il peut récupérer via un outil ou une requête RAG très ciblée.
2. Résumé et Condensation Intelligents
C’est probablement la technique la plus percutante que j’ai vue pour les tâches d’agent de longue durée. Au lieu de passer des conversations ou des documents entiers entre les étapes ou les tours, résumez-les. Il ne s’agit pas seulement de couper des mots ; il s’agit d’extraire les *points essentiels* qui sont critiques pour les étapes futures.
Retourons à l’agent d’analyse de transcription d’Acme Corp. Au départ, ils essayaient de transmettre l’intégralité des transcriptions dans un seul appel LLM pour analyse. Cela a rapidement touché les limites de tokens. Ma suggestion était de décomposer :
- Étape 1 : Lecture et Extraction Initiale de la Transcription : Pour chaque transcription, avoir un agent plus petit et spécialisé (ou même un prompt au LLM principal) identifier les entités clés (noms de produits, sentiment client, types de problèmes) et résumer le problème central et la résolution. Cette sortie est beaucoup plus petite que la transcription originale.
- Étape 2 : Agréger et Synthétiser : Transmettre ces résumés extraits (pas les transcriptions originales !) à un agent de niveau supérieur pour la reconnaissance de modèles et la génération de rapports.
Voici un extrait Python simplifié montrant comment vous pourriez résumer une transcription pour une utilisation ultérieure :
from openai import OpenAI
client = OpenAI()
def summarize_transcript(transcript_text: str) -> str:
"""Résume une transcription de support client pour extraire les problèmes clés et la résolution."""
prompt = f"""
Vous êtes un expert en résumé d'interactions de support client.
Lisez la transcription suivante et fournissez un résumé concis (moins de 200 mots) qui
identifie le problème principal du client, les étapes entreprises pour le résoudre, et le résultat final.
Concentrez-vous sur les insights exploitables pour l'amélioration du produit ou les points de douleur communs des clients.
Transcription :
---
{transcript_text}
---
Résumé :
"""
response = client.chat.completions.create(
model="gpt-4o", # Ou quel que soit le modèle que vous préférez pour le résumé
messages=[
{"role": "system", "content": "Vous êtes un assistant utile."},
{"role": "user", "content": prompt}
],
temperature=0.3,
max_tokens=250 # Contrôlez la longueur du résumé
)
return response.choices[0].message.content.strip()
# Exemple d'utilisation :
# with open("sample_transcript_001.txt", "r") as f:
# sample_transcript = f.read()
# condensed_info = summarize_transcript(sample_transcript)
# print(f"Longueur originale : {len(sample_transcript)} caractères")
# print(f"Longueur condensée : {len(condensed_info)} caractères")
# print(condensed_info)
Cette simple étape de résumé peut réduire le contexte de plusieurs ordres de grandeur, rendant l’analyse subséquente beaucoup plus efficace et efficace.
3. Résumé Récursif pour des Conversations de Longue Durée
Pour les agents engagés dans des conversations multi-tours (comme un assistant personnel ou un chatbot sophistiqué), la fenêtre contextuelle devient rapidement un problème. Chaque nouveau message ajoute à l’historique. La solution ? Le résumé récursif.
Après un certain nombre de tours (mettons, 5-10 messages), prenez l’historique de la conversation actuelle et demandez au LLM les points clés discutés jusqu’à présent, en préservant des détails cruciaux comme les décisions prises, les questions ouvertes ou les exigences spécifiques de l’utilisateur. Ensuite, vous pouvez écarter l’historique ancien et verbeux et le remplacer par ce résumé concis, rafraîchissant efficacement la fenêtre contextuelle.
Pensez-y comme prendre des notes lors d’une longue réunion. Vous ne transcrivez pas chaque mot ; vous notez les points clés et les actions à entreprendre.
Voici un flux conceptuel pour le résumé récursif :
conversation_history = [] # Stocke des tuples (rôle, contenu)
summary = ""
def add_to_history(role, content):
global conversation_history
conversation_history.append({"role": role, "content": content})
# Vérifie si l'historique devient trop long
if len(str(conversation_history)) > MAX_HISTORY_LENGTH_THRESHOLD:
global summary
# Ajoute le résumé existant à l'historique avant de résumer
full_context_to_summarize = [{"role": "system", "content": f"Résumé de la conversation précédente : {summary}"}] if summary else []
full_context_to_summarize.extend(conversation_history)
# Utilise le LLM le contexte combiné
summarization_prompt = [
{"role": "system", "content": "Vous êtes un résumé concis. Résumez les points clés de la conversation jusqu'à présent, en vous concentrant sur les décisions, les exigences et les questions ouvertes. Gardez-le sous 200 mots."},
*full_context_to_summarize
]
# Cette partie impliquerait un appel réel au LLM
new_summary_response = client.chat.completions.create(
model="gpt-4o",
messages=summarization_prompt,
temperature=0.2,
max_tokens=200
)
summary = new_summary_response.choices[0].message.content.strip()
conversation_history = [] # Réinitialiser l'historique, en s'appuyant sur le nouveau résumé
print("Historique résumé et réinitialisé !")
# Exemple d'interaction :
# add_to_history("user", "J'ai besoin de planifier un voyage à Rome le mois prochain pour 3 personnes.")
# add_to_history("assistant", "D'accord, je peux vous aider avec ça. Quelles sont vos dates préférées ?")
# # ... plusieurs tours ...
# add_to_history("user", "Nous avons décidé du 15 au 22 mars. Nous voulons un hôtel près du Colisée.")
# # À ce stade, add_to_history pourrait déclencher la résumation si MAX_HISTORY_LENGTH_THRESHOLD est atteint
# # Le nouveau 'résumé' contiendrait "Voyage à Rome, du 15 au 22 mars, 3 personnes, hôtel près du Colisée."
# # L’historique de la conversation serait vide, ou contiendrait juste les tours les plus récents.
L’astuce ici est de s’assurer que le prompt de résumation identifie et retient correctement les informations *critiques* nécessaires pour les tours futurs, et pas seulement un aperçu général.
4. Récupération Ciblée Augmentée par Génération (RAG)
RAG est une technique fondamentale, mais son application à la gestion de la fenêtre de contexte est souvent sous-estimée. Au lieu d’incorporer des documents entiers, vous devriez intégrer des *morceaux* de documents, et plus important encore, vous devez être judicieux sur *ce que* vous récupérez.
Ma plus grande courbe d’apprentissage avec RAG a été de réaliser que simplement lancer une requête utilisateur dans une base de données vectorielle et récupérer les top-N morceaux n’est souvent pas suffisant. Vous devez prétraiter la requête ou même utiliser un LLM pour générer d’abord une meilleure requête de recherche. Par exemple, si un utilisateur demande, « Comment puis-je réparer le code d’erreur 101 sur mon imprimante ACME-2000 ? », une simple recherche sémantique sur « réparer l’erreur 101 » pourrait ramener des dépannages génériques. Mais si vous demandez d’abord à un LLM d’extraire « appareil : imprimante ACME-2000 » et « code d’erreur : 101 », vous pouvez construire une requête RAG beaucoup plus précise.
De plus, réfléchissez à *ce que* vous coupez et intégrez. Pour l’analyse de transcript de Acme Corp, au lieu d’incorporer des transcriptions complètes, nous avons intégré les *résumés* générés à l’Étape 1. Cela signifie que le système RAG récupère des informations beaucoup plus concises et de niveau supérieur, réduisant drastiquement le contexte transmis à l’agent d’analyse finale.
5. Extraction d’Informations Pilotée par Schéma
Lorsque vous avez besoin de morceaux spécifiques d’informations à partir d’un texte plus large, ne comptez pas sur le LLM pour « juste le comprendre ». Donnez-lui un schéma. Cela est particulièrement utile pour extraire des données structurées à partir de texte non structuré, qui peuvent ensuite être transmises de manière beaucoup plus efficace que le texte brut.
Par exemple, si vous traitez des candidatures, au lieu de transmettre l’ensemble du CV, vous pouvez inciter le LLM à extraire « Nom », « Email », « Années d’expérience », « Compétences clés », « Dernier poste », etc., dans un objet JSON. Ces données structurées sont compactes, sans ambiguïté, et faciles à consommer pour les étapes d’agents suivantes ou les systèmes externes.
Cela ne concerne pas seulement l’économie de tokens ; cela concerne aussi la réduction de l’ambiguïté et l’amélioration de la fiabilité du transfert d’informations entre les modules ou outils d’agents.
Points à Retenir pour Votre Prochain Projet d’Agent
D’accord, donc cela a été beaucoup. Mais le message principal est le suivant : Traitez la fenêtre de contexte de votre LLM comme un bien précieux. Chaque token coûte de l’argent et une charge cognitive.
- Concevez pour un Flux d’Information Délibéré : Ne vous contentez pas de déverser des données. Réfléchissez à ce qui est véritablement nécessaire à chaque étape du processus de votre agent.
- Adoptez la Résumation (de Manière Aggressive) : Pour toute tâche de longue durée ou conversation multi-tours, faites de la résumation un pilier dans l’architecture de votre agent. Expérimentez avec différents prompts de résumation pour trouver ce qui fonctionne le mieux pour votre cas d’utilisation.
- Coupez Intelligent, Récupérez Plus Intelligent : Avec RAG, concentrez-vous à la fois sur la qualité de vos morceaux (sont-ils des unités significatives et autonomes ?) et sur la précision de vos requêtes de récupération. Envisagez d’utiliser un LLM pour affiner les requêtes avant de frapper votre base de données vectorielle.
- Utilisez des Schémas pour une Extraction Structurée : Lorsque vous savez quel type d’information vous avez besoin, dites-le explicitement au LLM avec des schémas JSON ou des instructions de formatage claires. Cela réduit le bruit et améliore le traitement en aval.
- Surveillez l’Utilisation des Tokens : Sérieusement, intégrez le comptage des tokens dans la journalisation de votre agent. C’est le seul moyen de réellement comprendre où votre fenêtre de contexte est consommée et où des optimisations sont nécessaires. Des outils comme LangChain ou LlamaIndex offrent souvent des accroches pour cela.
Je sais qu’il est tentant de penser que des fenêtres de contexte plus grandes provenant de modèles plus récents résoudront tous ces problèmes. Et oui, ils aident. Mais même avec des fenêtres de contexte massives, les principes de gestion efficace des informations restent cruciaux. Une fenêtre de contexte de 1M tokens ne signifie pas que vous *devez* la remplir de bruit irrélevant. Cela signifie juste que vous avez plus de capacité pour des informations *pertinentes et de haute qualité*.
Alors, la prochaine fois que vous déboguez un agent qui est confus, hallucine, ou simplement lent, regardez de près sa fenêtre de contexte. Cela pourrait être le tueur silencieux que vous négligez.
À la prochaine fois, continuez à construire ces agents plus intelligents ! Alex Petrov, vous salue.
Articles Connexes
- Actualités sur la Régulation de l’IA : Approches US vs EU et Pourquoi Cela Compte
- Composants de l’Architecture de l’Agent IA Expliqués
- Évaluation des Agents : Comment Mesurer la Performance Réelle
🕒 Published: