RAG en la empresa: el 80% de los problemas está en los datos, no en el modelo

Un prototipo de RAG se monta en una semana y se enseña en una demo. Parece mágico: el modelo responde con tus documentos y no alucina a partir de conocimiento general. Pero a las pocas semanas en producción, el sistema empieza a confundir versiones, pierde contexto y da con total seguridad respuestas basadas en fuentes que no existen. Es el camino habitual de la mayoría de los RAG empresariales. Y el culpable no es el transformer, sino los datos y la arquitectura.

Dónde se rompe el RAG

Al escalar del prototipo a producción aparece una verdad incómoda: entre el 70 y el 80% de los problemas del RAG tienen que ver con la gestión de datos, la indexación y la búsqueda, no con las capacidades del propio modelo de lenguaje. Por bueno que sea GPT-4 o Claude, si los datos están mal indexados, el sistema dará respuestas incorrectas. Se nota sobre todo al pasar de 100 a 10 000 documentos.

Estas son las causas reales por las que el RAG falla en la empresa:

• Confusión de versiones de documentos: las versiones antiguas siguen en el índice y el sistema no sabe cuál es la vigente. El usuario recibe una respuesta basada en un reglamento de hace dos años.
• Pérdida de contexto: el sistema no recuerda lo que se habló antes en el chat, se repite o se contradice.
• Chunking deficiente: los documentos se trocean por tamaño y no por sentido. La lógica se desintegra entre fragmentos y el sistema no ve las relaciones.
• Falta de reranking: BM25 trae mucho ruido y el sistema no distingue los documentos relevantes de una coincidencia casual de palabras.
• Embeddings de baja calidad: los vectores se entrenan con un corpus general y no entienden vuestra especificidad ni vuestra terminología.
• Ausencia de ciclo de feedback: nadie hace seguimiento de las respuestas incorrectas y el sistema no aprende de sus errores.

Cómo se construye un RAG correcto

En AlpinaGPT fuimos al revés: primero reunimos los requisitos de un sistema ideal y luego vimos qué problemas concretos los bloqueaban. El resultado es una arquitectura probada en combate con clientes corporativos. Estos son los componentes clave:

• Chunking por sentido: troceamos según la estructura del documento, los encabezados y los bloques semánticos, no por tamaño. Así el contexto no se desintegra entre fragmentos.
• Versionado de datos: cada versión del documento se indexa por separado con una etiqueta de fecha. El sistema sabe cuál es el vigente.
• Búsqueda en dos etapas: primero BM25 rápido (palabras clave) y después reranking con una red neuronal (semántica). Es más barato que buscarlo todo con embeddings.
• Contexto entre mensajes: el sistema recuerda todo el historial del chat y no repite lo que ya se le explicó al usuario.
• Feedback: hacemos seguimiento de las respuestas incorrectas y reentrenamos el ranker con esos ejemplos.
• Índices separados por tipo: reglamentos, instrucciones, FAQ y código se indexan de forma distinta.

Qué significa esto

El RAG del futuro no es solo embeddings y búsqueda vectorial. Es gestión del versionado de documentos, un troceado semántico correcto, búsqueda en varias etapas y feedback constante. Si la mitad de las respuestas de tu RAG son incorrectas, casi seguro que el problema no está en el modelo GPT-4 o Claude. El problema está en cómo preparas los datos, cómo los troceas, cómo los indexas y cómo recoges el feedback. Revisa todo ese pipeline y la calidad se dispara. Esto es lo que aprendimos con AlpinaGPT.