« On finetune le modèle sur nos données » : j'entends cette phrase une fois par mois, et la moitié du temps le bon outil aurait été du RAG. Les deux approches adaptent un LLM à ton contexte, mais elles n'agissent pas du tout au même endroit — et confondre les deux coûte cher, en temps GPU comme en résultats décevants.
Deux mécanismes qu'on confond
Le RAG et le finetuning répondent tous les deux à la question « comment adapter un LLM générique à mon cas précis ». Mais l'un agit au moment de la requête (RAG), l'autre au moment de l'entraînement (finetuning). Une fois qu'on visualise où chacun intervient dans le pipeline, la plupart des mauvais choix d'architecture deviennent évidents.
RAG : le contexte change, pas le modèle
Le RAG ne touche jamais aux poids. À chaque requête, tu calcules un embedding, tu retrouves les passages pertinents, et tu les colles dans le prompt. Le modèle reste strictement le même avant et après : ce qui change, c'est uniquement ce qu'il lit au moment de générer sa réponse.
Conséquence directe : mettre à jour la connaissance du système, c'est juste réindexer un document. Pas de réentraînement, pas de GPU à louer, un déploiement en minutes. C'est aussi pour ça que le RAG reste souvent préférable même quand un tool use direct existe pour la même donnée — voir RAG vs tool use direct pour trancher entre les deux.
Finetuning : les poids changent, via LoRA
Un finetuning complet réentraîne tous les paramètres du modèle — des milliards de poids, donc des dizaines de GPU-heures et un risque réel de catastrophic forgetting (le modèle oublie des capacités générales en apprenant la tâche spécifique). En pratique, presque personne ne fait plus ça directement. La technique standard s'appelle LoRA (Low-Rank Adaptation), et son intuition mérite d'être comprise plutôt que traitée comme une boîte noire.
Au lieu de modifier la matrice de poids W d'une couche, LoRA la gèle et ajoute un delta ΔW = B·A, où A et B sont deux petites matrices de rang r (typiquement 8 à 64). Si W fait 4096×4096, entraîner A et B avec r=16 revient à entraîner environ 130 000 paramètres au lieu de 16 millions pour cette seule couche — un facteur ~100 de réduction. Un paramètre alpha vient ensuite calibrer l'amplitude de ΔW (le ratio alpha/r agit comme un taux d'apprentissage effectif). Une fois l'entraînement fini, deux options : fusionner ΔW dans W (zéro coût à l'inférence), ou garder l'adapter séparé pour le brancher/débrancher selon le cas d'usage.
Côté outillage, c'est l'écosystème Python qui porte cette technique : la lib peft de Hugging Face implémente LoRA en quelques lignes au-dessus d'un modèle transformers, et bitsandbytes permet de quantifier le modèle de base en 4 bits (QLoRA) pour faire tenir l'entraînement sur un seul GPU grand public. Rien d'équivalent côté PHP — c'est une des raisons pour lesquelles cette partie du métier reste ancrée en Python.
Comparaison
| Critère | RAG | Finetuning (LoRA) |
|---|---|---|
| Ce qui change | Le contexte du prompt | Les poids du modèle (delta) |
| Coût pour démarrer | Embeddings + stockage vectoriel | GPU + curation d'un dataset d'exemples |
| Fraîcheur des connaissances | Immédiate (réindexer) | Figée à la date du dataset |
| Ce qu'il corrige bien | Faits, données qui bougent | Style, format, comportement, ton |
| Risque d'hallucination sur les faits | Dépend de la qualité du retrieval | Reste présent — le modèle n'apprend pas des faits comme une DB |
| Cycle d'itération | Quasi temps réel | Heures (entraînement + évaluation) |
Le vrai critère de décision
La question à se poser n'est pas « lequel est le plus performant » mais « qu'est-ce qui doit changer ». Si c'est une connaissance qui évolue (prix, stock, docs internes), c'est du RAG — un finetuning figerait cette connaissance et il faudrait tout réentraîner à chaque mise à jour. Si c'est un comportement stable (ton de marque, format de sortie strict, façon de raisonner sur un type de tâche), c'est du finetuning — le RAG ne peut pas apprendre un style, il ne fait qu'ajouter du texte au contexte.
Un signal pratique pour éviter de sur-investir : si le comportement souhaité tient dans quelques exemples en few-shot prompting, le finetuning n'apporte souvent rien de plus qu'un prompt bien construit, en coûtant beaucoup plus cher à maintenir.
Le piège classique
Finetuner un modèle « pour lui apprendre les infos de l'entreprise » est l'erreur la plus fréquente. Le modèle ne stocke pas des faits comme une base de données interrogeable — il apprend des motifs statistiques à partir des exemples vus. Avec un dataset de quelques centaines d'exemples, il va halluciner sur les faits qu'il n'a pas assez vus, exactement comme avant le finetuning. Le RAG reste supérieur pour ça, même après un finetuning coûteux.
Le pattern qui marche en prod combine les deux : finetuning léger (LoRA) pour le format et le comportement, RAG pour les faits qui doivent rester exacts et à jour. Pour limiter le coût des requêtes répétitives sur ce genre d'architecture hybride, voir aussi cache sémantique pour LLM.
FAQ
Peut-on combiner RAG et finetuning ?
Oui, c'est même le pattern le plus robuste en prod : finetuning (LoRA) pour le format et le comportement, RAG pour les faits et connaissances qui évoluent.
LoRA remplace-t-il un finetuning complet ?
Dans l'immense majorité des cas oui — LoRA atteint des performances proches du finetuning complet en entraînant une fraction des paramètres, pour une fraction du coût GPU.
Le finetuning est-il utile pour ajouter des connaissances récentes ?
Non, c'est le rôle du RAG. Le finetuning fige des connaissances à la date du dataset et coûte cher à répéter à chaque mise à jour.