RAG, ajustement fin ou agents : choisir la couche appropriée et l’ordre de sa mise en place

Deux questions se posent tôt ou tard dans presque tous les projets de LLM. La première concerne le choix entre récupérer des documents ou affiner le modèle. La seconde porte sur le fait de savoir si le produit a besoin d’un agent ou simplement d’un prompt plus intelligent. Ces deux questions sont étonnamment souvent mal résolues, et ce, non seulement par les débutants. Des ingénieurs expérimentés ont passé des semaines à affiner un modèle afin qu’il mémorise des faits que une requête de récupération aurait fournis en une après-midi. D’autres équipes ont enveloppé ce qui n’était en réalité qu’un point de terminaison de réponse à des questions dans un cadre d’agent, simplement parce que les agents étaient au centre de chaque réunion de suivi ce trimestre-là.

La réalité moins excitante est que le récupération de données, le réglage fin et les agents ne sont pas des concurrents pour la même tâche. Chacun résout un problème distinct, et les systèmes utilisés par des utilisateurs réels combinent généralement deux d’entre eux ou les trois, chaque composant faisant ce pour quoi il est conçu. Ce qui suit explique le fonctionnement interne de chacun, son coût, les manières dont les équipes les utilisent à tort, la manière dont les composants s’assemblent, ainsi qu’un petit projet montrant l’ordre de leur mise en place.

Ce que fait réellement chacun

Génération améliorée par le récupération de données

Le récupération de données n’affecte pas le modèle. Il ne modifie que ce que le modèle lit avant de répondre.

Lorsqu’une question arrive, le système la transforme en une représentation numérique de son sens, appelée embedding, puis cherche dans une base de données vectorielle telle que Pinecone, Qdrant, FAISS ou Azure AI Search les fragments stockés les plus proches en signification. Ces fragments sont intégrés dans le prompt en tant que contexte, et le modèle répond en s’appuyant sur ces éléments plutôt que sur ce qu’il a absorbé lors de son entraînement préalable.

La valeur réside dans les échecs qu’il permet d’éviter. Les modèles inventent facilement des détails lorsqu’ils sont contraints de répondre à partir de leur mémoire interne, surtout pour des sujets récents, obscurs ou spécifiques à une entreprise. Fournir au modèle du texte de référence à chaque appel signifie qu’il raisonne à partir de matériel actuel et ne suppose pas.

Le pipeline a une structure fixe : il ingère des documents, les divise en blocs, incorpore ces blocs, stocke les vecteurs, effectue une recherche de similarité (souvent combinée à une recherche par mots-clés), réordonne éventuellement les résultats, assemble la requête et génère le contenu.

Ajustement fin

L’ajustement fin diffère par sa nature, et non seulement par son degré. Un modèle préentraîné continue d’être entraîné à l’aide d’un ensemble soigneusement sélectionné de vos propres exemples, généralement des paires d’entrée et de sortie souhaitée illustrant le comportement exact recherché. Les poids du modèle changent, ou, avec LoRA et QLoRA, un petit ensemble de poids d’adaptateur est modifié sur une base déjà figée.

Cela fonctionne bien pour enseigner des manières de faire : un ton de voix, un format de sortie rigide, une méthode particulière pour résoudre un type de problème, ou la gestion des cas limites dans un domaine où des milliers d’exemples étiquetés existent. L’objectif est de remodeler le comportement par défaut afin que les mêmes instructions n’aient pas besoin d’être répétées dans chaque demande, plutôt que d’ajouter des faits.

Cela fonctionne mal pour tout ce qui change constamment. Un catalogue de produits mis à jour chaque semaine ne peut pas raisonnablement être intégré dans les poids du modèle, car les connaissances se figent à la fin de l’entraînement et chaque mise à jour nécessite une nouvelle exécution.

Agents

Un agent place le modèle dans une boucle : observer, raisonner, agir, observer le résultat, raisonner à nouveau, et continuer jusqu’à ce qu’un objectif soit atteint ou qu’une règle d’arrêt s’active. Le modèle ne produit plus une seule réponse. Il décide de ce qu’il doit faire ensuite, souvent en appelant des outils tels que des API, des fonctions, des bases de données et d’autres services, et intègre leurs résultats dans sa décision suivante.

