Qu’est-ce que l’ingénierie du contexte ? Ce que le modèle reçoit avant de répondre

L'ingénierie de contexte est la conception de ce qu'un modèle de langage reçoit comme information au moment de l'inférence, sous quelle forme, dans quel ordre et pendant combien de temps. Elle est plus large que l'ingénierie de prompt car le contexte du modèle peut inclure des instructions système, des messages utilisateur, des documents récupérés, des résultats d'outils, de la mémoire, l'état actuel de l'application, des exemples, des données structurées et des artefacts intermédiaires. L'objectif n'est pas de maximiser le nombre de tokens, mais de construire le plus petit contexte utile qui préserve les informations, contraintes et preuves nécessaires à la tâche en cours.

Ce que signifie réellement l'ingénierie de contexte

Chaque appel au modèle s'effectue dans un environnement de travail temporaire : les instructions actuelles, les messages, les preuves récupérées, les sorties d'outils et l'état qui tiennent dans la fenêtre de contexte active. L'ingénierie de contexte est la discipline qui consiste à construire cet environnement délibérément.

Le mot clé est délibérément. Un système naïf concatène simplement tout ce qu'il possède : l'historique complet, tous les documents récupérés, chaque réponse d'outil et de grands prompts système. Un système conçu avec une ingénierie de contexte décide quelles informations sont nécessaires à la décision en cours et quelles informations doivent rester en dehors de la fenêtre jusqu'à ce qu'elles soient nécessaires.

Cela fait de l'ingénierie de contexte en partie un problème d'architecture de l'information, en partie un problème d'exécution et en partie un problème d'évaluation. La conception doit décider ce qui peut entrer dans le contexte, d'où cela vient, quelle version est actuelle, comment les conflits sont résolus, quel niveau de détail est conservé et comment le résultat est testé.

L'exemple le plus simple

Imaginez un assistant de support interne. Un utilisateur demande : « Ce client peut-il annuler sans frais ? »

Le modèle pourrait avoir besoin de cinq choses : la politique d'annulation actuelle, le type de contrat actuel du client, la date d'effet du contrat, les règles d'exception pertinentes et le périmètre d'autorisation de l'utilisateur.

Il n'a pas nécessairement besoin de toute la base de données clients, de l'intégralité des archives de politiques, de chaque conversation précédente ou de chaque ticket de support. L'ingénierie de contexte est le processus qui sélectionne et assemble les cinq éléments utiles tout en excluant les informations non pertinentes.

Où l'exemple simple s'arrête

Les systèmes réels sont plus difficiles car les informations nécessaires à une étape peuvent ne pas être connues avant le début de l'exécution. Un agent peut découvrir de nouveaux faits via des outils, créer des fichiers intermédiaires, recevoir un état externe changeant ou couvrir une tâche plus longue qu'une fenêtre de contexte.

L'ingénierie de contexte devient donc dynamique. Le contexte de l'étape 12 ne devrait pas simplement être le contexte de l'étape 1 plus onze couches de sortie accumulée. Il devrait refléter l'état actuel de la tâche, les décisions qui comptent encore et les preuves nécessaires à l'action suivante.

Qu'est-ce qui peut entrer dans un contexte de modèle ?

Ingénierie du contexte vs ingénierie du prompt

Anthropic décrit explicitement l'ingénierie du contexte comme la progression naturelle de l'ingénierie du prompt pour les systèmes dans lesquels le modèle doit travailler avec des outils, des données externes, un historique de messages et un état d'agent de longue durée. La distinction pratique est utile car un prompt parfaitement rédigé ne peut pas compenser des données autoritaires manquantes ou un contexte pollué par un état contradictoire.

Ingénierie du contexte vs récupération

La récupération sélectionne des informations candidates à partir d'un corpus ou d'une source externe. L'ingénierie du contexte décide de ce qui se passe après et autour de cette récupération.

Le récupérateur peut renvoyer 30 passages. Un reranker peut les réduire à 10. La couche de contexte peut sélectionner quatre passages, supprimer les doublons, attacher des métadonnées de source/version, les combiner avec l'état actuel de l'application et les placer après les instructions système.

C'est pourquoi un système RAG peut récupérer le bon passage et néanmoins mal répondre : l'échec peut survenir lors de l'assemblage du contexte plutôt que lors de la récupération.

Ingénierie du contexte vs mémoire

La mémoire est une information conservée en dehors de l'invocation immédiate du modèle afin de pouvoir être réutilisée plus tard. Le contexte est l'information réellement chargée dans l'invocation actuelle.

