L'ingénierie de contexte pour les agents de code
L'ingénierie de prompt portait sur la formulation. L'ingénierie de contexte porte sur ce qu'il y a dans la fenêtre quand la formulation arrive, et cela vaut bien davantage.
Donnez à un modèle tout votre dépôt et une question, vous ne lui avez pas facilité la tâche. Vous en avez fait un problème de recherche avant d'être un problème de réponse. Il doit trouver le coin qui compte, dans une fenêtre où chaque fichier hors sujet dispute l'attention au bon.
C'est ce qu'on oublie : un contexte plus grand n'est pas strictement meilleur. Passé un seuil, il est pire, et vous le payez plus cher.
Les trois modes de défaillance
- La dilution. Le signal est là, mais entouré. La justesse de récupération d'un fait baisse à mesure que grandit le volume de matière sans rapport autour de lui, et elle baisse le plus vite pour ce qui est au milieu d'une longue fenêtre.
- La contradiction. Deux versions de la même fonction, un vieux commentaire contre du code neuf, un README périmé. Le modèle n'a aucun moyen de savoir lequel est à jour, et il choisira parfois le mauvais.
- La dérive. Les longues sessions accumulent des décisions annulées, des pistes abandonnées et des erreurs corrigées. Tout cela est encore dans la fenêtre, encore relu, et façonne encore la réponse.
Des règles qui tiennent
Elles n'ont rien d'astucieux. Ce sont celles qui survivent au contact du travail réel.
La pertinence bat le volume. Dix lignes qui répondent valent mieux que mille qui contiennent la réponse quelque part. Si vous pouvez montrer le code, montrez-le.
Le frais bat le complet. Un fichier périmé qui contredit le comportement actuel est pire que pas de fichier du tout, parce qu'il produit une réponse fausse et assurée au lieu d'une question.
Un plafond dur bat les bonnes intentions. Sans lui, le contexte ne fait que croître. Rien dans une boucle d'agent ne décide jamais qu'il en sait désormais assez.
Une tâche par fenêtre. La technique de gestion de contexte la moins chère qui existe, c'est de fermer la session.
À quoi cela ressemble en pratique
capsul context 'pourquoi le webhook renvoie 500' --open src/app/api/polar/webhook/route.tsAssemble le contexte et annonce ce qu'il coûte, sans dépenser une requête.
L'intérêt de construire le contexte à part, c'est que cela rend visible la partie invisible. On voit ce qu'une tâche coûte avant de s'y engager, et on peut comparer deux façons de poser la même question.
Le mesurer
L'ingénierie de contexte a un problème d'honnêteté, et il faut le nommer. Presque toutes les affirmations du domaine sont avancées sans bras témoin, ce qui les rend infalsifiables. Si vous changez la façon d'assembler le contexte, mesurez la même tâche sur le même modèle avec et sans le changement, répétez assez pour voir le plancher de bruit, et publiez l'intervalle plutôt que la médiane.
Questions
L'ingénierie de contexte, c'est de l'ingénierie de prompt renommée ?
Non. L'ingénierie de prompt porte sur la formulation de la demande, qui est une petite fraction de ce qui est envoyé. L'ingénierie de contexte porte sur les quatre-vingt-dix et quelques pour cent restants : quels fichiers, quel historique, quelles sorties d'outils, et ce qu'on laisse dehors.
Une fenêtre de deux cent mille tokens supprime-t-elle le problème ?
Elle supprime le plafond, pas le problème. La justesse de récupération se dégrade toujours avec le volume, les contradictions embrouillent toujours, et vous payez toujours chaque token à chaque tour.
Quel budget de contexte choisir ?
Assez petit pour forcer un choix. Le chiffre exact compte moins que le fait d'en avoir un, car un agent sans plafond remplit ce qu'on lui donne.
Comment savoir si un changement de contexte a vraiment aidé ?
Lancez la même tâche des deux façons, plusieurs fois, sur le même modèle, et comparez l'intervalle plutôt qu'une exécution isolée. Les sessions d'agent sont assez bruyantes pour qu'une comparaison avant/après unique ne veuille presque rien dire.
$ npm i -g @penra/capsul