RAG ou fine-tuning ? Comprendre d’abord l’erreur du chatbot

« Il faut entraîner l’IA avec nos données. » Cette phrase ouvre souvent un projet de chatbot. Demandez d’abord ce qui manque réellement. Le système ignore-t-il les conditions contractuelles actuelles ? Respecte-t-il mal le format demandé ? Les documents sont-ils eux-mêmes contradictoires ? Ces problèmes appellent des réponses différentes. L’entraînement n’est pas automatiquement la bonne solution à une connaissance d’entreprise absente.

Pour une petite société, un premier essai utile peut être une tâche claire avec quelques pièces choisies. Une recherche régulière dans un ensemble plus large peut justifier la génération augmentée par récupération, ou RAG. Le fine-tuning adapte plutôt le comportement du modèle à partir d’exemples. Ces approches peuvent se combiner, sans remplir la même fonction. Le choix doit suivre l’échec observé, pas le terme le plus impressionnant.

Trois approches et leur travail réel

La présentation AWS des questions documentaires distingue contexte fourni directement, RAG et adaptation du modèle. Les instructions définissent tâche, limites et sortie attendue. Un processus limité peut recevoir directement les informations utiles à chaque requête. Le RAG recherche des passages pertinents dans un fonds et les fournit pour préparer la réponse. Le fine-tuning adapte le comportement à partir d’exemples. Même un modèle adapté a besoin d’un accès aux faits modifiés après son entraînement.

La comparaison AWS entre RAG et fine-tuning recommande de commencer par le RAG pour les questions sur des documents propres. C’est une orientation utile, sans garantie pour votre projet. Vérifiez si la recherche trouve le passage valable et si la réponse l’utilise correctement dans votre fonds réel.

Commencer par une liste d’échecs

Réunissez des questions représentatives et notez les preuves nécessaires à chaque réponse attendue. Ajoutez des questions sans réponse disponible et au moins un cas de sources contradictoires. Utilisez des exemples anonymisés. Le but n’est pas de charger autant d’historiques que possible, mais de décrire le comportement métier sous une forme vérifiable.

Classez chaque erreur. La source actuelle était-elle absente des résultats ? Présente mais mal comprise ? Le contenu est-il juste et le format mauvais ? L’assistant a-t-il promis une action interdite ? Un modèle plus puissant ne répare pas de façon fiable un mauvais fonds documentaire. Un fonds plus grand ne remplace pas une règle de validation floue. Cette analyse évite une solution coûteuse au mauvais problème.

Quand des instructions peuvent suffire

Avec peu de règles stables et un contexte clair, commencez simplement. Un assistant peut par exemple classer les demandes dans trois catégories et signaler les informations manquantes. Fournissez définitions, exemples et limites. Examinez ensuite quels cas échouent encore après cette amélioration.

Cette variante a aussi ses limites. Des documents souvent modifiés ou des sources différentes pour chaque question rendent la sélection manuelle difficile. Une instruction trop longue peut cacher des règles incompatibles. Ne gardez pas la simplicité par principe. Servez-vous des résultats pour justifier l’étape nécessaire suivante, tout en conservant les tests réussis comme point de comparaison.

Quand examiner le RAG

Le RAG devient intéressant si les réponses dépendent d’un fonds important ou changeant. Le travail porte alors sur sources, recherche, métadonnées et permissions. Une nouvelle liste de prix doit remplacer visiblement la précédente. Un document de personnel ne doit pas apparaître dans une réponse client parce que ses mots ressemblent à la question.

Évaluez recherche et rédaction séparément. Montrez d’abord au responsable les passages trouvés seuls. Permettent-ils de répondre ? Examinez ensuite la réponse et son rapport au passage. Une belle formulation aide peu lorsque la mauvaise pièce a été retenue. L’absence de preuve demande une limite identifiable et une prochaine étape, sans certitude inventée.

Quand examiner le fine-tuning

Le fine-tuning mérite une étude si un défaut de comportement répété subsiste malgré des instructions et exemples corrects. Une classification particulière ou une structure de sortie constante peuvent être des cas utiles. Il faut des données d’entraînement adaptées et un ensemble d’évaluation séparé. L’amélioration doit se voir sur des cas qui n’ont pas servi à adapter le modèle.

Ne supposez pas que horaires, commandes en cours ou conditions révisées restent automatiquement à jour dans le modèle. Définissez leur apport au moment de la requête. Le fine-tuning n’ajoute pas non plus automatiquement citations et contrôle des droits. Ces fonctions exigent un processus explicite et des interfaces vérifiables.

Comparer le travail durable

Approche	Travail récurrent	Test important
Instructions	Maintenir règles et informations fournies.	Cas ambigu hors des exemples.
RAG	Maintenir sources, index, droits et recherche.	Source nouvelle et source interdite.
Fine-tuning	Suivre données, version du modèle et évaluation.	Cas inconnu de l’ensemble de test séparé.

Comparez consommation du modèle, recherche, maintenance, examen et corrections humaines. Un prix par réponse plus faible peut disparaître dans les retouches. Le pilote doit donc rendre visible le temps nécessaire pour garder le système utilisable. Désignez qui valide une source et comment une mauvaise réponse conduit à une modification précise.

Tester le choix avec une règle modifiée

Une expérience révélatrice consiste à réviser volontairement une règle. Utilisez un document interne fictif et changez l’heure limite d’une prestation test. Posez la même question avant et après. Le système doit employer la règle actuelle, sans continuer à présenter l’ancienne comme valable. Vérifiez responsable du changement et possibilité de retour arrière.

L’essai montre où résident les faits et ce que leur entretien demande. Il ne démontre pas une exactitude générale. Ajoutez d’autres questions et rôles autorisés avant une décision de production. Gardez résultat, version et erreurs restantes pour pouvoir expliquer le choix plus tard.

Ajoutez aussi une question demandant plusieurs sources. Un passage correct peut être insuffisant si la réponse dépend à la fois d’une politique de service et d’une liste d’exceptions. Vérifiez si le système reconnaît la partie manquante. Le problème peut relever de la recherche, sans être corrigé directement par l’entraînement du modèle qui rédige.

Garder un test final indépendant

Définissez les questions utilisées pendant le développement et celles réservées à la vérification finale. Un meilleur score pourrait autrement refléter seulement les exemples déjà connus. Ajoutez d’autres formulations et des situations demandant une réponse différente. Essayez une courte conversation où la personne corrige une donnée ou change de sujet. Une information ancienne peut contaminer la réponse même si la recherche fonctionne. Classez ce défaut séparément. Avant un nouvel investissement, montrez au responsable des erreurs concrètes et leur base attendue, plutôt qu’un score global seul.

Les articles sur l’origine des réponses et leurs sources traitent de la traçabilité ultérieure. Ici, nous parlons du choix d’investissement précédent. Pour un chatbot d’entreprise, apportez questions, sources actuelles et erreurs observées. Elles permettent d’examiner quelle technique supplémentaire est réellement nécessaire.