Un système de mémoire peut contenir des milliers de faits, notes ou décisions antérieures. L'ingénierie du contexte sélectionne lesquels doivent être réintroduits pour la tâche actuelle. Charger toute la mémoire à chaque tour va à l'encontre de l'objectif même de disposer d'une couche de mémoire externe.

La distinction devient cruciale pour l'état volatil. Un statut de projet ou une préférence utilisateur mémorisé peut être utile, mais l'état autoritaire actuel peut devoir être relu avant une décision conséquente.

Ingénierie du contexte vs état de l'application

L'état de l'application est la condition actuelle du système externe : solde du compte, statut du ticket, version du fichier, étape du workflow, état de déploiement ou progression de la tâche.

L'état peut être résumé dans le contexte, mais le résumé n'est pas l'état lui-même. Pour les opérations conséquentes, le runtime peut devoir relire le système autoritaire immédiatement avant l'action plutôt que de faire confiance à un instantané antérieur visible par le modèle.

La conception des outils fait partie de l'ingénierie du contexte

Les outils ne se contentent pas de donner des capacités aux agents. Les noms, descriptions, schémas et résultats des outils deviennent des informations visibles par le modèle qui façonnent les décisions.

Les recommandations actuelles d'Anthropic en matière d'ingénierie du contexte mettent l'accent sur des outils économes en tokens et avertissent contre les ensembles d'outils gonflés aux fonctionnalités qui se chevauchent. Un catalogue d'outils qu'un humain a du mal à distinguer est également difficile pour un modèle à router de manière fiable.

Les sorties d'outils nécessitent également une discipline de contexte. Renvoyer un journal complet de 20 000 lignes alors que l'agent a demandé une seule condition d'erreur consomme de l'attention et peut enterrer la preuve décisive.

Contexte juste-à-temps vs contexte préchargé

Anthropic décrit un modèle hybride dans lequel un certain contexte stable est préchargé tandis que les agents récupèrent des informations supplémentaires à l'exécution. C'est un modèle d'architecture utile car tous les faits importants ne méritent pas une résidence permanente dans la fenêtre de contexte.

Le contexte est un budget, pas un système de stockage

Une fenêtre de contexte définit une capacité. Elle ne garantit pas que chaque token sera utilisé aussi bien. Le modèle doit répartir son attention entre les instructions, l'historique, les preuves, les outils et l'état intermédiaire.

L'objectif pratique n'est donc pas de « remplir la fenêtre ». Il est de maximiser l'utilité du budget d'attention limité.

Anthropic formule un principe similaire comme la recherche du plus petit ensemble de tokens à fort signal qui maximise la probabilité du comportement souhaité. Les recommandations d'OpenAI en matière de gestion du contexte avertissent également qu'un historique non organisé, des résultats d'outils redondants et une récupération bruitée peuvent submerger même de grandes fenêtres.

Pourquoi plus de contexte peut être pire

Un contexte supplémentaire peut introduire des informations non pertinentes, un état obsolète, des preuves en double, des instructions contradictoires ou une compétition positionnelle. Il peut également amener les systèmes de compactage à écarter des détails qui deviennent importants par la suite.

L'étude classique Lost in the Middle a démontré que les modèles à long contexte peuvent utiliser les informations différemment selon l'endroit où le contenu pertinent apparaît, les performances se dégradant souvent lorsque des informations décisives sont placées au milieu de longues entrées.

Cela ne signifie pas que le contexte long est intrinsèquement mauvais. Cela signifie que la disponibilité dans la fenêtre n'est pas la même chose qu'une utilisation fiable.

L'ordre du contexte doit être intentionnel

La construction du contexte est aussi un problème d'ordre. Les instructions critiques, l'état actuel, les preuves décisives et les contraintes spécifiques à la tâche ne doivent pas être concaténés arbitrairement.

Il n'existe pas d'ordre parfait universel pour chaque modèle et chaque tâche. L'architecture doit donc tester si la réorganisation des preuves change l'exactitude et si les informations importantes restent robustes à travers des variations de contexte réalistes.

Une réponse stable qui change radicalement lorsque deux passages également valides échangent leurs positions indique une sensibilité au contexte qui devrait être mesurée plutôt qu'ignorée.

Un contexte conflictuel nécessite une préséance explicite

Un modèle peut recevoir une ancienne politique et une nouvelle politique, une préférence mémorisée et une instruction explicite actuelle, ou un statut mis en cache et un résultat d'API en direct. Le système ne devrait pas s'attendre à ce que le modèle déduise la préséance à partir du style de la prose.

