Fine-tuning ou RAG : choisir, données et coûts

Choisissez le RAG si le modèle doit consulter des informations privées, récentes ou accompagnées de sources ; envisagez le fine-tuning si vous devez améliorer durablement un comportement spécialisé à partir d’exemples corrigés. Commencez par mesurer les erreurs d’un modèle correctement instruit : les deux techniques peuvent se combiner, mais aucune ne remplace des données fiables ni une évaluation indépendante.

Ce que chaque approche change réellement

Le RAG, ou génération augmentée par récupération, ajoute une recherche avant la réponse. Le système sélectionne des passages dans une collection documentaire, puis les transmet au modèle avec la question. Dans cette architecture courante, les paramètres du modèle générateur restent inchangés.

Le fine-tuning poursuit l’entraînement d’un modèle existant. Dans sa forme supervisée, il utilise des exemples associant une entrée à la sortie souhaitée : classer une demande, extraire des champs ou rédiger une réponse selon une convention métier.

La distinction entre connaissances et comportement constitue un bon point de départ, mais pas une frontière absolue. Un entraînement peut faire mémoriser des faits ; des exemples ajoutés au contexte peuvent modifier le comportement. La question pratique est de savoir où placer l’information pour pouvoir la contrôler, l’actualiser et vérifier son utilisation.

La comparaison publiée dans la documentation AWS recommande de commencer par le RAG pour interroger des documents propres à une organisation. Elle précise aussi que les deux approches peuvent être associées.

Pour examiner les composants disponibles, consultez les fiches des modèles de langage. Un bon modèle de base pour votre tâche peut éviter une personnalisation coûteuse.

Tableau de décision : informations, comportement et contraintes

Critère	RAG	Fine-tuning
Objectif principal	Donner accès à des informations sélectionnées	Adapter les réponses à une tâche ou à un comportement
Données de départ	Documents exploitables et métadonnées	Exemples représentatifs avec sorties attendues
Actualisation	Mettre à jour les sources et leur index	Préparer et évaluer un nouvel entraînement
Références documentaires	Possibles si les passages conservent leur provenance	Non fournies automatiquement par l’apprentissage
Contrôle des accès	À appliquer lors de la sélection documentaire	Difficile à individualiser pour les faits mémorisés
Coût initial	Préparation, ingestion, recherche et intégration	Annotation, entraînement, évaluation et déploiement
Coût par demande	Recherche, contexte transmis et génération	Inférence du modèle personnalisé et hébergement éventuel
Défaillance caractéristique	Le passage utile n’arrive pas au modèle	Le comportement appris se généralise mal

Une documentation qui change souvent, des procédures internes ou des fiches produits orientent vers la récupération. Une classification stable et répétitive, avec des catégories bien définies, peut justifier un entraînement spécialisé.

La traçabilité impose toutefois une précision : récupérer une source ne garantit pas que la réponse la respecte. Il faut conserver le passage utilisé, vérifier qu’il soutient l’affirmation et distinguer une référence pertinente d’un simple lien ajouté en fin de réponse.

Enfin, ni le RAG ni le fine-tuning ne sont indispensables pour toutes les tâches. Si quelques documents tiennent dans le contexte et que leur accès est autorisé, les transmettre directement peut suffire. Pour un calcul exact ou une donnée transactionnelle, une requête déterministe peut être préférable.

Diagnostiquer les erreurs avant de choisir

Constituez un ensemble de demandes représentatives et observez une solution simple : instructions claires, exemples pertinents et modèle adapté. Classez ensuite les erreurs selon leur cause probable, plutôt que de les regrouper sous une mauvaise note globale.

Un diagnostic utile consiste à fournir manuellement le passage correct au modèle. S’il répond correctement, la difficulté se situe probablement dans l’accès aux informations. S’il échoue malgré une preuve complète et lisible, examinez les instructions, la capacité du modèle ou la complexité de la tâche.

Distinguez notamment :

Information absente : le système ne dispose pas de la réponse.
Recherche défaillante : la réponse existe, mais le passage utile n’est pas récupéré.
Mauvaise exploitation : le bon passage est présent, mais mal interprété.
Comportement instable : le modèle comprend, mais applique mal une convention récurrente.
Tâche mal définie : les évaluateurs eux-mêmes ne s’accordent pas sur la sortie attendue.

Le fine-tuning mérite une expérimentation lorsque le comportement reste défaillant malgré des instructions et un contexte satisfaisants. Il ne corrige pas directement une extraction documentaire qui a perdu les colonnes d’un tableau.

