El Modelo Mental de la Pipeline RAG y el Bucle de Agente
Cada página de esta sección, ya sea que cubra LangChain, LlamaIndex, bases de datos vectoriales o el Protocolo de Contexto del Modelo, es un detalle de implementación que se asienta sobre exactamente dos modelos mentales.
El primero es la generación aumentada por recuperación (RAG): una secuencia fija de etapas que convierte un conjunto de documentos en respuestas fundamentadas y citadas.
El segundo es el bucle de agente: un ciclo que permite a un modelo de lenguaje decidir qué hacer a continuación, llamar a una herramienta, observar el resultado y decidir de nuevo.
Comprender estos dos modelos primero hace que cada elección de biblioteca específica (qué almacén vectorial, qué reordenador, qué framework de orquestación) sea una decisión mucho menor de lo que parece inicialmente.
Resumen
- RAG fundamenta la generación en evidencia recuperada a través de una pipeline de fragmentar-incrustar-recuperar-reordenar-generar; los agentes envuelven la generación en un bucle que puede actuar sobre el mundo a través de herramientas.
- Por qué Importa: Ni una llamada a un LLM en bruto ni una única consulta a una base de datos resuelven "responde a esta pregunta usando nuestros datos y realiza una acción"; necesitas una pipeline y un bucle, y la mayoría de los errores provienen de tratar cualquiera de ellos como un solo paso.
- Conceptos Clave: fragmentación (chunking), incrustación (embedding), recuperación (retrieval), reordenación (reranking), generación (generation), bucle de agente (agent loop), uso de herramientas (tool use), fundamentación (grounding).
- Cuándo Usar: Preguntas y respuestas específicas de dominio, búsqueda de conocimiento interno, soporte al cliente sobre documentos privados y cualquier tarea que requiera razonamiento de varios pasos con acciones externas (reservar, consultar, escribir archivos).
- Limitaciones / Compensaciones: RAG solo ayuda cuando la respuesta realmente reside en tu corpus; los bucles de agente equilibran el determinismo y la previsibilidad de costes con la flexibilidad, y ambos añaden etapas de latencia que una única llamada a un modelo no tiene.
- Temas Relacionados: búsqueda vectorial, ingeniería de prompts, llamada a funciones, frameworks de orquestación.
Fundamentos
La generación aumentada por recuperación existe porque los modelos de lenguaje tienen dos límites difíciles: una ventana de contexto fija y una fecha de corte de entrenamiento.
No puedes pegar toda tu base de conocimientos en un prompt, y el modelo no puede conocer documentos escritos después de su entrenamiento.
RAG resuelve ambos recuperando solo la porción relevante de texto en el momento de la consulta y entregándola al modelo como contexto.
La pipeline tiene cinco etapas conceptuales, y cada una existe para corregir un fallo específico de la etapa anterior.
La fragmentación (chunking) divide documentos largos en piezas del tamaño de recuperación, porque incrustar un PDF completo como un solo vector pierde el significado detallado de cualquier párrafo individual dentro de él.
La incrustación (embedding) convierte cada fragmento en un vector, una lista de números que coloca el texto semánticamente similar cerca unos de otros en un espacio de alta dimensionalidad.
La recuperación (retrieval) toma una consulta, la incrusta de la misma manera y encuentra los vectores de fragmentos más cercanos, que es el primer punto real de fallo de la pipeline, ya que "más cercano" no es lo mismo que "correcto".
La reordenación (reranking) toma los principales candidatos de la recuperación y les reasigna puntuaciones con un modelo más caro y más preciso, porque la búsqueda aproximada rápida sobre millones de vectores necesariamente deja los resultados relevantes clasificados más bajo de lo que deberían estar.
La generación (generation) es el paso final, donde el LLM escribe una respuesta utilizando solo el contexto recuperado (y reordenado), idealmente con citas a los fragmentos de origen.
El bucle de agente es un modelo diferente pero complementario.
Donde RAG es una pipeline recta (los datos fluyen en una dirección, una vez), un bucle de agente es un ciclo: el modelo recibe un estado, decide una acción, una acción se ejecuta y el resultado se retroalimenta como nuevo estado.
La imagen mental más simple es un termostato: sentir la temperatura, decidir si calentar o enfriar, actuar, sentir de nuevo.
Para un agente LLM, "sentir" es la conversación y los resultados de herramientas hasta ahora, "decidir" es el modelo eligiendo una llamada a herramienta o una respuesta final, y "actuar" es invocar realmente esa herramienta.
El uso de herramientas (a veces llamado llamada a funciones) es lo que hace que el bucle sea útil: en lugar de que el modelo solo produzca prosa, produce una solicitud estructurada (un nombre de función y argumentos) que tu código ejecuta y retroalimenta como una observación.
Mecánicas e Interacciones
Los dos modelos interactúan constantemente en sistemas reales, porque la herramienta de agente más común es un recuperador RAG.
El paso de "decidir" de un bucle de agente comúnmente se resuelve en "llamar a la herramienta search_docs", lo que activa toda la pipeline RAG, cuya salida se convierte en el paso de "observar" que alimenta la siguiente decisión.
Es por eso que los dos modelos mentales pertenecen a la misma página: RAG sin un bucle es un sistema de Q&A de un solo disparo, y un bucle de agente sin RAG no tiene forma de fundamentar sus acciones en tus datos reales.
Dentro de la pipeline RAG, el modelo de incrustación utilizado en el momento de la indexación y el modelo de incrustación utilizado en el momento de la consulta deben ser el mismo modelo (o al menos compatibles), porque los vectores de diferentes modelos no comparten un espacio de coordenadas.
Este es un detalle mecánico sutil pero crítico: cambiar los modelos de incrustación significa re-incrustar y re-indexar cada fragmento, no solo las nuevas consultas.
La calidad de la recuperación generalmente se describe con recall (¿apareció el fragmento relevante en el conjunto de candidatos?) y precisión (¿cuánto del conjunto de candidatos es realmente relevante?), y estos tiran en direcciones opuestas.
Un top_k más grande mejora el recall pero diluye la precisión y aumenta los tokens enviados al paso de generación, que es exactamente el problema que la reordenación está diseñada para resolver: recuperar de forma amplia y barata, luego acotar de forma precisa y costosa.
En el bucle de agente, el detalle mecánico crítico es la terminación.
Un LLM no sabe inherentemente cuándo dejar de llamar a herramientas, por lo que cada framework de agente real impone un límite: un número máximo de iteraciones, un límite de recursión o una señal explícita de "respuesta final" que el modelo debe emitir.
Sin ese límite, un modelo que sigue decidiendo "necesito más información" llamará a herramientas indefinidamente, quemando coste y tiempo sin una salida natural.
def run_agent_loop(model, tools: dict, state: list, max_steps: int = 8):
for _ in range(max_steps):
decision = model.decide(state) # LLM elige: respuesta o llamada a herramienta
if decision.is_final_answer:
return decision.content
result = tools[decision.tool_name](**decision.args) # actuar
state.append({"tool_result": result}) # observar -> alimenta el próximo decide()
return "detenido: se excedió max_steps" # límite explícito, no un bloqueoEste fragmento no es un agente de producción (frameworks reales como LangGraph manejan ramificaciones, persistencia y llamadas a herramientas paralelas), pero hace explícita la forma del bucle: decidir, actuar, observar, repetir, con una parada forzada.
Consideraciones Avanzadas y Aplicaciones
A escala, ambos modelos desarrollan modos de fallo que no aparecen en una demostración con diez documentos.
Las pipelines RAG construidas sobre un único índice vectorial plano se degradan a medida que el corpus crece a millones de fragmentos, porque la búsqueda aproximada de vecinos más cercanos sacrifica recall por velocidad, y esa compensación empeora a medida que el índice crece a menos que añadas filtrado, búsqueda híbrida (combinando palabras clave/BM25 con similitud vectorial) o recuperación jerárquica.
Los bucles de agente desarrollan un modo de fallo paralelo: a medida que añades más herramientas, el paso de decisión del modelo se vuelve más difícil, porque ahora debe elegir correctamente entre un conjunto de opciones más grande y más ambiguo, y pequeños cambios en el prompt o en la descripción de la herramienta pueden alterar el comportamiento de forma impredecible.
La observabilidad difiere entre los dos modelos.
Las pipelines RAG se depuran inspeccionando qué se recuperó: si la respuesta es incorrecta, la primera pregunta siempre es "¿estuvo el fragmento correcto en el conjunto de candidatos?".
Los bucles de agente se depuran inspeccionando el rastreo de decisiones y llamadas a herramientas, ya que el fallo a menudo está varios pasos antes de la respuesta final incorrecta, no en el último paso en sí.
La seguridad también diverge: la superficie de ataque de RAG es el envenenamiento de datos (contenido malicioso inyectado en el corpus que se recupera y se trata como contexto confiable), mientras que la superficie de ataque de un bucle de agente es la inyección de prompts a través de salidas de herramientas (un resultado de herramienta que en sí mismo contiene instrucciones que el modelo puede seguir).
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| RAG Naive (recuperar + generar una vez) | Simple, baja latencia, fácil de razonar | Sin autocorrección si la recuperación falla | Corpus pequeños y bien curados |
| Recuperación + reordenación | Mayor precisión en consultas ambiguas | Latencia adicional y una segunda llamada al modelo | Corpus más grandes con fragmentos ruidosos |
| RAG Agéntico (el bucle llama a la recuperación como herramienta) | Puede reintentar, reformular consultas, combinar fuentes | Mayor coste, más difícil de limitar y probar | Preguntas de varios saltos, tareas de estilo de investigación |
| Agente de herramienta única fija | Predecible, fácil de aislar | No puede adaptarse a subtareas inesperadas | Automatizaciones bien definidas (una acción, un propósito) |
| Bucle multi-herramienta / multi-agente | Maneja tareas abiertas | Mayor radio de explosión, más difícil de evaluar | Flujos de trabajo complejos con puertas de revisión humana |
Conceptos Erróneos Comunes
- "RAG solo significa añadir una base de datos vectorial." Una base de datos vectorial es un componente de una etapa (recuperación); sin una fragmentación deliberada, un modelo de incrustación coincidente y, a menudo, reordenación, una base de datos vectorial por sí sola produce respuestas mediocres y difíciles de depurar.
- "Más contexto recuperado es siempre mejor." Meter más fragmentos en el prompt aumenta la probabilidad de que texto irrelevante o contradictorio ahogue la respuesta correcta, y cuesta más tokens; el recall y la precisión deben equilibrarse, no maximizarse de forma independiente.
- "Los agentes son autónomos y no supervisados por diseño." Cada bucle de agente de producción tiene un límite explícito: un límite de pasos, una lista blanca de herramientas o una puerta de aprobación humana, porque los bucles ilimitados son un pasivo, no una característica.
- "Un modelo más grande arregla una mala recuperación." Si la información correcta nunca entra en la ventana de contexto, ninguna cantidad de capacidad del modelo la recupera; la calidad de la recuperación es a menudo la solución de mayor apalancamiento sobre el tamaño del modelo.
- "El uso de herramientas es solo salida estructurada." La salida estructurada es necesaria pero no suficiente; el bucle también necesita una condición de terminación, manejo de errores para llamadas a herramientas fallidas y una forma de retroalimentar resultados como nuevo estado.
Preguntas Frecuentes
¿Cuál es la diferencia entre RAG y simplemente ajustar un modelo con mis datos?
- El ajuste fino (fine-tuning) integra el conocimiento en los pesos del modelo y es lento de actualizar.
- RAG recupera contexto fresco en el momento de la consulta, por lo que actualizar el corpus actualiza las respuestas inmediatamente.
- La mayoría de los sistemas de producción combinan ambos: ajuste fino para estilo/formato, RAG para hechos.
¿Por qué necesito fragmentación en absoluto? ¿Por qué no incrustar documentos enteros?
Una incrustación de documento completo mezcla muchos temas diferentes en un solo vector, por lo que una consulta sobre un párrafo no coincidirá de manera fiable. La fragmentación mantiene cada vector enfocado en una unidad de significado coherente.
¿Qué tan grande debe ser un fragmento?
No hay un número universal; depende del contexto efectivo del modelo de incrustación y la granularidad de tu contenido. La mayoría de los equipos comienzan con unos pocos cientos de tokens con una superposición modesta y ajustan según los resultados de la evaluación de recuperación.
¿Qué añade realmente un reordenador sobre la búsqueda vectorial?
La búsqueda vectorial utiliza un pase de incrustación para aproximar la relevancia rápidamente en un índice enorme. Un reordenador ejecuta un modelo más caro sobre solo la lista corta, cruzando la consulta y cada candidato directamente, lo que produce una ordenación más precisa a una escala mucho menor.
¿Es un "agente" solo un chatbot con plugins?
No exactamente. Un chatbot con plugins puede llamar a una herramienta por turno bajo dirección humana. Un bucle de agente puede tomar múltiples decisiones internas y llamadas a herramientas antes de producir una única respuesta final, sin un humano entre cada paso.
¿Cómo "decide" realmente el modelo llamar a una herramienta?
Al modelo se le dan esquemas de herramientas (nombre, descripción, tipos de argumentos) junto con la conversación, y está entrenado/prompted para emitir una llamada estructurada en lugar de prosa cuando una herramienta coincide con la tarea. El código de llamada luego ejecuta la función real.
¿Qué impide que un bucle de agente se ejecute para siempre?
Un límite explícito establecido por el desarrollador: un número máximo de iteraciones o recursiones, un presupuesto de tokens/coste, o una señal requerida de "respuesta final" que el modelo debe producir para salir del bucle.
¿Cuándo NO debería usar un bucle de agente?
- Cuando la tarea es una búsqueda única y bien definida (RAG simple es más rápido, más barato y más predecible).
- Cuando no puedes tolerar latencia o coste variable por solicitud.
- Cuando el espacio de acción es lo suficientemente pequeño como para codificarlo como un script lineal.
¿Se pueden usar RAG y bucles de agente sin el otro?
Sí. RAG simple (recuperar una vez, generar una vez) no necesita ningún bucle. Un bucle de agente puede existir sin ninguna recuperación, utilizando solo otras herramientas como una calculadora o una API de calendario.
¿Qué significa "fundamentación" (grounding) en este contexto?
Fundamentación significa que la respuesta del modelo está ligada a evidencia recuperada específica en lugar de generada puramente a partir de sus datos de entrenamiento, que es lo que hace posibles las citas y la reducción de alucinaciones.
¿Por qué existen frameworks como LangChain, LlamaIndex y LangGraph si los modelos son los mismos?
Implementan los mismos dos modelos mentales con diferentes ergonomías: LlamaIndex se inclina hacia la conveniencia de carga y indexación de datos, LangChain hacia cadenas componibles, y LangGraph hacia bucles explícitos con estado y ciclos. Los conceptos subyacentes de pipeline y bucle no cambian.
¿Cuál es el error más común en un sistema RAG?
Una falta de coincidencia o deriva entre el modelo de incrustación utilizado en el momento de la indexación frente al momento de la consulta, o una estrategia de fragmentación que divide la respuesta real en dos fragmentos separados de modo que ninguno por sí solo se recupera como totalmente relevante.
Relacionados
- Fundamentos de RAG - recorrido práctico de la pipeline de fragmentar-incrustar-recuperar-generar
- Recuperación y Reordenación - mecánicas más profundas de las etapas de recuperación y reordenación
- Bases de Datos Vectoriales - dónde se almacenan y buscan las incrustaciones
- LangGraph y Bucles de Agente - implementación del bucle de agente como un grafo de estado
- Uso de Herramientas y Llamada a Funciones - las mecánicas detrás del paso "actuar"
- Evaluación y Barreras de Seguridad - medición de la calidad de la recuperación y del agente
Versiones de la Pila: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.