RAG en production : les erreurs que l'on retrouve dans presque tous les systèmes d'entreprise

La génération augmentée par récupération (RAG) est la façon par défaut dont les entreprises mettent les grands modèles de langage au travail, et pour une bonne raison : elle ancre le modèle dans vos propres documents plutôt que dans ses données d'entraînement, sans le coût et la fragilité du fine-tuning. L'architecture est assez simple pour prototyper en une après-midi. C'est précisément pourquoi tant de systèmes RAG en production sont discrètement médiocres — la version facile fonctionne assez bien en démo pour cacher ce qui ne survit pas au contact des vrais utilisateurs.

Quand on nous appelle pour réparer un système RAG qui « fonctionne à peu près mais que personne ne fait confiance », le problème n'est presque jamais le modèle. C'est la récupération. Voici ce que nous trouvons systématiquement.

Le chunking est naïf

La plupart des systèmes découpent les documents en fenêtres de taille fixe — 500 tokens, un peu de chevauchement, et on passe à la suite. C'est correct pour de la prose uniforme et discrètement désastreux pour les documents que les entreprises ont réellement : des contrats où le sens d'une clause dépend d'une définition trois pages plus tôt, des tableaux qui perdent tout sens quand ils sont coupés au milieu d'une ligne, des spécifications techniques où le titre est la seule chose qui désambiguïse le paragraphe en dessous. Le chunking de taille fixe traite la structure comme du bruit. La correction consiste à découper selon les vraies frontières du document — sections, clauses, lignes de tableau conservées entières — et à transporter suffisamment de contexte dans chaque chunk pour qu'il puisse se tenir seul quand il est récupéré hors ordre.

Il n'y a pas de reranking

Un nombre surprenant de systèmes en production récupèrent les top-k chunks par similarité vectorielle et les envoient directement au modèle. La similarité vectorielle est un instrument grossier ; elle est bonne pour « à peu près sur le même sujet » et mauvaise pour « répond réellement à cette question spécifique ». Sans étape de reranking — un cross-encoder ou un modèle de rerank dédié qui score chaque candidat par rapport à la vraie requête — vous demandez au LLM de trouver l'aiguille pendant que vous lui donnez toute la meule de foin, mal classée. Ajouter du reranking est souvent le changement le plus impactant disponible, et c'est quelques heures de travail.

Personne ne mesure la pertinence

C'est celle qui compte le plus et qui se fait le moins. Les équipes mesurent si le système répond ; elles ne mesurent pas s'il a récupéré la bonne chose. Donc quand les réponses sont fausses, il n'y a pas moyen de savoir si la récupération a raté le chunk pertinent, ou si elle l'a récupéré et que le modèle l'a ignoré, ou s'il n'y avait pas de chunk pertinent à trouver. Ce sont trois bugs complètement différents avec trois corrections différentes, et sans un ensemble d'évaluation de pertinence vous devinez. Construisez un ensemble étiqueté de vraies questions avec des sources correctes connues, et mesurez la précision et le rappel de la récupération comme métrique de premier plan.

La récupération s'exécute même quand elle ne devrait pas

Toutes les requêtes n'ont pas besoin de la base de connaissances. « Résume le document que je viens de coller » non ; « quelle est notre politique sur X » oui. Les systèmes qui récupèrent inconditionnellement polluent le contexte avec des chunks non pertinents précisément sur les requêtes qui n'en avaient pas besoin. Une étape de routage légère — cette requête a-t-elle besoin de récupération, et depuis quel corpus — se paie d'elle-même.

La fenêtre de contexte est traitée comme gratuite

Ce n'est pas le cas. Bourrer vingt chunks dans le prompt parce qu'ils tiennent n'améliore pas les réponses ; au-delà d'un certain point, ça les dégrade, car le passage pertinent est enfoui parmi les plausibles. Moins de chunks, mieux classés, bat plus de chunks — chaque fois que nous l'avons mesuré.

Le fil conducteur de tout cela

Dans un système RAG en production, la qualité de la récupération fixe le plafond et le modèle ne détermine que jusqu'où on s'en approche. Les équipes dépensent leur énergie sur le prompt engineering et la sélection du modèle — les boutons visibles — pendant que la vraie contrainte se trouve en amont, dans la façon dont les documents sont découpés, scorés et sélectionnés. Passer à un meilleur modèle ne corrige presque jamais un problème de récupération. Il rend juste les mauvais chunks plus confiants.

Pour les environnements régulés, il y a une couche supplémentaire — chaque récupération et chaque réponse doivent être traçables et auditables, ce qui est son propre problème d'ingénierie — mais la fondation est la même : bien faire la récupération, la mesurer honnêtement, et la plupart des plaintes « l'IA est peu fiable » disparaissent.