Philipp Schmid : «La nouvelle compétence de l'IA n'est pas le prompting, mais l'ingénierie contextuelle».

Structurer dynamiquement le contexte permettrait de booster la pertinence des modèles d'IA, selon lui

Philipp Schmid : « La nouvelle compétence de l'IA n'est pas le prompting, mais l'ingénierie contextuelle ».
Structurer dynamiquement le contexte permettrait de booster la pertinence des modèles d'IA, selon lui

Depuis l’avènement des grands modèles de langage (LLM) tels que ChatGPT, Claude ou Mistral, l’art du prompting (formuler soigneusement une requête textuelle pour obtenir une réponse pertinente) est devenu l’une des compétences les plus recherchées dans le monde de l’IA générative. Des centaines de guides, tutoriels et formations promettaient de vous transformer en « prompt engineer ». Pourtant, à mesure que ces modèles deviennent plus puissants, une nouvelle compétence se distingue comme bien plus cruciale : l’ingénierie du contexte, ou context engineering.

C’est en tout cas la thèse défendue par Philipp Schmid, Senior AI Relation Engineer au sein de Google DeepMind. Selon lui, ce n’est plus tant comment vous posez la question à l’IA, mais ce que vous lui donnez à voir avant qu’elle ne réponde qui détermine la qualité du résultat.

L'intelligence artificielle, et plus particulièrement les modèles de langage de grande envergure (LLM), a révolutionné notre manière d'interagir avec la technologie. Pendant longtemps, l'accent a été mis sur le prompt engineering, l'art de formuler des instructions précises pour guider ces modèles vers les réponses souhaitées. C'était la compétence clé pour débloquer le potentiel des IA. Cependant, une évolution significative est en cours, soulignée par des experts comme Philipp Schmid : la véritable maîtrise de l'IA ne réside plus seulement dans le prompting, mais dans l'ingénierie de contexte.

Cette nouvelle approche, plus profonde et plus stratégique, reconnaît que la performance d'un modèle d'IA ne dépend pas uniquement de la clarté de la question posée, mais aussi de la richesse, de la pertinence et de la structure des informations qui lui sont fournies en amont. C'est l'idée que pour obtenir des résultats précis et fiables, il faut « éduquer » le modèle avec un environnement informatif bien pensé, plutôt que de simplement lui donner des ordres.


De quoi s'agit-il ? Le rôle fondamental du contexte

Un prompt n’est qu’une petite partie d’une interaction avec un modèle. Ce que l’on appelle contexte, c’est tout ce que l’IA peut consulter ou savoir au moment où elle produit une réponse :

• L’historique des conversations
• Les documents de référence (manuels, bases de données, CRM…)
• L’agenda ou les préférences d’un utilisateur
• Les outils qu’elle peut invoquer (ex. fonction send_email(), get_weather())
• Les métadonnées et résumés pertinents

Concrètement, un assistant personnel IA ne doit pas seulement savoir que « vous avez une réunion demain ». Il doit aussi :

• accéder à votre calendrier,
• comprendre la relation que vous avez avec votre interlocuteur,
• connaître les contraintes d’agenda de chacun,
• disposer d’une fonction lui permettant d’envoyer une invitation ou un message automatique.

C’est cette capacité à assembler, structurer et formater dynamiquement toutes ces données qui fonde l’ingénierie du contexte.

Philipp Schmid prend la peine de le préciser :


Qu'est-ce que l'ingénierie contextuelle ?

Pourquoi cette compétence devient stratégique ?

Alors que le prompt engineering est comparable à donner une instruction directe à un élève, l'ingénierie de contexte, c'est comme lui fournir une bibliothèque entière, des études de cas détaillées et un guide d'étude personnalisé avant même qu'il ne commence son devoir. Voici pourquoi cette distinction est cruciale :

Lever les ambiguïtés et préciser l'intention

Le langage humain est intrinsèquement ambigu. Un même mot ou une même phrase peut avoir plusieurs significations selon le contexte. Sans un cadre de référence clair, un LLM pourrait interpréter une requête de manière inattendue, menant à des réponses inexactes ou non pertinentes. L'ingénierie de contexte vise à éliminer cette ambiguïté en ancrant la requête dans des informations spécifiques.

