Trois raisons pour lesquelles les systèmes RAG en production échouent : contexte fragmenté, dérive et mauvaise utilisation.

Pourquoi les démos RAG fonctionnent tandis que les systèmes en production échouent

La génération augmentée par la récupération d’informations est devenue l’architecture par défaut pour l’intelligence artificielle d’entreprise. Les assistants de support, les outils de connaissance internes, les conseillers en conformité ainsi que les produits de recherche intelligente dans les secteurs bancaire, assurantiel, de la santé, des télécoms, du commerce de détail et gouvernemental l’utilisent tous pour relier les modèles linguistiques aux connaissances propres à l’entreprise. L’idée semble simple : récupérer des passages pertinents dans une base de connaissances et les transmettre au modèle avant qu’il ne réponde. Mettre cela en œuvre en production est bien plus difficile que ce qu’une démonstration de concept pourrait laisser penser.

De nombreuses équipes parviennent à faire fonctionner un prototype, mais rencontrent ensuite de nouveaux problèmes à grande échelle. Les réponses obtenues sont incomplètes. La qualité de la récupération diminue à mesure que les données augmentent. Le contexte essentiel est manquant, des hallucinations apparaissent, la latence augmente progressivement, et les utilisateurs reçoivent des réponses techniquement correctes mais pratiquement inutiles. Parfois, le système de récupération trouve précisément les documents adéquats, mais le modèle donne malgré tout une réponse erronée.

Les paramètres d’entreprise aggravent encore la situation, car les connaissances sont réparties sur des milliers de documents, de politiques, de procédures, de manuels opérationnels et de directives réglementaires. Une décision commerciale peut dépendre de détails dispersés dans plusieurs sections d’un répertoire, ce qui rend la qualité de la récupération aussi importante que les capacités du modèle.

On a souvent l’idée fausse que de meilleurs systèmes RAG signifient principalement un meilleur LLM. Le choix du modèle est important, mais de nombreux problèmes en environnement de production proviennent d’autres facteurs : le découpage des données, l’architecture de récupération, la gestion du contexte, les processus de classement et l’évaluation. Un système de récupération bien conçu associé à un modèle performant bat souvent un système mal structuré utilisant le dernier modèle de pointe. Dans des domaines réglementés comme la banque, connaître ces modes de défaillance est généralement plus utile que de maîtriser les détails internes des derniers modèles, car le succès en production ne dépend que rarement d’une simple mise à jour de modèle. Tout dépend de la qualité avec laquelle les informations sont récupérées, classées, présentées et structurées.

Trois scénarios illustrent comment les choses peuvent mal se passer :

• Un système récupère du matériel pertinent mais manque néanmoins des nuances essentielles.
• La qualité de la récupération diminue à mesure que la base de connaissances s’agrandit.

Le modèle donne une réponse erronée même si les documents corrects ont été récupérés.

La leçon commune à ces trois cas est que de bons systèmes RAG dépendent d’une meilleure récupération des informations, d’une meilleure gestion du contexte, d’une évaluation plus rigoureuse et d’un design de système adapté, et non seulement de modèles plus performants.

Situation un : texte pertinent, mais absence de pertinence dans la réponse

L’une des situations les plus frustrantes est lorsque le système de récupération trouve bien les passages pertinents, mais que la réponse reste insuffisante. Elle peut être factuellement correcte, mais manquer du contexte, des détails subtils ou des nuances propres au domaine que seul un expert humain remarquerait immédiatement. Ce phénomène devient de plus en plus fréquent avec les documents longs dont les informations sont réparties sur plusieurs sections.

Imaginez un répertoire de connaissances d’une banque contenant les politiques relatives à l’onboarding des clients. Les exigences principales se trouvent dans un chapitre, le traitement des exceptions dans un autre, tandis que les exigences réglementaires sont conservées dans une section distincte gérée par le département des risques. Un client demande si un document particulier suffit pour ouvrir un compte. Le système de recherche renvoie la politique d’onboarding sans prendre en compte l’exception réglementaire documentée ailleurs. La réponse du modèle est correcte compte tenu de ce qu’il a vu, mais reste incomplète pour les besoins de l’entreprise. Il s’agit donc d’un système qui ne comprend qu’une partie du document et manque de vue d’ensemble.

