IA générative : comprendre l’ingénierie de contexte, méthodes pour faire de l’IA un outil opérationnel efficace
Sommaire
L'ingénierie de contexte, qu'est-ce que c'est ?
Les outils d’IA Générative « grand public » impressionnent souvent au premier abord, mais peuvent se montrer décevants, approximatifs, lorsqu’on entre dans un usage suivi ou professionnel. C’est là l’un des enseignements de nos travaux d’expérimentation et d’évaluation de la technologie au sein du groupe KERAN. C’est également la raison pour laquelle Naomis a choisi de présenter des services spécifiques déclinant les possibilités de l’IA Générative sur des cas d’usage étudiés et testés sur IAK, la plateforme de « LLM souverain » déployée pour le groupe KERAN.
Un certain nombre de limitations inhérentes à ces modèles expliquent pourquoi cette forme d’Intelligence Artificielle échoue souvent à répondre aux attentes, en particulier dans un contexte professionnel. Certaines sont bien connues (comme l' »Horizon d’apprentissage » ou « date limite de connaissance ») d’autres moins.
Dans cet article, nous proposons de vous faire faire un petit tour d’Horizon des méthodes développées par l’industrie — et de plus en plus intégrées à nos projets IA chez KERAN — pour fournir à un LLM génératif ou conversationnel l’information dont il a besoin pour accomplir, avec assez de régularité, une tâche.
Limitations de la technologie
Les LLM, disposent à l’issue de leur entraînement, de façon « latente », résiduelle, hyper-compressée, de l’information des corpus de textes sur lesquels ils ont appris à imiter le langage.
Malgré l’ampleur de la collecte de sources intégrées aux jeux de données d’entraînement, il en demeure des limitations évidentes :
- La première, tient au fait que tout évènement ou document plus récent en est absent ;
- La seconde est le manque de diversité de ce corpus sur les domaines d’activité les plus spécifiques.
La seconde source d’information du LLM conversationnel est le prompt de l’utilisateur et le contexte de la conversation.
Comment ça marche ?
Un modèle « transformer » (architecture commune à tous les LLM actues) comprend un analyseur lexical ou « tokenizer » (Imaginez numéroter tous les mots du dictionnaire, et transformer un texte en la liste des positions de ses composants dans cette liste) et une vectorisation, un algorithme entraîné à attribuer à chacune des unités (« tokens ») de ce lexique un vecteur/descoordonnées (« embeddings ») dans un espace représentant – pour simplifier – les relations entre les champs lexicaux.
Par exemple, en fonction du contexte le modèle saura attribuer au mot « appareil » un encodage différent selon que les autres mots environnants évoquent la technologie ou la pâtisserie.
Le contexte, et le prompt de l’utilisateur sont ainsi vectorisés et ce vecteur est l’input fourni au modèle qui en retour prédit de nouveaux tokens composant sa réponse. Lorsque vous téléchargez un document, le texte en est extrait (ainsi que certains éléments de mise en page), vectorisé, et ce contenu est associé au contexte.
Nous touchons là à une nouvelle limite importante. Tout d’abord, un modèle ne peut recevoir comme entrée qu’un nombre limité de tokens de contexte, correspondant pour la plupart à quelques centaines de pages de texte. C’est largement suffisant pour ne pas oublier le début de votre conversation, mais pose vite un problème si vous souhaitez intégrer tout le Code de l’environnement, vos DCEs, toute la documentation d’un ou plusieurs de vos projets…
Par ailleurs la taille du contexte contribue à l’impact matériel du LLM, outre le poids du modèle, les contextes sous la forme d’un cache clefs-valeurs sont également chargés en mémoire (idéalement par le GPU) au moment de la génération et ce cache peut assez rapidement devenir plus volumineux encore que le modèle lui-même. Réduire la taille de ce cache ou optimiser son utilisation fait l’objet de recherches.
Enfin un agent conversationnel est, en fin de compte, une machine qui prend un texte en entrée et retourne un texte en sortie. Ce qui signifie que données d’entrées et instructions sont mêlées : seule la bonne rédaction du prompt permet d’orienter la génération en incitant le LLM à exploiter la donnée fournie pour répondre aux instructions.
Le principe d'ingénierie de contexte
Les techniques d’ingénierie de contexte regroupent toutes les méthodes permettant d’injecter de la donnée, de l’information, au contexte du LLM au bon moment.
Pour répondre aux limitations évoquées plus tôt, nous devons choisir la donnée la plus pertinente et la plus concise possible :
- Dynamiquement, en fonction de l’instruction donnée au LLM / de la question qui lui est posée, de la tâche attendue ;
- Parmi les systèmes de données / d’informations à disposition ;
- Sous le format le mieux structuré pour indiquer son rôle ;
- Avec les bonnes instructions, permettant au LLM de « comprendre » qu’il doit exploiter cette donnée pour accomplir au mieux sa tâche.
Tout se passe au niveau du Système d’Intelligence Artificielle, le programme intermédiaire entre l’utilisateur et le LLM. Il doit :
- Intercepter le prompt utilisateur ;
- Déterminer à partir de ce prompt une sélection de données pertinentes ;
- Mettre en forme cette donnée ;
- Intégrer cette donnée au contexte ;
- Transformer le prompt utilisateur pour indiquer au modèle qu’il dispose de la donnée pertinente pour répondre dans le contexte précédent.
Différentes techniques d'ingénierie de contexte
Voici succinctement trois méthodes utilisées de plus en plus fréquemment pour parvenir à une ingénierie de contexte performante.
Chacune de ces techniques présente ses atouts propres et ses inconvénients, toutes sont tout à fait pertinentes dans certains cas d’utilisation, notamment dans une logique d' »IA Frugale » impliquant de veiller à exploiter au mieux de petits modèles, à limiter les appels au LLM, en intégrant ceux-ci au sein d’une constellation d’outils plus efficients.
- Génération augmentée par recherche (R.A.G.)
Le R.A.G. fonctionne autour d’un moteur de recherche, il peut s’agir de divers systèmes de requêtes en bases de données, dans des fichiers ou au sein d’une base documentaire.
Le principe en est simple : le prompt de l’utilisateur est passé au moteur de recherche, le système sélectionne un jeu de données correspondant, et l’intègre au contexte en accompagnement du prompt.
Par exemple une IA d’assistance au développement informatique (GitHub Copilot, Claude Code, etc.) auquel il serait demandé d’écrire une nouvelle fonction manipulant une classe d’objet donnée, pour alimenter une base de données n’a pas besoin de connaître toute notre base de code, uniquement le code définissant la classe d’objet en question et les interactions avec la base de données. ; Une recherche dans le répertoire de travail sélectionnera les bons fichiers, les classes, les fonctions adéquates, et intégrera ceci au contexte.
Le détail d’implémentation peut être plus ardu, notamment parce que le prompt de l’utilisateur peut contenir une indication sémantique sur son objectif, ou non. Ainsi faire suivre la précédente instruction de « Explique-moi la troisième ligne » ne demande aucun ajout de nouveau contexte, on ne devra pas envoyer toutes les troisièmes lignes de notre code au LLM. Il faut donc un mécanisme déterminant quand, et comment utiliser le R.A.G ou, au contraire, laisser le contexte inchangé.
- Mode « Raisonnement »
L’aptitude d’un modèle génératif à un simulacre de raisonnement peut être obtenue de diverses façons et peut être exploitée à différents niveaux de complexité.
Cependant, même dans sa version la plus simple, il s’agit d’une forme sommaire d’ingénierie de contexte.
Il ne s’agit pas ici d’enrichir le contexte d’informations complémentaires à utiliser mais d’orienter, de conditionner le LLM pour répondre sans s’éparpiller.
En incitant le LLM, dans un premier temps, à établir un plan, une méthodologie de réponse, puis d’appliquer celle-ci, nous l’amenons à générer des tokens dans le contexte, dont la présence orientera la prédiction des suivants dans le bon sens.
- Les « Agents » et « Systèmes Agentiques »
Les systèmes dits « agentiques » à l’actualité brulante, demanderont un article dédié ; ils poussent la logique du R.A.G. bien plus loin, mais avec un inconvénient majeur : les appels au LLM vont être beaucoup, beaucoup plus nombreux.
Un système agentique c’est d’abord une collection de sous-programmes, d’APIs (Interfaces de Programmation) par exemples, permettant à deux systèmes d’informatiques d’échanger des données. Mais le LLM n’est pas capable d’appeler par lui-même des APIs ; encore une fois, il reçoit du texte et émet du texte.
Le système va tout d’abord intégrer au contexte des appels au LLM une description des outils à sa disposition. Pour cela, il fournit la définition d’une syntaxe servant à solliciter l’utilisation de ces outils, leurs noms, et pour chacun les paramètres qu’ils peuvent accepter.
Par exemple si le LLM génère le texte (json) suivant « {« outil » : « files », « parametres » : {« action » : « read », « cible » : « documents/projets/dce_1.pdf »}}« le programme doit déterminer que ce n’est pas une sortie destinée à l’utilisateur, mais une demande du LLM de lui faire lire le contenu de ce fichier PDF.
Pour cela, il a fallu décrire au LLM le protocole à suivre :
- Une chaîne json valide contenant les clefs « outil » et « paramètres » permet d’appeler les agents mis à sa disposition en indiquant d’abord un nom, puis, une sous-structure avec des options dépendant de chaque outil ;
- Il existe un outil « files » permettant de manipuler des fichiers ;
- Cet outil « files » utilise les paramètres « action » (un verbe) et « cible » (un chemin de fichier).
Autre exemple :
Pour utiliser une base de données SQL, il suffit de fournir le schéma de base de données, indiquant qu’il existe une table « facture » contenant des colonnes « nom_client » et « date_facture ».
Ça tombe bien, a priori le LLM sait très bien écrire des requêtes SQL. Si l’utilisateur prompte « Indique-moi de quand date la dernière facture de la Région Pays de la Loire, il pourra par exemple émettre quelque chose comme {« outil » : « database », « parameters » : {« query » : « SELECT MAX(date_facture) FROM facture WHERE nom_client LIKE « %pays%de%loire% » »}}. Le LLM n’est pas connecté à la base de données, c’est un autre programme qui va lire cette sortie, exécutera la requête en base de données, et transmettra les données reçues au LLM dans un nouveau prompt.
Ce programme, (On parle de « Serveur MCP » pour « Model Context Protocol » littéralement un protocole permettant de définir un contexte) reçoit les sorties du LLM, détermine qu’il s’agit d’une demande d’un agent, traite cette demande en appelant le sous-programme adéquat, réceptionne les données, et réémet alors un nouveau prompt au LLM assorti du résultat.
L’avantage par rapport au R.A.G. c’est la bien plus grande diversité et précision des données et des actions mises à disposition du LLM pour obtenir les données nécessaires à mener à bien sa tâche (toutes et uniquement celles dont il a besoin).
Le LLM produisant lui-même une description de ce dont il a besoin, nous pouvons avoir un contexte plus précis, mais…
1) Le risque d’hallucinations, se traduit par des demandes mal formatées ; le système doit intégrer des boucles pour signaler au LLM que ses demandes sont incorrectes, afin qu’il réitère sa demande, ou demande des compléments d’informations, et également des garde-fous pour éviter des boucles infinies.
2) ces multiples allers-retours avec le LLM démultiplient à la fois le coût d’exécution, et le temps d’attente de l’utilisateur. De plus en plus (d’où le terme d’agents) il s’agit même de multiples instances du LLM dédiés chacune à une seule tâche ou un seul outil.
Intéressés pour en savoir plus sur la mise en œuvre de ces systèmes dans nos projets ? > voir notre deuxième article pour des exemples !
L'AUTEUR
