Agentic RAG: del sistema que responde al que decide

Última entrega del bloque de técnicas de recuperación, de nivel avanzado. Todo lo visto hasta aquí comparte una propiedad: el flujo estaba decidido antes de que llegara la pregunta. Aquí se rompe ese supuesto, y con él se gana capacidad y se pierde previsibilidad. Conviene saber exactamente qué se cambia por qué.

Flujo fijo frente a flujo decidido

En un pipeline convencional, por sofisticado que sea, la secuencia de operaciones está escrita en el código. Se reescribe la consulta, se busca en híbrido, se reordena con un cross-encoder, se generan cinco fragmentos de contexto y se responde. Las técnicas de las entregas anteriores añaden ramas —el bucle de Corrective RAG, el enrutado al grafo— pero esas ramas también están escritas: el ingeniero previó los casos y programó qué hacer en cada uno.

En un sistema agéntico, la secuencia se decide en tiempo de ejecución y la decide el modelo. Se le entrega un conjunto de herramientas —índices, buscadores, APIs, funciones de cálculo—, una descripción de para qué sirve cada una y un objetivo, y el modelo elige qué invocar, con qué argumentos, en qué orden y cuándo parar. El flujo ya no es una propiedad del código, sino del resultado de la ejecución.

El cambio se puede resumir en cuatro decisiones que dejan de ser del programador y pasan a ser del modelo:

• Si recuperar. Para «reformula lo anterior en dos líneas» o «suma estas cifras» no hace falta tocar el índice. Un pipeline fijo recupera igualmente, y mete ruido.
• Con qué consulta. No una reformulación decidida de antemano, sino la consulta que el modelo considera pertinente en ese punto, que puede depender de lo que ya haya encontrado.
• De qué fuente. Índice de documentación, índice de incidencias, base de datos estructurada, grafo, búsqueda web. Cada una con sus datos y su coste.
• Si volver a intentarlo. Al ver los resultados, decidir si bastan o si hace falta otra búsqueda distinta.

Las tres capacidades que aparecen

Enrutado entre fuentes

Es el escalón más modesto y el que más veces se justifica. Una organización rara vez tiene un corpus: tiene varios, con naturalezas distintas. Documentación de producto, histórico de tickets, normativa interna, un CRM, un catálogo en base de datos.

Meterlo todo en un único índice vectorial es un error frecuente: las preguntas sobre normativa recuperan tickets parecidos, y las cifras que viven en una tabla se responden fatal desde texto. El enrutado consiste en que el modelo elija la fuente adecuada, o varias, según la pregunta. Y una de las opciones debe ser ninguna: no todas las peticiones son preguntas sobre el corpus.

Un enrutador es, en su versión mínima, una sola llamada de clasificación antes de recuperar. Aporta mucho y cuesta poco. No hace falta un agente completo para tenerlo.

Recuperación de varios pasos

Aquí está la capacidad genuinamente nueva. En la entrega 17 vimos la descomposición de preguntas compuestas en subconsultas que se lanzan en paralelo. Eso funciona cuando las partes son independientes. No funciona cuando la segunda búsqueda depende del resultado de la primera.

«¿Qué política de teletrabajo se aplica al equipo que dirige la responsable del proyecto Delta?» no se puede descomponer por adelantado, porque para formular la segunda consulta hay que conocer la respuesta de la primera. La secuencia necesaria es:

paso 1  buscar("responsable del proyecto Delta")
        → "Marta Ferrán, directora de operaciones"
paso 2  buscar("equipo a cargo de dirección de operaciones")
        → "Operaciones incluye logística y atención al cliente"
paso 3  buscar("política de teletrabajo del área de operaciones")
        → fragmento con la política aplicable
paso 4  generar respuesta con lo recogido en 1, 2 y 3

Tres búsquedas encadenadas, cada una formulada con lo aprendido en la anterior. Ningún flujo fijo produce esa secuencia, porque su forma depende de los datos y no se conocía al escribir el código. Es el argumento fuerte a favor de los agentes en recuperación, y conviene tenerlo claro porque es prácticamente el único que no admite un sustituto más barato.

Uso de herramientas más allá de buscar

Si el modelo ya decide qué invocar, las herramientas no tienen por qué ser todas de recuperación textual. Consultar una base de datos con SQL para responder cifras exactas, invocar una API para datos que cambian por minutos, ejecutar un cálculo en lugar de pedirle al modelo que aritmética mentalmente, comprobar un dato contra un sistema autoritativo.

Esto cubre una debilidad conocida del RAG clásico: las preguntas cuantitativas. «¿Cuántos pedidos se han retrasado este mes?» no se responde con fragmentos de texto, sino con una consulta a la base de datos. Un sistema con herramientas puede hacerlo; uno de recuperación pura, no.

Control de bucles y presupuesto de pasos

