RAG vs fine-tuning : le vrai besoin des entreprises

Presque tous les projets IA dont nous discutons avec nos clients commencent par la même question : « Faut-il fine-tuner un modèle sur nos données ? » Parfois, la réponse est oui. Plus souvent, le vrai besoin est ailleurs : un assistant qui connaît vos documents à jour, cite ses sources et peut être mis à jour un mardi après-midi sans lancer d’entraînement. Cet article explique les principales options en langage clair, dans quels cas chacune convient, et comment décider sans perdre des mois sur la mauvaise approche.

Les quatre outils de la boîte#

Quand on dit « apprendre notre métier au modèle », on parle en général de l’une de quatre techniques différentes. Elles résolvent des problèmes différents et peuvent se combiner.

La génération augmentée par récupération (RAG)#

Le RAG (retrieval-augmented generation) ne modifie pas le modèle. À la place, lorsqu’une question arrive, le système cherche d’abord dans vos propres contenus – manuels, contrats, tickets ou catalogue produits – et transmet au modèle les passages les plus pertinents avec la question. Le modèle répond alors en s’appuyant sur ces passages.

Trois notions comptent ici :

• La récupération (retrieval) : trouver les bons passages. Il s’agit en général d’un mélange de recherche sémantique sur des embeddings et de recherche classique par mots-clés, souvent suivi d’une étape de reranking.
• L’ancrage (grounding) : demander au modèle de répondre à partir du matériel fourni, et de le dire lorsque ce matériel ne contient pas la réponse.
• Les citations : indiquer le document, la page ou le passage précis d’où provient une réponse, pour qu’un humain puisse la vérifier.

Le RAG excelle lorsque les connaissances changent souvent, lorsque le corpus est volumineux et lorsque les réponses doivent pouvoir être vérifiées.

Le fine-tuning#

Le fine-tuning poursuit l’entraînement d’un modèle sur vos propres exemples, de façon à infléchir son comportement. Il est efficace pour enseigner comment répondre : un ton constant, un format de sortie strict, une grille de classification propre à un domaine ou une tâche étroite exécutée des milliers de fois par jour. C’est un mauvais moyen d’enseigner ce qui est vrai à l’instant présent. Les faits appris par fine-tuning sont difficiles à mettre à jour, difficiles à relier à une source, et peuvent être mélangés ou mal restitués.

Le fine-tuning permet aussi de confier une tâche étroite à un modèle plus petit, moins cher et plus rapide, ce qui peut compter beaucoup à fort volume.

Le contexte long avec prompt caching#

Les modèles récents d’Anthropic, d’OpenAI et de plusieurs familles open source acceptent des entrées très longues. Si votre base de connaissances est de taille modeste, par exemple un manuel produit, un ensemble de politiques internes ou une FAQ, vous pouvez souvent la placer tout entière directement dans le prompt. Pas d’index, pas de pipeline de récupération, pas de décisions de découpage.

L’objection évidente concerne le coût et la latence : envoyer le même gros document à chaque requête est du gaspillage. Le prompt caching y répond. Les fournisseurs peuvent mettre en cache un préfixe stable du prompt : les requêtes répétées réutilisent le contenu déjà traité et sont facturées et servies plus efficacement. Pour un corpus de connaissances stable et délimité, le contexte long avec cache est fréquemment la solution la plus simple qui fonctionne.

Les sorties structurées#

Beaucoup de projets « IA » sont en réalité des projets d’extraction : lire une facture, un CV, un contrat ou un e-mail, et produire des champs propres. Ici, la capacité clé, ce sont les sorties structurées (structured outputs) : le modèle est contraint de renvoyer des données conformes à un schéma que vous définissez, par exemple du JSON avec des champs et des types précis. Il n’est pas du tout question de connaissances. Il s’agit de fiabilité du format, et cela dispense le plus souvent de fine-tuning pour les tâches d’extraction.

Quelle approche pour quel besoin#

Une façon utile d’y réfléchir : séparer les connaissances du comportement.

