RAG vs ajustement fin pour chatbots spécifiques au domaine : comment choisir

Quel problème résolvons‑nous avec un chatbot spécifique au domaine ?

Un chatbot spécifique au domaine répond aux questions en utilisant les connaissances de votre organisation, pas des faits généraux extraits d'internet. Pensez aux politiques RH, manuels produits, règles de tarification, playbooks de support, procédures opérationnelles standard (SOP) et guides internes.

La plupart des équipes ne cherchent pas à « apprendre tout » au modèle. Elles veulent des réponses plus rapides et cohérentes à des questions quotidiennes comme « Quelle est notre règle de remboursement pour les abonnements annuels ? » ou « Quel formulaire dois‑je utiliser pour une demande fournisseur ? » sans fouiller dans des dossiers et des PDF.

La difficulté principale est la confiance. Un modèle général peut paraître sûr même lorsqu'il se trompe. Si votre politique indique « 7 jours ouvrés » et que le modèle répond « 10 jours calendaires », la réponse peut sembler correcte et pourtant causer des dégâts réels : validations erronées, réponses client incorrectes ou problèmes de conformité.

La fréquence de mise à jour de vos documents compte autant que la précision. Si les documents évoluent chaque semaine, le chatbot doit refléter rapidement ces changements, sinon il devient une source d'informations obsolètes. Si les documents changent une fois par an, vous pouvez tolérer un cycle de mise à jour plus lent, mais le chatbot doit rester fiable car les gens lui feront confiance.

Quand on compare RAG et le fine‑tuning pour des chatbots de domaine, l'objectif est pratique : des réponses utiles ancrées dans vos documents, avec des sources claires, et un comportement sûr quand le chatbot n'est pas sûr.

Un énoncé de problème solide couvre cinq éléments : quels documents le bot peut utiliser (et ceux qu'il doit éviter), les types de questions les plus courantes, à quoi ressemble une « bonne » réponse (correcte, brève, avec source), à quoi ressemble une « mauvaise » réponse (suppositions confiantes, règles obsolètes) et quoi faire quand il manque des preuves (poser une question de suivi ou dire qu'il ne sait pas).

RAG et fine‑tuning en langage simple

RAG et le fine‑tuning sont deux façons différentes d'aider un chatbot à bien se comporter au travail.

Retrieval augmented generation (RAG) revient à donner au chatbot une épreuve à livre ouvert. Lorsqu'un utilisateur pose une question, le système recherche dans vos documents (politiques, manuels, tickets, FAQ). Il transmet ensuite les extraits les plus pertinents au modèle et lui demande de répondre en utilisant ce matériel. Le modèle ne mémorise pas vos documents ; il lit des passages sélectionnés au moment de la réponse.

Le fine‑tuning, c'est entraîner le modèle avec des exemples jusqu'à ce qu'il adopte le comportement souhaité. Vous fournissez de nombreux couples entrée‑sortie (questions et réponses idéales, ton, format, règles de non‑expression). Les poids du modèle changent, donc il répond plus systématiquement même quand aucun document n'est fourni.

Un modèle mental simple :

• RAG garde la connaissance à jour en puisant dans vos documents actuels.
• Le fine‑tuning uniformise le comportement : style, règles et schémas de décision.

Les deux approches peuvent échouer, mais de façons différentes.

Avec RAG, le point faible est la récupération. Si l'étape de recherche renvoie la mauvaise page, un texte obsolète ou trop peu de contexte, le modèle peut produire une réponse assurée basée sur de mauvaises preuves.

Avec le fine‑tuning, le point faible est la sur‑généralisation. Le modèle peut apprendre des schémas à partir des exemples et les appliquer quand il devrait poser une question de clarification ou dire « je ne sais pas ». Le fine‑tuning ne suit pas non plus les changements fréquents des documents à moins de le réentraîner régulièrement.

Exemple concret : si votre politique voyage passe de « approbation du manager au‑delà de 500 $ » à « au‑delà de 300 $ », RAG peut répondre correctement le jour même si la politique mise à jour est récupérée. Un modèle fine‑tuned peut continuer à répéter l'ancien montant tant que vous ne l'avez pas réentraîné et vérifié le nouveau comportement.

