Les systèmes RAG échouent sur des données réelles : le coupable est le retrieval, pas le modèle

Un pipeline RAG ressemble à de la magie : charger les documents, les découper en chunks, générer les embeddings, connecter une base de données vectorielle. Poser une question — le modèle répond avec confiance et en détail. Le montrer au client, il est impressionné. Mais ensuite commence le test réel sur des questions réelles, et il s'avère que le système rate la moitié d'entre elles.

Le Goulot d'Étranglement de RAG

Sur des questions réelles, le système répond souvent incorrectement. Il trouve le mauvais document entièrement, ou trouve le bon document mais extrait le mauvais chunk de texte, ou ne récupère rien de pertinent et le modèle hallucine avec assurance. Il semble que le problème soit dans le modèle. En réalité, c'est la récupération qui est fautive.

GPT-4 et Claude répondent parfaitement si on leur donne le bon contexte. Si le contexte est mauvais — l'hallucination est garantie, peu importe la qualité du modèle. Le modèle répond seulement aussi bien que le contexte qui lui est fourni.

Le problème n'est pas dans les modèles. Le problème est dans la récupération — dans la façon dont nous recherchons les chunks de documents pertinents de votre base de données. C'est le goulot d'étranglement par lequel passe tout le pipeline RAG. Si la récupération donne au modèle le mauvais contexte, tout le reste est du temps et de l'argent gaspillés.

"Le modèle répond seulement aussi bien que le contexte qui lui est fourni."

Quand la Récupération Échoue

La récupération peut échouer pour des dizaines de raisons. Voici les plus courantes:

• Chunking trop large ou trop petit. Un chunk de 512 mots peut capturer un contexte voisin au lieu du morceau nécessaire. Une question sur la politique de retour, le chunk contient la description d'un tableau de tailles
• Embeddings générés pour des données en anglais, mais la question est en russe. La distance sémantique entre le vecteur de la question et les vecteurs des documents est énorme, aucune correspondance
• La question est reformulée de telle sorte que le vecteur de son embedding ne correspond pas aux vecteurs de la base de données. Vous cherchez "retourner la commande", les documents contiennent "retour de produit" — sémantique différente
• Document pertinent trouvé 8ème sur 10, mais le modèle n'a reçu que les 5 premiers résultats. Le contexte nécessaire ne tombe tout simplement pas dans la fenêtre de visibilité
• Index rempli de doublons et de bruit. De nombreux chunks non pertinents poussent l'information correcte hors des résultats

Chacun de ces problèmes conduit au même résultat : le modèle hallucine au lieu de donner la bonne réponse.

Le Coût de la Récupération

L'optimisation de la récupération n'est pas un hobby pour les enthousiastes. C'est du travail réel : une ou deux semaines qu'un développeur passe sur l'analyse révéleront que le système est 30-40% en dessous de la précision attendue. La raison n'est pas le modèle, mais que la récupération recherche incorrectement. Sur des projets réels, c'est une perte énorme : du temps dépensé sur RAG, de l'argent dépensé en infrastructure, et le système ne fonctionne pas parce que les vecteurs des documents ne correspondent pas aux vecteurs des questions.

Ce Que Cela Signifie

RAG ne fonctionne que si la récupération fonctionne. Sans elle, même le meilleur modèle se trompera. Cela signifie qu'avant de lancer RAG en production, vous devez investir un temps sérieux dans l'optimisation de la recherche, les tests sur des données réelles, et l'amélioration itérative du pipeline de récupération.