Recuperación por agente y contexto suficiente: cuando RAG no sabe lo suficiente

La búsqueda vectorial no es lo que hace fracasar a la mayoría de los sistemas RAG. El verdadero problema en la producción es un modelo que responde aunque carezca de evidencias suficientes. No se trata de no encontrar nada: el sistema suele ofrecer algo, los fragmentos parecen relevantes y la respuesta es fluida y segura. Sin embargo, resulta incompleta, ya que los hechos necesarios se encuentran distribuidos en varios documentos, sistemas, tablas, tickets, manuales, registros o relaciones gráficas.

El patrón clásico consiste en una sola pasada:

User question → embed query → retrieve top-k chunks → send to LLM → generate answer

Eso está bien para preguntas sencillas, pero rara vez ocurre con las empresariales. Una política se encuentra en un documento y sus excepciones en otro. Un ticket describe el incidente, una nota de lanzamiento explica un cambio de comportamiento, una fila de la base de datos almacena el estado actual, un arista de un grafo muestra una dependencia, una tabla en PDF contiene la cifra real, y una conversación anterior registra lo que el usuario ya intentó. Si se obtienen solo los primeros fragmentos similares, el modelo responde demasiado pronto. RAG no está muerto; necesita reconocer cuándo le falta información suficiente.

Respuestas prematuras

Muchos sistemas RAG fallan en silencio. Nunca indican que no hay suficientes pruebas. Entregan una respuesta fluida, estructurada y en su mayoría plausible, pero incorrecta.

Imagínese a un agente de soporte interno al que le preguntan por qué la exportación de Acme dejó de funcionar tras una migración de espacio de trabajo. Un proceso automático ingenuo encuentra una página de solución de problemas para exportaciones y afirma que faltaban permisos. Quizás tenga algo de razón. Una respuesta completa debe basarse en el registro de migración de Acme, una nota de lanzamiento sobre los cambios en los permisos de exportación, el ticket de la semana pasada, un informe del incidente interno, las banderas de funcionalidad de la cuenta y un grafo de dependencias que indique el servicio de exportación involucrado. Un único documento nunca podría contener todo eso, por lo que la recuperación de información debe funcionar más bien como lo haría un agente humano.

Qué significa un contexto suficiente

Un contexto suficiente significa que las pruebas disponibles permiten dar una respuesta segura. Los fragmentos poco relacionados, una alta puntuación de similitud o cinco documentos obtenidos no cuentan. Antes de generar la respuesta, el sistema debe verificar que cuenta con la política aplicable, las excepciones, el estado actual, el registro oficial, los vínculos entre entidades, información suficiente para explicar la causa y no solo el síntoma, además de una forma de citar el resultado. Si falta algo, debe volver a buscar. Ese es el paso del RAG clásico a la recuperación agente.

De top-k a búsqueda de evidencias

El RAG estándar trata la recuperación de información como un paso único: se obtiene la información una vez y se responde. La recuperación agente la considera un flujo de trabajo:

Retrieve once → answer

Plan → retrieve → inspect → judge evidence → retrieve again → answer

Nada obliga al modelo a responder basándose en lo que aparezca primero. Actúa más bien como un analista de investigación que busca, abre documentos, los compara, sigue las relaciones entre ellos, verifica la información y responde solo cuando el contexto es adecuado.

Por qué los agentes elevan la complejidad

Un chatbot responde a una pregunta. Un agente toma decisiones: elige herramientas, llama a APIs, actualiza registros, crea tickets, recomienda acciones, solicita aprobación o continúa a través de numerosos pasos. Un contexto incompleto entonces se propaga posteriormente:

Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action

Un agente de producción no debería limitarse a presentar un documento similar. Debería poder indicar que localizó la póliza, la excepción, el estado de la cuenta en tiempo real y el incidente relacionado, y que esta evidencia resuelve la cuestión. Esa es una arquitectura diferente.

La dirección que toma la recuperación por agentes

Los trabajos recientes sobre RAG y grafos de conocimiento apuntan hacia una recuperación controlada por agentes, consciente de los grafos, evaluada según la evidencia y respaldada por la memoria. No todos los sistemas necesitan un gran grafo de conocimiento, pero la capa de recuperación requiere más inteligencia que simplemente incrustar una consulta y devolver los resultados más relevantes. Hay varias direcciones importantes.

Recuperación entre corpus

El conocimiento empresarial no se encuentra en una única base de datos vectorial organizada. Está distribuido en Google Drive, Confluence, Notion, Slack, Jira, GitHub, almacenes, tickets de soporte, paneles de control, APIs internas, documentación de productos y manuales en PDF. Un buen sistema debe decidir dónde buscar primero. Un planificador de búsquedas puede clasificar la consulta como política, comportamiento del producto, específica del cliente, incidente, métrica financiera o dependencia técnica, y redirigirla en consecuencia. Buscar en todo es costoso, y buscar en el lugar equivocado es aún peor.