Quelle solution convient le mieux aux documents d'entreprise changeants ?

Si vos documents changent chaque semaine (ou chaque jour), la récupération correspond généralement mieux à la réalité que l'entraînement. Avec la récupération augmentée pour documents d'entreprise, vous gardez le modèle essentiellement identique et vous mettez à jour la base de connaissances à la place. Ainsi, le chatbot reflète les nouvelles politiques, tarifications ou notes produit dès que la source change, sans attendre un nouveau cycle d'entraînement.

Le fine‑tuning peut fonctionner quand la « vérité » est stable : ton constant, ensemble de règles produit fixe ou tâche étroite. Mais si vous fine‑tunez sur du contenu qui évolue, vous risquez d'enseigner la réponse d'hier. Réentraîner fréquemment pour suivre le rythme devient coûteux et facile à mal gérer.

Gouvernance : mises à jour et responsabilité

Une question pratique est : qui est responsable des mises à jour de contenu ?

Avec RAG, des équipes non techniques peuvent publier ou remplacer un document, et le bot peut l'utiliser après réindexation. Beaucoup d'équipes ajoutent une étape d'approbation pour que seules certaines personnes puissent pousser les changements.

Avec le fine‑tuning, les mises à jour nécessitent généralement un workflow ML. Cela implique souvent des tickets, des temps d'attente et des rafraîchissements moins fréquents.

Conformité et audit

Quand on demande « pourquoi le bot a‑t‑il dit ça ? », RAG a un avantage : il peut citer les passages exacts utilisés. Cela aide pour les audits internes, les revues support client et les sujets réglementés.

Le fine‑tuning intègre l'information dans les poids ; il est donc plus difficile d'afficher une source spécifique pour une phrase donnée.

Les coûts et efforts diffèrent aussi :

• RAG demande du travail initial pour collecter les documents, les découper, les indexer et assurer une ingestion fiable.
• Le fine‑tuning demande de préparer et d'évaluer les données d'entraînement, puis de répéter l'entraînement quand les connaissances changent.
• Quand les mises à jour sont fréquentes, RAG tend à avoir un coût récurrent inférieur.

Exemple : un chatbot RH qui répond à partir de politiques mises à jour chaque trimestre. Avec RAG, les RH peuvent remplacer le PDF de politique et le bot commencera à utiliser le nouveau texte rapidement, tout en affichant le paragraphe sur lequel il s'appuie. AppMaster peut vous aider à construire le portail d'administration pour téléverser les documents approuvés et enregistrer quelles sources ont été utilisées, sans réécrire toute l'application depuis zéro.

Quand utiliser RAG, quand fine‑tuner, et quand combiner

Si votre objectif est des réponses dignes de confiance qui correspondent à ce que disent vos documents aujourd'hui, commencez par la récupération augmentée pour documents d'entreprise. Elle extrait des passages pertinents au moment de la question, si bien que le bot peut indiquer précisément la politique, la spécification ou la SOP qui soutient sa réponse.

RAG est le choix par défaut lorsque le contenu change souvent, quand il faut montrer d'où vient une réponse, ou quand différentes équipes possèdent différents documents. Si les RH mettent à jour la politique de congés chaque mois, vous voulez que le chatbot utilise automatiquement la version la plus récente, pas ce qu'il a appris il y a des semaines.

Le fine‑tuning d'un chatbot sur les données internes a du sens lorsque les documents ne sont pas le problème principal. Le fine‑tuning est idéal pour un comportement stable : voix constante, format strict (par ex. toujours répondre selon un modèle), meilleur routage d'intention ou règles de refus fiables. Considérez‑le comme l'apprentissage du comportement de l'assistant, pas de la dernière version de votre manuel.

Combiner les deux est courant : RAG fournit les faits et un petit fine‑tuning (ou des instructions système fortes) maintient l'assistant cohérent et prudent. Cela convient aussi aux équipes produit qui intègrent le chatbot dans une appli, où l'UX et le ton doivent rester constants même si les connaissances évoluent.

