Ingénierie du contexte : sélectionner et maintenir les informations reçues par un système d’IA

Définition : concevoir les informations disponibles pour une tâche

L’ingénierie du contexte consiste à concevoir et à gérer les informations présentées à un modèle d’IA pendant une exécution afin de l’aider à accomplir une tâche donnée. Le contexte peut inclure des instructions, le message de l’utilisateur, des éléments de l’historique, des exemples, des résultats d’outils, des documents récupérés et des données sur l’état actuel du travail. La décision centrale ne porte donc pas seulement sur ce qu’il faut dire au modèle, mais aussi sur les informations à inclure, leur forme, le moment où les fournir et les limites à leur appliquer.

Le terme est employé dans un domaine en évolution et ne fait pas l’objet d’une définition formelle universellement admise par toutes les disciplines et tous les fournisseurs. Il est plus juste de le considérer comme une appellation pratique désignant un ensemble de décisions techniques observables : réunir des informations, choisir les éléments pertinents, les organiser en fonction de la tâche et les mettre à jour lorsque les résultats ou l’état du système changent. Le nom, à lui seul, ne garantit pas qu’un système applique une méthode particulière ni qu’il améliore ses performances.

Dans une conversation simple, le contexte peut se composer principalement d’instructions et de messages. Dans une application qui récupère des documents ou utilise des outils, il peut aussi comprendre des résultats externes. Pour un agent qui travaille en plusieurs étapes, certaines informations peuvent être conservées en dehors de la conversation puis réintroduites au moment opportun. Dans tous les cas, l’élément déterminant est le contenu effectivement accessible au modèle pendant cette exécution.

Quels éléments peuvent entrer dans le contexte ?

Les instructions définissent le rôle, les limites ou le format attendu. Le message de l’utilisateur exprime le besoin immédiat. L’historique peut apporter des éléments sur des décisions antérieures, à condition qu’ils restent pertinents. Les exemples illustrent des modèles de réponse ou de résolution, mais leur utilité dépend de leur représentativité par rapport à la tâche.

Les documents récupérés et les résultats d’outils apportent des informations externes au message initial. Un outil peut, par exemple, renvoyer le contenu d’un fichier ou le résultat d’une recherche. L’état du travail peut indiquer ce qui a déjà été fait, ce qu’il reste à faire et quel résultat doit être conservé pour l’étape suivante. Ces éléments ne sont pas toujours nécessaires : les inclure sans raison consomme de l’espace et peut ajouter du bruit.

Le contexte n’est pas nécessairement un texte unique rédigé par une personne. Il peut s’agir d’un assemblage préparé par une application avant chaque appel au modèle. Une partie peut provenir d’une requête ; une autre, d’une source de données, d’une recherche, de l’historique ou d’une opération antérieure. Examiner uniquement le prompt visible par l’utilisateur ne permet donc pas toujours de savoir quelles informations le modèle a reçues.

Comment fonctionne le cycle d’ingénierie du contexte ?

Une stratégie de contexte peut être envisagée comme un cycle. Il faut d’abord déterminer ce dont la tâche a besoin : répondre à une question, modifier un fichier ou comparer des sources, par exemple. On rassemble ensuite les informations disponibles dans le message, l’historique, les documents, les outils ou une mémoire externe. Toutefois, recueillir des données ne signifie pas qu’il faille toutes les inclure : il faut sélectionner les éléments pertinents, vérifier qu’ils sont à jour et écarter ceux qui ne contribuent pas à la tâche.

Vient ensuite l’organisation et la transformation du contenu. Il peut être nécessaire d’extraire des passages, de résumer des résultats, de distinguer les faits des questions encore ouvertes ou de structurer l’état du travail. Les éléments retenus sont ensuite ajoutés au contexte présenté au modèle. Après sa réponse ou son action, le système peut vérifier le résultat et mettre à jour l’état : conserver une découverte utile, remplacer des informations périmées ou rechercher ce qui manque encore.

Ce processus se répète tant que la tâche se poursuit. La stratégie adaptée dépend de la tâche, des sources et des capacités du système ; aucune recette ne garantit un résultat correct. Une sélection médiocre peut écarter une information décisive. À l’inverse, un contexte trop chargé peut empêcher le modèle de repérer l’essentiel. Il est donc préférable de concevoir le cycle à partir de besoins précis et d’observer quelles informations le système utilise.

Exemple pratique : un agent de programmation

Imaginons qu’une personne demande de corriger un bogue dans une application. Charger d’emblée tous les fichiers du projet peut être inutile. Une stratégie plus sélective commence par examiner le message d’erreur et repérer les composants probablement concernés. Le système peut consulter des fichiers, des tests et de la documentation au moyen d’outils, puis fournir au modèle les passages pertinents ainsi que les contraintes de la modification demandée.

