RAG в enterprise: почему 80% проблем в данных, а не в модели

Un prototype RAG est construit en une semaine et démontré. C'est magique : le modèle répond aux questions sur vos documents sans halluciner avec des connaissances générales. Mais après quelques semaines en production, le système commence à confondre les versions, perd le contexte et fournit avec confiance des réponses de sources inexistantes. C'est le chemin typique pour la plupart des systèmes RAG d'entreprise. Et le coupable ici n'est pas le transformer, mais les données et l'architecture.

Où le RAG Échoue

En passant du prototype à la production, une vérité désagréable émerge : 70-80 % des problèmes de RAG sont liés à la gestion des données, l'indexation et la recherche, pas aux capacités du modèle de langue lui-même. Peu importe la qualité de GPT-4 ou Claude, si les données sont mal indexées, le système fournira des réponses incorrectes. Cela devient particulièrement apparent lors de la mise à l'échelle du RAG de 100 à 10 000 documents.

Voici les véritables raisons pour lesquelles le RAG échoue dans les entreprises :

• Confusion de version de documents — les anciennes versions restent dans l'index, le système ne sait pas quel document est courant. Les utilisateurs obtiennent des réponses basées sur les réglementations d'il y a deux ans.
• Perte de contexte — le système ne se souvient pas de ce qui a été discuté dans les messages de chat précédents, se répète ou se contredit.
• Chunking déficient — les documents sont divisés par taille plutôt que par signification. La logique se désagrège entre les chunks, le système manque les connexions.
• Absence de reranking — BM25 entraîne beaucoup de bruit, le système ne peut pas distinguer les documents pertinents des correspondances aléatoires de mots-clés.
• Embeddings de faible qualité — les vecteurs sont entraînés sur un corpus général mais ne comprennent pas votre terminologie spécifique au domaine.
• Pas de boucle de rétroaction — personne ne suit les réponses incorrectes, le système n'apprend pas de ses erreurs.

Comment Construire RAG Correctement

Chez AlpinaGPT, nous avons travaillé en arrière : d'abord nous avons rassemblé les exigences d'un système idéal, puis identifié les problèmes spécifiques qui les bloquent. Le résultat est une architecture qui a réussi les tests réels avec les clients d'entreprise. Voici les composants clés :

• Chunking sémantique — nous divisons par structure de document, en-têtes et blocs sémantiques plutôt que par taille. Cela empêche le contexte de se fragmenter entre les chunks.
• Versioning des données — chaque version du document est indexée séparément avec un horodatage. Le système sait quel document est courant.
• Recherche en deux étapes — d'abord, BM25 rapide (mots-clés), puis reranking neural (sémantique). C'est moins cher que de tout chercher via des embeddings.
• Contexte entre messages — le système se souvient de l'historique complet du chat et ne répète pas ce qui a déjà été expliqué à l'utilisateur.
• Retour d'information — nous suivons les réponses incorrectes et réentraînons le ranker sur ces exemples.
• Index séparés par type — les réglementations, instructions, FAQs et code sont indexés différemment.

Ce Que Cela Signifie

Le RAG de l'avenir n'est pas seulement des embeddings et la recherche vectorielle. C'est la gestion des versions de documents, le chunking sémantique approprié, la recherche multi-étapes et les retours continus. Si la moitié de vos réponses RAG sont incorrectes, le problème n'est presque certainement pas le modèle GPT-4 ou Claude. Le problème est la façon dont vous préparez vos données, comment vous les divisez, comment vous les indexez et comment vous collectez les retours. Réfléchissez à tout ce pipeline — et la qualité bondit. Ceci est ce que nous avons appris d'AlpinaGPT.