Signaux rapides pour choisir :

• Choisissez RAG quand les réponses doivent rester actuelles, citer le libellé exact ou inclure des sources des documents les plus récents.
• Choisissez le fine‑tuning quand vous avez besoin d'un style fixe, de formats répétés ou de règles plus strictes de faire/ne pas faire.
• Combinez quand vous voulez des réponses ancrées dans les docs et un ton constant avec des refus sûrs.
• Reconsidérez votre plan si vous réentraînez constamment pour suivre de nouveaux documents, ou si la récupération échoue souvent parce que le contenu est désordonné ou mal découpé.

Un moyen simple de repérer la mauvaise approche est la douleur de maintenance. Si chaque mise à jour de politique déclenche une demande de réentraînement, vous utilisez le fine‑tuning pour régler un problème de fraîcheur documentaire. Si RAG renvoie la bonne page mais que le bot répond malgré tout de façon risquée, vous avez probablement besoin de garde‑fous supplémentaires (parfois le fine‑tuning aide).

Si vous intégrez cela dans un véritable outil (par exemple dans AppMaster), une approche pratique est : d'abord RAG, puis ajoutez du fine‑tuning uniquement pour des comportements que vous pouvez clairement tester et mesurer.

Étapes pas à pas : établir une base fiable (avant le choix du modèle)

La plupart des échecs de chatbot viennent de documents désordonnés et d'objectifs flous, pas du modèle.

Commencez par un inventaire des documents : ce que vous avez, où ils vivent et qui peut approuver les changements. Capturez le type et le format (PDF, wiki, tickets, tableurs), le propriétaire et la source de vérité, la fréquence de mise à jour, les règles d'accès et où les doublons apparaissent.

Ensuite, définissez le travail du chatbot en termes simples. Choisissez 20 à 50 questions réelles qu'il doit bien répondre (par ex. « Comment demander un remboursement ? » ou « Quelle est la procédure d'escalade ? »). Définissez aussi ce dont il doit s'abstenir, comme les conseils juridiques, les décisions RH ou tout ce qui dépasse vos documents approuvés. Un refus est une réussite s'il empêche une mauvaise réponse.

Puis nettoyez et structurez les documents pour que les réponses soient faciles à ancrer. Supprimez les doublons, conservez une version actuelle, et étiquetez clairement les anciennes versions. Ajoutez des titres, des dates et des sections claires pour que le chatbot puisse pointer la partie exacte qui soutient sa réponse. Si une politique change souvent, gardez une page unique mise à jour au lieu de plusieurs copies.

Enfin, établissez un contrat de sortie. Exigez une réponse courte, une citation de la section source utilisée et une action suivante si nécessaire (par exemple « Ouvrir un ticket auprès de Finance »). Si vous intégrez cela dans un outil interne avec AppMaster, il aide aussi de garder l'UI cohérente : réponse d'abord, puis citation, puis bouton d'action. Cette structure rend les problèmes visibles pendant les tests et réduit les réponses assurées mais erronées plus tard.

Comment évaluer la qualité sans deviner

Commencez par un petit jeu de test hors ligne. Recueillez 30 à 100 questions réelles que les gens posent déjà dans les tickets, e‑mails et fils de discussion. Gardez la formulation originale, incluez quelques questions vagues et quelques‑unes faciles à mal interpréter. Cela vous donne une méthode stable pour comparer RAG et le fine‑tuning pour les chatbots de domaine.

Pour chaque question, rédigez une courte réponse attendue en langage simple, plus la section exacte du document qui la soutient. Si le chatbot est autorisé à dire « je ne sais pas », incluez des cas où c'est le comportement correct.

Notez les réponses selon quelques dimensions simples

Gardez la grille de notation suffisamment petite pour que vous l'utilisiez réellement. Ces quatre vérifications couvrent la plupart des échecs des chatbots métiers :

