Contexte Technique
Je me suis intéressé à cette discussion non pas pour la beauté de la formule, mais parce qu'elle a un impact direct sur le coût et la qualité de l'automatisation par l'IA. Quand un agent traîne avec lui tout le fatras de l'historique, il ne réfléchit pas mieux. Il fait simplement des erreurs plus coûteuses.
L'idée elle-même est simple : lors de la compression, je conserve d'abord les invariants, puis j'extrais l'essence à haute densité d'information, et pour les parties complexes, je montre un exemple au lieu d'une longue explication. C'est-à-dire que je ne raconte pas tout le plan, mais je préserve ce qui ne doit pas être brisé, ce qui influence la décision actuelle et à quoi doit ressembler un bon résultat.
Et c'est là que je comprends les deux côtés de l'argument. Si le plan est bancal depuis le début, on peut en effet se retrouver avec des centaines de lignes de code jetées. Mais une revue détaillée de chaque plan peut aussi facilement se transformer en un gouffre à tokens, où l'agent dépense son contexte en introspection au lieu de travailler.
En pratique, je séparerais deux couches. La première, la couche permanente : objectifs, contraintes, interdictions architecturales, hypothèses critiques. Ce sont les invariants. La seconde, la couche éphémère : l'étape actuelle, les décisions controversées, les signaux frais des journaux, les échecs à ne pas répéter.
J'interprète la partie sur la 'haute perplexité' d'un point de vue d'ingénieur, sans romantisme. Il faut conserver non pas le plus 'intelligent', mais le plus rare et le plus utile : un bug inattendu, une limitation cachée de l'API, un conflit d'exigences, le coût d'une erreur. L'agent générera tout ce qui est banal par lui-même. Il oubliera en premier tout ce qui est inhabituel.
Et 'Montrer, ne pas dire' fonctionne très bien dans les prompts. Au lieu de dire 'écris de manière concise et pertinente', je préfère donner un mini-exemple de bonne compression. Le modèle saisit le format plus rapidement, et j'obtiens moins de dérive stylistique et moins de bavardage abstrait.
Si l'on regarde les recherches sur la compression extractive, la logique est la même : sélectionner des fragments importants est généralement plus fiable que de les reformuler avec un résumé abstrait. C'est particulièrement visible dans les chaînes d'agents, où toute généralisation imprécise brise ensuite le plan plus bas dans la pile.
Impact sur l'Entreprise et l'Automatisation
Pour la production, il y a trois effets directs. Premièrement : des exécutions longues moins chères, car vous réduisez les tokens sans rognage aveugle. Deuxièmement : moins de 'perdu au milieu', lorsque l'agent oublie un fait critique quelque part au milieu de son historique. Troisièmement : une intégration de l'IA plus facile dans les processus réels, où le contexte est constamment bruyant.
Les équipes avec de longs flux de travail en bénéficient : développement, support, audit, traitement de documents. Ceux qui croient qu'une grande fenêtre de contexte remplace à elle seule l'architecture de l'IA sont perdants.
Chez Nahornyi AI Lab, nous rencontrons constamment ces goulots d'étranglement : où stocker les invariants, quoi compresser de manière extractive, et ce qui ne peut absolument pas être coupé. Si votre agent brûle déjà votre budget tout en perdant le fil de la tâche, analysons votre scénario et élaborons une solution de développement IA pour que le modèle fonctionne enfin au lieu de simplement dévorer des tokens.