• Des connaissances récentes ou changeantes, et des réponses que l’on doit pouvoir vérifier : utilisez le RAG, ou le contexte long si le matériel est assez réduit. Tous deux permettent de mettre à jour les connaissances en mettant à jour les documents, et tous deux prennent en charge les citations.
• Des connaissances stables et délimitées, qui tiennent dans la fenêtre de contexte : commencez par le contexte long et le prompt caching. Passez au RAG quand le matériel devient trop volumineux ou quand vous avez besoin d’un contrôle d’accès fin, document par document.
• Un style, un ton ou un format constants sur de nombreuses sorties : essayez d’abord des consignes claires et quelques bons exemples dans le prompt. Si cela ne suffit pas à votre volume, le fine-tuning est une option légitime.
• De la classification ou du routage étroits à grande échelle : fine-tuner un modèle plus petit, ou simplement utiliser un modèle généraliste plus petit avec un prompt bien conçu, est souvent la voie la plus économique.
• L’extraction de champs à partir de documents : les sorties structurées, éventuellement combinées à des documents en entrée et à des citations, pour que chaque valeur extraite soit traçable.

Ces approches ne s’excluent pas. Un système mûr peut utiliser le RAG pour les connaissances, les sorties structurées pour le format de réponse et un petit modèle fine-tuné pour router les demandes entrantes.

Comparaison point par point#

Une checklist de décision pratique#

Avant de choisir une architecture, répondez honnêtement à ces questions :

1. Quelle est la tâche, exactement ? Répondre à des questions, rédiger du texte, classer ou extraire ? Notez cinq exemples réels d’entrée et de sortie idéale.
2. À quelle fréquence les connaissances sous-jacentes changent-elles ? Des changements quotidiens ou hebdomadaires plaident nettement contre le fine-tuning.
3. Les utilisateurs doivent-ils vérifier les réponses ? Dans les contextes juridiques, financiers, de conformité, de support ou de santé, les citations sont en général non négociables.
4. Quelle est la taille de la base de connaissances ? Si elle tient confortablement dans une fenêtre de contexte, essayez d’abord le contexte long avec cache.
5. Qui a le droit de voir quoi ? Si différents utilisateurs ont accès à différents documents, il vous faut une récupération avec filtrage par permissions, et non un prompt unique partagé ou un modèle entraîné sur tout.
6. Quels volume et latence attendez-vous ? Un fort volume sur une tâche étroite, c’est là que les modèles plus petits ou fine-tunés prennent tout leur intérêt.
7. Disposez-vous d’exemples annotés ? Sans un ensemble conséquent de bons exemples, le fine-tuning fait rarement mieux qu’un prompt bien écrit.
8. Comment mesurerez-vous la réussite ? Si vous ne savez pas répondre, arrêtez-vous et construisez d’abord un jeu d’évaluation.

Si la plupart des réponses pointent vers « connaissances changeantes, citations nécessaires, volume modéré », il vous faut du RAG ou du contexte long. Si elles pointent vers « tâche stable, format strict, très fort volume », envisagez le fine-tuning ou un modèle plus petit.

Les pièges courants#

Voici les problèmes que nous rencontrons le plus souvent lorsque nous examinons des systèmes d’IA qui « marchent presque ».

• Un mauvais découpage (chunking). Découper les documents en morceaux arbitraires de taille fixe coupe les tableaux en deux, sépare les titres de leur contenu et fait perdre le contexte. Découpez en suivant la structure du document et conservez les métadonnées utiles, comme le titre, la section et la date.
• Pas d’évaluations. Sans jeu de test, chaque changement est un pari. Les équipes retouchent les prompts, changent de modèle et modifient la taille des segments sans savoir si les choses s’améliorent ou se dégradent.
• Des index périmés. Les documents sources ont été mis à jour, l’index non. L’assistant cite avec aplomb la politique de l’an dernier. La réindexation doit faire partie du workflow de contenu, et non être une tâche manuelle à laquelle on pense après coup.
• Des hallucinations sans citations. Si le système ne montre pas d’où vient une réponse, les utilisateurs ne peuvent pas distinguer une réponse ancrée dans les sources d’une réponse inventée. Exigez des citations et apprenez au modèle à dire « je ne sais pas » quand les sources sont muettes.
• Confidentialité et RGPD. Des données personnelles dans des documents, des prompts et des logs restent des données personnelles. Sachez quel fournisseur les traite, dans quelle région, dans le cadre de quel accord de traitement des données, et combien de temps les logs sont conservés. Le fine-tuning sur des données personnelles appelle une prudence particulière, car il est difficile de les retirer ensuite.
• L’injection de prompt via les documents. Le contenu récupéré est une entrée non fiable. Un document peut contenir du texte qui tente de donner des instructions au modèle, par exemple d’ignorer ses règles ou de révéler d’autres données. Traitez le texte récupéré comme des données, limitez ce que le modèle peut faire avec des outils, et ne laissez jamais le contenu d’un document accorder des permissions.

Évaluer avant d’optimiser#

L’étape la plus précieuse de tout projet IA est aussi la moins prestigieuse : construire un jeu d’évaluation avant de choisir une architecture.

Un bon jeu de départ, c’est simplement de quelques dizaines à quelques centaines de questions ou d’entrées réelles, chacune accompagnée de la réponse attendue ou des documents qui devraient être cités. Mesurez ensuite :

• La qualité de la récupération : le système a-t-il trouvé les bons passages ?
• La qualité des réponses : la réponse est-elle correcte, complète et ancrée dans les sources ?
• L’exactitude des citations : les passages cités étayent-ils réellement l’affirmation ?
• Le comportement de refus : le système dit-il « je ne sais pas » quand il le faut ?
• La conformité du format : pour l’extraction, chaque sortie respecte-t-elle le schéma ?

Une fois cela en place, les comparaisons deviennent factuelles. Vous pouvez tester le contexte long contre le RAG, un modèle contre un autre, ou un modèle fine-tuné contre un modèle simplement guidé par prompt, sur vos propres données plutôt que sur des benchmarks génériques. Vous constaterez souvent que la correction la moins chère est une meilleure récupération ou un prompt plus clair, et non un modèle plus gros ou un entraînement.

La notation automatisée par un modèle peut accélérer le travail, mais contrôlez-la par sondage avec des relecteurs humains, surtout au début.

Comment nos propres démos illustrent ces approches#

Nous essayons d’appliquer ce que nous recommandons, et deux démos de ce site montrent ces approches à l’œuvre.

Le sigmacode Assistant répond aux questions sur nos services et notre approche. Sa base de connaissances est réduite et volontairement figée : au lieu d’un pipeline de récupération, il utilise donc le contexte long avec prompt caching. Toute la base de connaissances se trouve dans un préfixe de prompt mis en cache, et le modèle a pour consigne de ne répondre qu’à partir de celle-ci. Pour un corpus de connaissances délimité, c’est plus simple à construire et plus facile à maintenir exact qu’un index vectoriel.

La démo Questions sur documents, avec citations montre l’autre versant. Vous fournissez un document, vous posez des questions, et chaque réponse s’accompagne de citations qui renvoient aux passages sur lesquels elle s’appuie. C’est la promesse centrale d’une IA ancrée dans les sources : chaque affirmation peut être vérifiée à la source.

Aucune de ces démos n’a nécessité de fine-tuning. C’est typique. Pour la plupart des problèmes de connaissances en entreprise, l’ancrage et une bonne évaluation comptent davantage qu’un entraînement sur mesure.

En bref#

• Utilisez le RAG quand les connaissances sont volumineuses, changent souvent, exigent un contrôle d’accès ou doivent être citées.
• Utilisez le contexte long avec prompt caching quand les connaissances sont stables et tiennent dans la fenêtre.
• Utilisez le fine-tuning ou des modèles plus petits pour un comportement constant ou des tâches étroites à fort volume, pas pour des faits.
• Utilisez les sorties structurées pour l’extraction et pour toute sortie qu’un système doit analyser.
• Évaluez d’abord, puis optimisez ce que les chiffres vous indiquent.

Si vous pesez ces options pour un projet réel, notre équipe IA & automatisation, dirigée par un tech lead avec plus de 20 ans d’expérience, peut vous aider à le cadrer, à construire un jeu d’évaluation et à livrer une première version que vous pourrez réellement mesurer. Contactez-nous et dites-nous ce que vous cherchez à résoudre.