C’est cette boucle qui transforme un système qui répond aux questions en un système qui exécute des tâches. LangGraph, CrewAI ainsi qu’une boucle ReAct écrite manuellement implémentent toutes une version de celle-ci : le modèle formule une pensée, sélectionne un outil, l’outil s’exécute, le résultat est renvoyé dans le contexte, et le cycle se répète jusqu’à ce que l’agent juge avoir terminé ou atteint une limite de pas. Une limite de pas doit toujours être définie.

Une manière concise de distinguer ces trois éléments :

• La récupération fournit les informations appropriées.
• Le réglage fin assure le comportement souhaité.
• Les agents fournissent le degré d’autonomie approprié.

Côte à côte

Les différences se manifestent sur plusieurs dimensions :

• Mises à jour des connaissances. La récupération est en temps réel, car il suffit de mettre à jour le stockage vectoriel. Les connaissances ajustées sont figées jusqu’à la prochaine session d’entraînement. Pour les agents, cela dépend de ce qu’ils récupèrent ou appellent.
• Coût. La récupération est modérée : embeddings, stockage et tokens d’entrée supplémentaires. Le réglage fin est coûteux en raison de la sélection des données, des calculs, du temps d’utilisation des GPU et de l’évaluation. Les agents présentent des coûts allant de modérés à élevés, car chaque tâche implique plusieurs appels au modèle ainsi que des frais liés aux outils.
• Complexité. La récupération nécessite le découpage des données, l’incorporation de vecteurs d’embedding et l’ajustement des paramètres de recherche. Le fine-tuning exige une préparation des données, une infrastructure de formation, des boucles d’évaluation ainsi que des mesures de protection contre le surajustement. Les agents ont besoin de capacités de planification, d’intégration d’outils, de gestion des erreurs et de contrôle des boucles.
• Délai de mise en place. Quelques jours pour la récupération, des semaines pour le fine-tuning, et de quelques jours à plusieurs semaines pour les agents, en fonction du flux de travail.
• Utilisations idéales. Réponse à des questions, recherche de documents et contextualisation pour la récupération. Ajustement du ton, du format et du raisonnement sectoriel pour le fine-tuning. Tâches multi-étapes, automatisation et utilisation d’outils pour les agents.
• Latence. La récupération ajoute une étape supplémentaire, généralement de 50 à 300 millisecondes. Le fine-tuning n’ajoute rien en termes de latence lors de l’inférence par rapport au modèle de base. Les agents nécessitent souvent plusieurs étapes et peuvent impacter plusieurs secondes par tâche.
• Entretien. La récupération consiste à maintenir la base de connaissances à jour. Le réglage fin consiste à réentraîner périodiquement le modèle à mesure que les besoins évoluent. Les agents impliquent la mise à jour des flux de travail, des outils et des instructions.
• Faillite typique. Une mauvaise récupération entraîne un contexte irrelevant et une réponse inadéquate. Le surajustement rend le modèle trop sensible aux entrées inconnues. Les agents entrent en boucle, utilisent le mauvais outil ou génèrent des coûts illimités.

Trois situations, une pour chacune

Un chatbot d’assistance basé sur les documents produits permet une recherche efficace. Une entreprise de logiciels disposant de 400 pages de documentation, de journaux de modifications et de politiques pourrait affiner un modèle sur ce texte, mais ce modèle deviendrait obsolète dès la prochaine version. L’incorporation de chaque fragment dans un stockage vectoriel évite ce problème. Lorsqu’un client demande si l’API prend en charge les requêtes par lots, le système récupère les trois sections les plus pertinentes, le modèle y répond et cite la page correspondante. Après que les modifications apportées lors du prochain cycle de développement aient mis à jour la documentation, un nouvel incrustage met à jour les réponses sans nécessiter de reformation du modèle.

Un assistant d’écriture de type maison convient bien pour le ajustement fin. Une entreprise de médias souhaite des résumés dans un style précis : un rythme de phrase particulier, sans première personne et un nombre fixe de points clés en haut. Les prompts permettent d’obtenir des résultats proches, mais la qualité décline au fil des sessions longues. Un entraînement sur environ 2 000 paires de résumés édités par des humains permet au modèle de produire des textes conformes à l’identité de la marque de manière fiable, sans nécessiter de coller le guide de style dans chaque demande.

