Few-shot

Pourquoi quelques exemples suffisent

Un modèle de langage cherche à prolonger ce qu'on lui donne. Si la consigne contient deux ou trois échanges déjà résolus, il tend à en imiter la forme, le niveau de détail et le ton. Cette imitation est parfois plus efficace qu'une longue description : montrer un exemple évite d'expliquer en dix phrases ce que l'on attend d'une ligne de tableau ou d'une réponse type. C'est le principe du few-shot, étudié bien avant l'arrivée des assistants grand public.

L'effet dépend de la cohérence des exemples. Trois cas qui se contredisent apprennent au modèle à hésiter, ou pire, à mélanger les formats. Trois cas représentatifs, choisis pour couvrir les variantes réelles, donnent un cadre stable. La qualité prime sur la quantité : au-delà de quelques exemples, le gain devient marginal et le coût en jetons augmente à chaque appel. Le préambule devient aussi plus difficile à maintenir quand il grossit. Un exemple commenté vaut souvent deux exemples muets.

Ce que fait réellement un exemple

Un exemple transmet trois choses à la fois : le format de sortie, le niveau de précision attendu et la posture de réponse. Une réponse qui cite sa source, qui signale une incertitude ou qui refuse poliment montre au modèle comment se comporter dans les cas difficiles, sans qu'il faille l'écrire en toutes lettres. C'est souvent ce que les consignes abstraites échouent à obtenir. L'exemple sert de contrat implicite entre l'utilisateur et la machine, et il sera imité littéralement.

L'ordre des exemples compte aussi. Le modèle a tendance à suivre de plus près le dernier présenté, et les cas extrêmes placés en fin de liste pèsent davantage. Placer l'exemple le plus représentatif en dernier, ou varier l'ordre entre deux essais, permet de repérer cette sensibilité. Un résultat qui change du tout au tout selon l'ordre des exemples indique une consigne fragile. Il vaut mieux alors réécrire la consigne que multiplier les cas.

Les pièges

Le premier piège est la fuite d'information. Un exemple construit à partir d'un vrai dossier client transporte des noms, des montants ou des adresses dans chaque appel. Il faut anonymiser, ou fabriquer des cas fictifs réalistes. Le second est la sur-spécialisation : un modèle guidé par l'exemple à répondre en trois lignes répondra en trois lignes même quand la question exige une analyse longue. Il faut prévoir un exemple de cas long pour contrebalancer.

Le troisième piège est l'illusion de compréhension. Un modèle qui reproduit le format peut donner l'impression de maîtriser le fond, alors qu'il a seulement appris à présenter une réponse plausible. Sur des calculs, des références juridiques ou des données médicales, l'exemple ne remplace jamais la vérification. Il faut donc évaluer séparément la forme et le fond, avec des cas où le format est correct mais le contenu faux. C'est la seule manière de voir si le modèle a compris la tâche.

Few-shot ou autre chose

Trois approches se complètent. Le zero-shot donne la consigne sans exemple, ce qui suffit pour les tâches courantes. Le few-shot ajoute des cas pour cadrer un format. L'affinage apprend durablement un comportement à partir de nombreux exemples. La règle pratique consiste à commencer par le plus simple, puis à n'ajouter des exemples que si la sortie ne tient pas le format attendu. Chaque niveau ajoute du travail de maintenance, et changer un exemple est bien plus facile que changer un modèle affiné.

Si le problème vient d'un manque de connaissance et non de forme, les exemples ne serviront à rien. Il faut alors chercher l'information dans les documents et l'injecter dans le contexte, ou affiner le modèle sur le corpus. Confondre les deux besoins conduit à empiler des exemples qui n'améliorent pas la justesse, tout en alourdissant chaque requête et en masquant le vrai problème. Diagnostiquer avant d'écrire la consigne reste la première étape.