Blog

Busca na web chega ao Amazon Bedrock no GovCloud

A AWS anunciou a disponibilidade da ferramenta integrada de busca na web (Web Search) do Amazon Bedrock na região AWS GovCloud (US-West). A novidade amplia o alcance desse recurso para ambientes governamentais e do setor público, que possuem requisitos rigorosos de conformidade e tratamento de dados.

O que é o Web Search no Amazon Bedrock

O Web Search é uma ferramenta nativa do lado do servidor (built-in server-side tool) que permite aos modelos de linguagem fundamentarem suas respostas em informações atuais da web. O recurso é compatível com modelos OpenAI GPT suportados pelo Amazon Bedrock e inclui citações das fontes consultadas, permitindo rastrear cada afirmação até sua origem na web.

Isso é especialmente útil em situações onde a resposta depende de informações que mudam com o tempo ou que são mais recentes do que os dados de treinamento do modelo — como eventos atuais, lançamentos recentes ou preços em tempo real.

Sem infraestrutura para gerenciar

Por ser executado dentro do Amazon Bedrock, o Web Search elimina a necessidade de hospedar um índice de busca próprio, gerenciar crawlers ou escrever o loop de chamada de ferramentas manualmente. A AWS cuida de toda essa camada de infraestrutura, servindo os resultados a partir de um índice web e cache mantidos pela própria Amazon.

Governança e controle de acesso

O recurso foi projetado para atender aos padrões de governança e tratamento de dados exigidos pelos clientes do AWS GovCloud (US). Por padrão, os dados das requisições permanecem dentro do perímetro da AWS. Como capacidade nativa gerenciada pelo Gerenciamento de Identidade e Acesso da AWS (IAM — AWS Identity and Access Management), administradores podem permitir ou negar o uso do Web Search no nível da conta ou da organização, além de restringi-lo por região, garantindo controle centralizado.

Como começar a usar

Para utilizar o recurso, basta adicionar uma ferramenta do tipo web_search ao array tools na requisição da API de Respostas da OpenAI (OpenAI Responses API), utilizando a biblioteca cliente OpenAI existente com uma chave de API do Amazon Bedrock. O modelo aciona a ferramenta automaticamente apenas quando identifica que a requisição exige informações atuais.

Modelos e regiões suportados

No lançamento para o AWS GovCloud (US-West), o Web Search suporta os modelos GPT-5.4, GPT-5.6 Terra e Luna. Além da região GovCloud (US-West), o recurso também está disponível em US East (Norte da Virgínia), US East (Ohio) e US West (Oregon).

Para aprofundar o entendimento técnico, a AWS disponibiliza um blog técnico de introdução ao Web Search. Para orientações de implementação, consulte a documentação oficial do Web Search. Informações sobre preços estão disponíveis na página de preços do Amazon Bedrock.

Fonte

Web Search on Amazon Bedrock is now available in AWS GovCloud (US-West) (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-web-aws-govcloud/)

Mais controle sobre conectores no Amazon Quick

O Amazon Quick acaba de receber duas novidades relevantes para quem gerencia conectores na plataforma: novas configurações de ferramentas e suporte à sincronização com servidores MCP (Protocolo de Contexto de Modelo). As atualizações foram anunciadas pela AWS e chegam para dar mais controle a administradores e proprietários de conectores sobre como essas integrações são implantadas e mantidas atualizadas.

O que são os conectores do Amazon Quick?

Os conectores do Amazon Quick permitem que usuários utilizem ferramentas e serviços externos — como Outlook, Slack, Salesforce, Jira e servidores MCP próprios — diretamente em seus fluxos de trabalho. Isso vale para diferentes contextos dentro da plataforma: chat, agentes, aplicativos, flows e pesquisa aprofundada (deep research).

O que mudou com as novas configurações

Habilitação seletiva de ferramentas

Agora, proprietários de conectores e administradores podem habilitar ou desabilitar ferramentas individuais dentro de um conector. Na prática, isso significa que é possível garantir que apenas as ferramentas aprovadas fiquem disponíveis para os usuários finais — um controle importante em ambientes corporativos onde nem toda funcionalidade de um serviço externo deve estar acessível.

