RAG en production : ce qui casse vraiment quand de vrais clients commencent à poser des questions

Vous pouvez construire une démo fonctionnelle de Retrieval-Augmented Generation en un après-midi. On vectorise quelques documents, on les place dans un magasin vectoriel, on récupère les cinq meilleurs passages par similarité cosinus, on les colle dans le prompt. Ça répond aux questions. Dans une capture d'écran, on dirait de la magie.

Puis vous le mettez devant de vrais clients, et l'écart s'ouvre.

Quelqu'un pose sa question dans la troisième langue que vous prenez en charge. Quelqu'un interroge une politique qui existe en deux versions contradictoires sur votre propre site. Quelqu'un demande une chose que vos contenus ne couvrent tout simplement pas, et le système répond quand même : avec fluidité, avec assurance, à côté. Vingt personnes écrivent en même temps pendant qu'un nouveau crawl tourne. Un PDF scanné plutôt que saisi devient un bruit de recherche qui empoisonne discrètement toutes les réponses voisines.

Rien de tout cela n'apparaît en démo, car une démo utilise des documents propres, une seule langue, un seul utilisateur et des questions dont celui qui l'a construite connaît déjà les réponses. Tout ce qui coûte cher dans le RAG vit dans la distance entre ces deux situations.

Ce guide parle de cette distance. Il suppose que vous savez déjà ce qu'est le RAG — sinon, commencez par notre explication de ce qu'est un chatbot RAG et comment il fonctionne, puis revenez. Ce qui suit est la couche au-dessus : l'ingénierie qui décide si un système de recherche survit au contact d'utilisateurs réels.

À chaque agrandissement des fenêtres de contexte, quelqu'un déclare le RAG obsolète. Cela n'est pas arrivé, et les raisons sont structurelles, pas temporaires.

Le contexte utilisable est plus petit que le contexte annoncé. Un modèle qui accepte 200 000 tokens ne raisonne pas aussi bien sur l'ensemble des 200 000. L'effet est bien documenté : l'article « Lost in the Middle » de Liu et al. (2023) a montré une précision qui s'affaisse pour l'information enfouie au milieu d'entrées longues, et chaque génération suivante de modèles à long contexte est arrivée avec une version de la même mise en garde. La qualité se dégrade avant la limite dure. Or la base de connaissances réelle d'une entreprise de taille moyenne ne fait pas 200 pages, mais des dizaines de milliers.

Le fine-tuning change le comportement, pas la connaissance. C'est le malentendu le plus coûteux du domaine. Le fine-tuning excelle pour enseigner un format, un ton ou un schéma de raisonnement. C'est une manière faible et peu fiable d'enseigner des faits, et il se dégrade mal quand les faits changent — ce qu'ils font chaque semaine, dans les prix, les politiques et les stocks.

Le coût passe à l'échelle dans le mauvais sens. Fourrer tout le corpus dans chaque requête, c'est payer tout le corpus à chaque question. La recherche documentaire, c'est payer les quelques milliers de tokens pertinents. À volume de messages réel, cette différence représente toute la marge.

L'auditabilité est une exigence, pas une fonctionnalité. En finance, en santé et en droit, une réponse sans source traçable est inutilisable. La recherche produit cette trace gratuitement, puisque le système sait déjà de quel document vient chaque passage.

La vraie question n'est donc plus de savoir s'il faut faire de la recherche documentaire, mais pourquoi tant de systèmes la font mal.

La cause la plus fréquente de mauvaises réponses n'est ni le modèle, ni les embeddings, ni la base vectorielle. C'est le corpus.

Nous avons vu la base de connaissances d'un client dans laquelle environ la moitié des documents étaient des quasi-doublons de l'autre moitié : la même politique republiée avec de légères différences de mise en forme sur un site marketing, un centre d'aide et un PDF archivé. La recherche renvoyait consciencieusement cinq passages qui étaient cinq copies du même paragraphe ; le modèle voyait une tranche étroite d'éléments au lieu de cinq perspectives, et le budget top-k partait en redondance. Corriger cela fut un travail de pipeline de données manuel et sans gloire. Cela a pourtant plus amélioré la qualité des réponses que tous les réglages de recherche du mois.

