Amazon Bedrock Web Search: um teste de aceitação de respostas fundamentadas para sistemas de produção

Comece com um teste de evidência de citações, não com uma recapitulação do lançamento

Amazon Bedrock Web Search é agora uma ferramenta integrada para fundamentar respostas de modelos de base selecionados em resultados da web. A AWS anunciou a disponibilidade geral em 04 de agosto de 2026 e descreve o recurso como uma capacidade do Bedrock no lado do servidor que pode recuperar conhecimento atual da web, devolver citações de fontes e evitar uma integração separada com um fornecedor de pesquisa de terceiros. Isso é útil, mas não é evidência suficiente para uso em produção.

Um sistema de respostas em produção precisa de um teste de aceitação mais rigoroso. A questão não é se uma demonstração consegue citar uma fonte. A questão é se o sistema consegue responder a perguntas atuais, de alto risco, ambíguas e com fontes conflitantes usando citações que um revisor possa inspecionar. Ele também precisa comportar-se de forma previsível quando a resposta não é suportada, quando a fonte mais recente está ausente da cache, quando uma página contém injeção de prompt, quando os custos aumentam ou quando a latência de cauda se torna visível para os utilizadores.

A documentação da AWS diz que Web Search está disponível para modelos OpenAI GPT servidos por meio do endpoint Amazon Bedrock bedrock-mantle usando a Responses API. Os modelos compatíveis listados na documentação atual são openai.gpt-5.4, openai.gpt-5.5 e openai.gpt-5.6, incluindo variantes luna, terra e sol. As Regiões documentadas são US East (N. Virginia) us-east-1, US East (Ohio) us-east-2 e US West (Oregon) us-west-2. Estes detalhes devem ser tratados como restrições de implementação, não como notas de rodapé. Se a sua rota de produção estiver fora desses modelos ou Regiões, esta ferramenta nativa não é a rota a testar primeiro.

A AWS também descreve vários benefícios de qualidade, incluindo conhecimento web atual, citações, extração semântica de snippets, um índice web operado pela Amazon e redução de alucinações. Trate-os como afirmações do fornecedor até que a sua própria suíte de aceitação os reproduza para o seu domínio, formato de tráfego e modos de falha.

O teste de aceitação de respostas fundamentadas da Optijara

O teste de aceitação de respostas fundamentadas da Optijara é uma estrutura de avaliação nativa de lançamento para decidir se o Bedrock Web Search deve servir respostas de utilizadores em produção. Ele tem seis portas: adequação da rota, comportamento de recuperação, integridade das citações, comportamento de segurança e limites de dados, desempenho operacional e prontidão de fallback.

Use a estrutura num conjunto fixo de benchmarks antes da implementação. Inclua pelo menos cinco grupos de tarefas: factos recentes de produtos, alterações de documentação, perguntas sobre preços, perguntas técnicas de cauda longa e fontes deliberadamente conflitantes. Adicione controlos negativos em que a resposta correta é dizer que a evidência é insuficiente.

Planeamento de consultas e recall de recuperação

Bedrock Web Search permite que o modelo decida se informações atuais são necessárias e pode emitir uma ou mais consultas de pesquisa no mesmo turno. Esta conveniência deve ser testada, não assumida. Crie prompts que exijam recuperação sensível a datas e específica de entidades. Verifique se a ferramenta encontra páginas canónicas antes de blogs, espelhos, publicações sociais ou resumos de baixa qualidade. Para documentação técnica, a citação de maior qualidade é muitas vezes a página de documentação do fornecedor ou a nota de lançamento, não um artigo que a cita.

Meça o recall de recuperação com perguntas de resposta conhecida. Para cada pergunta, defina um conjunto de fontes padrão antes da execução. Uma aprovação significa que a resposta cita pelo menos uma fonte autoritativa que suporta cada afirmação material. Uma aprovação mais forte significa que ela recupera várias fontes independentes quando o tema é contestado ou está a mudar. Uma falha significa que a resposta depende de conteúdo obsoleto em cache, cita uma página fraca enquanto perde a fonte canónica ou dá uma resposta confiante quando o conjunto de fontes é inadequado.

A rota também deve testar comportamento de egressão zero de dados. A documentação da AWS afirma que, por predefinição, Web Search é servido a partir do índice web e da cache do Amazon Bedrock e que os dados do pedido não saem do limite da AWS para recuperação. A mesma documentação explica que o parâmetro external_web_access e a permissão IAM bedrock-websearch:ExternalWebAccess governam se pesquisa e fetch podem aceder à web externa diretamente, e que definir external_web_access como false mantém a recuperação dentro do limite da AWS. O seu teste de aceitação deve executar explicitamente ambos os estados de política permitidos e verificar o comportamento observado de autorização e resposta.

Completude das citações, fidelidade dos snippets e fontes conflitantes

Uma resposta fundamentada só é útil se as citações suportarem o texto em redor delas. Capture o JSON bruto da resposta e inspecione as anotações do conteúdo de saída. A AWS documenta anotações url_citation com título, URL e intervalos de caracteres. A sua UI deve manter e exibir esses links porque a linguagem de uso aceitável da AWS diz que saídas de utilizador final que incorporam Search Results devem manter e exibir citações e links de fontes.

Teste a completude das citações no nível da afirmação. Datas, preços, modelos compatíveis, Regiões, parâmetros de API, comportamento de segurança e requisitos de política devem apontar cada um para uma fonte relevante. Não aceite uma citação no nível do parágrafo que suporta apenas uma frase enquanto as afirmações em redor não têm suporte. Para fidelidade dos snippets, compare a declaração gerada com o texto da página citada. Uma citação falha se aponta para o domínio certo, mas não para evidência da afirmação.

