Exemples et few-shot prompting

Montrer plutôt que décrire

Fournir des exemples à Claude est l’une des techniques les plus efficaces du prompt engineering, et elle agit sur deux plans à la fois : obtenir la bonne réponse, et obtenir cette réponse dans le bon format. Là où une consigne décrit ce que vous voulez, un exemple le donne à voir — et un modèle de langage, entraîné à prolonger des motifs, exploite bien mieux un motif qu’une description.

Le vocabulaire est simple. Le few-shot prompting consiste à inclure quelques exemples dans le prompt. On parle de « zéro-shot » quand aucun exemple n’est fourni, de « one-shot » pour un exemple, de « n-shot » pour n exemples. Vous avez travaillé en zéro-shot jusqu’ici sans le savoir.

Quand cela vaut le détour

Trois situations justifient d’investir dans des exemples. La première : le format de sortie est précis et difficile à décrire en mots — essayez d’expliquer par écrit une indentation, un ordre de champs et une convention de casse, vous verrez que trois lignes d’exemple sont plus claires que trois paragraphes. La deuxième : vous visez un ton ou un style particulier, qui relève du ressenti plus que de la règle. La troisième : la tâche est complexe ou nuancée, et vos consignes finissent par se contredire à force d’ajouter des cas particuliers.

Régler le ton par l’exemple

Imaginons un chatbot destiné aux enfants. La réponse par défaut de Claude est formelle, un peu robotique, correcte mais froide. Vous pourriez rédiger un paragraphe sur le ton attendu ; il est plus rapide et plus fidèle de montrer un échange.

messages = [
    {"role": "user", "content": "Pourquoi le ciel est bleu ?"},
    {"role": "assistant", "content": "Oh super question ! Le ciel est bleu parce que la lumière du soleil rebondit sur les toutes petites particules dans l'air, et le bleu rebondit le plus !"},
    {"role": "user", "content": "Les dinosaures vont revenir ?"},
]

Remarquez la mécanique : l’exemple n’est pas décrit, il est joué dans la structure user/assistant. Claude voit un tour qu’il est censé avoir produit, avec son enthousiasme, ses phrases courtes et ses images concrètes, et il aligne naturellement le suivant.

Régler le format par l’exemple

Le même procédé s’applique à une extraction structurée. Plutôt que de détailler l’imbrication des balises, montrez-en une occurrence complète.

messages = [
    {"role": "user", "content": "Marie Curie etait physicienne."},
    {"role": "assistant", "content": "<individus>\n<personne>\n<nom>Marie Curie</nom>\n<profession>Physicienne</profession>\n</personne>\n</individus>"},
    {"role": "user", "content": "Albert Einstein etait physicien theoricien."},
]

Claude extrapolera le format à partir de l’exemple fourni : mêmes balises, même ordre, même façon de normaliser la profession avec une majuscule initiale. Ce dernier point mérite votre attention, car il est à double tranchant. Le modèle reproduit ce que l’exemple contient, y compris ce que vous n’aviez pas remarqué. Un exemple bâclé produit des sorties bâclées, très fidèlement.

Choisir ses exemples

La pertinence prime : vos exemples doivent ressembler aux cas réels que Claude traitera, pas à des cas d’école idéalisés. Ajoutez de la diversité en couvrant différents scénarios et cas limites, en particulier ceux qui vous ont posé problème en zéro-shot — un e-mail ambigu, une phrase sans profession identifiable, une entrée vide. Côté quantité, commencez avec trois à cinq exemples et ajoutez-en si nécessaire, en mesurant à chaque fois ce que vous y gagnez. Et retenez la règle qui rend la technique accessible : même un seul exemple vaut mieux que zéro.

L’exercice

Reprenez la classification d’e-mails de la leçon précédente, mais construisez-la cette fois en few-shot : montrez à Claude, par des exemples, le format de sortie attendu. La contrainte à respecter est précise — la dernière lettre de la réponse de Claude doit être la lettre de la catégorie. C’est le genre de spécification qu’une phrase d’instruction fait respecter à peu près, et qu’un exemple bien construit fait respecter systématiquement.