IA générative : comprendre l’ingénierie de contexte - nos exemples d'implémentation et nos conseils pour éviter le pire !
Sommaire
Dans l’article « IA générative : comprendre l’ingénierie de contexte, méthodes pour faire de l’IA un outil opérationnel efficace » nous proposions quelques éléments pour comprendre l’ingénierie de contexte, son intérêt et les méthodes applicables. Passons maintenant au concret avec quelques exemples et bonnes pratiques !
Notre service « bibliothécaire » dans IAK
IAK est la plateforme d’IA souveraine déployée pour les collaborateurs du groupe Keran. La plateforme met aux utilisateurs une variété de modèles de petites et moyennes tailles dans des services et cas d’usages concrets. Elle comprend notamment une bibliothèque de services travaillés pour répondre aux cas d’usage des collaborateurs.
Le « BibliothéKAIre » est un bon cas d’école du fonctionnement d’un RAG. Dans ce service l’utilisateur est invité à uploader quelques documents à sa bibliothèque « projet ».
Les documents sont segmentés en de multiples articles et extraits, vectorisés et indexés dans notre index / moteur de recherche.
Qu’est-ce qu’un index ?
On parle souvent d' »index » dans cet article. Un index, c’est l’outil (aujourd’hui informatisé, autrefois des tiroirs de petites fiches alphabétiques) permettant à un documentaliste, archiviste ou bibliothécaire, de vous indiquer, pour un thème qui vous intéresse, dans quels ouvrages ou documents vous retrouverez traité ce thème. C’est une brique indispensable des moteurs de recherches.
Lorsque le chatbot est interrogé, une recherche est effectuée dans les documents permettant de sélectionner les extraits les plus pertinents. Ces références sont fournies au LLM ; Il répond aux utilisateurs en tirant l’information de ces extraits et en prenant bien soin de citer les sources, ce qui nous permet de les présenter en vis-à-vis et d’y naviguer.
Nous appliquons une méthode hybride entre R.A.G. « pur » et fonctionnement agentique : nous pouvons utiliser directement le prompt dans le moteur de recherche, ou demander au LLM d’en modifier la formulation pour une recherche plus efficace. Lors de la suite de l’échange avec l’utilisateur, nous appliquons une méthode géométrique pour évaluer si les demandes sont très généralistes, restent « dans le thème » ou s’en écartent ; Il est estimé l’opportunité de réinterroger le moteur de recherche pour mettre à jour le contexte. En cas de doute, nous pouvons demander son avis au LLM qui demandera ou non une mise à jour. Ce type d’astuces permet de réduire les recours au LLM et d’utiliser à chaque fois que faire se peut, des méthodes bien plus légères en puissance de calcul.
Petit plus didactique :
Nous avons voulu donner à nos utilisateurs la possibilité d’entrouvrir le capot et de bien comprendre ce qu’il s’y passe. Il est donc possible d’avoir un aperçu de ce qui est envoyé au moteur de recherche, et de le dissocier des prompts, et modifier manuellement ces recherches dans les documents.
Des services à mémoire
Un problème que nous n’avons que peu évoqué est celui de donner « une mémoire » au LLM. L’impression de continuité de « conversation » avec une IA conversationnelle est liée à l’accumulation dans le contexte / le cache de l’ensemble des échanges précédents qui permet de simuler une mémoire à court terme.
Mais qu’en est-il de mémoire à « long terme » ? Nous avons eu besoin, pour différents projets en cours d’expérimentation, d’approfondir ce point !
Des services individuels qui vous connaissent bien !
Si vous avez un compte, ou (plus intrusif) l’application smartphone, d’un OpenAI ChatGPT, Anthropic Claude, ou Microsoft Copilot, auquel vous auriez donné accès à vos autres applications (messageries, photos, contacts, transactions…) ces outils construisent petit à petit une base de données de connaissance sur vous et vos centres d’intérêt dont ils pourront se servir pour alimenter le contexte, au besoin, pour mieux répondre à vos prompts.
Bien évidemment, il serait inconvenant de saturer systématiquement le contexte de toutes vos conversations passées, ainsi que de l’intégralité des données extraites d’applications liées, etc. Le LLM encode donc dans sa base de données interne une synthèse choisie des données pertinentes parmi lesquelles il pourra lire par la suite, réalisant ainsi l’artifice d’une mémoire à long terme, d’une connaissance acquise par l’Intelligence Artificielle, bien que le modèle lui-même n’évolue pas et n’apprend pas de vos échanges.
Dans nos exemples, nous avons besoin de donner à l’Intelligence Artificielle la possibilité de mobiliser toute la connaissance acquise sur un ou plusieurs projets : des dizaines de documents, de nature très diverse et des données issues des progiciels internes.
Notre solution pour donner à l’IA une « mémoire » à long terme de ce qui lui a été demandé et du contexte des projets consiste à modéliser un graphe de connaissance.
Dans ce graphe tous les acteurs, les territoires, les travaux et équipements, les missions, étapes et les documents du projet sont modélisés avec leurs relations. Le SIA peut alors, par des agents, prendre connaissance de la structure de ce graphe, et même le modifier.
Ainsi, s’il faut par exemple qu’un assistant de relecture vérifie l’adéquation du dernier cahier des charges en cours de rédaction avec les différentes phases d’aménagement prévues : le LLM n’aura pas besoin de se voir réalimenter de l’ensemble des extraits de documents décrivant ces aménagements. Il pourra consulter le graphe et y trouvera des synthèses qu’il aura lui-même générées, lors d’une précédente analyse de ces extraits de documents.
S’il estime manquer d’information sur un sujet par ce moyen, il pourra générer une seconde requête au graphe pour inventorier documents ou contenus pertinents et déclencher une recherche au R.A.G. filtrée grâce à ces données.
Bonnes pratiques de sûreté informatique
On rencontre parfois dans la presse des scénarios catastrophes un peu sensationnalistes liés à l’usage d’IA agentiques (prise de contrôle, suppression de données, etc.). Je conclurai donc cet article par une réflexion sur ces risques — hors usages intentionnellement malveillants — que je voudrais rassurante : Un défaut de prudence de l’utilisateur est à l’origine de toutes les défaillances en question.
Vous l’aurez compris, un LLM est par nature impuissant, toute action potentiellement destructrice est en fait réalisée, sur ses instructions, par le « harnais », serveur MCP et les outils qu’il anime.
Le problème ici, c’est que les plus enthousiastes utilisateurs de l’IA peuvent oublier les règles les plus élémentaires de développement d’outils informatiques. Les programmes sensibles doivent s’exécuter dans des conteneurs et des bacs à sable ; se voir attribuer des accès spécifiques à des portions bien définies des infrastructures sur un réseau. Enfin chaque programme, comme chaque utilisateur d’un système informatique se voit attribuer des droits spécifiques. Si mon IA locale peut lire mes notes de réunions, elle n’a aucune raison de les supprimer ; c’est à moi de m’assurer ou bien que le MCP n’en offre pas la possibilité, ou que son rôle ne le permette pas pour que l’OS l’en empêche.
Les personnes qui ont développé et mis en production les agents permettant à un LLM (Claude d’Anthropic) de provoquer la suppression d’une base de données et de tous ses backups chez « PocketOS » ne peuvent s’en prendre qu’à eux-mêmes. Il a fallu une chaîne de défaillances humaines pour qu’un LLM (un outil probabiliste toujours, par essence, capable d’avoir un comportement imprévu) ait une telle possibilité. Rien ne justifiait qu’il en ait la possibilité, or le MCP incluait un outil pour le faire, car trop généraliste ; rien ne justifiait non plus qu’il en ait le droit, mais un même jeton d’authentification était utilisé par plusieurs systèmes critiques, etc., etc.
On voit apparaître des assistants agentiques « grand public » comme OpenClaw. Un assistant proposant via une interface directement intégrée à vos messageries instantanées type WhatsApp, d’agir à votre place, en votre nom, avec vos mots de passe, via un serveur MCP donnant accès à vos documents, vos courriels, vos calendriers, une ligne de commande sur votre système, vos souscriptions à des services payés à l’usage, etc. Les risques d’une telle proposition sont évidents. (Des alternatives mieux conçues existent comme nanoclaw pour n’en citer qu’un). Voici quelques bonnes pratiques pour déterminer si un tel outil vous met en danger ou non :
- Limiter les accès au système hôte, en exécutant ces programmes dans une machine virtuelle ou un conteneur ;
- Ne pas communiquer vos mots de passes, mais utiliser des clefs APIs spécifiques dotés de droits limités ;
- Garder la main sur chaque outil activé dans le MCP et imposer une validation manuelle pour chaque action potentiellement destructrice (ou achat…).
L'AUTEUR
