Ingénierie du contexte pour les agents d’IA : sélectionner ce que le modèle voit

L’idée fondamentale : un fragment petit et pertinent

L’objectif n’est jamais de fournir au modèle tout ce qui pourrait éventuellement l’aider. Il s’agit plutôt de lui donner uniquement la partie d’information nécessaire pour qu’il puisse répondre correctement, en excluant le reste.

Les modèles se comportent de la même manière. L’ingénierie contextuelle consiste justement à leur transmettre ces trois fichiers plutôt que l’ensemble du répertoire.

Pourquoi la formulation seule ne suffit plus

Les premiers conseils concernant le travail avec les modèles de langage se concentraient sur la formulation : comment rédiger des instructions et quelles formulations produisaient de meilleures réponses. Il s’agit de l’ingénierie des prompts, et cela reste important pour une seule question.

Cependant, un agent ne répond pas à une seule question. Il exécute une boucle : il lit quelque chose, appelle un outil, reçoit un résultat, choisit l’action suivante et répète le processus, parfois des dizaines de fois. Chaque itération ajoute du matériel à ce que le modèle traite. Finalement, le contexte accumulé devient si volumineux que des détails importants sont négligés, un peu comme quelqu’un qui a assisté à des réunions toute la journée et ne se souvient plus de ce qui a été décidé lors de la première.

L’ingénierie contextuelle, selon Anthropic, consiste à trouver le meilleur ensemble d’informations possible pour le modèle à chaque instant donné, plutôt qu’à rédiger une seule instruction adéquate. Cela illustre le changement : l’ingénierie des prompts concerne les mots, tandis que l’ingénierie contextuelle prend en compte tout ce qui est présent au moment où le modèle répond.

Ingénierie des prompts versus ingénierie contextuelle

Ces deux approches se recoupent mais diffèrent par leur portée, leurs utilisations typiques et leurs modes de défaillance :

• Portée. L’ingénierie des prompts influence la formulation d’une seule instruction. L’ingénierie contextuelle gère l’ensemble des éléments d’entrée : instructions, conversation antérieure, faits récupérés et outils disponibles.

Où cela brille. L’ingénierie des prompts convient aux questions et tâches ponctuelles. L’ingénierie du contexte est particulièrement importante pour les agents à plusieurs étapes, où ce qui est transmis d’une étape à l’autre est aussi crucial que la demande actuelle.

Erreur typique. Dans l’ingénierie des prompts, il s’agit d’une instruction ambiguë ou confuse. Dans l’ingénierie du contexte, c’est le fait de fournir trop d’informations ou des informations erronées, même lorsque l’instruction est parfaitement claire.

Réparation typique. Un prompt faible peut être corrigé en le reformulant. Un problème de contexte ne peut pas être résolu par une simple reformulation ; il faut modifier ce qui est récupéré, ce qui est conservé et ce qui est éliminé.

Un diagnostic rapide : si votre correction consiste à modifier des mots, vous pratiquez l’ingénierie de prompt. Si votre correction change les informations que le modèle reçoit au départ, vous pratiquez l’ingénierie de contexte. Pour une méthode structurée permettant de déterminer à quel niveau appartient une panne d’agent, consultez debugging AI agents by layer.

Les quatre composants que vous gérez

Le contexte de chaque agent est constitué de quatre sources. Chacune d’elles a ses propres risques de dysfonctionnement.

Instructions : la description du poste

C’est le prompt système, qui décrit ce que l’agent doit faire et comment. S’il est trop rigide, l’agent ne peut gérer rien en dehors du script. S’il est trop souple, l’agent improvise librement. Visez des directives suffisamment précises pour orienter le comportement sans tenter d’énumérer à l’avance toutes les situations possibles.

Récupération : l’assistant de recherche

La récupération permet d’obtenir des informations externes en recherchant dans des documents, en interrogeant une base de données ou en lisant des fichiers. Une mauvaise récupération est la principale cause pour laquelle les systèmes d’IA affirment des choses fausses avec assurance. Souvent, le modèle ne invente rien ; on lui a fourni des faits incorrects ou irrelevants auxquels il s’est raisonnablement fié. Améliorer ce qui est récupéré a souvent un effet plus positif sur la précision que toute modification du prompt.

Mémoire : le carnet

La mémoire concerne ce que l’agent conserve, tant au cours d’une seule conversation qu’à travers différentes sessions. Sans mécanisme de synthèse et d’élimination des informations anciennes, la mémoire perd son utilité. Elle croît constamment jusqu’à ce que la plupart de ses contenus soient des données inutiles qui entravent l’accès aux informations actuellement importantes.

Outils : la boîte à outils

Les outils définissent les actions que l’agent peut effectuer, telles que la recherche sur le Web, l’exécution de code ou l’envoi d’e-mails. Le nom et la description de chaque outil fournissent également du contexte. Un ensemble de dix outils superposés et presque identiques confond un modèle de la même manière que dix tournevis indiscernables confondraient un nouvel employé. Moins d’outils ayant des fonctions clairement distinctes facilitent le choix et réduisent les coûts.

Un pipeline minimal de constitution du contexte

Le pseudocode suivant montre comment les quatre composants s’assemblent pour une seule appel à un modèle. Les fonctions d’aide sont des placeholders pour toute méthode de recherche, de classement et de résumé que vous utilisez, mais la structure reflète la manière dont les systèmes réels abordent le problème.

