Prompt Engineering vs Fine-Tuning : quelle stratégie choisir
Un cadre d'ingénierie pour choisir entre prompt engineering, fine-tuning et RAG selon les compromis coût, latence et qualité.
Prompt engineering vs fine-tuning : quelle stratégie adopter
La question revient dans chaque projet LLM : faut-il investir dans le prompt engineering, fine-tuner un modèle, ou construire un système RAG ? Ce n'est pas une question de préférence technique — c'est une décision d'ingénierie avec des implications sur les coûts, la maintenabilité, la latence et la qualité.
Le cadre de décision
Trois dimensions structurent le choix :
1. Stabilité du domaine : vos données et vos règles métier changent-elles fréquemment ? 2. Volume de données d'entraînement : avez-vous des centaines ou des milliers d'exemples labelisés ? 3. Contraintes opérationnelles : quelles sont vos exigences de latence, de coût, de confidentialité ?
Quand le prompt engineering suffit
Le prompting est la bonne réponse quand :
- Le domaine est volatile : les règles changent souvent, le modèle doit s'adapter rapidement
- Vous avez peu de données d'entraînement (< 100 exemples)
- Le modèle de base couvre déjà le domaine (langues courantes, tâches générales)
- Vous avez besoin de flexibilité : modifier le comportement en production sans re-déploiement
Heuristique empirique : un system prompt bien structuré permet souvent
d'atteindre ~80% de la qualité accessible sans fine-tuning — selon le domaine
et la tâche. Ce chiffre varie significativement en pratique.
Les techniques de prompting avancées — chain-of-thought, few-shot examples, structured outputs avec JSON schema, role prompting — permettent d'atteindre des performances remarquables. L'investissement est faible, l'itération est rapide, le coût marginal est nul.
Limite critique : le prompting ne peut pas injecter de connaissance factuelle que le modèle n'a pas. Pour des données propriétaires ou récentes, il faut RAG ou fine-tuning.
Quand fine-tuner
Le fine-tuning devient pertinent quand :
- Le domaine est stable et spécialisé (terminologie technique, format de sortie très contraint)
- Vous avez suffisamment de données (500+ exemples de haute qualité, idéalement 5000+)
- Vous avez des contraintes de latence : un modèle fine-tuné plus petit bat souvent un grand modèle avec un long system prompt
- Vous avez des contraintes de confidentialité fortes : dans ce cas, le point décisif n'est pas le fine-tuning en soi mais le mode d'hébergement du modèle et du pipeline — fine-tuner via un service externe ne résout pas automatiquement le sujet
# Structure typique d'un dataset de fine-tuning (format OpenAI)
training_example = {
"messages": [
{
"role": "system",
"content": "Tu es un assistant spécialisé en droit français des contrats."
},
{
"role": "user",
"content": "Quelle est la différence entre une clause pénale et des dommages-intérêts ?"
},
{
"role": "assistant",
"content": "La clause pénale est une stipulation contractuelle...",
# Réponse experte validée par un juriste
}
]
}Le fine-tuning sur des modèles open-source (Mistral, LLaMA 3, Qwen) avec des techniques comme LoRA ou QLoRA permet d'obtenir des modèles domain-specific en quelques heures sur du hardware accessible.
Quand utiliser RAG plutôt que fine-tuning
RAG est souvent confondu avec le fine-tuning, mais ils répondent à des besoins différents :
| Besoin | Fine-tuning | RAG |
|---|---|---|
| Style/format de réponse | Oui | Non |
| Connaissances factuelles récentes | Limité | Oui |
| Corpus volumineux (>10K docs) | Impraticable | Oui |
| Traçabilité des sources | Non | Oui |
| Mise à jour en temps réel | Non | Oui |
La règle empirique : fine-tunez pour le comment (style, format, comportement), utilisez RAG pour le quoi (contenu factuel, connaissances métier).
Matrice de coût comparée
| Stratégie | Coût initial | Coût marginal/requête | Maintenance |
|---|---|---|---|
| Prompting seul | Faible | Élevé (grand modèle) | Faible |
| RAG | Moyen (infra index) | Moyen | Moyen (index) |
| Fine-tuning + modèle hébergé | Moyen | Faible (petit modèle) | Élevé |
| Fine-tuning + déploiement propre | Élevé | Très faible | Très élevé |
La stratégie combinée
En pratique, les systèmes production-grade combinent les trois approches :
- Un modèle fine-tuné pour le style, le format et les comportements critiques
- RAG pour injecter les connaissances domaine et les données récentes
- Des prompts système pour les instructions contextuelles et les guardrails
Cette architecture en couches maximise la qualité tout en minimisant les coûts à l'échelle. La clé est de ne pas sur-investir dans le fine-tuning avant d'avoir épuisé les gains accessibles par prompting et RAG — dans cet ordre.