Agentic RAG: el LLM decide buscar 1-7 veces

Le pedimos al LLM que responda. También le pedimos que decida cuántas veces buscar antes de responder. ¿Cuántas veces? Depende de la pregunta — y ahí empieza el problema.

Agentic RAG es esa arquitectura donde el LLM decide autónomamente su propia estrategia de búsqueda. No es RAG mejorado. Es una decisión diferente, con costos diferentes y con problemas diferentes que el RAG clásico. Este texto explica cuándo tiene sentido y dónde se rompe.

RAG clásico vs Agentic RAG en una tabla

	RAG clásico	Agentic RAG
Búsquedas por pregunta	1 fija	1 a N (el LLM decide)
Estrategia de búsqueda	Similitud vectorial	LLM planifica y ajusta
Latencia por pregunta	Baja, constante	Alta, variable
Costo por pregunta	Bajo, constante	Alto, variable
Alucinaciones	Depende del retrieval	Bajan (más contexto)

El eje que cambia todo es “1 fija” vs “1 a N”. Es el LLM decidiendo el número.

Cómo el LLM decide N

En un Agentic RAG mínimo, el flujo es este:

El LLM lee la pregunta
El LLM emite un plan de búsqueda — qué buscar, con qué herramienta (vector search, keyword search, grep local, web search)
Ejecuta la primera búsqueda
Evalúa el resultado: ¿tengo lo suficiente para responder?
Si sí, responde. Si no, refina el plan y repite desde 3

En la práctica, N tiende a estar entre 1 y 7 por pregunta. La distribución no es uniforme: preguntas simples resuelven en 1, preguntas ambiguas o sobre código legacy tienden a los valores altos. El LLM no sabe N por adelantado — lo descubre iterando.

Por qué cambia la latencia, el costo y las alucinaciones

Latencia: cada iteración es un round-trip al LLM más una búsqueda. Si N=3, tienes 3× la latencia base. Para un chat interactivo, esto se nota.

Costo: cada iteración quema tokens de entrada (contexto acumulado) y salida (plan + evaluación). Duplicar o triplicar el costo por respuesta vs RAG clásico es realista, según qué tan seguido el bucle itera. La cuenta llega.

Alucinaciones: acá está el trade-off que justifica todo lo anterior. Cuando el LLM puede buscar de nuevo con una consulta refinada, deja de inventar. Varios benchmarks públicos recientes muestran ganancias claras de precisión al pasar de RAG clásico a Agentic RAG — la magnitud depende mucho del dataset (algunos reportan saltos del orden de 20-30 puntos en tareas multi-hop, otros menos), pero la dirección se repite. Ese es el número que importa cuando la respuesta va a producción.

Los tres patrones de arquitectura

No todos los Agentic RAG son iguales. Hay tres patrones principales.

Patrón 1: agente único

Un LLM, varias herramientas de búsqueda. El agente decide qué herramienta usar en cada paso. Es la implementación más simple.

Cuándo: dominios acotados, base de documentos coherente. Cuándo no: cuando las fuentes son muy distintas entre sí (académicas + código + foros + APIs).

Patrón 2: multi-agente colaborativo

Agentes especialistas (uno para papers académicos, otro para código de GitHub, otro para foros), coordinados por un orquestador.

Cuándo: preguntas que necesitan cruzar dominios (por ejemplo, “¿hay algún paper que valide lo que este repositorio hace?”). Cuándo no: preguntas simples. El overhead de coordinación mata la latencia.

Patrón 3: jerárquico

Un master agent delega a supervisores por dominio (técnico, negocio, datos), que delegan a especialistas. Es la versión “enterprise”.

Cuándo: sistemas grandes con requisitos de governance y trazabilidad. Cuándo no: proyectos individuales o de equipo chico. La complejidad no se paga.

Un contraejemplo importante: Claude Code eligió no usar RAG

El detalle que a mí me sorprendió: el equipo de Claude Code, después de probar RAG vectorial para búsqueda de código, lo descartó. Boris Cherny, uno de los devs, reportó en X que las versiones tempranas de Claude Code usaban RAG con una vector db local, pero descubrieron rápido que la búsqueda agéntica funciona mejor en su dominio — además de ser más simple y no arrastrar los problemas de seguridad, privacidad, staleness y confiabilidad.

¿Por qué? Búsqueda de código es diferente de búsqueda de documentos. En código, los nombres de función y los mensajes de error son claves exactas, no conceptos semánticos. Grep gana porque coincide exacto. El RAG vectorial pierde porque encuentra “cosas parecidas” cuando lo que necesitas es la línea exacta.

La lección para tu propio Agentic RAG: la elección de las herramientas de búsqueda importa más que la arquitectura del bucle. Si tu dominio es texto no estructurado, vector search + bucle agéntico funciona. Si tu dominio es código, grep + LLM plan funciona mejor y cuesta la mitad.

Si estás decidiendo entre RAG clásico y GraphRAG antes de siquiera pensar en Agentic, este artículo tiene la comparación de costos.

Cuándo elegir Agentic RAG

Una regla simple que uso:

¿Las preguntas son ambiguas o multi-parte? → Agentic
¿Las respuestas incorrectas causan daño (médico, legal, financiero)? → Agentic
¿La latencia importa más que la precisión? → RAG clásico
¿El presupuesto de tokens es fijo? → RAG clásico

Si dos de las cuatro salen “Agentic”, probablemente vale la pena el costo extra. Si tres o cuatro salen “clásico”, quédate con RAG estático — no todo problema necesita que el LLM decida cuántas veces buscar.

Herramientas concretas para empezar

En 2026, cuatro API de búsqueda dominan el segmento AI-native:

Tavily: diseñado para agentes, más simple de integrar. Empieza aquí
Exa: búsqueda vectorial semántica de alta precisión. Bueno para papers
Perplexity: búsqueda + razonamiento en un paso. Útil cuando la síntesis es lo que buscas
Brave Search: enfoque en privacidad. Si los datos no pueden salir de tu contexto, esta

Para el bucle en sí, LangGraph y LlamaIndex son las dos opciones principales. LangGraph gana en control de estado y ramificación condicional. LlamaIndex gana en ingesta de datos y manejo de índices.

Yo empecé con Tavily + LangGraph. En una tarde ya tenía un bucle funcional con búsqueda web + evaluación básica. Si tu meta es entender el patrón, ese es un buen punto de partida.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev