RAG en péril : alternatives pour les modèles de langage

La montée en puissance et les limites de RAG

La génération augmentée par récupération (RAG) s'est imposée comme une méthode privilégiée pour lier des documents à des modèles de langage (LLM). Le processus est relativement simple : il s'agit d'intégrer un ensemble de données, de récupérer les segments les plus pertinents via la similarité vectorielle, puis de les intégrer dans une invite. Cette méthode fonctionne bien dans les démonstrations et dans certains systèmes de production. Cependant, elle présente des défaillances notables, surtout lorsqu'elle est déployée à grande échelle.

Les ingénieurs cherchent activement à comprendre ces échecs et à explorer des alternatives viables qui pourraient surmonter ces limitations.

Les failles de RAG en production

L'un des problèmes les plus courants avec RAG est l'irrélevance de la récupération. Par exemple, lorsqu'un utilisateur pose une question sur une politique de congé parental, le système peut renvoyer des versions de 2022 et 2024 ainsi qu'un article de blog culturel, simplement parce que ces documents partagent un vocabulaire similaire avec la requête. Aucun de ces documents ne répond réellement à la question posée.

Le modèle, ne pouvant discerner la pertinence contextuelle, mélange ces informations pour produire une réponse qui semble confiante mais qui est factuellement incorrecte. Ce phénomène de similarité thématique sans pertinence factuelle est un problème majeur dans les systèmes RAG en production.

Un autre problème est la contamination contextuelle. Dans les bases de connaissances d'entreprise, un même document peut exister en plusieurs versions. Si le système récupère des morceaux de différentes versions, le modèle peut soit choisir une version, soit mélanger les informations, produisant ainsi une réponse potentiellement incorrecte sans que ni l'utilisateur ni le modèle ne s'en rendent compte.

Le problème fondamental réside dans le conflit structurel du pipeline chunk-embed-retrieve. Pour une récupération efficace, il est nécessaire d'utiliser de petits morceaux, de l'ordre de 100 à 256 tokens. Cependant, pour une bonne compréhension contextuelle, des morceaux plus grands, de 1 024 tokens ou plus, sont nécessaires. Les concepteurs de RAG doivent donc faire un choix difficile entre ces deux exigences.

La tentation de la sur-ingénierie

Face aux performances décevantes de RAG, une solution courante est de complexifier le système : utiliser des intégrations de dimension plus élevée, un reranking plus sophistiqué, ou une récupération en plusieurs étapes. Cependant, cela ne fait qu'aggraver le problème.

Par exemple, une entreprise mondiale de fabrication a initialement budgété 400 000 $ pour son système RAG, mais a fini par dépenser 1,2 million de dollars la première année, avec une précision finale de seulement 23% sur les requêtes de documentation technique. Le projet a été annulé. De même, une entreprise de santé a vu ses coûts de base de données vectorielle atteindre 75 000 $ par mois en seulement six mois. Ces cas illustrent un schéma plus large : en 2025, les implémentations de RAG en entreprise ont échoué à 72% au cours de leur première année.

L'augmentation des dimensions d'intégration et l'utilisation de modèles vectoriels plus sophistiqués n'améliorent pas automatiquement les performances. Au contraire, elles augmentent les coûts de calcul et retardent la question cruciale : l'architecture de récupération est-elle vraiment la bonne solution ?

Explorer des alternatives viables

Long-Context Prompting

Une alternative directe à la sur-ingénierie d'un pipeline RAG défaillant est de supprimer complètement l'étape de récupération. Si le corpus peut être intégré dans la fenêtre de contexte du modèle, il suffit de le charger et de laisser le modèle traiter les informations. Des études ont montré que les LLM à long contexte surpassent systématiquement RAG dans les tâches de questions-réponses lorsque les ressources de calcul sont disponibles.

Cependant, le compromis en termes de coût est significatif. Avec 1 million de tokens, la latence est 30 à 60 fois plus lente qu'un pipeline RAG, et le coût par requête est environ 1 250 fois plus élevé. Toutefois, en utilisant la mise en cache des invites pour les applications à fort trafic, le long-contexte peut devenir économiquement viable.

