Comprendre le one-shot et le few-shot prompting
Vous souhaitez demander à une intelligence artificielle de classer des messages, de produire des fiches identiques ou de respecter une présentation particulière. Vous rédigez une consigne précise, mais les résultats ne correspondent pas toujours à ce que vous attendiez.
Dans ce cas, il peut être utile de ne pas seulement décrire le résultat attendu, mais aussi de montrer à quoi ressemble un résultat correct.
C’est le principe du one-shot prompting et du few-shot prompting.
Vous souhaitez transformer des notes rapides en phrases professionnelles.
Vous avez fourni une démonstration de ce que vous attendez. Le modèle peut s’appuyer sur cet exemple pour traiter la nouvelle note.
Le one-shot fournit une démonstration ; le few-shot en fournit quelques-unes pour guider la réalisation d’une nouvelle tâche.
Ce cours vous apprend à choisir, construire et utiliser ces démonstrations sans confondre quantité d’exemples et qualité du résultat.
1. Objectifs pédagogiques
À la fin de ce cours, vous serez capable de :
- Définir le one-shot et le few-shot prompting.
- Les distinguer du zero-shot prompting.
- Reconnaître un véritable exemple de démonstration.
- Construire un prompt contenant un exemple complet.
- Créer un prompt contenant plusieurs exemples représentatifs.
- Choisir des exemples cohérents et correctement étiquetés.
- Comprendre l’influence du format des exemples sur la réponse.
- Identifier les risques liés aux exemples mal choisis.
- Tester l’intérêt réel d’ajouter des démonstrations.
- Appliquer ces techniques à des situations professionnelles.
2. Rappel : qu’est-ce que le zero-shot prompting ?
Dans le cours précédent, vous avez découvert le zero-shot prompting.
Cette approche consiste à formuler une demande sans fournir d’exemple de tâche déjà réalisée.
Le modèle reçoit une instruction et une donnée à traiter, mais aucune démonstration de classement.
Le one-shot et le few-shot ajoutent un élément : un ou plusieurs cas déjà traités.
3. Qu’est-ce que le one-shot prompting ?
Le one-shot prompting est une technique consistant à fournir un exemple de démonstration avant de demander au modèle de réaliser une tâche comparable.
L’exemple montre généralement :
- une entrée, c’est-à-dire une information à traiter ;
- une sortie, c’est-à-dire le résultat attendu pour cette entrée.
Exemple : classer un message
La catégorie attendue est Assistance technique.
Le premier message et sa catégorie constituent une démonstration. Le second message est le nouveau cas à traiter.
Le modèle ne reçoit pas une nouvelle formation complète grâce à cet exemple. Il utilise l’exemple présent dans le contexte de la demande pour orienter sa réponse.
4. Qu’est-ce que le few-shot prompting ?
Le few-shot prompting consiste à fournir quelques exemples de démonstration avant de présenter un nouveau cas.
Les exemples montrent au modèle plusieurs applications de la règle recherchée.
La catégorie attendue est Livraison.
Les trois démonstrations présentent les catégories et montrent comment les appliquer.
Le few-shot ne signifie pas nécessairement « beaucoup d’exemples ». Il désigne un petit ensemble de démonstrations choisi pour guider le modèle.
5. Comparer les trois approches
| Technique | Démonstrations | Utilisation | Limite possible |
|---|---|---|---|
| Zero-shot | Aucune | Tâche claire et suffisamment connue du modèle. | Format ou critères mal interprétés. |
| One-shot | Une | Montrer un format ou un traitement particulier. | L’exemple peut être peu représentatif. |
| Few-shot | Quelques-unes | Illustrer plusieurs catégories ou variantes. | Exemples incohérents ou trop nombreux. |
Aucune de ces approches n’est automatiquement supérieure aux autres.
Le choix dépend de la tâche, du modèle et de la qualité des exemples.
6. Pourquoi fournir un exemple peut-il aider ?
Une instruction peut être comprise de plusieurs manières.
Par exemple, « reformule ce message de manière professionnelle » laisse plusieurs possibilités :
- un message très formel ;
- une phrase courte ;
- un courriel complet ;
- une formulation neutre et directe.
Un exemple permet de montrer concrètement le type de transformation souhaité.
Sans démonstration
La présentation exacte reste ouverte.
Avec démonstration
Le style et la longueur attendus sont plus visibles.
La réponse pourrait être : « Le rendez-vous a été annulé et le client en a été informé. »
Il s’agit d’une proposition illustrative, pas du résultat d’un test réel du modèle.
7. Comprendre la notion d’apprentissage en contexte
On rencontre parfois l’expression anglaise in-context learning, que l’on peut traduire par « apprentissage en contexte ».
Elle désigne la capacité d’un modèle à adapter son comportement à partir des instructions et des exemples présents dans le contexte de l’échange.
Dans une utilisation classique du few-shot prompting, les paramètres du modèle ne sont pas modifiés.
Le prompt contient plusieurs entrées et leurs sorties attendues.
L’utilisateur présente une entrée qui n’a pas encore été traitée.
Le modèle utilise les instructions et les exemples pour produire une sortie.
L’utilisateur contrôle que la règle a été correctement appliquée.
Le fine-tuning est une méthode d’adaptation d’un modèle impliquant un entraînement supplémentaire.
Le few-shot prompting fournit des exemples dans la demande, sans réaliser cet entraînement supplémentaire.
8. Reconnaître une véritable démonstration
Tout élément présenté comme un « exemple » n’est pas nécessairement une démonstration de la tâche.
| Élément | Exemple | Démonstration ? |
|---|---|---|
| Instruction | « Traduis en anglais. » | Non. |
| Donnée | « Bonjour, comment allez-vous ? » | Non. |
| Liste de catégories | « Livraison, Facturation, Technique » | Non, à elle seule. |
| Entrée et résultat | « Bonjour → Hello » | Oui, pour une tâche de traduction. |
| Document à résumer | Un compte rendu brut. | Non, s’il constitue uniquement le document à traiter. |
| Document et résumé validé | Compte rendu A → Synthèse A. | Oui, s’il sert de modèle pour résumer B. |
La question essentielle est : le prompt montre-t-il un cas déjà réalisé pour guider un nouveau cas ?
9. Construire un prompt one-shot étape par étape
Une méthode simple comporte cinq étapes.
- Définir précisément la tâche.
- Choisir un exemple représentatif.
- Rédiger la réponse correcte pour cet exemple.
- Présenter le nouveau cas avec la même structure.
- Contrôler le résultat obtenu.
Application : reformuler des notes administratives
Une réponse possible serait : « Le devis a été transmis et nous attendons le retour du client. »
L’exemple montre la transformation souhaitée. Les règles explicites évitent de dépendre uniquement de l’imitation.
10. Comment choisir un bon exemple one-shot ?
Un bon exemple doit être :
- correct : il ne contient pas d’erreur à reproduire ;
- représentatif : il ressemble suffisamment aux cas futurs ;
- clair : l’entrée et la sortie sont faciles à identifier ;
- cohérent : il respecte les règles demandées ;
- sobre : il ne contient pas d’informations inutiles.
Si vous montrez uniquement une réponse très courte, le modèle peut reproduire cette brièveté même lorsque la tâche nécessiterait davantage de détails.
Le one-shot est donc particulièrement utile lorsque l’exemple choisi représente correctement le résultat recherché.
11. Construire un prompt few-shot étape par étape
Avec plusieurs exemples, il faut également veiller à leur cohérence et à leur diversité.
Préciser ce que tous les exemples doivent illustrer.
Sélectionner des situations représentatives des variantes possibles.
Contrôler chaque démonstration avant de l’intégrer.
Utiliser les mêmes étiquettes et le même format.
Présenter l’information à traiter sans fournir sa réponse.
12. Pourquoi la cohérence des exemples est-elle importante ?
Les exemples doivent appliquer les mêmes règles.
Si deux cas comparables reçoivent des réponses contradictoires, le modèle peut avoir du mal à déterminer la logique attendue.
Exemples incohérents
Le second classement contredit la règle attendue.
Exemples cohérents
Les deux exemples appliquent la même logique.
Avant de transmettre un jeu d’exemples à une IA, il faut donc vérifier leur exactitude.
13. Pourquoi varier les exemples ?
Des exemples presque identiques montrent peu de situations différentes.
Pour une tâche de classification, il est généralement préférable de couvrir les principales catégories et certaines variantes représentatives.
Exemple : incidents informatiques
La catégorie attendue est « Matériel », sous réserve qu’aucun autre élément ne révèle une cause logicielle.
Les exemples couvrent trois catégories distinctes et rendent la règle de classement plus visible.
14. Combien d’exemples faut-il fournir ?
Il n’existe pas de nombre universellement optimal.
Le nombre utile dépend notamment :
- de la complexité de la tâche ;
- du nombre de catégories ;
- de la diversité des situations ;
- du modèle utilisé ;
- de la longueur des exemples ;
- de la précision attendue.
Une démarche raisonnable consiste à commencer avec un exemple, puis à en ajouter seulement si les tests montrent un besoin.
Trois exemples corrects, complémentaires et représentatifs peuvent être plus utiles que dix exemples répétitifs ou contradictoires.
Il s’agit d’un principe pratique, pas d’une garantie de performance.
15. Utiliser des exemples positifs
Un exemple positif montre le résultat que l’on souhaite obtenir.
La démonstration montre une transformation correcte.
Les exemples positifs sont souvent faciles à interpréter parce qu’ils présentent directement le comportement attendu.
16. Utiliser des contre-exemples avec précaution
Un contre-exemple montre une réponse à éviter.
Il peut être utile pour illustrer une erreur, mais il doit être clairement identifié.
La consigne distingue explicitement le résultat incorrect du résultat à reproduire.
Un contre-exemple mal signalé peut être interprété comme un modèle de réponse.
Il faut toujours identifier clairement ce qui doit être imité et ce qui doit être évité.
17. Les exemples doivent-ils tous avoir le même format ?
Pour une tâche répétitive, une structure commune facilite généralement la compréhension.
Les étiquettes « Entrée » et « Sortie » restent identiques.
Le modèle peut ainsi repérer plus facilement le schéma de transformation.
18. Délimiter clairement les exemples
Lorsque les démonstrations sont longues, il devient important de séparer les différentes parties du prompt.
On peut utiliser :
- des titres ;
- des numéros ;
- des séparateurs ;
- des étiquettes « Entrée » et « Sortie » ;
- des balises textuelles.
La séparation visuelle réduit les risques de confusion entre démonstrations et nouvelle demande.
19. Un exemple ne remplace pas des règles claires
Il est tentant de fournir plusieurs démonstrations sans expliquer la tâche.
Mais le modèle peut alors imiter des éléments secondaires plutôt que la règle importante.
Exemples seuls
Le modèle doit déduire seul la règle et les catégories autorisées.
Règle et exemples
La tâche et les catégories sont explicites.
Le résultat attendu est « Objet ».
Les démonstrations complètent les instructions plutôt qu’elles ne les remplacent systématiquement.
20. Premier cas professionnel : classifier des courriels
Une entreprise reçoit des demandes de différentes natures.
Elle souhaite attribuer une catégorie à chaque message.
La catégorie attendue est « Livraison » si l’entreprise range les erreurs de préparation dans cette catégorie.
Cette convention doit toutefois être confirmée si les règles internes prévoient une catégorie différente.
21. Deuxième cas professionnel : harmoniser des comptes rendus
Une équipe rédige des comptes rendus selon des styles différents.
Elle souhaite obtenir une présentation homogène.
Résultat illustratif attendu
La démonstration aide à conserver la structure et le niveau de détail.
22. Troisième cas professionnel : préparer des fiches produits
Une entreprise souhaite présenter ses produits selon une structure commune.
Un exemple validé peut servir de référence.
Ce one-shot peut suffire à reproduire une structure très simple.
Pour des fiches plus élaborées, plusieurs exemples peuvent aider à illustrer des produits différents.
23. Quatrième cas professionnel : tickets de support informatique
Un service informatique souhaite classer des tickets selon leur nature.
La catégorie attendue est « Matériel » pour un classement initial, mais un diagnostic technique reste nécessaire pour déterminer la cause réelle.
Un exemple peut guider une catégorie de traitement sans prouver la cause d’un incident.
Il ne faut pas transformer un classement provisoire en diagnostic certain.
24. Cinquième cas professionnel : extraction de données
Une entreprise souhaite extraire des informations présentes dans des messages de réservation.
Le résultat attendu est :
Les démonstrations montrent comment extraire et ordonner les informations.
25. Les risques liés à un exemple incorrect
Un exemple faux peut orienter le modèle vers une mauvaise réponse.
Le classement est incohérent avec les catégories habituelles utilisées dans ce cours.
Si le modèle imite cette démonstration, il peut produire d’autres erreurs de classement.
Il faut donc vérifier chaque exemple avant de l’utiliser.
26. Les risques liés aux exemples trop similaires
Des démonstrations très proches peuvent donner une vision trop étroite de la tâche.
Ces exemples illustrent trois formulations du même problème.
Ils peuvent être utiles pour reconnaître des variantes de langage, mais ne montrent rien des autres catégories.
Pour une classification comprenant plusieurs catégories, il faut généralement prévoir une couverture plus équilibrée.
27. Les risques liés aux exemples trop différents
À l’inverse, des exemples sans logique commune peuvent brouiller la tâche.
Les exemples concernent trois tâches différentes : traduction, calcul et classification.
Sans instruction expliquant pourquoi ces transformations sont réunies, le modèle ne dispose pas d’une règle unique à appliquer.
Un ensemble few-shot doit présenter plusieurs variantes d’une même tâche, sauf si l’objectif explicite est de faire choisir entre plusieurs types de traitement.
28. Les exemples peuvent-ils introduire des biais ?
Oui.
Les démonstrations peuvent influencer les catégories, le ton ou les choix effectués par le modèle.
Par exemple, si toutes les réclamations contenant un ton mécontent sont classées comme urgentes, le modèle risque de reproduire cette association, même lorsque l’urgence réelle dépend d’autres critères.
Il faut donc distinguer :
- les éléments réellement déterminants ;
- les détails présents par hasard dans les exemples ;
- les critères métier définis par l’organisation.
Les exemples doivent refléter les règles de traitement souhaitées, et non des associations arbitraires.
29. Comment traiter les cas ambigus ?
Une démonstration ne suffit pas toujours à résoudre toutes les situations.
Un message peut concerner plusieurs catégories.
Message : « J’ai reçu un produit défectueux et ma facture est incorrecte. »
Ce message concerne potentiellement un problème de produit et un problème de facturation.
Il est possible de définir une règle :
Cette règle peut ensuite être illustrée par un exemple si nécessaire.
30. Faut-il inclure des exemples de cas limites ?
Un cas limite est une situation située à la frontière entre deux catégories ou deux interprétations possibles.
Ces cas peuvent être particulièrement utiles pour tester une méthode.
« Le logiciel ne fonctionne plus depuis la coupure du réseau. »
Le problème pourrait être classé comme logiciel ou réseau selon les informations disponibles.
Si l’entreprise dispose de règles de tri précises, elle peut intégrer une démonstration illustrant la manière de traiter ce type de cas.
Il faut toutefois éviter d’inventer une certitude technique à partir d’un message insuffisant.
31. Comment vérifier l’efficacité des exemples ?
La présence d’exemples ne prouve pas que la réponse sera meilleure.
Il faut comparer les résultats sur des cas de test.
| Critère | Question |
|---|---|
| Exactitude | La réponse est-elle correcte ? |
| Respect du format | Les rubriques demandées sont-elles présentes ? |
| Cohérence | Des cas similaires sont-ils traités selon la même règle ? |
| Gestion des ambiguïtés | Le modèle reconnaît-il les cas incertains ? |
| Robustesse | La méthode fonctionne-t-elle sur des formulations nouvelles ? |
| Coût de préparation | Les exemples supplémentaires apportent-ils une amélioration utile ? |
Pour une évaluation sérieuse, les cas de test doivent être distincts des démonstrations utilisées dans le prompt.
32. Tester zero-shot, one-shot et few-shot sur une même tâche
Imaginons que vous disposiez de 20 messages clients correctement classés par une personne compétente.
Vous pouvez préparer trois variantes :
- Une consigne zero-shot avec les catégories et les règles.
- La même consigne accompagnée d’une démonstration.
- La même consigne accompagnée de plusieurs démonstrations.
Vous testez ensuite chaque variante sur les mêmes messages, sans inclure les messages de test parmi les exemples.
Illustration fictive de résultats
| Variante | Messages corrects sur 20 | Taux |
|---|---|---|
| Zero-shot | 15 | 75 % |
| One-shot | 17 | 85 % |
| Few-shot | 18 | 90 % |
Ces chiffres sont purement illustratifs. Ils ne proviennent pas d’un test réalisé et ne représentent pas des performances générales des techniques.
Dans cet exemple fictif, les démonstrations améliorent le résultat.
Dans une autre situation, les performances pourraient être identiques ou moins bonnes.
33. Attention aux résultats trop dépendants des exemples
Un modèle peut reproduire des caractéristiques présentes dans les démonstrations sans comprendre correctement la règle recherchée.
Par exemple, si tous les messages classés « Facturation » contiennent le mot « facture », il pourrait moins bien traiter une demande concernant un prélèvement incorrect sans utiliser ce mot.
Pour limiter ce risque :
- variez les formulations ;
- testez des messages nouveaux ;
- définissez les catégories par des critères explicites ;
- contrôlez les erreurs de classement.
Le but n’est pas de faire mémoriser quelques formulations, mais d’obtenir une application fiable de la règle.
34. Peut-on mélanger instructions et exemples ?
Oui. C’est même une structure souvent utile.
Cette structure combine des règles explicites et deux démonstrations.
Elle correspond à une approche few-shot.
35. Modèle de prompt one-shot réutilisable
Ce modèle convient lorsque vous disposez d’une démonstration fiable et suffisamment représentative.
36. Modèle de prompt few-shot réutilisable
Les démonstrations doivent être adaptées à la tâche et vérifiées avant utilisation.
37. Quand faut-il éviter d’ajouter des exemples ?
Les démonstrations ne sont pas toujours nécessaires.
Elles peuvent être peu utiles lorsque :
- la tâche est simple et déjà correctement réalisée ;
- les exemples disponibles sont incertains ;
- la consigne suffit à définir précisément le résultat ;
- les exemples ajoutent de la confusion ;
- leur préparation coûte davantage que le bénéfice obtenu.
Commencez par une consigne claire. Ajoutez une démonstration lorsqu’elle répond à une difficulté identifiée. Testez ensuite si plusieurs exemples apportent une amélioration réelle.
38. Exercice 1 — Identifier les techniques
ApplicationObservez les trois prompts.
Travail demandé :
- Identifiez la technique utilisée dans chaque prompt.
- Indiquez le nombre de démonstrations.
- Expliquez pourquoi la phrase à traduire n’est pas une démonstration.
Afficher la correction détaillée
Prompt A
Zero-shot : aucune démonstration.
Prompt B
One-shot : une traduction déjà réalisée.
Prompt C
Few-shot : deux traductions déjà réalisées.
Justification
La nouvelle phrase à traduire constitue une donnée à traiter. Une démonstration comporte une entrée et sa traduction correcte, présentées pour guider le traitement du nouveau cas.
39. Exercice 2 — Construire un prompt one-shot
ApplicationUne entreprise souhaite transformer des notes rapides en phrases professionnelles.
Exemple validé :
Nouvelle note :
Travail demandé :
- Construisez un prompt one-shot.
- Définissez une règle interdisant les informations inventées.
- Rédigez la réponse attendue.
Afficher la correction détaillée
Prompt proposé
Réponse attendue
« La facture a été envoyée et le paiement est en attente. »
Justification
Le prompt comporte une démonstration complète et un nouveau cas. Il s’agit d’un one-shot.
40. Exercice 3 — Corriger un few-shot incohérent
EntraînementUne entreprise utilise trois catégories : Facturation, Livraison et Assistance technique.
Travail demandé :
- Identifiez l’exemple incorrect.
- Corrigez-le.
- Expliquez le risque lié à cette erreur.
- Proposez une règle de vérification des démonstrations.
Afficher la correction détaillée
1. Exemple incorrect
L’exemple 3 est mal classé.
Un problème de connexion relève normalement de l’assistance technique dans cette classification.
2. Correction
3. Risque
Le modèle peut reproduire une mauvaise association entre problème de connexion et facturation.
4. Contrôle
Chaque démonstration doit être comparée aux définitions des catégories et validée avant utilisation.
41. Exercice 4 — Sélectionner des exemples représentatifs
EntraînementVous souhaitez classer les incidents informatiques en trois catégories :
- Matériel ;
- Logiciel ;
- Réseau.
Vous disposez de cinq exemples possibles :
- Écran qui ne s’allume plus.
- Clavier défectueux.
- Application qui se ferme au démarrage.
- Impossible d’accéder au réseau local.
- Souris qui ne répond plus.
Travail demandé :
- Choisissez trois exemples pour un prompt few-shot.
- Justifiez votre sélection.
- Rédigez le prompt.
- Expliquez une limite possible de ce classement.
Afficher la correction détaillée
1. Sélection
Une sélection pertinente est :
- Écran qui ne s’allume plus → Matériel.
- Application qui se ferme au démarrage → Logiciel.
- Impossible d’accéder au réseau local → Réseau.
2. Justification
Chaque catégorie est représentée au moins une fois.
Choisir trois exemples matériels aurait laissé les catégories Logiciel et Réseau sans démonstration.
3. Prompt proposé
La catégorie attendue est « Logiciel ».
4. Limite
Le classement initial ne prouve pas la cause technique réelle. Un diagnostic peut révéler un problème différent.
42. Exercice 5 — Cas professionnel complet
SynthèseSituation
Une entreprise souhaite transformer des messages de clients en fiches de traitement.
Chaque fiche doit comporter :
- une catégorie ;
- un résumé factuel ;
- une information à vérifier.
Catégories autorisées : Facturation, Livraison, Assistance technique.
Messages disponibles :
Travail demandé :
- Construisez trois démonstrations cohérentes.
- Rédigez un prompt few-shot complet.
- Définissez le format des fiches.
- Traitez le nouveau message.
- Indiquez deux contrôles à effectuer avant utilisation.
Afficher la correction détaillée
1. Démonstrations
2. Prompt few-shot complet
3. Résultat attendu
4. Premier contrôle
Vérifier que le résumé reprend uniquement les informations présentes dans le message.
5. Deuxième contrôle
Vérifier que la catégorie correspond aux règles de classement de l’entreprise.
6. Conclusion
Le few-shot permet ici de montrer le format de fiche attendu et de représenter les trois catégories.
La qualité des démonstrations reste essentielle : des exemples incorrects ou ambigus pourraient orienter le modèle vers de mauvais résultats.
43. Questions fréquentes — 20 questions
1. Que signifie one-shot prompting ?
Il s’agit d’une technique consistant à fournir une démonstration avant un nouveau cas à traiter.
2. Que signifie few-shot prompting ?
Il s’agit d’une technique consistant à fournir quelques démonstrations pour guider une tâche.
3. Quelle différence avec le zero-shot ?
Le zero-shot ne fournit aucune démonstration dans le prompt.
4. Un document à analyser constitue-t-il un exemple few-shot ?
Non, pas s’il est uniquement la donnée à traiter.
5. Faut-il toujours utiliser plusieurs exemples ?
Non. Une instruction claire ou une seule démonstration peut suffire.
6. Le few-shot garantit-il une réponse correcte ?
Non. Les réponses doivent être contrôlées.
7. Peut-on utiliser des exemples de traduction ?
Oui. Une phrase et sa traduction peuvent servir de démonstration.
8. Peut-on utiliser des exemples de classification ?
Oui. Un message accompagné de sa catégorie constitue une démonstration.
9. Pourquoi les exemples doivent-ils être cohérents ?
Pour éviter de présenter au modèle des règles contradictoires.
10. Pourquoi varier les exemples ?
Pour représenter plusieurs situations pertinentes et éviter une couverture trop étroite.
11. Un exemple incorrect peut-il dégrader le résultat ?
Oui. Le modèle peut reproduire une erreur présente dans les démonstrations.
12. Peut-on utiliser des contre-exemples ?
Oui, à condition de les identifier clairement comme des réponses incorrectes.
13. Les exemples remplacent-ils les instructions ?
Pas nécessairement. Des règles explicites restent souvent utiles.
14. Combien d’exemples faut-il fournir ?
Le nombre dépend de la tâche. Il faut tester différentes quantités et privilégier les exemples utiles.
15. Le few-shot modifie-t-il les paramètres du modèle ?
Non, pas dans son usage classique. Les exemples sont fournis dans le contexte de la demande.
16. Quelle différence avec le fine-tuning ?
Le fine-tuning implique un entraînement supplémentaire, contrairement à la simple fourniture d’exemples dans un prompt.
17. Peut-on utiliser le few-shot pour des courriels professionnels ?
Oui, notamment pour montrer un style et une structure validés.
18. Comment évaluer un prompt few-shot ?
En le testant sur des cas nouveaux et en vérifiant l’exactitude, le format et la cohérence des réponses.
19. Pourquoi tester sur des cas différents des exemples ?
Pour vérifier que la méthode fonctionne sur de nouvelles situations, et pas seulement sur les démonstrations fournies.
20. Quand préférer le one-shot au few-shot ?
Lorsqu’une seule démonstration représentative suffit à clarifier le résultat attendu.
44. Glossaire
| Terme | Définition |
|---|---|
| Prompt | Consigne ou ensemble d’informations transmis à un modèle d’IA. |
| Zero-shot | Approche sans démonstration fournie dans le prompt. |
| One-shot | Approche utilisant une démonstration. |
| Few-shot | Approche utilisant quelques démonstrations. |
| Démonstration | Exemple montrant une entrée et son résultat attendu. |
| Entrée | Information soumise au traitement. |
| Sortie | Résultat produit ou attendu. |
| In-context learning | Adaptation du comportement du modèle à partir des informations présentes dans le contexte. |
| Fine-tuning | Adaptation d’un modèle par entraînement supplémentaire. |
| Classification | Attribution d’une catégorie à un élément. |
| Cas limite | Situation difficile à classer selon les règles habituelles. |
| Contre-exemple | Exemple montrant une réponse ou un comportement à éviter. |
| Biais | Tendance systématique susceptible d’influencer les résultats. |
| Jeu de test | Ensemble de cas utilisés pour évaluer une méthode. |
| Robustesse | Capacité à conserver de bonnes performances sur des situations variées. |
45. Les dix idées essentielles à retenir
- Le one-shot fournit une démonstration.
- Le few-shot fournit quelques démonstrations.
- Une démonstration montre une tâche déjà réalisée.
- Une donnée à traiter n’est pas nécessairement une démonstration.
- Les exemples peuvent clarifier un format ou une règle.
- Les démonstrations doivent être correctes et cohérentes.
- Des exemples variés peuvent mieux représenter une tâche.
- Un exemple erroné peut influencer négativement les réponses.
- Le few-shot n’est pas automatiquement meilleur que le zero-shot.
- Les performances doivent être vérifiées sur de nouveaux cas.
Le one-shot et le few-shot prompting permettent de guider une IA en lui montrant des réalisations attendues.
La réussite dépend moins du nombre brut d’exemples que de leur pertinence, de leur exactitude et de leur cohérence avec les instructions.
46. Ressources complémentaires
- OpenAI — Prompt Engineering : principes de rédaction des prompts et utilisation d’exemples.
- Google AI for Developers — Prompting Strategies : stratégies zero-shot et few-shot.
- Anthropic — Prompt Engineering : méthodes de conception et d’amélioration des prompts.
Les recommandations peuvent évoluer selon les modèles et leurs versions. Les exemples du cours sont pédagogiques et ne constituent pas des résultats de tests comparatifs réels.
47. Passer à la pratique
Pour maîtriser ces techniques, entraînez-vous à :
- transformer une consigne zero-shot en one-shot ;
- construire plusieurs démonstrations cohérentes ;
- corriger des exemples incorrects ;
- choisir des cas représentatifs ;
- comparer les résultats avec et sans exemples.
48. Préparer le cours suivant
Vous savez désormais distinguer le zero-shot, le one-shot et le few-shot prompting.
Le cours suivant approfondira un aspect essentiel : la construction d’exemples structurés.
Vous apprendrez notamment à :
- définir une structure d’entrée et de sortie ;
- harmoniser plusieurs démonstrations ;
- éviter les informations inutiles ;
- préparer des exemples exploitables dans des prompts réutilisables.
2 cours sur 15 — Vous connaissez maintenant les trois grandes approches de prompting selon le nombre de démonstrations fournies.
Exercices du cours
Entraînez-vous avec 15 exercices progressifs. Ouvrez un exercice pour répondre, puis afficher sa correction.