Techniques
Zero-shot
Capacité d'un modèle à traiter une tâche qu'il n'a jamais vue, sans exemple dans la consigne, en s'appuyant sur sa compréhension générale du domaine et du format attendu.
D'où vient cette capacité
Un modèle de langage a été entraîné sur des textes très variés, où il a rencontré des consignes, des questions, des formats de réponse et des exercices corrigés. Il a appris à reconnaître la forme d'une tâche avant son contenu. Quand on lui demande de classer un message en trois catégories, il identifie le schéma général du classement, même s'il n'a jamais vu ce type de message ni cette liste de catégories auparavant. Le mécanisme repose sur la reconnaissance de formes de tâches, pas sur une base de connaissances explicite.
Cette capacité a surpris les concepteurs eux-mêmes : elle n'était pas l'objectif direct de l'entraînement. Elle s'est renforcée avec la taille des modèles et avec les méthodes d'affinage sur instructions, qui apprennent au modèle à suivre une demande formulée en langage courant, avec son rôle, sa tâche et ses contraintes. Elle explique pourquoi une consigne bien écrite peut suffire là où il fallait auparavant constituer un jeu de données étiqueté. Cette propriété n'a pas été programmée : elle émerge de l'exposition à des textes qui contiennent eux-mêmes des consignes.
Quand cela suffit
Le zero-shot convient aux tâches courantes et bien décrites : résumer un texte, reformuler, traduire, classer selon des catégories explicites, extraire un champ nommé d'un document. Sur ces cas, un modèle récent atteint un résultat utilisable dès la première consigne, ce qui permet de tester une idée en quelques minutes, sans annoter de données ni réunir un échantillon représentatif. C'est la manière la plus rapide de vérifier qu'un besoin vaut un projet. Le coût d'un tel test est négligeable, alors que celui d'un jeu de données annoté ne l'est jamais.
Il convient aussi aux situations où les exemples seraient coûteux à produire ou délicats à divulguer. Un cabinet qui veut trier des courriers de clients peut décrire les catégories sans fournir de lettres réelles. Une collectivité qui prépare une réponse type n'a pas besoin d'un corpus étiqueté pour obtenir une première version, qu'elle corrigera ensuite à la main, avec l'expérience de ses agents. La contrainte de confidentialité devient alors un argument en faveur de l'essai immédiat, avant même de parler d'outil.
Où la limite apparaît
Le zero-shot échoue dès que la tâche dépend d'une convention interne. Un modèle ne peut pas deviner que votre service appelle un dossier urgent au-delà d'un certain seuil, ni quelle formulation votre direction attend dans un courrier de refus. Il produit alors une réponse correcte en général et fausse dans votre cadre. Ce sont précisément les cas où quelques exemples, ou une règle écrite noir sur blanc, changent tout. Un modèle ne connaît pas votre organigramme, vos seuils de priorité ni le ton de vos courriers habituels.
Il échoue aussi sur les tâches spécialisées : lecture d'un document technique, respect d'une norme, terminologie métier, langue peu représentée. La performance zero-shot doit alors être mesurée avant d'être supposée. Un test sur vingt cas réels, comparé à une version avec exemples, indique en une heure si la consigne seule suffit ou si un jeu de référence devient nécessaire avant d'aller plus loin. Sans cette mesure, on découvre les limites en production, sur des dossiers qui comptent.
En pratique
- Commencer par une consigne zero-shot claire avant d'investir dans un jeu de données.
- Décrire explicitement les catégories et le format attendu, sans les laisser deviner au modèle.
- Comparer zero-shot et quelques exemples sur vingt cas réels avant de trancher.
- Fournir les conventions internes : un modèle ne les connaît pas par défaut, même bien écrites.