Un sistema que decide cuándo parar puede decidir mal, y ese es su principal riesgo operativo. Los tres modos de fallo son conocidos y se repiten:

• El bucle. El agente busca, no le convence, reformula ligeramente, busca casi lo mismo, tampoco le convence, y así hasta que alguien lo corta. Típico cuando la respuesta no está en el corpus: no hay ninguna reformulación que la haga aparecer, pero el modelo no lo sabe.
• La deriva. Cada paso se aleja un poco del objetivo original hasta que el agente está resolviendo una pregunta parecida pero distinta. Al final produce una respuesta coherente que no contesta lo que se preguntó.
• El gasto desbocado. Sin fallo aparente, una consulta consume quince llamadas al modelo y cuarenta segundos porque el agente decidió ser exhaustivo. La respuesta es buena y la unidad económica, ruinosa.

Las salvaguardas no son opcionales. Un sistema agéntico en producción necesita, como mínimo:

1. Tope duro de pasos. Un máximo de iteraciones que no depende del criterio del modelo. Alcanzado el tope, se responde con lo que haya o se admite que no se ha podido responder.
2. Presupuesto de tokens y de llamadas por consulta. Contabilizado y cortado por el orquestador, no por el agente.
3. Detección de repetición. Si dos consultas consecutivas son casi idénticas o devuelven casi los mismos fragmentos, el bucle no está progresando y hay que cortarlo.
4. Salida explícita de rendición. Igual que en la entrega 19: el sistema tiene que poder decir que no encuentra la respuesta, y eso debe ser un resultado aceptable del flujo, no un fallo.
5. Trazas completas. Registrar cada paso, cada consulta emitida y cada resultado. Sin eso, un fallo en producción es indepurable: sabes que la respuesta fue mala y no sabes en qué paso se torció. La entrega 46 vuelve sobre esto.

El precio

La pérdida de reproducibilidad es la que peor se digiere en producción y la que menos se anticipa. Que la misma pregunta recorra caminos distintos en dos ejecuciones complica el soporte —«a mí ayer me contestó otra cosa» deja de ser un malentendido y pasa a ser cierto—, complica las pruebas de regresión y complica cualquier compromiso de servicio sobre tiempos de respuesta.

La evaluación también cambia de naturaleza. Con un flujo fijo se miden recuperación y generación por separado. Con un agente hay que medir además si eligió bien la fuente, si el número de pasos fue razonable y si el camino tenía sentido. Una respuesta correcta obtenida tras once pasos innecesarios es un fallo que ninguna métrica de calidad de respuesta detecta.

Cuándo se justifica un agente

Cuatro condiciones. Con una sola no basta; con dos o más, empieza a tener sentido.

Hay varias fuentes de naturaleza distinta y la elección entre ellas depende de la pregunta. Con un único corpus homogéneo, no hay nada que enrutar.

Existen preguntas con dependencia secuencial real, del tipo del ejemplo de arriba, y no son una anécdota del 2 % del tráfico. Si son marginales, sale más a cuenta detectarlas y derivarlas a un flujo especializado que agentizar todo el sistema.

El presupuesto de latencia es holgado. Un asistente de análisis en el que esperar veinte segundos es aceptable, sí. Un widget de ayuda en un proceso de compra, no.

El valor por consulta es alto. Un agente cuesta un múltiplo de una consulta simple. En una herramienta interna con cientos de consultas al día que ahorran horas de trabajo, se paga solo. En un canal de atención masiva con cientos de miles de consultas, la aritmética cambia por completo.

Y una advertencia que atraviesa todo este bloque: el agente no arregla una recuperación mala, la ejecuta más veces. Si el índice no encuentra lo que hay que encontrar, un sistema que busca cinco veces obtiene cinco resultados malos, tarda cinco veces más y cuesta cinco veces más. Antes de plantearse un agente hay que tener la recuperación en orden: corpus bien troceado, metadatos, búsqueda híbrida y, si aporta, reranking. Ese orden de trabajo no es negociable.

La progresión sensata, de hecho, es gradual: enrutador primero, que es barato y aporta; después recuperación de varios pasos con tope duro, sólo para las preguntas que la necesiten; después, si acaso, herramientas más allá de la búsqueda. Empezar por el agente completo es la vía rápida a un sistema caro que nadie sabe depurar.

Qué viene ahora

Con esta entrega se cierra el bloque de técnicas de recuperación. Hemos recorrido el camino completo desde la línea base de un paso hasta los sistemas que deciden su propio flujo, y en cada escalón hemos puesto la mejora al lado de su coste, porque la decisión rara vez es técnica en abstracto.

El bloque siguiente baja a los modelos concretos: cómo elegir un modelo de embeddings y qué criterios importan de verdad, comparativa de los comerciales y de los abiertos, qué funciona en español —que no siempre es lo que dicen las tablas generales—, los modelos de reranking disponibles y cómo elegir el modelo generador que redacta la respuesta final.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.