Les ingénieurs soupçonnent souvent en premier lieu le modèle. La cause habituelle réside dans l’architecture de recherche.

Des blocs de taille fixe qui fragmentent les idées

La première chose à examiner est la segmentation en blocs. De nombreuses implementations utilisent des blocs de taille fixe, car ils sont faciles à créer et se comportent bien dans les expériences : les documents sont divisés tous les quelques centaines de tokens, puis ces fragments sont stockés dans une base de données vectorielle. Cette méthode est simple, mais elle perturbe souvent les relations logiques. Les documents ne sont pas écrits en blocs de taille fixe ; ils sont organisés autour d’idées, de sections, de politiques, de procédures et de concepts commerciaux. Lorsqu’une frontière coupe l’un de ces éléments, le contexte se fragmente. Une définition de politique peut se trouver dans un bloc tandis que son exception se trouve dans un autre. Le système de récupération affiche la définition, mais ne trouve jamais l’exception, ce qui oblige le modèle à raisonner à partir de preuves incomplètes.

Solutions aux contextes fragmentés

Le chunking sémantique constitue la solution habituelle. Plutôt que de couper à des comptes de tokens arbitraires, il suit une structure naturelle telle que les titres, les sections, les paragraphes et les changements de sujet, ce qui préserve les relations entre éléments et améliore considérablement la récupération des informations.

Même dans ce cas, les informations importantes se trouvent souvent à la frontière entre deux blocs. Si ces blocs sont entièrement indépendants, la récupération peut encore les manquer. Les blocs qui se chevauchent aident à ce sujet : permettre aux blocs voisins de partager du contenu assure une continuité au-delà des frontières, car ce qui termine un bloc ouvre également le suivant, réduisant ainsi les risques de perdre un contexte pertinent.

Lorsque les documents deviennent plus complexes, une structure parent-enfant s’avère très utile. De petits fragments sont intégrés et recherchés car ils permettent une précision accrue. Dès qu’un petit fragment correspond, le système récupère la section parente plus large qui le contient, permettant ainsi au modèle de voir à la fois les détails correspondants et leur contexte. C’est un peu comme trouver le paragraphe approprié puis lire toute la section plutôt que quelques phrases isolées.

Les systèmes de production montrent également que la meilleure réponse réside rarement dans un seul fragment. Les informations complémentaires se trouvent souvent juste avant ou après le résultat principal, de sorte que se limiter au fragment le mieux classé peut laisser le raisonnement incomplet. Étendre la recherche pour inclure les fragments voisins en plus du résultat principal permet de préserver la continuité et de faire en sorte que le modèle comprenne comment les éléments sont liés.

L’augmentation des bases de connaissances rend la qualité du retrait d’informations encore plus cruciale. La recherche vectorielle est excellente pour trouver du contenu sémantiquement similaire, mais elle peut manquer des termes exacts, des noms de produits, des identifiants de politiques, des références réglementaires et des mots-clés spécifiques à un domaine. Dans la banque, un client peut citer une réglementation précise, un type de compte ou une catégorie de transaction qui exige une correspondance exacte. Une stratégie hybride combinant la recherche sémantique avec des méthodes basées sur les mots-clés comme BM25 couvre ces deux aspects : la recherche sémantique permet de saisir le sens, tandis que la recherche par mots-clés assure la précision ; ensemble, elles offrent des résultats supérieurs à chacune prise isolément.

En dernier lieu, on procède au réclassement et à l’optimisation du contexte avant que quoi que ce soit n’atteigne le modèle. Tous les extraits récupérés ne méritent pas d’être inclus dans la requête finale. Les outils de réclassement placent en tête les éléments les plus pertinents, tandis que l’optimisation du contexte élimine les redondances afin d’exploiter au mieux l’espace disponible. L’objectif n’est pas seulement de récupérer du texte pertinent, mais aussi de fournir au modèle la compréhension qu’aurait une personne compétente après avoir lu les sections pertinentes. Lorsque la récupération préserve les relations entre concepts, politiques, exceptions et preuves, la qualité des réponses s’améliore considérablement et les détails subtils dissimulés dans de longs documents cessent d’être oubliés.

