RAG para agentes de IA: por qué el retrieval agéntico sustituye a los pipelines vectoriales fijos

Qué es el RAG para agentes de IA

El RAG para agentes es un sistema que da al agente acceso a información externa mientras razona y actúa. El RAG tradicional sigue una secuencia fija. El RAG agéntico cambia esa secuencia para que el agente decida cuándo recuperar.

Pregunta del usuario
→ Embedding de la pregunta
→ Búsqueda en una base vectorial
→ Recuperar chunks
→ Enviar los chunks al modelo
→ Generar una respuesta

Tarea del usuario
→ El agente analiza la tarea
→ El agente decide qué información necesita
→ El agente llama a una herramienta de retrieval o de documentos
→ El agente evalúa el resultado
→ El agente llama a otra herramienta si hace falta
→ El agente actúa o responde

La diferencia importante es que el retrieval deja de ser un paso invisible de preprocesado. Pasa a ser una capacidad del agente. La documentación de LangChain lo describe de forma directa: un agente puede usar una o varias herramientas para obtener conocimiento externo, incluidos cargadores de documentos, APIs y consultas a bases de datos, en lugar de depender solo de una cadena de retrieval ya construida.

RAG tradicional frente a RAG agéntico

El RAG agéntico no es simplemente RAG con un agente encima. Es otra forma de diseñar la relación entre agentes, documentos y herramientas externas.

Límites del RAG vectorial fijo

El RAG basado en vectores sigue siendo útil, sobre todo en colecciones grandes y persistentes de texto. El pipeline estándar muestra varias debilidades cuando se convierte en la solución por defecto de cada agente.

El chunking puede destruir la estructura

El chunking parte un documento en pasajes más pequeños para indexarlos. Los documentos no son colecciones naturales de fragmentos arbitrarios. El sentido puede depender del título de una sección, de la cabecera de una tabla, de una nota, de un párrafo anterior, de una referencia de página, de la relación entre filas, de una cláusula y su adenda, o de la posición de un valor en un formulario.

Una fila sin los encabezados de columna no equivale a una tabla completa. Una cláusula de contrato sin las definiciones puede inducir a error. Una frase de una política puede depender de excepciones que aparecen varios párrafos después.

Los embeddings miden similitud, no relevancia de negocio

Los embeddings representan relaciones semánticas. Pueden encontrar texto parecido a una consulta, pero la similitud no es lo mismo que la relevancia para una tarea. Preguntar si una factura coincide con un pedido exige comparar proveedor, producto, cantidad, precio, impuesto, total y moneda. Una búsqueda vectorial puede recuperar texto de ambos documentos. No hace la comparación por sí sola.

Una sola llamada de retrieval puede no bastar

Una cadena RAG fija supone que una recuperación aporta el contexto necesario. Los agentes suelen necesitar varios pasos: encontrar el contrato, encontrar la última adenda, revisar la cláusula de renovación, comparar la fecha, decidir si hace falta un preaviso y crear un recordatorio. El agente elige qué inspeccionar a continuación según lo que acaba de descubrir.

Las bases vectoriales añaden infraestructura

• Ingesta, parsing, chunking y generación de embeddings.
• Almacenamiento vectorial, filtros, actualizaciones de índice y borrado.
• Versiones, control de acceso y evaluación del retrieval.
• Citas y reprocesado cuando cambia el parsing.

Frameworks como LlamaIndex y LangChain simplifican partes del proceso, pero no eliminan las decisiones de arquitectura. LlamaIndex sigue siendo especialmente útil para conectores, índices y motores de consulta. La pregunta no es si esas herramientas valen. La pregunta es si cada agente debe empezar con una pila completa de retrieval vectorial.

Chunking, embeddings y bases vectoriales no son todo el futuro

Decir que las bases vectoriales, los embeddings y el chunking están muertos es demasiado simple. Siguen siendo valiosos para bibliotecas grandes de documentación, bases de conocimiento persistentes, búsqueda semántica, descubrimiento por similitud, recomendaciones, colecciones a largo plazo y consultas repetidas de alto volumen.

El cambio real es de arquitectura. El retrieval vectorial pasa a ser una herramienta dentro de un sistema de información agéntico, no el fundamento universal de cada agente. El agente usará extracción estructurada para facturas, SQL para registros financieros, APIs para datos en vivo, procesamiento del documento completo para archivos cortos, comparación documental para expedientes, grafos para relaciones, índices léxicos para búsqueda textual, vectores para descubrimiento semántico y revisión humana para la ambigüedad.

Qué es el RAG agéntico

El RAG agéntico es una arquitectura de retrieval en la que el agente controla cuándo y cómo se accede a la información externa. Puede decidir si hace falta recuperar, elegir la fuente, formular una subpregunta más precisa, consultar más de una fuente, evaluar el resultado, hacer una pregunta de seguimiento, comparar salidas, detectar evidencia insuficiente y detenerse antes de una acción no respaldada.