Après une modification, les résultats des tests ou les sorties des outils peuvent être ajoutés au contexte de l’étape suivante. Si le travail doit se poursuivre à une autre étape, une note d’état peut résumer l’objectif, les décisions prises, les fichiers modifiés et les tâches restantes. Cette note n’est qu’une représentation partielle du travail : ce n’est ni une transcription complète ni une garantie qu’aucun détail n’a été perdu.

Cet exemple montre pourquoi la gestion du contexte peut inclure à la fois des recherches effectuées à la demande et la conservation d’informations entre plusieurs étapes. Les systèmes décrits pour des agents de longue durée utilisent des mécanismes de transfert et un état externe afin de poursuivre le travail lorsqu’une seule fenêtre de contexte ne suffit pas. Leur mise en œuvre précise dépend de l’agent.

Exemple pratique : un assistant de service client

Dans un assistant de service client, la question d’une personne peut être combinée à la politique en vigueur qui s’applique à son cas et à une partie pertinente de son historique, si cet accès est autorisé. Pour connaître l’état d’un remboursement, par exemple, le système peut avoir besoin de la demande actuelle, de la règle applicable et de la donnée de commande nécessaire pour identifier la transaction. Cet exemple est illustratif : les sources disponibles ne décrivent pas un système de service client précis configuré de cette manière.

La sélection doit également limiter l’accès au strict nécessaire. Si une donnée personnelle ne contribue pas à résoudre la demande, rien ne justifie de l’ajouter par défaut au contexte. L’application doit déterminer quelles informations elle peut récupérer, qui peut y accéder et combien de temps elles doivent être conservées. Ces décisions relatives à la confidentialité et aux autorisations relèvent de la conception du système ; elles ne se règlent pas simplement en ajoutant des instructions au modèle.

L’assistant doit aussi distinguer une politique en vigueur des anciens messages susceptibles d’être dépassés. Si la réponse dépend d’une règle actuelle, les informations récupérées doivent pouvoir être vérifiées auprès d’une source autorisée. La présence d’un document dans le contexte ne prouve pas, à elle seule, qu’il est exact, à jour ou applicable au cas.

Exemple pratique : un agent de recherche

Un agent de recherche peut répartir une question complexe en plusieurs axes de travail et conserver séparément les documents rassemblés pour chacun d’eux. Au lieu de présenter tous les documents au même modèle à chaque étape, il peut classer les sources et les découvertes par thème, puis transmettre au coordinateur une synthèse qui renvoie aux éléments pertinents et recense les questions encore ouvertes.

Une synthèse facilite le passage d’une étape à l’autre, mais elle peut omettre des nuances ou des réserves. L’état du travail devrait donc distinguer ce qui a été observé dans les sources, ce qui relève d’une interprétation et ce qui reste à vérifier. Si une conclusion dépend d’un détail, il peut être nécessaire de revenir au document d’origine plutôt que de se fier uniquement à un résumé.

Le système de recherche multiagent décrit par Anthropic fournit un exemple d’organisation du travail entre des agents aux contextes séparés, avec une synthèse des découvertes transmise à un agent coordinateur. Il s’agit d’un cas concret de conception, et non d’une preuve que la même architecture est supérieure pour tous les travaux de recherche.

Notions voisines : prompt, RAG, découpage, mémoire et fenêtre de contexte

L’ingénierie des prompts se concentre principalement sur la rédaction et l’organisation des instructions qui orientent la réponse du modèle. L’ingénierie du contexte a une portée plus large : elle prend également en compte la manière de rassembler, sélectionner, organiser et mettre à jour les autres informations disponibles. Les deux pratiques peuvent se recouper. Une bonne instruction fait partie du contexte, mais elle ne détermine pas à elle seule quels documents récupérer ni quel état conserver.

La génération augmentée par récupération, ou RAG, combine récupération d’informations et génération. Elle peut servir à obtenir des documents à intégrer au contexte, mais elle n’est pas synonyme d’ingénierie du contexte. Même avec du RAG, un système doit décider quoi récupérer, quels passages inclure et comment traiter les résultats. Il est également possible de gérer le contexte sans système RAG.

Le découpage, ou « chunking », consiste à diviser des documents ou d’autres contenus en unités afin de les stocker, de les récupérer ou de les traiter. Il influe sur les portions qui peuvent parvenir au modèle, mais ne suffit pas à déterminer si elles sont pertinentes ni comment les combiner avec les instructions et l’historique. La mémoire désigne, quant à elle, des mécanismes de conservation et de récupération d’informations entre différents moments ou différentes tâches. Avant d’intégrer au contexte un élément récupéré depuis cette mémoire, le système doit évaluer s’il reste pertinent.

La fenêtre de contexte est la limite de la quantité d’informations qu’un modèle peut traiter au cours d’une exécution, selon les caractéristiques du système. Elle ne constitue pas une stratégie de sélection : une fenêtre plus grande ne détermine pas quoi inclure et ne garantit pas que chaque élément recevra la même attention. Le cache peut réutiliser du contenu ou des résultats de traitement pour éviter des opérations répétées, mais il ne répond pas non plus à la question de savoir quelles informations sont nécessaires à une tâche.

