Le RAG (Retrieval-Augmented Generation) est devenu l'architecture de référence pour connecter un LLM à des données d'entreprise. Le principe est simple : au lieu de fine-tuner un modèle, on lui fournit le contexte pertinent au moment de la requête. En théorie, c'est élégant. En pratique, la majorité des projets RAG restent bloqués au stade du PoC.
Voici les 5 pièges que nous rencontrons le plus fréquemment chez nos clients, et comment les éviter.
1. Le chunking naïf
Le découpage des documents en blocs de taille fixe (500 tokens, 1000 tokens) est la première approche que tout le monde teste. Elle fonctionne sur des démos, mais s'écroule sur des documents métier complexes.
Le problème : un contrat de 50 pages découpé en blocs de 500 tokens perd toute cohérence sémantique. Une clause qui référence un article précédent se retrouve isolée de son contexte.
La solution : adoptez un chunking sémantique. Utilisez la structure du document (titres, sections, paragraphes) comme frontières naturelles. Pour les documents non structurés, des modèles de segmentation comme ceux proposés par LangChain ou LlamaIndex offrent des résultats nettement supérieurs.
2. Ignorer la qualité des embeddings
Beaucoup de projets utilisent un modèle d'embedding générique (comme text-embedding-ada-002) sans se poser la question de sa pertinence pour le domaine métier concerné.
Un embedding entraîné sur du texte généraliste ne capturera pas les nuances d'un vocabulaire juridique, médical ou financier. Deux solutions :
- Fine-tuner l'embedding sur un corpus représentatif de vos documents
- Utiliser un re-ranker après la recherche vectorielle pour affiner la pertinence
Dans nos déploiements, l'ajout d'un re-ranker améliore la précision du retrieval de 20 à 35% sans toucher au reste de la chaîne.
3. Négliger l'évaluation continue
Un système RAG n'est pas un modèle qu'on entraîne une fois. C'est un pipeline vivant dont la qualité dépend de la fraîcheur des données, de la pertinence du retrieval et de la justesse des réponses générées.
Métriques essentielles à monitorer :
- Retrieval precision : le contexte remonté est-il pertinent ?
- Faithfulness : la réponse est-elle fidèle au contexte fourni ?
- Answer relevancy : la réponse répond-elle à la question posée ?
Des frameworks comme RAGAS permettent d'automatiser ces évaluations et de détecter les dérives avant qu'elles n'impactent les utilisateurs.
4. Sous-estimer l'ingénierie des prompts
Le prompt système qui encadre les réponses du LLM est souvent traité comme un détail. C'est une erreur. Un prompt mal conçu génère des hallucinations, des réponses hors sujet ou des formats inconsistants.
Bonnes pratiques :
- Définir explicitement le rôle du modèle et le périmètre de ses réponses
- Instruire le modèle de citer ses sources
- Prévoir une réponse par défaut quand le contexte est insuffisant (« Je ne dispose pas de cette information »)
- Versionner les prompts comme du code
5. Oublier la gouvernance des données
Le RAG connecte un LLM à vos données internes. Cela soulève immédiatement des questions de contrôle d'accès, de confidentialité et de fraîcheur.
Si un collaborateur junior peut interroger le système et obtenir des informations auxquelles il n'a normalement pas accès, c'est un problème de sécurité majeur. La couche de retrieval doit respecter les permissions existantes de votre système documentaire.
Ce que nous recommandons
Chez Bomzai, nous déployons des architectures RAG en production avec une approche itérative :
- Phase 1 : PoC rapide sur un périmètre restreint (1 source, 1 use case)
- Phase 2 : industrialisation avec monitoring, évaluation et CI/CD
- Phase 3 : extension progressive à d'autres sources et use cases
Cette approche permet de livrer de la valeur dès 30 jours tout en construisant des fondations solides pour le passage à l'échelle.