Ingénierie du contexte pour les agents d’IA : une analyse approfondie

de meilleurs modèles, des fenêtres contextuelles plus grandes et des agents plus performants. Mais la plupart des échecs du monde réel ne proviennent pas de la capacité du modèle, mais de la façon dont le contexte est construit, transmis et maintenu.

C’est un problème difficile. L’espace évolue rapidement et les techniques évoluent encore. Une grande partie reste une science expérimentale et dépend du contexte (jeu de mots), des contraintes et de l’environnement dans lequel vous évoluez.

Dans mon travail de création de systèmes multi-agents, un modèle récurrent est apparu : la performance dépend bien moins de la quantité de contexte que vous donnez à un modèle, mais bien plus de la façon dont précisément vous le façonnez.

Cette pièce est une tentative de distiller mes apprentissages en quelque chose que vous pouvez utiliser.

Il se concentre sur les principes de gestion du contexte en tant que ressource contrainte – décider ce qu’il faut inclure, ce qu’il faut exclure et comment structurer les informations afin que les agents restent cohérents, efficaces et fiables au fil du temps.

Car en fin de compte, les agents les plus forts ne sont pas ceux qui voient le plus. Ce sont eux qui voient les bonnes choses, sous la bonne forme, au bon moment.

Terminologie

Ingénierie du contexte

L’ingénierie de contexte est l’art de fournir les informations, les outils et le format appropriés à un LLM pour qu’il puisse accomplir une tâche. Une bonne ingénierie du contexte signifie trouver le plus petit ensemble possible de jetons de signal élevé qui donnent au LLM la plus grande probabilité de produire un bon résultat.

En pratique, une bonne ingénierie du contexte se résume généralement à quatre mouvements. Toi décharger informations vers des systèmes externes (déchargement de contexte) le modèle n’a donc pas besoin de tout transporter en bande. Toi récupérer informations de manière dynamique au lieu de tout charger en premier (récupération du contexte). Toi isoler contexte afin qu’une sous-tâche n’en contamine pas une autre (isolement du contexte). Et toi réduire historique en cas de besoin, mais uniquement de manière à préserver ce dont l’agent aura encore besoin plus tard (réduction du contexte).

Un mode de défaillance courant de l’autre côté est contexte pollution: la présence de trop d’informations inutiles, contradictoires ou redondantes qui distrait le LLM.

Pourriture contextuelle

La pourriture du contexte est une situation dans laquelle les performances d’un LLM se dégradent à mesure que la fenêtre contextuelle se remplit, même si elle se situe dans la limite établie. Le LLM a encore de la place pour en savoir plus, mais son raisonnement commence à s’estomper.

Vous aurez remarqué que la fenêtre contextuelle effective, dans laquelle le modèle fonctionne avec une qualité élevée, est souvent beaucoup plus petite que ce dont le modèle est techniquement capable.

Il y a deux parties à cela. Premièrement, un modèle ne conserve pas un rappel parfait sur toute sa fenêtre contextuelle. Les informations du début et de la fin sont mémorisées de manière plus fiable que celles du milieu.

Deuxièmement, des fenêtres contextuelles plus grandes ne résolvent pas les problèmes des systèmes d’entreprise. Les données d’entreprise sont effectivement illimitées et fréquemment mises à jour. Même si le modèle pouvait tout ingérer, cela ne signifierait pas qu’il pourrait en maintenir une compréhension cohérente.

Tout comme les humains ont une capacité de mémoire de travail limitée, chaque nouveau jeton introduit dans le LLM épuise d’une certaine quantité son budget d’attention. Le manque d’attention provient des contraintes architecturales du transformateur, où chaque jeton s’occupe de tous les autres jetons. Cela conduit à un modèle d’interaction n² pour n jetons. À mesure que le contexte s’élargit, le modèle est obligé de répartir son attention sur un plus grand nombre de relations.

Compactage du contexte

Le compactage du contexte est la réponse générale à la pourriture du contexte.

Lorsque le modèle approche de la limite de sa fenêtre contextuelle, il résume son contenu et relance une nouvelle fenêtre contextuelle avec le résumé précédent. Ceci est particulièrement utile pour les tâches de longue durée afin de permettre au modèle de continuer à fonctionner sans trop de dégradation des performances.

Travaux récents sur le pliage de contexte propose une approche différente : les agents gèrent activement leur contexte de travail. Un agent peut bifurquer pour gérer une sous-tâche, puis la replier une fois terminée, réduisant ainsi les étapes intermédiaires tout en conservant un résumé concis du résultat.

La difficulté, cependant, n’est pas de résumer, mais de décider de ce qui survit. Certaines choses doivent rester stables et presque immuables, comme l’objectif de la tâche et les contraintes strictes. D’autres peuvent être jetés en toute sécurité. Le problème est que l’importance de l’information n’est souvent révélée que plus tard.

Un bon compactage doit donc préserver les faits qui continuent de contraindre les actions futures : quelles approches ont déjà échoué, quels fichiers ont été créés, quelles hypothèses ont été invalidées, quelles poignées peuvent être revisitées et quelles incertitudes restent non résolues. Sinon, vous obtenez un résumé soigné et concis qui se lit bien pour un humain et est inutile pour un agent.

Harnais d’agent

Un modèle n’est pas un agent. Le harnais est ce qui transforme un modèle en un seul.

Par exploiter, j’entends tout ce qui concerne le modèle et qui décide de la manière dont le contexte est assemblé et maintenu : sérialisation rapide, routage des outils, politiques de nouvelle tentative, règles régissant ce qui est conservé entre les étapes, etc.

Une fois que vous regardez les systèmes d’agents réels de cette façon, de nombreux « échecs de modèle » supposés semblent désormais différents. J’en ai rencontré beaucoup au travail. Il s’agit en réalité de défaillances d’exploitation : l’agent a oublié car rien ne persistait dans le bon état ; il a répété le travail parce que le harnais n’a révélé aucun artefact durable d’une défaillance antérieure ; il a choisi le mauvais outil parce que le harnais surchargeait l’espace d’action ; et ainsi de suite.

Un bon harnais est, dans un certain sens, une coque déterministe enroulée autour d’un noyau stochastique. Cela rend le contexte suffisamment lisible, stable et récupérable pour que le modèle puisse consacrer son budget de raisonnement limité à la tâche plutôt qu’à la reconstruction de son propre état à partir d’une trace désordonnée.

Communication entre agents

À mesure que les tâches deviennent plus complexes, les équipes se sont tournées par défaut vers des systèmes multi-agents.

L’erreur est de supposer que plus d’agents signifie plus de contexte partagé. En pratique, transférer une transcription partagée géante dans chaque sous-agent crée souvent exactement le contraire de la spécialisation. Désormais, chaque agent lit tout, hérite des erreurs des autres et paie encore et encore la même facture contextuelle.

Si seulement un certain contexte est partagé, un nouveau problème apparaît. Qu’est-ce qui fait autorité lorsque les agents ne sont pas d’accord ? Qu’est-ce qui reste local et comment les conflits sont-ils résolus ?

La solution consiste à traiter la communication non pas comme une mémoire partagée, mais comme une transfert d’état via des interfaces bien définies.

Pour les tâches discrètes avec des entrées et des sorties claires, les agents doivent généralement communiquer via des artefacts plutôt que par des traces brutes. Un agent de recherche Web, par exemple, n’a pas besoin de transmettre l’intégralité de son historique de navigation. Il lui suffit de faire apparaître le matériau que les agents en aval peuvent réellement utiliser.

Cela signifie que le raisonnement intermédiaire, les tentatives infructueuses et les traces d’exploration restent privées sauf si cela est explicitement nécessaire. Ce qui est transmis, ce sont des résultats distillés : des faits extraits, des conclusions validées ou des décisions qui contraignent l’étape suivante.

Pour des tâches plus étroitement couplées, comme un agent de débogage où le raisonnement en aval dépend véritablement des tentatives antérieures, une forme limitée de partage de trace peut être introduite. Mais cela doit être délibéré et limité, et non une décision par défaut.

Pénalité de cache KV

Lorsque les modèles d’IA génèrent du texte, ils répètent souvent bon nombre des mêmes calculs. La mise en cache KV est une technique d’optimisation du temps d’inférence qui accélère ce processus en mémorisant les informations importantes des étapes précédentes au lieu de tout recalculer à nouveau.

Cependant, dans les systèmes multi-agents, si chaque agent partage le même contexte, vous confondez le modèle avec une tonne de détails non pertinents et payez une énorme pénalité de cache KV. Plusieurs agents travaillant sur la même tâche doivent communiquer entre eux, mais cela ne doit pas se faire via le partage de mémoire.

C’est pourquoi les agents doivent communiquer de manière contrôlée via des résultats minimaux et structurés.

Gardez l’ensemble d’outils de l’agent petit et pertinent

Le choix de l’outil est un problème de contexte déguisé en problème de capacité.

À mesure qu’un agent accumule davantage d’outils, l’espace d’action devient plus difficile à parcourir. Il existe désormais une probabilité plus élevée que le modèle adopte une mauvaise action et emprunte un itinéraire inefficace.

Cela a des conséquences. Les schémas d’outils doivent être beaucoup plus distincts que la plupart des gens ne le pensent. Les outils doivent être bien compris et avoir un minimum de chevauchement de fonctionnalités. Il doit être très clair sur leur utilisation prévue et comporter des paramètres d’entrée clairs et sans ambiguïté.

Un mode d’échec courant que j’ai remarqué même dans mon équipe est que nous avons tendance à avoir des ensembles d’outils très volumineux qui sont ajoutés au fil du temps. Cela conduit à une prise de décision floue quant aux outils à utiliser.

Mémoire agent

Il s’agit d’une technique dans laquelle l’agent écrit régulièrement des notes conservées en mémoire en dehors de la fenêtre contextuelle. Ces notes sont réintégrées ultérieurement dans la fenêtre contextuelle.

Le plus difficile est de décider ce qui mérite d’être promu dans la mémoire. Ma règle générale est que la mémoire durable doit contenir des éléments qui continuent de contraindre le raisonnement futur : les préférences persistantes. Tout le reste devrait avoir une barre très haute. En stocker trop n’est qu’une autre voie de retour vers la pollution contextuelle, seulement maintenant vous l’avez rendue persistante.

Mais la mémoire sans révision est un piège. Une fois que les agents conservent leurs notes au fil des étapes ou des sessions, ils ont également besoin de mécanismes de résolution, de suppression et de rétrogradation des conflits. Autrement, la mémoire à long terme devient une décharge de croyances dépassées.

Pour résumer

L’ingénierie du contexte est toujours en évolution et il n’existe pas de méthode unique et correcte pour y parvenir. Une grande partie reste empirique, façonnée par les systèmes que nous construisons et les contraintes sous lesquelles nous opérons.

Si rien n’est fait, le contexte grandit, dérive et finit par s’effondrer sous son propre poids.

S’il est bien géré, le contexte fait la différence entre un agent qui se contente de répondre et un autre capable de raisonner, de s’adapter et de rester cohérent lors de tâches longues et complexes.