Amazon Bedrock ajoute les modes RAG en une passe et récupération seule

Amazon Web Services a mis à jour sa base de connaissances gérée Bedrock pour prendre en charge trois modes de récupération distincts via un seul point de terminaison API. Publiée le 9 novembre 2026, cette modification permet aux développeurs de choisir entre la planification agentique, la génération en une passe ou la récupération brute de passages en ajustant un seul paramètre. Cette mise à jour vise à réduire la latence et les coûts pour les requêtes simples tout en préservant les capacités de raisonnement approfondi pour les tâches complexes.

Ce qui s'est passé

Auparavant, les développeurs créant des applications de génération augmentée par récupération (RAG) sur Amazon Bedrock devaient gérer des chemins de code ou des API séparés pour différents types de questions utilisateur. Les recherches simples, comme trouver un élément spécifique dans une liste de contrôle, nécessitaient la même orchestration lourde que les questions comparatives complexes exigeant plusieurs itérations de recherche. Cette approche universelle entraînait souvent une latence inutile et une utilisation accrue du modèle pour les demandes directes.

La nouvelle mise à jour introduit le paramètre maxAgentIteration dans l'API AgenticRetrieveStream, avec une plage allant de 0 à 5. Ce réglage unique contrôle le comportement du processus de récupération. En définissant la valeur sur 1, les développeurs peuvent déclencher le « RAG en une passe », qui effectue une seule récupération et génère une réponse sans aucune planification agentique ni réécriture de requête. La définir sur 0 active le mode « récupération seule », qui renvoie les passages sources sans faire appel à un modèle fondamental. Les valeurs de 2 à 5 conservent le comportement existant de récupération agentique, où le système planifie et exécute plusieurs tours de recherche.

Cette consolidation signifie que les applications n'ont plus besoin d'intégrer une seconde API ni de maintenir des branches logiques séparées pour les requêtes simples par rapport aux complexes. Le service gère le flux de travail en interne, permettant aux développeurs d'adapter dynamiquement l'effort de récupération aux besoins spécifiques de chaque demande. Comme indiqué dans l'annonce, « Les applications n'ont pas besoin d'implémenter leur propre boucle pour coordonner ces étapes. »

Comment cela fonctionne

Le mécanisme central repose sur la manière dont le système compte les itérations. Une itération équivaut à un appel au modèle fondamental. Le processus se termine toujours par un appel final pour générer la réponse si la génération de réponse est activée. Par conséquent, une valeur maxAgentIteration de n autorise jusqu'à n moins 1 tours de planification agentique, la dernière itération étant réservée à la génération de la réponse finale. Il est important de noter que la récupération spéculative, qui s'exécute avant la première étape de planification pour accélérer le processus, ne compte pas dans cette limite.

Lorsque maxAgentIteration est défini sur 1, le système contourne entièrement la phase de planification. Il récupère les passages pertinents une fois sur la base de la requête originale et les transmet immédiatement au modèle fondamental pour la génération de la réponse. Cela est idéal pour les questions bien cadrées où la réponse existe dans un seul document ou section. Lorsqu'il est défini sur 0, le système effectue une récupération garantie mais ignore complètement l'appel au modèle fondamental, ne renvoyant que les passages de texte brut. Cela équivaut à appeler directement l'API Retrieve, mais maintient le flux de travail dans l'interface AgenticRetrieveStream.

Pour les valeurs comprises entre 2 et 5, le modèle fondamental agit comme un planificateur. Il décompose les questions complexes en sous-requêtes, évalue les preuves récupérées et décide si des recherches supplémentaires sont nécessaires. Ce processus itératif aide à combler les lacunes informationnelles, ce qui le rend adapté aux questions multipartites ou aux comparaisons entre différents documents. Le développeur sélectionne le mode via la logique de l'application, plutôt que de compter sur un routage automatique par le paramètre lui-même.

Détails clés

• Le paramètre maxAgentIteration accepte désormais des valeurs de 0 à 5, remplaçant la plage limitée précédente.
• Définir maxAgentIteration=1 active le RAG en une passe, effectuant une récupération et une génération de réponse sans tours de planification.
• Définir maxAgentIteration=0 active le mode récupération seule, renvoyant des passages sans aucun appel au modèle fondamental ; generateResponse doit être false.
• La récupération agentique (valeurs 2–5) permet jusqu'à n moins 1 tours de planification, soutenant la décomposition de requêtes et la collecte itérative de preuves.
• Les trois modes prennent en charge plusieurs bases de connaissances, ce qui signifie que la récupération en une passe n'est pas limitée à une seule source de données.
• La récupération spéculative, qui se produit avant la première étape de planification, ne compte pas dans la limite maxAgentIteration.

Pourquoi c'est important

Pour les ingénieurs logiciels construisant des assistants IA, cette mise à jour simplifie l'architecture et améliore l'efficacité des coûts. Auparavant, optimiser les réponses à faible latence pour les requêtes simples pouvait nécessiter la construction d'un pipeline de récupération léger séparé parallèlement à un système agentique plus complexe. Désormais, un seul appel API peut gérer les deux scénarios. Cela réduit la charge opérationnelle liée à la maintenance de multiples intégrations et garantit une gestion cohérente des citations et des événements de trace pour tous les types de requêtes.

La possibilité de basculer entre les modes offre également un contrôle plus fin sur le compromis entre vitesse et précision. Dans les applications à fort volume, telles que les bots d'assistance client ou les outils de recherche d'entreprise internes, la plupart des requêtes sont probablement des vérifications factuelles simples. L'utilisation du RAG en une passe pour ces demandes réduit la consommation de tokens et le temps de réponse. Pour la minorité de requêtes complexes nécessitant le croisement de références entre plusieurs documents, les développeurs peuvent augmenter dynamiquement la limite d'itérations pour garantir l'exhaustivité. Cette flexibilité permet une meilleure allocation des ressources et une expérience utilisateur plus réactive.

Ce que vous pouvez faire

• Mettez à jour vos appels AgenticRetrieveStream pour inclure le paramètre maxAgentIteration dans l'objet agenticRetrieveConfiguration.
• Définissez maxAgentIteration=1 et generateResponse=true pour les questions directes et bien cadrées afin d'activer le RAG en une passe.
• Définissez maxAgentIteration=0 et generateResponse=false lorsque vous devez afficher des passages sources aux utilisateurs sans générer de résumé IA.
• Utilisez des valeurs de 2 à 5 pour les questions complexes et multipartites nécessitant la comparaison d'informations entre différents documents ou bases de connaissances.
• Testez différentes limites d'itérations avec des questions représentatives pour trouver l'équilibre optimal entre latence et qualité de réponse pour votre cas d'utilisation spécifique.
• Assurez-vous que la logique de votre application détermine le mode approprié en fonction de la complexité de la requête, plutôt que de compter sur l'API pour le détecter automatiquement.