L'ingénierie du contexte devrait encoder la préséance par la sélection des sources, les métadonnées, l'ordre ou des instructions explicites : l'état actuel faisant autorité prime sur les copies obsolètes ; une instruction explicite actuelle de l'utilisateur prime sur une préférence plus ancienne inférée ; une politique approuvée supplante les brouillons obsolètes.

La compaction est une transformation du contexte, pas un stockage sans perte

Les systèmes de longue durée finissent par devoir réduire, résumer ou compacter l'historique. La compaction crée une nouvelle représentation du contexte antérieur afin que l'agent puisse continuer sans rejouer chaque token.

Les exemples de gestion du contexte d'OpenAI utilisent la réduction et la compression pour les sessions de longue durée. Anthropic décrit la compaction comme une technique principale pour maintenir la cohérence lorsqu'une interaction approche de la limite de contexte.

La partie difficile consiste à décider ce qui ne peut pas être supprimé en toute sécurité : les tâches non résolues, les identifiants, les contraintes de l'utilisateur, les frontières de sécurité, les décisions d'architecture, les exceptions, la provenance des sources et les conditions qui rendent une conclusion précédente valide.

Préserver les limites de validité

Les conclusions importantes devraient porter les conditions dans lesquelles elles restent étayées : version, date, portée, hypothèses, autorité de la source et désaccord non résolu.

L'ingénierie du contexte est donc liée à la Frontière de Validité des Réponses. L'assembleur de contexte ne devrait pas supprimer les métadonnées qui déterminent si les preuves s'appliquent encore.

L'ingénierie du contexte est aussi une frontière de sécurité

Les données qui atteignent le modèle ont franchi une frontière système importante. L'assemblage du contexte doit donc respecter les règles d'autorisation, d'isolation des locataires, de confidentialité et de minimisation des données.

Un récupérateur peut techniquement trouver un passage auquel l'utilisateur actuel ne peut pas accéder. La conception correcte consiste à empêcher ce passage d'entrer dans le contexte du modèle plutôt que de compter sur le modèle pour l'ignorer.

Les sorties d'outils peuvent également contenir des instructions non fiables ou du contenu adversarial. L'ingénierie du contexte devrait préserver la distinction entre les instructions de l'application et les données externes afin que le texte récupéré ne puisse pas acquérir silencieusement une autorité d'instruction.

Une architecture pratique d'ingénierie de contexte

L'assembleur de contexte est conceptuellement important même lorsqu'aucun module ne porte exactement ce nom. Dans une petite application, il peut s'agir de code applicatif ordinaire. Dans une grande plateforme d'agents, il peut combiner la gestion de session, la récupération, la mémoire, l'intergiciel d'outils, la compaction et l'application des politiques.

Une politique pratique de construction de contexte

Comment évaluer l'ingénierie de contexte

L'assemblage de contexte est une couche de défaillance RAG distincte

Un pipeline RAG peut réussir la récupération et échouer en aval. La source pertinente peut apparaître au rang 2, mais l'assembleur de contexte peut la supprimer, la tronquer, la combiner avec des éléments contradictoires obsolètes ou dépasser le budget de tokens.

C'est pourquoi les traces de récupération doivent être comparées au contexte réel envoyé au modèle. Sans cette comparaison, les défaillances de contexte sont facilement diagnostiquées à tort comme des défaillances d'embedding ou de modèle.

Preuves d'implémentation originales

Source of Truth Research Engine : une recherche bornée au lieu d'un contexte illimité

Le Source of Truth Research Engine sépare la découverte, l'acquisition, l'extraction, la vérification, l'analyse des contradictions et la synthèse en étapes de recherche bornées, au lieu d'envoyer une seule énorme tâche de recherche et tout le matériel accumulé dans un unique appel au modèle.

Son modèle de preuves stocke les Sources, Artefacts, Affirmations, Relations, Contradictions et la provenance en dehors du contexte du modèle. Le modèle peut recevoir le sous-ensemble nécessaire à l'étape de recherche en cours, tandis que les preuves durables restent dans le stockage externe.

C'est un modèle concret d'ingénierie de contexte : l'état de recherche durable vit en dehors de la fenêtre du modèle ; le contexte actif du modèle est reconstruit pour l'étape en cours.

Aaasaasa AI Client : l'exécution, les permissions et le contexte sont des préoccupations distinctes

Aaasaasa AI Client sépare la sélection du fournisseur et du modèle, l'emplacement d'exécution, les autorisations de l'espace de travail, les ressources locales et l'accès aux outils. Cela empêche le contexte du modèle de devenir le propriétaire de l'autorisation ou de l'état de l'application.

