Module 3 — Sans exemple, avec un exemple, avec plusieurs exemples

Une consigne peut décrire une tâche, ou la montrer. Ce module compare les trois régimes — zéro, un, plusieurs exemples — et donne des règles pour choisir sans tester à l'aveugle.

Trois régimes, un seul critère de choix

Le vocabulaire est stabilisé :

• Sans exemple (zero-shot) : la consigne décrit la tâche, aucun cas résolu n'est fourni.
• Un exemple (one-shot) : un unique paire entrée/sortie précède le cas à traiter.
• Plusieurs exemples (few-shot) : trois à dix paires précèdent le cas.

Le critère de choix n'est pas la difficulté ressentie, c'est la description écrite suffit-elle pour un humain qui ne connaît pas votre domaine ?. Si oui, zéro exemple. Sinon, un ou plusieurs, jusqu'à ce que la performance mesurée sur le jeu de test se stabilise.

Sans exemple sur le fil rouge

Notre consigne système du module 2 est purement descriptive : elle liste les valeurs autorisées, elle explique quoi faire d'un produit non identifiable. Sur un courriel bien formé, elle suffit.

Elle échoue en revanche sur des cas frontières que les mots ne décrivent pas bien : un courriel qui mentionne plusieurs produits, un courriel où le client se plaint mais n'exprime pas d'action attendue, un courriel qui contient à la fois un problème de livraison et un défaut. Ce sont exactement les cas où les exemples deviennent rentables.

Un exemple : quand et pourquoi

Un unique exemple bien choisi coûte peu et corrige beaucoup. Il transporte une information difficile à écrire en mots : ordre des clés dans le JSON, convention de casse, gestion d'un cas ambigu représentatif.

EXEMPLE = """
Courriel :
Bonjour, ma commande CMD-42 est bloquée en livraison depuis lundi et la
crêpière que j'ai reçue le mois dernier ne chauffe plus non plus. Je
préférerais un remboursement complet.

Sortie :
{"motif": "livraison", "produit": null, "urgence": "moyenne", "action_demandee": "remboursement"}
""".strip()

messages = [
    {"role": "system", "content": SYSTEME},
    {"role": "user", "content": EXEMPLE},
    {"role": "user", "content": courriel},
]

Cet exemple choisit délibérément le cas ambigu — deux problèmes dans un seul courriel — et montre comment le trancher : on retient le motif de la plainte principale (livraison), on met le produit à null parce que plusieurs sont mentionnés. Un exemple qui montre un cas trivial n'apporte presque rien.

Plusieurs exemples : quand cela devient nécessaire

Trois à cinq exemples deviennent utiles dès que plusieurs classes ou plusieurs comportements doivent être démontrés. Sur notre tâche, on choisirait typiquement :

Exemple	Ce qu'il démontre
Courriel de livraison, urgence élevée, remboursement	cas nominal
Courriel avec plusieurs produits	choix du produit principal, ou null
Courriel qui n'est pas une réclamation (question)	motif = autre, action = information
Courriel bilingue avec extrait en anglais	on répond quand même en français
Courriel très court sans salutation	robustesse au format

Chaque exemple porte une décision que le texte de la consigne ne détaille pas. Un exemple qui ne démontre rien de nouveau est un exemple à retirer.

L'ordre des exemples compte

Le modèle attribue plus de poids aux derniers exemples vus, phénomène connu sous le nom de biais de récence. Deux conséquences :

Ne pas placer en dernier l'exemple le plus fréquent dans votre trafic réel. Sinon le modèle sur-prédit cette classe et vos métriques de production se dégradent à mesure que la distribution se déplace.

Alterner les classes dans l'ordre des exemples. Si les cinq exemples finissent tous par « urgence : élevée », le modèle apprend à répondre « élevée » un peu trop souvent — même sur des courriels tempérés.

$$P(y \mid x, e_1, \ldots, e_k) \neq P(y \mid x, e_{\sigma(1)}, \ldots, e_{\sigma(k)})$$

pour une permutation $\sigma$ non triviale. La distribution induite par le modèle dépend de l'ordre, pas seulement du contenu.

Exemples contrastés

Un exemple contrasté associe deux entrées très proches avec des sorties différentes, pour rendre la frontière explicite :

Courriel A : « Ma cafetière ne chauffe plus depuis lundi. »
Sortie A : {"motif": "produit_defectueux", "urgence": "moyenne", ...}

Courriel B : « Ma cafetière ne chauffe plus, je pars en réunion client
dans 20 minutes. »
Sortie B : {"motif": "produit_defectueux", "urgence": "elevee", ...}

Les deux entrées ne diffèrent que par la contrainte temporelle. Cette paire enseigne ce qui fait basculer l'urgence mieux qu'une phrase de consigne « mettre élevée si le client mentionne une contrainte temporelle », qui laisserait au modèle le soin d'interpréter.

Attention à la fuite du jeu de test dans les exemples

Si vos exemples sont tirés du même échantillon annoté que celui qui sert à mesurer la performance, vous mesurez la capacité du modèle à recopier ses propres exemples. Le score sera flatteur, la production décevante. Séparer strictement les exemples de consigne du jeu d'évaluation, comme on sépare entraînement et test en apprentissage supervisé.

Le coût en jetons

Chaque exemple ajoute des jetons à chaque appel. Sur une consigne à cinq exemples de 100 jetons chacun envoyée un million de fois par mois, c'est 500 millions de jetons d'entrée facturés simplement pour les exemples. À un tarif d'entrée typique de 0,15 $par million de jetons, cela représente 75$ mensuels rien que pour les démonstrations.

$$\text{Surcoût mensuel} = N_{\text{appels}} \cdot k \cdot \bar{J}_{\text{exemple}} \cdot C_{\text{entrée}}$$

Où $k$ est le nombre d'exemples et $\bar{J}_{\text{exemple}}$ leur taille moyenne en jetons. Un exemple qui n'améliore pas une métrique mesurée est un exemple à retirer, pas seulement pour la propreté de la consigne mais pour la facture.

Ajouter les exemples un par un et mesurer

La procédure honnête : partir de zéro exemple, mesurer sur le jeu de test, ajouter le meilleur exemple candidat, mesurer à nouveau. Arrêter dès que la métrique cesse de progresser. Beaucoup d'équipes découvrent qu'après trois exemples bien choisis, le quatrième n'apporte plus rien mesurable.

En résumé

• Choisir le régime d'exemples d'après « la description écrite suffit-elle seule ? », pas d'après une intuition de difficulté.
• Un exemple bien choisi montre une décision ambiguë ; un exemple qui démontre un cas trivial ne change rien.
• Le modèle est sensible à l'ordre : placer en dernier un exemple représentatif de votre trafic biaise la sortie vers cette classe.
• Chaque exemple ajoute des jetons à chaque appel : ajouter les exemples un par un et arrêter dès que la métrique se stabilise.

Module suivant : la chaîne de pensée, une technique qui aide sur certaines tâches et qui nuit sur d'autres — savoir distinguer les deux.