Fournir des exemples

Dernière technique de la section, et l’une des plus efficaces de tout le répertoire : fournir des exemples dans vos prompts. Cette approche, appelée « one-shot » ou « multi-shot prompting » selon le nombre d’exemples, consiste à donner à Claude des paires entrée/sortie pour guider ses réponses — exploiter la force la plus profonde des modèles de langage : leur capacité à généraliser depuis des démonstrations. Là où une consigne décrit le comportement attendu, un exemple le montre.

Comment ça marche

Prenons un cas où décrire ne suffit pas : l’analyse de sentiment. Vous voulez que Claude catégorise un tweet comme positif ou négatif. Le défi : le sarcasme. Un tweet comme « Ah oui, c’était vraiment le meilleur film depuis “Plan 9 from Outer Space” » semble positif en surface — tous les mots le sont —, mais c’est du sarcasme (Plan 9 from Outer Space est un film notoirement mauvais). Écrire « attention au sarcasme » dans la consigne aide peu : encore faut-il que le modèle sache à quoi ressemble le sarcasme dans vos données, avec leur ton et leur format.

Ajouter des exemples au prompt

C’est exactement ce qu’un exemple transmet. Les éléments clés d’un exemple bien intégré :

• Introduction claire : « Voici un exemple d’entrée avec une réponse idéale »
• Balises XML pour la structure : <sample_input> et <ideal_output>
• Exemples concrets qui démontrent le comportement souhaité

Les balises jouent ici un rôle de sécurité autant que de clarté : sans elles, Claude pourrait confondre l’exemple avec le texte à analyser — et « répondre » à votre exemple au lieu de la vraie entrée.

Gérer les cas limites

Pour les scénarios délicats comme le sarcasme, utilisez plusieurs exemples (multi-shot prompting) :

Soyez particulierement attentif aux tweets contenant du sarcasme.
Par exemple :

<sample_input>
Oh super, j'avais vraiment besoin d'un retard de vol ce soir ! Excellent !
</sample_input>
<ideal_output>
Negatif
</ideal_output>

La paire montre le mécanisme exact à détecter — enthousiasme de surface, situation négative — et le verdict attendu. Le modèle n’applique plus une règle abstraite : il reconnaît une similarité avec un cas résolu.

Quand utiliser des exemples

Trois situations où les exemples paient le plus : capturer des cas limites ou des scénarios atypiques — le sarcasme, les ambiguïtés, tout ce que les consignes générales ratent ; définir des formats de sortie complexes — une structure JSON précise se montre mieux qu’elle ne se décrit ; et montrer à Claude exactement à quoi ressemble une « bonne » sortie — niveau de détail, ton, organisation, tout ce qui est difficile à verbaliser.

Trouver de bons exemples

Reste à savoir quoi montrer, et votre pipeline d’évaluation a déjà la réponse : dans vos évaluations de prompts, cherchez les sorties ayant les meilleurs scores. Copiez l’entrée et la sortie d’une réponse qui a obtenu un 10 (ou votre meilleur score) pour l’utiliser comme exemple. La boucle est élégante : le pipeline génère des dizaines de sorties, l’évaluateur identifie les championnes, et ces championnes deviennent la démonstration qui tire les futures réponses vers leur niveau — vos exemples sortent de vos données, certifiés par vos propres critères.

Ajouter du contexte aux exemples

Rendez les exemples encore plus efficaces en expliquant pourquoi ils sont bons :

<ideal_output>
[Votre exemple de sortie ici]
</ideal_output>

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

Cela aide Claude à comprendre non seulement quoi produire, mais pourquoi cette sortie est considérée comme idéale — sans l’explication, il doit deviner ce qui fait la qualité de l’exemple : le style ? la longueur ? la précision ? L’explication désigne les propriétés à reproduire.

Bonnes pratiques

La forme compte autant que le fond : structurez vos exemples avec des balises XML (<example>, <ideal_output>) pour que Claude distingue sans ambiguïté ce qui relève de l’exemple et ce qui relève de la consigne, et annoncez explicitement ce que vous lui montrez — « voici une entrée type et la sortie attendue » vaut mieux qu’un bloc collé sans explication. Sur le choix des exemples, deux critères se complètent : la représentativité, en couvrant vos cas d’usage les plus fréquents, et la difficulté, en incluant les cas limites qui piègent le modèle — c’est là que les exemples ont le plus d’impact, car les cas faciles réussissent de toute façon. Enfin, quand la qualité d’un exemple ne saute pas aux yeux, dites pourquoi il est bon : une ligne de justification (« notez que le résumé conserve les chiffres exacts ») transmet le critère, pas seulement le résultat.

Points clés à retenir

• Un exemple montre ce qu’une consigne décrit — décisif sur le sarcasme, les nuances, les formats complexes
• Balisez chaque paire <sample_input>/<ideal_output> et annoncez-la : jamais d’exemple collé sans cadre
• Multi-shot pour les cas limites récurrents ; chaque exemple coûte des tokens à chaque requête
• Recrutez vos exemples parmi les sorties les mieux notées par votre pipeline d’évaluation
• Expliquez pourquoi un exemple est idéal : le critère se transmet mieux que le seul résultat