• Exactitude : est‑elle factuelle, sans détails inventés ?
• Exhaustivité : couvre‑t‑elle les points clés dont l'utilisateur a besoin pour agir ?
• Qualité de la citation : les extraits ou références soutiennent‑ils réellement l'affirmation ?
• Clarté : est‑elle lisible et précise, ou vague et verbeuse ?

Si vous utilisez la récupération, ajoutez une vérification : a‑t‑elle récupéré le bon fragment, et la réponse a‑t‑elle réellement utilisé ce fragment au lieu de l'ignorer ?

Suivez les changements dans le temps, pas des impressions ponctuelles

Faites de la qualité une routine :

• Exécutez le même jeu de test après chaque changement de prompt, de récupération ou de modèle.
• Conservez une grille unique et enregistrez les totaux par date.
• Étiquetez les échecs (détail de politique manquant, mauvais nombre, doc obsolète, formulation peu claire).
• Examinez en priorité les 5 pires questions et corrigez la cause racine.

Exemple : si un chatbot RH répond correctement à une question sur les avantages mais cite un PDF obsolète, votre score doit baisser. Cela vous indique quoi corriger : fraîcheur des documents, découpage, ou filtres de récupération, pas le style rédactionnel du modèle.

Si vous intégrez le chatbot dans une appli (par exemple avec AppMaster), stockez les questions de test et les résultats avec les releases pour repérer les régressions tôt.

Empêcher les réponses confiantes mais fausses (hallucinations) en pratique

Les réponses assurées mais fausses proviennent généralement de trois causes : le modèle n'a pas reçu le bon contexte, il a reçu un mauvais contexte, ou vous l'avez involontairement encouragé à deviner. Ce risque existe avec RAG et le fine‑tuning, mais il se manifeste différemment. RAG échoue quand la récupération est faible ; le fine‑tuning échoue quand le modèle apprend des schémas et comble les lacunes par du texte plausible.

La solution la plus efficace est d'exiger des preuves. Traitez chaque réponse comme un petit rapport : si le texte de support n'est pas dans les sources fournies, le bot ne doit pas l'affirmer. En pratique, cela signifie que votre application doit passer les extraits récupérés dans le prompt et obliger le modèle à n'utiliser que ces extraits.

Ajoutez des règles de refus et d'escalade claires pour que le bot ait une issue sûre. Un bon chatbot n'est pas celui qui répond à tout ; c'est celui qui sait quand il ne peut pas répondre.

• Si les sources ne mentionnent pas le sujet, dire « Je n'ai pas assez d'informations dans les documents pour répondre ».
• Si la question est floue, poser une question de clarification.
• Si la réponse impacte de l'argent, des accès ou la conformité, l'orienter vers un humain ou ouvrir un ticket.
• Si les documents sont contradictoires, signaler le conflit et demander quelle politique ou version s'applique.

Les contraintes réduisent aussi les suppositions et facilitent la détection des erreurs. Pour les réponses de style politique, exigez le nom du document et la date, et citez 1 à 2 lignes clés qui justifient la réponse.

Exemple : un employé demande « Quelle est la dernière limite de remboursement de voyage ? » Si l'extrait récupéré provient de l'année passée, le bot doit afficher cette date et refuser d'affirmer une « dernière » limite sans une source plus récente.

Si vous construisez cela dans AppMaster, intégrez les règles dans le flux Business Process : étape de récupération, vérification des preuves, puis soit réponse avec citations, soit escalade. Ainsi le comportement de sécurité est cohérent et non optionnel.

Erreurs courantes et pièges à éviter

La plupart des échecs de chatbot ne viennent pas du modèle. Ils viennent de documents désordonnés, d'une récupération faible ou de choix d'entraînement qui poussent le système à paraître sûr alors qu'il devrait ralentir. La fiabilité est d'abord un problème de données et de processus.

Un problème fréquent avec RAG est un découpage qui ignore le sens. Si les fragments sont trop petits, vous perdez le contexte (qui, quand, exceptions). S'ils sont trop grands, la récupération ramène du texte non lié et la réponse devient un mélange d'informations à moitié justes. Un test simple : lorsque vous lisez un fragment seul, a‑t‑il encore du sens et contient‑il une règle complète ?