En bref

Avec ce symptôme, examinez la couche de récupération avant le modèle. Revoyez la stratégie de segmentation en blocs, passez à une segmentation sémantique avec chevauchement, ajoutez une récupération parent-enfant, étendez-la aux blocs voisins, et combinez une recherche hybride avec un réclassement. Ces modifications fournissent généralement au modèle un contexte plus riche et mieux connecté, ce qui est habituellement ce qui permet de préserver les nuances dans les documents longs.

Scénario deux : performant en développement, instable en production

Une histoire fréquente dans le milieu des entreprises se déroule ainsi : un système RAG brille pendant le développement, puis commence à retourner des résultats irrelevants ou incohérents peu après son lancement. La démonstration s’est bien passée, les requêtes de test ont donné des réponses précises, la récupération d’informations semblait fiable et la confiance était élevée. Puis le trafic réel arrive : les utilisateurs posent des questions différentes, de nouveaux documents continuent d’être ajoutés à la base de connaissances, les processus métier changent et le volume augmente. Les réponses qui semblaient correctes deviennent incohérentes, incomplètes ou hors sujet.

Les données ont-elles changé ?

La première vérification consiste à déterminer si la distribution des données a changé. Les environnements de développement disposent d’un ensemble de données petit, soigneusement sélectionné et organisé. En production, on peut trouver des milliers ou des millions de documents rédigés par différentes équipes selon divers formats et normes. Imaginez une banque qui commence avec un petit ensemble de politiques d’intégration avant d’ajouter progressivement des procédures de conformité, des documents d’audit, des directives anti-fraude, des manuels produits, de la correspondance avec les clients et des notifications réglementaires. Une requête qui auparavant sélectionnait parmi dix documents hautement pertinents doit désormais concurrencer des milliers de documents partiellement liés. Le système de récupération peut encore afficher du contenu dont le ton est similaire sans fournir celui qui est le plus utile, et c’est souvent le premier signe que la qualité de la récupération a décliné avec l’augmentation de la base de connaissances.

Évaluer la récupération indépendamment

Ensuite, évaluez le processus de récupération séparément du modèle de langage. Une erreur fréquente consiste à blâmer le LLM pour des réponses de mauvaise qualité lorsque c’est le système de récupération qui n’a jamais fourni le contexte adéquat. Des métriques telles que Recall@K et Precision@K permettent de trancher rapidement : si le document correct n’apparaît pas parmi les résultats principaux, le modèle n’a jamais eu de chance. Souvent, c’est le pipeline de récupération lui-même qui nécessite des améliorations.

Une cause fréquente est le dérive des embeddings. Un modèle d’embeddings qui fonctionnait bien avec un petit ensemble de données peut rencontrer des difficultés lorsque les documents deviennent plus diversifiés, car différents types, styles d’écriture et vocabulaires sectoriels affaiblissent progressivement son efficacité. La base de connaissances d’une banque peut mélanger des politiques émises par les équipes de conformité, des manuels produits par les équipes commerciales et des spécifications fournies par les ingénieurs. Tout cela appartient à une même organisation, mais le langage utilisé varie beaucoup ; si les embeddings ne capturent pas ces différences, la qualité diminue.

Les stratégies de segmentation peuvent également devenir obsolètes. Une méthode qui a fonctionné pour des centaines de documents peut échouer avec des centaines de milliers, car des segments mal structurés ajoutent du bruit à la recherche de similarité et rendent plus difficile la découverte d’informations pertinentes. C’est pourquoi les systèmes RAG en environnement de production nécessitent une évaluation continue et non une mise en place unique.

Les requêtes réelles diffèrent des requêtes de test

