Qu'est-ce que l'ingénierie contextuelle ?

L’invite système définit le contexte fondamental de l’agent  : son identité, ses capacités, ses contraintes et ses règles de comportement. Contrairement aux invites utilisateur, qui varient à chaque interaction, l’invite système reste relativement stable. Elle agit comme une « personnalité » persistante et un référentiel de règles. Une invite système efficace repose sur un équilibre entre trois exigences souvent contradictoires : la précision (pour éviter les comportements ambigus), la flexibilité (pour s’adapter à une grande diversité de cas),la brièveté (pour limiter l’encombrement de la fenêtre de contexte). Quelques bonnes pratiques à suivre :

• Définir clairement le rôle de l’agent (ex. : « Vous êtes un assistant spécialisé en analyse financière… »)
• Fournir des exemples concrets de comportements attendus plutôt que des règles abstraites
• Utilisation de délimiteurs structurés (balises XML, sections Markdown) pour organiser les instructions afin d'améliorer la compréhension du modèle
• Positionner les contraintes critiques (ex. : règles de sécurité, exigences de format) dès le début, car les modèles sont sensibles à l’ordre des instructions

Parmi les techniques avancées, on trouve les instructions conditionnelles, qui s’activent selon le contexte d’exécution (par exemple : « Si l’utilisateur pose une question sur les données personnelles, rediriger vers la politique de confidentialité »), ainsi que les méta-instructions, qui orientent le raisonnement de l’agent (par exemple : « Réfléchissez étape par étape avant de fournir une analyse »). Parmi les techniques avancées, on trouve les instructions conditionnelles, qui s’activent selon le contexte d’exécution (par exemple : « Si l’utilisateur pose une question sur les données personnelles, rediriger vers la politique de confidentialité »), ainsi que les méta-instructions, qui orientent le raisonnement de l’agent (par exemple : « Réfléchissez étape par étape avant de fournir une analyse »).

La mémoire à long terme permet à une IA de conserver des informations sur plusieurs sessions ou conversations. Contrairement à la mémoire à court terme, qui est éphémère et perdue à la fin d’une session, la mémoire à long terme permet à une IA de se souvenir des préférences utilisateur, des interactions passées et des faits appris, pour y faire référence plus tard.

L’état et l’historique de la session constituent la mémoire de travail de l’agent : il s’agit de l’enregistrement de ce qui a été dit, fait et appris au cours d’une interaction en cours. Cette mémoire à court terme assure la continuité de la conversation : l’agent peut se référer aux échanges précédents sans forcer l’utilisateur à répéter le contexte. Cependant, l’historique de la conversation croît linéairement avec la durée des interactions, ce qui consomme rapidement l’espace disponible dans la fenêtre de contexte.

Une ingénierie du contexte efficace repose sur des stratégies actives de gestion de la mémoire. La fonction de résumé compresse les échanges plus anciens en représentations synthétiques, tout en conservant les faits et décisions clés. Le fenêtrage consiste à ne conserver que les N derniers messages, en supprimant l’historique plus ancien, partant du principe que le contexte récent est le plus pertinent. La rétention sélective repose sur des heuristiques pour identifier et conserver les informations essentielles (préférences utilisateur, faits établis, questions en suspens), tout en supprimant les échanges accessoires ou répétitifs.

Les approches les plus avancées s’appuient sur des structures de mémoire épisodique, dans lesquelles l’agent consigne des états importants dans un stockage externe, pour les retrouver à la demande. Cela imite la façon dont les humains ne retiennent pas l’intégralité d’une conversation dans leur mémoire de travail, mais sont capables de rappeler certains détails au moment opportun. Le défi principal reste la cohérence : un filtrage trop agressif peut conduire l’agent à « oublier » des éléments essentiels du contexte et à répéter les mêmes erreurs, tandis qu’une compression insuffisante risque de saturer la fenêtre de contexte et de nuire aux performances.

