Agentes IA crecen 14x: Claix replantea el RAG vectorial

El RAG vectorial se queda corto cuando el agente decide por sí mismo

El dato lo publicó Opsin Labs en agosto de 2026: las interacciones de empleados con agentes de IA crecieron 14x entre enero y junio de ese año. La cifra importa porque cambia el problema de fondo. Cuando un agente pasa de demo a producción y empieza a manejar casos de negocio reales —aprobar una factura, cruzar un contrato con su última enmienda, comparar una orden de compra con un albarán— la cadena fija de "buscar en una base vectorial y responder" deja de aguantar.

Claix, una startup de procesamiento documental para agentes, publicó esta semana un argumento directo contra esa cadena fija: el futuro del RAG no es universal, es agéntico. Retrieval se convierte en una herramienta más entre SQL, APIs, grafos de conocimiento, extracción estructurada y revisión humana. El agente elige cuándo y cómo usarla.

Qué cambia entre el RAG tradicional y el RAG agéntico

En el RAG tradicional el flujo es fijo: pregunta del usuario, embedding, retrieval de chunks, prompt con el contexto, respuesta. Una pasada, una base vectorial, un resultado. En el RAG agéntico el flujo lo decide el propio agente:

• Planifica qué información necesita.
• Elige qué herramienta invocar (búsqueda, extracción, comparación de documentos, SQL, API).
• Evalúa si el resultado es suficiente.
• Itera: formula una sub-pregunta, llama a otra herramienta o pide revisión humana.
• Actúa o responde solo cuando tiene evidencia.

Como resume la guía de Microsoft sobre agentic RAG, el patrón se aleja del pipeline retrieve-then-generate y entra en dynamic query planning, multi-step reasoning y autonomous information gathering. LangChain lo describe igual: un agente puede usar uno o más tools para obtener conocimiento externo en lugar de depender de una cadena de retrieval predefinida.

Las cuatro debilidades concretas del vector RAG

Claix las enumera, y son las que más duelen en producción:

1. El chunking rompe la estructura del documento. Una fila de tabla sin sus encabezados ya no es una tabla. Una cláusula de contrato sin la sección de definiciones puede inducir a error. Un párrafo suelto de una política puede contradecir una excepción tres páginas más adelante.
2. Los embeddings miden similitud, no relevancia de negocio. "Busca texto parecido" no es lo mismo que "verifica si la factura coincide con la orden de compra en proveedor, cantidad, precio unitario, IVA, total y moneda". Una búsqueda vectorial devuelve contexto similar; no realiza la comparación.
3. Una sola llamada de retrieval suele quedarse corta. Un flujo real es multi-paso: localizar el contrato, buscar la última enmienda, leer la cláusula de renovación, comparar fechas, determinar si hay que avisar y crear el recordatorio. Un pipeline fijo retrieve-then-answer no fue diseñado para eso.
4. La infraestructura vectorial no es gratis. Ingesta, parseo, chunking, embeddings, indexado, versionado, control de acceso, reprocesado cuando cambia el formato. Marcos como LlamaIndex y LangChain simplifican partes del proceso, pero no eliminan las decisiones de fondo.

Dónde siguen mandando las bases vectoriales

No todo se va a vector. Snyk, en su State of Agentic AI Adoption Report de agosto de 2026, encontró que el 46,9% de las organizaciones que usan IA ya desplegó arquitecturas agentic (agentes, servidores MCP, o ambos). Pero al mismo tiempo los modelos open-source representaron el 32,5% de los despliegues y los propietarios el 63,8%, según el mismo informe. Los vectores siguen siendo la pieza por defecto para retrieval semántico a gran escala.

Las bases vectoriales siguen siendo la mejor opción cuando:

• Hay millones de segmentos de documentos y consulta repetida de alta frecuencia.
• La colección de conocimiento es permanente y compartida.
• El producto central es búsqueda semántica o descubrimiento por similitud.
• Se necesitan políticas de filtrado y acceso sofisticadas.

