Ingénierie du contexte pour les agents

L’ingénierie du contexte consiste à choisir les instructions, fichiers et résultats récents nécessaires à la prochaine action d’un agent, tout en maintenant des documents durables plutôt qu’en comptant sur le seul prompt. La fenêtre de contexte limite la quantité d’informations que le modèle peut recevoir à la fois ; elle ne garantit pas qu’il les exploitera toutes correctement. Lost in the Middle montre, par exemple, que la qualité de récupération peut dépendre de la position de l’information dans une longue entrée. L’objectif est de fournir des éléments pertinents et à jour, pas de remplir la fenêtre.

Cette page traite de l’ensemble de travail d’une tâche : ce que le modèle doit voir maintenant et ce qui peut rester hors de sa fenêtre. Le pipeline de recherche couvre la découverte des candidats ; la mémoire des agents, la conservation et la révision entre tâches.

Voir l’image en grand

L’axe horizontal déplace le passage contenant la réponse parmi 20 documents, soit environ 4 000 tokens. L’axe vertical mesure la précision des réponses, pas le rappel du moteur de recherche. Dans cette expérience avec GPT-3.5-Turbo-0613, les positions centrales donnent de moins bons résultats que les extrémités ; les pointillés représentent les réponses sans documents. Ce résultat invite à tester la position des preuves avec le modèle utilisé, sans généraliser cette courbe historique à tous les modèles.

Liu et al., Lost in the Middle (2024), Figure 1; cropped from the paper. · CC BY 4.0

Ce qui doit figurer dans le contexte

Les quatre premières couches peuvent entrer dans le prompt. L’état durable reste à l’extérieur et y est de nouveau sélectionné au besoin. Une transcription est un historique d’interaction, pas la source de vérité du projet.

Sélectionner avant de compresser

Recherchez des symboles, sites d’appel, tests, définitions et preuves exactes avant de demander à un modèle de résumer quoi que ce soit. Un résumé ne peut pas retrouver un élément qui n’a jamais été récupéré, et des résumés répétés peuvent transformer discrètement une supposition en fait.

Un budget d’entrée pratique est :

$$\text{usable input}=\text{model limit}-\text{reserved output}-\text{tool/schema overhead}-\text{safety margin}.$$

Il n’existe pas de pourcentage universel pour les règles, les preuves et la sortie. C’est l’action suivante qui doit déterminer le paquet. Les modèles locaux peuvent aussi atteindre les limites du cache KV ou de mémoire avant que la limite de contexte annoncée ne devienne exploitable.

Exemple de paquet de tâche

Pour un analyseur qui échoue sur une séquence UTF-8 coupée, un paquet utile pourrait être :

contract:
  write_scope: [src/parser.py, tests/test_parser.py]
  success: targeted test and parser suite pass
state:
  attempted: boundary check after byte slicing
  result: still fails on a split multibyte code point
working_set:
  - parser function and two callers
  - three relevant tests
  - exact traceback
open_question: should truncation operate on bytes or Unicode code points?

Le dépôt entier, le journal de tests complet et toutes les hypothèses antérieures seraient plus volumineux, mais pas nécessairement plus utiles.

Comment garder l’ensemble de travail réduit

Technique	Bon usage	Risque principal
recherche exacte ou par symbole	identifiants et dépendances connus	manque les synonymes conceptuels
récupération dans un corpus	large sélection de sources	erreurs de classement et documents hostiles ou périmés
résumé glissant	clôturer des parties terminées d’une conversation	perte de provenance et dérive du résumé
cache de prompt	préfixes stables répétés pris en charge par le fournisseur	une petite modification du préfixe peut invalider le cache
sortie d’outil bornée	grands journaux et résultats de commandes	le contenu central omis peut contenir la cause
relevé de tâche sur disque	sessions devant survivre à un redémarrage	le relevé et le dépôt peuvent diverger

Le cache de prompt fonctionne au mieux lorsque les instructions et schémas réellement stables restent inchangés. Les économies exactes dépendent du fournisseur, du modèle, de la forme de la requête et de la politique de cache ; mesurez-les plutôt que de reprendre un pourcentage accrocheur.

Les sorties volumineuses doivent être stockées intégralement et représentées dans le contexte par un extrait utile et une référence à l’artefact. La troncature de la tête et de la queue est une option, non la garantie que la ligne importante subsiste.

Compresser sans blanchir l’incertitude

Un résumé doit conserver :

• la source ou l’artefact étayant une affirmation ;
• si l’énoncé a été observé, déduit ou seulement proposé ;
• les tentatives échouées qui évitent de les répéter ;
• les contradictions non résolues ;
• la prochaine décision, et non chaque tour de conversation.

Un état structuré est souvent plus facile à examiner qu’un récapitulatif rédigé, mais il n’est pas juste automatiquement. Mettez-le à jour de façon atomique lorsque c’est possible et comparez-le aux fichiers actuels lors de la reprise.

Tester une stratégie de contexte

Déplacez les mêmes preuves entre le début, le milieu et la fin. Ajoutez des documents non pertinents et contradictoires. Incluez un cas où la bonne réponse est « preuves insuffisantes ». Mesurez la réussite de la tâche, les contraintes manquées, l’attribution, la latence et l’usage de jetons.

Parmi les libellés d’échec utiles figurent le bourrage de contexte, le biais de récence, la dérive du résumé, le biais de récupération et la dépendance à l’état caché. Ces noms sont des raccourcis de diagnostic, pas des raisons d’ajouter un cadre de plus. Le remède consiste généralement à retirer le contenu non pertinent, à récupérer de meilleures preuves ou à sortir l’état durable du prompt.

Revenir au parcours · Les notes ouvertes sont mémorisées dans ce navigateur.