La recuperación como herramientas

Un patrón útil presenta la recuperación como un conjunto controlado de herramientas en lugar de un resultado fijo:

search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)

Esto refleja la investigación humana: búsqueda, apertura de resultados prometedores, inspección de secciones, perfeccionamiento de la consulta y comparación de pruebas. El modelo de razonamiento impulsa el proceso, pero solo dentro de un conjunto de herramientas limitado, lo que brinda flexibilidad sin acceso ilimitado.

Navegación por el grafo de conocimiento

La búsqueda vectorial encuentra texto semánticamente similar, mientras que muchas consultas en entornos reales se basan en relaciones. ¿A qué clientes afecta este servicio? ¿Qué productos dependen de esta API? ¿Qué política se aplica en esta región? ¿Qué despliegue causó este incidente? Estas son preguntas relacionadas con el contexto, no con la similitud. Un grafo puede vincular directamente las entidades:

Customer → Workspace → Feature Flag → Service → Incident → Release Note

Un agente puede seguir esos enlaces en lugar de esperar que el fragmento adecuado aparezca entre los resultados principales. Eso demuestra que se trata más de navegación que de recuperación de información. Úselo cuando las relaciones sean importantes, y omítelo cuando simplemente suene avanzado.

Evaluación de la suficiencia de las pruebas

Después de la recuperación, el sistema debe determinar si las pruebas son suficientes. ¿Responde directamente a la pregunta? ¿Faltan entidades, fechas o fuentes? ¿Existen conflictos entre las fuentes? ¿Tiene el origen una autoridad real? ¿Se puede citar la respuesta? Cuando las pruebas son débiles, el sistema continúa buscando:

Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source

El bucle evita respuestas prematuras y facilita la depuración, ya que se puede ver por qué el agente realizó una nueva búsqueda.

Gráficos de contexto y memoria del agente

RAG suele tratar conocimientos externos, pero los agentes también necesitan memoria: lo que el usuario preguntó anteriormente, qué se ha buscado, qué pruebas se aceptaron, qué se decidió y qué suposiciones siguen abiertas. Un búfer de conversación plano no es suficiente. Un diseño mejor vincula la memoria con las entidades y las decisiones, de modo que la propia traza del razonamiento se convierte en memoria:

User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch

La próxima vez que aparezca un problema similar, el agente no parte de cero, lo cual es importante para los agentes que operan durante mucho tiempo.

RAG multimodal y consciente de documentos

Gran parte del conocimiento empresarial no está en formato de texto plano. Se encuentra en PDF, tablas, capturas de pantalla, diagramas, fórmulas, escaneos, gráficos, presentaciones y formularios. El procesamiento habitual de los datos distorsiona su estructura: las tablas se convierten en texto desordenado, las fórmulas pierden su contexto, los diagramas se reducen a suposiciones del OCR y las secciones se separan de las leyendas que las explican. Un sistema consciente de documentos comprende el texto, las tablas, las figuras, el diseño, la jerarquía de encabezados, las leyendas, los campos de formulario y cómo las imágenes se relacionan con el texto. Los sectores de finanzas, salud, manufactura, derecho, seguros y documentación técnica dependen en mayor medida de este tipo de sistemas.

Presupuestos de herramientas y contexto

Las herramientas también consumen contexto. Al cargar docenas de herramientas de recuperación, gráficas, bases de datos y búsqueda, sus esquemas compiten con las pruebas:

Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window

Por lo tanto, el RAG agente necesita un entorno de ejecución consciente del presupuesto que decida qué herramientas mostrar, cuántos fragmentos incluir, si resumir la salida de las herramientas y, lo que es más importante, cuándo detenerse. El objetivo es recuperar lo suficiente, pero no de forma interminable.

Una arquitectura de producción

En conjunto, un sistema de recuperación agente para producción se asemeja mucho más a un plano de control que a una tubería de procesamiento:

User Question
   ↓
Intent + Risk Classifier
   ↓
Retrieval Planner
   ↓
Source Router
   ├── Enterprise Search
   ├── Vector Search
   ├── Keyword Search
   ├── Knowledge Graph
   ├── Structured Data
   ├── Document Parser
   └── Agent Memory
   ↓
Evidence Inspector
   ↓
Sufficiency Gate
   ├── If insufficient → refine query / follow graph / open document
   └── If sufficient → generate answer
   ↓
Answer with Evidence Trace

El mensaje práctico es más simple: no deje que RAG responda hasta que tenga suficientes pruebas.

