AWS ajoute à Bedrock le RAG en un seul appel et un mode de récupération seule

Amazon Web Services a annoncé le 9 novembre 2026 qu’Amazon Bedrock Managed Knowledge Base prend désormais en charge la génération augmentée par récupération (RAG) en un seul appel et les requêtes limitées aux passages, par l’intermédiaire de AgenticRetrieveStream. Une plage élargie de 0 à 5 pour maxAgentIteration permet aux applications de choisir entre la récupération de sources, une réponse obtenue après une seule recherche et la récupération agentique existante du service, qui comporte plusieurs étapes.

Cette mise à jour intègre le schéma RAG de base — une récupération suivie de la génération d’une réponse — dans la même API de diffusion en continu que celle utilisée pour les recherches complexes. Le RAG en un seul appel utilise un unique appel au modèle de fondation pour générer la réponse, tandis que les requêtes de récupération seule n’en nécessitent aucun. Selon AWS, le fonctionnement en un seul appel peut réduire la latence et l’utilisation des modèles par rapport à la récupération agentique, mais l’annonce ne fournit aucune comparaison mesurée de la latence ou des coûts.

Un paramètre permet de choisir le mode de récupération

La valeur 0 renvoie les passages correspondants sans générer de réponse ; la valeur 1 effectue une seule récupération et génère une réponse avec generateResponse=true ; et les valeurs de 2 à 5 conservent le comportement agentique existant. Tous les modes prennent en charge plusieurs bases de connaissances. « En un seul appel » désigne donc une seule récupération, et non une restriction à une seule base de connaissances.

Une itération correspond à un appel au modèle de fondation. Lorsque la génération est activée, une limite de n réserve le dernier appel à la génération de la réponse et autorise jusqu’à n moins 1 cycles de planification. Chaque cycle de planification associe la reformulation d’une requête à une récupération. La récupération exploratoire initiale s’effectue avant la planification et n’est jamais prise en compte dans la limite.

Avec la valeur 0, la génération de réponse doit être désactivée. Si elle est activée, une erreur 4xx se produit, car une réponse nécessite un appel au modèle. Avec la valeur 1, le flux transmet une récupération et une réponse étayée, sans événements de suivi de planification. Les requêtes existantes utilisant les valeurs de 2 à 5 restent inchangées.

Fonctionnement en continu et limites d’utilisation

La référence de l’API AgenticRetrieveStream indique messages, retrievers, et agenticRetrieveConfiguration comme paramètres obligatoires de la requête, tandis que generateResponse est facultatif. Les segments de réponse générés ne sont transmis que si la génération est activée. Le résultat final peut contenir les éléments récupérés, une réponse synthétisée et des citations reliant des passages de la réponse aux résultats qui les étayent.

Le fonctionnement en mode récupération seule équivaut à appeler directement Retrieve , mais le format de la réponse diffère : les passages apparaissent dans l’événement result du flux, sans score ni location champs. Les applications qui utilisent déjà AgenticRetrieveStream peuvent ainsi obtenir un comportement de type Retrieveen modifiant un paramètre plutôt qu’en intégrant une API distincte.

Pour les questions complexes, le guide de l’utilisateur d’Amazon Bedrock décrit un processus qui décompose les requêtes en sous-requêtes, vérifie si les éléments récupérés sont suffisants, effectue des recherches supplémentaires et peut étendre la recherche à un document complet. La récupération agentique est compatible uniquement avec les bases de connaissances Bedrock entièrement gérées et autorise jusqu’à cinq moteurs de récupération par requête. Réduire le nombre maximal d’itérations peut mettre fin plus tôt au travail de l’agent et potentiellement diminuer la précision des réponses aux questions complexes.

Les équipes applicatives choisissent et testent le mode

AWS illustre les paramètres à l’aide de l’assistant interne consacré aux règles d’une banque fictive, et non d’un déploiement chez un client. Une question sur la documentation destinée à un entrepreneur individuel utilise maxAgentIteration=1, tandis qu’une comparaison des exigences applicables aux entrepreneurs individuels et aux sociétés à responsabilité limitée (LLC), qui vérifie également les règles concernant les propriétaires non résidents, utilise la valeur 4 et autorise jusqu’à trois cycles de planification. Une demande d’examen du texte des règles utilise la valeur 0 et renvoie les passages sources sans résumé.

L’application doit sélectionner le mode ; maxAgentIteration ne répartit pas automatiquement les requêtes entre les modes. L’assistant présenté en exemple permet de rechercher et de comparer les règles, mais il n’approuve pas les comptes et ne remplace ni l’examen ni l’autorisation de la banque.

Pour préparer l’adoption, AWS recommande de comparer le RAG en un seul appel à la configuration agentique existante, sur la même base de connaissances et à l’aide de questions représentatives et de leurs réponses attendues. L’évaluation devrait mesurer la latence et le coût par requête, vérifier l’exactitude des réponses et leur étayage par les passages récupérés, et inclure des questions nécessitant plusieurs documents ainsi que des questions auxquelles il est impossible de répondre. Ces résultats peuvent aider à choisir la limite d’itérations la plus basse qui satisfait aux exigences de qualité de chaque processus.

Cette modification fait de la profondeur de récupération un choix d’infrastructure explicite pour chaque requête. Les recherches directes peuvent éviter les appels de planification, tandis que les requêtes complexes continuent de bénéficier d’une collecte itérative d’éléments probants. Pour les entreprises, l’enjeu central consiste à déterminer si la réduction de l’utilisation des modèles permet de conserver des réponses complètes et étayées par leurs propres documents, plutôt que de supposer qu’une limite d’itérations plus élevée est toujours préférable.