RAG ou fine-tuning : l’arbitrage par le coût

Le RAG fournit au modèle des faits récupérés dans un corpus au moment de la question, alors que le fine-tuning modifie le modèle lui-même pour lui apprendre une manière de répondre. Ce sont deux outils pour deux besoins distincts.

Le RAG, ou génération augmentée par récupération, cherche dans une base documentaire les passages utiles à la question, puis les place dans le contexte envoyé au modèle. Le principe et ses raisons sont exposés dans le RAG, la seule architecture qui tienne. Le fine-tuning, ou réglage fin, ré-entraîne un modèle existant sur un jeu d’exemples pour qu’il adopte un format, un vocabulaire ou un ton.

L’affinage apprend donc au modèle une manière : un format de sortie, un vocabulaire métier, un ton, une structure de document. Il est très efficace pour cela, et rien d’autre ne le remplace bien.

La récupération apporte des faits : le contenu du contrat signé en mars, le montant du plafond en vigueur, la référence de la procédure applicable. Elle n’améliore pas la manière, elle fournit la matière.

L’erreur courante consiste à utiliser l’un pour répondre à l’autre : typiquement, affiner un modèle pour lui « apprendre » des faits qui changeront.

Comparer RAG et fine-tuning exige de mesurer la qualité sur le corpus et la tâche visés, puis de chiffrer préparation, exploitation et reprises sur la durée du service. La question utile est ailleurs.

En cadrage, je remplace cette comparaison par une autre : que se passe-t-il quand une information change. C’est cette question qui tranche, parce qu’en entreprise l’information change tout le temps. Un tarif, une procédure, un plafond réglementaire, une gamme de produits : chaque modification doit se retrouver dans les réponses, et le coût de cette propagation diffère radicalement d’une approche à l’autre.

Le choix entre RAG et fine-tuning dépend du rythme de mise à jour des faits, de leur justification, des droits d’accès, du format attendu et des conditions de migration.

• À quelle fréquence l’information change ? Au-delà de quelques fois par an, l’affinage devient une charge récurrente.
• Faut-il citer la source ? Si oui, prévoir des sources identifiables et vérifier qu’elles soutiennent la réponse ; les poids seuls ne constituent pas cette preuve.
• Y a-t-il des droits d’accès différenciés ? Un modèle affiné a tout absorbé et ne peut pas cloisonner.
• Le format de sortie est-il très spécifique ? C’est le cas où l’affinage apporte quelque chose que le prompt ne donne pas.
• Combien de temps le modèle restera-t-il en place ? Un affinage est perdu au changement de génération.

Le vrai coût d’un fine-tuning n’est pas celui de l’entraînement mais celui de sa répétition, qui revient à chaque évolution du corpus comme à chaque changement de modèle de base. C’est ce qui décide.

Chaque cycle comprend la constitution du jeu de données, l’entraînement, l’évaluation et le déploiement. Ce cycle se multiplie par le nombre de fois où il faudra recommencer sur la durée de vie du service.

Une dépréciation annonce une transition ; un retrait rend la version indisponible. Leur calendrier dépend du fournisseur et du modèle : il faut vérifier le préavis et la possibilité de migrer l’affinage, sans attribuer une durée de vie générale.

La récupération peut être réutilisée au changement de modèle, mais prompts, format et qualité doivent être revalidés : c’est le bénéfice de la réversibilité décrit dans la couche qui rend le modèle remplaçable. Le coût de la récupération se situe ailleurs, dans la tenue du corpus et la réindexation, comme le rappelle le corpus est le projet.

Budgéter un affinage demande de compter la préparation des exemples, l’entraînement, l’évaluation et le déploiement à chaque reprise effectivement nécessaire, sans supposer une cadence annuelle universelle.

Le coût d’un affinage n’est pas celui de l’entraînement. C’est celui de sa répétition : constitution du jeu de données, entraînement, évaluation, déploiement, multiplié par le nombre de fois où il faudra recommencer sur la durée de vie du service.

Pour choisir entre RAG et fine-tuning, on qualifie d’abord le besoin (faits ou manière), puis on teste le prompt seul sur un jeu de cas avant d’envisager tout affinage. La méthode tient en cinq étapes.

1. Séparer les besoins : lister ce qui relève des faits (contenus, montants, références) et ce qui relève de la forme (structure, ton, mentions obligatoires).
2. Construire un jeu de tests de cas réels avec la réponse attendue, selon la méthode de construire un jeu de tests en une journée.
3. Mesurer le prompt seul, avec des exemples et, si le fournisseur le permet, une sortie structurée. Les capacités de sortie structurée peuvent éviter un affinage motivé seulement par le format, comme décrit dans sorties structurées : le format garanti supprime une étape.
4. Ajouter la récupération pour tous les faits susceptibles de changer, avec citation des sources.
5. N’envisager l’affinage que si, mesures à l’appui, la forme ne tient toujours pas, et chiffrer alors son coût de répétition sur la durée de vie prévue.

Combiner un fine-tuning léger pour le format et le registre avec une chaîne de récupération pour le contenu couvre les situations où l’une des deux approches seule ne suffit pas. Je la retiens lorsque les essais montrent deux besoins distincts.

Le cas typique est la rédaction de documents normés : comptes rendus réglementés, notes internes à structure imposée, fiches standardisées, réponses commerciales avec des mentions obligatoires, produits à partir d’un corpus qui évolue. L’affinage peut stabiliser la forme, la récupération rend le contenu vérifiable ; ni l’un ni l’autre ne garantit l’exactitude de la réponse.

Chacun se met à jour indépendamment, ce qui est précisément ce qu’on cherche. Mais je ne le mets en place qu’après avoir constaté, mesures à l’appui, que le prompt seul ne tient pas la forme. Dans la majorité des cas, il la tient.

L’erreur la plus fréquente consiste à affiner un modèle pour lui faire mémoriser des faits d’entreprise qui changeront, alors que l’affinage ne garantit ni leur exactitude ni leur mise à jour. Plusieurs autres erreurs en découlent.

• Affiner avant d’avoir mesuré le prompt seul, et payer un entraînement pour un gain qu’un exemple bien choisi aurait apporté.
• Oublier l’exigence de preuve : un utilisateur métier, un auditeur ou un juriste demandera d’où vient la réponse.
• Ignorer les droits d’accès : un modèle affiné sur l’ensemble des documents peut restituer à n’importe qui ce qu’il a absorbé.
• Ne pas chiffrer la durée de vie du modèle de base, et découvrir la dépréciation au moment où l’affinage commence à rapporter.
• Sous-estimer la récupération : sa qualité dépend du découpage et de la recherche, ce qu’explique les embeddings expliqués à une direction.

Pour arbitrer sur un cas réel, un audit IA part de ces critères et des volumes constatés.

La récupération constitue un point de départ pertinent pour des faits documentaires évolutifs, tandis que l’affinage doit répondre à un défaut précisément mesuré sur la tâche et le format. Je décide sur la charge d’entretien.

Quand un document change, il faut actualiser l’index et vérifier la nouvelle réponse. Si les faits sont incorporés aux exemples d’entraînement, leur correction peut demander de reprendre ces exemples puis l’évaluation. L’écart économique vient de cette chaîne, pas d’un calendrier supposé de remplacement des modèles.

Un exercice de formation IA peut comparer les deux parcours sur une même procédure corrigée : retrouver sa version, produire le résultat attendu et expliquer ce qui doit être redéployé.

Je ne tire pas de conclusion générale sur les affinages abandonnés en 2023 ou 2024 : une annonce de nouveau modèle ne prouve ni l’abandon d’un service existant ni l’inutilité de son jeu de données.