Évaluation du chatbot RAG : comment un balayage de modèle + des correctifs de récupération ont réduit les coûts de 79 % et amélioré la qualité de 19 %

Un utilisateur de Reddit a procédé à une évaluation complète d'un chatbot RAG de support client qui fonctionnait sur ChromaDB avec un seuil de similarité par défaut de 0,7 (distance cosinus) et utilisait Gemini 3.1 Flash Lite Preview pour la génération. Il a constaté que le modèle le plus cher était le moins performant et que plusieurs changements non évidents avaient un réel impact.

Les problèmes de récupération se font passer pour des problèmes de LLM

Le bot répondait « Je n'ai pas accès à des informations spécifiques sur les services de notre entreprise » lorsque les utilisateurs posaient des questions d'ouverture informelles comme « Hey, qu'est-ce que vous faites ? ». L'instinct était de modifier les prompts ou de changer de modèle, mais la cause première était la récupération : le seuil de similarité dans ChromaDB était fixé à 0,7 (distance cosinus, plus bas = plus similaire, donc en fait strict). Les ouvertures informelles ne produisaient pas d'embeddings suffisamment proches d'un chunk, donc aucun document n'était récupéré. La leçon : enregistrer le contexte réellement reçu par le LLM avant d'incriminer la génération. Si la récupération ne renvoie rien, aucun prompt engineering ne pourra y remédier.

Les évaluateurs heuristiques sont pires que rien

La correspondance de mots-clés et le comptage de références sources donnaient des chiffres sans corrélation avec la satisfaction des utilisateurs. L'auteur est passé à un juge LLM (Claude Haiku 4.5 via OpenRouter) notant la pertinence, l'exactitude, l'utilité et l'ensemble sur une échelle de 0 à 10. Coût : quelques centimes par exécution complète.

Dédupliquer les chunks

Deux tours de discussion contenaient trois chunks FAQ quasi identiques dans la fenêtre de contexte. L'ajout d'une vérification de chevauchement de tokens supérieur à 80 % provenant du même fichier source a nettoyé le contexte, réduit les tokens et arrêté une hallucination de noms de produits sur un tour.

Compromis d'ancrage plus strict

L'ajout d'une règle selon laquelle l'agent ne mentionne que des faits issus des documents récupérés a amélioré l'exactitude mais réduit l'utilité sur les tours où le knowledge manquait : le bot a commencé à dire « les docs ne précisent pas cela, contactez le support » au lieu de deviner. L'auteur note que c'est le bon choix pour un bot de support factuel, mais doit être fait consciemment.

Résultats du balayage de modèles

L'exécution du même harnais d'évaluation sur 5 modèles a montré que Gemma 4 26B obtenait un score de 7,88 contre 7,33 pour le Gemini 3.1 Flash Lite Preview original — et coûtait 75 % de moins par session. Mistral Small 3.2 était juste derrière. Nova Micro était le moins cher, mais ses réponses laconiques étaient pénalisées pour ne pas être exploitables. Globalement, la qualité est passée de 6,62 à 7,88 (+19 %) et le coût a chuté de 0,002420 $ à 0,000509 $ par session (−79 %).

L'ensemble de l'évaluation a été réalisée à l'aide de Neo AI Engineer, qui a construit le harnais d'évaluation, géré les exécutions avec points de contrôle, traité les problèmes de timeout et de limite de contexte, et consolidé les résultats. L'auteur a tout vérifié manuellement.