RAG en production : les 5 erreurs que j'ai vues partout

Le RAG marche mieux quand on arrête de le vendre comme magique

J'ai vu beaucoup de systèmes RAG promettre la même chose : brancher les documents de l'entreprise à un LLM et obtenir un assistant fiable, contextualisé. La démo est souvent convaincante. On pose trois questions préparées, le système retrouve le bon PDF, cite une phrase pertinente, et tout le monde voit le potentiel. Le problème commence avec des utilisateurs réels, des documents hétérogènes, des permissions imparfaites, des coûts qui montent et des réponses qui doivent être défendables.

Le RAG n'est pas un produit. C'est une architecture pour réduire l'hallucination et injecter du contexte. En production, sa qualité dépend de décisions concrètes : découpage des sources, sélection des passages, mesure des erreurs, questions refusées, et budget temps/coût par réponse. Les équipes qui l'acceptent construisent des systèmes utiles. Les autres découvrent tard que leur assistant est surtout un moteur de recherche flou avec une belle interface.

Erreur 1 : découper les documents sans stratégie

La première erreur est presque toujours le chunking. Beaucoup d'équipes découpent chaque document en blocs fixes, ajoutent un overlap, indexent le tout, puis passent à autre chose. C'est rassurant parce que c'est simple à automatiser. C'est aussi une manière efficace de casser le sens. Une clause coupée en deux, une procédure séparée de ses exceptions, un tableau détaché de son titre, ou une FAQ mélangée à un pied de page peuvent suffire à produire une réponse incomplète mais confiante.

La bonne question n'est pas quelle taille de chunk choisir. La bonne question est quelle unité porte le sens pour ce corpus. Dans une documentation produit, ce peut être une section avec son titre et sa version. Dans des contrats, une clause complète avec ses définitions. Dans des tickets support, le couple problème, diagnostic, résolution. Le chunking doit respecter la structure métier avant la limite de tokens.

Le correctif est concret : plusieurs stratégies de découpage par type de source, des métadonnées utiles, le chemin vers le document original, et des tests de récupération sur de vraies questions. Je préfère un pipeline vérifiable, plutôt qu'un index énorme où personne ne sait pourquoi tel fragment arrive en premier. Si l'équipe ne peut pas expliquer pourquoi le bon contexte devrait être récupéré, elle espère.

Erreur 2 : croire que la recherche vectorielle suffit

La deuxième erreur consiste à s'arrêter au top k de la recherche vectorielle. Les embeddings sont puissants, mais ils ne comprennent pas toujours la différence entre un passage vaguement proche et le passage décisif. Ils peuvent favoriser une formulation similaire, ignorer une contrainte récente, ou remonter cinq extraits redondants d'un même document alors qu'il manque l'exception importante située ailleurs. En production, cette nuance est exactement là que les erreurs coûteuses apparaissent.

Le correctif est d'ajouter une étape de reranking et, souvent, une recherche hybride. La recherche lexicale attrape les identifiants, les noms de produits, les codes internes et les termes rares. Le reranker relit les candidats et les ordonne selon la question précise. On peut aussi dédupliquer par source, pénaliser les documents obsolètes, filtrer par permission, ou imposer une fraîcheur minimale. Ce n'est pas du luxe. C'est souvent la différence entre une réponse qui a l'air correcte et une réponse qui utilise réellement la bonne preuve.

Erreur 3 : lancer sans pipeline d'évaluation

La troisième erreur est la plus dangereuse : ne pas savoir si le système s'améliore. Les équipes testent quelques questions dans l'interface, corrigent un prompt, changent le nombre de chunks, remplacent le modèle, puis jugent au feeling. Cela peut suffire pour une démo. En production, c'est ingérable. Chaque changement peut améliorer une famille de questions et dégrader silencieusement une autre. Sans évaluation, le RAG devient une boîte noire que personne n'ose modifier.

