RAG en entreprise : 80 % des problèmes viennent des données, pas du modèle

Un prototype RAG se monte en une semaine et se montre en démo. Cela semble magique : le modèle répond à partir de vos documents et n'hallucine pas à partir de connaissances générales. Mais quelques semaines après la mise en production, le système se met à confondre les versions, perd le contexte et fournit avec aplomb des réponses tirées de sources qui n'existent pas. C'est le parcours typique de la plupart des RAG d'entreprise. Et le coupable n'est pas le transformer, mais les données et l'architecture.

Où le RAG casse

Quand on passe du prototype à la production, une vérité désagréable apparaît : 70 à 80 % des problèmes du RAG relèvent de la gestion des données, de l'indexation et de la recherche, et non des capacités du modèle de langage lui-même. Aussi bon que soit GPT-4 ou Claude, si les données sont mal indexées, le système donnera de mauvaises réponses. Cela saute aux yeux surtout quand on passe de 100 à 10 000 documents.

Voici les vraies raisons pour lesquelles le RAG échoue en entreprise :

• Confusion entre versions de documents : les anciennes versions restent dans l'index et le système ne sait pas laquelle est à jour. L'utilisateur reçoit une réponse fondée sur un règlement vieux de deux ans.
• Perte de contexte : le système ne se souvient pas de ce qui a été dit plus tôt dans le chat, se répète ou se contredit.
• Chunking défaillant : les documents sont découpés selon la taille et non selon le sens. La logique s'effrite entre les morceaux et le système ne voit pas les liens.
• Absence de reranking : BM25 ramène beaucoup de bruit et le système ne distingue pas les documents pertinents d'une simple coïncidence de mot.
• Embeddings de mauvaise qualité : les vecteurs sont entraînés sur un corpus généraliste et ne comprennent ni votre spécificité ni votre terminologie.
• Absence de boucle de feedback : personne ne suit les mauvaises réponses, le système n'apprend pas de ses erreurs.

Comment construire un RAG correct

Chez AlpinaGPT, nous avons raisonné à l'envers : nous avons d'abord recueilli les exigences d'un système idéal, puis examiné quels problèmes précis les bloquaient. Le résultat est une architecture éprouvée auprès de clients d'entreprise. Voici les composants clés :

• Chunking par le sens : nous découpons selon la structure du document, les titres et les blocs sémantiques, et non selon la taille. Le contexte ne s'effrite donc pas entre les morceaux.
• Versionnage des données : chaque version d'un document est indexée séparément avec une date. Le système sait quel document est à jour.
• Recherche en deux étapes : d'abord un BM25 rapide (mots-clés), puis un reranking par réseau de neurones (sémantique). C'est moins cher que de tout chercher via les embeddings.
• Contexte entre les messages : le système se souvient de tout l'historique du chat et ne répète pas ce qui a déjà été expliqué à l'utilisateur.
• Feedback : nous suivons les mauvaises réponses et réentraînons le ranker sur ces exemples.
• Index distincts par type : règlements, instructions, FAQ et code sont indexés différemment.

Ce que cela signifie

Le RAG de demain, ce n'est pas seulement des embeddings et une recherche vectorielle. C'est la gestion du versionnage des documents, un découpage sémantique correct, une recherche en plusieurs étapes et un feedback permanent. Si la moitié des réponses de votre RAG sont fausses, le problème ne vient presque certainement pas du modèle GPT-4 ou Claude. Il vient de la façon dont vous préparez les données, dont vous les découpez, dont vous les indexez et dont vous collectez le feedback. Revoyez tout ce pipeline et la qualité fait un bond. C'est ce que nous avons appris avec AlpinaGPT.