Une règle de décision courante est la suivante : si le corpus tient dans la fenêtre de contexte et que le volume de requêtes est modéré, le long-context prompting est la meilleure option. La récupération ne doit être ajoutée que lorsque le corpus dépasse la fenêtre, que la latence ne respecte pas les objectifs de niveau de service (SLO), ou que le volume de requêtes dépasse le seuil de rentabilité.

Compression de mémoire

Lorsque le corpus est trop volumineux pour la fenêtre de contexte, une solution consiste à résumer les documents avant de les récupérer. La récupération basée sur le résumé compresse les documents avant de les injecter, plutôt que de récupérer des morceaux bruts. Les benchmarks montrent que cette approche est comparable aux méthodes de long-contexte complet, tandis que la récupération basée sur des morceaux est systématiquement inférieure aux deux.

Un exemple concret : une approche RAG utilisant 48 000 tokens bien choisis a surpassé la récupération en contexte complet avec 117 000 tokens de 13 points F1, tout en utilisant un septième du budget de tokens. Un document pertinent bien compressé est plus efficace qu'un déversement brut de morceaux tangentialement liés.

Récupération structurée

Lorsque la récupération est la bonne architecture, la solution consiste à router par type de requête plutôt que d'appliquer uniformément de meilleures intégrations.

Des recherches présentées à EMNLP 2024 ont introduit Self-Route, qui permet au modèle de classifier si une requête nécessite un contexte complet ou une récupération ciblée avant de l'exécuter. Les recherches factuelles simples sont dirigées vers un RAG ciblé, tandis que les questions complexes nécessitant une compréhension globale sont orientées vers un long contexte.

Le résultat est une meilleure précision globale à un coût computationnel inférieur. Les systèmes adaptatifs utilisant cette approche hybride ont montré des améliorations de précision de récupération de 15 à 30% grâce à une recherche hybride et un reranking.

Le changement clé est de rendre le routage explicite. Chaque requête est classifiée avant que toute récupération ne soit effectuée, et le système cesse de traiter toutes les requêtes comme des problèmes d'intégration identiques.

Raisonnement basé sur les graphes

Pour les requêtes nécessitant une compréhension des relations à travers un ensemble de données, plutôt que de récupérer un passage spécifique, la récupération vectorielle échoue par conception.

Ce sont les questions à multi-sauts : par exemple, quelles décisions le conseil a-t-il annulées au T3, et quelle était la raison déclarée à chaque fois ? Aucun morceau unique ne peut répondre à cela. La réponse réside dans les connexions entre les documents.

Microsoft Research a introduit GraphRAG en 2024. Ce système construit un graphe de connaissances à partir du corpus, puis explore les relations entre entités plutôt que de faire correspondre des vecteurs.

Cette approche aborde directement le cas d'échec que le RAG standard ne peut pas gérer : la synthèse à travers plusieurs documents nécessitant un raisonnement relationnel.

Le compromis est le coût. L'extraction de graphe de connaissances coûte 3 à 5 fois plus cher que le RAG de base et nécessite un réglage spécifique au domaine. GraphRAG est justifié pour l'analyse thématique et le raisonnement à multi-sauts, mais pas pour les recherches factuelles à passage unique.

Conclusion

RAG reste un choix par défaut raisonnable pour de nombreux cas d'utilisation, mais il présente des faiblesses prévisibles : l'irrélevance de la récupération lorsque le vocabulaire correspond mais que la sémantique diverge, la contamination contextuelle avec des versions contradictoires, et les limites structurelles lorsque la taille des morceaux ne peut satisfaire à la fois la récupération et la cohérence. Ajouter de la complexité à un design de récupération défaillant rend ces problèmes plus coûteux.

Quatre alternatives se distinguent selon la situation :

• Si le corpus tient dans la fenêtre de contexte, le long-context prompting évite complètement le problème de récupération.
• Si la compression de contexte est nécessaire, le résumé avant récupération surpasse la récupération brute par morceaux.
• Si les requêtes varient par type, le routage explicite avec la récupération structurée améliore à la fois la précision et le coût.
• Si les requêtes nécessitent une synthèse relationnelle à travers des documents, le raisonnement basé sur les graphes est la bonne architecture.

Adaptez l'architecture au type de requête pour optimiser les performances et les coûts.