Un autre piège fréquent est le mélange de versions. Les équipes indexent des politiques de différents mois, puis le bot récupère des passages contradictoires et en choisit un au hasard. Traitez la fraîcheur des documents comme une fonctionnalité : étiquetez les sources avec dates, propriétaires et statut (brouillon vs approuvé), et retirez ou dégradez le contenu obsolète.

L'erreur la plus dommageable est de forcer une réponse quand rien de pertinent n'a été récupéré. Si la récupération est vide ou de faible confiance, le bot doit dire qu'il ne trouve pas de support et poser une question de clarification ou escalader à un humain. Sinon, vous créez des absurdités confiantes.

Le fine‑tuning a son propre écueil : sur‑entraîner sur un ensemble étroit de Q&A. Le bot commence à répéter vos formulations d'entraînement, devient fragile et peut perdre des compétences de raisonnement ou de langage de base.

Signes d'alerte pendant les tests :

• Les réponses ne citent aucun texte source ou citent la mauvaise section.
• La même question obtient des réponses différentes selon la formulation.
• Les questions de politique reçoivent des réponses définitives alors que les docs sont silencieux.
• Après fine‑tuning, le bot a du mal avec des questions simples du quotidien.

Exemple : votre politique voyage a changé la semaine dernière, mais les deux versions sont indexées ; le bot peut approuver une dépense qui n'est plus autorisée. Ce n'est pas un problème de modèle ; c'est un problème de contrôle de contenu.

Checklist rapide avant le déploiement

Avant de mettre un chatbot de domaine à disposition des utilisateurs, traitez‑le comme tout autre outil métier : il doit être prévisible, testable et sûr quand il est incertain.

Utilisez cette checklist comme porte finale :

• Toute réponse de type politique est ancrée. Pour des affirmations comme « Vous pouvez rembourser ceci » ou « le SLA est de 99,9 % », le bot doit montrer d'où il tient cela (nom du doc + titre de section ou extrait). S'il ne peut pas pointer une source, il ne doit pas présenter l'affirmation comme un fait.
• Il demande quand la question est floue. Si la requête de l'utilisateur peut raisonnablement signifier deux choses différentes, il pose une brève question de clarification au lieu de deviner.
• Il sait dire « je ne sais pas » proprement. Quand la récupération renvoie des preuves faibles ou absentes, il refuse poliment, explique ce qui manque et suggère ce qu'il faut fournir (document, nom de politique, date, équipe).
• Les mises à jour de doc changent rapidement les réponses. Modifiez une phrase dans un document clé et confirmez que la réponse du bot change après réindexation. S'il continue à répéter l'ancienne réponse, votre pipeline de mise à jour n'est pas fiable.
• Vous pouvez examiner les échecs. Enregistrez la question utilisateur, les extraits récupérés, la réponse finale et si les utilisateurs ont cliqué utile/pas utile. Cela rend le travail de qualité possible sans deviner.

Test concret : choisissez 20 questions réelles provenant des tickets ou du chat interne, y compris des cas complexes avec exceptions. Exécutez‑les avant le lancement, puis de nouveau après avoir mis à jour une politique. Si le bot ne peut pas ancrer ses réponses, poser des questions de clarification et refuser quand les sources manquent, il n'est pas prêt pour la production.

Si vous transformez le bot en application (par exemple un portail interne), facilitez la visibilité des sources et conservez un bouton « signaler un problème » à côté de chaque réponse.

Scénario d'exemple : un chatbot pour des docs internes fréquemment mis à jour

Votre équipe RH a des politiques et documents d'onboarding qui changent chaque mois : règles de congés, limites de remboursement, dates d'inscription aux avantages et étapes d'intégration. Les gens posent encore les mêmes questions en chat, et les réponses doivent correspondre à la version la plus récente des documents, pas à ce qui était vrai le trimestre précédent.

Option A : uniquement RAG, optimisé pour la fraîcheur

