Le Retrieval-Augmented Generation est devenu l'architecture par défaut pour les applications d'IA en entreprise. Demandez à n'importe quelle entreprise qui développe avec des LLM et elle construit probablement un système RAG.
Mais voici la vérité inconfortable : la plupart des systèmes RAG qui fonctionnent en démo échouent en production.
La démo récupère 3 documents pertinents d'un ensemble de test organisé. La production récupère 3 documents non pertinents parmi 10 millions de documents bruités. Le modèle hallucine. Les utilisateurs perdent confiance. Le projet échoue.
J'ai audité des dizaines de systèmes RAG en production. Les patterns d'échec sont remarquablement cohérents — et remarquablement corrigibles.
Le compromis fondamental
Chaque système RAG se situe sur un spectre entre précision et rappel :
Haute précision : Les documents récupérés sont hautement pertinents, mais vous pourriez en manquer de bons. Haut rappel : Vous capturez la plupart des documents pertinents, mais incluez des documents non pertinents.
Le LLM peut filtrer le contexte non pertinent dans une certaine mesure — mais au prix de la latence et de la précision. Le bon équilibre dépend de votre cas d'usage :
- Support client : Privilégiez la précision. Les mauvaises réponses détruisent la confiance.
- Recherche juridique : Privilégiez le rappel. Manquer un document pertinent est inacceptable.
- Q&A général : Équilibrez les deux. Les utilisateurs pardonnent l'imprécision occasionnelle.
Stratégies de découpage
La façon dont vous découpez les documents en chunks a un impact massif sur la qualité de la récupération. La tension fondamentale :
- Les chunks plus petits (100-256 tokens) correspondent plus précisément aux requêtes mais perdent le contexte environnant.
- Les chunks plus grands (1024+ tokens) préservent le contexte mais diluent la pertinence dans les embeddings.
Découpage récursif
L'approche généraliste la plus robuste. Commencez par des séparateurs de haut niveau (paragraphes, sections), puis découpez récursivement si les chunks restent trop grands. La recherche montre que le découpage récursif basé sur les tokens avec une taille de base de 100 tokens surpasse constamment les alternatives.
Découpage sémantique
Découpez en fonction du sens, pas de la structure. Analysez la similarité des phrases et créez des chunks là où les sujets changent. Préserve le sens mais nécessite un calcul d'embedding supplémentaire.
Méthodes sensibles à la structure
Pour les documents structurés (Markdown, HTML, PDF avec des en-têtes clairs), utilisez des découpeurs sensibles à la structure. C'est souvent la plus grande amélioration que vous pouvez faire — les en-têtes fournissent des frontières sémantiques naturelles.
Quand ne pas découper
Les petits documents focalisés qui répondent directement aux questions des utilisateurs peuvent ne pas avoir besoin de découpage du tout. Découper ces documents peut en fait nuire à la récupération.
Sélection des embeddings
Votre modèle d'embedding transforme le texte en vecteurs. La qualité de cette transformation détermine la qualité de la récupération.
Options généralistes
- OpenAI text-embedding-3-large : Performance solide, dépendance cloud
- Cohere embed-v3 : Force multilingue, qualité compétitive
- BGE-large-en-v1.5 : Open source, auto-hébergeable, excellente qualité
Fine-tuning spécifique au domaine
Pour les domaines spécialisés — juridique, médical, technique — le fine-tuning des embeddings sur des données de domaine peut améliorer considérablement la récupération. Même 10 000 exemples spécifiques au domaine peuvent améliorer significativement la performance.
Considérations multilingues
Si vos documents couvrent plusieurs langues, vous avez besoin d'embeddings multilingues. Des options comme les embeddings multilingues de Cohere ou BGE-M3 gèrent bien cela.
Stratégies de récupération
La recherche vectorielle seule ne suffit pas
La recherche sémantique est puissante mais a des angles morts. Elle peut manquer des correspondances exactes pour les noms, codes et termes rares. La recherche hybride — combinant la similarité vectorielle avec la correspondance par mots-clés BM25 — capture à la fois la pertinence sémantique et les correspondances exactes.
Reranking
La récupération initiale est rapide mais imprécise. Les modèles de reranking (Cohere Rerank, ColBERT) prennent les top-k résultats et les réordonnent par pertinence. C'est coûteux en calcul mais améliore significativement la précision.
Filtrage par métadonnées
Utilisez les métadonnées pour affiner la récupération avant la recherche sémantique. Si vous savez que l'utilisateur pose des questions sur les contrats 2024, filtrez d'abord sur les contrats 2024. Cela améliore la précision et réduit le calcul.
Architecture de production
Mise en cache
Mettez en cache les requêtes fréquentes. Si 100 utilisateurs posent des questions sur la politique de vacances, récupérez une fois. La stratégie d'invalidation du cache compte — équilibrez la fraîcheur par rapport au coût.
Traitement asynchrone
Pour les applications non temps réel, traitez la récupération de manière asynchrone. Mettez les requêtes en file d'attente, traitez par lots, retournez les résultats via callback.
Surveillance
Suivez tout :
- Latence des requêtes par percentile (p50, p95, p99)
- Pertinence de la récupération (si vous avez des signaux de feedback)
- Consommation de tokens par requête
- Taux de hit du cache
- Taux d'erreurs
Sans surveillance, vous ne pouvez pas optimiser.
Dégradation gracieuse
Que se passe-t-il quand la récupération échoue ? Quand l'API du LLM timeout ? Concevez des comportements de repli — réponses en cache, escalade humaine, messages d'erreur transparents.
Modes d'échec courants
Sur-récupération
Récupérer trop de chunks remplit la fenêtre de contexte d'informations marginalement pertinentes, diluant les bonnes. Commencez avec moins de chunks (3-5) et augmentez seulement si nécessaire.
Mauvais prétraitement des requêtes
Les requêtes utilisateur sont souvent ambiguës, mal orthographiées ou conversationnelles. Prétraitez les requêtes — développez les abréviations, corrigez l'orthographe, réécrivez sous forme de déclarations — avant la récupération.
Ignorer la qualité des documents
Le RAG récupère ce que vous mettez dedans. Si votre corpus de documents est plein de contenu obsolète, contradictoire ou mal écrit, votre système RAG le citera avec confiance. La curation des documents est souvent plus importante que l'optimisation de la récupération.
Approche unique pour tout
Différents types de requêtes bénéficient de stratégies différentes. Une recherche factuelle a besoin de précision. Une question exploratoire a besoin de largeur. Envisagez de router les requêtes vers différentes configurations de récupération.
Le chemin vers la production
Étape 1 : Construire un ensemble de données d'évaluation
Avant d'optimiser, sachez à quoi ressemble le succès. Construisez un ensemble de données de plus de 100 paires question-réponse avec des réponses correctes vérifiées par des humains. Exécutez chaque changement sur cet ensemble de données.
Étape 2 : Établir des métriques de référence
Mesurez la performance actuelle : précision, rappel, latence, coût. Vous ne pouvez pas améliorer ce que vous ne mesurez pas.
Étape 3 : Itérer systématiquement
Changez une chose à la fois. Mesurez l'impact. Gardez ce qui fonctionne, abandonnez ce qui ne fonctionne pas. Résistez à la tentation de tout changer en même temps.
Étape 4 : Surveiller en production
Les données de production diffèrent des données d'évaluation. Surveillez la qualité de la récupération en continu. Construisez des boucles de feedback pour identifier les échecs.
Étape 5 : Amélioration continue
Les systèmes RAG se dégradent au fil du temps à mesure que les corpus de documents évoluent. Planifiez une réindexation et une réévaluation régulières.
L'essentiel
Le RAG n'est pas un problème résolu. Construire des systèmes RAG qui fonctionnent de manière fiable à l'échelle de production nécessite une ingénierie soigneuse sur le découpage, l'embedding, la récupération et la surveillance.
La bonne nouvelle : les techniques sont bien comprises. Le travail difficile est de les appliquer systématiquement plutôt que d'espérer que la démo passe à l'échelle.
