Amazon Bedrock añade modos de RAG de una sola pasada y solo recuperación

Amazon Web Services ha actualizado su Base de Conocimientos Gestionada de Bedrock para admitir tres modos distintos de recuperación a través de un único punto final de API. Lanzado el 9 de noviembre de 2026, este cambio permite a los desarrolladores elegir entre planificación agéntica, generación de una sola pasada o recuperación de pasajes en bruto ajustando un único parámetro. Esta actualización busca reducir la latencia y el costo para consultas simples mientras preserva las capacidades de razonamiento profundo para tareas complejas.

Qué ocurrió

Anteriormente, los desarrolladores que creaban aplicaciones de generación aumentada por recuperación (RAG) sobre Amazon Bedrock debían gestionar rutas de código o APIs separadas para diferentes tipos de preguntas de usuario. Las búsquedas simples, como encontrar un elemento específico de una lista de verificación, requerían la misma orquestación pesada que las preguntas comparativas complejas que necesitaban múltiples iteraciones de búsqueda. Este enfoque de talla única para todos a menudo resultaba en latencia innecesaria y mayor uso del modelo para solicitudes directas.

La nueva actualización introduce el parámetro maxAgentIteration en la API AgenticRetrieveStream, con un rango de 0 a 5. Esta única configuración controla el comportamiento del proceso de recuperación. Al establecer el valor en 1, los desarrolladores pueden activar "RAG de una sola pasada", que realiza una recuperación y genera una respuesta sin ninguna planificación agéntica ni reescritura de consultas. Establecerlo en 0 habilita el modo "solo recuperación", que devuelve pasajes fuente sin invocar ningún modelo fundacional. Los valores de 2 a 5 retienen el comportamiento existente de recuperación agéntica, donde el sistema planifica y ejecuta múltiples rondas de búsqueda.

Esta consolidación significa que las aplicaciones ya no necesitan integrar una segunda API ni mantener ramas de lógica separadas para consultas simples frente a complejas. El servicio gestiona el flujo de trabajo internamente, permitiendo a los desarrolladores adaptar el esfuerzo de recuperación a las necesidades específicas de cada solicitud dinámicamente. Como se señala en el anuncio, "Las aplicaciones no necesitan implementar su propio bucle para coordinar estos pasos".

Cómo funciona

El mecanismo central depende de cómo el sistema cuenta las iteraciones. Una iteración equivale a una llamada al modelo fundacional. El proceso siempre concluye con una llamada final para generar la respuesta si la generación de respuestas está habilitada. Por lo tanto, un valor de maxAgentIteration de n permite hasta n menos 1 rondas de planificación agéntica, reservando la última iteración para la generación de la respuesta final. Es importante notar que la recuperación especulativa, que se ejecuta antes del primer paso de planificación para acelerar el proceso, no cuenta contra este límite.

Cuando maxAgentIteration se establece en 1, el sistema omite completamente la fase de planificación. Recupera pasajes relevantes una vez basándose en la consulta original e inmediatamente los pasa al modelo fundacional para la generación de la respuesta. Esto es ideal para preguntas bien definidas donde la respuesta existe en un solo documento o sección. Cuando se establece en 0, el sistema realiza una recuperación garantizada pero omite por completo la llamada al modelo fundacional, devolviendo solo los pasajes de texto en bruto. Esto es equivalente a llamar directamente a la API Retrieve pero mantiene el flujo de trabajo dentro de la interfaz AgenticRetrieveStream.

Para valores entre 2 y 5, el modelo fundacional actúa como planificador. Descompone preguntas complejas en subconsultas, evalúa la evidencia recuperada y decide si se necesitan más búsquedas. Este proceso iterativo ayuda a abordar lagunas en la información, haciéndolo adecuado para preguntas de varias partes o comparaciones entre documentos diferentes. El desarrollador selecciona el modo mediante la lógica de la aplicación, en lugar de depender del enrutamiento automático por parte del parámetro mismo.

Detalles clave

• El parámetro maxAgentIteration ahora acepta valores de 0 a 5, reemplazando el rango limitado anterior.
• Establecer maxAgentIteration=1 habilita RAG de una sola pasada, realizando una recuperación y una generación de respuesta sin rondas de planificación.
• Establecer maxAgentIteration=0 habilita el modo solo recuperación, devolviendo pasajes sin llamadas al modelo fundacional; generateResponse debe ser false.
• La recuperación agéntica (valores 2–5) permite hasta n menos 1 rondas de planificación, apoyando la descomposición de consultas y la recopilación iterativa de evidencia.
• Los tres modos admiten múltiples bases de conocimiento, lo que significa que la recuperación de una sola pasada no está limitada a una única fuente de datos.
• La recuperación especulativa, que ocurre antes del primer paso de planificación, no cuenta hacia el límite de maxAgentIteration.

Por qué importa

Para ingenieros de software que construyen asistentes de IA, esta actualización simplifica la arquitectura y mejora la eficiencia de costos. Anteriormente, optimizar para respuestas de baja latencia en consultas simples podría haber requerido construir un pipeline de recuperación ligero separado junto con un sistema agéntico más complejo. Ahora, una sola llamada a la API puede manejar ambos escenarios. Esto reduce la sobrecarga operativa de mantener múltiples integraciones y asegura un manejo consistente de citas y eventos de trazabilidad en todos los tipos de consultas.

La capacidad de alternar entre modos también proporciona un control más fino sobre el equilibrio entre velocidad y precisión. En aplicaciones de alto volumen, como bots de soporte al cliente o herramientas internas de búsqueda empresarial, la mayoría de las consultas probablemente sean comprobaciones simples de hechos. Usar RAG de una sola pasada para estas solicitudes reduce el consumo de tokens y el tiempo de respuesta. Para la minoría de consultas complejas que requieren cruzar referencias entre múltiples documentos, los desarrolladores pueden aumentar dinámicamente el límite de iteraciones para asegurar exhaustividad. Esta flexibilidad permite una mejor asignación de recursos y una experiencia de usuario más receptiva.

Qué puedes hacer

• Actualiza tus llamadas a AgenticRetrieveStream para incluir el parámetro maxAgentIteration en el objeto agenticRetrieveConfiguration.
• Establece maxAgentIteration=1 y generateResponse=true para preguntas directas y bien definidas para habilitar RAG de una sola pasada.
• Establece maxAgentIteration=0 y generateResponse=false cuando necesites mostrar pasajes fuente a los usuarios sin generar un resumen de IA.
• Usa valores de 2 a 5 para preguntas complejas de varias partes que requieran comparar información entre documentos o bases de conocimiento diferentes.
• Prueba diferentes límites de iteración con preguntas representativas para encontrar el equilibrio óptimo entre latencia y calidad de respuesta para tu caso de uso específico.
• Asegúrate de que la lógica de tu aplicación determine el modo apropiado basado en la complejidad de la consulta, en lugar de depender de que la API lo detecte automáticamente.