- Tutoriel de prompt engineering proposé par Anthropic, qui guide de manière interactive et étape par étape la rédaction de prompts optimisés pour les modèles Claude
- Les utilisateurs peuvent s’exercer directement à la structure d’un bon prompt, aux cas d’échec, ainsi qu’aux techniques d’amélioration efficaces, afin de les assimiler concrètement
- Chaque chapitre inclut des exemples pratiques et leurs explications, pour offrir une expérience proche des usages réels
- Composé de 9 chapitres allant du niveau débutant à avancé, ainsi que d’annexes, il permet de développer ses compétences en rédaction de prompts et en résolution de problèmes
- Le tutoriel est aussi disponible en version Google Sheets, ce qui améliore son accessibilité et son utilité
Tutoriel interactif d’Anthropic sur le prompt engineering
- Ressource d’apprentissage open source fournissant des connaissances sur la conception de prompts optimisés pour le modèle d’IA Claude
- Semblable à un parcours d’apprentissage pour chatbot basé sur OpenAI, mais plus pertinent pour un usage professionnel grâce à son focus sur les points forts et les limites du modèle Claude, ainsi que sur la pratique concrète
- Le fait de pouvoir rédiger des prompts et expérimenter les résultats en parallèle constitue un avantage majeur, en particulier pour les ingénieurs débutants
Présentation du cours et objectifs
- Ce tutoriel explique étape par étape comment concevoir et utiliser des prompts optimaux dans Claude
- À l’issue du cours, l’utilisateur pourra acquérir les compétences suivantes
- Comprendre la structure d’un prompt efficace
- Identifier les schémas d’échec courants et les méthodes d’amélioration prioritaires (règle des 80/20)
- Cerner les forces et faiblesses du modèle Claude
- Développer une capacité à construire des prompts applicables à de nombreuses tâches générales
Structure du cours et contenu
- Le cours se compose de 9 chapitres (du niveau débutant à avancé) et d’annexes avancées
- Chaque chapitre combine explications théoriques et mise en pratique directe
- À la fin de chaque partie, un espace "Example Playground" permet de saisir directement des prompts et d’expérimenter les variations des réponses
- Une clé d’explication est fournie pour tous les exemples
- Le modèle de base du tutoriel est Claude 3 Haiku, le plus léger, rapide et économique. Des mentions de Sonnet et Opus, plus puissants, sont également incluses si nécessaire
- Il peut aussi être utilisé dans une version étendue Google Sheets, ce qui améliore l’accessibilité de l’apprentissage
Sommaire du programme
- Débutant
- Chapter 1: Structure de base d’un prompt
- Chapter 2: Comment rédiger des instructions claires et directes
- Chapter 3: Attribuer un rôle
- Intermédiaire
- Chapter 4: Séparer les données et les instructions
- Chapter 5: Définir le format de sortie et conversationnaliser Claude
- Chapter 6: Réflexion préalable (faire émerger un raisonnement étape par étape)
- Chapter 7: Comment utiliser des exemples
- Avancé
- Chapter 8: Prévenir les hallucinations (Hallucination)
- Chapter 9: Construire des prompts complexes (cas d’usage par secteur)
- Ex. : chatbot, services juridiques, services financiers, code, etc. — traitement de problèmes concrets selon différents métiers
- Annexe
- Méthodes allant au-delà du prompt standard
- Prompt chaining, utilisation d’outils, recherche / intégration des résultats de recherche, et autres techniques avancées
Guide d’utilisation
- Il est recommandé de suivre le tutoriel chapitre par chapitre, dans l’ordre
- Grâce à une pratique orientée usage réel et à des explications progressives, même un ingénieur débutant peut acquérir naturellement de véritables compétences en conception de prompts utilisables en situation professionnelle
- Tous les noms de produits et de modèles sont conservés dans leur forme d’origine, ce qui permet une utilisation immédiate dans des environnements de travail anglophones
Informations supplémentaires et open source
- Sur GitHub, le projet compte plus de 19 400 étoiles et 1 900 forks
- Le langage principal de développement est Jupyter Notebook, avec également un peu de code Python
- Il n’existe pas de package de distribution distinct, et l’ensemble des ressources peut être consulté librement en open source
1 commentaires
Avis Hacker News
L’usage du mot « engineering » dans ce contexte m’agace énormément ; je ne pense pas qu’on puisse appeler ça de la vraie ingénierie. L’ingénierie consiste à concevoir et construire de manière prévisible à partir de connaissances accumulées pendant des années, de lois physiques, de règles, etc., alors qu’ici on ne fait que tenter au hasard jusqu’à obtenir un résultat.
Je pense que tous les mots ont plusieurs sens ; dans « prompt engineering », « engineering » a une nuance proche mais différente, un peu comme dans « social engineering ». Par exemple, la définition n°2 de engineering selon Google est « l’action d’user de stratagèmes pour parvenir à un but ». On retrouve aussi clairement ce sens non technique — du type « manipulation habile » ou « élaboration d’un plan » — dans la 3e définition du Merriam-Webster, ainsi que dans le Collins Dictionary et YourDictionary. C’est un sens secondaire bien établi du mot.
Moi, je mange mes céréales en examinant les specs de la boîte de céréales. Je fais ça tous les matins, et j’applique aussi mes compétences d’ingénierie pour monter dans le bus, puisque je gagne ma vie grâce au prompt engineering. J’ai l’impression que trop de mots perdent aujourd’hui leur sens d’origine, donc ça me rassure de voir que je ne suis pas le seul que ça agace.
Je continue à préférer l’approche canadienne : pour utiliser le titre d’ingénieur, il faut être agréé par l’organisme de réglementation professionnelle de sa province. Aux États-Unis, j’ai l’impression qu’on va trop loin en appelant ingénieurs tous les développeurs logiciels, mécaniciens, installateurs HVAC et même plombiers.
Je pense qu’on pourrait en réalité adresser exactement la même critique au travail de nombreuses « engineering teams ». Il y a une hypothèse implicite selon laquelle, si c’est fait par des ingénieurs, alors c’est forcément de l’ingénierie ; et, plus profondément, une autre hypothèse sur le fait que le logiciel lui-même mérite ou non d’être qualifié de software engineering.
À mon avis, le mot « Engineering » est un procédé rhétorique destiné à donner aux gens l’impression qu’il ne s’agit pas simplement d’écrire des phrases. Honnêtement, si on disait « prompt writing », cela paraîtrait sans doute plus léger ; ce sera donc d’autant plus inconfortable pour ceux qui n’aiment déjà pas l’expression « soft skill ».
On dirait l’épisode du jour de « l’alchimie pour débutants ». Ça me rappelle un cas où la vitesse d’un algorithme avait augmenté de 30 % sur un benchmark quand on avait fixé la seed aléatoire à 7 — pas 8, pas 6, mais 7.
En lisant cet article, la prise de conscience importante pour moi a été de réfléchir à l’ordre de sortie des éléments. Par exemple, demander d’extraire d’abord les preuves ou les indicateurs avant de répondre. Je savais qu’un LLM est un autocompléteur probabiliste, mais je n’avais pas pensé à ce type de priming.
Cette approche ne s’applique peut-être pas aux modèles de reasoning. Les modèles de reasoning passent par le type de processus de pensée souhaité avant de donner une réponse, donc l’ordre de sortie influe moins sur la précision. C’est peut-être d’ailleurs pour ça qu’OpenAI cherche à imposer le reasoning.
Moi, je demande en général d’abord de courtes citations tirées de sources trouvées en ligne (quand c’est pertinent). Ça aide à compenser un peu la fiabilité de l’information. C’est quelque chose dont nous avons eu énormément besoin récemment dans notre organisation lors du déploiement de Cloudflare Zero Trust.
À l’inverse, si on demande d’abord la réponse puis les justifications, le modèle passe en « mode bullshit » : il sort une réponse arbitraire puis la rationalise de façon plausible. Il vaut bien mieux lui faire d’abord extraire objectivement les avantages et inconvénients, puis lui faire tirer une conclusion ; ses réponses deviennent alors beaucoup plus prudentes.
À mon avis, il vaudrait mieux ajouter « (2024) » au titre de cette soumission.
Pour les problèmes difficiles, le meilleur conseil de prompt engineering que je connaisse est « ouvrir puis resserrer ». Concrètement : commencer par présenter clairement le problème et le contexte, puis demander à l’IA d’analyser et de rechercher toutes les options et approches possibles afin d’ouvrir au maximum l’espace d’information ; ensuite, lui faire lister les avantages et inconvénients de chaque méthode, puis sélectionner la solution la plus adaptée. Pour un problème simple, on peut sauter tout ça et poser directement la question, mais sur un problème difficile, si on demande tout de suite la réponse, le modèle va juste inventer quelque chose de plausible. Il faut donc impérativement partir d’éléments réalistes. D’où ce flux : contexte précis → analyse des options → pros & cons → choix final.
Il faudrait ajouter 2024 au titre.
J’ai l’impression qu’on est en train d’apprendre à enseigner à l’IA le travail que nous faisions nous-mêmes, puis à lui demander efficacement de refaire ce travail. Si cette technologie n’est pas soutenue par l’ensemble de l’économie américaine, elle pourrait se gonfler comme une montgolfière à air chaud puis retomber d’un coup.
Comme d’autres commentaires, je ne ressens pas ça comme de l’ingénierie au sens classique. En revanche, je trouve qu’Anthropic a mené des recherches assez impressionnantes sur l’interprétabilité des modèles. Si cet outil était rendu disponible via une API publique, on pourrait peut-être comparer les différences d’état interne du modèle selon les prompts et créer une boucle de feedback pour un réglage plus systématique.
Ce tutoriel a été écrit pour trois modèles (Sonnet, Haiku, Opus 3). Certaines leçons restent valables aujourd’hui, mais certains éléments comptent moins pour des modèles RL plus intelligents (comme Sonnet 4.5). Pour référence, Claude 3 Haiku est le modèle le plus petit, le plus rapide et le moins cher ; Sonnet et Opus sont plus intelligents, et Opus est le plus performant.