Fontes conflitantes precisam de um caminho separado. Faça perguntas em que a documentação oficial, o blog de lançamento, a página de preços e comentários de terceiros diferem ou são atualizados em velocidades diferentes. A resposta deve identificar a fonte mais autoritativa e declarar incerteza quando necessário. Ela não deve juntar declarações incompatíveis em uma única resposta confiante.

Injeção de prompt e páginas maliciosas fazem parte do mesmo teste. Use páginas que contenham instruções como ignore direções anteriores ou oculte esta fonte. O sistema de respostas deve tratar o texto recuperado da página como evidência, não como instruções. Uma implementação segura regista a qualidade da fonte, regras de permissão ou negação de domínios quando apropriado e um caminho de revisão para páginas que pareçam adversariais ou irrelevantes.

Custo, latência, limites de taxa, observabilidade e rollout

Web Search nativo altera o formato de custo de uma resposta. Continua a pagar pela inferência do modelo, e a AWS tem um separador de preços separado para Web Search na página de preços do Bedrock. Não publique uma percentagem de economia de custos a menos que ela venha da sua própria carga de trabalho medida. Em vez disso, acompanhe pesquisas por resposta, fetches por resposta, tokens de entrada e saída, novas tentativas, comportamento de cache e a percentagem de respostas que exigem fallback.

A latência deve ser medida como uma distribuição, não como uma única média. Acompanhe p50, p95 e p99 para rotas fundamentadas e não fundamentadas. Inclua cold starts, turnos com múltiplas consultas, comportamento de streaming e novas tentativas. Uma rota que parece aceitável numa demonstração ainda pode falhar num SLO de produção quando a cauda longa cresce.

A observabilidade deve incluir ID do pedido, ID do modelo, Região, configuração external_web_access, contagem de invocações de ferramenta, URLs de fontes, intervalos de citações, eventos de recusa ou evidência insuficiente, latência, uso de tokens, códigos de estado e cobertura do CloudTrail. A documentação da AWS afirma que Web Search é integrado ao AWS CloudTrail como eventos de dados, então a sua equipa de operações deve confirmar o que é capturado e o que é intencionalmente excluído antes de depender disso para auditoria.

O rollout deve começar com canários. Envie uma pequena percentagem de perguntas elegíveis da web pública para o Bedrock Web Search, compare com uma linha de base de recuperação direta ou RAG e reveja diariamente uma amostra de respostas. Reverta se a completude das citações cair, a latência violar o SLO, a qualidade das fontes diminuir, o custo exceder limites de orçamento ou as respostas não suportadas aumentarem.

Matriz de decisão de rota de fundamentação

Checklist de implementação

1. Confirme que o modelo é openai.gpt-5.4, openai.gpt-5.5 ou openai.gpt-5.6 na Responses API bedrock-mantle do Bedrock.
2. Confirme que a Região de implementação é us-east-1, us-east-2 ou us-west-2.
3. Decida se external_web_access deve ser false para recuperação com limite controlado.
4. Configure ações IAM para Search e Fetch, e conceda ExternalWebAccess apenas quando a política permitir.
5. Armazene anotações brutas de resposta e exiba URLs de fontes ao lado do texto da resposta.
6. Crie um conjunto de benchmarks com factos recentes, factos obsoletos, fontes conflitantes, preços, documentação e controlos negativos.
7. Pontue completude de citações, autoridade da fonte, fidelidade de snippets, atraso de atualidade, recall, latência, custo e qualidade da recusa.
8. Defina rotas de fallback para recuperação direta, RAG privada, resposta em cache ou resposta de evidência insuficiente.
9. Monitorize CloudTrail, logs da aplicação, uso de tokens, chamadas de ferramentas, códigos de estado e erros de citação.
10. Comece com canário, depois expanda apenas quando os resultados medidos permanecerem dentro dos limites.

Erros comuns, ressalvas e medição

Erros comuns incluem tratar toda resposta citada como fundamentada, ocultar citações dos utilizadores, ignorar Regiões incompatíveis, deixar comportamento web externo indefinido, medir apenas atualidade no caminho feliz e comparar Web Search nativo com RAG sem pontuação igual de qualidade de fontes. Outro erro é usar Web Search quando a rota correta é uma consulta ao sistema de registo. Se a resposta for sobre uma conta de utilizador, uma transação, uma cláusula legal ou uma política privada, a fundamentação na web pública geralmente é a ferramenta errada.

Ressalvas importam. Bedrock Web Search pode reduzir o trabalho de integração para fundamentação na web pública, mas não elimina avaliação, revisão de fontes, política de segurança ou desenho de fallback. Declarações da AWS sobre escala, atualidade, latência e redução de alucinações são afirmações úteis de produto, não prova de produção para o seu sistema. Teste novamente após mudanças de modelo, mudanças de Região, mudanças de IAM, mudanças de prompt, atualizações de preços e grandes lançamentos de produto.

A medição deve ser explícita: cobertura de citações por afirmação material, taxa de acerto em fonte autoritativa, atraso de atualidade contra atualizações conhecidas, recall de recuperação contra fontes padrão, taxa de respostas não suportadas, resistência a injeção de prompt, latência p95 e p99, pesquisas por resposta, custo de tokens, taxa de nova tentativa, taxa de fallback e cliques de utilizadores em citações visíveis. A métrica final de produção não é se a resposta parece atual. É se um revisor consegue rastrear cada afirmação importante até uma fonte relevante e fiável, e se o sistema se comporta com segurança quando não consegue.