Les récidivistes :

• PDF scannés et dégâts d'OCR. Un texte parfaitement lisible à l'œil peut être structurellement déchiqueté : ordre des colonnes mélangé, tableaux aplatis en soupe de mots. Les embeddings d'un texte déchiqueté se récupèrent de façon imprévisible.
• Contenus standards et bandeaux de consentement. Crawlez un site naïvement et chaque page traînera le même avis cookies, le même menu, le même pied de page. Tous les passages partagent alors un long préfixe identique, et la similarité sémantique entre pages sans rapport grimpe. C'est pourquoi notre crawler retire consentement et habillage avant toute indexation.
• Murs d'authentification et pages creuses. Une page de connexion contient du texte, donc un pipeline naïf l'ingère. Elle n'apporte rien et dilue tout.
• Contradictions que personne n'a remarquées. Deux pages indiquent des délais de retour différents. La recherche trouve les deux. Le modèle en choisit une. Quel que soit son choix, quelqu'un recevra une information fausse.

La règle pratique : un contrôle qualité se place avant l'indexation, à un seul endroit du code, et s'applique à tous les chemins capables d'ajouter du contenu. Quand les règles d'ingestion vivent à trois endroits, elles divergent, et l'écart de qualité entre votre parcours d'onboarding et votre recrawl devient un mystère que personne ne sait reproduire. Pour la version pratique, voyez notre guide pour construire une base de connaissances propre.

Une seule recherche vectorielle dense est le brouillon de la recherche documentaire. En production, c'est un pipeline de quatre ou cinq étapes, et chacune corrige un mode de défaillance que les autres n'atteignent pas.

L'expansion de requête. Les vraies requêtes sont courtes, mal orthographiées et pleines de jargon interne. Enrichir la requête de synonymes et de sigles développés avant de la vectoriser améliore le rappel de façon mesurable — surtout pour les questions de deux ou trois mots qui dominent le trafic réel.

La recherche hybride : dense et lexicale. Les embeddings denses captent le sens mais ratent les tokens exacts : références produit, codes d'erreur, numéros de modèle, noms propres. La recherche par mots-clés (chez nous, BM25 sur un tsvector Postgres) atteint précisément ces cas et rate les reformulations. Lancer les deux et fusionner les résultats par Reciprocal Rank Fusion est le standard de production, pas une optimisation.

Un détail qui compte plus qu'il ne le devrait : la recherche par mots-clés dépend de la langue. Postgres ne ramène « prix » à sa racine que si vous lui dites que le texte est en français. Le turc, l'allemand, l'espagnol, le français, l'italien et le portugais ont chacun besoin de leur configuration ; et les langues sans racinisateur intégré — japonais, coréen, chinois — exigent un repli délibéré plutôt qu'accidentel. Un système RAG multilingue qui racinise chaque requête comme de l'anglais perd silencieusement du rappel dans toutes les autres langues. Si vous adressez plusieurs marchés, lisez aussi notre guide des chatbots multilingues.

Le reranking. La fusion vous laisse vingt ou trente candidats plausibles. Un reranker de type cross-encoder note chacun face à la requête réelle et fait régulièrement remonter le bon passage de la 15e place au top 3. Si votre système « cite sans cesse une page presque juste », l'étape de reranking manquante est le premier endroit où regarder.

Le cache, avec soin. Des questions identiques ne devraient pas relancer tout le pipeline. Mais mettez en cache le résultat de recherche, indexé par requête et top-k — pas la réponse générée — sinon vous servirez une réponse périmée après la mise à jour du document sous-jacent.

Tout système RAG sérieux note sa recherche avant de générer et utilise ce score pour indiquer au modèle jusqu'où faire confiance au contexte : répondre directement, répondre avec réserve, ou refuser et transférer. C'est la meilleure défense qui existe contre l'hallucination.

C'est aussi le réglage le plus susceptible d'être faux, car les valeurs par défaut sont généralement inventées plutôt que mesurées.

