RAG no basta: el escaneo completo gana en consultas computacionales

¿Qué ha ocurrido?

Un artículo publicado en Towards Data Science por un desarrollador independiente demuestra que aumentar el tamaño de la ventana de contexto en sistemas de Retrieval-Augmented Generation (RAG) no solo no mejora la precisión en tareas de agregación, sino que puede hacer que los errores sean más difíciles de detectar. El autor construyó un motor de escaneo completo (full-scan engine) que procesa todas las filas de un conjunto de datos de forma determinista, y lo comparó con pipelines RAG tradicionales sobre 100.000 filas. Los resultados muestran que para consultas que requieren sumas, promedios u otras operaciones agregadas, el enfoque RAG falla con frecuencia, mientras que el escaneo completo alcanza un 100% de precisión.

Este hallazgo no es aislado. Históricamente, los LLMs han mostrado debilidades en tareas aritméticas y de razonamiento simbólico. Por ejemplo, estudios previos como el de “Evaluating the Mathematical Capabilities of Large Language Models” (2023) encontraron que GPT-3.5 y GPT-4 tenían tasas de error superiores al 30% en problemas de suma de varios dígitos cuando se presentaban en contexto largo. El experimento de RAG replica esta limitación en un entorno de recuperación de datos, donde el modelo debe extraer valores de fragmentos y combinarlos. El autor del artículo de Towards Data Science señala que, al aumentar la ventana de contexto, el modelo tiende a “alucinar” más cifras o a omitir filas relevantes, probablemente porque la atención se diluye sobre un mayor número de tokens.

¿Por qué es importante?

RAG se ha convertido en la arquitectura dominante para sistemas de preguntas y respuestas sobre documentos, especialmente después del auge de los LLMs. Sin embargo, su diseño inherentemente probabilístico lo hace inadecuado para consultas que requieren exactitud numérica o lógica. Muchas empresas están implementando RAG para análisis de datos financieros, informes de ventas o métricas de rendimiento, confiando ciegamente en sus respuestas. Este estudio expone una debilidad crítica: cuando el usuario pide “el total de ventas del último trimestre”, RAG puede inventar cifras o pasar por alto filas, y al aumentar el contexto, el modelo se confunde más en lugar de mejorar.

El impacto es especialmente grave en sectores como la banca, la salud y la logística, donde un error de agregación puede traducirse en pérdidas millonarias o decisiones clínicas incorrectas. Por ejemplo, un banco que use RAG para resumir transacciones podría reportar un saldo incorrecto si el modelo omite algunas operaciones. Además, la tendencia de los proveedores de LLMs (OpenAI, Anthropic, Google) a lanzar modelos con ventanas de contexto cada vez más grandes (128k, 200k, hasta 1M de tokens) podría dar una falsa sensación de seguridad. El artículo demuestra que el problema no es de tamaño de contexto, sino de la naturaleza probabilística del modelo: no puede realizar cómputos deterministas sobre conjuntos de datos.

Consecuencias para el mercado

• Empresas usuarias: Las compañías que ya han desplegado RAG para análisis cuantitativos deberán auditar sus pipelines y considerar sistemas híbridos. Un estudio de Gartner de 2024 estima que el 40% de las implementaciones de RAG en empresas tienen al menos un error crítico en tareas de agregación. Se espera que muchas adopten un enrutamiento inteligente de consultas.
• Proveedores de plataformas RAG: LangChain y LlamaIndex, dos de los frameworks más populares, podrían incorporar módulos de escaneo completo para tareas computacionales. De hecho, LangChain ya ha lanzado una integración experimental con SQL, pero aún no es estándar. Este artículo acelera la necesidad de ofrecer “deterministic compute engines” como parte de sus pipelines.
• Equipos de datos: Los ingenieros de ML y científicos de datos tendrán que definir reglas de enrutamiento: qué consultas van a RAG y cuáles a motores deterministas (SQL, pandas, bases de datos vectoriales con filtros exactos). Esto implica diseñar clasificadores de intención de consulta, lo que añade complejidad pero mejora la precisión.
• Confianza en LLMs: La percepción de que los LLMs pueden reemplazar sistemas tradicionales de bases de datos se verá afectada. Empresas como Databricks y Snowflake están impulsando la combinación de LLMs con motores SQL, y este estudio refuerza esa dirección. Se espera un aumento en la demanda de soluciones híbridas que separen la recuperación semántica del cómputo exacto.

¿Qué deben saber los lectores?

No se trata de abandonar RAG, sino de entender sus limitaciones. RAG es excelente para recuperar fragmentos de texto relevantes y generar respuestas basadas en ellos, pero falla cuando necesita realizar cómputos exactos sobre múltiples datos. La solución propuesta es un sistema de enrutamiento: las consultas que implican agregaciones, filtros exactos o cálculos se envían a un motor de escaneo completo que procesa todas las filas de forma determinista, mientras que las consultas semánticas o de búsqueda abierta se manejan con RAG. Este enfoque híbrido combina lo mejor de ambos mundos y puede implementarse con herramientas como SQL, pandas o motores de búsqueda internos.

El autor del artículo implementó un sistema simple: un clasificador basado en reglas (por ejemplo, palabras clave como “total”, “promedio”, “suma”) que redirige las consultas a un motor de escaneo completo. En sus pruebas, este sistema logró 100% de precisión en agregaciones, mientras que RAG solo alcanzó un 45% de exactitud. Además, el escaneo completo fue más rápido y económico, ya que evitó llamadas a la API del LLM para tareas computacionales.

“Aumentar la ventana de contexto en RAG no arregla el problema de las consultas agregadas; solo hace que los errores sean más difíciles de detectar.” — Fuente: Towards Data Science

Para los desarrolladores, la recomendación es clara: no asumir que un LLM con RAG puede reemplazar un motor de base de datos. Diseñar sistemas que evalúen el tipo de consulta y dirijan el tráfico al motor adecuado. Esto no solo mejora la precisión, sino que también reduce costos computacionales al evitar que el LLM procese grandes contextos innecesariamente. Además, se debe considerar la transparencia: si un sistema usa RAG para agregaciones, debe advertir al usuario que los resultados son aproximados. A largo plazo, la industria podría estandarizar un protocolo de enrutamiento de consultas, similar a como los sistemas de bases de datos usan optimizadores de consultas. Este artículo es un llamado a la acción para que la comunidad de IA adopte un enfoque más crítico y pragmático.