L’ingénierie du contexte de l’IA consiste à concevoir tout ce qui entoure l’agent en matière d’informations, de limites et d’instructions, afin qu’il sache ce qu’il peut voir, ce qu’il doit faire et comment se comporter lorsqu’il rencontre une situation nouvelle ou des données manquantes. Selon les explications de Doug Whitley, directeur de l’ingénierie chez Stack Overflow, et d’Ash Zade, directeur des produits, l’objectif n’est pas de submerger l’agent avec toutes les données disponibles, mais de lui fournir le contexte précis dont il a besoin pour accomplir une tâche au résultat prévisible.
Ces propos ont été tenus lors d’un entretien publié par le Stack Overflow Blog dans le cadre de la série « No Dumb Questions ». L’entretien a abordé les différences entre l’ingénierie du contexte, l’infrastructure du contexte et l’ingénierie contextuelle, ainsi que la relation de ces concepts avec les technologies RAG et MCP et les raisons pour lesquelles les entreprises choisissent d’acheter des solutions prêtes à l’emploi plutôt que de tout construire en interne.
De l’infrastructure à l’ingénierie
Whitley distingue l’infrastructure du contexte, qui concerne la manière dont le contexte est stocké, affiché et fourni à l’agent, de l’ingénierie du contexte, qui se concentre sur la conception du système et les raisons qui conduisent à organiser ses composants d’une certaine manière. Quant à l’ingénierie du contexte au sens opérationnel, elle concerne la construction effective du système, notamment le choix des algorithmes, des langages de programmation et des outils utilisés.
Il situe le RAG dans une zone qui réunit les trois niveaux. Les index, les magasins de contexte et les méthodes de recherche représentent l’aspect infrastructurel, tandis que la construction du système dans un langage comme .NET, Python ou Rust relève de l’ingénierie. En revanche, l’architecture définit la forme générale du système et les règles qui régissent son fonctionnement. Pour Whitley, le MCP est un protocole assorti d’exigences précises, mais la décision de l’intégrer au système, les langages utilisés et les fonctionnalités qu’il prendra en charge sont autant de décisions de conception.
Réduire l’espace des décisions prises par l’agent
Zade explique cette idée à l’aide de l’exemple d’une recherche de pneus automobiles. Si l’on envoie un agent dans une bibliothèque pour rechercher des « pneus », il peut trouver des informations concernant les avions, les vélos et les brouettes, car tous ces éléments correspondent au mot demandé. Mais un système bien conçu précise dès le départ que la tâche concerne les pneus automobiles, ou spécifiquement les pneus de voitures de sport, et limite les informations disponibles à ce périmètre.
Selon Zade, placer ces instructions dans un simple prompt textuel ne garantit pas que l’agent les respectera. L’ingénierie du contexte exige donc de contrôler les données auxquelles l’agent peut accéder, tout en définissant ce qu’il doit faire lorsqu’il rencontre des informations incomplètes ou incorrectes. De cette manière, certaines variables sont retirées des décisions de l’agent, au lieu de le laisser décider lui-même si une information est fiable ou s’il convient d’élargir le périmètre de la recherche.
Le système comprend également la mémoire de l’agent, afin qu’il conserve ce qu’il a accompli, appris, communiqué et construit jusqu’à présent. Cette mémoire devient encore plus importante lorsque plusieurs agents travaillent ensemble ou lorsqu’une tâche est interrompue puis reprise ultérieurement.
Confiance, autorisations et intervention humaine
Stack Internal, selon les intervenants, fournit un exemple de liaison entre le contexte, un système de confiance et un processus de vérification par des experts. Les connaissances sont classées selon des niveaux élevé, moyen ou faible. Si le niveau est moyen ou faible, l’utilisateur peut être orienté vers un expert du domaine afin de vérifier l’information ou de compléter les éléments manquants, plutôt que de laisser l’agent prendre une décision fondée sur des connaissances incertaines.
La protection des données ne se limite pas à déterminer si l’agent peut voir une information donnée. Une information peut être accessible à l’utilisateur tout en étant inappropriée pour la tâche exécutée par l’agent. Les intervenants décrivent donc deux niveaux de contrôle :
- Autorisations de la source : l’agent hérite des autorisations de l’utilisateur dans les systèmes où il effectue ses recherches, tels que Slack, MS Teams, Google Drive ou SharePoint.
- Périmètres : l’utilisateur peut réduire l’étendue des données accessibles à l’agent, même s’il dispose d’une autorisation d’accès à un ensemble plus vaste.
- Nouvelles données : il est possible de limiter ce que l’agent crée ou renvoie au système, afin qu’il le transmette d’abord à l’utilisateur et ne l’ajoute pas automatiquement à la base de connaissances générale ou ne le partage pas avec l’équipe.
Cette distinction montre que la gestion du contexte ne concerne pas uniquement la récupération, mais englobe également le contrôle de la mémoire et des connaissances créées par l’agent.
Pourquoi une entreprise achèterait-elle la solution plutôt que de la construire ?
Whitley affirme qu’il est possible de construire une ingénierie du contexte, mais que le défi ne se limite pas à écrire du code. Lorsqu’une entreprise rassemble des données provenant de Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub et Jira, elle doit déterminer comment les indexer, les trier et les réordonner, ainsi que comment gérer les informations contradictoires, incomplètes ou incorrectes.
Pour Zade, une grande partie du travail consiste à définir la confiance elle-même. Un utilisateur expert peut faire confiance aux résultats de l’IA lorsqu’ils correspondent à ses attentes et à son expérience antérieure, mais cette approche n’est pas accessible dans la même mesure à une personne qui manque d’expertise dans le domaine où elle demande à l’IA d’intervenir. Le système exige donc des discussions sur ce qui rend une information digne de confiance, et pas uniquement des solutions techniques pour la collecter.
Whitley ajoute que l’achat d’une solution prête à l’emploi peut donner à l’entreprise accès à l’expérience accumulée à partir des problèmes rencontrés par d’autres clients, notamment les cas limites et les problèmes quotidiens que son équipe, dit-il, classe dans environ 20 catégories. Les deux intervenants n’excluent toutefois pas la construction en interne : celle-ci peut être adaptée lorsqu’il s’agit d’un cas d’utilisation nouveau ou lorsque l’entreprise a besoin de décisions de conception qui lui sont propres.
Pour Whitley et Zade, la qualité de l’ingénierie du contexte se mesure à la flexibilité du système et à sa capacité à fournir des résultats cohérents et prévisibles, et non au simple fait de limiter son périmètre à une seule tâche. Le filtrage précoce des informations peut également réduire le nombre de jetons traités par l’agent : rechercher dans des livres sur l’automobile coûte moins cher que rechercher dans une bibliothèque entière, et rechercher dans les pages consacrées aux pneus coûte moins cher que parcourir tous les livres. L’objectif final reste de permettre à l’agent d’exécuter la tâche attendue, puis de s’arrêter ou de demander une aide humaine lorsqu’il atteint des limites qu’il ne devrait pas dépasser.