Voici une erreur instructive — la nôtre. Notre seuil de « confiance élevée » était fixé à 0,82 de similarité cosinus, un chiffre qui sonne convenablement strict. Nous l'avons ensuite confronté au trafic réel : moins de 2 % des réponses réelles l'ont jamais franchi. Les correspondances sémantiques denses dépassent rarement 0,80 environ, même quand le passage récupéré est manifestement, exactement le bon. Le modèle s'entendait donc dire « ce contexte n'est que partiel » sur presque chaque question, et il prenait des précautions : des réponses justes enveloppées d'une incertitude inutile. La recherche allait bien. C'est la règle graduée qui était fausse.

La correction n'a pas consisté à tout relâcher. Nous avons extrait un échantillon de conversations réelles dans la bande ambiguë et nous les avons lues : entre 0,64 et 0,68, les réponses étaient précises et correctes, citant des limites de forfait et des règles exactes. Mais les vrais trous — des questions sur une intégration que nous ne prenons pas en charge — obtenaient le même score et prenaient à juste titre des précautions. Nous avons donc abaissé la barre haute à un niveau que de vraies correspondances peuvent atteindre, gardé la bande intermédiaire ambiguë en « partiel » et laissé exactement en place le garde-fou bas « ne pas inventer ».

Les leçons transposables : calibrez les seuils sur votre propre distribution, pas sur l'intuition ; lisez les conversations réelles de la bande que vous réglez, car les scores agrégés masquent la différence entre une bonne réponse et un raté bien noté ; et faites de chaque seuil une variable d'environnement, pour qu'un mauvais calibrage soit un retour arrière d'une minute plutôt qu'un déploiement.

Le découpage (chunking) ressemble à une décision de mise en forme. C'est en réalité une décision de recherche, et une part surprenante des plaintes du type « le bot ne trouve pas une chose qui est pourtant dans notre doc » vient de là.

Découper à longueur fixe tous les 500 tokens coupera un tableau en deux, séparera un titre du paragraphe qu'il introduit et scindera une procédure numérotée sur deux passages dont aucun n'est utilisable seul. Un découpage sensible à la structure — respecter d'abord les titres et les limites de paragraphes, puis fusionner vers une taille cible, puis couper les longs segments aux frontières de phrases — coûte une journée d'implémentation et s'amortit immédiatement. Notre pipeline vise environ 800 tokens par passage avec 200 tokens de chevauchement, un point de départ raisonnable pour du contenu d'entreprise essentiellement rédigé.

Le problème plus subtil : une fois isolé, un passage perd le contexte qui le rendait signifiant. « La livraison standard prend 3 à 5 jours ouvrés » est une cible de recherche inutile si le passage ne dit pas de quelle livraison, de quelle région ou de quelle gamme il s'agit. Récupéré seul, il peut être appliqué par le modèle à une tout autre question.

La solution consiste à enrichir chaque passage de sa provenance avant de le vectoriser — titre du document, intitulé de section, source — pour que le texte vectorisé porte le contexte qu'un lecteur humain aurait eu grâce à la page environnante. Anthropic a popularisé une version de cette idée sous le nom de « contextual retrieval » et rapporté une baisse substantielle des échecs de recherche. Nul besoin d'un passage par un LLM pour que cela vaille le coup : un préfixe déterministe construit à partir des métadonnées du document capte l'essentiel du bénéfice à coût marginal nul — c'est ce que nous exécutons en production.

Un avertissement tiré de l'expérience : si vous changez votre stratégie de découpage ou de contextualisation, vous héritez d'une migration. Chaque passage existant a été vectorisé selon l'ancien schéma. Prévoyez une réindexation ciblée, document par document — jamais un réencodage massif à l'aveugle d'un corpus en production.

Les équipes débattent de la qualité de recherche. Ce qui met réellement les systèmes à terre, c'est la fiabilité.

L'ingestion est un processus long, en plusieurs étapes et partiellement externe : récupérer, extraire, découper, vectoriser (un appel d'API payant qui peut heurter une limite de débit), écrire, marquer comme terminé. Tout ce qui tourne plusieurs minutes en franchissant une frontière réseau finira interrompu, et ces interruptions ne sont pas rares.

