Fine-tuning, RAG ou prompting : lequel choisir ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Utilisez le prompting pour clarifier la tâche, la génération augmentée par récupération (RAG) pour fournir des connaissances à jour ou privées, et le fine-tuning pour modifier un comportement reproductible du modèle. Ces techniques répondent à des problèmes différents et sont souvent combinées au sein d’un même système.
Commencez par établir une baseline de prompting mesurée. Ajoutez du RAG lorsque les réponses nécessitent des éléments de preuve externes ou des faits qui changent fréquemment. Envisagez le fine-tuning pour les erreurs persistantes de ton, de classification, de tool use ou de langage métier, lorsque vous disposez d’un nombre suffisant d’exemples vérifiés. Pour les erreurs de format de réponse, essayez d’abord un structured output contraint par un schéma.
Choisissez en fonction des erreurs observées, de la fréquence à laquelle les faits changent et des données disponibles pour tester une correction.
Tableau de décision
| Problème | Première intervention | Pourquoi |
|---|---|---|
| Les instructions manquent de clarté ou les exemples sont absents | Prompting | Cela permet de vérifier si des instructions et des exemples plus clairs résolvent les échecs observés. |
| Les faits sont privés, doivent être cités ou changent fréquemment | RAG | La récupération d’informations met à jour les connaissances sans réentraînement et peut préserver la provenance des sources. |
| Un comportement stable reste incorrect après les tests de prompts | Envisager le fine-tuning | Des exemples vérifiés peuvent enseigner un style, des étiquettes ou un comportement avec les outils ; comparez le résultat à la baseline de prompting. |
| Une baseline de prompting rigoureuse échoue toujours | Tester un autre modèle ou une autre conception système | Comparez les alternatives sur les mêmes cas ; l’échec du prompting ne suffit pas à démontrer que le fine-tuning serait utile. |
| Les réponses nécessitent des faits à jour et un comportement spécialisé | RAG plus fine-tuning | La récupération d’informations fournit les éléments de preuve tandis que le fine-tuning modifie la façon dont le modèle les exploite. |
Commencez par le prompting
Le prompting est une méthode nécessitant peu de mise en place pour diagnostiquer les échecs. Définissez la tâche, le contrat de sortie, les exemples, les outils autorisés et les conditions de refus. Constituez un petit jeu d’évaluation avant d’ajouter de l’infrastructure. Si un prompt plus efficace corrige les échecs représentatifs, arrêtez-vous là.
Si un prompt qui s’allonge devient plus difficile à maintenir, identifiez ce qui a été ajouté. Les informations produit qui évoluent peuvent relever de la récupération d’informations. Les exemples répétés de comportement peuvent servir à l’entraînement. La longueur du prompt ne prouve pas à elle seule que l’un ou l’autre changement améliorera le résultat.
Utilisez le RAG pour les connaissances et la provenance
Le RAG convient aux manuels produit, aux politiques, aux documents internes, aux événements récents et aux réponses qui doivent citer une source. L’article original sur le RAG associe un générateur à des passages récupérés ; les éléments de preuve récupérés sont fournis au moment de la requête. Sa qualité dépend de l’analyse, de la segmentation en fragments, de la récupération d’informations, du classement par pertinence, des permissions et de la prise en charge des citations. Modifier uniquement le générateur ne fournit pas une source que la récupération d’informations a omise.
Le RAG n’est pas une méthode d’entraînement du comportement. Il peut présenter au modèle un exemple ou une règle, mais ne rend pas ce comportement stable pour chaque requête.
Pour un assistant de support, une réponse obsolète sur la garantie indique que la politique actuelle manque : fournissez-la par récupération d’informations. Si la bonne politique est déjà présente, mais que l’assistant attribue régulièrement la mauvaise catégorie à la réclamation, testez d’abord des exemples plus clairs. Le fine-tuning devient une option si cette erreur de classification persistante subsiste et que des exemples d’entraînement vérifiés sont disponibles.
Utilisez le fine-tuning pour un comportement reproductible
Le fine-tuning supervisé s’effectue sur des exemples d’entrée/sortie, comme l’explique le guide d’entraînement de TRL. Il peut convenir à la classification, au style d’extraction, à la structure des réponses, à la terminologie métier et aux schémas récurrents de tool use. Pour les échecs liés uniquement au format, essayez d’abord un structured output contraint par un schéma si votre runtime le prend en charge. Une structure valide nécessite tout de même de vérifier que les valeurs des champs sont correctes.
Le fine-tuning nécessite des données d’entraînement vérifiées, un jeu d’évaluation réservé, le versionnage du modèle et une procédure de rollback. Ne faites pas de fine-tuning sur des faits qui changent fréquemment lorsque la récupération d’informations peut les fournir au moment de la requête.
Une séquence pratique
- Définissez la réussite et constituez un jeu d’évaluation représentatif.
- Établissez une baseline reposant uniquement sur le prompting, avec le modèle le plus performant acceptable.
- Ajoutez du RAG si les échecs proviennent d’éléments de preuve manquants ou changeants.
- Collectez et examinez les exemples des échecs stables qui subsistent.
- Ne faites du fine-tuning que si le gain de qualité, de latence ou de coût compense les données et les opérations supplémentaires sur le modèle.
- Relancez la même évaluation après chaque modification du prompt, de l’index, du modèle ou de l’adaptateur.
Pour approfondir
- Fine-tuning des LLMs traite des données, de LoRA, de l’évaluation et du déploiement.
- Métriques d’évaluation du RAG explique comment localiser les échecs selon l’étape du pipeline.
- Context engineering pour les agents AI traite du contexte runtime autour des prompts et de la récupération d’informations.