Améliorer la précision et la pertinence des résultats

Les modèles d'IA, malgré leur vaste base de connaissances, peuvent parfois « halluciner », c'est-à-dire générer des informations incorrectes ou inventées. En fournissant des données factuelles et des exemples concrets directement dans le contexte, on réduit considérablement ce risque. L'IA n'a plus besoin de « deviner » ou d'inférer à partir de ses données d'entraînement génériques ; elle peut s'appuyer sur des faits vérifiés et des directives claires.

C'est particulièrement vrai pour les domaines de niche ou les informations très récentes qui n'auraient pas été incluses dans ses données d'entraînement initiales.

Gérer la complexité des tâches spécifiques

Certaines tâches, comme la rédaction de documents techniques complexes, l'analyse de données financières ou la génération de code spécifique à une API, dépassent largement les capacités d'un simple prompt. Ces tâches nécessitent une compréhension approfondie du domaine, l'application de règles spécifiques et souvent l'intégration de multiples sources d'information.

L'ingénierie de contexte permet de décomposer la complexité en fournissant à l'IA tous les éléments nécessaires : des extraits de documentation technique, des exemples de code, des schémas, ou même les résultats de calculs intermédiaires.

Exercer un contrôle granulaire sur la sortie

Au-delà de la justesse de l'information, le style, le ton, le format et la structure de la réponse sont souvent cruciaux. L'ingénierie de contexte offre un contrôle plus fin sur ces aspects. En incluant des exemples de réponses souhaitées, des directives de style ou des contraintes spécifiques, on peut sculpter la sortie de l'IA avec une plus grande précision.

Intégrer des connaissances externes et dynamiques

L'un des plus grands avantages de l'ingénierie de contexte est sa capacité à intégrer des sources de données externes et dynamiques aux LLM. Plutôt que de se limiter à ce qu'un modèle a appris lors de sa phase d'entraînement (qui est statique et souvent dépassée), on peut lui fournir des informations en temps réel : les dernières actualités boursières, les données d'un capteur IdO, les informations d'une base de données clients, ou le contenu d'une page web spécifique.

Et Philipp Schmid d'expliquer :

Le secret de la construction d'agents d'intelligence artificielle vraiment efficaces a moins à voir avec la complexité du code que vous écrivez, et tout à voir avec la qualité du contexte que vous fournissez. La construction d'agents est moins liée au code que vous écrivez ou au cadre que vous utilisez. La différence entre une démo bon marché et un agent « magique » réside dans la qualité du contexte que vous fournissez. Imaginez que l'on demande à un assistant IA de planifier une réunion sur la base d'un simple courriel :

« Hey, je voulais juste savoir si tu étais disponible pour une rapide synchronisation demain ».

L'agent « Démo bon marché » dispose d'un contexte médiocre. Il ne voit que la demande de l'utilisateur et rien d'autre. Son code peut être parfaitement fonctionnel - il appelle un LLM et obtient une réponse - mais le résultat est inutile et robotique :

« Merci pour votre message. Demain me convient. Puis-je vous demander à quelle heure vous pensiez ? »

L'agent « magique » est alimenté par un contexte riche. La tâche principale du code n'est pas de déterminer comment répondre, mais de rassembler les informations dont le LLM a besoin pour atteindre son objectif. Avant d'appeler le LLM, vous devez étendre le contexte pour y inclure