Le tri des candidats convient à un agent. Une startup de recrutement souhaite pouvoir trier les candidats, programmer un appel s’ils remplissent les critères, et laisser le reste se dérouler automatiquement. L’agent lit le CV, le compare aux exigences du poste à l’aide d’une API d’évaluation interne, consulte le calendrier du responsable des recrutements, rédige et envoie l’e-mail de planification, puis enregistre le résultat dans le système de suivi des candidats. Une seule instruction gère tout cela, sans que personne n’intervienne sur les étapes individuelles.

Cette même séparation se retrouve fréquemment dans la pratique : les architectures axées sur la récupération des données s’occupent du traitement des données de base, les agents gèrent l’orchestration, et le ajustement fin est utilisé uniquement lorsque les instructions fournies ne suffisent pas à maintenir un comportement stable.

Comment ils s’articulent

Ces trois éléments ne constituent pas des couches exclusives. Les systèmes les plus performants les associent en chaîne, avec une demande qui part de l’agent chargé de la planification, passe par la récupération des faits, pour arriver à un modèle adapté qui formule la réponse.

User Query
    ↓
   Agent (decides what needs to happen — plan the steps)
    ↓
   RAG (retrieves relevant knowledge, if the step needs facts)
    ↓
   LLM (fine-tuned, if tone/format/behavior consistency matters)
    ↓
   Action (respond to user, call a tool, trigger a downstream workflow)
    ↓
   Agent (evaluates result → loop again or stop)

Dans un environnement de support, le processus se déroule comme suit : un message arrive et l’agent classe son intention, en concluant qu’il faut des informations sur le produit. Le système de récupération extrait les fragments de documentation pertinents. Un modèle affiné rédige la réponse dans le ton de la marque. L’agent juge ensuite si son niveau de confiance est suffisant pour envoyer la réponse automatiquement ou s’il faut que quelqu’un s’en charge, puis il enregistre l’échange dans le CRM.

Si l’un de ces éléments est supprimé, une lacune apparaît. La récupération sans agent ne sait pas quand chercher des informations et quand agir. Un agent sans système de récupération est aveugle à tout ce qui dépasse ses données d’entraînement. Un modèle affiné sans système de récupération produit des réponses fiables et bien formatées, mais qui peuvent être obsolètes.

Le coût de chacun

Les chiffres ci-dessous indiquent uniquement des ordres de grandeur, car les valeurs réelles varient en fonction de l’échelle et du fournisseur.

Pour la récupération, le coût initial consiste à intégrer le corpus, soit une seule fois, soit de manière progressive à mesure que le volume de documents augmente. Les coûts opérationnels comprennent l’hébergement de la base de données vectorielle selon un tarif défini, ainsi que des tokens supplémentaires pour le contexte récupéré à chaque demande. C’est le moyen le moins coûteux pour obtenir une valeur significative, c’est pourquoi la plupart des équipes devraient commencer par là.

Pour le fine-tuning, l’élément coûteux en amont est souvent les données : collecter et étiqueter de bons exemples d’entraînement est cher. Viennent ensuite les ressources informatiques nécessaires aux cycles d’entraînement et d’évaluation. Par la suite, un retraining est requis chaque fois que le comportement doit changer, ainsi que l’hébergement d’un modèle personnalisé, sauf si l’on utilise LoRA sur une base commune. Cela exige le plus grand investissement initial et tolère le moins les erreurs, car de mauvaises données d’entraînement influencent directement négativement les poids du modèle.

Pour les agents, la configuration implique la conception des flux de travail, l’intégration d’outils et le test des scénarios d’échec. Le coût de fonctionnement est l’aspect le plus insidieux, car chaque étape de l’agent correspond à une nouvelle appel à un modèle. Une tâche en cinq étapes peut coûter cinq à dix fois plus cher qu’une simple requête de récupération d’informations, et une boucle sans limite d’itérations peut devenir extrêmement coûteuse. Le coût reflète la complexité de la tâche, et non seulement le volume d’utilisation.

En pratique, la récupération d’informations constitue généralement le moyen le moins cher pour réduire au maximum les hallucinations. Le réglage fin ne s’avère rentable que lorsque le comportement cohérent est une exigence réelle du produit et non un simple avantage supplémentaire. Les agents justifient un prix par tâche uniquement lorsque le travail nécessite plusieurs décisions et actions, et non lorsqu’une seule requête bien fondée suffirait.

Règles pratiques pour le choix

