Amazon Bedrock Web Search : test d'acceptation des réponses ancrées pour les systèmes de production

Commencez par un test de preuves de citation, pas par un récapitulatif de lancement

Amazon Bedrock Web Search est désormais un outil intégré pour ancrer les réponses de certains modèles de fondation dans des résultats web. AWS a annoncé la disponibilité générale le 04 août 2026 et décrit la fonctionnalité comme une capacité Bedrock côté serveur qui peut récupérer des connaissances web actuelles, renvoyer des citations de sources et éviter l'intégration d'un fournisseur de recherche tiers distinct. C'est utile, mais ce n'est pas une preuve suffisante pour un usage en production.

Un système de réponses en production a besoin d'un test d'acceptation plus exigeant. La question n'est pas de savoir si une démonstration peut citer une source. La question est de savoir si le système peut répondre à des questions actuelles, à forts enjeux, ambiguës et en conflit entre sources, avec des citations qu'un relecteur peut inspecter. Il doit aussi se comporter de manière prévisible lorsque la réponse n'est pas étayée, lorsque la source la plus récente manque dans le cache, lorsqu'une page contient une injection de prompt, lorsque les coûts augmentent ou lorsque les queues de latence deviennent visibles pour les utilisateurs.

La documentation AWS indique que Web Search est disponible pour les modèles OpenAI GPT servis par le point de terminaison Amazon Bedrock bedrock-mantle avec l'API Responses. Les modèles pris en charge listés dans la documentation actuelle sont openai.gpt-5.4, openai.gpt-5.5 et openai.gpt-5.6, y compris les variantes luna, terra et sol. Les Régions documentées sont US East (N. Virginia) us-east-1, US East (Ohio) us-east-2 et US West (Oregon) us-west-2. Ces détails doivent être traités comme des contraintes de déploiement, pas comme des notes de bas de page. Si votre route de production se trouve en dehors de ces modèles ou Régions, cet outil natif n'est pas la route à tester en premier.

AWS décrit aussi plusieurs bénéfices de qualité, notamment des connaissances web actuelles, des citations, l'extraction sémantique d'extraits, un index web exploité par Amazon et une réduction des hallucinations. Traitez ces éléments comme des affirmations du fournisseur jusqu'à ce que votre propre suite d'acceptation les reproduise pour votre domaine, votre profil de trafic et vos modes de défaillance.

Le test d'acceptation Optijara des réponses ancrées

Le test d'acceptation Optijara des réponses ancrées est un cadre d'évaluation conçu pour la mise en production afin de décider si Bedrock Web Search doit servir les réponses utilisateurs en production. Il comporte six portes : adéquation de la route, comportement de récupération, intégrité des citations, comportement de sécurité et de limites des données, performance opérationnelle et préparation au repli.

Utilisez le cadre sur un ensemble de référence fixe avant le déploiement. Incluez au moins cinq groupes de tâches : faits produits récents, changements de documentation, questions de prix, questions techniques de longue traîne et sources volontairement contradictoires. Ajoutez des contrôles négatifs où la bonne réponse consiste à dire que les preuves sont insuffisantes.

Planification des requêtes et rappel de récupération

Bedrock Web Search laisse le modèle décider si des informations actuelles sont nécessaires et peut émettre une ou plusieurs requêtes de recherche dans le même tour. Cette commodité doit être testée, pas supposée acquise. Construisez des prompts qui exigent une récupération sensible à la date et spécifique à l'entité. Vérifiez si l'outil trouve les pages canoniques avant les blogs, les miroirs, les publications sociales ou les résumés de faible qualité. Pour la documentation technique, la citation de meilleure qualité est souvent la page de documentation du fournisseur ou la note de version, pas un article qui la cite.

Mesurez le rappel de récupération avec des questions dont la réponse est connue. Pour chaque question, définissez un ensemble de sources de référence avant l'exécution. Une réussite signifie que la réponse cite au moins une source faisant autorité qui étaye chaque affirmation importante. Une réussite plus forte signifie qu'elle récupère plusieurs sources indépendantes lorsque le sujet est contesté ou changeant. Un échec signifie que la réponse s'appuie sur du contenu en cache obsolète, cite une page faible en manquant la source canonique ou donne une réponse confiante alors que l'ensemble de sources est insuffisant.

