Du prompt engineering au context engineering : la revanche des ingénieurs

On m'a souvent demandé si "prompt engineer" devait devenir un métier, s'il fallait créer un poste, se former, etc. Ma conviction était qu'il n'y en avait pas véritablement besoin. D'une part, parce que des utilisateurs métiers aguerris étaient tout à fait capables de peaufiner leurs prompts eux-mêmes. D'autre part, parce que des experts pouvaient intervenir sur des prompts systèmes, cachés, de manière ponctuelle, sans que cela ne devienne un métier ou ne requière une compétence technique pointue.

Puis les LLM ont gagné en performance et, aujourd'hui, votre maîtrise du prompt importe finalement moins. Ce qui importe en revanche, c'est la maîtrise du contexte que vous fournissez à votre LLM pour garantir la meilleure réponse possible. Typiquement, lui balancer l'intégralité des 312 PDF de votre dossier pour lui demander de répondre à une question précise vous apportera plus de frustration que de satisfaction. Et pourrait coûter très cher (pour rien). C'est pourquoi on entend aujourd'hui de plus en plus parler de "context engineering".

Maintenant qu'Andrej Karpathy, l'ancien monsieur IA de Tesla, a adoubé le terme, je crois que nous pouvons en parler sereinement.

Tweet d'Andrej Karpathy sur X : https://x.com/karpathy/status/1937902205765607626

Andrej Karpathy QRT un tweet de Tobi Lutke, le patron de Shopify, qui disait préférer en terme de "context engineering" plutôt que celui de "prompt engineering", en disant ceci [traduit en français par mes soins] :

"Les gens associent les prompts à de courtes descriptions de tâches qu'on donnerait à un LLM dans son usage quotidien. Alors que dans toute application LLM de niveau industriel, l'ingénierie de contexte est l'art délicat et la science qui consiste à remplir la fenêtre de contexte avec exactement les bonnes informations pour l'étape suivante. Une science, parce que bien faire cela implique des descriptions et explications de tâches, des exemples few-shot, du RAG, des données connexes (possiblement multimodales), des outils, l'état et l'historique, la compression... Trop peu ou sous la mauvaise forme, et le LLM n'aura pas le bon contexte pour une performance optimale. Trop ou trop peu pertinent, et les coûts du LLM peuvent augmenter et les performances peuvent diminuer. Bien faire cela n'est franchement pas trivial. Et c'est un art, parce qu'il faut exercer son intuition autour de la psychologie des LLM et de l'esprit des gens.

En plus de l'ingénierie de contexte elle-même, une application LLM doit :

décomposer les problèmes de la bonne façon en flux de contrôle
remplir les fenêtres de contexte de la bonne manière
dispatcher les appels vers les LLM du bon type et avec les bonnes capacités
gérer les flux d'interface génération-vérification
s'occuper de beaucoup d'autres choses : garde-fous, sécurité, évaluations, parallélisme, préchargement...

Donc l'ingénierie de contexte n'est qu'une petite partie d'une couche logicielle épaisse émergente et non-triviale qui coordonne les appels individuels aux LLM (et bien plus) en applications LLM complètes. Le terme "wrapper ChatGPT" est obsolète et vraiment, vraiment faux."

Pour bien faire comprendre cette notion de contexte, Andrej Karpathy utilise également une analogie pertinente, celle de la limitation de la RAM dans un ordinateur : le processeur utilise les diverses informations qui y sont temporairement stockées pour accomplir sa tâche. Cela nécessite des arbitrages et une excellente connaissance des modèles et des mécanismes mis en œuvre. Pour un ordinateur, nous faisons confiance aux programmeurs.

Alors que nous envisageons aujourd'hui des SI agentiques, il est crucial de travailler le "context engineering" avec des ingénieurs qui comprennent cette problématique, pour éviter un fort effet déceptif.