Les modèles de requêtes méritent une attention particulière. Les tests de développement reposent sur des questions idéales, car les ingénieurs connaissent déjà les données. Les utilisateurs réels posent des questions vagues ou incomplètes et utilisent des termes absents de la base de connaissances. Un agent de service pourrait rechercher « règles de fermeture du compte premium », tandis que les documents officiels parlent de « procédures de résiliation des comptes clients à haute valeur ». Les gens comprennent immédiatement le lien, mais le système de récupération d’informations ne le fait pas toujours. Observer l’interaction des utilisateurs réels permet généralement de découvrir des faiblesses que les tests ne mettent jamais en évidence.

Découvrez l’intérieur du pipeline

L’observabilité de la récupération est une autre technique précieuse. Pour chaque requête en production, la visibilité doit couvrir :

• quels documents ont été récupérés
• la raison pour laquelle chacun a été sélectionné
• les scores de similarité
• le contexte final envoyé au LLM
• la réponse générée

Sans cela, le débogage relève du hasard. Avec cela, les traces permettent souvent de déterminer si le problème provient de la récupération, du réclassement, de la construction de l’instruction ou de la génération.

Au fur et à mesure que les données augmentent, des couches supplémentaires peuvent être ajoutées avant la recherche vectorielle, telles que des méthodes de récupération hybrides, des filtres de métadonnées, une classification des documents, des outils de réclassement ou des pipelines spécifiques à un domaine. Une question bancaire concernant les prêts immobiliers, par exemple, devrait rechercher dans des documents spécifiques aux prêts immobiliers avant d’explorer l’ensemble de la base de connaissances de l’entreprise. Restreindre l’espace de recherche améliore à la fois la précision et la qualité des réponses.

En résumé, les systèmes RAG de production sont des systèmes vivants qui évoluent avec leurs données. On ne doit pas supposer qu’une solution performante dès le premier jour restera également efficace six mois plus tard ; par conséquent, un suivi continu, une évaluation régulière et un reformation constant des composants de récupération sont essentiels pour maintenir une qualité optimale à grande échelle.

En bref

Lorsqu’un système fonctionne bien en phase de développement mais mal en production, il convient d’abord de séparer les problèmes de récupération de ceux de génération. Analysez les métriques de récupération, examinez les documents obtenus, vérifiez la qualité des embeddings, étudiez les schémas réels de requêtes et assurez une meilleure observabilité dans l’ensemble du processus. À mesure que le volume augmente, envisagez des recherches hybrides, un filtrage par métadonnées, un réclassement des résultats et une récupération adaptée au domaine afin de garantir que les résultats restent pertinents et précis.

Scénario trois : les bons documents, la mauvaise réponse

De nombreux ingénieurs pensent que, une fois la récupération des données fonctionnelle, le travail est terminé. L’un des scénarios les plus difficiles dans le cadre du RAG est justement l’inverse : le système trouve les documents corrects, mais le modèle donne malgré tout une réponse erronée. Cela est particulièrement frustrant, car l’instinct habituel de débogage porte directement sur la récupération des données, alors que le système de recherche peut très bien remplir sa fonction parfaitement. L’échec réside dans la manière dont le modèle traite et analyse ce contexte.

Imaginons un assistant à la conformité bancaire qui répond aux questions relatives à la lutte contre le blanchiment d’argent. Un utilisateur demande si un compte client peut rester actif en attendant la vérification KYC. La récupération des données fournit les documents réglementaires appropriés, et la règle pertinente se trouve dans le contexte. Pourtant, la réponse indique que le compte peut rester actif indéfiniment. Les informations nécessaires étaient bien présentes, mais le modèle n’a pas su les utiliser correctement.

Surcharge de contexte et problème de type « perdu au milieu »

L’une des causes est la surcharge de contexte. Plus les documents récupérés sont nombreux, plus le modèle doit en absorber, et tout n’a pas la même importance ; ainsi, des détails cruciaux peuvent se retrouver enfouis au milieu d’un prompt long. On parle souvent de ce phénomène de « perte dans le milieu » : les modèles ont tendance à se concentrer sur le matériel situé au début et à la fin du contexte, en négligeant ce qui se trouve au milieu. La bonne réponse peut littéralement se trouver dans le prompt et pourtant être ignorée.