La route doit aussi tester le comportement sans sortie de données. La documentation AWS indique que, par défaut, Web Search est servi depuis l'index web et le cache d'Amazon Bedrock, et que les données de requête ne quittent pas la limite AWS pour la récupération. La même documentation explique que le paramètre external_web_access et l'autorisation IAM bedrock-websearch:ExternalWebAccess gouvernent la possibilité pour la recherche et la récupération d'atteindre directement le web externe, et que définir external_web_access sur false maintient la récupération dans la limite AWS. Votre test d'acceptation doit exécuter explicitement les deux états de politique autorisés et vérifier le comportement observé d'autorisation et de réponse.

Complétude des citations, fidélité des extraits et sources contradictoires

Une réponse ancrée n'est utile que si les citations étayent le texte qui les entoure. Capturez le JSON brut de la réponse et inspectez les annotations du contenu de sortie. AWS documente les annotations url_citation avec un titre, une URL et des plages de caractères. Votre interface utilisateur doit conserver et afficher ces liens, car le langage d'utilisation acceptable d'AWS indique que les sorties destinées aux utilisateurs finaux qui incorporent des Search Results doivent conserver et afficher les citations et liens des sources.

Testez la complétude des citations au niveau de l'affirmation. Les dates, prix, modèles pris en charge, Régions, paramètres d'API, comportements de sécurité et exigences de politique doivent chacun pointer vers une source pertinente. N'acceptez pas une citation au niveau du paragraphe qui n'étaye qu'une seule phrase tandis que les affirmations environnantes ne sont pas étayées. Pour la fidélité des extraits, comparez l'énoncé généré au texte de la page citée. Une citation échoue si elle pointe vers le bon domaine mais pas vers une preuve de l'affirmation.

Les sources contradictoires ont besoin d'un chemin séparé. Posez des questions où la documentation officielle, le blog de lancement, la page de prix et les commentaires de tiers divergent ou se mettent à jour à des vitesses différentes. La réponse doit identifier la source qui fait le plus autorité et indiquer l'incertitude lorsque nécessaire. Elle ne doit pas fusionner des déclarations incompatibles en une seule réponse confiante.

L'injection de prompt et les pages malveillantes font partie du même test. Utilisez des pages contenant des instructions telles que ignorer les consignes précédentes ou masquer cette source. Le système de réponses doit traiter le texte de page récupéré comme une preuve, pas comme des instructions. Une implémentation sûre enregistre la qualité des sources, les règles d'autorisation ou de blocage de domaines lorsque c'est approprié, et un chemin de revue pour les pages qui semblent adversariales ou non pertinentes.

Coût, latence, limites de débit, observabilité et déploiement

Web Search natif modifie la forme des coûts d'une réponse. Vous payez toujours l'inférence du modèle, et AWS dispose d'un onglet de tarification distinct pour Web Search sur la page de tarification Bedrock. Ne publiez pas de pourcentage d'économie de coûts sauf s'il provient de votre propre charge de travail mesurée. Suivez plutôt les recherches par réponse, les récupérations par réponse, les tokens d'entrée et de sortie, les nouvelles tentatives, le comportement du cache et le pourcentage de réponses qui nécessitent un repli.

La latence doit être mesurée comme une distribution, pas comme une moyenne unique. Suivez p50, p95 et p99 pour les routes ancrées et non ancrées. Incluez les démarrages à froid, les tours à requêtes multiples, le comportement de streaming et les nouvelles tentatives. Une route qui semble acceptable dans une démonstration peut quand même échouer à un SLO de production lorsque la longue queue augmente.