Notre panne la plus instructive fut silencieuse. Une utilisatrice a lancé un crawl de son site, puis a changé de page. La fonction serverless qui traitait sa requête a été tuée en plein vol — après l'écriture des passages et des embeddings, mais avant que le document ne soit marqué comme traité. Aucune exception. Aucune erreur dans la supervision. Juste un document entièrement indexé affiché en permanence comme « indexation en cours », et une utilisatrice qui a recrawlé le même site quatre fois en dix-neuf heures pour faire changer un badge, avant de partir.

Cette classe de bug nous a enseigné trois invariants à reprendre :

• Ordonnez les écritures pour poser d'abord la vérité visible par l'utilisateur. Basculez l'indicateur « traité » immédiatement après l'écriture durable du contenu ; statistiques, invalidation de cache et autre comptabilité viennent ensuite, chacune bornée et en best effort. Ne laissez jamais une étape facultative s'intercaler entre le vrai travail et l'indicateur qui l'enregistre.
• Rendez chaque handler de tâche idempotent, puis remettez généreusement en file. Si un worker meurt en cours de route, le balayage suivant doit pouvoir rejouer toute la tâche sans risque. Les handlers « supprimer puis insérer » rendent les reprises gratuites.
• Ajoutez un balayage auto-réparateur. Une tâche périodique qui cherche les documents bloqués dans un état inachevé et les remet en file transforme un échec permanent et visible en un retard de quelques minutes. C'est le travail de fiabilité au meilleur rendement dans un pipeline RAG, et presque personne ne le construit avant de s'être brûlé.

Sous charge concurrente, ajoutez aussi l'infrastructure ennuyeuse : une vraie file d'attente plutôt que des promesses lancées et oubliées, des limites de pool de connexions tenant compte du fait que les appels d'embedding gardent des connexions ouvertes, et un cloisonnement par client pour que le crawl de 900 pages de l'un n'affame pas le chat en direct de tous les autres.

La qualité d'un RAG ne s'apprécie pas à l'œil. Toutes les équipes croient en être capables, et toutes se trompent, car le mode de défaillance d'un mauvais système RAG est une réponse fluide, plausible, bien formatée — et fausse. Elle se lit exactement comme une bonne.

Le dispositif d'évaluation minimal viable est plus petit qu'on ne le craint :

Un jeu de référence. Trente à cent vraies questions dont on connaît la bonne réponse, tirées de votre historique de support et non inventées. Rejouez-le après chaque changement de recherche, de découpage, de prompts ou de version de modèle. C'est un test de non-régression, et il doit échouer bruyamment.

Séparez la note de recherche et la note de réponse. Quand la qualité baisse, vous devez savoir si le bon passage n'a pas été trouvé ou s'il a été trouvé puis ignoré. Les corrections sont totalement différentes, et un score global de bout en bout ne peut pas les distinguer.

Surveillez la distribution des scores de confiance dans le temps. Un décalage dans l'histogramme est une alerte précoce : le plus souvent, quelqu'un a ajouté un gros lot de contenu de faible qualité, ou le trafic s'est déplacé vers des sujets que votre corpus ne couvre pas.

Traitez le « je ne sais pas » comme votre télémétrie la plus précieuse. Chaque réponse à faible confiance et chaque transfert est un manque de contenu déjà étiqueté. Les équipes dont l'assistant s'améliore visiblement au fil des mois sont presque toujours celles qui lisent cette liste chaque semaine et écrivent la page manquante. Notre guide d'analytics chatbot détaille les indicateurs à suivre.

Et mesurez le taux de déviation honnêtement. Une conversation n'est pas résolue parce que le client a cessé d'écrire ; elle l'est parce qu'il ne vous a pas envoyé d'e-mail une heure plus tard. Si votre plateforme ne relie pas ces deux événements, vous optimisez un chiffre qui vous flatte.

Deux systèmes RAG d'architecture identique peuvent réussir pour l'un et échouer pour l'autre dans le même secteur. La différence n'est généralement pas dans le pipeline.