El caso Acme, de principio a fin

Al preguntarse por qué falló una exportación tras la migración del espacio de trabajo, RAG estándar obtiene la guía de solución de problemas para exportaciones y las Preguntas Frecuentes sobre migración, y responde que la exportación probablemente falló por falta de permisos. Un sistema agente investiga:

1. Busca en los documentos de soporte casos de fallas en exportaciones.
2. Busca en las notas de lanzamiento cambios relacionados con la migración del espacio de trabajo.
3. Abre la configuración de la cuenta del cliente.
4. Verifica el estado de las banderas de funcionalidad.
5. Busca en el historial de incidentes.
6. Sigue el grafo de dependencias desde el servicio de exportación hasta el servicio de permisos.
7. Decide si ahora las pruebas son suficientes.
8. Escribe la respuesta con las fuentes correspondientes.

La respuesta es la siguiente: Acme fue migrado al nuevo modelo de espacio de trabajo, mientras que el servicio de exportación seguía verificando la ruta de permisos antigua. La marca del espacio de trabajo está activada, pero la política de exportación nunca se actualizó, por lo que la solución consiste en actualizar dicha política para el modelo de espacio de trabajo. No fue un modelo más robusto lo que cambió el resultado, sino una mejor recopilación de evidencias.

Qué construir primero

Con un sistema RAG ya existente, no reconstruya todo. Siga estos pasos en orden:

1. Agregue una verificación de suficiencia. Antes de generar la respuesta, pregunte si las evidencias obtenidas son suficientes para esa pregunta específica; si no lo son, realice otra búsqueda o haga una pregunta de aclaración al usuario.
2. Añadir enrutamiento de fuentes. Buscar en cada fuente cada vez es una pérdida de esfuerzo. Clasificar primero la consulta: las preguntas relacionadas con políticas van a los documentos de políticas, los problemas de los clientes a los tickets junto con el estado de la cuenta, las fallas técnicas a los documentos, registros y el grafo del servicio, y las preguntas sobre métricas a la capa semántica.
3. Añadir herramientas de recuperación como search, open, find, summarize, follow_entity_relation y query_structured_record, para que la recuperación sea iterativa.
4. Añadir recorrido de grafos, donde las respuestas dependen de la propiedad, dependencia, linaje, causalidad, jerarquía, enlaces de múltiples saltos o excepciones en las políticas.
5. Preservar la estructura del documento. Para PDF, informes, diapositivas, tablas y diagramas, utilizar un análisis consciente del documento y almacenar su estructura en lugar de dividirlo simplemente en fragmentos.
6. Conserva un registro de pruebas que detalle las fuentes consultadas, los documentos abiertos, los hechos aceptados, las lagunas encontradas y la razón por la cual el sistema decidió que ya tenía suficiente información. Ese registro es lo que genera confianza en los sistemas RAG agentes.

Qué no sobredesarrollar

Esto puede volverse demasiado complejo, y no toda técnica es adecuada para todos los casos de uso. Una búsqueda simple en una FAQ probablemente no necesite un grafo de conocimiento; los documentos de texto plano no requieren análisis multimodal; las preguntas y respuestas puntuales no necesitan memoria gráfica a largo plazo; y un dominio completamente interno no necesita búsquedas externas. La pregunta a hacerse es qué tipo de evidencia necesita esa consulta. Para un documento sencillo, el RAG normal puede ser suficiente. Cuando la respuesta abarca fuentes, relaciones, memoria y estado actual, entonces la recuperación mediante agentes justifica su complejidad.

El cambio

El movimiento actual en RAG no tiene como objetivo reemplazar la búsqueda vectorial. Más bien, añade control sobre el proceso de recuperación de información. La búsqueda vectorial sigue siendo importante, al igual que la búsqueda por palabras clave. Los grafos de conocimiento son relevantes cuando existen relaciones, el análisis de documentos cuando hay estructura definida, y la memoria cuando un agente opera a lo largo del tiempo. La tarea real consiste en combinarlos. La próxima generación no se verá así:

Vector DB → top-k chunks → LLM

Y más cosas como esta:

Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer

RAG no falla solo cuando obtiene fragmentos de mala calidad. También falla cuando recibe fragmentos parcialmente útiles y responde de inmediato. Para preguntas simples, el método top-k puede seguir funcionando. En el caso de entornos empresariales, de investigación, de soporte técnico, de operaciones y de agentes con muchos documentos, la recuperación de información requiere un bucle más robusto:

plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded

Ese es el paso del RAG estándar a la recuperación por agentes. No se debe a que el RAG esté obsoleto. Los agentes en producción deben reconocer cuándo no saben lo suficiente.