RAG no es la respuesta automática: cuándo prescindir de una arquitectura cara que nadie ha definido

El presupuesto llega antes que el problema

En enero, un cliente abrió una llamada con una frase que ya hemos oído varias veces: tenemos presupuesto aprobado para un sistema RAG. Le preguntamos qué preguntas debía responder ese sistema. Alguien repitió la frase del presupuesto. Nadie en la sala podía describir el problema, aunque todos podían describir la arquitectura.

Eso no es una anécdota aislada. Es un patrón. Y tiene consecuencias reales: proyectos que consumen meses de ingeniería para resolver algo que no era un problema de recuperación de información en absoluto.

Este artículo no es un obituario de RAG. Hemos lanzado más de una docena de estos sistemas y algunos funcionan exactamente bien. Un equipo de soporte que responde desde un conjunto estable y mantenido de documentación de producto es un uso perfectamente válido. RAG no está muerto, y quien te diga que lo está tiene algo más nuevo que vender. Lo que sí creemos es que no debería ser el movimiento automático cada vez que IA y documentos aparecen en la misma frase.

El verdadero problema casi nunca es de recuperación

Un cliente llegó queriendo incrustar 40.000 documentos en una base de datos vectorial. Antes de tocar ninguna infraestructura, hicimos algo aburrido: listar las 20 preguntas que los empleados realmente hacían a ese corpus. Más de la mitad eran preguntas estructuradas: totales de reembolsos, recuentos de empleados, fechas de contrato. Cosas que pertenecen a una consulta directa a base de datos, no a retrieval semántico.

Unos 50 documentos cubrían la mayoría del resto. Los otros 39.000 y pico eran borradores antiguos, versiones intermedias y políticas obsoletas que contradecían directamente las vigentes. Incrustar todo el corpus habría hecho que la respuesta equivocada llegara más rápido, con más confianza y con una cita de fuente que parecía legítima.

Lo que necesitaban era limpieza. Eso no aparece en ningún presupuesto de proyecto de IA.

Por qué los documentos obsoletos son peores que la ausencia de documentos

Existe una trampa específica que hace que este problema sea más difícil de lo que parece: un documento supersedido no desaparece del índice. Al contrario, compite con ventaja. Contiene exactamente el vocabulario que los empleados usaban cuando ese proceso existía, así que cuando alguien hace la misma pregunta de siempre, el documento antiguo supera en ranking al vigente porque la similitud semántica es mayor.

Vivimos nuestra versión de esto con un bot que citaba confiadamente una política de viajes que había sido reemplazada dos veces. Nada en el pipeline sabía lo que significaba la palabra reemplazada. El modelo cargó con la culpa durante meses por lo que era, en realidad, un problema de archivo. Un mejor chunking nunca lo habría arreglado. Tres meses borrando documentos sí lo arreglaron.

La comunidad técnica que trabaja con estos sistemas llega a la misma conclusión: ni la metadata de recencia ni estrategias de recuperación más sofisticadas resuelven esto de raíz. Solo funciona eliminar el documento obsoleto. La pregunta incómoda que viene después es si, una vez limpia la biblioteca, alguien se va a ocupar de que siga limpia dentro de seis meses.

La arquitectura cambió; las reuniones de presupuesto, no

Chunk and embed fue una solución práctica a un problema real: las ventanas de contexto de los modelos de 2023 eran pequeñas y no había otra forma de hacer que el modelo viera documentos grandes. Esa restricción se ha disuelto en buena medida. Un conjunto de documentos estable y no demasiado extenso puede residir directamente en contexto cacheado sin pasar por ningún sistema de recuperación.

Para el resto, el patrón que mejor nos ha funcionado es el del analista junior: un agente que lanza búsquedas por palabras clave, abre lo que parece relevante, y cuando la respuesta vive en un sistema operacional, lo consulta directamente en lugar de buscar en una copia que puede estar desactualizada. Retrieval sigue presente, pero como una herramienta que el agente usa a veces, no como el diseño central de todo.

Varios equipos con los que hemos hablado han llegado a la misma arquitectura por caminos distintos: datos estructurados de negocio mediante queries directas a base de datos o APIs, y retrieval solo para conocimiento no estructurado que realmente no tiene otro hogar. El resultado es un sistema más simple, más barato de mantener y con menos alucinaciones, precisamente porque cada tipo de pregunta va a la fuente que le corresponde.

