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

Un prototipo de RAG se construye en una semana y se demuestra. Se ve mágico: el modelo responde preguntas sobre sus documentos sin alucinar con conocimiento general. Pero en un par de semanas en producción, el sistema comienza a confundir versiones, pierde contexto y proporciona con confianza respuestas de fuentes inexistentes. Este es el camino típico para la mayoría de los sistemas RAG empresariales. Y el culpable aquí no es el transformer, sino los datos y la arquitectura.

Dónde Falla el RAG

Al escalar de un prototipo a la producción, surge una verdad desagradable: el 70-80% de los problemas de RAG están relacionados con la gestión de datos, la indexación y la búsqueda, no con las capacidades del modelo de lenguaje mismo. No importa cuán buenos sean GPT-4 o Claude, si los datos están mal indexados, el sistema proporcionará respuestas incorrectas. Esto se vuelve especialmente evidente al escalar RAG de 100 a 10.000 documentos.

Aquí están las razones reales por las que falla el RAG en las empresas:

• Confusión de versión de documentos — las versiones antiguas permanecen en el índice, el sistema no sabe cuál documento es actual. Los usuarios obtienen respuestas basadas en regulaciones de hace dos años.
• Pérdida de contexto — el sistema no recuerda lo que se discutió en mensajes de chat anteriores, se repite a sí mismo o se contradice.
• Fragmentación deficiente — los documentos se dividen por tamaño en lugar de por significado. La lógica se desmorona entre fragmentos, el sistema pierde conexiones.
• Falta de reranking — BM25 trae mucho ruido, el sistema no puede distinguir documentos relevantes de coincidencias de palabras clave aleatorias.
• Embeddings de baja calidad — los vectores se entrenan en un corpus general pero no comprenden su terminología específica del dominio.
• Sin ciclo de retroalimentación — nadie rastrea respuestas incorrectas, el sistema no aprende de los errores.

Cómo Construir RAG Correctamente

En AlpinaGPT, trabajamos al revés: primero recopilamos los requisitos de un sistema ideal, luego identificamos los problemas específicos que los bloquean. El resultado es una arquitectura que ha superado las pruebas reales con clientes corporativos. Aquí están los componentes clave:

• Chunking semántico — dividimos por estructura de documento, títulos y bloques semánticos en lugar de por tamaño. Esto evita que el contexto se fragmente entre fragmentos.
• Versionamiento de datos — cada versión del documento se indexa por separado con una marca de fecha. El sistema sabe cuál documento es actual.
• Búsqueda en dos etapas — primero, BM25 rápido (palabras clave), luego reranking neural (semántica). Esto es más económico que buscar todo a través de embeddings.
• Contexto entre mensajes — el sistema recuerda todo el historial de chat y no repite lo que ya fue explicado al usuario.
• Feedback — rastreamos respuestas incorrectas y reentrenamos el clasificador en estos ejemplos.
• Índices separados por tipo — las regulaciones, instrucciones, preguntas frecuentes y código se indexan de manera diferente.

Qué Significa Esto

El RAG del futuro no es solo embeddings y búsqueda vectorial. Es gestión de versión de documentos, chunking semántico adecuado, búsqueda multietapa y retroalimentación continua. Si la mitad de sus respuestas de RAG están mal, el problema casi con certeza no es el modelo GPT-4 o Claude. El problema es cómo prepara sus datos, cómo los divide, cómo los indexa y cómo recopila retroalimentación. Replantee todo este pipeline — y la calidad se dispara. Esto es lo que aprendimos de AlpinaGPT.