• Choisissez la récupération de connaissances lorsque les données changent fréquemment. Les documents, politiques, catalogues, prix et stocks qui évoluent chaque semaine ou chaque jour s’y prêtent bien, tandis que le réglage fin s’y adapte mal.
• Choisissez le réglage fin lorsque le comportement est plus important que les connaissances. Si le modèle connaît le domaine mais continue d’utiliser le ton, le format ou le schéma de raisonnement incorrects malgré de bons prompts, le problème est comportemental.
• Choisissez un agent lorsque la tâche nécessite plusieurs étapes ou actions dans le monde réel. Répondre à une question n’en exige pas, mais déterminer ce qui doit se passer puis l’accomplir à travers plusieurs systèmes, si.
• Combinez la récupération de connaissances et le réglage fin lorsque des faits fiables ainsi qu’une voix cohérente sont nécessaires, ce qui est très courant dans les produits destinés aux clients.
• Combinez la récupération de connaissances et un agent lorsque la tâche requiert à la fois des faits et des décisions, l’agent choisissant ce qu’il faut rechercher et quand agir en fonction de cela.

Évitez l’agent lorsqu’il n’est utile que par mode. Si une prompt bien conçue et une seule requête de récupération suffisent, l’agent ajoute du retard, des coûts et des risques d’échec sans aucun avantage.

La même logique s’applique dans deux diagrammes de flux courts. Le premier vérifie si la réponse dépend d’informations qui changent fréquemment.

Does the answer depend on information that changes often?
   YES → RAG
   NO  ↓

La deuxième question porte sur la cohérence du comportement et sur le fait de savoir si la tâche comprend plusieurs étapes ou des actions réelles.

Does the model need to consistently behave/sound a certain way,
and prompting alone isn't holding that consistency?
   YES → Fine-tuning
   NO  ↓Does the task require multiple steps, tool calls, or real actions
(not just answering a question)?
   YES → Agent (likely combined with RAG, and fine-tuning if voice matters)
   NO  → A single well-prompted LLM call is probably enough

Un petit projet illustrant l’ordre d’action

Prenons l’exemple d’un assistant RH interne.

1. Commencez par la récupération des informations. Intégrez le manuel du personnel, les politiques de congés et les documents relatifs aux avantages sociaux dans un stockage vectoriel. Les employés pourront alors demander combien de jours de maladie ils ont et recevoir une réponse fondée et citée. Cela couvre environ 70 pour cent des cas d’usage et ne nécessite que quelques jours.
2. Apportez des ajustements uniquement en cas de lacune. Supposons que le service RH souhaite que chaque réponse ait un ton empathique spécifique ainsi qu’un format strict : « Voici la politique, voici ce que cela signifie pour vous ». Si les prompts échappent constamment à ce format, un petit modèle entraîné sur quelques centaines de paires de questions-réponses rédigées dans ce style peut combler cette lacune.

Ajouter un agent pour les cas à plusieurs étapes. Une demande de congé pour le vendredi suivant n’est pas une simple recherche. Cela implique de vérifier le solde de congés, de consulter le calendrier de l’équipe pour détecter les conflits, de soumettre la demande et de confirmer à l’employé, chaque étape constituant une requête distincte. L’agent utilise la couche de récupération d’informations pour les questions relatives aux politiques en vigueur, ainsi que le modèle affiné pour déterminer le ton du message final.

Cet ordre est intentionnel. La récupération d’informations vient en premier car elle est la moins coûteuse et couvre le plus grand nombre de tâches. L’affinage du modèle n’intervient qu’une fois qu’un véritable écart de comportement apparaît. Les agents interviennent en dernier, et uniquement lorsque la tâche nécessite réellement plusieurs étapes d’exécution.

Erreurs fréquentes

• Ajustements finaux là où une récupération d’informations était nécessaire. Les équipes tentent d’intégrer les connaissances dans les poids du modèle lorsque le problème réel implique un manque d’accès aux informations actuelles. Le résultat est plus lent, bien plus coûteux, et devient obsolète dès sa mise en production.
• Agents sans processus de travail défini. Un objectif vague associé à des outils non restreints pousse l’agent à errer, à faire des boucles et à se comporter de manière imprévisible. Des outils ciblés, des conditions d’arrêt claires et un plafond strict au nombre d’étapes de raisonnement permettent de le maintenir sous contrôle, tandis que lui demander simplement de résoudre le problème ne remplace en rien un processus bien défini.
• Ignorance de la latence et des coûts. Chaque opération de récupération d’informations et chaque étape effectuée par l’agent entraîne un aller-retour supplémentaire ainsi que des coûts supplémentaires en tokens. Une démonstration peut sembler excellente, mais en production, elle peut nécessiter 12 secondes et six appels au modèle pour obtenir une seule réponse.