La génération augmentée par récupération (RAG, pour Retrieval Augmented Generation) consiste à permettre à l’IA de récupérer, « juste à temps », des données externes issues d’une base de connaissances – comme des documents internes à l’entreprise ou des sites publics. RAG permet à l’IA de répondre à des questions en s’appuyant sur des informations qui ne faisaient pas partie de son entraînement initial, garantissant ainsi des réponses à jour et pertinentes.

La segmentation sémantique améliore la pertinence des résultats en structurant l’information de manière logique. Plutôt que de découper le texte en fragments arbitraires et de taille fixe, la segmentation sémantique regroupe les concepts liés (par exemple : par paragraphe, par fonction ou par section logique). Lorsqu’un fragment pertinent est récupéré, son environnement immédiat est également inclus. Cela permet au modèle de langage de bénéficier d’un contexte plus cohérent et plus complet, ce qui améliore son raisonnement et limite les erreurs dues à une information fragmentée.

La recherche hybride est essentielle en ingénierie du contexte, car s’appuyer sur une seule méthode de récupération d’information se révèle souvent insuffisant. La recherche vectorielle est particulièrement efficace pour identifier des contenus similaires sur le plan conceptuel (par exemple, « vêtements d’été » renverra vers « tenues par temps chaud »), mais peut passer à côté de termes précis ou spécifiques. La recherche par mots-clés (comme BM25), quant à elle, excelle dans la correspondance exacte (ex. : « SKU-123AB »), mais ne gère pas bien les synonymes. En combinant ces deux approches dans une requête unifiée, la recherche hybride garantit que le modèle de langage accède à un contexte à la fois précis et équilibré, qui reflète l’intention conceptuelle de l’utilisateur tout en capturant les mots-clés critiques.

Le reclassement (ou reranking) permet de résoudre le compromis classique entre vitesse et précision dans les systèmes de récupération à grande échelle. La recherche initiale (comme la recherche hybride) est optimisée pour extraire rapidement un grand nombre de documents potentiellement pertinents (par exemple, les 100 meilleurs résultats). Un modèle de reclassement — généralement plus coûteux en calcul mais nettement plus précis — est ensuite utilisé pour réévaluer uniquement ce sous-ensemble restreint. En ingénierie du contexte, cette étape est cruciale, car elle garantit que les extraits les plus pertinents et de meilleure qualité figurent tout en haut de la fenêtre de contexte. C’est essentiel pour atténuer le problème du « contenu perdu au milieu » et concentrer l’attention du modèle sur les informations les plus utiles.

Les outils étendent les capacités d’un agent au-delà de la génération de texte, en lui permettant d’interagir avec des systèmes externes : exécuter du code, interroger des bases de données, appeler des API ou manipuler des fichiers. Du point de vue de l’ingénierie du contexte, cela pose un défi spécifique : chaque outil doit être décrit (nom, objectif, paramètres, exemples d’utilisation), ce qui consomme de l’espace dans la fenêtre de contexte. À mesure que les bibliothèques d’outils s’élargissent, cette « surcharge contextuelle des outils » devient un facteur important. Un agent doté de 100 outils peut consacrer jusqu’à 30 %–40% de sa fenêtre de contexte uniquement à la description de ses capacités – avant même de commencer la tâche demandée par l’utilisateur.

L'ingénierie efficace des outils suit plusieurs principes :

• Restez concis sans ambiguïté dans la description des outils : indiquez leur objectif, les paramètres requis avec leur type, ainsi qu’un exemple d’utilisation représentatif.
• Concevez des outils modulables : des outils simples et ciblés (par exemple : « rechercher_des_documents », « résumer_texte ») se combinent plus facilement que des outils monolithiques censés couvrir plusieurs scénarios.
• Mettez en place des catégories ou des espaces de noms pour permettre un chargement sélectif : un agent dédié à l’analyse financière n’a pas besoin d’outils de traitement d’image.
• Utilisation du filtrage des résultats des outils : ne retourne que les informations essentielles à l’agent, pas les réponses brutes de l'API. Un outil de requête de base de données devrait renvoyer « 3 transactions pertinentes trouvées pour un total de 4 532 $ » plutôt que des ensembles de résultats SQL complets.

