Qu’est-ce que l’ingénierie du contexte, et en quoi diffère-t-elle de l’ingénierie de prompts?

Depuis quelques semaines, l’expression « ingénierie du contexte » (context engineering) se répand rapidement chez les gens qui conçoivent des produits avec l’IA. Le PDG de Shopify, Tobi Lutke, a dit la préférer à « ingénierie de prompts » (prompt engineering), parce qu’elle décrit mieux la véritable compétence : donner au modèle tout le contexte dont il a besoin pour avoir une chance raisonnable de réussir la tâche. Andrej Karpathy, un chercheur en IA bien connu, a abondé dans le même sens, et des billets de blogue de Harrison Chase, de LangChain, et d’autres ont depuis tenté de cerner l’idée.

Ce changement de vocabulaire reflète un changement dans ce que les gens construisent. Un prompt est le texte que vous envoyez à un modèle. Une fenêtre de contexte est tout ce que le modèle peut lire d’un coup, mesuré en jetons (des morceaux de mots). Quand vous clavardez avec ChatGPT, votre prompt est l’essentiel de ce que vous contrôlez. Quand vous créez un agent, un programme qui permet à un modèle d’utiliser des outils et de faire plusieurs étapes, le prompt n’est qu’une petite tranche d’un contexte que votre code assemble automatiquement, différemment chaque fois.

La différence en un tableau

Harrison Chase décrit l’ingénierie de prompts comme un sous-ensemble du travail plus vaste. Des consignes claires comptent toujours, mais les autres morceaux comptent tout autant. Son test pratique mérite d’être retenu : quand un agent se trompe, demandez-vous s’il avait la bonne information et les bons outils. Sinon, la correction se trouve dans le contexte, pas dans la formulation. S’il avait tout et s’est quand même trompé, c’est le modèle ou les consignes qui posent problème.

Simon Willison, un développeur qui écrit beaucoup sur les modèles de langage, fait une remarque sur les mots eux-mêmes. Bien des gens entendent « ingénierie de prompts » comme un nom pompeux pour le fait de taper dans un robot conversationnel; l’expression n’a donc jamais rendu compte de l’effort en jeu. « Ingénierie du contexte » se prête moins aux malentendus.

Un exemple concret : une requête, de nombreuses parties

Prenons un assistant pour une petite entreprise, construit sur un modèle qui a accès à des outils. Un client écrit : « Est-ce que je peux déplacer mon rendez-vous de jeudi à la semaine prochaine? » Voici ce qu’un système bien conçu pourrait placer dans le contexte avant que le modèle voie le message. Le nombre de jetons est donné à titre d’illustration.

Les mots du client lui-même représentent environ 20 jetons sur quelque 1 500. Le reste décide si la réponse est utile. Sans la politique, le modèle risque d’inventer des frais. Sans la mémoire, il risque de proposer des plages l’après-midi. Sans l’outil list_free_slots, il ne peut que deviner ce qui est libre.

Philipp Schmid, un ingénieur en IA qui écrit sur les agents, donne un exemple semblable dans son survol : un assistant qui répond à une demande de réunion rapide fait beaucoup mieux quand il peut aussi voir votre calendrier, vos courriels passés avec cette personne et un outil pour envoyer une invitation.

Des principes qui s’appliquent à l’usage quotidien

Même sans écrire de code, les habitudes se transposent. Donnez au modèle les faits qu’il ne peut pas connaître; il ne peut lire ni dans vos pensées ni dans vos fichiers. Préférez un court résumé pertinent à un long déversement, puisque le fouillis fait concurrence à ce qui compte. Le format compte aussi : une liste bien rangée des heures d’ouverture est plus facile à utiliser pour un modèle qu’une page Web collée telle quelle. Et quand une conversation s’est égarée, une nouvelle conversation qui commence par un résumé propre fonctionne souvent mieux qu’un long historique embrouillé.

Que contient le contexte d’un agent, à part le prompt?

La plupart des descriptions énumèrent les mêmes briques. Le prompt système contient les consignes permanentes : rôle, règles, ton et parfois des exemples. Les définitions d’outils décrivent chaque fonction que l’agent peut appeler, avec son nom, son but et ses entrées, pour que le modèle sache ce qu’il peut faire et comment le demander. L’information récupérée, souvent appelée RAG (retrieval-augmented generation, génération augmentée par récupération), est du texte tiré de documents, de bases de données ou du Web pour cette requête.

Vient ensuite la mémoire. La mémoire à court terme est la conversation jusqu’ici, y compris les résultats des appels d’outils précédents, souvent condensée en résumé quand elle s’allonge. La mémoire à long terme est ce que le système conserve d’une session à l’autre, comme les préférences d’un utilisateur. Enfin, une définition de la sortie indique au modèle quelle forme sa réponse doit prendre, par exemple un objet JSON que le programme peut lire.

Le travail d’ingénierie consiste à choisir parmi ces éléments à chaque étape. Tout ce qu’on inclut coûte des jetons et de l’attention, et tout ce qui manque devient une supposition. Un bon agent charge ce dont l’étape suivante a besoin, laisse de côté ce qui ne sert pas et garde des consignes assez claires pour que le modèle sache quoi faire du reste.