Aller au contenu principal

Fournir des exemples

Mis à jour le 30 juillet 2026

Dernière technique de la section, et l’une des plus efficaces du répertoire : fournir des exemples dans vos prompts — un seul (one-shot) ou plusieurs (multi-shot). L’idée exploite une force profonde des modèles de langage : ils généralisent remarquablement bien à partir de démonstrations. Là où une consigne décrit le comportement attendu, un exemple le montre — et sur les tâches subtiles, montrer bat décrire.

Le problème du sarcasme

Voici une tâche où les consignes seules plafonnent : l’analyse de sentiment. Un tweet comme « Ouais, bien sûr, c’était le meilleur film que j’aie vu depuis “Plan 9 from Outer Space” » semble positif en surface — tous les mots le sont — mais est en réalité sarcastique et négatif. Vous pouvez écrire « attention au sarcasme » dans la consigne : encore faut-il que le modèle sache à quoi le sarcasme ressemble dans vos données, avec leur ton et leur format.

Ajouter un exemple

C’est exactement ce qu’un exemple apporte :

Attention au sarcasme.
Par exemple :
<sample_input>
Oh oui, j'avais vraiment besoin d'un retard de vol ce soir ! Excellent !
</sample_input>
<ideal_output>
Negatif
</ideal_output>

La paire entrée/sortie donne à Claude un patron clair : voilà une phrase enthousiaste en surface, voilà le verdict correct. Le modèle n’applique plus une règle abstraite, il reconnaît une similarité — « ce tweet ressemble à l’exemple, même mécanisme d’ironie, donc négatif ». Notez la structure : des balises XML dédiées (<sample_input>, <ideal_output>) séparent proprement l’exemple des consignes et du texte à traiter, sans risque de confusion.

Formats de sortie complexes

Les exemples brillent sur un second terrain : les sorties structurées — JSON imbriqué, rapports au gabarit précis. Décrire un format complexe en toutes lettres (« un objet avec un champ items qui contient… ») est long, ambigu et fragile ; au lieu de décrire le format, montrez à quoi ressemble une bonne sortie. Une seule sortie modèle fixe d’un coup la structure, les noms de champs, la casse et le niveau de détail — tout ce qu’une description énumère laborieusement.

Trouver de bons exemples via les évaluations

Reste à savoir quoi montrer — et votre pipeline d’évaluation a déjà la réponse. Dans vos rapports, cherchez les sorties ayant obtenu le score maximal (10/10) et utilisez-les comme exemples dans votre prompt. La boucle est élégante : le pipeline génère des dizaines de sorties, l’évaluateur identifie les meilleures, et ces championnes deviennent la démonstration qui tire toutes les futures réponses vers leur niveau. Vos exemples ne sortent pas de votre imagination — ils sortent de vos données, certifiés par vos propres critères.

Ajouter du contexte aux exemples

Un raffinement qui augmente encore le rendement : après l’exemple, expliquez pourquoi il est idéal :

Ce plan alimentaire est bien structure, fournit des informations detaillees
sur les choix alimentaires et les quantites, et correspond aux objectifs
et restrictions de l'athlete.

Sans cette explication, Claude doit deviner ce qui fait la qualité de l’exemple — est-ce le style ? la longueur ? la précision des quantités ? L’explication lève l’ambiguïté : elle désigne les propriétés à reproduire, et transforme une imitation de surface en imitation des bonnes raisons.

Bonnes pratiques

La méthode la plus sûre est incrémentale. Structurez d’abord vos exemples avec des balises XML pour les séparer proprement des consignes, puis commencez avec un seul exemple bien choisi : dans beaucoup de cas, il suffit, et chaque exemple supplémentaire coûte des tokens à chaque requête. N’en ajoutez que là où le modèle échoue réellement — c’est sur les cas limites difficiles que les exemples paient, pas sur les cas que Claude réussit déjà sans aide. Quand la tâche implique un raisonnement, montrez-le dans l’exemple plutôt que le seul résultat : un exemple qui déroule le cheminement apprend la méthode, pas seulement la forme. Et bouclez avec l’évaluation vue dans les leçons précédentes : ce sont vos résultats de tests, pas votre intuition, qui désignent les cas où un exemple de plus fera progresser le score.

Points clés à retenir

  • Un exemple montre ce qu’une consigne décrit — sur les tâches subtiles (sarcasme, nuances), montrer gagne
  • Balisez chaque paire <sample_input>/<ideal_output> pour la séparer des consignes
  • Pour les formats complexes, une sortie modèle vaut mieux que toute description du format
  • Recrutez vos exemples parmi les sorties notées 10/10 par votre pipeline d’évaluation
  • Incrémental : un exemple bien choisi d’abord, et n’ajoutez que là où les scores montrent un échec