RAG agéntica frente a RAG tradicional: ¿cuándo merece la pena un agente?

El RAG tradicional debería ser la opción predeterminada para la mayoría de las aplicaciones de recuperación. Es más fácil de probar, más rápido de ejecutar y más predecible en producción. El RAG agéntico resulta rentable cuando responder a una pregunta requiere que el sistema decida qué buscar, divida la tarea en pasos dependientes, evalúe pruebas incompletas o cambie las estrategias de recuperación en tiempo de ejecución.

En este artículo, RAG agéntico se refiere a un sistema RAG en el que un modelo puede influir en las decisiones de recuperación en tiempo de ejecución. No implica automáticamente múltiples agentes, un uso ilimitado de herramientas o un bucle de razonamiento abierto.

Por tanto, la cuestión práctica entre el RAG agéntico y el RAG tradicional no es qué arquitectura es más avanzada. Se trata de determinar si las decisiones de recuperación en tiempo de ejecución mejoran suficientes consultas complejas como para justificar la latencia añadida, el coste, la carga de pruebas y el riesgo operativo.

Cómo responden a la misma pregunta el RAG tradicional y el RAG agéntico

La arquitectura original de generación aumentada por recuperación combina documentos recuperados con el conocimiento interno de un modelo de lenguaje. En una implementación de producción típica, la aplicación sigue una secuencia fija:

1. Recibir la pregunta del usuario.

2. Convertir la pregunta en un embedding o consulta de búsqueda.

3. Recuperar un número fijo de fragmentos.

4. Reordenar opcionalmente los fragmentos.

5. Enviar el contexto seleccionado al modelo.

6. Generar una respuesta.

Considere esta solicitud:

Compare las condiciones de cancelación de nuestro acuerdo empresarial con la política de soporte actual y explique qué norma se aplica a un cliente que renovó el mes pasado.

Una canalización de RAG tradicional puede recuperar los fragmentos principales para la pregunta completa y pedirle al modelo que responda a partir de ellos. Esto puede funcionar si el acuerdo y la política pertinentes están bien indexados y los fragmentos recuperados contienen las fechas y condiciones necesarias.

Un flujo de trabajo de RAG agéntico puede abordar la misma solicitud como un problema de pruebas. Puede:

1. Identificar la versión del acuerdo del cliente y la fecha de renovación.

2. Recuperar la cláusula de cancelación aplicable.

3. Buscar la política de soporte actual por separado.

4. Comprobar si alguno de los documentos contiene una excepción por fecha de entrada en vigor.

5. Comparar las pruebas.

6. Recuperar de nuevo si falta un dato necesario.

7. Generar una respuesta con las citas de respaldo correspondientes.

La diferencia no radica simplemente en que el RAG agéntico ejecute más búsquedas. El agente puede decidir qué acción de recuperación debe llevarse a cabo a continuación en función de las pruebas ya recopiladas.

Qué aporta un agente al proceso de recuperación

Una canalización fija ejecuta las decisiones de recuperación que los desarrolladores definieron previamente. Un agente añade una capa de decisión en tiempo de ejecución entre la solicitud del usuario y la respuesta final.

Descomposición de consultas

Una solicitud compleja puede contener varias necesidades de pruebas que no deben comprimirse en una sola consulta de búsqueda. Un agente puede dividir la solicitud en subconsultas y recuperar pruebas para cada parte.

La recuperación adaptada a la conversación también puede utilizar turnos anteriores para crear subconsultas específicas y combinar sus resultados para solicitudes complejas. Sin embargo, ejecutar múltiples consultas suele añadir latencia en comparación con una canalización de una sola consulta.

Selección de fuentes y herramientas

Una misma aplicación puede tener acceso a documentación de productos, registros de clientes, bases de datos de políticas, herramientas SQL, búsquedas web o API internas. Un agente puede elegir la fuente aprobada con más probabilidades de responder a cada subproblema.