Celui-ci fonctionne en quatre étapes. D’abord, il effectue une recherche large, en acceptant un certain niveau de bruit, avec une limite généreuse de 50 candidats. Ensuite, il classe ces candidats et ne conserve que les cinq meilleurs. Par la suite, il compresse l’historique de la conversation en un résumé limité à 500 unités, au lieu de le reproduire intégralement. Enfin, il organise délibérément les éléments, en plaçant d’abord les instructions et la question actuelle en dernier, puis il ajuste le résultat en fonction du budget de tokens alloué.

def get_context_for_the_model(question, past_conversation, budget):
    # Step 1: Cast a wide net — search broadly, don't worry about noise yet
    possible_facts = search_everywhere(question, limit=50)
    # Step 2: Narrow it down - keep only the genuinely relevant ones
    best_facts = keep_most_relevant(possible_facts, top=5)
    # Step 3: Summarize old conversation instead of keeping all of it
    short_memory = summarize(past_conversation, max_length=500)
    # Step 4: Put the most important things first and last, not buried in the middle
    final_context = [
        job_description,      # instructions
        short_memory,         # memory
        *best_facts,          # retrieval
        question,             # what's being asked right now, last
    ]
    return trim_to_fit(final_context, budget)

Deux habitudes présentes dans ce schéma méritent d’être adoptées.

Recherchez largement, puis affinez sévèrement. Une recherche large diminue le risque de manquer le document pertinent ; un classement rigoureux permet de garder un contexte restreint. Ne faire que la première étape submerge le modèle, tandis que ne faire que la seconde risque de ne jamais trouver le matériel adéquat.

Mettez ce qui est important en marge. Placez le contenu le plus important au début ou à la fin de l’entrée plutôt qu’au milieu. Il ne s’agit pas d’une préférence stylistique. Des recherches menées sur de longues entrées ont constaté à plusieurs reprises que les modèles prêtent moins d’attention aux informations enfouies au milieu d’un contexte long, phénomène souvent qualifié de « perdu au milieu ». L’ampleur de cet effet varie selon le modèle, il convient donc de le tester avec votre propre configuration, mais l’ordre des éléments reste un moyen peu coûteux pour améliorer les résultats dans tous les cas.

Quelques améliorations pratiques découlent de la même logique. Déterminez à l’avance comment le budget est réparti entre les différents composants, afin qu’un grand nombre de résultats de recherche ne vienne pas masquer silencieusement les instructions. Lors du tri, supprimez d’abord les éléments récupérés les moins pertinents avant de toucher aux instructions ou à la question en cours. Enregistrez également le contexte final assemblé pour chaque appel ; lorsque l’agent se comporte mal, ce registre montre généralement pourquoi.

Que se passe-t-il lorsque le contexte n’est pas sélectionné avec soin ?

Inclusion de tout par précaution

Ajouter tous les éléments potentiellement pertinents semble responsable, mais a tendance à avoir des effets contraires. Plus le modèle doit examiner de matériel non pertinent, plus il a de mal à trouver le fait qui compte vraiment. C’est l’équivalent de lire un rapport de cent pages avant de prendre une décision en cinq minutes.

Informations obsolètes

Si rien ne vérifie si le contenu récupéré reste exact, le modèle produira une réponse fiable basée sur des informations devenues fausses il y a des mois. Des métadonnées relatives à la fraîcheur, des règles d’expiration ou une révalidation pour les sources sensibles au temps aident toutes à y remédier.

Cacher le fait clé

Même lorsque la récupération trouve précisément le bon fait, le placer au milieu d’un long texte augmente statistiquement les chances qu’il soit ignoré. Le fait reste identique ; seule sa position a changé, ce qui aggrave la situation.

Trop d’options similaires

Si un membre de votre équipe ne peut pas déterminer avec certitude quel outil ou document s’applique dans une situation donnée, le modèle ne fera pas mieux. Unifiez les outils qui se chevauchent et éliminez les documents presque identiques avant qu’ils n’arrivent dans le contexte.

Questions fréquentes

L’ingénierie de contexte remplace-t-elle l’ingénierie des prompts ?

Non. Des instructions claires font toujours partie de la tâche. L’ingénierie du contexte est la mission plus large qui les entoure : déterminer ce que le modèle voit en dehors de l’instruction elle-même.

Pourquoi plus d’informations peut-il nuire aux résultats ?

L’attention est une ressource limitée, tant pour les modèles que pour les humains. Plus le modèle doit trier d’informations, plus il y a de risques qu’il manque le détail crucial, tout comme une personne a du mal à repérer une ligne importante dans un long document.

Un écran de contexte plus grand résout-il le problème ?

Cela aide en offrant plus d’espace, mais cela ne résout pas le problème de fond. Les informations situées au milieu de longs entrées sont toujours utilisées avec moins de fiabilité, et la latence ainsi que le coût augmentent à mesure que l’entrée s’allonge. Il reste utile de sélectionner soigneusement les informations à inclure, même avec des écrans de contexte très grands.

Points clés

• Considérez l’entrée du modèle comme un artefact conçu spécifiquement pour chaque appel, et non comme un simple journal d’entrées.
• Gérez délibérément les quatre composants : instructions, récupération des informations, mémoire et outils ; chacun peut échouer à sa manière.
• Récupérez des informations de manière large, classez-les de façon stricte, résumez l’historique, et placez le contenu essentiel au début ou à la fin.
• Lorsqu’un agent se dégrade au fil de plusieurs étapes, examinez ce qui lui a été donné avant de réécrire ce qui lui a été indiqué.
• Une fenêtre temporelle plus large offre de l’espace, mais pas d’immunité ; la discipline consiste toujours à transmettre uniquement les trois fichiers appropriés plutôt que l’ensemble du code.