Fine-tuning vs Prompting

Définition

Le choix entre Fine-tuning (adapter les poids du modele) et Prompting (utiliser des instructions dans le contexte) est une decision architecturale fondamentale pour les applications LLM enterprise. Ces deux approches ont des tradeoffs distincts en termes de cout, latence, performance et maintenance. Quand choisir le Prompting d'abord : (1) Prototypage rapide — pas de temps/budget pour le fine-tuning, (2) Taches peu courantes — pas assez de donnees (< 100 exemples), (3) Variabilite elevee — les cas d'usage changent frequemment, (4) Acces aux connaissances recentes — le modele de base est plus a jour que le fine-tune. Le prompt engineering + RAG resout souvent 80% des besoins enterprise sans fine-tuning. Quand choisir le Fine-tuning : (1) Format de sortie tres specifique et contraint (JSON schema custom, code dans un DSL particulier), (2) Vocabulaire et style tres specifique du domaine (terminologie interne, format de rapport standardise), (3) Performance insuffisante du prompting meme avec beaucoup d'exemples, (4) Latence/cout d'inference critique — un modele fine-tune plus petit peut remplacer un grand modele avec prompting complexe. Le continuum entre les deux : Few-shot prompting (quelques exemples dans le prompt) > Prompt Tuning / Soft Prompts (prompts appris) > LoRA/QLoRA (fine-tuning de quelques parametres) > SFT complet (fine-tuning de tous les poids) > Pre-training. Chaque etape augmente le cout de creation mais peut ameliorer la performance sur la tache cible. La regle empirique 2024 : commencer toujours par le prompting (prompt engineering + RAG), mesurer les performances sur un eval set representatif, et envisager le fine-tuning seulement si les resultats sont insuffisants et si un dataset d'entrainement de qualite (500+ exemples) est disponible. Le fine-tuning ameliore rarement les connaissances (c'est le role du RAG et du pre-training) mais ameliore le style, le format et les comportements specifiques.