Pour un format strict, testez d’abord une génération contrainte par un schéma, si votre moteur la permet, puis une validation applicative. Entraîner le modèle à produire une structure ne dispense pas de vérifier les champs, les types et les valeurs autorisées.

Les données nécessaires pour construire un RAG

Un dossier rempli de fichiers n’est pas encore une base de connaissances exploitable. Il faut identifier les documents faisant autorité, écarter les doublons et conserver la date d’application, la version documentaire, la provenance et les droits d’accès.

La préparation dépend du contenu. Un tableau exige de préserver les relations entre cellules ; une procédure doit garder ses conditions et exceptions. Découper mécaniquement les documents peut séparer une règle de la restriction qui en change le sens.

Un embedding représente un contenu sous forme numérique pour faciliter la recherche par similarité. Il ne vérifie ni sa validité ni son actualité. Selon les demandes, une recherche combinant proximité sémantique, mots-clés et filtres peut mieux convenir qu’une recherche sémantique seule.

Préparez aussi des questions de référence associées aux passages attendus. Incluez les acronymes métier, les références exactes, les questions ambiguës et les demandes sans réponse disponible. Vous évaluerez ainsi la sélection documentaire avant même de juger la rédaction.

Le guide de référence sur le RAG détaille le découpage et l’indexation. Pour choisir une solution, notre sélection d’outils de bases documentaires et RAG permet d’examiner les composants sans confondre une base de recherche avec une application complète.

Prévoyez enfin le retrait des documents périmés. Ajouter une nouvelle procédure sans désactiver l’ancienne laisse le système choisir entre des textes contradictoires, parfois presque identiques.

Les données nécessaires pour un fine-tuning

Pour un entraînement supervisé, il faut montrer ce que le modèle devra produire dans les conditions réelles d’utilisation. Chaque exemple doit contenir une entrée représentative et une sortie corrigée selon une règle explicite. Accumuler des réponses historiques sans relecture peut apprendre les incohérences du service.

La couverture compte autant que le volume. Un ensemble composé uniquement de demandes faciles donnera peu d’informations sur les exceptions. Incluez les entrées incomplètes, les formulations inhabituelles, les catégories proches et les situations où la bonne réponse consiste à demander une précision.

Séparez les données d’entraînement, de validation et de test. Évitez que des variantes d’un même dossier apparaissent de part et d’autre : le modèle pourrait reconnaître un cas au lieu d’apprendre la tâche. Une séparation par client, document ou période peut être nécessaire selon l’usage.

Il n’existe pas de seuil universel d’exemples. Commencez par un lot contrôlé, augmentez sa diversité et tracez la performance sur le test indépendant. Si l’amélioration plafonne, examinez les annotations avant d’acheter davantage de calcul.

Les exemples synthétiques peuvent compléter les données, mais exigent une vérification. Un générateur peut multiplier la même erreur sous différentes formulations. Conservez la provenance des exemples et distinguez ceux validés par un spécialiste de ceux encore automatiques.

Écrivez enfin une consigne d’annotation utilisable par plusieurs personnes. Les désaccords sur la réponse attendue révèlent souvent un problème de définition que l’entraînement ne résoudra pas.

Fine-tuning complet, adaptateurs et exploitation

Le fine-tuning complet ajuste l’ensemble des paramètres entraînables retenus pour le modèle. Les méthodes à adaptateurs limitent les paramètres modifiés. La documentation technique de LoRA explique comment cette approche conserve les poids de base figés et apprend des matrices d’adaptation plus petites.

Cette réduction concerne les paramètres entraînables ; elle ne signifie pas que le modèle de base disparaît. L’entraînement et l’inférence doivent encore charger les éléments nécessaires, avec des besoins mémoire dépendant du modèle, du contexte et de la configuration.

Un adaptateur doit également rester compatible avec sa base. Archivez l’identifiant exact du modèle, les paramètres d’entraînement, les données utilisées et les résultats d’évaluation. Un fichier d’adaptation isolé ne suffit pas à reproduire une application.

Avec une API hébergée, vérifiez les modèles personnalisables, les formats acceptés et les conditions de déploiement au moment du projet. La disponibilité d’un modèle en inférence ne prouve pas qu’il accepte le fine-tuning.

Avec un déploiement que vous gérez, ajoutez la licence, la maintenance et la capacité de calcul à la décision. La possibilité technique d’entraîner ne règle pas les droits d’utilisation des données ni les contraintes d’exploitation.

Le modèle retenu doit surtout réussir la tâche après personnalisation. Une baisse de la perte d’entraînement indique que l’optimisation avance sur ses exemples ; elle ne démontre pas, seule, une amélioration sur de nouvelles demandes.

Calculer le coût complet, au-delà des tokens