Le chat direct et les environnements d'exécution agentiques peuvent avoir des capacités d'outils différentes. Les profils d'autorisation de l'espace de travail sont appliqués par l'environnement d'exécution plutôt que simplement décrits dans un contexte en langage naturel. Cette distinction est importante : le contexte peut indiquer à un modèle ce qu'il devrait faire, tandis que l'environnement d'exécution doit toujours appliquer ce qu'il est réellement autorisé à faire.

Les preuves de mise en œuvre ici relèvent de la séparation architecturale, et non de l'affirmation que chaque technique avancée de gestion du contexte décrite dans cet article est déjà implémentée.

Modes de défaillance courants de l'ingénierie du contexte

Idées fausses courantes

Une séquence pratique d'ingénierie du contexte

Liste de contrôle d'ingénierie du contexte

Cas limites et limitations

Certaines tâches sont assez simples pour que l'ingénierie du contexte se réduise à un court prompt système et un seul message utilisateur. Ajouter la récupération, la mémoire et la compaction n'introduirait qu'une architecture inutile.

Certaines tâches nécessitent un rappel élevé et peuvent intentionnellement inclure plus de contexte avant une synthèse ultérieure. La recherche, la découverte et l'examen juridique peuvent préférer éviter les omissions plutôt que minimiser le nombre de tokens.

Certaines informations ne devraient jamais être résumées avant utilisation. Les contrats exacts, le code, le matériel cryptographique, les enregistrements numériques et les textes réglementaires peuvent nécessiter une récupération verbatim ou structurée lorsque la compression pourrait altérer le sens.

Le comportement en contexte long varie considérablement d'un modèle à l'autre. Une stratégie validée sur un modèle, une longueur de contexte ou un harnais d'outils ne devrait pas être automatiquement transférée à un autre.

Le modèle peut encore ignorer ou mal interpréter un excellent contexte. L'ingénierie de contexte améliore l'environnement informationnel ; elle ne garantit pas l'exactitude du raisonnement.

Qu'est-ce qui pourrait changer cette réponse ?

Les futurs modèles pourraient devenir plus robustes face aux contextes longs, aux effets de position et aux informations contradictoires. Cela pourrait réduire la quantité de curation manuelle nécessaire.

La distinction architecturale resterait néanmoins utile car les permissions, la fraîcheur, la persistance de la mémoire, l'autorité des sources et l'état des applications externes existent en dehors du modèle, indépendamment de la taille de la fenêtre de contexte.

L'équilibre recommandé entre contexte préchargé et contexte juste-à-temps évolue également avec les exigences de latence, la fiabilité des outils, la taille du corpus, le coût du modèle et le degré de dynamicité des informations sous-jacentes.

Connaissances canoniques associées

L'ingénierie de contexte se situe entre la récupération et la génération. Le RAG explique comment les connaissances externes sont récupérées ; R01 distingue les embeddings, la recherche vectorielle et le reranking ; l'ingénierie de contexte explique ce qui parvient finalement au modèle.

L'architecture de source de vérité répond à une question différente : non pas quelles informations sont présentes dans le contexte, mais quelle source est autorisée à établir une affirmation.

L'article existant Pourquoi plus de contexte peut dégrader les réponses de l'IA est le complément diagnostique de cette définition canonique. Il se concentre sur la pollution du contexte, les effets de position, la croissance du top-k, la perte due à la compaction et la dégradation des réponses plutôt que de redéfinir l'ingénierie de contexte elle-même.

Questions fréquentes

Glossaire

Conclusion

L'ingénierie de contexte est la couche qui décide ce que le modèle peut voir avant de répondre. Cela la rend plus large que le prompting et en aval de la récupération, tout en restant distincte de la mémoire durable et de l'état faisant autorité de l'application.

Une architecture de contexte solide ne traite pas la fenêtre de contexte comme une base de données. Elle conserve l'état durable et les connaissances en dehors du modèle, charge ce qui est nécessaire à la décision en cours, préserve l'autorité et la provenance, élimine le bruit inutile et actualise les informations volatiles lorsque nécessaire.

L'objectif pratique n'est donc pas un contexte maximal. C'est un contexte minimal suffisant, à fort signal, correctement autorisé et préservant la validité pour la prochaine décision du modèle.

Sources primaires et recommandations actuelles

Les sources ci-dessous étayent la terminologie actuelle de l'ingénierie de contexte, le comportement en contexte long et les modèles opérationnels de gestion du contexte. Les sections du projet constituent explicitement des preuves de mise en œuvre plutôt que des affirmations universelles.