Esta capacidad solo resulta valiosa cuando la elección es significativa. Si cada pregunta debe buscar en el mismo índice de documentos, un enrutador basado en reglas o aprendizaje automático puede ser más sencillo que un agente.

Evaluación de pruebas

Recuperar fragmentos no garantiza que las pruebas sean completas, pertinentes, actuales o coherentes internamente. Un agente puede comprobar si el contexto recuperado cubre las afirmaciones requeridas antes de generar una respuesta.

Recuperar el mismo número de fragmentos para cada solicitud puede añadir contexto irrelevante cuando las pruebas externas son innecesarias o los primeros resultados son débiles. La recuperación adaptativa y la autorreflexión permiten que el sistema decida cuándo es necesaria la recuperación y evalúe las pruebas antes de responder. Un paso de recuperación correctivo puede activar una acción de recuperación diferente cuando el contexto inicial es insuficiente.

Reintentos condicionales

Un agente acotado puede modificar su siguiente acción cuando la recuperación falla. Podría:

• Reescribir una consulta que no arrojó resultados útiles.

• Aplicar un filtro de fecha, región, cuenta o producto.

• Cambiar de búsqueda vectorial a búsqueda por palabras clave o híbrida.

• Recuperar un documento principal cuando un fragmento carezca de contexto.

• Pedir al usuario un dato que falta.

• Detenerse e informar de que las pruebas disponibles son insuficientes.

Estas acciones aportan valor cuando los fallos requieren respuestas diferentes. Repetir la misma búsqueda con pequeñas modificaciones en la redacción no es suficiente para justificar una arquitectura agéntica.

Cuándo es suficiente una canalización de recuperación fija

El RAG tradicional suele ser suficiente cuando la ruta de recuperación se conoce antes de que llegue la solicitud.

Utilice una canalización fija cuando:

• Las preguntas procedan de una base de conocimiento única y estable.

• La mayoría de las solicitudes contengan una necesidad de información clara.

• Los filtros de metadatos se puedan derivar de forma determinista.

• Una sola pasada de recuperación y reordenación suela devolver suficientes pruebas.

• El formato de output requerido sea coherente.

• Una latencia baja y predecible sea prioritaria.

• Los fallos se puedan gestionar con alternativas predefinidas.

• La aplicación deba ser fácil de probar y auditar.

Un asistente de soporte que responda a preguntas sobre la configuración del producto es un ejemplo típico. Si cada solicitud se puede gestionar mediante recuperación híbrida, filtrado de metadatos, reordenación y una instrucción de respuesta fundamentada, añadir un modelo de planificación puede generar más sobrecarga que valor.

Antes de introducir un agente, asocie el fallo observado con el cambio útil más pequeño posible.

Esta progresión es importante porque muchos supuestos problemas de RAG agéntico son en realidad problemas de calidad de recuperación. Una fragmentación deficiente, la falta de metadatos, controles de acceso débiles o un modelo de embedding inadecuado no se resolverán de forma fiable añadiendo un planificador.

Cuándo justifica un agente la recuperación en varios pasos

El RAG agéntico resulta útil cuando la siguiente búsqueda no se puede seleccionar correctamente hasta que el sistema ve el resultado de una búsqueda anterior.

Un agente acotado es especialmente útil cuando se cumplen tres condiciones:

1. La consulta contiene múltiples requisitos de pruebas.

2. Los pasos de recuperación presentan dependencias.

3. El sistema puede definir una condición de parada clara.

Si las búsquedas son independientes y se conocen de antemano, la aplicación a menudo puede ejecutarlas en paralelo sin necesidad de un agente. Si no existe una regla de parada fiable, un agente puede aumentar el coste y la latencia sin mejorar la respuesta de forma constante.

La decisión debe basarse en los resultados de la evaluación y no en preferencias de arquitectura. Cree un conjunto de datos que contenga preguntas sencillas, ambiguas, multifuente, con sensibilidad temporal y con pruebas insuficientes. Compare ambos sistemas en cuanto a:

• Tasa de aceptación de respuestas

• Exhaustividad de las pruebas

• Precisión de las citas

• Tasa de afirmaciones no fundamentadas

• Latencia mediana y de cola

• Número de llamadas de recuperación

• Coste de modelo e infraestructura

• Precisión de escalado o abstención

Utilice una métrica de coste operativo que incluya los intentos infructuosos:

Coste por respuesta aceptada = (Coste de inferencia del modelo + coste de recuperación e infraestructura) ÷ Número de respuestas que superan los criterios de aceptación

Un mayor coste por solicitud puede seguir estando justificado si el agente produce sustancialmente más respuestas aceptadas en tareas de gran valor. La comparación también debe separar las solicitudes sencillas de las complejas. De lo contrario, las mejoras en un segmento reducido de consultas difíciles pueden quedar ocultas dentro de la media general.

Construir un flujo de trabajo de RAG agéntico acotado

El diseño de producción más seguro no suele ser un agente totalmente autónomo. Es un flujo de trabajo restringido con herramientas aprobadas, estado explícito, reintentos limitados y reglas de parada aplicadas por la aplicación.

1. Comenzar con una ruta de recuperación determinista

Ejecute primero la canalización de recuperación habitual. Si las pruebas iniciales cumplen con los criterios de aceptación, genere la respuesta sin activar el agente.

Esto mantiene la rapidez para las preguntas rutinarias y reserva las llamadas adicionales al modelo para aquellas solicitudes que las necesitan.

2. Definir el requisito de pruebas

Antes de la recuperación, convierta la solicitud en un plan de pruebas reducido. El plan debe describir lo que se debe encontrar, sin generar una larga cadena de razonamiento.

Para el ejemplo del acuerdo, los requisitos de pruebas pueden ser:

• La versión de contrato aplicable

• La fecha de renovación del cliente

• La cláusula de cancelación

• La política de soporte actual

• Cualquier norma de fecha de entrada en vigor o de prelación

3. Limitar las acciones disponibles

Exponga únicamente las herramientas necesarias para el flujo de trabajo. Las acciones de recuperación comunes incluyen:

• search_documents

• search_by_metadata

• fetch_document_section

• query_approved_database

• check_evidence

• request_clarification

Cada acción de recuperación debe aplicar el alcance de autorización del usuario. El modelo nunca debe decidir a qué documentos tiene permiso de acceso un usuario.

4. Aplicar límites en el código de la aplicación

Las instrucciones del prompt no son límites de control fiables. El recuento de pasos, los tiempos de espera, los permisos de las fuentes y los límites de reintentos deben aplicarse fuera del modelo.

5. Mantener el estado explícito

El flujo de trabajo debe registrar:

• La pregunta normalizada

• Los requisitos de pruebas

• Las consultas ya intentadas

• Las fuentes consultadas

• Los fragmentos recuperados y sus identificadores

• Las pruebas ausentes

• Los errores de las herramientas

• El presupuesto de pasos restante

• El estado de la respuesta final

Un estado explícito reduce las búsquedas repetidas y facilita la inspección de fallos.

El siguiente pseudocódigo constituye un ejemplo arquitectónico y no una implementación ejecutable completa:

def answer_with_bounded_rag(user_query, user):
    question = normalize_query(user_query)
    source_scope = authorized_sources(user)

    initial_evidence = retrieve(
        query=question,
        sources=source_scope,
        limit=8,
    )

    if evidence_is_sufficient(question, initial_evidence):
        return generate_grounded_answer(question, initial_evidence)

    plan = build_evidence_plan(
        question=question,
        max_items=3,
    )

    evidence = list(initial_evidence)
    attempted_queries = {question}

    for step in range(3):
        gap = next_unresolved_evidence_item(plan, evidence)

        if gap is None:
            break

        query = create_targeted_query(gap, evidence)

        if query in attempted_queries:
            break

        attempted_queries.add(query)

        new_evidence = retrieve(
            query=query,
            sources=source_scope,
            limit=5,
        )

        evidence.extend(new_evidence)

        if evidence_is_sufficient(question, evidence):
            return generate_grounded_answer(question, evidence)

    return abstain_or_request_clarification(
        question=question,
        evidence=evidence,
        missing_items=find_missing_evidence(plan, evidence),
    )

