Comment améliorer les réponses d’un LLM ?
Améliorez les réponses avec la bonne solution : prompt, exemples, contexte, recherche documentaire, outils ou ajustement du modèle.
Objectifs de la leçon
Identifier la cause d’une mauvaise réponse avant de choisir une solution.
Écrire des prompts avec une tâche claire, des faits utiles, des contraintes et un format de sortie.
Utiliser correctement le sans exemple (zero-shot), l’exemple unique (one-shot) et quelques exemples (few-shot).
Distinguer le contexte, la génération augmentée par recherche (RAG), les outils, les agents et l’ajustement fin (fine-tuning).
Commencer par identifier la cause du problème
LLM signifie « Large Language Model », ou grand modèle de langage. Dans cette leçon, il désigne le modèle de texte dont vous souhaitez améliorer les réponses.
Une mauvaise réponse ne signifie pas toujours que le modèle est mauvais. Le prompt peut être vague, une information importante peut manquer, la tâche peut demander une donnée actuelle ou le format attendu peut ne jamais avoir été précisé.
La solution dépend de la cause. Une consigne plus claire corrige l’ambiguïté. Le contexte ou la génération augmentée par recherche (RAG, de l’anglais « Retrieval-Augmented Generation ») apporte des connaissances. Un outil effectue un calcul ou récupère une donnée actuelle. Des exemples montrent un format particulier. L’ajustement fin (fine-tuning) modifie un comportement stable qui doit être répété à grande échelle.
Testez toujours la solution la plus simple en premier. Réécrire un prompt prend quelques minutes ; construire un système RAG ou fine-tuner un modèle demande des données, du développement, des évaluations, de la maintenance et un budget supplémentaire.
| Problème observé | Cause probable | Première solution à tester |
|---|---|---|
| La réponse est vague ou utilise le mauvais format. | La consigne et les critères de réussite sont imprécis. | Réécrire le prompt avec un objectif, des contraintes et un format précis. |
| Le modèle invente un prix ou une règle de l’entreprise. | L’information nécessaire manque dans le contexte. | Fournir le document source ou le rechercher avec un RAG. |
| La réponse utilise un ancien taux de change ou un stock dépassé. | La tâche exige une information actuelle. | Connecter un outil web, une base de données ou le système de l’entreprise. |
| Le modèle comprend la tâche, mais ne respecte pas un style particulier. | Le comportement attendu est difficile à décrire uniquement avec des règles. | Ajouter un ou plusieurs exemples approuvés. |
| La même tâche répétitive reste instable malgré de bons prompts et exemples. | Le comportement peut nécessiter une adaptation du modèle. | Mesurer une référence, puis envisager le fine-tuning. |
Ne pas fine-tuner un modèle pour lui apprendre le stock du jour
Une boutique veut que son assistant indique si un produit est disponible. Le stock change après chaque vente. Réentraîner le modèle à chaque modification serait lent et l’information deviendrait immédiatement dépassée.
Utilisez un outil relié au stock ; le modèle doit expliquer le résultat, pas mémoriser une information qui change sans cesse.
Ne pas changer de modèle avant de corriger un prompt incomplet
Un restaurant de Cotonou demande : « Rédige ma publicité. » La réponse reste générique, car le prompt ne donne ni menu, ni prix, ni public, ni canal, ni offre. Un modèle plus coûteux devrait lui aussi deviner ces informations.
Améliorez d’abord les informations données au modèle avant de choisir un modèle plus puissant.
Donner une consigne complète et vérifiable
Un bon prompt n’a pas besoin d’être long. Il doit surtout contenir les informations qui influencent la réponse : la tâche exacte, le public, les faits à utiliser, les limites à respecter, le format attendu et les critères de réussite.
Formulez des contraintes vérifiables. « Fais quelque chose de professionnel » reste subjectif. « Utilise un français simple, moins de 80 mots, uniquement le prix fourni et termine par une question de commande » peut être contrôlé.
Précisez aussi ce que le modèle doit faire lorsqu’une information manque. Il peut poser une question, utiliser null dans une sortie structurée, lister les données absentes ou indiquer clairement que la réponse ne peut pas être confirmée.
Tâche L’action exacte que le modèle doit réaliser.
Rédiger un message de lancement WhatsApp, pas « parler de mon produit ».
Contexte et faits Les informations nécessaires pour comprendre la situation et éviter les inventions.
Produit, prix, public, ville, date et affirmations autorisées.
Contraintes Les règles que la réponse doit respecter.
Aucune promesse médicale, 80 mots maximum et aucune réduction inventée.
Format de sortie La structure dans laquelle le résultat doit être rendu.
Format JSON (« JavaScript Object Notation »), tableau, email, checklist, script ou trois points.
Une demande vague oblige le modèle à décider à votre place
Le prompt indique seulement : « Rédige un message commercial pour mon savon. » Le modèle doit deviner le public, le prix, le format, les avantages, le canal, le ton et la longueur. La réponse peut sembler réussie tout en contenant des informations fausses.
Si une information compte, fournissez-la ou demandez explicitement au modèle de ne pas l’inventer.
Une demande précise rend le résultat plus facile à évaluer
Le prompt demande un message WhatsApp de moins de 70 mots pour un savon de 100 g, parfum citron, fabriqué à Bohicon et vendu à 1 500 FCFA. Il vise les familles du marché, interdit les promesses médicales et doit terminer par une question simple pour commander.
Les faits, le public, le canal, la longueur et les affirmations interdites peuvent tous être vérifiés.
Montrer un exemple lorsque les consignes ne suffisent pas
Le sans exemple (zero-shot) consiste à donner uniquement la consigne. Il convient aux tâches connues et faciles à expliquer. L’exemple unique (one-shot) ajoute un seul modèle de réponse. La méthode avec quelques exemples (few-shot) en ajoute plusieurs pour montrer la décision, le style ou la structure attendue.
Les exemples sont particulièrement utiles lorsque les catégories appartiennent à votre organisation, lorsque les clients emploient des expressions locales ou lorsque le ton attendu est plus facile à montrer qu’à décrire.
De mauvais exemples produisent un mauvais comportement. Vérifiez les catégories, couvrez des cas différents et évitez toute contradiction avec la consigne. Les cas utilisés pour l’évaluation finale ne doivent pas être les mêmes que les exemples placés dans le prompt.
| Méthode | Contenu du prompt | Quand l’utiliser |
|---|---|---|
| Zero-shot | Uniquement la consigne et l’entrée. | La tâche et les catégories sont simples et connues. |
| One-shot | Un exemple entrée-sortie approuvé avant le nouveau cas. | Un exemple suffit à clarifier la structure attendue. |
| Few-shot | Plusieurs exemples variés suivis du nouveau cas. | La tâche dépend de formulations locales, de catégories particulières, du ton ou de cas limites. |
Utiliser le few-shot pour des catégories propres à l’entreprise
Une équipe de support Mobile Money distingue « destinataire non crédité » de « transfert échoué ». Ces catégories peuvent sembler proches pour un modèle général. Le prompt fournit plusieurs messages approuvés pour chaque catégorie, avec une orthographe informelle et les termes de paiement courants.
Les exemples montrent la frontière entre les catégories plus clairement qu’une définition courte.
Utiliser des exemples pour montrer la voix d’une marque
Une marque décrit son ton comme « chaleureux et simple », mais les modèles interprètent ces mots différemment. Trois messages approuvés montrent la longueur des phrases, le vocabulaire, le niveau de familiarité et les promesses acceptées.
Quelques bons exemples transmettent souvent le style mieux qu’une longue liste d’adjectifs.
Ajouter des connaissances ou des actions sans réentraîner le modèle
Le contexte consiste à placer directement les informations nécessaires dans la demande. C’est la solution la plus simple pour une courte procédure, un tableau, une conversation ou un extrait de document utilisé ponctuellement.
La génération augmentée par recherche (RAG, « Retrieval-Augmented Generation » en anglais) consulte une collection de documents avant chaque réponse et place les passages les plus pertinents dans le contexte du modèle. Elle devient utile lorsque les connaissances sont privées, nombreuses ou régulièrement mises à jour.
Un outil donne au modèle une capacité externe : recherche web, calcul, consultation d’une base de données, analyse de fichier, envoi d’un email ou génération de média. Un agent combine un modèle, des instructions, des outils et plusieurs étapes pour réaliser un objectif plus large.
| Besoin | Mécanisme | Exemple concret |
|---|---|---|
| Quelques faits pour une demande | Contexte | Coller la liste actuelle des produits et des prix dans le prompt. |
| Rechercher dans de nombreux documents internes | RAG | Trouver la règle scolaire pertinente avant de répondre à un parent. |
| Obtenir une information actuelle | Outil | Rechercher le taux de change officiel ou consulter le stock du jour. |
| Effectuer une opération exacte | Outil | Calculer le total d’une facture ou consulter une base de transactions. |
| Réaliser un projet en plusieurs étapes | Agent | Rechercher, préparer un plan, rédiger des fichiers, générer des visuels et livrer le résultat final. |
Utiliser le RAG pour répondre selon les règles de l’école
Une école possède des dizaines de documents sur les frais, les absences, les examens, les uniformes et les inscriptions. Lorsqu’un parent pose une question, le système RAG retrouve les passages concernés et les transmet au modèle avant la rédaction de la réponse.
La réponse peut respecter les documents actuels de l’école au lieu de dépendre des connaissances générales du modèle.
Utiliser un outil pour une valeur qui change chaque jour
Un utilisateur demande le taux de change officiel du jour. Le modèle peut expliquer le résultat, mais un outil web ou financier doit d’abord récupérer le taux actuel auprès d’une source fiable.
L’outil fournit la donnée actuelle ; le modèle la transforme en réponse utile.
Utiliser l’ajustement fin (fine-tuning) pour un comportement durable
L’ajustement fin (fine-tuning) poursuit l’entraînement d’un modèle existant avec un jeu de données préparé. Il sert à rendre plus fiable un comportement répétitif : un système de classification, une structure de sortie stable, une terminologie spécialisée ou un style récurrent.
Le fine-tuning n’est pas une base de données. Il convient mal aux prix, aux stocks, aux règlements, aux horaires et aux informations qui changent régulièrement. Ces faits doivent venir du contexte, d’un RAG ou d’un outil.
Avant de fine-tuner, mesurez le modèle actuel avec un benchmark. Préparez des exemples d’entraînement de qualité, séparez les ensembles de validation et de test, comparez le modèle adapté à la référence et vérifiez que ses autres capacités utiles n’ont pas régressé.
Ensemble d’entraînement Les exemples utilisés pour modifier le comportement du modèle.
Message client associé à la catégorie et à la réponse approuvées.
Ensemble de validation Des exemples séparés utilisés pendant le développement et les ajustements.
Repérer le surapprentissage avant l’évaluation finale.
Ensemble de test Des exemples jamais utilisés auparavant pour la comparaison finale avec la référence.
Mesurer si l’amélioration fonctionne sur de nouveaux cas.
Adaptation de faible rang (LoRA) LoRA signifie « Low-Rank Adaptation ». Cette méthode entraîne un petit ensemble de paramètres ajoutés plutôt que tous les poids du modèle.
Adapter un modèle open weight avec moins de puissance de calcul qu’un ajustement complet.
Un projet adapté au fine-tuning
Une entreprise traite des milliers de messages d’incident récurrents. Chaque résultat doit utiliser les mêmes catégories, niveaux de gravité, champs obligatoires et formulations approuvées. De bons prompts et exemples améliorent le résultat, mais le format échoue encore trop souvent à grande échelle.
Le comportement est stable, répétitif, mesurable et soutenu par de nombreux exemples approuvés.
Un projet qui ne demande pas de fine-tuning
Une boutique veut que son assistant connaisse le stock du matin, les prix actuels et les produits qui viennent d’être épuisés. Ces informations peuvent changer plusieurs fois dans la journée.
Connectez l’assistant au système de stock ; n’entraînez pas le modèle à mémoriser des faits changeants.
Utilisez la solution la plus légère qui corrige le problème mesuré. Une meilleure consigne doit souvent être testée avant une infrastructure plus lourde.