Avec une configuration RAG, le bot recherche d'abord dans la base de connaissances RH actuelle, puis répond en utilisant uniquement ce qu'il a récupéré. L'essentiel est de rendre « montrer son travail » par défaut.

Un flux simple qui fonctionne généralement :

• Indexez les documents RH selon un planning (ou après chaque mise à jour approuvée) et stockez titre, section et date de dernière mise à jour.
• Répondez avec de courtes citations (doc + section) et une note « dernière mise à jour » quand c'est pertinent.
• Ajoutez des règles de refus : si rien de pertinent n'est récupéré, le bot dit qu'il ne sait pas et suggère qui contacter.
• Orientez par défaut les sujets sensibles (licenciement, litiges juridiques) vers un humain.

Cela reste précis au fil des changements parce que vous n'intégrez pas de texte ancien dans le modèle.

Option B : fine‑tuning léger pour le format, toujours ancré dans RAG

Si vous voulez un ton constant et des réponses structurées (par ex. « Éligibilité », « Étapes », « Exceptions », « Escalade vers RH »), vous pouvez fine‑tuner légèrement un modèle sur un petit ensemble d'exemples approuvés. Le bot utilise toujours RAG pour les faits.

La règle reste stricte : le fine‑tuning enseigne comment répondre, pas ce que dit la politique.

Après 2 à 4 semaines, le succès ressemble à moins d'escalades RH pour des questions basiques, une meilleure précision lors des contrôles ponctuels et moins de réponses assurées mais fausses. Vous pouvez le mesurer en suivant la couverture des citations (réponses qui incluent des sources), le taux de refus en cas d'information manquante et un audit hebdomadaire par RH.

Les équipes construisent souvent cela comme un outil interne pour que les RH puissent mettre à jour le contenu, réviser les réponses et ajuster les règles sans dépendre de l'ingénierie. AppMaster est une façon de construire cette application complète (backend, web app et mobile) avec rôles et workflows d'administration.

Prochaines étapes : piloter et intégrer le chatbot dans un produit réel

Considérez le chatbot comme un petit produit. Commencez par une équipe (par ex. support client), un jeu de documents (le dernier playbook de support et politiques) et une boucle de feedback claire. Cela limite la portée et rend les problèmes de qualité évidents.

Plan de pilote mesurable :

• Choisissez 30 à 50 questions réelles tirées des logs de l'équipe.
• Définissez « bon » : réponse correcte, cite le bon doc, et dit « je ne sais pas » quand nécessaire.
• Lancez un pilote de 2 à 3 semaines avec un petit groupe et collectez pouce levé/baissé et commentaires courts.
• Examinez les échecs deux fois par semaine et corrigez la cause (documents manquants, mauvais découpage, politique floue, prompts faibles).
• Étendez seulement après avoir atteint un niveau de qualité fiable.

Pour passer du pilote au « réel », vous avez besoin des fonctions applicatives autour du modèle. Les utilisateurs poseront des questions sensibles et vous devez pouvoir retracer ce qui s'est passé quand le bot se trompe.

Construisez l'essentiel tôt : authentification et rôles (qui peut accéder à quels ensembles de docs), journaux et traces d'audit (question, sources récupérées, réponse, feedback utilisateur), une UI d'administration simple pour gérer les sources de documents et voir les motifs d'échec, et une voie de secours sûre (transfert à un humain ou ticket quand la confiance est basse).

C'est aussi là qu'une plateforme no‑code comme AppMaster peut aider : vous pouvez livrer l'application périphérique, y compris le backend, le panneau admin et les rôles utilisateurs, tout en gardant la logique chatbot modulaire. Cela facilite le changement d'approche plus tard, que vous restiez sur la récupération augmentée ou ajoutiez du fine‑tuning pour des tâches spécifiques.

Après le pilote, ajoutez un nouvel ensemble de documents à la fois. Conservez le même jeu d'évaluation, mesurez de nouveau, puis ouvrez l'accès à d'autres équipes seulement si les résultats sont satisfaisants. Une expansion lente vaut mieux qu'une confusion rapide et réduit les réponses assurées mais erronées avant qu'elles n'érodent la confiance.