Tres casos concretos para decidir qué necesitas

Soporte desde documentación de producto

Si tienes un conjunto de manuales y políticas internas que se actualizan de forma controlada y hay alguien que es propietario de esa biblioteca, RAG funciona. La clave es ese alguien. Sin propietario, no hay sistema de IA que sobreviva a la entropía documental.

Automatización de propuestas comerciales

Precios, condiciones, histórico de cliente, márgenes: todo eso vive en el CRM o el ERP. Intentar recuperarlo mediante retrieval semántico es innecesariamente complejo y menos fiable que una llamada directa a la API. RAG aquí no aporta nada que una integración limpia no resuelva mejor.

Automatización de procesos operativos

Un agente que mezcla consultas directas a sistemas con búsqueda documental puntual sale más barato, tiene menos deuda técnica y es más fácil de auditar. Para equipos con recursos limitados, esto importa más que la elegancia arquitectónica.

El coste real que no aparece en el presupuesto inicial

Una base de datos vectorial en la nube parece barata al principio. El coste real tiene tres componentes que raramente se presupuestan juntos: la limpieza inicial del corpus, el mantenimiento continuo para que no se degrade, y el tiempo de alguien que sea propietario permanente de la biblioteca.

Si no hay presupuesto para ese mantenimiento, la limpieza inicial dura lo que dura. En organizaciones donde el conocimiento vive en las cabezas de las personas y se transmite de forma oral, el problema es estructural: cuando esa persona se va, el conocimiento se evapora. Ningún sistema de retrieval lo recupera. Esto no es un problema técnico; es un problema de gobernanza de datos que la IA no puede resolver por sí sola.

Desde la perspectiva del Reglamento de IA de la UE, hay además un riesgo regulatorio concreto: sistemas que basan decisiones con consecuencias reales en retrieval no verificado exponen a la empresa a responsabilidades que van más allá del coste técnico. La trazabilidad de fuente y la auditoría de respuestas no son opcionales cuando las decisiones importan.

Sobre la gobernanza: mantener limpia la biblioteca sin ahogar al equipo

La pregunta práctica que casi nadie hace antes de aprobar el proyecto es: ¿quién borra los documentos obsoletos el año que viene? La respuesta honesta en la mayoría de las organizaciones es nadie, porque nadie ha presupuestado ese tiempo.

Hay enfoques que alivian parte de esta carga sin requerir una persona dedicada al cien por cien. Automatizar la detección de documentos que llevan más de cierto tiempo sin revisión, aplicar reglas de versionado que marquen como inactivos los documentos cuando se crea una nueva versión, o usar flujos que notifiquen al responsable de cada área cuando un documento de su ámbito supera su fecha de revisión. Nada de esto elimina la necesidad de que alguien tome decisiones, pero reduce la carga de buscarlas.

El Model Context Protocol y los agentes con capacidad de búsqueda granular también permiten delegar parte de la lógica de selección de fuentes al propio sistema: si el agente puede consultar qué versión de un documento está marcada como vigente antes de usarla, el riesgo de citar una política desfasada se reduce sin depender únicamente de que la base documental esté perfecta.

La prueba que vale más que una semana de arquitectura

Antes de que se apruebe la siguiente línea de presupuesto para RAG, hay un ejercicio que tarda una hora y responde casi todo lo que importa: escribe las 20 preguntas concretas que el sistema tiene que responder y responde 5 de ellas a mano.

Si para responder esas 5 preguntas has abierto una hoja de cálculo, consultado el ERP o llamado a alguien, no tienes un problema de retrieval. Si has abierto documentos y la respuesta estaba en el más reciente y estaba clara, quizás sí. Si has abierto documentos y has encontrado tres versiones contradictorias, tienes un problema de gobernanza que RAG va a amplificar, no a resolver.

El cliente de enero terminó sin base de datos vectorial. La calidad de las respuestas del sistema que entregamos es lo mejor que hemos entregado en lo que va de año. Todavía resulta un poco incómodo decirlo así.

RAG seguirá funcionando perfectamente en miles de empresas durante otra década. Ese es precisamente el punto: las cosas no se convierten en legado por fallar. Se convierten en legado por funcionar temprano y luego nadie vuelve a preguntarse si sigue siendo la mejor opción. Si tienes un proyecto de automatización documental en marcha o sobre la mesa, merece la pena hacerse esa pregunta antes de que el presupuesto decida por ti.