RAG en production : les 3 erreurs qu'on voit le plus
Sortir un prototype de recherche augmentée fonctionne en deux jours. Le mettre en production sérieuse, sur un corpus métier réel, demande d'éviter trois pièges récurrents. Voici les trois erreurs qui plombent la majorité des projets que nous reprenons en cadrage.
Erreur 1 — Le découpage naïf du corpus
L'instinct du développeur qui découvre le RAG : prendre tous les documents, les couper en blocs de 500 ou 1000 tokens, indexer le tout, et appeler ça un système de recherche.
Résultat typique : les requêtes utilisateur retournent des passages qui contiennent les mots-clés mais perdent le contexte. Une section démarre au milieu d'une explication technique, une définition est coupée en deux, un tableau perd ses en-têtes.
Ce qui marche mieux :
- Découpage respectant la structure logique (sections, titres, paragraphes)
- Conservation des en-têtes parents dans chaque passage indexé (contexte hiérarchique)
- Découpage sémantique : grouper les phrases qui parlent d'un même sujet plutôt que d'imposer une taille fixe
- Stratégie spécifique aux tableaux, listes, code (ne pas les couper)
Un découpage soigné peut faire passer la précision de 60 à 85 % sur un même corpus, à modèle d'embeddings équivalent. C'est l'investissement avec le meilleur rendement.
Erreur 2 — L'absence de jeu d'évaluation
« Ça a l'air de marcher quand je teste » : la pire phrase à entendre sur un projet RAG en production. Sans jeu d'évaluation systématique, vous naviguez à l'aveugle.
Chaque modification (changement de modèle d'embeddings, nouveau découpage, mise à jour du prompt système) peut améliorer 70 % des cas et casser silencieusement les 30 % restants. Sans mesure, vous n'aurez aucun moyen de le savoir.
Ce qui marche :
- Construire un jeu de 50 à 200 requêtes typiques avec les équipes métier
- Pour chaque requête, valider quels passages doivent absolument apparaître dans le top-K
- Mesurer Recall@K et Precision@K à chaque modification
- Ajouter des requêtes adverses : mal formulées, hors-scope, ambiguës
- Rejouer le jeu à chaque modification, automatiquement
Construire un jeu d'évaluation prend 2 à 3 jours-homme au cadrage. C'est le meilleur investissement possible sur un projet RAG. Sans ce filet, tout déploiement en production est un pari.
Erreur 3 — Le pipeline non observable
Un système RAG en production fait beaucoup de choses : reçoit la requête, calcule un embedding, cherche dans une base vectorielle, optionnellement re-classe les résultats, construit un prompt, appelle un modèle de langage, formate la réponse, ajoute des citations.
Quand un utilisateur signale une mauvaise réponse, sans observabilité, vous ne pourrez jamais déterminer où le problème a eu lieu. Mauvais passages retournés ? Bon passage mais le modèle l'a ignoré ? Citation incorrecte ?
Ce qui marche :
- Logger chaque requête, les passages retournés, le prompt construit, la réponse, les citations
- Ajouter un identifiant unique par requête pour rejouer le pipeline
- Permettre aux utilisateurs de signaler une mauvaise réponse en un clic
- Constituer un dataset de cas problématiques à partir des signalements pour les rejouer après chaque modification
- Tableau de bord temps réel : latence, taux de réponses sourcées, signalements négatifs
L'observabilité ajoute environ 10 % de temps de développement initial. Elle économise 10x ce temps en debugging et en régressions évitées.
Erreur bonus — Optimiser sans mesurer
Beaucoup d'équipes passent des semaines à comparer des modèles d'embeddings, des stratégies de re-ranking, des prompts système, sans jeu d'évaluation. Résultat : elles choisissent ce qui « semble mieux » sur quelques requêtes favorites, qui ne représentent pas l'usage réel.
La séquence saine est inverse : (1) constituer le jeu d'évaluation, (2) déployer une version simple, (3) mesurer, (4) optimiser uniquement ce qui est validé par les chiffres.
Notre approche par défaut
Toutes nos missions RAG suivent la même séquence :
- Atelier cadrage : identifier le corpus, les cas d'usage prioritaires, les contraintes
- Construction du jeu d'évaluation avec vos équipes métier
- Architecture sobre : découpage soigné, observabilité dès la première version
- Itération mesurée : chaque optimisation validée par le jeu d'évaluation
- Déploiement progressif avec supervision continue
- Transfert : documentation, formation, remise du jeu d'évaluation à vos équipes
Pour aller plus loin
Si vous avez un système RAG en cours qui rame ou qui ne donne pas satisfaction, on peut faire un audit rapide en 30 minutes : projects@littlab.com.