Une évaluation RAG utile doit séparer au moins trois choses : la récupération, la génération, et l'expérience utilisateur. Est-ce que le bon document apparaît dans les candidats ? Est-ce que le passage envoyé au modèle contient réellement la réponse ? Est-ce que la réponse finale respecte les sources, cite correctement, refuse quand le contexte est insuffisant, et reste utile pour le métier ? Ces dimensions ne se mesurent pas avec une seule note magique.

Le correctif commence petit. Créez un set de 50 à 100 questions réelles, avec sources attendues, réponses acceptables, refus attendus et cas pièges. Rejouez ce set à chaque modification importante. Loggez les passages récupérés, le rang du bon passage, les tokens, la latence, le modèle, le prompt et le feedback. Ajoutez des juges LLM seulement là où ils sont vérifiés par des exemples humains. L'évaluation n'est pas une couche administrative. C'est le volant du système.

Erreur 4 : utiliser le RAG comme solution universelle

La quatrième erreur est stratégique : traiter le RAG comme une réponse à tous les problèmes LLM. Un système RAG ne résout pas une mauvaise définition du workflow, une donnée source contradictoire, une politique de permission floue, ou une décision métier qui devrait rester humaine. Il donne du contexte au modèle. Il ne transforme pas automatiquement ce contexte en décision sûre, traçable et acceptable pour l'organisation.

Le correctif est de réduire la promesse. Définissez les tâches que le RAG doit faire très bien, celles où il doit aider sans décider, et celles qu'il doit refuser. Pour certaines tâches, une extraction structurée, une règle métier, une base SQL, une recherche classique ou un formulaire bien conçu fera mieux qu'un RAG conversationnel. Les meilleurs systèmes que j'ai vus ne cherchent pas à tout couvrir. Ils combinent retrieval, règles, validations humaines, outils métier et refus explicites. C'est moins spectaculaire. C'est beaucoup plus fiable.

Erreur 5 : oublier le budget latence et coût

La cinquième erreur arrive souvent trop tard, quand les utilisateurs commencent vraiment à s'en servir. Un RAG sérieux peut faire beaucoup d'opérations avant de répondre : réécriture de requête, recherche hybride, reranking, filtrage par permission, génération, citations, parfois vérification finale. Chaque étape ajoute latence, tokens, infrastructure et points de panne. Sans budget clair, le produit devient lent ou cher exactement au moment où il prouve son intérêt.

Le correctif est de budgéter dès le design. Quelle latence p95 est acceptable pour ce cas d'usage ? Combien de documents peut-on relire avant que le coût ne dépasse la valeur de la réponse ? Quels chemins doivent être rapides et approximatifs, et lesquels peuvent être plus lents parce que le risque est élevé ? Mesurez par étape, mettez en cache ce qui peut l'être, choisissez des modèles différents selon la tâche, et prévoyez un mode dégradé. La performance n'est pas seulement une optimisation. Dans un RAG, elle façonne le produit.

Checklist de readiness RAG

Avant de mettre un RAG en production, je veux pouvoir répondre clairement à ces questions. Quels corpus sont inclus, exclus et propriétaires ? Quelle unité de chunking respecte le sens de chaque source ? Quelles métadonnées filtrent la langue, la version, la fraîcheur, le droit d'accès et le type de document ? Quel mix entre recherche vectorielle, recherche lexicale et reranking est utilisé ? Quels cas doivent refuser de répondre ? Quels logs permettent de rejouer une mauvaise réponse ?

Je veux aussi un minimum d'évaluation et d'exploitation : un set de questions réelles, des sources attendues, des tests de régression, un suivi de latence, un suivi de coût, des exemples de réponses dangereuses, une procédure de correction de l'index, et un propriétaire métier capable d'arbitrer les ambiguïtés. Si ces éléments existent, le RAG peut devenir un vrai produit. S'ils n'existent pas, on peut quand même faire une démo. Mais il faut être honnête : la production n'a pas encore commencé.