Le RAG ajoute des postes de dépense : extraction, indexation initiale, mises à jour, stockage, recherche, éventuel reclassement et contexte envoyé au générateur. Le fine-tuning ajoute la préparation des exemples, les essais d’entraînement, leur évaluation et le déploiement du résultat.

Le travail humain appartient au budget. Nettoyer un corpus ou arbitrer des annotations contradictoires peut coûter davantage que les appels au modèle. Comptez aussi les nouvelles évaluations lorsqu’une procédure, une catégorie ou le modèle de base change.

Poste	RAG	Fine-tuning
Mise en place	Nettoyage documentaire et chaîne de recherche	Définition de la tâche et annotation
Calcul initial	Extraction et indexation	Entraînements et essais
Exploitation	Recherche, stockage et génération	Inférence et hébergement du modèle adapté
Maintenance	Synchronisation et retrait des sources	Nouveaux exemples et réentraînement
Contrôle qualité	Recherche, preuves et réponse	Généralisation et régressions

Les unités facturées dépendent du fournisseur. La documentation de personnalisation d’Amazon Bedrock décrit notamment une facturation d’entraînement fondée sur les tokens du corpus multipliés par les passages d’entraînement, ainsi qu’un stockage du modèle. Ces modalités ne constituent pas un tarif universel.

Comparez sur un même horizon :

Coût total = préparation + expérimentation + exploitation + maintenance + traitement des erreurs.

Le dernier poste comprend les reprises manuelles et les demandes relancées. Le calculateur de prix LLM aide à estimer la consommation ; il faut compléter ce montant avec vos coûts d’infrastructure et de personnel.

Un exemple chiffré et le seuil de rentabilité

Prenons un scénario hypothétique de calcul, sans mesure de performance : une application traite 10 000 demandes mensuelles. Chaque demande contient 1 000 tokens d’instructions et de question, reçoit 4 000 tokens documentaires et produit 500 tokens.

Pour isoler le coût de génération, utilisons les tarifs de GPT-6.1 Sol : 2 dollars par million de tokens en entrée et 10 dollars en sortie, relevé du site, octobre 2026. Cet exemple ne suppose aucune disponibilité de fine-tuning pour ce modèle.

Dans ces hypothèses, sans cache, remise ni appels supplémentaires :

Entrée mensuelle : 50 millions de tokens, soit 100 dollars.
Sortie mensuelle : 5 millions de tokens, soit 50 dollars.
Génération totale : 150 dollars, dont 80 dollars liés aux passages documentaires.

Ce montant exclut la recherche, l’indexation, l’hébergement et la maintenance. Il illustre pourquoi il faut mesurer la longueur des passages utiles plutôt que transmettre systématiquement davantage de documents.

Un modèle personnalisé pourrait réduire certains exemples ou instructions répétés. Il ne permet pas de retirer les documents nécessaires aux faits récents sans changer la fiabilité attendue.

Le seuil de rentabilité se calcule ainsi : surcoût fixe de personnalisation divisé par économie nette par demande réussie. Cette économie doit inclure les corrections, les relances et l’hébergement. Si elle est nulle ou négative, l’entraînement ne s’amortit pas par le volume ; il doit alors se justifier par une amélioration mesurée de la qualité.

Exemples de choix et architecture combinée

Les situations suivantes sont des exemples de conception hypothétiques, pas des cas clients ni des résultats observés.

Assistant de support documentaire. Il doit expliquer les conditions applicables à un produit donné. Un RAG peut sélectionner la documentation correspondant au produit et à sa période de validité. Le test décisif porte sur la bonne procédure, ses exceptions et la justification de la réponse.

Classement de demandes entrantes. Il faut attribuer une catégorie stable à chaque message selon une nomenclature interne. Après un essai avec instructions et exemples, un fine-tuning peut être évalué sur les confusions récurrentes. Si les catégories changent souvent, le coût de leur réannotation devient déterminant.

Rédaction selon une convention métier. Le système doit consulter les procédures actuelles puis produire une réponse suivant une organisation précise. Le RAG apporte les faits ; un entraînement peut améliorer la manière de les exploiter. Les exemples doivent alors contenir le contexte documentaire réellement disponible.

La publication RAFT : Adapting Language Model to Domain Specific RAG étudie une telle combinaison, avec un entraînement comprenant des documents pertinents et des distracteurs. Elle fournit une piste de conception, sans garantir un gain sur votre corpus.

Avant d’adopter cette architecture, comparez-la au RAG seul. Elle ajoute des composants et des données à maintenir. Pour comprendre un besoin voisin, l’article sur la mémoire des agents IA distingue la conservation d’informations d’une session à l’autre de l’entraînement du modèle.