La pregunta ya no es "vectores sí o no", sino qué operación de información requiere la tarea.

El menú de alternativas al vector RAG

Claix agrupa las alternativas en seis familias que un agente puede orquestar:

• Extracción estructurada: convertir un documento en campos conocidos (proveedor, total, IVA, vencimiento) que se validan contra reglas de negocio.
• Procesamiento directo del documento: enviar el archivo completo al modelo en lugar de pre-indexarlo, útil para archivos subidos para una sola tarea.
• Procesamiento multi-documento: comparar varios PDFs a la vez (factura + orden de compra + albarán) y devolver match o mismatch.
• SQL y grafos: para preguntas estructuradas del tipo "¿qué proveedores están sobre su límite de crédito?" o "¿qué entidades se relacionan con esta cuenta?".
• APIs y sistemas internos: CRM, ERP, knowledge bases internas conectadas como tools sin reindexar en vectores.
• Revisión humana: para ambigüedad, datos sensibles o excepciones regulatorias.

Progress Software dio el mismo giro por la vía enterprise el 1 de octubre de 2026: anunció nuevas capacidades en su plataforma Progress Agentic RAG, incluyendo un Smart Agent para retrieval multi-paso con soporte nativo de Model Context Protocol (MCP). El sector entero se mueve en esta dirección.

Qué significa esto para tu startup

Si estás construyendo un producto con agentes IA que tocan documentos —legal, finanzas, onboarding, soporte, salud, operaciones— la decisión de arquitectura ya no se resuelve con "instalemos Pinecone". Tres movimientos concretos que podés aplicar esta semana:

1. Audita qué hace tu agente hoy con cada documento. Si la operación natural es comparar campos entre archivos, validar contra reglas o cruzar información estructurada, una capa de extracción estructurada o procesamiento multi-documento va a darte mejor resultado y menos alucinaciones que un índice vectorial. Documentá qué tipo de operación requiere cada caso de uso antes de elegir la tecnología.
2. Diseña el retrieval como catálogo de tools, no como pipeline. En lugar de "primero retrieval, después generación", exponé a tu agente un conjunto explícito de capacidades: extract_fields(), compare_documents(), query_sql(), search_web(), request_human_review(). Esto encaja con cómo orquestan los frameworks modernos (LangGraph, Mastra, Haystack, DSPy) y con cómo los proveedores enterprise (Progress, Opsin, los stacks de MCP) ya están entregando la infraestructura.
3. No construyas la base vectorial antes de entender el comportamiento del documento. El error más caro en 2025 fue invertir meses en indexar todo para descubrir después que el caso de uso necesitaba comparación entre archivos o extracción a JSON. Empezá por una capa de procesamiento documental directa (Markdown estructurado para contexto, JSON estructurado para tools) y reservá la base vectorial para los casos donde la búsqueda semántica a gran escala sea realmente el producto central.

Conclusión

El RAG vectorial no desaparece: sigue siendo la pieza correcta para descubrimiento semántico a gran escala sobre colecciones permanentes. Lo que cambia es que deja de ser el centro. En 2026 el patrón por defecto para agentes que actúan sobre documentos es agéntico: el agente decide cuándo recuperar, de dónde y si necesita llamar a otra herramienta antes de responder. Para un founder, eso significa que la pregunta estratégica dejó de ser "¿qué base vectorial uso?" y pasó a ser "¿qué conjunto de capacidades de información necesita mi agente para hacer bien su trabajo?".

Fuentes

• We Built an Alternative to Vector RAG for AI Agent Memory — Claix
• Opsin Labs Report: 60% of Enterprise AI Agents Are Over-Permissioned as Adoption Accelerates 14x — Yahoo Finance / Business Wire
• Progress Software Connects Enterprise Knowledge Across Business Systems with New Agentic RAG Capabilities — Taiwan News / Globe Newswire
• Your enterprise AI footprint is about three times bigger than your model list — Help Net Security / Snyk