Utiliser des exemples structurés
Lorsque vous demandez à une intelligence artificielle de reproduire une présentation, de classer des informations ou de transformer des données, il ne suffit pas toujours de lui montrer plusieurs exemples.
Encore faut-il que ces exemples soient organisés de manière claire, cohérente et facilement interprétable.
Un exemple mal présenté peut introduire des ambiguïtés. Plusieurs exemples contradictoires peuvent même rendre la tâche plus difficile.
À l’inverse, des exemples structurés permettent de montrer précisément quelles informations doivent être traitées, comment elles doivent être transformées et sous quelle forme le résultat doit être présenté.
La séparation entre la tâche, les démonstrations et le nouveau cas facilite l’identification du résultat attendu.
Un exemple structuré ne montre pas seulement quoi répondre. Il montre aussi comment organiser la réponse.
1. Objectifs pédagogiques
À la fin de ce cours, vous serez capable de :
- Définir ce qu’est un exemple structuré.
- Distinguer les données d’entrée et les résultats attendus.
- Organiser plusieurs démonstrations selon un format commun.
- Utiliser des étiquettes et des séparateurs.
- Choisir les informations utiles à inclure.
- Présenter des exemples de classification et d’extraction.
- Construire des exemples sous forme de tableaux ou de JSON.
- Éviter les incohérences entre démonstrations.
- Gérer les données absentes et les situations ambiguës.
- Vérifier la qualité d’un ensemble d’exemples avant utilisation.
2. Qu’est-ce qu’un exemple structuré ?
Un exemple structuré est une démonstration organisée selon des champs, des étiquettes ou une présentation définie.
Il permet d’identifier clairement :
- les informations fournies au modèle ;
- la tâche réalisée ;
- le résultat correct ;
- la forme attendue pour les prochains cas.
Une structure peut être très simple.
Elle peut aussi comporter plusieurs champs.
Le niveau de détail dépend de la tâche.
3. Pourquoi structurer les exemples ?
Une démonstration non structurée peut être difficile à interpréter.
Par exemple :
Une personne peut comprendre l’intention, mais les relations entre les informations ne sont pas clairement délimitées.
Version structurée
Cette seconde version permet d’identifier sans ambiguïté les messages et leurs catégories.
La structure devient particulièrement utile lorsque les démonstrations sont nombreuses ou comportent plusieurs informations.
4. Les trois composants fondamentaux
Un ensemble d’exemples structurés repose généralement sur trois composants.
Ce que l’IA doit réaliser.
Des entrées accompagnées de leurs résultats corrects.
Une entrée à traiter selon les mêmes règles.
Cette organisation évite de mélanger les exemples déjà résolus avec la demande actuelle.
5. Comprendre la notion d’entrée
L’entrée correspond aux informations que l’IA doit traiter.
Selon la tâche, il peut s’agir :
- d’une phrase à traduire ;
- d’un message à classer ;
- d’un document à résumer ;
- d’une note à reformuler ;
- d’un ensemble de chiffres à analyser ;
- d’une description de produit.
Cette entrée constitue la matière à traiter.
Elle ne doit pas être confondue avec le résultat attendu.
6. Comprendre la notion de sortie
La sortie correspond au résultat attendu pour une entrée donnée.
La sortie peut être :
- un mot ;
- une phrase ;
- un tableau ;
- une liste ;
- un objet JSON ;
- un texte comportant plusieurs rubriques.
Dans une démonstration, la sortie doit être correcte et conforme aux règles définies.
7. Utiliser des étiquettes explicites
Les étiquettes permettent d’identifier la fonction de chaque information.
Par exemple :
Ces étiquettes doivent rester cohérentes entre les exemples.
Présentation variable
Les noms des champs changent.
Présentation homogène
Les mêmes étiquettes sont utilisées.
La présentation homogène facilite la lecture et réduit les ambiguïtés.
8. Utiliser des séparateurs
Lorsque les exemples sont longs, les séparateurs permettent de distinguer les différents blocs.
Les séparateurs peuvent être des titres, des lignes ou des balises textuelles.
L’essentiel est de conserver une présentation régulière.
9. Utiliser des exemples de longueur comparable
Des exemples de longueur très différente peuvent influencer le niveau de détail de la réponse.
Il n’est pas obligatoire que toutes les sorties aient exactement la même longueur.
En revanche, elles doivent respecter une règle commune.
Les deux sorties respectent le même niveau de synthèse.
10. Éviter les informations inutiles
Un exemple doit contenir les informations nécessaires à la tâche.
Des détails sans rapport avec l’objectif peuvent introduire des associations indésirables.
Exemple surchargé
Plusieurs informations ne sont pas nécessaires au classement.
Exemple ciblé
Les informations utiles sont conservées.
Cette simplification facilite également la protection des données personnelles.
11. Présenter des exemples de classification
La classification consiste à attribuer une catégorie à une information.
Pour cette tâche, les exemples doivent respecter les catégories autorisées.
La catégorie attendue est « Livraison ».
Les démonstrations montrent les associations entre les messages et les catégories.
12. Présenter des exemples de reformulation
Les exemples structurés sont également utiles pour harmoniser le style d’un texte.
Une réponse possible est : « L’intervention est terminée et le rapport a été transmis. »
13. Présenter des exemples d’extraction
L’extraction consiste à relever des informations précises dans un document.
Les exemples structurés permettent de montrer quels champs doivent être renseignés.
La réponse attendue est :
14. Structurer des exemples sous forme de tableau
Un tableau peut rendre plusieurs démonstrations plus lisibles.
| Message | Catégorie |
|---|---|
| « Ma facture est incorrecte. » | Facturation |
| « Mon colis n’est pas arrivé. » | Livraison |
| « Le logiciel ne démarre plus. » | Assistance technique |
Cette présentation est particulièrement adaptée aux tâches simples comportant une entrée et une sortie courte.
Pour des démonstrations longues, des blocs séparés peuvent être plus faciles à lire.
15. Structurer des exemples en JSON
Le JSON est un format textuel permettant de représenter des données structurées.
Il utilise notamment des clés et des valeurs.
Dans un prompt, des exemples JSON peuvent montrer la structure attendue.
La sortie attendue est :
Un exemple JSON peut guider la structure, mais il ne garantit pas à lui seul que toutes les réponses seront techniquement valides.
Pour une utilisation automatisée, il faut prévoir une validation du format et, lorsque l’outil le permet, utiliser des mécanismes de sortie structurée.
16. Comprendre les champs obligatoires
Un champ obligatoire est une information qui doit apparaître dans chaque résultat.
Par exemple, une fiche de traitement peut imposer :
- une catégorie ;
- un résumé ;
- une action à vérifier.
Chaque démonstration doit respecter cette structure.
Si un exemple omet une rubrique obligatoire, il risque d’encourager des réponses incomplètes.
17. Gérer les informations manquantes
Une donnée peut ne pas contenir toutes les informations attendues.
Il faut alors définir une règle explicite.
Cette démonstration montre que l’IA ne doit pas inventer les informations absentes.
Utilisez toujours la même convention pour les données manquantes : « non précisé », valeur nulle ou autre format clairement défini.
Le choix dépend de l’utilisation finale des données.
18. Gérer les situations ambiguës
Une information peut correspondre à plusieurs interprétations.
Il est utile de montrer comment traiter ces situations.
Cette démonstration évite de forcer artificiellement une catégorie unique.
19. Utiliser des exemples positifs et négatifs
Un exemple positif montre ce qu’il faut produire.
Un exemple négatif montre ce qu’il faut éviter.
Une entreprise souhaite résumer les réclamations sans inventer d’informations.
La distinction entre réponse correcte et incorrecte doit être explicite.
20. Éviter les exemples contradictoires
Deux démonstrations ne doivent pas appliquer des règles incompatibles.
Exemples contradictoires
Le second classement ne correspond pas à la règle attendue.
Exemples cohérents
Les deux cas respectent la même logique.
Les exemples doivent être validés avant d’être intégrés au prompt.
21. Éviter les démonstrations trop similaires
Plusieurs exemples identiques dans leur logique peuvent être peu informatifs.
Ces trois exemples concernent le même type de problème.
Ils peuvent illustrer des variantes de formulation, mais ne couvrent pas les autres catégories.
Pour une classification générale, il est souvent préférable de varier les situations.
22. Choisir des exemples représentatifs
Un ensemble d’exemples doit couvrir les principales situations que le modèle rencontrera.
| Catégorie | Exemple représentatif |
|---|---|
| Facturation | Montant de facture incorrect. |
| Livraison | Colis non reçu. |
| Assistance technique | Application inaccessible. |
La représentativité ne signifie pas qu’il faut montrer toutes les situations possibles.
Il faut choisir des cas utiles pour illustrer les règles essentielles.
23. Ajouter des cas limites
Un cas limite est une situation située à la frontière entre plusieurs catégories.
Par exemple :
Ce message peut nécessiter une vérification avant de déterminer la catégorie.
Une démonstration peut montrer comment signaler cette incertitude.
Cette approche est particulièrement utile dans les domaines où un mauvais classement peut avoir des conséquences importantes.
24. Utiliser des exemples structurés pour des comptes rendus
Une équipe peut souhaiter produire des comptes rendus selon un modèle commun.
Le résultat attendu est :
L’exemple permet de reproduire la même organisation.
25. Utiliser des exemples structurés pour le support informatique
Un service informatique souhaite produire des fiches de tickets homogènes.
Une fiche possible est :
La catégorie reste provisoire tant qu’un diagnostic n’a pas été effectué.
26. Utiliser des exemples structurés pour des fiches produits
Une entreprise peut utiliser des exemples pour harmoniser ses descriptions de produits.
Le modèle doit reprendre uniquement les caractéristiques fournies.
Il ne doit pas ajouter d’autonomie, de dimensions ou de compatibilité inconnues.
27. Utiliser des exemples structurés pour des données chiffrées
Les exemples peuvent aussi montrer comment présenter des calculs.
Correction
La démonstration montre la structure attendue, mais les calculs doivent toujours être vérifiés.
28. Attention aux formats de dates et aux unités
Une structure cohérente doit également préciser les conventions utilisées.
Par exemple, la date « 04/05/2026 » peut être interprétée différemment selon les pays.
Il est préférable de définir un format explicite.
De la même manière, il faut préciser les unités des montants, distances ou durées.
Un exemple ne suffit pas toujours à lever toutes les ambiguïtés.
Il est préférable d’associer une règle explicite à la démonstration.
29. Protéger les données personnelles dans les exemples
Les démonstrations peuvent contenir des informations sensibles ou confidentielles.
Avant de les utiliser, il faut examiner si elles sont réellement nécessaires.
Par exemple, pour apprendre à classer des réclamations, le nom complet, l’adresse et le numéro de téléphone du client ne sont généralement pas indispensables.
Exemple inutilement détaillé
Exemple limité au nécessaire
Il est préférable d’utiliser des données fictives ou anonymisées lorsque cela est possible et adapté.
Une simple suppression du nom ne garantit pas toujours une anonymisation suffisante.
30. Vérifier la qualité d’un ensemble d’exemples
Avant d’utiliser plusieurs démonstrations, il est utile de procéder à une vérification systématique.
| Critère | Question de contrôle |
|---|---|
| Exactitude | Chaque sortie est-elle correcte ? |
| Cohérence | Les exemples appliquent-ils les mêmes règles ? |
| Structure | Les champs sont-ils identiques ? |
| Représentativité | Les situations principales sont-elles couvertes ? |
| Clarté | Les entrées et les sorties sont-elles bien séparées ? |
| Données manquantes | Une convention est-elle prévue ? |
| Confidentialité | Les données inutiles ont-elles été retirées ? |
| Validation | La méthode fonctionne-t-elle sur de nouveaux cas ? |
31. Tester les exemples sur de nouveaux cas
Un ensemble d’exemples ne doit pas être évalué uniquement sur les cas qu’il contient déjà.
Pour vérifier son efficacité, il faut utiliser des données nouvelles.
Construire un ensemble d’exemples validés.
Choisir des situations distinctes des démonstrations.
Faire traiter les nouveaux cas.
Contrôler les réponses avec des critères définis.
Corriger les exemples ou les instructions.
32. Quand faut-il utiliser un tableau plutôt que des blocs ?
Le choix dépend de la complexité des informations.
| Format | Particulièrement adapté à | Limite |
|---|---|---|
| Tableau | Entrées et sorties courtes, comparaisons. | Moins lisible pour des textes longs. |
| Blocs séparés | Cas détaillés, plusieurs champs. | Peut occuper davantage d’espace. |
| JSON | Données structurées et traitements informatiques. | Nécessite une syntaxe rigoureuse. |
| Liste numérotée | Transformations simples et étapes courtes. | Moins adaptée aux structures complexes. |
Il n’existe pas de format universellement meilleur.
33. Modèle réutilisable d’exemples structurés
Ce modèle peut être adapté à la classification, à l’extraction, à la reformulation ou à la production de documents structurés.
34. Les erreurs fréquentes
| Erreur | Conséquence possible | Correction |
|---|---|---|
| Étiquettes variables | Champs mal interprétés. | Uniformiser les noms. |
| Exemples incorrects | Reproduction d’erreurs. | Valider les sorties. |
| Exemples contradictoires | Règles confuses. | Résoudre les incohérences. |
| Démonstrations répétitives | Couverture limitée. | Varier les cas utiles. |
| Informations inutiles | Associations parasites. | Supprimer les détails superflus. |
| Absence de règle pour les données manquantes | Informations inventées. | Définir une convention. |
| Format de sortie non défini | Résultats hétérogènes. | Préciser les champs. |
| Aucun test indépendant | Fiabilité non vérifiée. | Tester sur de nouveaux cas. |
35. Cas pratique guidé : construire une fiche de réclamation
Une entreprise souhaite transformer les messages clients en fiches homogènes.
Étape 1 — Définir les rubriques
Étape 2 — Définir les catégories
- Facturation ;
- Livraison ;
- Assistance technique.
Étape 3 — Construire les démonstrations
Étape 4 — Présenter le nouveau cas
Étape 5 — Définir la réponse attendue
Étape 6 — Vérifier le résultat
La fiche doit :
- respecter les trois rubriques ;
- utiliser une catégorie autorisée ;
- reprendre uniquement les faits connus ;
- indiquer une vérification pertinente.
Les exemples structurés permettent ici de guider simultanément la classification, la rédaction du résumé et la présentation de la fiche.
36. Exercice pratique 1 — Reconnaître une structure correcte
ApplicationComparez les deux ensembles suivants.
Travail demandé :
- Identifiez l’ensemble le plus structuré.
- Relevez trois différences.
- Expliquez l’intérêt de cette structure.
Afficher la correction détaillée
1. Ensemble le plus structuré
L’ensemble B est le plus structuré.
2. Différences
- Les exemples sont numérotés.
- Les entrées sont identifiées par « Message ».
- Les sorties sont identifiées par « Catégorie ».
3. Intérêt
Cette organisation facilite la distinction entre les données et les résultats attendus.
Elle permet également d’ajouter de nouveaux exemples sans modifier la structure.
37. Exercice pratique 2 — Harmoniser des démonstrations
ApplicationLes exemples suivants utilisent des présentations différentes.
Travail demandé :
- Choisissez deux étiquettes communes.
- Réécrivez les trois démonstrations.
- Expliquez pourquoi cette harmonisation est utile.
Afficher la correction détaillée
1. Étiquettes retenues
Les étiquettes « Message » et « Catégorie » conviennent à cette tâche.
2. Démonstrations corrigées
3. Justification
Les champs ont désormais la même signification et la même présentation dans tous les exemples.
Le modèle peut identifier plus facilement la règle commune.
38. Exercice pratique 3 — Gérer les données manquantes
EntraînementUne entreprise souhaite extraire les informations suivantes :
- nom ;
- date ;
- nombre de personnes.
Message :
Travail demandé :
- Définissez une structure de sortie.
- Précisez la règle pour les informations manquantes.
- Produisez le résultat attendu.
- Expliquez pourquoi il ne faut pas inventer une date.
Afficher la correction détaillée
1. Structure
2. Règle
Si une information manque, écrire « non précisé ».
3. Résultat
4. Justification
Le message ne contient aucune date.
Inventer une date rendrait la fiche incorrecte et pourrait entraîner une erreur de réservation.
39. Exercice pratique 4 — Construire des exemples de calcul
EntraînementVous souhaitez créer des démonstrations permettant de calculer une variation en euros et en pourcentage.
Données :
- Cas A : 100 € → 120 €.
- Cas B : 200 € → 150 €.
- Nouveau cas : 80 € → 100 €.
Travail demandé :
- Définissez les champs d’entrée.
- Définissez les champs de sortie.
- Construisez deux démonstrations correctes.
- Calculez le nouveau cas.
- Expliquez l’intérêt d’utiliser une hausse et une baisse dans les exemples.
Afficher la correction détaillée
1. Structure
2. Exemple A
3. Exemple B
Calcul : (150 – 200) ÷ 200 × 100 = -25 %.
4. Nouveau cas
Calcul : (100 – 80) ÷ 80 × 100 = 25 %.
5. Intérêt
Les deux démonstrations montrent une augmentation et une diminution.
Elles illustrent donc les signes positifs et négatifs du calcul.
40. Exercice pratique 5 — Cas professionnel complet
SynthèseSituation
Une entreprise souhaite transformer les messages clients en fiches de traitement homogènes.
Chaque fiche doit comporter :
- une catégorie ;
- un résumé ;
- une information à vérifier.
Catégories autorisées :
- Facturation ;
- Livraison ;
- Assistance technique.
Messages :
Travail demandé :
- Définissez la structure des fiches.
- Construisez trois démonstrations.
- Rédigez un prompt few-shot complet.
- Traitez le nouveau message.
- Définissez trois critères de contrôle.
Afficher la correction détaillée
1. Structure
2. Démonstrations
3. Prompt complet
4. Résultat attendu
5. Contrôles
- Vérifier que la catégorie est autorisée.
- Vérifier que le résumé ne contient aucune information inventée.
- Vérifier que les trois rubriques sont présentes.
6. Conclusion
Les exemples structurés montrent ici à la fois la classification et le format attendu.
Ils peuvent faciliter l’homogénéité des fiches, à condition d’être corrects et représentatifs.
41. Questions fréquentes — 20 questions
1. Qu’est-ce qu’un exemple structuré ?
Une démonstration organisée selon des champs ou une présentation clairement définie.
2. Pourquoi utiliser des étiquettes ?
Pour distinguer les informations d’entrée des résultats attendus.
3. Quelle différence entre entrée et sortie ?
L’entrée est la donnée à traiter ; la sortie est le résultat attendu.
4. Faut-il toujours utiliser un tableau ?
Non. Des blocs, des listes ou du JSON peuvent également convenir.
5. Pourquoi utiliser des séparateurs ?
Pour distinguer clairement les démonstrations du nouveau cas.
6. Les exemples doivent-ils avoir les mêmes champs ?
Pour une tâche répétitive, une structure commune est généralement préférable.
7. Peut-on utiliser des exemples structurés en zero-shot ?
On peut demander une sortie structurée en zero-shot, mais fournir une démonstration entrée-sortie fait passer à une approche avec exemple.
8. Peut-on utiliser du JSON ?
Oui, notamment pour montrer une structure de données destinée à un traitement informatique.
9. Le JSON garantit-il une sortie valide ?
Non. Une validation technique reste nécessaire.
10. Pourquoi définir les champs obligatoires ?
Pour limiter les oublis et obtenir des résultats plus homogènes.
11. Que faire si une donnée manque ?
Définir une convention, par exemple « non précisé ».
12. Pourquoi éviter les exemples contradictoires ?
Parce qu’ils peuvent rendre la règle attendue ambiguë.
13. Pourquoi varier les démonstrations ?
Pour couvrir plusieurs situations pertinentes.
14. Qu’est-ce qu’un cas limite ?
Une situation difficile à classer selon les critères habituels.
15. Peut-on montrer une réponse incorrecte ?
Oui, si elle est clairement identifiée comme un contre-exemple.
16. Les exemples doivent-ils contenir des données personnelles ?
Non, sauf nécessité justifiée et dans le respect des règles applicables. Des données fictives ou anonymisées sont préférables lorsque cela convient.
17. Comment vérifier les démonstrations ?
En contrôlant leur exactitude, leur cohérence et leur conformité aux règles.
18. Pourquoi tester sur de nouveaux cas ?
Pour vérifier que le prompt fonctionne au-delà des exemples fournis.
19. Un exemple plus long est-il forcément meilleur ?
Non. Il doit surtout contenir les informations utiles à la tâche.
20. Quel est l’objectif principal des exemples structurés ?
Rendre les démonstrations plus claires, cohérentes et faciles à appliquer à de nouveaux cas.
42. Glossaire
| Terme | Définition |
|---|---|
| Exemple structuré | Démonstration organisée selon un format défini. |
| Entrée | Information à traiter. |
| Sortie | Résultat attendu ou produit. |
| Champ | Emplacement réservé à une information. |
| Étiquette | Nom identifiant un champ. |
| Séparateur | Élément permettant de distinguer les parties d’un prompt. |
| Classification | Attribution d’une catégorie à une information. |
| Extraction | Repérage d’informations dans une source. |
| JSON | Format textuel de représentation de données structurées. |
| Champ obligatoire | Information devant figurer dans chaque résultat. |
| Cas limite | Situation située à la frontière entre plusieurs interprétations. |
| Contre-exemple | Démonstration d’une réponse à éviter. |
| Validation | Vérification de la conformité et de l’exactitude. |
| Jeu de test | Ensemble de cas utilisés pour évaluer une méthode. |
| Few-shot prompting | Technique utilisant quelques démonstrations dans un prompt. |
43. Les dix idées essentielles à retenir
- Un exemple structuré présente clairement les entrées et les sorties.
- Les étiquettes facilitent l’identification des informations.
- Les séparateurs distinguent les démonstrations du nouveau cas.
- Les exemples doivent respecter une structure cohérente.
- Les démonstrations doivent être correctes.
- Les exemples doivent représenter les situations utiles.
- Les informations inutiles doivent être limitées.
- Les données manquantes doivent être traitées selon une règle définie.
- Les formats structurés peuvent inclure des tableaux ou du JSON.
- Les résultats doivent être testés sur de nouveaux cas.
Structurer des exemples consiste à rendre explicite la relation entre les informations fournies et les résultats attendus.
Cette organisation facilite la compréhension de la tâche par le modèle, mais ne remplace ni des instructions précises ni une vérification des réponses.
44. Ressources complémentaires
- OpenAI — Prompt Engineering : conception des prompts et utilisation d’exemples.
- Google AI for Developers — Prompting Strategies : techniques de prompting et exemples structurés.
- Anthropic — Prompt Engineering : méthodes de formulation et d’amélioration des instructions.
- CNIL : informations sur la protection des données personnelles.
Les exemples de ce cours sont fictifs et destinés à l’apprentissage. Ils ne constituent pas des résultats de tests réels de modèles d’IA.
45. Passer à la pratique
Pour progresser, entraînez-vous à :
- transformer des exemples informels en démonstrations structurées ;
- harmoniser les étiquettes ;
- ajouter des règles pour les informations manquantes ;
- vérifier les sorties ;
- tester des cas nouveaux.
46. Préparer le cours suivant
Vous savez maintenant construire des démonstrations claires et cohérentes.
Le prochain cours abordera les prompts à plusieurs étapes.
Vous apprendrez comment organiser une demande complexe en une succession d’actions, définir les résultats intermédiaires et vérifier que chaque étape prépare correctement la suivante.
3 cours sur 15 — Vous maîtrisez les principes de construction des exemples structurés.
Exercices du cours
Entraînez-vous avec 15 exercices progressifs. Ouvrez un exercice pour répondre, puis afficher sa correction.