RAG en Production : Pourquoi la Récupération Devient Lente_
Les goulets d'étranglement qui nuisent réellement aux systèmes RAG en production, du fractionnement et du trafic inter-régions au reranking et aux index obsolètes.
La plupart des démonstrations RAG sont rapides parce qu'elles évitent les parties qui rendent la récupération en production coûteuse.
L'ensemble de données est petit. Les morceaux sont propres. L'appel d'embedding est proche. L'index vectoriel est chaud. Il n'y a pas de filtres de permission, pas de stade de reranking, et pas besoin d'expliquer pourquoi un résultat a été sélectionné.
Les systèmes réels sont plus lents car la récupération n'est pas une étape unique. C'est un pipeline.
## Le Budget de Latence N'est Pas Juste une Recherche Vectorielle
Lorsqu'un utilisateur pose une question, un flux de récupération en production comprend souvent :
1. normalisation de la requête
2. génération d'embedding
3. filtrage des métadonnées
4. recherche vectorielle
5. recherche lexicale
6. reranking
7. assemblage du prompt
8. l'appel final au modèle
Les équipes blâment souvent la base de données vectorielle car c'est le composant le plus visible. En pratique, la partie la plus lente se trouve souvent ailleurs.
Le trafic inter-régions est un exemple courant. Si votre application fonctionne dans une région, votre fournisseur d'embedding est dans une autre, et votre magasin de vecteurs est dans une troisième, le système peut sembler lent même lorsque chaque composant individuel est "rapide" en isolation.
## La Qualité du Fractionnement Décide de la Qualité de Récupération
De mauvais morceaux produisent un mauvais rappel.
Un fractionneur naïf à largeur fixe va couper à travers les titres, les blocs de code, les tableaux et les paragraphes sans comprendre quoi que ce soit. Les embeddings résultants sont techniquement valables et sémantiquement faibles.
Si le contenu est structuré, fractionnez avec la structure :
- respect des titres Markdown
- conserver les blocs de code intacts
- préserver les titres de section avec leur contenu
- garder les métadonnées telles que l'ID du document, le chemin de section, la langue et la portée d'accès
Vous n'avez pas besoin d'un fractionneur parfait. Vous avez besoin d'un qui évite de briser clairement le sens du matériel source.
## La Récupération Hybride Est Généralement le Meilleur Par défaut
La récupération dense est bonne pour la similarité sémantique. La récupération lexicale est bonne pour les termes exacts, les ID, les noms de fichiers, les codes d'erreur et les noms de produits.
Les systèmes de production ont généralement besoin des deux.
Une forme pratique ressemble à ceci :
```ts
type RetrievalResult = {
id: string;
score: number;
source: "dense" | "lexical";
};
async function retrieve(query: string) {
const [dense, lexical] = await Promise.all([
vectorIndex.search(query),
bm25Index.search(query),
]);
return mergeAndDedupe([...dense, ...lexical]);
}
Cela ne rend pas le système plus simple, mais cela le rend généralement plus fiable.
Le Reranking Est Coûteux et Souvent Justifié
Les index de voisins les plus proches approximatifs optimisent la vitesse, pas le classement parfait. C'est acceptable pour la génération de candidats. Ce n'est souvent pas suffisant pour la phase de réponse finale.
Le reranking améliore la précision en prenant un ensemble de candidats plus petit et en évaluant chaque résultat par rapport à la requête réelle avec un modèle plus performant.
Le compromis est évident :
- meilleure pertinence
- plus de latence
- plus de coût
C'est pourquoi le reranking doit intervenir après la récupération, pas avant. Laissez le système rapide trouver des candidats. Laissez le système plus lent les affiner.
La Fraîcheur Est un Problème Systémique
Une grande partie de la frustration liée au RAG est en réalité un problème d'indexation.
La source de vérité change, mais l'index de récupération accuse un retard. Alors l'utilisateur obtient une réponse de morceaux obsolètes et l'équipe blâme le modèle de langage.
Traitez l'indexation comme son propre pipeline :
- capturer les changements de documents
- mettre en file d'attente le travail de ré-embedding
- insérer ou mettre à jour les nouveaux morceaux
- retirer ou marquer les morceaux obsolètes
- suivre la version de l'index ou la révision du document
Si vous passez cela, vous n'avez pas un système de récupération. Vous avez un instantané.
Les Filtres Changent la Forme du Problème
La recherche en entreprise signifie rarement "chercher partout". Cela signifie généralement "chercher uniquement ce que cet utilisateur est autorisé à voir".
Cela signifie que la conception des métadonnées compte presque autant que la qualité des embeddings.
Un morceau devrait généralement porter suffisamment de métadonnées pour soutenir :
- l'isolation des locataires
- les filtres par type de document
- les filtres par système source
- les fenêtres de fraîcheur
- la récupération consciente des permissions
C'est aussi à ce niveau que certains benchmarks de bases de données vectorielles deviennent moins utiles. Un benchmark sans filtres réels et contraintes d'accès ne ressemble pas à une charge de travail de production.
Une Meilleure Posture de Production
Si votre fonctionnalité RAG semble lente, vérifiez ces points avant de blâmer les embeddings :
- Les services sont-ils dans la même région ?
- Récupérez-vous trop de candidats ?
- Rerankez-vous trop de morceaux ?
- Les morceaux sont-ils structurellement valables ?
- L'index est-il frais ?
- Les permissions sont-elles appliquées dans la couche de récupération ?
La qualité RAG n'est pas seulement la qualité du modèle. C'est de l'ingénierie de récupération.
Lectures Complémentaires
Articles liés.
Poursuivez avec des articles proches sur le software engineering, l'architecture et les compromis d'implémentation.
La génération de code par l'IA change le travail plus qu'elle ne supprime l'ingénieur
Les LLM sont les plus efficaces pour l'accélération et l'échafaudage. Ils restent plus faibles en jugement, en architecture, et en responsabilité des conséquences de production.
L'UI générative s'améliore lorsque les modèles choisissent des composants, pas seulement du texte
Les interfaces pilotées par LLM deviennent plus utiles lorsqu'elles aident à choisir ou à configurer des composants UI fiables au lieu de toujours répondre par des paragraphes.