Des outils bien conçus incluent également la gestion des erreurs dans leur description, afin d’apprendre à l’agent à se remettre proprement d’un échec plutôt que de propager des erreurs tout au long du processus.

Recherche agentique

La recherche agentique est un outil spécialisé de type « sous-agent » qui effectue une exploration complexe en plusieurs étapes dans un contexte isolé. Par exemple, elle peut traduire une requête en langage naturel en une requête ESQL précise, rechercher les données, puis renvoyer uniquement un résumé concis à l’agent principal, tout en maintenant sa mémoire de travail propre.

Workflows spécifiques à un domaine

Les workflows spécifiques à un domaine sont des chaînes d’outils prédéfinies et déterministes, conçues pour des processus métier critiques, où la fiabilité et la cohérence priment sur la flexibilité exploratoire. Contrairement aux agents généralistes qui raisonnent dynamiquement à chaque étape, ces workflows suivent une séquence stricte et validée. Exemple : « Vérifier l’identité du client → Consulter l’historique de crédit → Contrôle réglementaire externe → Calculer le score de risque → Générer le rapport de conformité. » Chaque étape est associée à des critères de réussite explicites, des mécanismes de gestion des erreurs et, si nécessaire, des procédures de retour arrière.

Cette rigidité est volontaire : elle vise à éviter que l’imprévisibilité propre au raisonnement des modèles de langage n’impacte des opérations critiques comme les validations financières, les diagnostics médicaux ou la conformité réglementaire. D’un point de vue ingénierie du contexte, les workflows spécifiques à un domaine simplifient la tâche de l’agent en réduisant les degrés de liberté. L’agent n’a pas besoin de connaître tous les outils et stratégies possibles, uniquement les informations nécessaires à l’étape en cours du workflow. Ce contexte ciblé améliore à la fois la précision et l’efficacité.

La mise en œuvre repose généralement sur des machines à états ou des graphes orientés acycliques (DAG), où le modèle de langage gère les éléments variables (analyse des requêtes utilisateur, sélection des sources de données, génération de résumés en langage naturel), tandis qu’une logique déterministe contrôle le déroulement global du processus. Le compromis ? Une adaptabilité réduite : ces workflows excellent dans les scénarios connus, mais peinent à gérer les cas limites qui sortent du cadre prédéfini.

Découverte dynamique d'outils

La découverte dynamique d’outils permet de résoudre le problème de « surcharge des invites » qui survient lorsque les agents ont accès à de vastes bibliothèques d’outils. Plutôt que d’énumérer des centaines de descriptions d’outils dans l’invite système — ce qui consomme un espace précieux dans la fenêtre de contexte et nuit à la précision de la sélection — cette approche utilise la recherche sémantique sur les métadonnées des outils pour ne récupérer, à l’exécution, que les capacités réellement pertinentes.

Lorsqu’un agent reçoit une tâche, il interroge un registre d’outils en utilisant la description de cette tâche comme requête, afin de récupérer les 3 à 5 outils les plus pertinents sur le plan sémantique pour ce contexte spécifique. Cette approche fonctionne comme une récupération de données just-in-time : les outils restent stockés à l’extérieur jusqu’à ce qu’ils soient nécessaires, ce qui permet à l’agent de concentrer son attention sur les capacités utiles plutôt que de la disperser sur un catalogue exhaustif. Des protocoles comme MCP (Model Context Protocol) normalisent ce fonctionnement en fournissant des registres dans lesquels les outils peuvent être découverts, compris et appelés dynamiquement. Cela dit, la découverte dynamique introduit une certaine latence (liée à la recherche elle-même) et nécessite une ingénierie rigoureuse pour éviter que l’agent ne sélectionne des outils inadaptés ou ne suive des pistes inutiles en cas de description trop vague.