Configurações de permissão por ferramenta

Além da habilitação seletiva, as novas configurações de permissão permitem que proprietários de conectores definam quais ferramentas exigem consentimento explícito do usuário antes de serem executadas. Também é possível deixar essa decisão nas mãos dos próprios usuários finais, oferecendo maior flexibilidade conforme a política de cada organização.

Sincronização automática com servidores MCP externos

O recurso de sincronização MCP garante que os conectores se mantenham atualizados automaticamente à medida que os servidores MCP externos evoluem — seja adicionando novas ferramentas, atualizando descrições ou expandindo suas capacidades. Com isso, os usuários sempre têm acesso às informações mais recentes sem precisar de intervenção manual para atualizar os conectores.

Disponibilidade

Todos esses recursos já estão disponíveis em todas as regiões da AWS onde o Amazon Quick está presente. Para saber mais sobre como configurar e aproveitar essas novidades, a AWS disponibiliza o Guia do Usuário do Amazon Quick.

Fonte

Amazon Quick adds new tool settings and Model Context Protocol (MCP) sync support for connectors (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-quick-adds-tool-settings-mcp-sync/)

O que foi anunciado

A AWS anunciou a disponibilidade geral do Agentic CX Designer, uma ferramenta de canvas visual sem código integrada ao Amazon Connect Customer. O objetivo é permitir que equipes de negócio criem e publiquem experiências de autoatendimento com inteligência artificial — tanto por voz quanto por canais digitais — sem depender de times de engenharia para colocar tudo em produção.

O que é o Agentic CX Designer

A proposta central da ferramenta é unir dois tipos de IA em um único ambiente: a IA agêntica, que conduz conversas naturais com os clientes usando modelos de linguagem de grande escala (LLMs), e a IA determinística, que garante resultados exatos em situações onde não há margem para variação — como elegibilidade, aprovações, roteamento ou conformidade regulatória.

Na prática, funciona assim: no canvas visual, a equipe define a lógica do fluxo, as regras de negócio, as integrações com sistemas existentes e os limites de atuação da IA. O modelo de linguagem cuida da conversa em si, de forma natural. Para etapas críticas do processo, o fluxo segue exatamente o que foi definido pela equipe — sem improvisação do modelo.

A analogia usada pela AWS é direta: o Agentic CX Designer oferece “a clareza de um fluxograma com o poder de um modelo de linguagem de grande escala”.

Principais capacidades

• Canvas visual sem código: design, testes e publicação acontecem no mesmo ambiente, sem necessidade de transferir o trabalho para a engenharia.
• Combinação de IA agêntica e determinística: conversas naturais com controle preciso nos pontos críticos do fluxo.
• Integração com sistemas de negócio: é possível conectar a ferramenta aos sistemas que já operam na empresa durante o próprio processo de design.
• Velocidade de implantação: segundo a AWS, equipes conseguem ir do design à produção em semanas, não meses.

Regiões disponíveis

O Agentic CX Designer está disponível nas seguintes regiões da AWS:

• US East (N. Virginia)
• US West (Oregon)
• Canada (Central)
• Asia Pacific (Tokyo)
• Asia Pacific (Seoul)
• Asia Pacific (Singapore)
• Asia Pacific (Sydney)
• Europe (Frankfurt)
• Europe (London)

Saiba mais

Para entender como o Agentic CX Designer está transformando as experiências de autoatendimento, a AWS disponibilizou um post no blog oficial com mais detalhes sobre a combinação de lógica de negócio estruturada com IA agêntica. Também é possível acessar a documentação oficial da ferramenta e o site do Amazon Connect Customer, solução de IA agêntica voltada para empresas que buscam entregar experiências de atendimento ao cliente de alto nível.

Fonte