La solution consiste à privilégier la qualité du contexte à sa quantité. Les équipes tentent souvent d’améliorer la précision en récupérant plus d’informations, mais davantage de contexte ne garantit pas nécessairement de meilleures réponses ; quelques passages de haute qualité suffisent souvent à surpasser une multitude de textes peu liés entre eux. Le réclassement s’avère utile dans ce cas, car il place en tête les passages les plus pertinents avant que le modèle ne les consulte. Fournir au modèle trois documents hautement pertinents accompagnés de preuves claires peut être plus efficace que dix documents modérément pertinents.

Des prompts exigeant un ancrage concret

La conception des prompts est également importante. Plutôt que de laisser le modèle répondre librement, il convient de lui indiquer de s’appuyer strictement sur le contexte récupéré et d’indiquer clairement qu’il n’y a pas suffisamment d’informations lorsque les éléments disponibles ne permettent pas de formuler une réponse. Cela réduit considérablement les raisonnements non étayés.

La génération basée sur des citations est également utile. Lorsque le modèle doit nommer des sections spécifiques ou des identifiants de documents, il est beaucoup plus facile de vérifier si une réponse s’appuie sur les éléments de preuve obtenus, ce qui est crucial dans des industries réglementées comme la banque où l’auditable et l’explicabilité sont des exigences.

Sources contradictoires

Vérifiez si les documents obtenus sont contradictoires. Les grandes organisations conservent souvent plusieurs versions de politiques, de procédures et de directives ; si la recherche renvoie à la fois des versions obsolètes et actuelles, le modèle peut ne pas savoir laquelle doit avoir la priorité. Le filtrage des métadonnées et la gestion des versions des documents deviennent alors essentiels.

L’objectif n’est pas seulement de récupérer des informations, mais aussi de s’assurer que le modèle puisse identifier, prioriser et raisonner à partir des éléments de preuve les plus pertinents parmi celles-ci. Un système RAG ne fonctionne correctement que lorsque la récupération d’informations et le raisonnement s’associent.

En bref

Lorsque les documents appropriés reviennent mais que la réponse reste incorrecte, observez comment le modèle utilise le contexte : surcharge, effets de type « perdu au milieu », sources contradictoires et manque de fondement solide. Les solutions à essayer incluent le réclassement des résultats, la réduction du contexte, des réponses citant leurs sources, des filtres de métadonnées, ainsi que des instructions obligeant le modèle à s’appuyer uniquement sur les éléments obtenus. Souvent, le problème ne réside pas du tout dans la récupération des informations mais dans la manière dont celles-ci sont utilisées.

Ce que les trois cas ont en commun

Construire un bon système RAG exige bien plus que de simplement relier une base de données vectorielle à un LLM. Les prototypes de preuve de concept ont souvent l’air impressionnants, mais les véritables défis apparaissent lorsque les systèmes entrent en production et doivent fonctionner de manière fiable à grande échelle. Dans ces trois cas, les fragments de contexte se dispersent dans de grands documents, la qualité de la récupération diminue à mesure que les répertoires s’agrandissent, et même avec les informations correctement récupérées, le modèle peut ne pas parvenir à en tirer des conclusions logiques.

Le thème récurrent est que la qualité de la récupération d’informations est tout aussi importante que les capacités du modèle. Même le LLM le plus avancé ne peut compenser l’absence de contexte, des blocs mal structurés, des stratégies de récupération insuffisantes ou des éléments irrelevants dans l’instruction ; améliorer l’architecture de récupération rapporte souvent plus que de simplement changer de modèle. Pour les ingénieurs, les architectes et les responsables techniques, ce qui distingue les systèmes de niveau production des démonstrations spectaculaires, c’est une conception réfléchie : un découpage cohérent des données, des pipelines de récupération solides, une ancrage dans le contexte, un réclassement des résultats et une évaluation continue. L’IA d’entreprise ne concerne pas seulement la génération de réponses ; il s’agit plutôt de générer des réponses pertinentes, fondées sur des données concrètes, explicables et fiables de manière constante.