Sus usuarios hacen preguntas exploratorias, comparativas y de varias partes que abarcan archivos PDF, diapositivas, tickets, transcripciones y contenido web. La recuperación clásica de un solo disparo se desmorona en estas preguntas. Las respuestas pierden el contexto, los tickets de soporte aumentan y los analistas pierden horas volviendo a ejecutar búsquedas. La recuperación agente para las bases de conocimiento administradas de Amazon Bedrock está diseñada para estas preguntas.
Considere dos preguntas que podría hacer un analista: "Compare nuestra estrategia para 2020 y 2023. ¿Qué cambió?" y "¿Cuáles son los tres mayores riesgos en todas las líneas de productos?" Tampoco lo es una búsqueda de un solo disparo. Una pregunta con múltiples intenciones no tiene un único objetivo para incrustar un espacio que la represente bien, por lo que los fragmentos top-k regresan como un promedio de subintenciones en competencia.
La recuperación agente planea e itera sobre la recuperación y puede generar una respuesta en la misma llamada. Esta publicación se centra en por qué la recuperación clásica no responde a preguntas de varias partes, cómo funciona la API AgenticRetrieveStream (incluida la construcción de solicitudes y el análisis de seguimiento) y cuándo elegirla en lugar de la API de recuperación estándar.
Por qué la recuperación de un solo disparo se queda corta
Un ejemplo elaborado concreta la brecha. Supongamos que ha ingerido 25 años de cartas de accionistas de Amazon en una base de conocimiento administrada. Tu primera pregunta es directa:
“¿Cuál es el mensaje más importante de los documentos?”
La API de recuperación estándar devuelve cinco fragmentos por puntuación híbrida. En nuestro corpus de prueba, el resultado superior es de alta puntuación pero de bajo valor: cubre la combinación de colores del logotipo de Amazon. Los siguientes fragmentos cubren la contratación, los constructores y la diferenciación. El recuperador hizo su trabajo y clasificó por similitud con la consulta incrustada. Pero el “mensaje más importante” es vago y el anotador no tiene señal de lo que importa.
Ahora pase a una pregunta realista:
"Compare cómo Amazon habló sobre contratación, inversión a largo plazo y obsesión por el cliente en 2020 con 2023. ¿Dónde cambió el énfasis?"
La recuperación de un solo disparo ahora debe cumplir con tres intenciones en dos períodos de tiempo con un vector de consulta. Obtiene uno de dos resultados: una dispersión de fragmentos poco relacionados o un grupo reducido dominado por la señal más fuerte. Tampoco lo es lo que haría un analista humano.
Lo que haría un analista humano
Un humano descompondría la pregunta. Buscarían contratación en 2020, luego contratación en 2023 y luego filosofía de inversión cada año. Leerían los resultados, notarían lagunas, refinarían la búsqueda y la ejecutarían nuevamente. Con suficiente evidencia en mano, sintetizarían.
La recuperación agente automatiza este flujo de trabajo como una API.
Huecos que deja la recuperación de un solo disparo
Preguntas de varias partes: es posible que una sola incrustación no represente bien una consulta con múltiples intenciones, por lo que los mejores resultados tienden a combinar intenciones. Razonamiento comparativo: “Comparar A y B en la dimensión X” requiere una recuperación específica por elemento, no una búsqueda combinada. Preguntas de fuentes cruzadas: cuando la evidencia abarca múltiples bases de conocimiento, las reglas de enrutamiento estático son frágiles y es posible que no se adapten bien a cada consulta. Suficiencia: la recuperación clásica no juzga "suficiente". Devuelve k fragmentos independientemente. Exploración: algunas preguntas necesitan búsquedas de seguimiento basadas en lo que revelan los primeros resultados. La recuperación de un solo disparo no se puede iterar.
Los equipos han abordado esta brecha con marcos de agentes personalizados creados en la API de Retrieve. Solicitan un modelo para planificar y llamar a Retrieve API en un bucle, gestionar subconsultas, deduplicar y decidir cuándo detenerse. Funciona, pero se convierte en una instalación personalizada en cada aplicación, y cada instancia conlleva sus propios riesgos de latencia, costo y confiabilidad.
¿Qué es la recuperación agente?
La recuperación de Agentic es un nuevo modo de recuperación en las bases de conocimiento administradas de Amazon Bedrock, disponible a través de la API AgenticRetrieveStream. En lugar de una búsqueda de similitud, ejecuta un ciclo de planificación impulsado por un modelo básico: el modelo descompone su pregunta, la recupera en cada parte, juzga si tiene suficiente evidencia y repite según sea necesario. Genera una respuesta fundamentada por defecto en la misma llamada. Establezca generateResponse=False para devolver resultados de recuperación sin generar una respuesta.
Usted ve cada paso de ese bucle como un flujo ordenado de eventos de seguimiento. Cada evento conlleva un paso y un estado, para que puedas ver qué hizo el planificador y por qué:
SpeculativeRetrieval: una recuperación inicial que se ejecuta antes del primer paso de planificación para reducir la latencia de un extremo a otro. Con un solo KB, utiliza la consulta de usuario sin formato. Con varias KB, se trata de una búsqueda de sondeo que se utiliza para enrutar subconsultas. No cuenta para maxAgentIteration. Planificación: el modelo básico (FM) analiza la consulta, revisa los resultados anteriores y emite subconsultas alineadas con intenciones recuperables. Entre iteraciones, aquí también es donde el modelo juzga la suficiencia y decide si detenerse o buscar nuevamente. Recuperación o FullDocumentExpansion: un evento por ejecución de subconsulta, cada uno con su propio estado. En la recuperación agente, esta acción/evento puede recuperar un documento completo si el agente determina que el contexto del pasaje es insuficiente para responder la consulta. A menudo, las consultas que requieren resúmenes, enumerar elementos o información de varias partes de un documento se benefician de esta acción. El bucle puede ejecutar varias iteraciones si se necesita más evidencia, limitada por maxAgentIteration. Resultado: El evento final. Contiene los fragmentos de origen deduplicados recopilados a lo largo de las iteraciones. Para solicitudes de varios KB, cada fragmento identifica su sourceRetriever. Debido a que la generación de respuestas está habilitada de forma predeterminada, el evento de resultado también contiene la respuesta fundamentada y las citas, a menos que establezca generateResponse=False.
Una nota sobre la deduplicación y el rastreo. La deduplicación se aplica únicamente al evento del resultado final. Cuando varias subconsultas recuperan el mismo fragmento, ese fragmento aparece solo una vez en los resultados finales. Los eventos de seguimiento permanecen disponibles para revisar los pasos individuales de planificación y recuperación.
Dos parámetros realizan la mayor parte del ajuste. El primero es maxAgentIteration, el límite máximo de iteraciones de planificación y recuperación. Utilice 3 para un solo KB y 4-5 para consultas comparativas o de varios KB, aunque el planificador puede salir temprano después de que su paso de evaluación encuentre que la evidencia es suficiente. Consulte Cuotas y límites para valores predeterminados y máximos.
El segundo es la configuración del modelo básico. El campo FoundationModelType determina si la recuperación agente utiliza el modelo administrado por servicio o un modelo personalizado. Cuando lo configure en PERSONALIZADO, proporcione el modelo a través de FoundationModelConfiguration.
Nota sobre los precios: la recuperación de Agentic tiene un precio por llamada y el modelo que elija para la orquestación establece la tarifa. Con el modelo administrado, usted paga $4 por cada 1000 llamadas de recuperación de agentes más $1 por cada 1000 llamadas de API de recuperación subyacentes. Si elige un modelo disponible en Amazon Bedrock, paga el precio estándar de transferencia de Bedrock por ese modelo más el mismo $1 por cada 1000 llamadas de Retrieve subyacentes. Vea más detalles en la página de precios.
Tutorial de API
Ahora que ha visto cómo funciona el ciclo de planificación, examinamos la API AgenticRetrieveStream en la práctica.
Base de conocimiento única
El caso más directo: un KB, una consulta, deje que el planificador se descomponga. Usted envía la solicitud y luego consume la secuencia, que entrega eventos de seguimiento, fragmentos de respuesta generada cuando la generación de respuesta está habilitada y un evento de resultado final.
Ese es el ciclo completo: una solicitud, sin código de orquestación y una secuencia que se lee de arriba a abajo. Los eventos de seguimiento le dicen lo que hizo el planificador. El evento de resultado le proporciona los fragmentos deduplicados. En producción, registre estos eventos de seguimiento en Amazon CloudWatch para la atribución de costos, el presupuesto de latencia y la depuración. Cada iteración es una invocación del planificador más sus recuperaciones de subconsultas, por lo que el número de iteraciones es lo que impulsa tanto el costo como la latencia del reloj de pared.
Múltiples bases de conocimiento
El enrutamiento de múltiples KB es lo que hace la recuperación agente que las otras API no pueden. Registre hasta cinco recuperadores de KB administrados en una solicitud y adjunte una descripción en lenguaje natural a cada uno. El planificador lee esas descripciones para enrutar cada subconsulta a la KB más relevante.
Consumes la transmisión de la misma manera. La decisión de enrutamiento aparece en el resultado: cada fragmento lleva un ID de sourceRetriever, por lo que puede ver qué KB respondió a qué subconsulta. Las descripciones son el contrato por el que se dirige el planificador, así que escriba cada una como una frase de una sola frase para su base de conocimiento. Las descripciones vagas conducen a rutas vagas.
Elegir la API de recuperación adecuada
Las bases de conocimiento administradas le brindan dos superficies de consulta: Retrieve y AgenticRetrieveStream. Eliges según la forma de la pregunta.
Utilice Recuperar para preguntas breves y de amplio alcance en las que una búsqueda de similitud sea suficiente. No tiene planificador, tiene el costo por llamada más bajo y la latencia más ajustada, y usted mantiene control total sobre cómo genera una respuesta.
Utilice AgenticRetrieveStream cuando las preguntas sean de varias partes, comparativas, exploratorias o abarquen múltiples bases de conocimiento. Descompone la pregunta, recupera por intención, evalúa la suficiencia y puede generar una respuesta fundamentada en la misma llamada, o devolver fragmentos para que los sintetice con un modelo que usted controle. Cuesta más y lleva más tiempo porque realiza múltiples llamadas de modelos, pero encuentra evidencia que una sola búsqueda puede pasar por alto.
Característica Recuperar Salida de AgenticRetrieveStream Fragmentos sin procesar + puntajes de relevancia Fragmentos deduplicados (transmisión), respuesta fundamentada opcional Compatibilidad con múltiples KB No Sí, hasta 5. Descomposición de consultas No Sí Solo sincronización de transmisión Siempre Tamaño de consulta del usuario, texto en inglés (caracteres) 10 000 10 000 Costo por llamada del modelo básico Ninguno Invocaciones múltiples Latencia Mínima Mínima KB autoadministrado (VECTOR) Sí No (Solo base de conocimiento administrada) Puntuaciones de relevancia En los resultados directamente Solo en eventos de seguimiento Reclasificación Opcional Opcional (un reclasificador entre recuperadores) Barandillas compatibles Solo BLOQUE (MASCARA no compatible)
Cómo se desempeña la recuperación agente en los puntos de referencia
Evaluamos la recuperación de agentes en MuSiQue (Trivedi et al., 2022), un punto de referencia público de preguntas de múltiples saltos. En estas preguntas, mostró una mejora absoluta en la recuperación del 20 por ciento con respecto a la recuperación de un solo disparo, con las mayores ganancias en las preguntas más difíciles. Las preguntas de un solo salto muestran ganancias menores (menos de cinco puntos).
Cada pregunta de MuSiQue está diseñada para requerir dos, tres o cuatro pasos de recuperación, y un anotador humano identificó la cadena de documentos exacta necesaria para responderla. Esa cadena es una descomposición de un oráculo: el plan de recuperación ideal para comparar.
Complejidad de la pregunta Δ (ganancia) con Agentic Retrieve Agentic Hops (promedio) Preguntas de 2 saltos +22,8 1,98 Preguntas de 3 saltos +31,9 3,50 Preguntas de 4 saltos +37,3 4,78
Destacan dos patrones. En primer lugar, cuanto más difícil sea la pregunta, mayor será la ganancia. Cuantos más pasos requiere una pregunta, más se pierde una búsqueda y más recuperación agencial se recupera. Las preguntas que requieren varios pasos simplemente no pueden responderse de una sola vez.
En segundo lugar, el sistema toma tantos pasos como la pregunta realmente necesita. El punto de referencia nos dice el número ideal de pasos para cada pregunta (la cadena que trazó un experto humano). El número de pasos de la recuperación agente se mantiene aproximadamente dentro de uno de ese ideal, por lo que busca lo suficiente para responder la pregunta sin desviarse.
Ejemplo
Demostramos cómo la recuperación agente resuelve una consulta de 4 saltos en el conjunto de datos de MuSiQue.
Consulta: “¿Cuándo llegó el explorador a la sede del grupo del que forma parte el sello discográfico Study in Brown?”
Seguimiento de recuperación agente:
Hop Documentos de oro recuperados (sobre) 0 Estudio en Brown 1 Emarcy Records 2 The Right Stuff Records 3 4 Santa Mónica California
Ilustramos el proceso de recuperación utilizando el siguiente gráfico t-SNE sobre el espacio de representación del corpus. Muestra cómo se comparan los resultados de la recuperación de un solo paso (límite de puntos rojos) con la recuperación agente de varios pasos. En cada salto, la recuperación agente desglosa la consulta. Llega al documento que contiene la respuesta.
Mejores prácticas
Estas prácticas reducen los costos, mejoran la latencia y mantienen la recuperación agente predecible en producción.
Comience con un modelo de planificador pequeño y rápido. La recuperación de agentes realiza muchas llamadas breves. Un planificador grande rara vez justifica la latencia. Establezca maxAgentIteration según el alcance. Utilice 3 para un solo KB, 4–5 para varios KB. Mida y luego afine. Escriba descripciones de perros perdigueros, como marketing de productos. Sea específico, concreto y distintivo. Transmita el seguimiento a Amazon CloudWatch Logs con un ID de correlación por solicitud. Esto admite reproducción y depuración. Planifique los costos por iteraciones, no solo por tokens. Las iteraciones impulsan tanto el costo como la latencia del reloj de pared. Combinar con reclasificación. La recuperación agente puede utilizar un modelo de reclasificación para mejorar la relevancia de los resultados recuperados. Para AgenticRetrieveStream, configure la reclasificación a través de agenticRetrieveConfiguration.rerankingModelType. Cuando utilice un modelo de reclasificación personalizado, proporcione su configuración a través de agenticRetrieveConfiguration.rerankingConfiguration. Trate los resultados como evidencia, no como una respuesta. Sintetiza con un modelo que controlas para que puedas imponer el tono, las citas y las barreras de seguridad.
Seguridad, gobernanza y observabilidad
La recuperación agente hereda el modelo de acceso de las bases de conocimiento administradas. La entidad principal de AWS Identity and Access Management (IAM) que llama necesita cuatro acciones: bedrock:AgenticRetrieveStream para invocar la transmisión; bedrock:Retrieve y bedrock:GetDocumentContent, con alcance a ARN específicos de la base de conocimientos, para recuperar pasajes y el contenido completo del documento; y bedrock:InvokeModelWithResponseStream para invocar el modelo del planificador y transmitir la respuesta generada. Para conocer la política y la configuración completas, consulte la documentación.
Dos detalles son específicos de la recuperación agente y vale la pena mencionarlos. Las barandillas se configuran a través de PolicyConfiguration.bedrockGuardrailConfiguration y solo se admite la acción BLOQUEAR; la acción MÁSCARA no es compatible con la recuperación agente. Debido a que el planificador genera subconsultas intermedias, es tan importante auditar esas subconsultas como los resultados finales. Registre el seguimiento completo en Amazon CloudWatch para poder revisar lo que buscó el planificador, no solo lo que devolvió.
Para mayor observabilidad, las bases de conocimiento administradas emiten métricas de CloudWatch para invocaciones, errores de cliente, errores de servidor y limitaciones. AgenticRetrieveStream también emite la métrica TotalIterationCount. La telemetría de la base de conocimientos administrada se integra con Amazon Bedrock AgentCore Observability. Consulte la documentación para obtener la lista completa de métricas, espacios de nombres y opciones de enrutamiento de registros.
Conclusión
Esta publicación explicó por qué la recuperación de una sola vez se queda corta en preguntas de varias partes, presentó la API AgenticRetrieveStream y mostró cuándo elegirla en lugar de la recuperación estándar. La recuperación agente traslada la planificación, la iteración y la evaluación de suficiencia al servicio de bases de conocimiento administradas, de modo que obtiene una API única y observable con seguridad, registro y comportamiento de costos consistentes en lugar de una orquestación personalizada en cada aplicación.
Comience con Retrieve para búsquedas directas y utilice AgenticRetrieveStream cuando los usuarios hagan preguntas de varias partes, comparativas o exploratorias, o cuando la evidencia abarque múltiples bases de conocimiento. Para crear su primera base de conocimientos agentes, siga el cuaderno complementario en GitHub. Para obtener detalles sobre la API, consulte la referencia de la API AgenticRetrieveStream o explore la función en la consola de Amazon Bedrock.
Sobre los autores
Omar Elkharbotly
Omar es arquitecto senior de soluciones especializado en GenAI/ML en AWS. Trabaja con clientes empresariales en todo el Reino Unido e Irlanda para diseñar e implementar soluciones de aprendizaje automático e inteligencia artificial generativa utilizando Amazon Bedrock, Amazon Bedrock AgentCore y la pila más amplia de IA/ML de AWS para crear aplicaciones escalables y listas para producción.
Shreya Pawaskar
Shreya es consultora de entrega especializada en IA/ML en AWS Professional Services. Ayuda a los clientes empresariales a diseñar e implementar soluciones de IA generativa y de recuperación de agentes en Amazon Bedrock. Tiene una maestría en Ciencias de la Computación de la Universidad de California, Irvine. Fuera del trabajo, le gusta caminar por los senderos del Área de la Bahía y descubrir nuevos restaurantes.
Sailik Sengupta
Sailik es científico senior en el equipo de Agentic AI en AWS. Se especializan en el diseño de sistemas de recuperación y reclasificación a gran escala, y en la alineación y decodificación de modelos lingüísticos. Tienen un doctorado. en Ciencias de la Computación de la Universidad Estatal de Arizona y obtuvo un doctorado en IBM. Beca por su trabajo en ciberdefensas impulsadas por IA. Su trabajo abarca la alineación de grandes modelos de lenguaje, modelos integrados, teoría de juegos, planificación automatizada de tareas y ciberseguridad, con contribuciones publicadas en lugares como ACL, ICLR, NAACL, AAAI, EMNLP, NeurIPS, etc. Fuera del trabajo, le encanta viajar, caminar y leer libros.