Interpréter les options comme une échelle. Aucune des trois n’est plus avancée que les autres. Le meilleur système est celui qui est le plus simple et qui remplit sa fonction, ce qui est souvent uniquement la récupération d’informations ou la récupération combinée à un modèle légèrement ajusté, bien avant qu’un ensemble d’agents ne soit nécessaire.

Éviter l’évaluation. Les trois approches se dégradent progressivement : fragments de récupération faibles, ajustements excessifs, ou agents qui prennent des décisions erronées sans que personne ne s’en aperçoive. Des ensembles d’évaluation doivent exister avant que l’une de ces approches ne puisse être étendue.

Direction future

Le secteur se dirige clairement vers des workflows basés sur des agents, c’est-à-dire des systèmes qui planifient, agissent et font le suivi sans avoir besoin d’être sollicités à chaque fois. L’étape suivante est l’approche hybride : utilisation de la récupération d’informations pour fonder les réponses, ajustements pour stabiliser le comportement, ainsi que une mémoire à long terme permettant à un agent de se remémorer des échanges antérieurs au lieu de commencer à zéro à chaque session.

On observe un changement visible, passant des chatbots à ce que certains appellent désormais des employés IA, des systèmes qui effectuent des tâches continues à travers différents outils et sur le long terme, au lieu d’attendre une question. Atteindre ce stade n’a peu à voir avec le choix de la technique la plus spectaculaire ; cela dépend de la compréhension de ce que chaque composant fait bien et de leur assemblage délibéré, en commençant par la couche la plus simple capable de résoudre le problème.

Le choix n’a jamais porté sur la récupération d’informations, le réglage fin ou les agents. La vraie question est de savoir quelle combinaison un système donné a besoin, et dans quel ordre le construire.

Lectures complémentaires

• Chroma Context-1 : un sous-agent de recherche de 20B pour un RAG agent plus économique et plus performant — Comment Chroma’s Context-1 de 20B fonctionne en tant que sous-agent uniquement dédié à la récupération de données en éliminant son propre contexte, comment il a été entraîné, ce qui manque sans son mécanisme de support, et où il présente des limites.
• Notes pratiques : les trois niveaux de Google Cloud RAG : recherche vectorielle, moteur RAG et récupération par agent — Guide opérationnel des Notes pratiques : les trois niveaux de Google Cloud RAG : recherche vectorielle, moteur RAG et récupération par agent : contrats, vérifications et emplacements de code à insérer.

Le récupération agente et le contexte suffisant : quand RAG ne sait pas assez — Le RAG standard répond souvent trop tôt. Apprenez à planifier les recherches, à orienter les sources, à évaluer les preuves et à effectuer de nouvelles recherches jusqu’à ce que le contexte soit suffisant, avec un exemple concret.

Notes pratiques : RAG est mort. LLM Wiki — L’idée d’Andrej Karpathy — est ce qui vient ensuite — Guide pas à pas des Notes pratiques : RAG est mort. LLM Wiki — L’idée d’Andrej Karpathy — est ce qui vient ensuite : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui développent RAG.

Dix façons de réduire les hallucinations sans retouche fine — Dix solutions au niveau du système permettant de diminuer les hallucinations des LLM dans un agent de e-commerce : un meilleur contexte, des mécanismes de récupération d’informations, des graphes, des outils, des procédures de validation et d’évaluation, sans aucune retouche fine.

Notes pratiques : Qu’est-ce que la génération augmentée par la récupération d’informations (RAG) ? Une approche pratique — Guide opérationnel des Notes pratiques : Qu’est-ce que la génération augmentée par la récupération d’informations (RAG) ? Une approche pratique : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui mettent en œuvre ce modèle.

Petit modèle, grand impact : Ce que nous avons appris en affinant NVIDIA Nemotron 3.5 — Guide pratique de Petit modèle, grand impact : Ce que nous avons appris en affinant NVIDIA Nemotron 3.5 : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui adoptent ce modèle.

Notes pratiques : Que signifie la responsabilité lorsque des agents écrivent du code — Guide pratique de Notes pratiques : Que signifie la responsabilité lorsque des agents écrivent du code : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui adoptent ce modèle.