Amazon Connect Customer announces general availability of agentic CX designer (https://aws.amazon.com/about-aws/whats-new/2026/09/agentic-cx-designer/)

Claude Fable 5.1 chega ao Amazon Bedrock

A AWS anunciou a disponibilidade do Claude Fable 5.1 no Amazon Bedrock e na Claude Platform on AWS. O novo modelo da Anthropic foi projetado para tarefas de alta complexidade — com destaque para codificação, pesquisa científica e fluxos de trabalho corporativos. Por conta do nível de capacidade que oferece, a Anthropic classificou o Fable 5.1 como um Covered Model (Modelo Coberto), uma categoria que impõe políticas adicionais de retenção de dados, revisão de segurança e controle de acesso em qualquer ambiente onde o modelo esteja disponível. Para entender como isso funciona no Amazon Bedrock, vale consultar a documentação de detecção de uso indevido e a página de Covered Models da Anthropic.

Junto com o lançamento do modelo, a Anthropic também apresentou os Enterprise Frontier Safeguards (Salvaguardas de Fronteira Empresarial, EFS) — uma solução desenvolvida em parceria com a AWS que permite às organizações utilizar os modelos mais avançados da Anthropic mantendo seus dados dentro da infraestrutura de nuvem que controlam.

O que diferencia o Fable 5.1

Segundo a Anthropic, o Fable 5.1 representa um avanço claro em relação ao Fable 5 nos testes de raciocínio mais exigentes que a empresa realiza. Esses testes envolvem matemática de competição, questões de pós-graduação em engenharia e ciências, e problemas longos com múltiplos passos onde a confiabilidade é essencial.

Na prática, isso se traduz em melhor julgamento em tarefas ambíguas e menos respostas erradas apresentadas com excesso de confiança. As principais melhorias incluem:

• Codificação agêntica: O modelo consegue conduzir projetos de forma mais autônoma — desde funcionalidades que abrangem toda uma base de código até revisão e otimização de performance, em sessões de várias horas. Ele também é mais honesto: quando trava, diz isso claramente, e é menos propenso a desabilitar testes que estão falhando para forçar uma aprovação.
• Operação autônoma: Projetado para tarefas de múltiplas horas que envolvem vários aplicativos. Ele planeja, utiliza as ferramentas necessárias, se recupera quando uma etapa falha e mantém o usuário informado sem precisar ser solicitado.
• Trabalho de conhecimento de ponta a ponta: Conduz uma análise desde a primeira pergunta até o documento final — fazendo a pesquisa, construindo planilhas, redigindo memorandos ou apresentações e verificando os números ao longo do processo. Voltado especialmente para rotinas de finanças, contabilidade e saúde.
• Pesquisa científica: Suporta campanhas de pesquisa desde a revisão de literatura e formulação de hipóteses até modelagem, experimentos e verificação formal.
• Melhor usabilidade: Mantém o usuário atualizado em tarefas longas, escreve com mais clareza e segue instruções com mais precisão.

Retenção de dados e revisão humana

Por ser um Covered Model, o uso do Claude Fable 5.1 está sujeito à retenção de dados por até 30 dias e à revisão humana por pessoal da Amazon. No Amazon Bedrock, é possível controlar a retenção de dados por meio de um modo configurável na conta ou no projeto do Amazon Bedrock, utilizando a API de retenção de dados.

Para usar o Claude Fable 5.1, é obrigatório ativar o modo aws_review antes de invocar o modelo. Nesse modo, a AWS retém os prompts e as saídas para revisão de segurança humana dentro do perímetro da AWS — mas sem exigir compartilhamento com o provedor do modelo. Mais detalhes estão disponíveis na documentação de retenção de dados do Amazon Bedrock.

Enterprise Frontier Safeguards

Os Enterprise Frontier Safeguards (EFS), desenvolvidos em parceria entre AWS e Anthropic, foram criados para ajudar clientes elegíveis a utilizar o Claude Fable 5 e o Claude Fable 5.1 mantendo seus dados em um ambiente de nuvem sob seu próprio controle.

Clientes elegíveis ao EFS podem usar esses modelos com retenção zero de dados (Zero Data Retention, ZDR) no Amazon Bedrock e na Claude Platform on AWS. Essa opção está disponível para uso interno até 31 de dezembro de 2026.

Recursos adicionais do EFS serão disponibilizados ainda neste ano: os clientes poderão manter prompts e saídas dentro de sua própria conta AWS, sob suas próprias chaves de criptografia, políticas de acesso e registros de auditoria. O monitoramento de segurança será realizado por revisão automatizada, sem necessidade de revisão humana.

Como começar com o Fable 5.1 no Amazon Bedrock

Para experimentar o modelo diretamente pela interface, basta acessar o console do Amazon Bedrock, navegar até Test > Playground e selecionar o Fable 5.1. A partir daí, é possível executar prompts diretamente contra o modelo.

Para uso programático, o modelo pode ser chamado via Anthropic Messages API contra o bedrock-runtime (usando o SDK da Anthropic). Também é possível utilizar as APIs Invoke e Converse no bedrock-runtime por meio da Interface de Linha de Comando da AWS (AWS CLI) e do AWS SDK.

Pré-requisitos

• Conta AWS ativa com acesso ao Amazon Bedrock.
• AWS CLI instalada e configurada.
• Python 3.10 ou superior.
• Boto3 instalado: pip install boto3.
• Permissões do Gerenciamento de Identidade e Acesso da AWS (IAM): bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream.

Abaixo, um exemplo rápido usando o SDK da AWS para Python (Boto3):

import boto3
import json

# Create a Bedrock Runtime client
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"
)