• Les informations de votre agenda (qui montrent que votre emploi du temps est chargé).
• Les courriels que vous avez échangés avec cette personne (pour déterminer le ton informel approprié).
• Votre liste de contacts (pour l'identifier comme un partenaire clé).
• Les outils pour envoyer_invitation ou envoyer_email.

Vous pouvez ensuite générer une réponse.

« Hey Jim ! Demain, c'est plein à craquer de mon côté. Jeudi matin libre si ça te convient ? J'ai envoyé une invitation, j'aimerais savoir si ça marche ».

La magie ne réside pas dans un modèle ou un algorithme plus intelligent. Il s'agit de fournir le bon contexte pour la bonne tâche. C'est pourquoi l'ingénierie contextuelle sera importante. Les échecs des agents ne sont pas seulement des échecs de modèle ; ce sont des échecs de contexte.


Le prompt engineering, qui a émergé avec l'essor de l'IA générative, est en voie d'extinction

Cette compétence a été particulièrement recherchée entre fin 2022 et 2024, avec des offres d'emploi proposant des salaires élevés. Aujourd'hui, avec les progrès de l'IA, l'industrie ne considère plus l'ingénierie de requête comme un rôle à part entière, mais simplement comme une compétence attendue.

Certaines entreprises utilisent même l'IA pour générer les meilleurs messages-guides pour leurs propres systèmes d'IA. Un rapport publié en avril 2024 suggère que l'IA a surpassé les humains en matière de persuasion. Le mois suivant, Anthropic a lancé un logiciel permettant à l'utilisateur de décrire ses objectifs et son chatbot Claude utilisera des techniques d'ingénierie de requête afin de créer « des requêtes beaucoup plus efficaces, plus précises et plus fiables ».

Cela accélère les itérations et permet aux utilisateurs de tester différents scénarios plus rapidement. Le logiciel est disponible via la console en ligne d'Antropic. Dès son lancement, l'outil a été perçu comme une menace pour l'avenir du métier naissant d'ingénieur de requête. Aujourd'hui, les offres d'emploi pour ce poste ont pratiquement disparu. Le déclin de l'ingénierie de requête est une mise en garde pour le marché de l'emploi dans le domaine de l'IA.

Pourquoi le métier d'ingénieur de requête disparaît-il rapidement ?

L'attrait de l'ingénierie de requête tenait en partie à sa faible barrière à l'entrée. Le poste ne nécessitait que peu d'expertise technique (ou pas du tout), ce qui en faisait une voie accessible aux personnes désireuses de rejoindre un marché en plein essor. Mais comme le poste était très généraliste, il était aussi facilement remplaçable. Les fabricants de chatbots ont rapidement inondé le marché d'outils permettant aux entreprises clientes de se passer de ces rôles.

Malcom Frank, PDG de TalentGenius, compare l'ingénierie de requête à des fonctions telles que « magicien Excel » et « expert PowerPoint » ; des compétences précieuses, mais pour lesquelles les entreprises ne recrutent généralement pas individuellement. Et les ingénieurs de requête ne sont peut-être pas les seuls rôles à disparaître. Malcolm Frank imagine un monde où les agents d'IA, qui prennent déjà forme, remplaceront les tâches de niveau inférieur.

Il explique : « l'IA se nourrit déjà d'elle-même. L'ingénierie de requête est devenue quelque chose d'intégré dans presque toutes les fonctions, et les gens savent comment s'y prendre. De plus, l'IA peut désormais vous aider à rédiger les messages parfaits dont vous avez besoin. C'est passé d'un travail à une tâche très, très rapidement ». De nombreux facteurs ont favorisé le déclin rapide du métier de l'ingénieur de requête pour l'IA, notamment :

• les IA comprennent mieux le langage naturel : les modèles les plus récents (comme GPT-4.5, Claude 3, Gemini 1.5, etc.) peuvent répondre de façon pertinente à des requêtes très simples. Il n’est plus nécessaire de formuler des instructions complexes ;
• des outils automatisent l'optimisation des requêtes : de nouveaux systèmes comme les agents autonomes ou les interfaces enrichies proposent eux-mêmes les bonnes requêtes, ou les génèrent à la place de l’utilisateur.

Source : Philipp Schmid

Et vous ?

Que pensez-vous de la réflexion de Philipp Schmid ? La trouvez-vous crédible ou pertinente ? Dans quelle mesure ?

Que pensez-vous de ces métiers de l'IA ? Estimez-vous qu'on peut les qualifier comme tel (métier) ou s'agit-il simplement, selon vous, de compétences parmi d'autres ?

Que pensez-vous des noms qui leur sont attribué (prompt engineering et autres) ?

Le prompt engineering est-il réellement dépassé ou simplement devenu une sous-discipline de la context engineering ?

Peut-on imaginer des cas où un bon prompt suffit, sans aucun contexte enrichi ? Quels sont ces cas limites ?

Où situer la frontière entre prompt et contexte : à partir de quand un prompt devient-il un système contextuel ?