L’invite utilisateur correspond à l’entrée directe qui déclenche le comportement de l’agent et définit le contexte immédiat de la tâche. Contrairement à l’invite système (relativement stable), l’invite utilisateur varie à chaque interaction et bénéficie du poids d’attention le plus élevé dans la plupart des architectures de modèles de langage. Ce biais de position implique que les invites utilisateur ont souvent la priorité sur les informations contradictoires présentes ailleurs dans le contexte.

Une ingénierie du contexte efficace considère les invites utilisateur comme bien plus que de simples questions : elles peuvent inclure des indices contextuels explicites (horodatages, préférences utilisateur, état de session) qui orientent la récupération d’informations et la sélection d’outils, sans alourdir l’invite système. Pour les agents à état (stateful), l’invite utilisateur devient le point d’entrée où s’injectent les informations propres à la session — par exemple : « compte tenu de notre discussion sur les indicateurs trimestriels… » indique à l’agent de privilégier les données financières récemment consultées. Cependant, les invites utilisateur représentent aussi l’élément de contexte le plus imprévisible : elles peuvent être ambiguës, contradictoires, voire hostiles. L’ingénierie du contexte doit intégrer cette variabilité à travers des modèles de compréhension des requêtes capables de reformuler les demandes floues, des filtres de sécurité pour détecter les tentatives d’injection, ainsi que des stratégies de repli lorsque l’intention ne peut être déduite de manière fiable à partir de la seule entrée.

La sortie structurée fait référence aux informations qu'une IA doit formater d'une manière spécifique, comme du JSON, du XML ou un tableau. En définissant une sortie structurée, les réponses de l'IA peuvent être cohérentes et facilement utilisées par d'autres programmes ou systèmes.

Pour approfondir ces concepts, consultez l’article complet sur notre blog : Vue d’ensemble de l’ingénierie du contexte.

L’ingénierie du contexte se conçoit avant tout comme la conception d’un pipeline systématique destiné à soutenir le modèle de langage (LLM). Plutôt que d’assembler des composants de manière ponctuelle, ce pipeline est pensé pour une tâche spécifique et vise à orchestrer l’ensemble du flux d’informations entrant et sortant du modèle à chaque étape du cycle. Ce pipeline s’articule généralement autour de trois phases clés :

1. Récupération et génération du contexte :cette première étape consiste à collecter activement des données brutes issues de sources variées : récupération de documents dans une base vectorielle, requêtes sur une base SQL structurée, appels API vers des services externes, etc.
2. Traitement du contexte : une fois les données collectées, il s’agit de les optimiser. Cela passe par la transformation de l’information pour en maximiser le rapport signal/bruit, à l’aide de techniques comme la segmentation, le résumé, la compression ou la structuration.
3. Gestion du contexte : cette dernière phase détermine comment l’information est stockée, actualisée et réutilisée au fil des interactions. Elle est essentielle pour construire des applications à état (stateful) et repose sur des stratégies adaptées à la mémoire de court terme (session) comme à la mémoire de long terme (persistante).

La stratégie la plus puissante consiste à conserver l’information en dehors de la fenêtre de contexte, et à la récupérer « juste à temps » lorsque l’agent en a besoin. C’est d’ailleurs ainsi que fonctionnent les humains : nous ne mémorisons pas toute une bibliothèque, nous utilisons des moteurs de recherche et des systèmes de classement pour retrouver ce qu’il nous faut, à la demande.

