- Le débat est en train de passer du « prompt engineering » au « context engineering », une étape plus avancée
- Le contexte ne désigne pas simplement une phrase de prompt, mais toutes les informations que le LLM peut voir avant de générer une réponse (instructions, historique de conversation, mémoire à long terme, informations externes, outils disponibles, etc.)
- La réussite ou l’échec d’un agent dépend désormais davantage de la qualité du contexte que des performances du modèle
- Les agents avancés intègrent divers éléments contextuels, comme le calendrier de l’utilisateur, ses anciens e-mails ou ses contacts, pour produire des réponses plus proches d’une vraie résolution de problème
- Le context engineering correspond à une conception de système dynamique adaptée à la situation, qui consiste à fournir au LLM les bonnes informations et les bons outils au moment opportun
Qu’est-ce que le Context Engineering ?
- Ces derniers temps, le terme « context engineering » se répand rapidement dans le domaine de l’IA
- Alors que le « prompt engineering » traditionnel se concentrait sur la conception d’une question ou d’une instruction unique, le context engineering constitue une approche bien plus large et plus puissante
- Tobi Lutke le définit comme « l’art de fournir tout le contexte nécessaire pour qu’un LLM puisse résoudre une tâche de manière fiable »
Les principaux éléments du contexte
- Dans un système d’agents, le bon fonctionnement dépend en grande partie des informations incluses dans la mémoire de travail (working memory)
- La plupart des échecs des agents ne viennent pas du modèle, mais d’un manque de contexte pertinent
Les composants du contexte
- Prompt système / instructions : consignes de base, exemples et règles qui définissent le comportement du modèle
- Prompt utilisateur : demande ou question immédiate de l’utilisateur
- État / historique de conversation : déroulé de la conversation en cours et informations de contexte associées
- Mémoire à long terme : conversations précédentes en plusieurs étapes, préférences de l’utilisateur, résumés d’anciens projets et ensemble d’informations que le modèle est amené à retenir sur la durée
- RAG (génération augmentée par la recherche) : informations récentes et hautement pertinentes récupérées depuis des documents externes, des bases de données, des API, etc.
- Outils disponibles : fonctions que le modèle peut appeler, définitions des outils intégrés (ex. :
check_inventory, send_email)
- Sortie structurée : définition du format de réponse que le modèle doit respecter (ex. : JSON)
Pourquoi le contexte est important
- En pratique, le facteur qui permet de créer des agents IA réellement efficaces n’est ni un code complexe ni la qualité du modèle, mais la pertinence du contexte fourni
- Là où un agent simple, « de démonstration », se contente de prendre la demande de l’utilisateur pour fournir une réponse de base, un agent « magique » produit des réponses bien plus utiles et humaines en tenant compte d’un contexte riche
- Comparaison
- Agent de faible qualité (démo) : il ne voit qu’une demande simple et produit une réponse stéréotypée. Ex. : à l’e-mail « Êtes-vous disponible demain ? », il répond mécaniquement « Oui, demain me convient. Quelle heure vous conviendrait ? »
- Agent de haute qualité (magique) : il peut exploiter son calendrier, l’historique des e-mails passés, des informations sur l’identité de l’interlocuteur, ainsi que les options d’appel d’outils nécessaires, afin de générer une réponse naturelle et adaptée à la situation. Ex. : « Je suis déjà complet demain, mais jeudi matin est libre ; je vous ai envoyé une invitation. Dites-moi si cela vous convient. »
- Ainsi, le facteur décisif n’est pas l’algorithme ni le modèle, mais la capacité à fournir le bon contexte pour la tâche donnée
- La plupart des échecs des agents IA résultent non pas du modèle, mais d’un échec dans la conception du contexte
De l’évolution du prompt engineering vers le context engineering
- Si le prompt engineering se concentre sur l’optimisation d’une instruction textuelle en une ligne, le context engineering englobe un champ bien plus large d’informations, d’outils et de conception structurelle
- Le context engineering est « la compétence professionnelle de conception et de construction consistant à fournir de manière systémique au LLM, dans le bon format et au bon moment, les informations et outils nécessaires pour lui permettre d’accomplir sa tâche »
Les caractéristiques du context engineering
- Conception du système dans son ensemble : le contexte n’est pas un simple template de prompt, mais le produit de tout le système qui opère avant l’appel au LLM
- Génération dynamique : sélection et traitement en temps réel de différentes informations comme le calendrier, les e-mails ou la recherche web, selon la tâche
- Fournir les bonnes informations et les bons outils au bon moment : le principe « Garbage In, Garbage Out » s’applique ; il est essentiel d’éviter de fournir au modèle des informations inutiles ou incomplètes
- L’importance de la clarté du format : lorsqu’on transmet des informations, il faut les résumer et les structurer plutôt que les empiler de manière désordonnée, et l’usage des outils doit aussi être communiqué clairement
Conclusion
- L’essence du développement d’agents IA puissants et fiables ne réside ni dans un « prompt magique » ni dans le modèle le plus récent, mais dans le context engineering (la conception et la fourniture du contexte)
- Cela va au-delà d’un simple problème technique : il faut une capacité de conception système globale, adaptée aux besoins et objectifs métier, incluant la définition des informations, des outils et des sorties structurées
- Le point clé est de fournir les bonnes informations dans le bon format au bon moment pour permettre au LLM d’accomplir sa tâche
Références
2 commentaires
On a surtout l’impression que seul le nom change.
Avis Hacker News
J’ai récemment écrit un billet de blog sur ce sujet, voir mon article - Context Engineering
Je pense que les articles de Drew Breunig traitent vraiment ce sujet de manière remarquable
Le timing a coïncidé avec une période où le mème « context engineering » circulait, mais en réalité ce travail n’avait rien à voir avec ce mème
L’article How Long Contexts Fail - pourquoi les longs contextes échouent explique de différentes façons comment les longs contextes causent des problèmes et comment apparaît ce qu’on appelle le « context rot »
L’article How to Fix Your Context - comment corriger votre contexte donne un nom à diverses techniques comme Tool Loadout, Context Quarantine, Context Pruning, Context Summarization et Context Offloading, et propose des façons de résoudre le problème
Je pense que les posts de Drew Breunig valent vraiment la lecture
C’est très important non seulement si l’on construit ses propres agents, mais aussi lorsqu’on utilise aujourd’hui du coding avec agents
Ces limites et ces modes de fonctionnement devraient rester avec nous pendant un certain temps
J’attends de voir qui développera en premier un Logic Core qui automatisera l’ingénieur du contexte
Je pense que cela aussi est une « compétence valable un mois »
Au final, cela disparaîtra vite comme tant d’autres modes
Ces problèmes sont considérés dans la recherche sur les LLM comme des produits des LLM actuels
Des recherches sont déjà en cours sur la manière d’utiliser simultanément des millions d’outils et des longs contextes stables
À l’avenir, sauf cas particuliers nécessitant une connexion à d’autres fournisseurs, un seul agent devrait suffire dans la plupart des situations
Ceux qui conçoivent des systèmes d’agents du futur à partir des LLM actuels risquent de finir comme LangChain
Comme LangChain conçu pour GPT-3, devenu presque immédiatement obsolète avec GPT-3.5
Pour quiconque a utilisé un LLM ou comprend son fonctionnement, c’est une chose assez évidente
Il était clair que la « compétence » de prompt engineering ne durerait pas longtemps en tant qu’idée centrale temporaire
Fondamentalement, il s’agit de donner au LLM des entrées (le contexte) et des actions (les sorties), avec beaucoup de travail de pipeline autour
Je suis d’accord avec la conclusion selon laquelle « construire des agents IA puissants et fiables s’éloigne de la recherche du prompt magique ou de la mise à jour de modèle »
Il est juste de dire qu’il faut davantage se concentrer sur le « context engineering, c’est-à-dire fournir les bonnes informations et les bons outils, dans le bon format et au bon moment »
Mais si ce « bon format » et ce « bon moment » ne sont pas définis en essence, n’est-ce pas encore une chasse à la « solution magique » ?
Si les « bonnes informations » sont celles « qui amènent le LLM à produire une réponse suffisamment correcte », alors je ne vois pas de différence essentielle avec le prompt engineering
Pour ces machines non déterministes, j’estime qu’il existe peu d’heuristiques fiables en dehors de l’approche « essayer un prompt et voir le résultat »
Au final, c’est une pensée magique sans fin
Même si l’on renomme aujourd’hui le « prompt engineering » en « context engineering », cela reste une activité consistant à bricoler dans tous les sens pour trouver quelque chose qui fonctionne dans un espace incertain
Au fond, c’est de l’overfitting
Le prompt engineering, c’est finalement cela
Le problème, c’est que « le bon format, le bon moment » ne sont pas définis en essence
La plupart des conseils sur la façon de « bien utiliser l’IA » partent en réalité de ce problème
Au final, cela donne l’impression de battre un tambour et de pratiquer un rituel chamanique
Dans les frameworks théoriques récents, ce processus est séparé en deux étapes : exploration (Exploratory) et découverte (Discovery)
La phase d’exploration peut être vue comme une sorte de dispositif de pulvérisation de matière en suspension
On y injecte à grande vitesse une substance marqueur facilement identifiable, généralement comparée à des excréments
La phase de découverte consiste à conceptualiser l’analyse du motif de dispersion
En résumé, ces deux étapes peuvent se formuler par « on tente au hasard » puis « on regarde le résultat »
Maintenant que tout le monde a compris que le « prompt engineering » n’était pas une compétence si extraordinaire, on a l’impression que l’industrie de l’IA déplace sans cesse les critères de l’objectif
La nouvelle compétence, au final, c’est la « programmation »
La même compétence qu’avant
Pour comprendre ces choses, il faut écrire soi-même des programmes
En écrivant des programmes pour entraîner des LLM, lancer l’inférence et analyser leur comportement, on comprend progressivement de plus en plus de choses
Au départ, j’avais une théorie et des résultats attendus, mais après avoir réellement entraîné des LLM de différentes façons, j’en suis arrivé à des résultats et des convictions complètement différents
Le fait d’implémenter concrètement les outils fait toute la différence
Moi aussi, je n’ai qu’une expérience intermédiaire en programmation de machine learning, mais je pense que le fait d’avoir construit moi-même un compilateur de niveau intermédiaire est la clé pour obtenir de bons résultats sur des systèmes complexes
Comment pensez-vous que Karpathy en est arrivé là ?
La réponse se trouve sur le blog de Karpathy
C’est comme conseiller d’écrire un compilateur pour comprendre les compilateurs
C’est techniquement vrai, mais la plupart des gens n’ont pas envie d’aller aussi loin
J’ai l’impression que cette discussion ressemble de plus en plus à des forums de jeux comme WoW, où les joueurs testent des stratégies et se disputent avec un jargon collectif étrange
Les soi-disant stratégies sont presque toujours trouvées par essais et erreurs, puis discutées dans une langue compréhensible uniquement à l’intérieur du groupe
La programmation, elle aussi, s’adapte de plus en plus à une ère de gamification
On voit des power users vendre de fausses stratégies à des débutants ou à des dirigeants excessivement joueurs
En réalité, la même chose s’est déjà répétée pendant les précédentes modes de l’enterprise software
Cette fois, la différence est simplement que cette « mode menée par les power users » pénètre profondément jusque dans les zones d’influence, de contrôle et de workflow que les développeurs, c’est-à-dire les builders, détenaient auparavant
Ce que ressentent aujourd’hui les développeurs n’est sans doute pas différent de ce qu’ont ressenti autrefois les personnes en QA, SRE ou CS lorsqu’on leur imposait des outils ou des pratiques au nom du « c’est la nouvelle norme ! »
Conclusion :
« Construire des agents IA puissants et fiables ne dépend pas d’un prompt magique ni d’une mise à jour de modèle, mais du context engineering : fournir les bonnes informations et les bons outils, dans le bon format et au bon moment, pour l’usage métier visé »
En réalité, ce même principe s’applique aussi aux humains
Si on leur donne les bonnes informations au bon moment, les humains résolvent eux aussi mieux les problèmes
Je n’aime pas cette tendance aux comparaisons superficielles entre machine learning et humains
Cela n’apporte aucun éclairage, et ce n’est presque jamais juste
Au fond, il s’agit simplement de trouver et d’appuyer efficacement sur le bouton objectif dans un environnement
Ce n’est pas très différent du software engineering classique
Les résultats sont juste plus non déterministes
J’ai toujours demandé sans relâche aux équipes UX et produit des explications sur les mockups, les exigences, les critères d’acceptation, des exemples d’input et d’output, ainsi que sur l’importance de telle fonctionnalité
Tant qu’on ne peut pas scanner un cerveau pour en extraire ce que quelqu’un veut, il est indispensable d’expliquer correctement ce qu’on attend
Ce n’est pas quelque chose qu’on peut laisser au simple « feeling »
La clé, ce n’est pas plus de contexte, mais un meilleur contexte
(exemple typique : le X-Y problem)
Même si l’on fournit un contexte excellent aux LLM les plus récents, ils échouent encore
Dans notre entreprise, cela fait déjà plus de deux ans que nous explorons ce sujet en profondeur
Il est surprenant de voir à quel point la croyance selon laquelle « le contexte est la réponse » est forte
À partir d’un certain point, je pense qu’il est plus rapide de faire le travail directement sans IA
Au moins, cela laisse une leçon utile, contrairement au fait de passer des heures à générer du contexte pour un LLM
Je serais curieux de voir des cas où un LLM échoue malgré un contexte suffisant
Ce serait bien de partager des exemples concrets
La recherche du prompt magique n’a jamais vraiment été ce qu’était le « prompt engineering »
Au fond, cela a toujours été du « context engineering »
Beaucoup de prétendus experts de l’IA ont vendu cela comme du prompt engineering, mais sans vraiment en comprendre la substance
Le RAG (retrieval-augmented generation) n’est pas un concept apparu soudainement cette année
Les outils qui encapsulent des savoir-faire complexes autour des embeddings, des bases vectorielles, des bases graphe, etc., se démocratisent de plus en plus
Les grandes plateformes améliorent elles aussi leurs outils associés pour offrir un écosystème plus riche
On a toujours l’impression qu’on invente un nouveau concept pour le même problème, puis qu’on se contente d’en changer le nom
Au final, c’est toujours la répétition d’un rituel chamanique consistant à battre le tambour devant un feu de camp et à réciter des incantations
J’avais l’impression d’invoquer un démon et d’espérer qu’en prononçant la bonne formule avec les bons mots, il obéirait correctement à mes ordres
En moi, l’ingénieur qui veut de la fiabilité, de la reproductibilité et une forte couverture de tests se heurte à la complexité incontrôlable actuelle
J’ai beaucoup de respect pour ceux qui font des démos à grande échelle avec de tels systèmes
Cela me rappelle l’époque des démos de recherche sur les failles de sécurité
Même avec une excellente préparation, le résultat pouvait dérailler à tout moment sur place, et je me souviens avoir transpiré à grosses gouttes pendant les présentations
C’est un point de vue très proche de mon expérience
Quand j’ajoute du contexte à un LLM, je me pose souvent la question : « Un humain pourrait-il résoudre cela avec ces seules informations ? »
Quand je construisais autrefois un produit text2SQL, si le modèle échouait, un vrai analyste de données répondait lui aussi parfois : « Ah, cette table est ancienne. Maintenant, il faut utiliser celle-ci. »
Au final, si le LLM n’a pas le contexte dont un « analyste humain » a besoin, il se trompe
S’il y a une chose absente de ce sujet, c’est bien « l’évaluation » (evaluations)
Je suis encore surpris de voir tant de projets IA sans évaluations, ou avec des évaluations bâclées
Les évaluations sont encore plus importantes que les tests dans l’ingénierie traditionnelle
Il n’est pas nécessaire d’avoir un énorme ensemble d’évaluation ; il suffit qu’il couvre bien le domaine du problème
Sans cela, on n’a que des « suppositions »
Et moi aussi, je me demande souvent : « Un humain pourrait-il résoudre cela avec ces seules informations ? »
Il m’est arrivé d’attendre d’un LLM qu’il résolve des problèmes qu’un humain ne pourrait même pas résoudre
Une loi classique de la programmation informatique
« Si l’on propose de permettre aux programmeurs de coder en anglais, on découvre en réalité que les programmeurs n’écrivent déjà pas très bien en anglais »
C’est une plaisanterie, mais avec une part de vérité
La plupart des langues naturelles ne sont pas si claires que cela
Si vous pouviez exprimer avec une grande précision ce que vous voulez en anglais, vous auriez sans doute tout aussi bien pu l’écrire directement dans un langage interprétable par la machine
Si l’on pose une question oui/non
il y a 50 % de chances d’obtenir une réponse fausse
C’est le genre de caractéristique qu’ils ont
Avant que le modèle ne commence réellement à travailler, je lui fais souvent poser ce genre de questions d’abord
Par exemple, je lui donne comme consigne de poser des questions en cas d’incertitude, et de demander des exemples de patterns de code existants
J’essaie de l’amener à prendre pour exemples des templates déjà utilisés
Les gens qui jouent au data scientist ne veulent pas d’évaluations
C’est pourquoi, en dehors des produits réellement monétisés, il n’y a presque pas d’évaluations
Dire que « le roi est nu » ne rapporte pas d’argent
Mais dès qu’il y a un véritable besoin opérationnel, un travail d’évaluation est forcément mis en place