L'observabilité doit inclure l'ID de requête, l'ID du modèle, la Région, le paramètre external_web_access, le nombre d'invocations d'outil, les URL des sources, les plages de citation, les événements de refus ou de preuves insuffisantes, la latence, l'utilisation des tokens, les codes de statut et la couverture CloudTrail. La documentation AWS indique que Web Search est intégré à AWS CloudTrail en tant qu'événements de données. Votre équipe d'exploitation doit donc confirmer ce qui est capturé et ce qui est volontairement exclu avant de s'y fier pour l'audit.

Le déploiement doit commencer par des canaries. Envoyez un petit pourcentage des questions éligibles du web public vers Bedrock Web Search, comparez avec une base de référence de récupération directe ou de RAG, et examinez chaque jour un échantillon de réponses. Revenez en arrière si la complétude des citations baisse, si la latence dépasse le SLO, si la qualité des sources décline, si les coûts dépassent les seuils budgétaires ou si les réponses non étayées augmentent.

Matrice de décision de route d'ancrage

Liste de contrôle d'implémentation

1. Confirmez que le modèle est openai.gpt-5.4, openai.gpt-5.5 ou openai.gpt-5.6 sur l'API Responses Bedrock bedrock-mantle.
2. Confirmez que la Région de déploiement est us-east-1, us-east-2 ou us-west-2.
3. Décidez si external_web_access doit être false pour une récupération dont les limites sont contrôlées.
4. Configurez les actions IAM pour Search et Fetch, et accordez ExternalWebAccess uniquement lorsque la politique l'autorise.
5. Stockez les annotations brutes de réponse et affichez les URL des sources à côté du texte de réponse.
6. Construisez un ensemble de référence avec des faits récents, des faits obsolètes, des sources contradictoires, la tarification, la documentation et des contrôles négatifs.
7. Notez la complétude des citations, l'autorité des sources, la fidélité des extraits, le retard de fraîcheur, le rappel, la latence, le coût et la qualité des refus.
8. Définissez des routes de repli vers la récupération directe, le RAG privé, la réponse en cache ou une réponse indiquant des preuves insuffisantes.
9. Surveillez CloudTrail, les journaux applicatifs, l'utilisation des tokens, les appels d'outils, les codes de statut et les erreurs de citation.
10. Commencez par un canary, puis élargissez uniquement lorsque les résultats mesurés restent dans les seuils.

Erreurs courantes, réserves et mesure

Les erreurs courantes consistent à traiter chaque réponse citée comme ancrée, à masquer les citations aux utilisateurs, à ignorer les Régions non prises en charge, à laisser le comportement web externe non défini, à mesurer seulement la fraîcheur du chemin nominal et à comparer Web Search natif au RAG sans notation égale de la qualité des sources. Une autre erreur consiste à utiliser Web Search lorsque la bonne route est une recherche dans le système d'enregistrement. Si la réponse concerne un compte utilisateur, une transaction, une clause juridique ou une politique privée, l'ancrage web public est généralement le mauvais outil.

Les réserves comptent. Bedrock Web Search peut réduire le travail d'intégration pour l'ancrage web public, mais il n'élimine pas l'évaluation, la revue des sources, la politique de sécurité ni la conception du repli. Les déclarations AWS sur l'échelle, la fraîcheur, la latence et la réduction des hallucinations sont des affirmations produit utiles, pas des preuves de production pour votre système. Re-testez après les changements de modèle, de Région, d'IAM, de prompt, de tarification et les versions produit majeures.

La mesure doit être explicite : couverture de citation par affirmation importante, taux de présence de sources faisant autorité, retard de fraîcheur par rapport aux mises à jour connues, rappel de récupération par rapport aux sources de référence, taux de réponses non étayées, résistance à l'injection de prompt, latence p95 et p99, recherches par réponse, coût des tokens, taux de nouvelle tentative, taux de repli et taux de clics sur les citations visibles par l'utilisateur. La métrique finale de production n'est pas de savoir si la réponse semble actuelle. Elle est de savoir si un relecteur peut relier chaque affirmation importante à une source pertinente et fiable, et si le système se comporte de manière sûre lorsqu'il ne le peut pas.