RAG ou ajustement fin ? Ce que de vrais projets clients nous ont appris pour faire le bon choix

Presque toutes les discussions que j’ai avec des entreprises au sujet de l’IA aboutissent au même dilemme dès la première heure. Le client dispose d’un grand modèle de langage qui fait forte impression en démonstration, mais qui ne connaît ni ses produits, ni ses politiques, ni sa façon de rédiger. Quelqu’un dans la salle demande alors : faut-il ajuster le modèle sur nos données ou construire autour de lui un système de génération augmentée par récupération (RAG) ?

La réponse honnête, c’est que la question est généralement mal posée. Le RAG et l’ajustement fin répondent à des problèmes différents. Les équipes qui les considèrent comme des solutions concurrentes ont tendance à passer des mois et à engloutir une grande partie de leur budget GPU à résoudre le mauvais problème. Voici comment nous tranchons en pratique et ce que nous avons vu réussir ou échouer.

Commencez par déterminer ce qui manque au modèle

Lorsqu’un modèle fournit une mauvaise réponse à une tâche métier, il lui manque l’une de ces deux choses.

Il lui manque des connaissances. Il ne connaît pas votre dernière liste de prix, la clause de votre contrat fournisseur de 2025 ni les étapes de dépannage d’un produit lancé le mois dernier. C’est un problème de faits.

Il lui manque les bons comportements. Il en sait assez, mais ne répond pas comme vous le souhaitez. Il ne respecte pas votre format de sortie, adopte un ton inadapté, interprète mal vos codes internes ou n’arrive pas à exécuter une tâche précise et répétitive, comme classer des tickets dans vos 40 catégories. C’est un problème de compétences.

Le RAG est l’outil adapté au premier problème. L’ajustement fin répond au second. La plupart des confusions que je constate viennent des tentatives d’utiliser l’ajustement fin pour enseigner des faits.

Pourquoi l’ajustement fin est une mauvaise façon d’ajouter des connaissances

On pourrait croire qu’en entraînant un modèle sur vos documents, il va les « connaître ». En pratique, il apprend leur style bien plus sûrement que les faits qu’ils contiennent. Des chercheurs de Microsoft ont comparé directement les deux approches pour répondre à des questions nécessitant beaucoup de connaissances et ont constaté que le RAG donnait systématiquement de meilleurs résultats que l’ajustement fin non supervisé, aussi bien pour les faits que le modèle avait vus pendant l’entraînement que pour des faits entièrement nouveaux.

Il y a aussi des difficultés pratiques. Les faits changent. Chaque fois que votre politique ou votre catalogue évolue, le modèle ajusté devient obsolète jusqu’à ce que vous le réentraîniez. Vous perdez également la traçabilité : lorsqu’un modèle ajusté avance un chiffre, vous ne pouvez pas indiquer le document dont il provient. Pour les clients soumis à une réglementation dans les secteurs de l’assurance et de la santé, cela suffit généralement à clore la discussion.

Le RAG, décrit pour la première fois dans l’article de 2020 de Lewis et al., conserve les connaissances à l’extérieur du modèle. Au moment de la question, vous récupérez les passages pertinents et les fournissez au modèle comme contexte. Pour mettre à jour les connaissances, il suffit de mettre à jour un index, sans réentraînement. Chaque réponse peut en outre citer sa source.

L’un de nos clients du secteur de la logistique en est un bon exemple. Ses clients voulaient obtenir instantanément des réponses sur la localisation de leurs expéditions et les documents manquants. Ces informations changent toutes les quelques minutes. Aucun entraînement n’aurait permis de garder un modèle à jour ; l’assistant que nous avons conçu répond donc aux questions à partir des données de suivi en temps réel et des données de l’IdO, plutôt que de s’en remettre à sa mémoire. La récupération était la seule architecture viable.

Quand l’ajustement fin trouve sa place

L’ajustement fin n’a pas disparu. Son champ d’application est simplement plus restreint que ce que beaucoup imaginent. Nous y recourons dans trois situations :

• Des formats de sortie stricts et répétitifs. Lorsqu’un modèle doit produire des milliers de fois par jour le même résultat structuré, par exemple extraire des champs de factures dans un schéma JSON fixe, un petit modèle ajusté est souvent plus fiable et bien moins coûteux qu’un grand modèle auquel on donne des instructions.
• Le vocabulaire d’un domaine. Dans certains secteurs, le modèle de base interprète mal certaines abréviations. Les codes de statut logistique, les abréviations cliniques et les codes de produits internes en sont des exemples courants. Un ajustement fin limité peut résoudre ce problème.
• Les coûts et la latence à grande échelle. Une fois une tâche bien définie, un petit modèle ajusté peut remplacer un grand modèle généraliste. Des méthodes comme LoRA rendent cette approche abordable, car elles consistent à entraîner un petit ensemble de poids supplémentaires plutôt que le modèle entier.

Remarquez qu’aucun de ces cas ne concerne des faits. Il s’agit d’apprendre à un modèle comment se comporter pour une tâche que vous maîtrisez déjà bien.

La plupart des échecs du RAG sont des échecs de récupération

Quand une équipe me dit : « Nous avons essayé le RAG, mais ça n’a pas marché », le problème vient rarement du modèle. Il se situe au niveau de la récupération. La qualité du modèle ne peut pas dépasser celle des passages qui lui sont fournis.

Les solutions sont peu spectaculaires, mais efficaces :

• Découpez selon le sens, pas selon le nombre de caractères. Découper un contrat tous les 500 caractères coupe les clauses en deux. Le découper par section et par titre permet de préserver le contexte.
• Ajoutez du contexte à chaque segment. Un segment qui indique « la limite est de 30 jours » est inutile si l’on ne sait pas à quelle politique il se rapporte. Anthropic a indiqué que l’ajout d’un bref contexte documentaire à chaque segment avant l’indexation — une approche qu’il appelle récupération contextuelle — réduisait les échecs de récupération de 49 %, et de 67 % lorsqu’il était associé à un reclassement.
• Combinez la recherche par mots-clés et la recherche vectorielle. La recherche vectorielle est efficace pour saisir le sens, mais moins performante avec les termes exacts, comme les numéros de pièces. La recherche hybride couvre les deux.
• Testez séparément la récupération des informations. Constituez un ensemble de questions réelles dont les passages sources corrects sont connus, puis mesurez si le bon passage figure parmi les premiers résultats avant d’évaluer les réponses finales.

Quand utiliser les deux

En production, les systèmes les plus performants combinent souvent les deux. Le RAG fournit les faits. Un modèle légèrement affiné prend en charge le format, le ton et le langage propre au domaine. La recherche évolue dans le même sens : l’approche RAFT de l’UC Berkeley affine un modèle spécifiquement pour qu’il exploite mieux les documents récupérés et ignore ceux qui ne sont pas pertinents.

Mais l’ordre compte. Nous commençons presque toujours par mettre en place le RAG, nous mesurons ses lacunes, puis nous décidons si l’affinage en vaut la peine. Commencer par l’affinage revient à payer pour l’entraînement avant de connaître la véritable lacune.

Une simple liste de critères pour décider

1. La tâche repose-t-elle sur des faits qui changent plus d’une fois par trimestre ? Utilisez le RAG.
2. Les utilisateurs ou les auditeurs doivent-ils pouvoir savoir d’où provient une réponse ? Utilisez le RAG.
3. Le problème concerne-t-il le format, le ton ou le vocabulaire des réponses, et non les faits qu’elles contiennent ? Envisagez l’affinage.
4. S’agit-il d’une tâche ciblée, exécutée à grande échelle, pour laquelle le coût ou la vitesse compte ? Envisagez d’affiner un modèle plus petit.
5. Avez-vous mesuré séparément la qualité de la récupération ? Sinon, faites-le avant toute autre chose.

À retenir

Le RAG et l’affinage ne sont pas des solutions concurrentes. L’un fournit au modèle les bonnes informations, l’autre façonne son comportement. Déterminez clairement le problème auquel vous êtes réellement confronté, améliorez la récupération avant d’en rendre le modèle responsable et considérez l’affinage comme une optimisation que vous ne méritez qu’une fois le système opérationnel, et non comme un raccourci pour le faire fonctionner.