Évaluer séparément la recherche et la réponse

Une moyenne globale peut masquer le composant défaillant. Pour le RAG, mesurez d’abord si les preuves attendues sont récupérées. Évaluez ensuite si la réponse respecte ces preuves, couvre la demande et reconnaît les informations manquantes.

La documentation des évaluateurs RAG de Microsoft distingue notamment qualité de récupération, ancrage dans le contexte, pertinence et complétude. Ces dimensions évitent de confondre une réponse fidèle mais incomplète avec une réponse détaillée contenant des affirmations non étayées.

Pour le fine-tuning, mesurez la tâche attendue : classification correcte, champs exacts, respect des exceptions ou qualité rédactionnelle selon une grille. Vérifiez aussi les comportements que vous ne souhaitiez pas modifier.

Comparez sur le même jeu indépendant le modèle de départ, le RAG seul, le modèle personnalisé et, si nécessaire, leur combinaison. Gardez les conditions comparables et consignez les changements de configuration.

Incluez des documents contradictoires, des entrées mal formées et des demandes hors périmètre. Une bonne évaluation teste aussi l’abstention : répondre systématiquement n’est pas un objectif de qualité.

Enfin, mesurez la latence et le coût par demande résolue selon vos critères. Un système moins cher par appel peut coûter davantage s’il oblige à recommencer. Le guide pour évaluer un agent IA détaille la construction d’un jeu de tests et le suivi des régressions.

Confidentialité, maintenance et décision finale

Dans un RAG, appliquez les autorisations avant de transmettre les passages au modèle. Un filtre d’interface ne suffit pas si la recherche peut récupérer des documents d’un autre utilisateur. Les index, caches et journaux font également partie du périmètre à protéger.

Les textes récupérés restent des données, même lorsqu’ils contiennent des consignes. Délimitez leur rôle et empêchez qu’une instruction trouvée dans un document modifie les permissions de l’application. Un entraînement ne doit pas être considéré comme une protection suffisante contre ce détournement.

Pour le fine-tuning, examinez les données susceptibles d’être mémorisées, les personnes pouvant interroger le modèle et la procédure de remplacement. Évitez d’entraîner sur des secrets ou sur des informations dont l’accès varie selon l’utilisateur.

Prévoyez un retour à la configuration précédente pour chaque modification. Versionnez le corpus, l’index, les instructions et le modèle adapté afin de pouvoir expliquer une régression. Une amélioration apparente devient difficile à vérifier si plusieurs composants changent simultanément.

À retenir

Commencez par diagnostiquer les erreurs sur une solution simple et un test indépendant.
Choisissez le RAG pour consulter des informations actualisables et vérifiables.
Évaluez le fine-tuning pour un comportement spécialisé démontré par des exemples cohérents.
Combinez les approches seulement si le gain mesuré justifie leur maintenance.
Budgétez la préparation, l’exploitation et les erreurs, puis comparez le coût par demande réussie.

Pages liées

Questions fréquentes

Peut-on faire du RAG sans base vectorielle ?

Oui. Une recherche par mots-clés, une requête dans une base relationnelle ou une combinaison de méthodes peut sélectionner les informations transmises au modèle. La base vectorielle est un moyen de recherche, pas une condition de définition du RAG.

Combien d'exemples faut-il pour un fine-tuning ?

Il n'existe pas de quantité universelle garantissant un résultat. Le volume utile dépend de la diversité des entrées, de la difficulté de la tâche et du modèle choisi. Construisez des lots progressifs et vérifiez si les performances sur des cas indépendants continuent de progresser.

Le fine-tuning supprime-t-il les hallucinations ?

Non. Il peut améliorer un comportement ciblé, mais aussi reproduire les erreurs et les biais des exemples d'entraînement. Une réponse mieux présentée peut rester factuellement incorrecte.

Peut-on supprimer une information apprise par fine-tuning ?

Retirer cette information du fichier d'entraînement ne modifie pas le modèle déjà produit. Il faut prévoir une procédure de remplacement ou de réentraînement et vérifier son résultat. Ne traitez pas les poids du modèle comme une base documentaire dans laquelle chaque donnée serait effaçable séparément.

Faut-il choisir un modèle à poids ouverts pour le fine-tuning ?

Pas nécessairement : certaines API proposent une personnalisation hébergée pour des modèles compatibles. Des poids accessibles donnent davantage de contrôle sur l'entraînement et le déploiement, sous réserve de la licence. Comparez aussi la maintenance, la capacité de calcul et les possibilités de migration.

Fine-tuning ou RAG : comment choisir, coûts, données nécessaires, exemples