La guía de RAG agéntico de Microsoft describe este patrón como planificación dinámica de consultas, razonamiento en varios pasos y recolección autónoma de información, en lugar de una única llamada fija de retrieval.

El retrieval se convierte en una herramienta

• search_documents() y query_document()
• process_multiple_documents() y compare_documents()
• extract_fields() y query_database()
• search_web(), get_contract_amendment() y request_human_review()

Ante la pregunta de si una factura coincide con un pedido, el agente puede procesar ambos archivos juntos, comparar proveedor y totales, devolver una excepción si difieren y pedir revisión si el resultado no está claro. No necesita una búsqueda semántica genérica que espere que los chunks contengan la comparación.

La evolución del RAG para agentes

• Etapa uno: recuperar y generar. Consulta, búsqueda vectorial, chunks y respuesta del modelo.
• Etapa dos: recuperar y reordenar. Mejora la calidad, pero el pipeline sigue siendo casi fijo.
• Etapa tres: retrieval híbrido. Vectores, palabras clave y filtros de metadatos.
• Etapa cuatro: retrieval agéntico. El agente planifica, elige fuentes y herramientas, evalúa, itera y actúa.

El sistema deja de centrarse en una base de datos. Se centra en la capacidad del agente para usar herramientas de información.

Alternativas al RAG basado en vectores

La frase “alternativa al RAG” suele ser engañosa, porque muchas alternativas siguen dando contexto externo a un modelo. Cambian el mecanismo de recuperación o de procesamiento.

• Extracción estructurada: convierte un documento en campos que el agente puede validar y escribir en otro sistema.
• Consulta directa del documento: se envía el archivo y se pregunta sobre él, sin indexarlo antes. Encaja con archivos puntuales, cargas del usuario y casos temporales.
• Procesamiento multi-documento: varios archivos se comparan en una operación. No es RAG tradicional; es entender relaciones entre archivos.
• Retrieval por herramientas: SQL, CRM, APIs, grafos de conocimiento y búsqueda web, sin reconstruir cada sistema como una base vectorial.
• Contexto del documento completo: para archivos cortos o moderados, una representación estructurada puede ser más fiable que partir tablas y secciones.
• SQL y grafos: preguntas de negocio como facturas vencidas o contratos ligados a un proveedor suelen ser más precisas como consulta estructurada o como relación explícita.

Un agente maduro puede combinar procesamiento documental, extracción estructurada, SQL, APIs, búsqueda, un grafo y revisión humana, y elegir la capacidad que encaja con la tarea.

RAG sobre documentos para agentes

A menudo se trata el RAG sobre documentos como sinónimo de meter PDFs en una base vectorial. Eso es solo una implementación. Un agente documental puede necesitar leer el archivo, extraer campos, hacer preguntas de seguimiento, comparar documentos, seguir la evidencia, entender tablas, detectar archivos que faltan, conservar contexto, crear una tarea y escalar la incertidumbre.

Ese modelo se parece más al trabajo real: el agente recibe un conjunto de capacidades documentales y decide cómo combinarlas.

Claix y la siguiente generación de RAG documental

Claix puede actuar como capa documental para agentes que no quieren construir a mano cada componente de RAG. En lugar de forzar cada flujo por parsear, trocear, embeber, guardar y recuperar, expone capacidades: un archivo a Markdown estructurado para el contexto del agente, un archivo a JSON para una llamada de herramienta, varios archivos a una comparación cruzada, y un documento a contexto persistente para preguntas posteriores.

La idea no es que toda base vectorial quede obsoleta. Es que un agente a menudo puede empezar con una operación documental más directa. Las landings de Documento a Markdown y Procesamiento multi-documento describen esas dos capas.

Markdown sirve para leer y razonar. JSON sirve para validar y actuar. Algunas tareas ni siquiera necesitan una base de conocimiento: responden una pregunta sobre un conjunto pequeño de archivos relacionados. Una operación multi-documento directa puede ser más simple que construir un índice vectorial para un caso temporal.

Alternativas a LlamaIndex para RAG agéntico

LlamaIndex es un framework útil para conectar modelos con datos, construir índices y crear flujos de retrieval. No es la única opción, y puede no ser la abstracción adecuada para cada agente.

• Llamadas directas a herramientas del modelo, cuando quieres control sobre definiciones, estado, permisos, reintentos y observabilidad.
• LangChain y LangGraph, para grafos de agentes, flujos con ramas, estado persistente y nodos de aprobación humana.
• Mastra, para equipos de TypeScript que construyen agentes y workflows en el ecosistema JavaScript.
• Haystack, para una arquitectura Python modular de procesamiento, retrieval y agentes.
• DSPy, cuando el reto principal es mejorar de forma sistemática prompts, módulos de razonamiento o estrategias de retrieval.
• Un runtime propio más una API documental gestionada, cuando quieres menos capas de abstracción alrededor de la extracción, el Markdown, el JSON y el procesamiento cruzado.

Claix se entiende mejor como una capa de procesamiento documental que puede usarse con un runtime propio o con frameworks como LangChain y LangGraph. No sustituye todas las capacidades de un framework completo de agentes.

Cuándo una base vectorial sigue teniendo sentido

Una base vectorial puede seguir siendo adecuada con millones de segmentos, una colección permanente grande, mucho volumen de consulta, búsqueda semántica repetida, muchos usuarios sobre los mismos datos, políticas de acceso complejas o un producto cuyo centro es la búsqueda.

La pregunta útil no es si usar vectores o agentes. Es qué operación de información exige la tarea. Vectores para descubrimiento semántico, extracción estructurada para campos, procesamiento multi-documento para comparar, SQL para registros, APIs para datos en vivo y un grafo para relaciones. Un agente puede orquestarlos todos.

Una arquitectura mejor para agentes documentales

Capa 1: extracción consciente del formato
PDF, Excel, Word, imagen, audio, HTML
        ↓
Markdown legible o JSON estructurado

Capa 2: operaciones documentales
Consultar, comparar, extraer, validar, detectar lo que falta, obtener evidencia

Capa 3: razonamiento del agente
Planificar, elegir herramientas, evaluar, preguntar de nuevo, decidir si continuar

Capa 4: acciones de negocio
Crear un registro, aprobar, rechazar, avisar, abrir un ticket, actualizar un CRM, pedir revisión

Un pipeline vectorial fijo puede trocear una factura y pedir el total al modelo, pero no verifica la factura. Un enfoque documental agéntico procesa la factura con el pedido y el albarán, compara proveedor, cantidades y totales, y deja que el agente apruebe o escale.

Un agente legal que solo recupera la cláusula de renovación más parecida sigue sin ver la relación entre contrato, adenda y anexo. La operación útil es extraer fechas y obligaciones, comparar condiciones y crear una tarea de revisión. El onboarding de clientes sigue el mismo patrón: solicitud, documento de identidad y ficha de empresa. El centro es la verificación entre documentos.

Por qué el RAG agéntico tiende a ser el patrón por defecto

• Los agentes necesitan contexto dinámico de varias fuentes y varios pasos.
• El retrieval es una herramienta más, junto a bases de datos, CRM, calculadoras, búsqueda web y revisión humana.
• El agente tiene que evaluar si la evidencia basta, si los documentos discrepan y si es seguro actuar.
• Una tarea como aprobar un proveedor no cabe en una búsqueda vectorial seguida de una respuesta.
• La mejor fuente puede ser un documento, una hoja de cálculo, una base de datos, una API, un grafo, un usuario o un revisor.

Qué cambia para quien desarrolla

El trabajo pasa de construir un gran pipeline de RAG a diseñar un conjunto fiable de capacidades del agente. En lugar de preguntar cómo indexar cada documento, la pregunta es qué debe poder hacer el agente con los documentos: leer, extraer campos, comparar, consultar, encontrar lo que falta, obtener evidencia y crear una tarea de revisión.

Un marco práctico de decisión

• Usa procesamiento directo cuando los archivos llegan para una tarea, el conjunto es pequeño o necesitas una respuesta cruzada inmediata.
• Usa extracción estructurada cuando los campos se conocen, importa la validación o la salida actualiza otro sistema.
• Usa un Knowledge Space cuando los documentos deben persistir y se van a consultar otra vez.
• Usa búsqueda vectorial cuando el descubrimiento semántico es el centro, la colección es grande y la similitud es de verdad la operación correcta.
• Usa orquestación agéntica cuando la tarea necesita varias herramientas, planificación, comparación, acciones y aprobaciones.

Estas opciones se complementan. No se excluyen.

Errores habituales al construir RAG agéntico

• Tratar todo problema documental como búsqueda semántica cuando el flujo necesita totales, fechas o identificadores.
• Construir una base vectorial antes de entender el comportamiento documental del producto.
• Enviar archivos crudos al modelo en lugar de una representación consistente.
• Ignorar las relaciones: factura, pedido y albarán suelen ser un solo caso.
• Tratar la información ausente como una respuesta negativa. Desconocido no es lo mismo que falso.
• Permitir acciones no respaldadas sobre sistemas financieros, legales o de clientes.
• Ocultar la evidencia del resultado.

El futuro del RAG para agentes

Es poco probable que el futuro sea una única arquitectura de retrieval. El patrón que emerge es una capa de información dirigida por herramientas: extracción documental, procesamiento multi-documento, JSON estructurado, contexto Markdown, búsqueda, SQL, APIs, grafos de conocimiento y revisión humana. Las bases vectoriales y los embeddings siguen en ese ecosistema, elegidos para tareas concretas de retrieval y no como infraestructura obligatoria de cada agente.

El RAG tradicional recupera texto parecido. El RAG agéntico da a los agentes las herramientas para obtener, comparar y usar la información adecuada para la tarea. Para quien construye agentes conscientes de documentos, la pregunta estratégica ya no es qué base vectorial usar. Es qué capacidades documentales y de información debe poder llamar el agente.