Bien, 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 sont en effervescence avec des discussions sur les agents AI. Pas seulement des « et si » abstraits, mais les « comment faire » très réels et très complexes pour faire en sorte que ces choses fassent réellement quelque chose d’utile sans devenir un presse-papiers halluciné et coûteux.
Aujourd’hui, je veux parler de quelque chose qui me tracasse, et honnêtement, quelques-uns de mes clients en consultant aussi : le tueur silencieux de la performance des agents AI – la gestion de la fenêtre de contexte. Nous sommes tous tellement concentrés sur le choix du LLM « meilleur », la création de la prompt parfaite, ou la conception de systèmes multi-agents élaborés, que nous négligeons souvent le travail de fond pour garder nos agents concentrés et efficaces. Ce n’est pas glamour, mais croyez-moi, c’est là où une part significative de votre performance (et de votre budget) vit ou meurt.
Récemment, j’ai eu un client, appelons-le « Acme Corp », qui voulait qu’un agent analyse des transcriptions de support client, identifie des problèmes récurrents et rédige des rapports de synthèse. Cela semblait assez simple. Ils ont commencé avec un LLM plutôt puissant, lui ont donné accès à une tonne de données historiques, et s’attendaient à de la magie. Ce qu’ils ont obtenu, c’est beaucoup de « Et ce n’est pas juste une question de limite de tokens de votre LLM choisi. C’est une question de la manière dont vous *structurez* les informations que vous lui fournissez, de la façon dont vous *les récupérez*, et surtout, comment vous *les résumez et les filtrez* pour que l’agent reste opérationnel dans son point doux cognitif.
Le Coût Caché de Trop d’Information
Nous y avons tous été. Vous construisez un agent, vous voulez qu’il soit intelligent, alors vous lui balancez tout sauf l’évier de cuisine. « Voici l’intégralité du manuel produit, toutes les 500 FAQs du support client, et chaque conversation précédente pour le contexte ! »
Ma première tentative d’un agent interne pour l’idéation d’articles 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à traités trois fois. C’était comme essayer d’avoir une conversation cohérente avec quelqu’un qui lit simultanément tous les livres d’une bibliothèque. La surcharge d’information n’est pas seulement un problème humain ; c’est aussi un problème d’agent AI.
Il y a deux problèmes principaux ici :
- Limites de Tokens : C’est l’évidence. Chaque LLM a une fenêtre de contexte maximale. 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 les limites de tokens, un contexte plus large rend plus difficile pour le LLM de se concentrer sur les éléments réellement pertinents. C’est comme demander à un humain de trouver une aiguille dans une botte de foin ; plus la botte de foin 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 des morceaux massifs de texte de manière répétée peut rapidement rendre votre agent économiquement non viable.
Stratégies pour une Gestion de Contexte Plus Intelligente
Alors, comment résoudre 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 fins et concentrés.
1. Divulgation Progressive d’Information
Au lieu de balancer tout d’un coup, considérez votre agent comme un détective. Donnez-lui les détails immédiats du cas, laissez-le demander plus d’informations si besoin, ou fournissez des détails supplémentaires à mesure que la tâche évolue. C’est un principe fondamental dans de nombreux cadres agentiques, mais il est souvent mal implémenté.
Exemple : Agent de Support Client
Au lieu de lui donner l’intégralité de l’historique du client et du manuel produit au début de chaque interaction, vous pourriez commencer par :
- La requête actuelle du client.
- Un bref résumé de leur dernière interaction (si disponible et pertinent).
- Accès aux outils pour consulter des informations sur le produit ou des tickets passés *uniquement si nécessaire*.
Si le client demande « Comment puis-je 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 du mot de passe, qu’il peut obtenir 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 impactful que j’ai vue pour les tâches d’agent de longue durée. Au lieu de faire passer des conversations ou documents entiers entre les étapes ou les tours, résumez-les. Ce n’est pas seulement une question de couper des mots ; il s’agit d’extraire les *points saillants* qui sont critiques pour les étapes futures.
Revenons à l’agent d’analyse de transcription d’Acme Corp. Au départ, ils tentaient d’envoyer des transcriptions entières dans un seul appel LLM pour analyse. Cela a rapidement atteint les limites de tokens. Ma suggestion était de le décomposer :
- Étape 1 : Lecture et Extraction Initiale de la Transcription : Pour chaque transcription, avoir un agent spécialisé plus petit (ou même une prompt pour le LLM principal) identifier les entités clés (noms de produits, sentiment du client, types de problème) et résumer le problème central et sa résolution. Cette sortie est beaucoup plus petite que la transcription originale.
- Étape 2 : Agrégation et Synthèse : Fournir 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 de code Python simplifié illustrant 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é des interactions de support client.
Lisez la transcription suivante et fournissez un résumé concis (moins de 200 mots) qui
identifie le problème central du client, les étapes prises pour le résoudre, et l'issue finale.
Concentrez-vous sur les insights actionnables pour l'amélioration du produit ou les points de douleur courants 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 étape de résumé simple peut réduire le contexte de plusieurs ordres de grandeur, rendant l’analyse ultérieure beaucoup plus efficace et impactante.
3. Résumé Récursif pour les Conversations Longues
Pour les agents engagés dans des conversations multi-tours (comme un assistant personnel ou un chatbot sophistiqué), la fenêtre de contexte devient rapidement un problème. Chaque nouveau message s’ajoute à l’historique. La solution ? Le résumé récursif.
Après un certain nombre de tours (disons, 5-10 messages), prenez l’historique de conversation actuel et demandez au LLM les points clés discutés jusqu’à présent, en préservant les détails cruciaux comme les décisions prises, les questions ouvertes ou les exigences spécifiques des utilisateurs. Ensuite, vous pouvez jeter l’ancien historique verbeux et le remplacer par ce résumé concis, actualisant ainsi efficacement la fenêtre de contexte.
Pensez-y comme prendre des notes pendant une longue réunion. Vous ne transcrivez pas chaque mot ; vous notez les points clés et les éléments d’action.
Voici un flux conceptuel pour le résumé récursif :
conversation_history = [] # Stocke les 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
# Précède 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 avec le contexte combiné
summarization_prompt = [
{"role": "system", "content": "Vous êtes un résumeur 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éinitialise l'historique, en se basant 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 échanges ...
# 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 un résumé 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 échanges les plus récents.
Le truc ici est de s’assurer que le prompt de résumé identifie et conserve correctement les informations *cruciales* nécessaires pour les échanges futurs, et pas seulement un aperçu générique.
4. Génération Augmentée par la Récupération Ciblée (RAG)
RAG est une technique fondamentale, mais son application à la gestion des fenêtres de contexte est souvent sous-estimée. Au lieu d’intégrer des documents entiers, vous devriez intégrer des *morceaux* de documents, et plus important encore, vous devriez ê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 sur une base de données vectorielle et récupérer les meilleurs 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 corriger le code d’erreur 101 sur mon imprimante ACME-2000 ? », une simple recherche sémantique sur « corriger l’erreur 101 » pourrait renvoyer des solutions de dépannage 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 découpez et intégrez. Pour l’analyse des transcriptions de Acme Corp, au lieu d’intégrer 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 considérablement le contexte transmis à l’agent d’analyse final.
5. Extraction d’Informations Basée sur un Schéma
Lorsque vous avez besoin de pièces d’information spécifiques dans un texte plus large, ne comptez pas sur le LLM pour « simplement le comprendre ». Donnez-lui un schéma. Cela est particulièrement utile pour extraire des données structurées d’un texte non structuré, qui peuvent ensuite être transmises de manière beaucoup plus efficace que du texte brut.
Par exemple, si vous traitez des candidatures, au lieu de passer tout le CV, vous pouvez demander au LLM d’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 à utiliser pour les étapes d’agent suivantes ou les systèmes externes.
Ce n’est pas seulement une question d’économiser des tokens ; il s’agit de réduire l’ambiguïté et d’améliorer la fiabilité du transfert d’informations entre les modules ou outils d’agent.
Leçons Actionnables pour Votre Prochain Projet d’Agent
D’accord, cela faisait beaucoup. Mais le message central est le suivant : Considérez 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 vraiment nécessaire à chaque étape du processus de votre agent.
- Adoptez la Résumé (de manière Agressive) : Pour toute tâche de longue durée ou conversation multi-tours, faites du résumé une priorité dans l’architecture de votre agent. Expérimentez avec différents prompts de résumé pour trouver ce qui fonctionne le mieux pour votre cas d’utilisation.
- Découpez Malin, Récupérez Plus Malin : Avec RAG, concentrez-vous 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 d’atteindre 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, indiquez-le explicitement au LLM en utilisant 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 comprendre vraiment où votre fenêtre de contexte est consommée et où des optimisations sont nécessaires. Des outils comme LangChain ou LlamaIndex fournissent souvent des hooks 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, elles aident. Mais même avec des fenêtres de contexte massives, les principes de gestion efficace de l’information restent cruciaux. Une fenêtre de contexte de 1 million de tokens ne signifie pas que vous *devez* la remplir de bruit inutile. Cela signifie simplement que vous avez plus de capacité pour des informations *pertinentes et de haute qualité*.
Ainsi, la prochaine fois que vous déboguez un agent qui est confus, hallucine ou tout simplement lent, examinez attentivement sa fenêtre de contexte. Cela pourrait bien être le tueur silencieux que vous négligez.
Jusqu’à la prochaine fois, continuez à construire ces agents plus intelligents ! Alex Petrov, à bientôt.
Articles Connexes
- Actualités sur la Réglementation de l’IA : Approches des États-Unis vs de l’UE et Pourquoi Cela Compte
- Composants de l’Architecture d’Agent IA Expliqués
- Évaluation des Agents : Comment Mesurer la Réelle Performance
🕒 Published: