RAG ou affinage : quand utiliser l’un ou l’autre

Lorsque vous avez besoin qu’un LLM fonctionne bien dans votre domaine spécifique, deux stratégies principales s’offrent à vous : la génération augmentée par récupération (RAG) injecte dynamiquement les connaissances pertinentes au moment de l’inférence, tandis que l’ajustement fin met à jour les poids du modèle pour y intégrer des connaissances, un style ou des préférences de format. Faire le bon choix peut faire la différence entre un système fiable et des mois de calcul GPU coûteux gaspillés avec une mauvaise approche.

L’ajustement fin met à jour les poids du modèle en l’entraînant sur des paires d’entrées et de sorties d’exemple. Il excelle pour modifier le comportement : apprendre à un modèle à toujours répondre dans un format JSON précis, à adopter la voix d’une marque, à suivre des schémas de raisonnement propres à un domaine ou à effectuer un type de tâche pour lequel il n’a pas été optimisé. L’ajustement fin ne met pas à jour de manière fiable les connaissances factuelles : les modèles peuvent mémoriser excessivement les exemples d’entraînement sans généraliser les faits sous-jacents à de nouvelles requêtes.

RAG ne modifie pas les poids du modèle. Il modifie plutôt les informations accessibles au modèle au moment de l’inférence en plaçant les documents pertinents dans la fenêtre de contexte. RAG excelle pour les connaissances : répondre à des questions sur des documents privés, maintenir les réponses à jour grâce à des données fréquemment actualisées et ancrer les réponses dans des sources vérifiables. Ce que RAG ne modifie pas facilement, c’est le style intrinsèque du modèle, ses préférences de format ou son approche du raisonnement.

Pour tout cas d’utilisation où les informations évoluent au fil du temps, RAG est clairement supérieur. Réindexer une base vectorielle lorsque les documents sont mis à jour prend quelques minutes et ne nécessite aucune ressource GPU. Ajuster un modèle sur de nouvelles données exige un nouvel entraînement (coûteux et lent) et, même dans ce cas, le modèle peut ne pas se rappeler de manière fiable les nouveaux faits. Les catalogues de produits, les réglementations juridiques, les recommandations médicales et les politiques d’entreprise sont tous mieux pris en charge par RAG que par l’ajustement fin.

Si vous avez besoin que le modèle réponde toujours dans un style, un ton ou un format structuré très précis que la conception d’invites seule ne permet pas d’imposer de manière fiable, l’ajustement fin est le bon outil. Exemples : un agent de service client qui doit toujours utiliser le vocabulaire propre à votre marque, un générateur de code qui doit produire du code conforme au guide de style interne de votre entreprise ou un modèle de classification qui doit produire de manière fiable une taxonomie rigide dans des milliers de cas particuliers.

L’ajustement fin entraîne un coût initial élevé (calcul nécessaire à l’entraînement, préparation du jeu de données, évaluation), mais il réduit le coût par requête si l’ajustement fin vous permet d’utiliser un modèle plus petit. RAG entraîne un coût initial faible (l’indexation d’une base de données vectorielle est peu coûteuse), mais ajoute une surcharge par requête : un appel à l’API d’encodage et des invites légèrement plus longues contenant le contexte injecté. Pour la plupart des applications traitant moins de 10 millions de requêtes quotidiennes, la surcharge par requête de RAG est négligeable comparée au coût de développement de l’ajustement fin.

Les modèles ajustés peuvent être plus rapides lors de l’inférence, car ils nécessitent des invites plus courtes : les connaissances se trouvent dans les poids, et non dans le contexte. RAG ajoute deux allers-retours : un appel à l’API d’encodage et une requête de recherche vectorielle. La surcharge totale est généralement de 50 à 200 ms. Pour les applications sensibles à la latence, comme les assistants vocaux en temps réel, cette surcharge est importante. Pour la plupart des applications conversationnelles et de questions-réponses, la latence supplémentaire est imperceptible pour les utilisateurs.

RAG fournit une piste d’audit claire : pour chaque réponse, vous savez exactement quels documents ont été récupérés et pouvez les montrer à l’utilisateur. Les modèles ajustés répondent à partir de poids opaques : aucun enregistrement n’indique quel exemple d’entraînement a produit une sortie donnée. Dans les secteurs réglementés comme la finance, la santé et le droit, où les réponses doivent être explicables et vérifiables, la transparence de RAG constitue un avantage important par rapport à l’ajustement fin.

RAG et l’ajustement fin ne s’excluent pas mutuellement. Un schéma courant en production consiste à ajuster finement un modèle pour obtenir un format de sortie et un vocabulaire propres au domaine cohérents, puis à ajouter RAG pour fournir les connaissances factuelles actuelles. Le modèle ajusté gère de manière fiable le style et la structure, tandis que RAG gère les connaissances. Cette combinaison surpasse chacune des deux approches utilisées seule dans les applications d’entreprise à forts enjeux.

Suivez ce parcours de décision : le problème concerne-t-il la cohérence du style ou du format ? → Envisagez l’ajustement fin. Les informations sont-elles privées ou fréquemment mises à jour ? → Utilisez RAG. Avez-vous besoin de citations des sources ? → Utilisez RAG. Le jeu de données est-il trop petit pour l’ajustement fin (moins de 500 exemples) ? → Utilisez RAG avec une invite à quelques exemples. Avez-vous besoin que le modèle effectue une tâche qu’il refuse actuellement d’effectuer ? → Effectuez un ajustement fin avec RLHF ou DPO. En cas d’incertitude, commencez par RAG : sa création est plus rapide, sa mise à jour plus facile et sa transparence supérieure.

Utilisez ces scénarios pour développer votre intuition : agent conversationnel RH interne (les politiques changent chaque trimestre, les sources doivent être citées) → RAG. Complétion de code pour un framework propriétaire (style de code cohérent, schémas propres au framework) → Ajustement fin. Questions-réponses sur des documents juridiques (documents privés, citation précise nécessaire) → RAG. Agent de support client (ton spécifique, FAQ produit mise à jour chaque semaine) → ajustement fin pour le ton + RAG pour les connaissances. Résumeur de publications médicales (recherches actuelles, attribution essentielle) → RAG.

Testez votre compréhension des concepts d’ingénierie de l’IA présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’ajustement fin modifie le comportement et le style du modèle, mais pas de manière fiable ses connaissances factuelles ; que RAG fournit dynamiquement les connaissances au moment de l’inférence, avec une transparence totale et la citation des sources ; ainsi que le cadre de décision à appliquer : utilisez RAG pour les connaissances privées fréquemment mises à jour qui nécessitent une attribution, l’ajustement fin pour un style et un format cohérents, et combinez les deux pour les applications d’entreprise à forts enjeux. Ensuite, nous commencerons à créer un pipeline RAG complet à partir de zéro.