# Invoke Claude Fable 5.1
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-fable-5-1",
    contentType="application/json",
    accept="application/json",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 4096,
        "messages": [
            {
                "role": "user",
                "content": "An S3 bucket serves 40 TB/month egress. Estimate the monthly egress cost at $0.09/GB, and state one architecture change to cut it. Show the calculation, keep it under 120 words."
            }
        ]
    })
)

result = json.loads(response["body"].read())

# Fable 5.1 is a reasoning model: the response may include a thinking block
# before the text block, so select the text block rather than a fixed index.
print(next(b["text"] for b in result["content"] if b["type"] == "text"))

Para mais exemplos, vale explorar o notebook de introdução disponível no GitHub.

Disponibilidade

O Claude Fable 5.1 já está disponível no Amazon Bedrock por meio dos perfis de inferência US Geo CRIS (us.) e Global CRIS (global.). No AWS GovCloud (US), o modelo está acessível nos endpoints bedrock-runtime e bedrock-mantle. A lista completa de regiões suportadas pode ser consultada na documentação do Bedrock. As informações de preço estão disponíveis na página de preços do Amazon Bedrock.

O modelo também está disponível pela Claude Platform on AWS na América do Norte. Para experimentar, acesse o console do Amazon Bedrock, a Claude Platform on AWS, ou explore os notebooks de introdução no GitHub.

Fonte

