Machine Learning Mastery publie un guide de context engineering pour des agents IA fiables

Machine Learning Mastery a publié un guide pratique du context engineering pour les agents IA, la discipline qui détermine les données que le modèle voit à chaque moment de son travail. La thèse centrale de l'article : les problèmes en production des systèmes agentiques tiennent plus souvent non à la qualité du modèle, mais à la façon dont les développeurs gèrent le contexte, l'historique et les tokens.

Pourquoi les agents plantent

L'auteur propose de considérer la fenêtre de contexte comme une ressource de calcul limitée, et non comme un détail technique que l'on pourrait ignorer. Les tokens n'ont pas qu'un coût financier, puisque chaque appel au modèle est facturé : une entrée longue et mal structurée dégrade aussi la qualité du raisonnement. Le modèle accorde plus d'attention au début et à la fin du contexte, tandis que le milieu perd souvent de son influence, même si tout tient formellement dans la limite.

La fenêtre de contexte n'est pas une contrainte à contourner, mais le

principal paramètre de conception d'un système agentique.

D'où le scénario d'échec typique : on « colle » simplement tout à l'agent, y compris d'anciennes réponses, des tool outputs bruts, des fragments de retrieval en double et des décisions périmées. La latence et le coût augmentent, et le signal utile se noie dans le bruit. L'article compare cela à la RAM : la mémoire rapide est puissante, mais finie. Tout ce dont l'agent n'a pas besoin tout de suite doit être stocké en mémoire externe et n'entrer dans le contexte qu'à la demande.

Comment assembler le contexte

L'idée d'architecture la plus utile du guide est de séparer strictement contexte statique et contexte dynamique. La partie statique comprend les instructions système, le rôle de l'agent, les règles, les descriptions des outils et le format de réponse. Ces données ne changent presque pas, on peut donc les mettre en cache comme préfixe. La partie dynamique correspond à la requête en cours de l'utilisateur, aux résultats récents des outils, aux dernières étapes de l'agent et aux documents réellement nécessaires à ce stade précis.

Avant de construire le prompt, l'auteur conseille d'auditer toutes les couches qui remplissent habituellement la context window :

• instructions système et exemples few-shot ;
• historique du dialogue, réponses de l'agent et résultats de tool calls ;
• données externes issues d'une base de connaissances, de fichiers ou d'une recherche ;
• état de travail : conclusions intermédiaires, plan, next steps.

La conclusion pratique est simple : il ne faut pas minimiser chaque couche à tout prix, mais retirer uniquement ce qui n'aide pas l'étape en cours.

Un schéma en deux passes paraît utile. Le système monte d'abord l'ossature permanente : system prompt, règles pouvant être mises en cache, summaries de longue durée. Il charge ensuite la partie variable : l'état actuel de la tâche, un retrieval récent et une courte fin d'historique pertinente. Cet assemblage simplifie aussi le débogage, car on voit tout de suite si le problème vient de la configuration ou des données de la session en cours.

Comment contrôler la qualité

Un volet distinct de l'article porte sur les deux zones où les agents se dégradent le plus vite : l'historique du dialogue et le retrieval. Accumuler tout l'échange fait gonfler rapidement le contexte et fige les erreurs du modèle comme s'il s'agissait de faits. L'auteur conseille de passer de l'historique brut à un rolling summary, voire à un session state structuré qui consigne séparément l'intention de l'utilisateur, les décisions prises, les actions effectuées et l'étape suivante. L'agent obtient ainsi une mémoire sans croissance infinie du nombre de tokens.

Pour le retrieval, la logique est proche : chaque lot de données récupéré consomme du budget, on ne peut donc pas le considérer comme gratuit. L'article recommande de filtrer les résultats avant de les insérer dans le prompt, d'utiliser le semantic chunking plutôt qu'un découpage en morceaux de taille fixe et, au besoin, de combiner la recherche sémantique avec des filtres par mots-clés ou métadonnées. Pour les systèmes matures, l'option jugée la plus solide est l'agent-controlled retrieval, où l'agent lance lui-même la recherche uniquement quand il en a réellement besoin, et non automatiquement à chaque tour.

En production, l'auteur suggère de mesurer non seulement la réponse finale, mais aussi la qualité du contexte lui-même. Parmi les métriques utiles : le remplissage du budget de tokens, le taux de compression après summary, la précision du retrieval et les signes de context drift, quand l'agent se met à relire des fichiers déjà traités ou s'écarte de la tâche initiale. Autre technique pratique, la probe-based evaluation : après la compression ou le retrieval, on pose au système des questions de contrôle pour vérifier que les faits et artefacts nécessaires ont été conservés et qu'une tâche en plusieurs étapes peut reprendre au même point.

Ce que cela signifie

Le guide de Machine Learning Mastery décrit bien un déplacement dans le développement d'agents : la qualité d'un agent IA dépend désormais non seulement du choix du modèle, mais aussi de la rigueur avec laquelle sont conçus la mémoire, le retrieval et le budget de tokens. Pour les équipes qui mettent des agents en production, c'est un signal direct : il faut concevoir le contexte comme une couche d'architecture à part entière, et non comme la queue d'un prompt.