RAG & LLMChatbot interne sur des milliers de documents : ce qui casse en production
· 6 min de lecture · par l'équipe Agenticiel
Un chatbot sur des documents internes casse rarement à cause du modèle : il casse quand le volume passe de quelques dizaines à plusieurs milliers de documents. Les cinq points de rupture sont toujours les mêmes : le découpage des documents, les droits d’accès par document, la fraîcheur des sources, les citations et l’absence d’evals. Sur 5 000 fichiers SharePoint, le chatbot qui répondait juste en démonstration donne des réponses fausses, périmées ou tirées d’un dossier interdit à l’utilisateur.
Le principe reste celui du RAG (Retrieval-Augmented Generation) : à chaque question, le système recherche les passages pertinents dans vos documents, puis un LLM (Claude, Mistral, GPT) rédige la réponse à partir de ces seuls passages. Sur un grand corpus, la recherche doit choisir parmi des milliers de passages proches, souvent contradictoires : c’est là que la qualité se joue.
Un cas typique : une ETI déploie un assistant interne sur ses procédures, contrats et notes RH, puis les signalements arrivent : une procédure de 2023 citée à la place de celle de 2026, une note de direction confidentielle reprise dans une réponse, une source introuvable. Chaque incident correspond à un point de rupture précis, qui se corrige.
Pourquoi un chatbot RAG se dégrade-t-il quand le nombre de documents augmente ?
Un chatbot RAG se dégrade avec le volume parce que la recherche, pas le modèle, devient le maillon faible : plus il y a de passages similaires, plus le risque de remonter le mauvais est élevé.
Trois mécanismes expliquent cette dégradation :
- Les doublons et les versions : la même procédure existe en trois versions dans trois dossiers, et la recherche vectorielle les juge équivalentes.
- Le vocabulaire métier : les embeddings (représentations numériques du sens d’un texte) captent mal les références internes, codes produits ou numéros d’articles. Une recherche hybride, qui combine similarité sémantique et mots-clés via Elasticsearch ou la recherche plein texte de PostgreSQL, rattrape ces cas.
- Le classement : sur 5 000 documents, les dix premiers résultats ne suffisent plus. Un reranker comme Cohere Rerank reclasse les candidats selon leur pertinence réelle pour la question, et améliore souvent plus la qualité que le changement de modèle.
Comment découper des milliers de documents sans perdre le sens ?
Il faut découper selon la structure du document (titres, sections, articles, tableaux) plutôt qu’en blocs de taille fixe, et rattacher à chaque passage son contexte : titre du document, section, date, auteur. Un passage « Le délai est de 30 jours » ne sert à rien si l’on ne sait pas de quel contrat il vient.
En production, la difficulté tient à l’hétérogénéité des formats (PDF scannés, tableaux, pages Notion, présentations). Des outils comme Unstructured ou Docling extraient le texte en conservant titres et tableaux ; LlamaIndex orchestre ensuite le découpage et l’indexation avec des stratégies adaptées à chaque type de source. Le réglage de ces paramètres est détaillé dans notre article sur le découpage des documents pour un RAG en production.
Faites relire cent passages par un expert métier avant l’indexation complète.
Comment respecter les droits d’accès par document dans un chatbot interne ?
Un chatbot interne respecte les droits d’accès quand le filtrage est appliqué au moment de la recherche, avant que le LLM ne voie le moindre passage. Demander au modèle de « ne pas révéler » une information confidentielle ne protège rien : s’il a lu le passage, il peut le restituer.
Concrètement, chaque passage indexé porte les groupes autorisés hérités de la source (SharePoint, Google Drive, Notion). À chaque question, le système identifie l’utilisateur via le SSO de l’entreprise, puis la base vectorielle ne renvoie que les passages qu’il a le droit de lire. Deux pièges reviennent souvent :
- Les droits qui changent : un collaborateur change de service, un dossier est restreint. Si l’index n’est pas resynchronisé, l’ancien droit reste actif dans le chatbot.
- Les réponses agrégées : une synthèse construite à partir de dix documents ne doit en contenir aucun d’interdit. Le filtrage passage par passage règle ce cas, le filtrage par document en tête de liste ne le règle pas.
Ce contrôle se teste automatiquement, avec les mêmes questions posées sous des profils différents. Pour des données sensibles (santé, RH, juridique), l’hébergement du modèle et de l’index en Europe avec Mistral ou un modèle open source s’ajoute à ce filtrage.
Comment garder des réponses à jour et des citations vérifiables ?
Des réponses à jour supposent une indexation incrémentale : chaque document ajouté, modifié ou supprimé à la source doit l’être dans l’index, sans réindexer tout le corpus chaque nuit. La suppression est le point le plus souvent oublié : une procédure retirée de SharePoint continue alors d’être citée pendant des mois.
Quatre pratiques :
- synchroniser à partir des événements de la source (modification, suppression) ou d’un contrôle d’empreinte des fichiers ;
- stocker la date de version de chaque passage et privilégier la plus récente à pertinence égale ;
- marquer les documents archivés pour qu’ils restent consultables mais ne servent plus de base de réponse par défaut ;
- afficher la date de la source dans la réponse.
Les citations sont la deuxième moitié de la confiance. Chaque affirmation de la réponse doit renvoyer au document, à la section et, si possible, au paragraphe, avec un lien qui ouvre la source. Une seule citation qui pointe vers un passage sans rapport suffit à faire abandonner l’outil. Un exemple de mise en production : un assistant d’analyse de contrats qui cite le paragraphe exact. Le sujet de la fraîcheur est approfondi dans garder des réponses RAG à jour quand les sources changent.
Quelles evals mettre en place avant d’ouvrir le chatbot à toute l’entreprise ?
Avant d’ouvrir le chatbot, il faut un jeu de test de 100 à 200 questions réelles, avec la bonne réponse et le document source attendu, validé par les experts métier. Les evals (tests automatisés de la qualité des réponses) mesurent ensuite trois choses distinctes :
| Mesure | Question posée | Outil courant |
|---|---|---|
| Qualité de la recherche | Le bon passage est-il remonté ? | Ragas, scripts maison |
| Fidélité | La réponse s’appuie-t-elle uniquement sur les sources ? | Ragas, DeepEval |
| Utilité | La réponse répond-elle à la question posée ? | relecture métier, Langfuse |
Ce jeu de test est rejoué à chaque changement de découpage, de modèle ou de prompt. En production, Langfuse trace chaque question, les passages remontés, la réponse et le retour de l’utilisateur : les questions sans bonne réponse alimentent le jeu de test suivant. La construction de ce jeu est détaillée dans évaluer un RAG avec un jeu de test représentatif.
Les cinq vérifications à faire sur votre chatbot cette semaine
Cinq tests rapides, sur un chatbot existant ou en cours de construction :
- posez une question dont la réponse a changé récemment et vérifiez que la nouvelle version est citée ;
- connectez-vous avec un profil restreint et cherchez une information confidentielle ;
- cliquez sur trois citations et vérifiez qu’elles mènent au bon passage ;
- supprimez un document de test à la source et vérifiez qu’il disparaît des réponses ;
- demandez combien de questions de test sont rejouées à chaque modification.
Si l’un de ces tests échoue, le chatbot n’est pas prêt pour toute l’entreprise. Pour un corpus de plusieurs milliers de documents, un chatbot RAG sur vos documents internes se construit avec ces cinq points dès la conception : c’est le cadrage, offert, qui fixe le prix selon les sources et les droits d’accès à gérer, et qui chiffre aussi le coût de fonctionnement mensuel.