Erreurs fréquentes et limites

Une erreur courante consiste à supposer qu’un contexte plus riche est toujours préférable. Des expériences portant sur des modèles à long contexte ont observé que leur capacité à utiliser une information peut varier en fonction de l’endroit où se trouve l’élément pertinent. Augmenter la quantité de texte ou la taille de la fenêtre ne garantit donc pas que le modèle repérera ou exploitera mieux l’information nécessaire.

Une autre erreur consiste à confondre information disponible et information utilisée. Le fait qu’un document ait été ajouté au contexte ne prouve pas qu’il a correctement influencé la réponse. De même, un résumé ne conserve pas nécessairement toutes les nuances de l’original. La compression peut faire disparaître des conditions, des exceptions ou des désaccords ; les détails décisifs devraient pouvoir être vérifiés à partir de la source.

Le contenu récupéré peut aussi être incomplet, hors sujet ou périmé. En outre, des documents et des pages Web peuvent contenir des instructions malveillantes destinées à l’agent. Si le système traite ce contenu comme des instructions fiables, il peut être amené à s’écarter de sa tâche. L’injection de prompt constitue un risque associé à l’intégration de contenu non fiable ; les mesures de défense doivent être testées et ne peuvent être tenues pour efficaces au seul motif qu’elles existent.

La sélection du contexte implique également des arbitrages entre coût, latence et confidentialité. Récupérer ou traiter davantage d’informations peut accroître le travail nécessaire, tandis que transmettre des données inutiles élargit leur exposition. Il n’existe pas de quantité universelle de contexte qui convienne à toutes les situations : le choix dépend de la tâche, de la qualité des sources, des contraintes du système et des erreurs que l’on souhaite éviter.

Comment évaluer une stratégie ?

Pour déterminer si une stratégie est utile, il est préférable de définir des tâches de test représentatives et de préciser à l’avance ce qui constitue un résultat acceptable. On peut ensuite comparer différentes variantes : par exemple, examiner les effets d’une récupération de moins de documents, d’un autre ordre de présentation des éléments ou d’un résumé d’état plus explicite. Dans la mesure du possible, il vaut mieux ne modifier qu’un seul choix à la fois afin de faciliter l’interprétation.

L’évaluation peut porter sur la qualité des réponses ou des actions, les omissions d’informations pertinentes, les erreurs de sélection, la latence, le coût et la quantité ou la sensibilité des données incluses. Pour les systèmes utilisant des documents, il est également important de vérifier si les réponses s’appuient sur des sources applicables et à jour. Les résultats doivent être interprétés au regard des tâches et des données de test employées : ils ne démontrent pas automatiquement que la stratégie fonctionnera dans d’autres situations.

Pour attribuer une amélioration à la gestion du contexte, il faut comparer les résultats de manière systématique et maintenir, autant que possible, le modèle et les autres conditions pertinentes constants. Une impression anecdotique ou une réponse qui paraît convaincante ne suffit pas à établir un lien de cause à effet. En cas d’erreur, examiner ce qui a été récupéré, ce qui a été omis et ce qui est effectivement parvenu au modèle peut aider à en localiser l’origine.

Principes pratiques et notions connexes

Pour concevoir un système, commencez par préciser la tâche et les informations susceptibles de modifier la réponse ou l’action. Ne récupérez que des données provenant de sources autorisées, sélectionnez les éléments pertinents et prévoyez un moyen de consulter les documents originaux lorsqu’une synthèse ne suffit pas. Mettez l’état à jour à mesure que de nouveaux éléments apparaissent, plutôt que d’accumuler indéfiniment un historique qui n’est peut-être plus utile.

Testez ensuite la conception sur des situations habituelles et des cas limites : sources contradictoires, informations périmées, demandes ambiguës ou documents contenant des instructions sans rapport avec la tâche. Vérifiez ce qui parvient au modèle, ce qui en est exclu et le résultat obtenu. Si le système échoue, ne partez pas du principe qu’il lui faut davantage de contexte : recherchez plutôt si le problème tient à la récupération, à la sélection, à l’organisation, à l’actualité des données ou à l’interprétation du modèle.

Pour approfondir le vocabulaire, consultez dans le glossaire les entrées consacrées à l’ingénierie des prompts, au RAG, au découpage ou « chunking », à la mémoire, ainsi que l’entrée générale du glossaire. La distinction pratique est simple : le prompt porte surtout sur les instructions ; le RAG sur la récupération d’informations en vue de générer ; le découpage sur la division des contenus ; la mémoire sur la conservation et la récupération de l’état. L’ingénierie du contexte s’intéresse à la manière de combiner ces éléments pour une exécution donnée.

Concepts associés