def answer_with_bounded_rag(user_query, user):
    question = normalize_query(user_query)
    source_scope = authorized_sources(user)

    initial_evidence = retrieve(
        query=question,
        sources=source_scope,
        limit=8,
    )

    if evidence_is_sufficient(question, initial_evidence):
        return generate_grounded_answer(question, initial_evidence)

    plan = build_evidence_plan(
        question=question,
        max_items=3,
    )

    evidence = list(initial_evidence)
    attempted_queries = {question}

    for step in range(3):
        gap = next_unresolved_evidence_item(plan, evidence)

        if gap is None:
            break

        query = create_targeted_query(gap, evidence)

        if query in attempted_queries:
            break

        attempted_queries.add(query)

        new_evidence = retrieve(
            query=query,
            sources=source_scope,
            limit=5,
        )

        evidence.extend(new_evidence)

        if evidence_is_sufficient(question, evidence):
            return generate_grounded_answer(question, evidence)

    return abstain_or_request_clarification(
        question=question,
        evidence=evidence,
        missing_items=find_missing_evidence(plan, evidence),
    )

def answer_with_bounded_rag(user_query, user):
    question = normalize_query(user_query)
    source_scope = authorized_sources(user)

    initial_evidence = retrieve(
        query=question,
        sources=source_scope,
        limit=8,
    )

    if evidence_is_sufficient(question, initial_evidence):
        return generate_grounded_answer(question, initial_evidence)

    plan = build_evidence_plan(
        question=question,
        max_items=3,
    )

    evidence = list(initial_evidence)
    attempted_queries = {question}

    for step in range(3):
        gap = next_unresolved_evidence_item(plan, evidence)

        if gap is None:
            break

        query = create_targeted_query(gap, evidence)

        if query in attempted_queries:
            break

        attempted_queries.add(query)

        new_evidence = retrieve(
            query=query,
            sources=source_scope,
            limit=5,
        )

        evidence.extend(new_evidence)

        if evidence_is_sufficient(question, evidence):
            return generate_grounded_answer(question, evidence)

    return abstain_or_request_clarification(
        question=question,
        evidence=evidence,
        missing_items=find_missing_evidence(plan, evidence),
    )

La aplicación, y no el modelo, controla el límite del bucle y la autorización de las fuentes. El verificador de pruebas debe evaluar si los hechos requeridos están respaldados, no simplemente si la recuperación devolvió fragmentos.

6. Conectar las acciones de recuperación a través de la API del modelo

En SiliconFlow, una aplicación puede proporcionar definiciones de funciones mediante la API de Chat Completions e inspeccionar las tool_calls devueltas antes de ejecutar una acción de recuperación aprobada.

Un bucle de orquestación práctico debería:

1. Enviar la solicitud del usuario y las definiciones de herramientas disponibles.

2. Validar el nombre de la herramienta y los argumentos devueltos.

3. Comprobar la autorización antes de acceder a cualquier fuente.

4. Ejecutar la herramienta en el código de la aplicación.

5. Devolver el resultado de la herramienta al modelo.

6. Detenerse cuando las pruebas sean suficientes o se haya agotado el presupuesto de pasos.

La compatibilidad de herramientas y los parámetros relacionados pueden variar según el modelo alojado. Confirme que el modelo de SiliconFlow seleccionado admita el comportamiento de llamada a herramientas requerido antes de utilizarlo en producción.

7. Tratar el contenido recuperado como Input no confiable

Los archivos y páginas web recuperados pueden contener inyecciones indirectas de instrucciones que intenten anular las directrices del sistema o influir en la selección de herramientas.

Reduzca este riesgo mediante:

