RAG vs. Fine-Tuning : un cadre de décision pour les fondateurs

Optez pour le RAG (retrieval-augmented generation) lorsque vos données sous-jacentes évoluent fréquemment ou que vous devez montrer aux utilisateurs la provenance d'une réponse. Optez pour le fine-tuning lorsque le problème vient du comportement du modèle lui-même — ton, format de sortie, ou une tâche précise qu'il continue de gérer structurellement de travers. La plupart des équipes que nous rencontrons se tournent d'abord vers le fine-tuning parce que ça semble plus « sur-mesure », pour découvrir ensuite que le RAG aurait résolu 80 % du problème pour une fraction du coût et de la complexité.

Ce que chacune fait réellement

Ces deux approches résolvent des problèmes différents, et les confondre, c'est là où la plupart des fondateurs perdent des semaines.

• Le RAG récupère des documents pertinents au moment de la requête et les injecte dans le prompt comme contexte. Les poids du modèle ne changent jamais. Vous étendez ce que le modèle sait, pas la façon dont il se comporte.
• Le fine-tuning ajuste les poids du modèle sur un jeu d'exemples d'entraînement. Vous modifiez la façon dont le modèle répond — son format, son ton, ou son schéma de raisonnement propre à une tâche — sans lui apporter de nouvelles connaissances.

L'article fondateur de Lewis et al. (2020) le formulait exactement ainsi : associer un modèle paramétrique à une mémoire non paramétrique que l'on peut mettre à jour indépendamment. C'est toujours le cœur du compromis aujourd'hui — voulez-vous que les connaissances résident dans les poids, ou dans un store que vous pouvez modifier sans ré-entraîner ?

Quand le RAG s'impose

Choisissez le RAG si l'un de ces critères est vrai :

• Vos données changent chaque semaine ou chaque jour. Grilles tarifaires, stocks, documents de politique interne, tickets de support. Fine-tuner sur une cible mouvante implique un ré-entraînement constant.
• Vous avez besoin de citations. Les cas d'usage dans la santé, le droit et la finance exigent généralement de montrer la source. Le RAG vous fournit une piste d'audit ; le fine-tuning incorpore les faits dans une matrice de poids opaque que vous ne pouvez pas auditer.
• Vous n'avez pas encore atteint le product-market fit. Le RAG vous permet de changer le modèle sous-jacent ou d'ajuster la logique de récupération sans toucher à un artefact entraîné. Nous couvrons les mécanismes dans notre introduction au RAG et la couche de stockage dans notre explication des bases de données vectorielles.
• Le budget est serré. Pas de run d'entraînement, pas de location de GPU, pas de pipeline MLOps à maintenir. Vous payez par requête, et non par cycle de mise à jour.

Quand le fine-tuning s'impose

Le fine-tuning justifie son coût lorsque le problème n'est pas un manque de connaissances, mais un comportement incorrect :

• Le modèle continue d'ignorer votre format de sortie. Vous avez besoin d'un JSON strict, d'un ton particulier, ou d'un style de raisonnement propre à votre domaine (par exemple, un workflow de triage) que le prompting seul ne tient pas de façon cohérente à grande échelle.
• Vous disposez de milliers d'exemples étiquetés de comportements corrects et le schéma est stable — pas de « nouvelles connaissances », mais « effectuer cette tâche exactement de cette façon ».
• La latence et la taille des prompts sont de véritables contraintes. Chaque requête RAG implique un coût de récupération et un prompt plus long. Si vous effectuez des millions d'appels par jour, un modèle fine-tuné avec un prompt court peut être significativement moins cher et plus rapide qu'un long contexte RAG, une fois le coût d'entraînement amorti. Consultez notre analyse des coûts pour voir comment ces chiffres se comparent réellement dans le temps.
• Le vocabulaire ou le schéma de raisonnement de votre domaine est suffisamment atypique pour qu'une bonne récupération et un bon prompting ne suffisent pas à orienter de manière fiable un modèle généraliste (par exemple, une tâche de codage clinique très spécialisée).

La documentation sur le fine-tuning d'OpenAI est une référence utile pour comprendre ce à quoi le fine-tuning est réellement adapté : la conformité au format, le ton et la cohérence sur des tâches précises — pas l'injection de nouveaux faits.

Le cas hybride

En pratique, les systèmes de production les plus performants utilisent les deux approches — mais pas dès le premier jour :

1. Lancez avec le RAG et le prompting. L'itération est rapide et les modifications peu coûteuses.
2. Instrumentez tout — journalisez chaque requête, chaque récupération et chaque sortie.
3. Une fois que vous avez identifié de vrais schémas d'échec (et non des hypothèses), faites du fine-tuning de façon ciblée sur le comportement précis qui pose problème.

Construire un pipeline de fine-tuning avant d'avoir des logs de production, c'est concevoir dans le noir. Vous supposez à quoi ressemble « le bon résultat » au lieu d'entraîner sur vos vrais modes d'échec.

Ce que nous avons observé en pratique

Nous exploitons notre propre outil de prospection qui analyse le site d'un prospect et rédige un e-mail de démarchage personnalisé. Notre premier réflexe a été l'architecture « propre » : une chaîne d'agents qui extrait les faits, raisonne sur leur pertinence, rédige, puis critique son propre brouillon. C'était plus lent, plus coûteux, et produisait de moins bons e-mails qu'un unique appel LLM bien structuré auquel on fournit la page extraite comme contexte — essentiellement un schéma RAG avec un seul document plutôt qu'un corpus. Nous n'aurions eu recours au fine-tuning que si cette approche en un seul appel avait échoué à maintenir une voix cohérente sur des centaines d'e-mails — ce qui ne s'est pas produit. La leçon est généralisable : ne saisissez pas l'outil le plus lourd avant d'avoir prouvé que le plus léger est insuffisant. Le même réflexe qui pousse à sur-construire une chaîne d'agents multi-étapes là où un seul appel suffirait est celui qui pousse à sur-construire un pipeline de fine-tuning là où la récupération ferait l'affaire.

La checklist du fondateur

Avant d'engager un budget, répondez à ces questions :

• À quelle fréquence les données sous-jacentes changent-elles ? Quotidiennement/hebdomadairement → RAG. Rarement/jamais → le fine-tuning est envisageable.
• Avez-vous besoin de montrer les sources ? Oui → RAG, ou au minimum RAG combiné au fine-tuning, jamais le fine-tuning seul.
• Le mode d'échec est-il « mauvaises informations » ou « mauvais format/comportement » ? Mauvaises informations → RAG. Mauvais comportement → fine-tuning.
• Disposez-vous déjà d'exemples étiquetés de comportements corrects ? Non → vous n'êtes pas prêt à faire du fine-tuning, quel que soit le cas d'usage.
• Quel est votre volume de requêtes ? Faible à moyen → le coût par requête du RAG est acceptable. Élevé et sensible à la latence → le coût amorti du fine-tuning commence à l'emporter.

Si vous intégrez l'une ou l'autre approche dans un produit existant plutôt qu'en partant de zéro, notre guide pour intégrer l'IA dans votre produit passe en revue les décisions d'architecture environnantes — authentification, rate limiting et comportement de fallback — qui comptent autant que le choix du modèle lui-même.

Aucune des deux approches n'est plus « avancée » que l'autre — elles résolvent des problèmes différents, et le chemin le plus rapide vers un produit fonctionnel est généralement l'option la moins coûteuse que vous pouvez valider en premier. Si vous souhaitez un second avis sur celle qui correspond à votre produit, parlons-en.