AWS incorpora RAG de una sola pasada y un modo de solo recuperación en Bedrock

Amazon Web Services anunció el 9 de noviembre de 2026 que Amazon Bedrock Managed Knowledge Base ahora admite la generación aumentada por recuperación (RAG) de una sola pasada y las solicitudes que devuelven solo pasajes a través de AgenticRetrieveStream. Un rango ampliado de 0–5 para maxAgentIteration permite a las aplicaciones elegir entre recuperar fuentes, generar una respuesta a partir de una sola búsqueda o usar la recuperación agéntica de varios pasos que ya ofrecía el servicio.

La actualización incorpora el patrón básico de RAG —una recuperación seguida de una respuesta generada— a la misma API de streaming que se usa para búsquedas complejas. El RAG de una sola pasada requiere una llamada al modelo fundacional para generar la respuesta, mientras que las solicitudes de solo recuperación no requieren ninguna. AWS afirma que la operación de una sola pasada puede reducir la latencia y el uso de modelos frente a la recuperación agéntica, pero el anuncio no ofrece comparaciones cuantificadas de latencia ni de costos.

Un parámetro selecciona el modo de recuperación

El valor 0 devuelve pasajes coincidentes sin generar una respuesta; el valor 1 realiza una recuperación y genera una respuesta con generateResponse=true; y los valores del 2 al 5 mantienen el comportamiento agéntico existente. Todos los modos admiten varias bases de conocimiento. Por tanto, «de una sola pasada» se refiere a una única recuperación, no a una limitación a una sola base de conocimiento.

Una iteración equivale a una llamada al modelo fundacional. Cuando la generación está habilitada, un límite de n reserva la llamada final para generar la respuesta y permite hasta n menos 1 rondas de planificación. Cada ronda de planificación combina una reformulación de la consulta con una recuperación. La recuperación especulativa inicial se ejecuta antes de la planificación y nunca se contabiliza dentro del límite.

Con el valor 0, la generación de respuestas debe estar desactivada. Si se activa, se produce un error 4xx, porque generar una respuesta requiere una llamada al modelo. Con el valor 1, el flujo incluye una recuperación y una respuesta fundamentada, sin eventos de seguimiento de planificación. Las solicitudes existentes que usan valores del 2 al 5 no cambian.

Comportamiento del flujo y límites operativos

La documentación de referencia de la API AgenticRetrieveStream indica que messages, retrievers, y que agenticRetrieveConfiguration son entradas obligatorias de la solicitud, mientras que generateResponse es opcional. Los fragmentos de la respuesta generada se emiten solo cuando la generación está habilitada. El resultado final puede incluir elementos recuperados, una respuesta sintetizada y citas que vinculan fragmentos de la respuesta con los resultados que la respaldan.

La operación de solo recuperación equivale a llamar directamente a Retrieve , pero el formato de la respuesta es distinto: los pasajes aparecen en el evento del flujo result sin score ni location Las aplicaciones que ya usan AgenticRetrieveStream pueden, por tanto, obtener un comportamiento Retrievesimilar cambiando un parámetro, en lugar de integrar una API independiente.

Para las preguntas complejas, la Guía del usuario de Amazon Bedrock describe un flujo de trabajo que descompone las consultas en subconsultas, comprueba si las pruebas recuperadas son suficientes, realiza búsquedas adicionales y puede ampliarse hasta abarcar un documento completo. La recuperación agéntica solo admite bases de conocimiento de Bedrock totalmente administradas y permite hasta cinco recuperadores por solicitud. Reducir el límite de iteraciones puede hacer que el agente se detenga antes y, potencialmente, disminuir la precisión en consultas complejas.

Los equipos de aplicaciones eligen y prueban el modo

AWS ilustra los ajustes con un asistente interno de políticas de un banco ficticio, no con una implementación para un cliente. Para una consulta sobre la documentación de una empresa unipersonal se usa maxAgentIteration=1, mientras que una comparación de los requisitos para empresas unipersonales y sociedades de responsabilidad limitada (LLC) que también comprueba las normas aplicables a propietarios no residentes usa el valor 4, lo que permite hasta tres rondas de planificación. Una solicitud para examinar el texto de una política usa el valor 0 y devuelve pasajes de las fuentes sin un resumen.

La aplicación debe seleccionar el modo; maxAgentIteration no dirige las solicitudes automáticamente. El asistente del ejemplo permite consultar y comparar políticas, pero no aprueba cuentas ni sustituye la revisión y autorización del banco.

Para implementar la solución, AWS recomienda comparar el RAG de una sola pasada con la configuración agéntica existente en la misma base de conocimiento, utilizando preguntas representativas y sus respuestas esperadas. La evaluación debe medir la latencia y el costo por solicitud, comprobar la corrección de las respuestas y que los pasajes recuperados las respalden, e incluir preguntas que requieran varios documentos y preguntas sin respuesta posible. Los resultados pueden servir para elegir el límite de iteraciones más bajo que satisfaga los requisitos de calidad de cada flujo de trabajo.

El cambio convierte la profundidad de la recuperación en una decisión explícita de infraestructura para cada solicitud. Las consultas directas pueden prescindir de las llamadas de planificación, mientras que las consultas complejas mantienen la recopilación iterativa de pruebas. Para las empresas, la disyuntiva fundamental es determinar si reducir el uso de modelos permite conservar respuestas completas y respaldadas por sus propios documentos, en lugar de dar por sentado que un límite de iteraciones más alto siempre es mejor.