Certaines choses sont pénibles à décrire et triviales à montrer : un style d’écriture maison, un format de données biscornu, l’échelle exacte de gravité de votre triage de tickets. Le few-shot saute la description : vous mettez deux ou trois exemples résolus dans le prompt, et le modèle copie le schéma. (Demander sans aucun exemple s’appelle le zero-shot : le mode par défaut.)

L’analogie

Former un nouveau collègue en montrant d’anciens dossiers. Vous ne lui tendez pas un mémo de 10 pages sur « notre ton dans les e-mails » — vous lui montrez trois e-mails qui étaient exactement justes et vous dites « comme ça ». Les humains généralisent bien mieux à partir d’exemples qu’à partir de règles. Les modèles aussi : c’est littéralement comme ça qu’ils ont tout appris.

Le principe

Classe chaque message client. Catégories : BUG, FACTURATION, AUTRE.

<exemple>
Message : « J'ai été débité deux fois ce mois-ci »
→ FACTURATION | urgence : haute
</exemple>
<exemple>
Message : « Le bouton export ne fait rien depuis mardi »
→ BUG | urgence : moyenne
</exemple>

Message : « Comment ajouter un collègue à mon espace ? »
→

Les règles qui font que ça marche :

  • Les exemples battent les adjectifs. Un vrai « → FACTURATION urgence : haute » définit votre format mieux que trois phrases à son sujet.
  • Couvrez les bords, pas seulement le milieu. Incluez le cas piégeux (un message à la fois bug et facturation) : c’est là que le zero-shot échoue.
  • 2 à 5 exemples, c’est le bon compte. Au-delà, le rendement décroît pendant que le coût grimpe.
  • Un formatage cohérent. Le modèle copie tout de vos exemples, y compris les incohérences.

Un exemple concret

Une équipe qui extrait les lignes de factures fournisseurs a d’abord décrit son format (« dates en ISO, montants sans symbole monétaire, quantités entières… ») — 14 règles, et toujours 20 % de sorties mal formées. Remplacé par 3 factures d’exemple avec leurs extractions attendues : les sorties mal formées tombent sous 3 %, et le prompt est devenu plus court.

💶 Le gain en tokens

  • Les exemples vivent dans la partie stable du prompt, les mêmes à chaque appel. Placés avant l’entrée variable, ils profitent du prompt caching : après le premier appel, vos 800 tokens d’exemples sont relus jusqu’à ~90 % moins cher. Décrire les mêmes règles en prose coûte à peu près autant sans marcher aussi bien.
  • Moins de sorties mal formées = moins de reprises, et chaque reprise re-facture tout le contexte (voir les fondamentaux).
  • C’est l’alternative bon marché au fine-tuning : enseigner un format par l’exemple coûte quelques centaines de tokens en cache par appel, pas une campagne d’entraînement.

Le piège classique

Les exemples biaisés. Si tous vos exemples sont FACTURATION, le modèle sur-prédit FACTURATION ; s’ils sont tous courts, il gère mal les entrées longues. Vos exemples sont un mini jeu d’entraînement : équilibrez-les comme tel, et quand une catégorie échoue en production, ajoutez un exemple résolu de ce cas (votre jeu d’éval vous dira lequel).