Pour un agent d’IA, cela signifie interroger une base de connaissances externe. Cependant, identifier la bonne information représente un véritable défi. À mesure que les données croissent, une simple recherche sémantique peut devenir peu fiable. Une sélection efficace repose souvent sur une approche hybride, combinant plusieurs techniques de recherche — par mots-clés, sémantique, ou via des graphes — afin d’identifier avec précision le contexte requis dans des ensembles de données vastes et complexes.

Cette stratégie offre à l’agent un espace pour décharger l’information, en l’écrivant dans une mémoire externe, comme un fichier « brouillon » ou une base de données dédiée. Par exemple, un agent peut enregistrer son plan en plusieurs étapes dans un fichier et s’y référer plus tard, ce qui empêche ce plan d’être évincé d’une fenêtre de contexte déjà saturée. Cela permet à l’agent de conserver l’état de la session et de suivre l’avancement de tâches longues, sans encombrer sa mémoire de travail.

Les techniques de compression réduisent le nombre de jetons dans la fenêtre de contexte tout en préservant l’information essentielle.

• Résumé : utilise un LLM pour condenser de longues conversations ou documents en résumés synthétiques. Par exemple, la sortie complète d’un outil — souvent lourde en jetons — peut être remplacée par un résumé concis de ses résultats.
• Élagage : filtre le contexte à l’aide de règles prédéfinies, comme la suppression des messages les plus anciens dans une conversation, ou l’effacement des sorties redondantes d’outils devenues inutiles.

Pour des tâches très complexes, un agent unique peut rapidement être submergé. L’isolation consiste à décomposer le problème en sous-tâches, confiées à des « sous-agents » spécialisés, chacun disposant de sa propre fenêtre de contexte, propre et ciblée. Un agent principal coordonne cette équipe, ne recevant que les résultats finaux, déjà synthétisés, de chaque spécialiste. Cette approche permet de garder le contexte de chaque agent pertinent et facile à gérer, ce qui améliore les performances globales sur des tâches complexes de recherche ou d’analyse.

En appliquant ces principes, l’ingénierie du contexte vise à fournir au LLM le plus petit ensemble possible de jetons à forte valeur informative, afin de maximiser les chances d’un résultat pertinent et réussi.

À la base, l’ingénierie du contexte est définie par une contrainte fondamentale : les modèles de langage (LLM) disposent d’un budget d’attention limité. La fenêtre de contexte (mesurée en jetons) détermine la quantité maximale d’informations qu’un modèle peut traiter en une seule fois. Bien que les modèles récents prennent en charge des fenêtres de contexte de plus en plus grandes (100 000, 1 million, voire 2 millions de jetons), le simple fait de remplir cet espace ne garantit pas de meilleures performances.

Les LLM reposent sur une architecture de type transformer, dans laquelle chaque jeton doit tenir compte de tous les autres. À mesure que le contexte s’allonge, cela génère une surcharge de calcul, et ce que les spécialistes appellent la « dérive du contexte » : la capacité du modèle à maintenir son attention et à se souvenir de détails précis se détériore au fur et à mesure que la quantité d’informations augmente. Ce phénomène reflète les limites cognitives humaines : plus d’informations ne signifie pas nécessairement de meilleures décisions.

Le simple fait d'élargir la fenêtre pose de sérieux défis :

• Coût et latence accrus : la complexité computationnelle du mécanisme d’attention dans l’architecture Transformer augmente de manière quadratique ($O(n^2)$) avec la longueur de la séquence, rendant les contextes plus longs exponentiellement plus coûteux et plus lents à traiter.
• Dégradation des performances (« perdu au milieu ») : les LLM mémorisent bien les informations situées tout au début ou à la fin d’une longue fenêtre de contexte, mais leurs performances chutent fortement pour les données situées au milieu.
• Bruit et distraction  : une fenêtre de contexte plus grande augmente le risque d’inclure des informations non pertinentes ou « bruyantes », ce qui peut détourner l’attention du modèle et nuire à la qualité du résultat. On parle souvent ici du problème de « l’aiguille dans une botte de foin ».

