RAG ou fine-tuning : la question ne se pose presque jamais dans ce sens

Deux problèmes différents

Un modèle de langage a deux choses : ce qu’il sait, et la façon dont il se comporte. Le RAG agit sur la première, le fine-tuning sur la seconde. Confondre les deux conduit à payer cher pour un résultat qui ne s’améliore pas.

RAG : fournir des connaissances

On récupère les bons extraits au moment de la question et on les donne au modèle. La connaissance reste à l’extérieur : on la met à jour en mettant à jour la source, sans rien réentraîner. C’est ce qu’il faut quand le modèle ignore vos produits, vos procédures ou vos clients.

Fine-tuning : façonner un comportement

On réentraîne partiellement le modèle sur des exemples entrée/sortie pour qu’il adopte systématiquement une forme : toujours produire ce JSON, toujours classer selon cette nomenclature, toujours écrire dans ce registre. La connaissance intégrée reste marginale et, surtout, figée.

Le test le plus simple : si la bonne réponse change quand vos données changent, c’est du RAG. Si la bonne réponse garde la même forme quelles que soient les données, c’est peut-être du fine-tuning.

Pourquoi le RAG gagne presque toujours

• La mise à jour est immédiate : un document corrigé aujourd’hui est utilisé dans la réponse de cet après-midi.
• Les réponses sont traçables : on peut citer la source, donc vérifier, donc corriger.
• Les permissions restent applicables : on filtre à la récupération, ce qui est impossible sur un modèle entraîné.
• Le fournisseur reste remplaçable : votre valeur est dans la récupération, pas dans des poids de modèle.
• L’erreur se diagnostique : une mauvaise réponse vient d’un mauvais extrait récupéré, ce qui s’observe et se corrige.

Ce dernier point est sous-estimé. Un modèle fine-tuné qui répond mal est une boîte noire : la seule action possible est de refabriquer un jeu de données et de réentraîner. Un système RAG qui répond mal montre exactement quels documents ont été retenus.

Quand le fine-tuning se justifie réellement

Il existe des cas légitimes, généralement en aval d’un système qui fonctionne déjà :

1. Une tâche unique, répétitive et à fort volume : classer, extraire des champs, normaliser. Un petit modèle spécialisé peut y être plus rapide et nettement moins cher qu’un grand modèle généraliste.
2. Un format de sortie strict que les instructions ne tiennent pas de façon fiable, malgré une sortie structurée.
3. Un registre de langue ou une terminologie métier très particulière, difficile à obtenir par instruction.
4. Une contrainte de latence ou de coût qui impose un modèle plus petit, qu’il faut alors spécialiser pour compenser.

Dans ces quatre cas, on connaît déjà la tâche, on a déjà des exemples réels, et on cherche à optimiser un système qui marche. C’est très différent de « on ne sait pas quoi faire, alors on fine-tune ».

Le vrai coût du fine-tuning

Le coût de calcul n’est pas le sujet. Ce qui coûte, c’est le reste :

• Constituer un jeu de données propre : plusieurs centaines à plusieurs milliers d’exemples corrects, annotés par des gens qui connaissent le métier.
• Constituer un jeu d’évaluation distinct, sans lequel on ne peut pas dire si le modèle s’est amélioré.
• Recommencer à chaque évolution significative de la tâche.
• Recommencer aussi à chaque changement de modèle de base, et les modèles changent vite.
• Assumer un modèle figé sur des connaissances datées, ce qui ramène souvent à ajouter du RAG par-dessus.

Autrement dit, le fine-tuning transforme un problème d’ingénierie en problème de données annotées. C’est un choix défendable, mais il doit être fait en connaissance de cause.

Ce qu’il faut essayer avant

Dans l’ordre, du moins coûteux au plus coûteux. Il est fréquent de s’arrêter à l’étape 2 ou 3.

1. Préciser l’instruction : rôle, contraintes, cas limites, ce qu’il ne faut pas faire. La marge de progression y est souvent considérable.
2. Imposer une sortie structurée plutôt que d’espérer un format en texte libre.
3. Ajouter quelques exemples représentatifs dans le contexte.
4. Découper la tâche : deux appels simples et vérifiables valent mieux qu’un appel qui doit tout réussir d’un coup.
5. Ajouter de la récupération d’information si le modèle manque de connaissances.
6. Alors seulement, envisager le fine-tuning, sur une tâche stabilisée et mesurée.

Les deux ensemble, dans le bon ordre

Quand les deux sont utiles, l’ordre compte : on construit d’abord la récupération, on mesure, puis on spécialise éventuellement le modèle sur une étape précise du pipeline. Par exemple un petit modèle fine-tuné pour reformuler la requête ou classer l’intention, et un modèle généraliste pour rédiger la réponse à partir des extraits.

Commencer par le fine-tuning revient à optimiser une étape d’un système qui n’existe pas encore.

Décider en une question

« Si je donne les bons documents à un humain compétent qui n’a jamais travaillé chez vous, répond-il correctement ? » Si oui, votre problème est un problème de récupération d’information : c’est du RAG. Si non (parce qu’il faut connaître une convention interne implicite, un format exact, un jargon), alors et seulement alors le fine-tuning entre dans la discussion.