Fournir des exemples — Construire avec l'API Claude

One-shot vs multi-shot

Il existe une limite à ce qu’une instruction peut transmettre, et elle apparaît toujours au même endroit : quand le résultat attendu dépend d’un jugement plutôt que d’une règle. Décrire ce qu’est un « ton professionnel mais chaleureux » demande un paragraphe et reste flou ; en montrer un exemple règle la question en trois lignes.

C’est là toute la logique de cette leçon : l’exemple ne remplace pas l’instruction, il prend le relais là où elle plafonne.

Zero-shot : pas d’exemple, uniquement des instructions
One-shot : un seul exemple d’entrée/sortie
Multi-shot : plusieurs exemples couvrant différents cas

Plus la tâche est ambiguë ou le format de sortie complexe, plus les exemples sont nécessaires.

Le problème : les cas ambigus

Prenons l’analyse de sentiment. Pour des phrases directes, Claude s’en sort bien sans exemple :

“Ce produit est génial !” → Positif (facile)
“Service déplorable.” → Négatif (facile)

Mais le sarcasme et l’ironie posent problème :

“Bravo, 3 semaines de livraison pour un t-shirt, vraiment impressionnant.” → ?

Ce cas illustre pourquoi l’instruction ne suffit pas. Vous pourriez écrire « attention au sarcasme » : le modèle en tiendra compte, mais il devra deviner ce que vous appelez du sarcasme, et cette frontière varie selon les domaines. Un seul exemple correctement étiqueté fixe la frontière sans discussion possible. Sans exemple, Claude peut interpréter le “Bravo” et “impressionnant” comme positifs. Avec un exemple de sarcasme correctement classifié, il comprend immédiatement le pattern.

Structure d’un exemple avec XML

Utilisez des balises explicites pour séparer l’entrée de la sortie attendue :

<exemple>
  <sample_input>
  Wow, 45 minutes d'attente pour un cafe. Quelle efficacite remarquable.
  </sample_input>
  <ideal_output>
  Sentiment : Negatif
  Confiance : 0.9
  Note : Sarcasme detecte. Les mots "Wow" et "remarquable" sont utilises ironiquement
  pour exprimer une frustration face au temps d'attente excessif.
  </ideal_output>
</exemple>

Exemple complet : analyse de sentiment avec sarcasme

<instructions>
Analyse le sentiment du texte fourni. Classifie-le en Positif, Negatif ou Neutre.
Indique ton niveau de confiance (0 a 1) et explique ton raisonnement en une phrase.
Sois attentif au sarcasme et a l'ironie.
</instructions>

<exemple>
  <sample_input>
  Ah super, encore une mise a jour qui casse tout. Merci les developpeurs !
  </sample_input>
  <ideal_output>
  Sentiment : Negatif
  Confiance : 0.95
  Note : Sarcasme. "Super" et "Merci" sont ironiques, l'utilisateur critique
  une mise a jour qui a cause des problemes.
  </ideal_output>
</exemple>

<exemple>
  <sample_input>
  Le support client m'a rappele en 10 minutes et a resolu mon probleme du premier coup.
  </sample_input>
  <ideal_output>
  Sentiment : Positif
  Confiance : 0.95
  Note : Expression sincere de satisfaction. Rapidite (10 minutes) et efficacite
  (premier coup) sont des indicateurs positifs sans ambiguite.
  </ideal_output>
</exemple>

<texte_a_analyser>
{texte_utilisateur}
</texte_a_analyser>

Quand fournir des exemples

Les exemples sont particulièrement utiles dans ces situations :

Cas limites et ambigus

Sarcasme, ironie, formulations à double sens. Un exemple bien choisi vaut une longue explication.

Formats de sortie complexes

Si vous attendez un format spécifique (JSON avec des clés précises, tableau avec des colonnes exactes), un exemple montre le format mieux que n’importe quelle description.

<exemple>
  <sample_input>Reseau neuronal convolutif</sample_input>
  <ideal_output>
  {
    "terme": "Reseau neuronal convolutif",
    "acronyme": "CNN",
    "definition_simple": "Un type d'IA spécialisé dans l'analyse d'images",
    "analogie": "Comme un oeil qui apprend a reconnaître des formes",
    "niveau": "intermediaire"
  }
  </ideal_output>
</exemple>

Style ou ton spécifique

Si vous voulez un ton particulier (pédagogique, humoristique, corporate), un exemple ancre le style mieux que des adjectifs.

Entrées ambiguës

Quand les mêmes données pourraient être traitées de plusieurs façons, l’exemple clarifie votre intention.

Trouver de bons exemples

Voici le point qui relie ce chapitre au précédent, et il vaut de l’or en pratique : vous avez déjà les exemples, vous ne le savez pas. Les meilleures sorties de votre évaluation sont, par définition, des paires entrée/sortie validées par un score — exactement ce qu’un exemple doit être. La meilleure source d’exemples est donc votre pipeline d’évaluation. Quand vous évaluez un prompt :

Identifiez les sorties qui ont obtenu les meilleurs scores
Utilisez-les comme exemples dans votre prompt
Re-évaluez pour mesurer l’impact

C’est un cercle vertueux : les meilleures sorties deviennent les exemples qui améliorent les sorties suivantes.

Ajouter du contexte aux exemples

Un exemple brut montre le « quoi » ; un exemple commenté explique le « pourquoi ». La différence est décisive pour la généralisation : sans explication, le modèle peut retenir un détail accessoire de votre exemple — la longueur, un mot particulier — au lieu du principe que vous vouliez illustrer. L’explication lui dit ce qu’il faut reproduire et ce qui n’était qu’accidentel.

<exemple>
  <sample_input>
  Ce restaurant etait pas mal du tout.
  </sample_input>
  <ideal_output>
  Sentiment : Positif
  Confiance : 0.7
  Note : "Pas mal du tout" est une litote francaise exprimant une appreciation
  moderee mais reelle. Confiance moyenne car l'intensite du sentiment est ambigue.
  </ideal_output>
  <explication>
  Cet exemple illustre comment traiter les litotes, frequentes en francais.
  "Pas mal" semble negatif syntaxiquement mais exprime un sentiment positif.
  La confiance est volontairement basse car l'intensite est difficile a quantifier.
  </explication>
</exemple>

La balise <explication> aide Claude à comprendre la logique derrière l’exemple, pas seulement le résultat.

Bonnes pratiques

Utilisez des balises XML pour structurer vos exemples (<sample_input>, <ideal_output>)
Soyez explicite sur ce qui fait qu’un exemple est bon ou mauvais
Ciblez les cas de défaillance — les exemples ont le plus d’impact là où Claude échoue
2-3 exemples suffisent dans la plupart des cas — inutile d’en mettre 10
Variez les exemples — couvrez des cas différents, pas des variations du même cas
Ajoutez du contexte quand le “pourquoi” n’est pas évident

Points clés

One-shot (1 exemple) suffit souvent pour les formats de sortie et les cas simples
Multi-shot (2-3 exemples) est nécessaire pour les cas ambigus et le sarcasme
Structurez les exemples avec <sample_input> et <ideal_output>
Les meilleurs exemples viennent de vos évaluations (sorties ayant obtenu les meilleurs scores)
Ajoutez une <explication> pour clarifier le raisonnement derrière l’exemple
Les exemples sont la technique la plus efficace pour les cas limites que les instructions seules ne résolvent pas