• La separación de las instrucciones del sistema del contenido recuperado.

• La identificación del texto recuperado como pruebas en lugar de instrucciones.

• La creación de listas de permitidos para herramientas y estructuras de argumentos.

• La validación de los argumentos de herramientas generados por el modelo.

• La aplicación de permisos fuera del modelo.

• La prevención de que el texto recuperado amplíe el conjunto de herramientas.

• La exigencia de aprobación para acciones irreversibles o sensibles.

• El registro de las decisiones de recuperación y de herramientas para su posterior revisión.

Un agente de recuperación debe recopilar y evaluar pruebas. No debe obtener mayor autoridad simplemente porque un documento recuperado le pida realizar otra acción.

8. Enrutar solo las consultas que necesitan un agente

Un sistema de producción no tiene por qué elegir una única arquitectura para cada solicitud. Un diseño de enrutamiento práctico puede utilizar:

• RAG tradicional para preguntas claras y de fuente única

• Recuperación correctiva para resultados deficientes en la primera pasada

• RAG agéntico para la recopilación de pruebas dependiente y en varios pasos

• Escalado a humanos para casos sensibles o no resueltos

Este enfoque híbrido limita el coste del agente y su superficie de fallo, al tiempo que preserva su valor para las preguntas más difíciles.

Preguntas frecuentes

¿Deberían el planificador y el generador de respuestas utilizar el mismo modelo?

No necesariamente. Un modelo más pequeño puede ser suficiente para la clasificación de consultas, la descomposición o el enrutamiento de fuentes, mientras que otro modelo gestiona la respuesta final. Evalúe cada función por separado, ya que la precisión de la planificación, el uso de herramientas, la latencia y la calidad de la respuesta son requisitos distintos.

¿Debería un sistema de RAG agéntico guardar su estado entre solicitudes?

Solo cuando las solicitudes posteriores dependan realmente del trabajo previo. Conserve hechos estructurados, identificadores de fuentes, permisos y tareas pendientes en lugar de un historial de razonamiento ilimitado. Vuelva a validar la información almacenada cuando las políticas, los documentos, el acceso de los usuarios o los datos de origen hayan podido cambiar.

¿Se pueden almacenar en caché los resultados de RAG agéntico?

Sí. Almacene en caché resultados de recuperación deterministas, consultas normalizadas, versiones de documentos y outputs intermedios aprobados cuando proceda. Incluya las versiones de las fuentes y el alcance de autorización en la clave de caché para que no se entregue a un usuario contenido obsoleto o pruebas permitidas exclusivamente para otro usuario.

¿Qué debe ocurrir cuando falla una llamada a una herramienta?

Clasifique el fallo antes de reintentar. Los tiempos de espera transitorios pueden permitir un reintento acotado, mientras que los argumentos no válidos deben corregirse o rechazarse. Los fallos de permisos deben detener el proceso de inmediato. Si las pruebas necesarias siguen sin estar disponibles, el sistema debe pedir aclaraciones, abstenerse o escalar en lugar de hacer suposiciones.

¿Requiere el RAG agéntico una base de datos vectorial?

No. Un flujo de trabajo de RAG agéntico puede utilizar búsqueda vectorial, búsqueda por palabras clave, SQL, consultas de grafos, API o combinaciones de estas fuentes. La característica definitoria es el control en tiempo de ejecución sobre las decisiones de recuperación, no una base de datos o un método de recuperación específico.

El RAG tradicional sigue siendo el mejor punto de partida cuando la ruta de recuperación es estable y una sola pasada bien diseñada puede proporcionar suficientes pruebas. Utilice el RAG agéntico cuando las preguntas complejas requieran búsquedas dependientes, comprobaciones de pruebas o acciones de recuperación condicionales. Mantenga el flujo de trabajo acotado, enrute solo las consultas que lo necesiten y juzgue la complejidad añadida en función de la calidad de las respuestas aceptadas, la latencia y el coste operativo total.