Bedrock Knowledge Base apprend à choisir la profondeur de recherche : de 0 appel LLM au RAG agentique

Le matin, un employé de banque demande à l'assistant IA interne quels documents sont nécessaires pour ouvrir un compte pour un entrepreneur individuel (IP). La réponse figure dans une seule checklist. L'après-midi, il demande en quoi diffèrent les exigences pour un IP, une SARL (OOO) et des partenariats avec plusieurs propriétaires. La réponse est éparpillée dans plusieurs règlements. L'assistant est unique, mais les questions diffèrent beaucoup en complexité et en coût. Si vous lancez une lourde boucle agentique pour les deux, vous payez trop et perdez en latence. Si vous faites une seule recherche pour les deux, vous perdez en précision sur la question complexe.

AWS comble cet écart dans Amazon Bedrock Managed Knowledge Base. Auparavant, seul le mode agentique était disponible via AgenticRetrieveStream ; deux autres modes viennent de s'y ajouter.

Un paramètre au lieu de deux API

Tout se pilote via maxAgentIteration. La plage est désormais de 0 à 5, et le comportement de la requête dépend de la valeur.

0 : recherche seule. Le service effectue une seule recherche garantie et ne génère rien. Aucun appel à un foundation model : c'est en pratique l'équivalent de l'API Retrieve classique. Ce mode convient à ceux qui sont déjà passés à AgenticRetrieveStream et ne veulent pas changer d'API pour une requête sans génération. Si l'on définit generateResponse=true avec la valeur 0, une erreur 4xx est renvoyée : une réponse nécessite un LLM.

1 : RAG classique. Une recherche, un appel au modèle pour la réponse, ni planification ni réécriture de la requête. Exemple tiré de l'article : « Quels documents faut-il pour ouvrir un compte professionnel pour un IP ? ». La checklist est dans la base, le planificateur n'ajouterait que de la latence. Si la majorité de votre trafic se compose de questions directes et bien délimitées, AWS laisse entendre que c'est votre option par défaut.

2–5 : mode agentique. Le modèle découpe la question en sous-requêtes, effectue une recherche pour chacune, évalue si les résultats suffisent et, au besoin, affine la recherche ou récupère le document entier. Les valeurs 2 à 5 fonctionnent comme avant : les requêtes existantes ne seront pas cassées.

Comment les itérations sont comptées

La règle est simple : une itération équivaut à un appel au foundation model. La dernière itération est toujours consacrée à la génération de la réponse. Ainsi, la valeur n donne jusqu'à n−1 tours de planification, chaque tour comprenant une réécriture de la requête et une recherche.

Une nuance : la recherche spéculative, lancée avant la première étape de planification, n'est pas comptée dans les itérations. Elle ne consomme pas la limite et ne peut qu'accélérer la requête.

AWS souligne par ailleurs qu'une recherche unique ne signifie pas une seule base de connaissances. Les trois modes, y compris 0 et 1, fonctionnent avec plusieurs bases. Le mode agentique ajoute la décomposition de la question, l'évaluation des éléments trouvés et la recherche itérative, mais le multi-base n'en dépend pas.

Sur l'exemple de la banque, cela donne ceci. Pour la question sur la checklist IP, on règle maxAgentIteration=1 et generateResponse=true. Pour comparer IP et SARL avec les contrôles des non-résidents, on règle 4, soit jusqu'à trois tours de planification. Quand l'employé a besoin du texte du règlement lui-même plutôt que d'un résumé, on règle 0 et generateResponse=false, et l'application affiche les passages avec des liens vers les sources. Passer d'un appel agentique à un RAG ordinaire revient à modifier un seul nombre dans le JSON.

Limites et conseils pratiques

Principal point : le choix du mode reste à la charge de votre application. Il n'y a pas de routage automatique selon la complexité de la question. Il faut soit un routeur simple (selon le type de scénario, une heuristique, un petit classifieur), soit associer rigidement un mode à un écran ou une fonctionnalité donnés.

Deuxième point : le format de réponse en mode 0 diffère de celui de Retrieve direct. Les passages dédupliqués arrivent dans l'événement result du flux, sans les champs score et location. Si votre interface s'appuie sur un score de pertinence ou sur la localisation exacte d'un fragment, vérifiez-le avant la migration.

Troisième point : les exemples bancaires de l'article sont illustratifs. AWS ne fournit aucune mesure de latence, de coût ou de qualité. L'affirmation selon laquelle le single-shot réduit la latence et la consommation du modèle par rapport au mode agentique est logique, mais aucun chiffre ne l'appuie. Ne la prenez pas pour argent comptant.

Voici un plan pratique :

• Constituez un jeu de questions réelles avec des réponses de référence tirées de vos documents.
• Faites-le passer par le mode 1 et par votre configuration agentique actuelle, sur la même base de connaissances.
• Mesurez la latence et le coût par requête, et vérifiez que les réponses sont correctes et étayées par les passages trouvés.
• Incluez impérativement des questions dont la réponse doit être assemblée à partir de plusieurs documents. C'est là que la recherche unique décroche généralement.

Si le mode agentique est actuellement votre option par défaut, il y a de fortes chances que vous payiez, sur les requêtes simples, une planification qui n'apporte rien. Commencez par une valeur basse pour le trafic simple et augmentez-la là où la précision sur les questions complexes compte plus que la vitesse. La limite d'itérations doit aussi être calibrée sur vos propres données : plus d'itérations ne signifie pas toujours une meilleure réponse.