Introducing Claude Fable 5.1 on AWS (https://aws.amazon.com/blogs/machine-learning/introducing-claude-fable-5-1-on-aws/)

Criação de aplicações sem código, direto pela descrição

A AWS anunciou a disponibilidade geral de um novo recurso do Amazon Quick: a criação de aplicações personalizadas por meio de linguagem natural. Em vez de envolver times de desenvolvimento ou meses de projeto, qualquer pessoa pode descrever o que precisa e o Quick constrói a aplicação funcional automaticamente.

A proposta é clara: eliminar a barreira técnica entre uma ideia e um produto funcionando. Gerentes de produto, analistas financeiros, parceiros de Recursos Humanos (RH) e analistas de operações passam a ter autonomia para criar soluções próprias — sem escrever uma linha de código.

Como funciona na prática

O fluxo é direto: o usuário descreve o que quer, e o Quick entrega uma aplicação ativa, conectada em tempo real aos dados dos sistemas que a empresa já utiliza. A ferramenta se integra nativamente com plataformas amplamente adotadas no mercado corporativo, como:

• Salesforce
• Jira e Asana
• ServiceNow
• Microsoft 365 e Google Workspace
• Bancos de dados e data warehouses

As aplicações se mantêm atualizadas automaticamente conforme os dados subjacentes mudam. Além disso, todas as conexões respeitam as políticas de identidade, autorização e controle de acesso já existentes na organização — sem necessidade de reconfigurar permissões.

Publicação, compartilhamento e ajustes

Após a criação, o app pode ser publicado e compartilhado instantaneamente — seja para usuários específicos ou para toda a organização. E se for necessário ajustar algo, como adicionar inteligência artificial (IA), mudar o estilo visual ou conectar a outro sistema, basta descrever a mudança desejada. O Quick cuida do restante.

Casos de uso reais do período de prévia

Durante o período de prévia, empresas já utilizaram o Amazon Quick para substituir planilhas e ferramentas desconectadas por aplicações construídas para fins específicos. Dois exemplos se destacam:

• A New York Life desenvolveu um portal de e-learning para sua equipe de Vida Institucional, consolidando processos de onboarding, treinamentos e cursos de conformidade em uma única experiência.
• O próprio time do Amazon Quick passou a acompanhar pipeline, solicitações de clientes e métricas de adoção em um app de revisão semanal de liderança, substituindo a extração manual de dados de quatro sistemas diferentes.

Disponibilidade e como começar

A criação de apps no Quick está disponível para clientes dos planos Plus, Professional e Enterprise a partir de 1º de setembro de 2026. Para saber mais sobre como começar, a AWS disponibilizou o guia de introdução aos Apps no Quick.

Fonte

Amazon Quick now lets you build custom apps with natural language – (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-quick-custom-apps-natural-language/)

O problema que essa arquitetura resolve

Permitir que usuários façam upload de documentos e conversem com eles em tempo real parece simples na superfície. A interface de chat é relativamente fácil de construir — o problema real está na camada de recuperação por trás dela, especialmente quando a aplicação precisa atender múltiplos usuários ao mesmo tempo.

Em um ambiente multi-tenant, os documentos de cada usuário precisam ficar completamente isolados dos demais. Esse isolamento não pode depender de um valor enviado pelo cliente — ele precisa vir de uma identidade verificada no servidor. Quando você adiciona recuperação agêntica ao cenário, a complexidade aumenta: o agente decompõe uma pergunta em sub-consultas e executa múltiplas buscas em sequência, e cada um desses saltos precisa carregar o filtro correto do tenant. Se qualquer salto deixar de aplicar o filtro, o isolamento quebra.

Além disso, a equipe ainda precisaria construir e operar um motor de busca vetorial e full-text, um pipeline de ingestão que processe múltiplos formatos e um índice sincronizado. É uma quantidade significativa de infraestrutura para quem quer apenas entregar um recurso de chat com documentos.

A AWS publicou uma arquitetura de referência que endereça exatamente esse cenário usando o Amazon Bedrock Managed Knowledge Base.

O que o Amazon Bedrock Managed Knowledge Base oferece aqui

O serviço cuida da ingestão, armazenamento, embedding e ranqueamento dos documentos — sem infraestrutura para provisionar ou capacidade para monitorar. Ele também traz recuperação agêntica nativa, com planejamento iterativo e múltiplos saltos de busca para responder perguntas complexas, aplicando os filtros de acesso em cada etapa.

Com a ingestão direta via conector customizado, a aplicação envia o documento direto para a knowledge base e ele fica disponível para consulta em segundos. Não é necessário configurar pipelines externos de ingestão nem gerenciar índices separados.

Visão geral da solução

A arquitetura apresentada pela AWS tem dois fluxos principais: ingestão de documentos e recuperação conversacional. Os componentes centrais são:

• Amazon Bedrock Managed Knowledge Base: processa, armazena e recupera conteúdo multimodal, incluindo texto, vetores, metadados e arquivos estruturados como CSV e Excel. Um conector customizado recebe os uploads dos usuários diretamente.
• Amazon API Gateway e AWS Lambda: expõem os endpoints de upload, status e chat, e executam a lógica da aplicação.
• Amazon Cognito: autentica os usuários e fornece a identidade verificada que a aplicação usa para isolar os documentos de cada um.
• Amazon Simple Queue Service (SQS): desacopla os uploads da ingestão, absorve picos e encaminha mensagens com falha repetida para uma fila de mensagens mortas (dead-letter queue), mantendo o endpoint de upload responsivo.
• Amazon DynamoDB: rastreia o status de indexação de cada documento para que a aplicação mostre ao usuário quando ele está pronto para consulta.
• Amazon Simple Storage Service (S3): armazena temporariamente arquivos maiores que o limite inline e hospeda a aplicação de página única (SPA) atrás do Amazon CloudFront.

Como os dois fluxos funcionam

Ingestão de documentos

Quando um usuário faz upload de um documento, a aplicação extrai a identidade dele a partir do Token Web JSON (JWT) validado pelo API Gateway — nunca confia em um valor enviado diretamente pelo cliente. Essa identidade é incluída na mensagem enviada para a fila SQS junto com o documento ou sua referência no S3.

Arquivos de até 6 MB são enviados inline na chamada de API. Arquivos maiores, até 50 MB para texto, são primeiro enviados ao S3 e a mensagem carrega o URI do S3 para que o Bedrock leia o arquivo diretamente de lá.

Uma função Lambda worker lê a mensagem da fila, marca o documento com um atributo de metadados user_id igual ao identificador (sub) do usuário no Cognito, e então chama a API IngestKnowledgeBaseDocuments. O Amazon Bedrock fragmenta, faz o embedding e indexa o documento de forma assíncrona. O status de cada documento é registrado no DynamoDB, e o navegador consulta periodicamente um endpoint de status para atualizar a interface.

Um detalhe importante sobre a ingestão direta via conector customizado: ao contrário do conector S3 — que é projetado para ingestão em lote com sincronizações agendadas e pode sobrescrever ou remover um documento recém-adicionado — a ingestão direta via IngestKnowledgeBaseDocuments não tem sincronização. O documento persiste até ser explicitamente deletado. Além disso, como a aplicação atribui seus próprios IDs de documento, reingeri-lo com o mesmo ID atualiza o registro no lugar, sem criar duplicatas.

A knowledge base também mantém uma cópia do arquivo original recuperável via API GetDocumentContent, eliminando a necessidade de operar um repositório de documentos separado.

Ciclo de vida da indexação

A API de ingestão é assíncrona: ela retorna imediatamente com status STARTING, mas o documento só fica disponível para consulta depois que o Bedrock conclui o processamento. O ciclo passa por cinco estados:

• STARTING: requisição aceita, processamento ainda não iniciado.
• PENDING: na fila, aguardando um slot de processamento.
• IN_PROGRESS: parsing e embedding em execução.
• TEXT_INDEXED: fragmentos de texto indexados; para PDFs, o processamento multimodal ainda está em andamento. Já é possível consultar o texto.
• INDEXED: processamento completo, incluindo elementos multimodais como imagens e tabelas em PDFs.

A recomendação da AWS é marcar o documento como pronto ao atingir TEXT_INDEXED, e não esperar pelo INDEXED — a diferença só é relevante para conteúdo multimodal. Em testes com documentos pequenos (abaixo de 5 MB) em uma knowledge base ociosa, textos simples atingiram INDEXED em 2 a 3 segundos, enquanto PDFs chegaram a TEXT_INDEXED entre 5 e 30 segundos e a INDEXED em cerca de 90 segundos. Esses números são referências de ordem de grandeza para design, não garantias de latência.

Isolamento por usuário com filtros de metadados

Em uma aplicação multi-tenant, os documentos de um usuário nunca podem aparecer nos resultados de outro. A solução usa uma knowledge base compartilhada com filtros de metadados, em vez de provisionar uma knowledge base separada por tenant. Essa abordagem escala melhor para grandes volumes de usuários finais, evita custos de base de múltiplos índices pequenos e elimina a latência de criação de uma knowledge base no momento do cadastro.

O worker marca cada documento com o atributo user_id, e a aplicação aplica um filtro de igualdade nesse atributo em cada consulta. O valor do filtro é construído no servidor a partir do JWT verificado — nunca a partir do corpo da requisição. Esse é o limite de segurança real da solução.

A knowledge base tem a capacidade de inferir filtros a partir do texto da pergunta, mas isso é um recurso de relevância, não de controle de acesso. O isolamento precisa vir de um filtro explícito construído pela aplicação a partir da identidade autenticada. Como defesa em profundidade, a implementação de referência confirma que o filtro está correto antes de cada requisição e descarta qualquer fragmento retornado cujo user_id não corresponda ao do chamador.

Para cargas de trabalho reguladas que exigem que o próprio serviço aplique o controle de acesso, a knowledge base também suporta listas de controle de acesso (ACLs) no nível do documento, avaliadas contra um userContext no momento da consulta.

Recuperação e geração de respostas

Para responder a uma pergunta, a aplicação chama a API AgenticRetrieveStream com o filtro explícito de user_id. A API executa um ciclo completo de chat: decompõe a pergunta em sub-consultas, executa as buscas com o filtro aplicado em cada salto e transmite uma resposta fundamentada com citações quando o parâmetro generateResponse está ativo. Isso se encaixa diretamente em uma interface de chat e oferece baixo tempo até o primeiro token sem que a equipe precise orquestrar recuperação e geração separadamente.

Quando é necessário mais controle — como um prompt customizado por tenant ou um modelo específico — a recomendação é usar a API Retrieve para buscar os fragmentos e chamar a API Converse separadamente, passando o mesmo filtro por usuário.

O histórico de conversa não é persistido entre chamadas pela API. A aplicação precisa armazená-lo em seu próprio repositório (como o DynamoDB) e passar os turnos relevantes em cada requisição. Isso também permite aplicar o mesmo isolamento por usuário ao histórico de conversas.

Boas práticas para operar em escala

• Desacople uploads da ingestão com uma fila. Para cargas baixas, é possível chamar a API de ingestão diretamente do handler de upload. Para qualquer aplicação com uploads concorrentes, use o SQS entre o endpoint de upload e a ingestão. O worker pode empacotar até 10 documentos em cada chamada de IngestKnowledgeBaseDocuments, o que é a principal alavanca de throughput. Por exemplo, 500 uploads simultâneos se transformam em aproximadamente 50 chamadas em lote.
• Planeje para o limite de ingestão, não de recuperação. A API Retrieve suporta picos de 25 consultas por segundo (QPS) ou 10 QPS sustentados por knowledge base — raramente será o gargalo. O throughput de ingestão é adequado para uploads interativos, mas uma migração em massa de um repositório existente vai saturá-lo. Para esses cenários, use o conector S3 com sincronização agendada, que é projetado para cargas grandes de uma vez só.
• Trate o limite de concorrência como condição de retry. Ao exceder o limite, o Bedrock retorna ValidationException, não ThrottlingException. Um classificador de retry que só trata throttling vai interpretar isso como erro fatal e descartar o documento.
• Monitore os sinais que antecipam o teto. Acompanhe a taxa de sucesso da ingestão e o tempo para atingir INDEXED nos percentis P50 e P99. Um tempo crescente para INDEXED é o primeiro indicador de que o pipeline de ingestão está se aproximando do limite de throughput — bem antes de as requisições começarem a falhar.
• Persista o histórico de conversa você mesmo. A API AgenticRetrieveStream aceita turnos anteriores no parâmetro messages para suporte a contexto multi-turno, mas não os persiste entre chamadas. Armazene o histórico em seu próprio repositório e passe os turnos relevantes em cada requisição.

Custos

O custo da solução depende da configuração de modelos escolhida. Com modelos gerenciados, o Managed Knowledge Base é cobrado apenas por armazenamento e recuperação (por chamada, não por token), sem custo adicional de ingestão. Se você selecionar um modelo Amazon Bedrock, paga pelos tokens de embedding na ingestão e pelos tokens de orquestração e geração na recuperação agêntica. Os serviços de suporte (Lambda, API Gateway, SQS, DynamoDB e S3) representam uma fração pequena do custo total em escala moderada. Consulte a página de preços do Amazon Bedrock para os valores atuais.

Como começar

A AWS disponibilizou um repositório de exemplo no GitHub para quem quiser implantar a solução na própria conta e usá-la como base para uma aplicação de chat com documentos. Para se aprofundar no Amazon Bedrock Managed Knowledge Base, a AWS também publicou posts complementares sobre busca empresarial para agentes com Amazon Bedrock Managed Knowledge Base e sobre recuperação agêntica no Amazon Bedrock Managed Knowledge Base.

Fonte

Build multi-tenant agentic chat applications on enterprise data with Amazon Bedrock Managed Knowledge Base (https://aws.amazon.com/blogs/machine-learning/build-multi-tenant-agentic-chat-applications-on-enterprise-data-with-amazon-bedrock-managed-knowledge-base/)