Le langage métier est un vrai chantier. Abréviations médicales, noms d'instruments financiers, formats de citation juridique et conventions de références produit cassent la recherche générique de manières bien spécifiques. Un client en finance demande « la trois ans » et désigne un produit précis ; un embedding générique pense au temps. Cela se corrige avec des dictionnaires de synonymes, des filtres de métadonnées et du contenu écrit aussi pour la machine — pas avec un modèle plus gros.

La discipline de périmètre l'emporte sur la puissance. Le moyen le plus rapide de détruire la confiance dans un assistant est de le laisser répondre en dehors de ce qu'il sait réellement. Une frontière explicite — cet agent répond sur nos produits, nos politiques et notre documentation, et transfère le reste — réduit les réponses embarrassantes plus que n'importe quelle amélioration de recherche. C'est d'ailleurs le correctif que nous avons déployé après avoir vu de vrais assistants dériver vers le générique et l'inutile.

L'adoption est une condition de lancement. Un assistant dont l'équipe support n'a pas été informée sera saboté par l'équipe support. Quelqu'un doit être responsable des manques de contenu, lire les transferts et décider de ce que l'assistant a le droit de promettre.

La confiance des grands comptes a une check-list. Accès par rôles pour que la recherche tienne compte de qui pose la question, journaux d'audit montrant quelle source a produit quelle réponse, localisation des données claire, contrôles de rétention et déclaration sans ambiguïté que les conversations clients ne servent pas à entraîner des modèles publics. Ce ne sont pas des fonctionnalités qu'on ajoute après une revue de sécurité : ce sont la raison pour laquelle cette revue passe ou non. Notre guide sur la sécurité et la confidentialité des chatbots détaille ce qu'il faut vérifier chez un fournisseur.

Si vous construisez en interne, le périmètre honnête n'est pas « une base vectorielle et un prompt ». C'est un contrôle qualité du contenu, un pipeline de recherche multi-étapes, des seuils de confiance calibrés, une file de tâches à handlers idempotents avec balayage auto-réparateur, un harnais d'évaluation et une boucle d'analytics — plus l'exploitation continue de l'ensemble. Cela vaut le coup quand la qualité de recherche est votre produit. C'est un mauvais usage de l'année d'une petite équipe quand la recherche n'est qu'un moyen de répondre aux clients.

Si vous achetez, la check-list de cet article devient votre due diligence. Demandez au fournisseur : utilisez-vous une recherche hybride ou seulement dense ? Y a-t-il une étape de reranking ? Comment est fixé le seuil du « je ne sais pas », et puis-je le modifier ? Qu'arrive-t-il à un document si l'ingestion est interrompue à mi-parcours ? Puis-je voir quelle source a produit une réponse donnée ? Que devient la recherche par mots-clés dans ma langue ? Quelles questions l'assistant n'a-t-il pas su traiter la semaine dernière ? Un fournisseur incapable de répondre a construit une démo.

C'est précisément la couche que Chatloom a vocation à prendre en charge. Le pipeline décrit tout au long de cet article — découpage sensible à la structure avec enrichissement contextuel, expansion de requête, recherche hybride dense et lexicale avec racinisation adaptée à la langue, fusion RRF, reranking cross-encoder, confiance calibrée avec un vrai « je ne sais pas », tâches d'ingestion idempotentes et balayage auto-réparateur, et un tableau de bord qui montre exactement quelles questions sont restées sans réponse — tourne derrière chaque agent de la plateforme, en dix langues, sans équipe ML de votre côté de la table.

Essayez-le dès aujourd'hui sur vos propres contenus. Créez un compte gratuit, collez l'URL de votre site et regardez toute la boucle se dérouler — crawl, contrôle qualité, découpage, embeddings, recherche hybride — en à peu près le temps qu'il vous a fallu pour lire cet article. Posez-lui les cinq questions que vos clients posent vraiment. Si les réponses s'appuient sur vos contenus et qu'il admet ce qu'il ignore, vous avez votre évaluation. L'offre gratuite ne demande pas de carte bancaire.

Vous préférez les détails d'abord ? Découvrez comment fonctionne notre moteur RAG, ou lisez l'article compagnon sur l'entraînement d'un assistant sur vos propres données.