Ce paradoxe renforce la nécessité d'une curation intelligente, et non d'une simple force brute, faisant de l'ingénierie du contexte un art délicat.

L’objectif prioritaire de l’ingénierie du contexte est de garantir qu’un agent puisse mener à bien sa tâche de manière fiable et cohérente. Sans un contexte précis et pertinent, et sans les bons outils, un agent échouera : hallucinations, mauvais choix d’outil ou incapacité à exécuter un plan en plusieurs étapes. C’est ce problème fondamental que l’ingénierie du contexte cherche à résoudre.

Dans un système conçu avec une ingénierie du contexte, la qualité des résultats désigne la capacité de l’agent à répondre en cohérence avec l’intention de l’utilisateur, l’exactitude des faits et les exigences de la tâche — au-delà de la seule fluidité ou cohérence, que les LLM maîtrisent naturellement. Un résultat de qualité dépend directement d’un contexte d’entrée de qualité : le principe du « garbage in, garbage out » s’applique pleinement.

L’ingénierie du contexte améliore la qualité des résultats grâce à plusieurs mécanismes :

• Qualité de la récupération : garantit que l’agent accède à des sources précises et pertinentes, au lieu d’halluciner ou de s’appuyer sur des données d’entraînement obsolètes.
• Structure du contexte : influence l’efficacité avec laquelle le modèle extrait et synthétise l’information.
• Un contexte bien segmenté et sémantiquement cohérent permet un raisonnement plus précis que des extraits fragmentés.
• Le rapport signal/bruit est crucial : inclure cinq documents très pertinents donne de meilleurs résultats que d’y ajouter vingt autres seulement liés de façon marginale, car l’information non pertinente détourne l’attention du modèle.

La qualité des résultats dépend aussi de la clarté des instructions dans l’invite système et des exigences explicites en matière de format (des sorties structurées comme en JSON réduisent les erreurs d’analyse). L’évaluation de la qualité nécessite des métriques adaptées à la tâche : exactitude factuelle pour les systèmes RAG, taux de réussite pour les agents, scores de satisfaction utilisateur pour les systèmes conversationnels. L’ingénierie du contexte permet d’améliorer la qualité de manière systématique en rendant la relation entre l’entrée et la sortie observable et ajustable. Vous pouvez mesurer quelles combinaisons de contexte produisent les meilleurs résultats, puis optimiser la récupération, le classement et le filtrage en conséquence.

Chaque jeton dans la fenêtre de contexte a un coût : ressources de calcul, facturation API et latence. L'ingénierie contextuelle a un impact direct sur les trois aspects suivants :

• Optimisation des coûts : réduire le nombre de jetons inutiles dans les invites permet de faire baisser considérablement les coûts d’API, en particulier pour les applications à fort volume.
• Réduction de la latence : des contextes plus petits et ciblés entraînent des temps d’inférence plus rapides et des applications plus réactives.
• Amélioration de la qualité : un contexte ciblé et à forte valeur informative surpasse systématiquement les masses d’informations non structurées.

Les systèmes d’IA de production doivent être résilients. Une mauvaise ingénierie du contexte conduit à plusieurs modes de défaillance :

• Empoisonnement contextuel : lorsque des hallucinations ou des erreurs s’intègrent dans le contexte et se répercutent sur les interactions suivantes.
• Dérive des objectifs : lorsque l’accumulation d’informations non pertinentes pousse l’agent à perdre de vue ses objectifs initiaux.
• Surcharge de capacité : lorsque des informations critiques sont tronquées parce que la fenêtre de contexte est remplie par des données de moindre priorité.

Une bonne ingénierie du contexte permet d’éviter ces problèmes grâce à des mécanismes de validation, d’élagage et de gestion structurée de la mémoire. Considérer le contexte comme une ressource soigneusement organisée plutôt qu’un simple accumulateur passif d’informations.