Ingénierie du contexte : au-delà du RAG classique

Qu’est-ce que l’ingénierie du contexte ?

Un agent répond à partir du contexte qu’on lui fournit. L’ingénierie du contexte, c’est le travail qui consiste à préparer ce contexte volontairement, plutôt que d’espérer qu’une recherche par similarité ramène les bons passages.

Elle couvre l’origine de l’information, sa durée de validité, les personnes qui ont le droit de la lire et la part qui tient dans la fenêtre du modèle.

Quelle différence avec le RAG classique ?

Le RAG classique répond bien à un problème étroit : trouver du texte lié à une question et laisser le modèle rédiger à partir de lui. L’ingénierie du contexte part d’une autre question : de quoi cet agent a-t-il besoin pour accomplir cette tâche en sécurité ?

Je ne plaide pas contre la récupération. La recherche hybride, un découpage raisonnable et le reclassement restent le socle, et le travail mené à la DILA montre l’ingénierie soignée qu’ils méritent. Le point est que la récupération est nécessaire mais insuffisante dès que des agents agissent pour le compte de personnes, sur des documents qui changent et n’ont pas le même niveau de confidentialité.

Le tableau compare les deux approches sur les critères qui décident si un agent peut être digne de confiance dans une organisation.

Pourquoi les agents échouent-ils même quand la récupération fonctionne ?

D’après mon expérience, les agents échouent rarement faute d’un meilleur modèle. Ils échouent dans quatre situations que la recherche par similarité ne voit pas :

Chacune relève de la gouvernance, pas du classement. Un meilleur modèle d’embeddings améliore la proximité d’un passage avec une question, mais il ne peut pas savoir qu’une décision a été annulée, ni que la personne qui demande est un stagiaire. Ce savoir vit dans le cycle de vie des données et dans le modèle d’accès : il faut donc le modéliser explicitement et l’appliquer au moment de l’assemblage.

• Une décision a été remplacée le mois dernier, mais l’ancien document reste le plus proche de la question.
• Deux versions d’une spécification se contredisent, et les deux arrivent dans le prompt.
• Une contrainte, par exemple d’accessibilité, figure dans un document qui n’a jamais été récupéré.
• Le lecteur n’a pas le droit de voir un document, mais celui-ci a été récupéré parce qu’il était pertinent.

À quoi ressemble un élément de mémoire gouverné ?

ORBIT, la plateforme que j’ai construite pour explorer le sujet, traite les décisions, besoins, contraintes, risques et préférences comme des éléments de mémoire plutôt que comme des fragments isolés. Chacun porte des versions et une provenance jusqu’au paragraphe source.

C’est le cycle de vie qui rend la mémoire gouvernable. Un élément n’est pas simplement stocké : il est proposé, revu, puis remplacé ou oublié.

Comment assemble-t-on le contexte d’une tâche ?

ORBIT assemble le contexte par tâche, et non par question. Les sources sont d’abord ingérées avec détection et caviardage des données personnelles, puis indexées pour une recherche hybride. À la requête, l’assemblage suit une séquence fixe. J’y tiens à l’explicabilité : quand un agent donne une réponse surprenante, on peut ouvrir le contexte qu’il a reçu et lire pourquoi chaque élément y figurait ou non, au lieu de deviner à partir d’un score de similarité.

• Comprendre l’intention de la tâche et qui la demande.
• Chercher dans la mémoire et les documents, puis fusionner les résultats classés.
• Appliquer la fraîcheur, résoudre les conflits et supprimer les doublons.
• Appliquer habilitations et classification, pour qu’un lecteur ne reçoive jamais ce qu’il n’a pas le droit de voir.
• Sélectionner dans le budget de tokens et compresser le reste.
• Renvoyer le contexte avec un code de raison pour chaque élément retenu ou exclu.

Comment mesurer la qualité du contexte ?

Un contexte que l’on ne mesure pas est un contexte que l’on ne peut pas améliorer. ORBIT est conçu pour enregistrer la latence, les tokens, le coût estimé, les exclusions par raison et les sources les plus utiles, et pour exporter les traces vers l’évaluation. Des snapshots versionnés permettent à plusieurs agents de partager le même contexte et de le comparer dans le temps.

ORBIT est une bêta publique, non validée pour un usage en production, et je n’en revendique aucun gain mesuré. Les chiffres que je peux défendre viennent de la plateforme de la DILA, au service du Premier ministre : la chaîne de récupération a été mesurée à 0,94 de fidélité, 0,91 de pertinence des réponses, 0,89 de précision du contexte et 0,92 de rappel du contexte, avec 85 % des scénarios RAG prioritaires couverts.

Le même travail sur les chaînes a contribué à un coût par requête d’IA en baisse de 30 %, et les composants réutilisables ont ramené la livraison d’une application RAG de 10 semaines à 4. Ces résultats viennent de l’ingénierie de la chaîne autour du modèle, ce qui est exactement l’argument de cet article.

Plusieurs agents peuvent-ils partager le même contexte, et où cette approche s’arrête-t-elle ?

Des snapshots versionnés permettent à des agents de travailler sur le même contexte assemblé et de le comparer à un contexte ultérieur : un désaccord entre deux agents se ramène alors à une différence dans ce qu’ils ont reçu. Chaque snapshot indique la classification de ce qu’il livre, et ORBIT est accessible par une API REST et un serveur MCP.

L’approche a ses limites. Une mémoire gouvernée coûte du temps de revue, quelqu’un doit arbitrer les contradictions, et l’extraction par un modèle de langage est optionnelle et doit être vérifiée. Elle reflète aussi mes choix de conception, éprouvés sur un projet de démonstration plutôt qu’en production, d’où le terme de bêta publique pour ORBIT.

Par où commencer ?

Inutile d’adopter une nouvelle plateforme dès le premier jour. L’ordre qui a fonctionné pour moi consiste à rendre les problèmes visibles avant de les corriger.

• Lister les sources sur lesquelles un agent s’appuie et nommer un responsable pour chacune.
• Ajouter habilitations et classification au chemin de récupération, pas seulement à l’index.
• Suivre quelles décisions en remplacent d’autres, même dans un simple tableau.
• Journaliser ce qui a été retenu et exclu pour chaque requête.
• Évaluer l’étape de récupération séparément de la réponse générée.