Author: Make.com Service User

Fechando o ciclo: do modelo ao dashboard de negócio

A AWS publicou a terceira parte da série que demonstra como construir um workflow completo de Aprendizado de Máquina (ML) sem escrever uma linha de código. Se você acompanhou as partes anteriores, já sabe que a Parte 1 tratou da configuração do banco de dados no Snowflake e da infraestrutura base do projeto, enquanto a Parte 2 cobriu a preparação dos dados e a construção do modelo de detecção de fraudes usando o Amazon SageMaker Canvas — com transformações visuais via Data Wrangler e o algoritmo XGBoost.

Nesta terceira etapa, o fluxo se completa: as previsões geradas pelo SageMaker Canvas são integradas ao Amazon QuickSight, agora parte do Amazon Quick, para criar dashboards interativos que combinam dados operacionais com previsões de ML voltadas à Inteligência de Negócio (BI) para detecção de fraudes.

O que o Amazon QuickSight oferece neste contexto

O Amazon QuickSight é o serviço de Inteligência de Negócio (BI) da AWS voltado para construção de dashboards interativos, análise aprofundada de dados e compartilhamento de insights dentro de uma organização. Ele faz parte do Amazon Quick, que expande essas capacidades com Inteligência Artificial (IA) generativa — permitindo consultas em linguagem natural, agentes de IA personalizados para automação de workflows e Spaces colaborativos para organizar arquivos, dashboards e bases de conhecimento em um único lugar.

Para times que já utilizam o SageMaker Canvas, o Amazon Quick oferece um caminho direto das previsões de ML até dashboards prontos para o negócio, sem necessidade de infraestrutura adicional ou integrações customizadas.

Visão geral da solução

O objetivo desta etapa é cobrir o workflow completo para visualizar as previsões de detecção de fraudes no Amazon QuickSight: desde a importação do dataset de previsões do SageMaker Canvas até a construção de dashboards interativos e o uso das capacidades de BI generativo para obter insights em linguagem natural.

Pré-requisitos

Antes de iniciar a Parte 3, é necessário ter concluído as etapas anteriores:

• Parte 1 — Configurar uma conta no Snowflake, criar o banco de dados e a tabela de detecção de fraudes, e obter o nome da conta da organização no Snowflake para uso com o Amazon SageMaker Canvas.
• Parte 2 — Conectar o SageMaker Canvas ao Snowflake, preparar o dataset usando o Data Wrangler, construir e treinar o modelo XGBoost de detecção de fraudes, e enviar as previsões ao Amazon QuickSight.
• Criar uma conta no Amazon Quick para acessar o Amazon QuickSight, e atualizar os usuários para os perfis Admin Pro, Author Pro ou Reader Pro, que habilitam as capacidades de BI generativo.

Importando as previsões do Canvas como dataset

Antes de construir qualquer visualização, é preciso importar as previsões do Canvas no Amazon QuickSight como um dataset. As previsões enviadas na etapa anterior já estarão disponíveis no console do QuickSight. A partir do painel de navegação lateral, basta acessar a seção de Datasets para localizar o dataset de previsões do Canvas e, em seguida, criar uma nova análise — o que abre uma área em branco para começar a construir as visualizações que transformarão as previsões de detecção de fraudes em insights acionáveis.

Construindo visualizações

Com o dataset importado, o próximo passo é criar os visuais para analisar as previsões. Na interface de análise, o processo começa com a seleção de campos do dataset para montar o primeiro visual. Para orientações detalhadas sobre criação de dashboards, a AWS disponibiliza a documentação de criação de análises no Amazon QuickSight.

O resultado esperado é um dashboard de análise de fraudes que exibe padrões distribuídos em múltiplas dimensões — categorias de transação, comportamento por comerciante e tendências temporais.

BI generativo: insights em linguagem natural

As capacidades de BI generativo do Amazon QuickSight aceleram a criação de dashboards por meio de interações em linguagem natural. Para acessar esses recursos, é necessário que os usuários da conta estejam nos perfis Admin Pro, Author Pro ou Reader Pro dentro da assinatura do Amazon Quick. Esses perfis concedem acesso às funcionalidades de BI generativo correspondentes a cada papel, incluindo a capacidade de compartilhar tópicos de perguntas e respostas (Q&A) com outros usuários. Para entender como os nomes de assinatura se mapeiam para os perfis de usuário, a AWS disponibiliza a documentação sobre assinaturas e perfis do Amazon Quick.

Ao acessar o ícone de faísca (sparkle) no QuickSight, um painel lateral é aberto com opções contextuais baseadas na tarefa em andamento. Quando se trabalha em uma análise, é possível construir cálculos, criar e editar visuais, configurar tópicos de Q&A ou fazer perguntas diretamente sobre os dados.

Para gerar um visual personalizado, basta inserir uma descrição em linguagem natural no menu “Build a visual”. O sistema gera o visual automaticamente, e o usuário pode adicioná-lo ao dashboard com um clique. Um exemplo prático apresentado no artigo original é a criação de um visual de taxa de fraude por hora da transação — gerado a partir de uma consulta simples em linguagem natural — que revela como a atividade fraudulenta varia ao longo do dia, expondo padrões temporais que seriam difíceis de detectar manualmente.

Também é possível consultar o dashboard diretamente, sem criar um novo visual: basta inserir a pergunta no painel de BI generativo para obter uma resposta instantânea com base nos dados. O exemplo citado no artigo mostra uma consulta sobre o total de casos de fraude no estado de Washington, com o sistema retornando o resultado imediatamente — demonstrando como perguntas em linguagem natural podem surfaçar respostas orientadas a dados para usuários de negócio.

Publicando o dashboard

Após finalizar todas as modificações na análise, o processo de publicação do dashboard é direto. O usuário escolhe a opção “Publish” no canto superior da análise, define um nome descritivo para o dashboard e verifica se a opção “Allow executive summary” está selecionada — essa configuração habilita resumos executivos gerados por IA para os visualizadores do dashboard. Em seguida, basta confirmar a publicação.

Após a publicação, os usuários têm acesso a um conjunto de capacidades adicionais pelo menu superior do dashboard:

• Share — Controle de acesso e permissões para usuários e grupos.
• Send reports — Agendamento de entrega automatizada de relatórios por e-mail.
• Threshold alerts — Configuração de notificações quando métricas ultrapassam limites definidos.
• Export — Download do conteúdo do dashboard em formato PDF para distribuição offline.
• Create executive summary — Geração de insights com IA a partir dos dados do dashboard.

Outras capacidades para interagir, personalizar e compartilhar dashboards estão detalhadas na documentação oficial do Amazon Quick.

O resumo executivo usa IA generativa para analisar automaticamente as visualizações e apresentar insights em linguagem natural, facilitando que stakeholders entendam rapidamente os achados mais importantes sem precisar navegar pelo dashboard inteiro.

O que o dashboard de detecção de fraudes entrega

O dashboard resultante reúne as previsões do SageMaker Canvas e o Amazon QuickSight para expor padrões de fraude em categorias de transação, comportamento por comerciante e tendências temporais — tudo em uma única visão interativa. Com o agendamento automatizado de relatórios, alertas baseados em limites e resumos executivos gerados por IA, tanto times técnicos quanto não técnicos conseguem tomar decisões mais rápidas e orientadas por dados.

Com o BI generativo, stakeholders podem consultar insights em linguagem natural e acessar resumos executivos automáticos, fechando o ciclo do workflow de ML sem código construído ao longo de toda a série.

Conclusão da série

Esta série de três partes demonstra como os serviços da AWS podem trabalhar em conjunto para levar organizações de dados brutos a inteligência de negócio acionável, inteiramente por meio de ferramentas visuais e sem código. Para organizações que gerenciam grandes volumes de dados operacionais, esse workflow remove as barreiras tradicionais entre ciência de dados e tomada de decisão de negócio.

Insights que antes exigiam recursos especializados de engenharia agora estão acessíveis a analistas, times de operações e executivos por meio de uma arquitetura governada, escalável e totalmente gerenciada pela AWS. Seja para detectar anomalias, prever demanda, classificar riscos ou entender o comportamento de clientes, essa abordagem se aplica a diferentes casos de uso e setores.

Para começar a transformar dados do Snowflake em inteligência de negócio acionável, a AWS recomenda explorar o Amazon SageMaker Canvas e o Amazon QuickSight.

Referências da série

• Parte 1 – Configurando o ambiente Snowflake
• Parte 2 – Preparação de dados e construção do modelo com Amazon SageMaker Canvas

Fonte

Build a no-code ML workflow with Snowflake, Amazon SageMaker Canvas and Amazon Quick – Part 3: Visualizing insights with Amazon Quick Sight (https://aws.amazon.com/blogs/machine-learning/build-a-no-code-ml-workflow-with-snowflake-amazon-sagemaker-canvas-and-amazon-quick-part-3-visualizing-insights-with-amazon-quick-sight/)

Por que filtros de fonte e data importam para agentes de IA

Quando um agente de Inteligência Artificial (IA) usa busca na web para embasar suas respostas, a organização por trás desse agente precisa de mecanismos para controlar de onde vêm as informações e quão recentes elas precisam ser. Um agente de serviços financeiros não deveria fundamentar respostas em um blog sem curadoria. Um agente de informações de produto não deveria citar preços de três anos atrás quando o usuário pergunta sobre disponibilidade atual.

Pensando exatamente nesse problema, a AWS anunciou filtros de domínio e data de publicação em tempo de execução para o Web Search no Amazon Bedrock AgentCore — a plataforma da AWS para construir, conectar e otimizar agentes em escala com qualquer framework ou modelo. Essa capacidade faz parte da versão 1.2.0 do conector de busca na web.

O que há de novo na versão 1.2.0 do conector

O lançamento introduz dois novos recursos dentro do objeto filters no esquema de entrada da ferramenta Web Search:

1. Filtro de domínio em tempo de execução

É possível passar uma lista de inclusão (allowlist) ou exclusão (denylist) de domínios em cada invocação de tools/call. Isso oferece controle por requisição sobre quais fontes o agente pode consultar:

• filters.domainFilter.include — resultados desses domínios são retornados
• filters.domainFilter.exclude — resultados desses domínios são suprimidos

Cada lista suporta até 100 domínios, contados de forma independente.

2. Filtro por data de publicação

É possível restringir resultados a conteúdo publicado dentro de um intervalo de datas específico, usando limites em formato ISO-8601 UTC:

• filters.publishedDateFilter.from — data de publicação mais antiga (inclusive)
• filters.publishedDateFilter.to — data de publicação mais recente (inclusive)

Ambos os filtros são opcionais e aplicados por requisição. Omiti-los preserva o comportamento existente, onde todo o conteúdo indexado é elegível.

Por que filtros em tempo de execução fazem diferença

Cargas de trabalho reais com agentes exigem um controle mais granular do que políticas organizacionais amplas conseguem oferecer sozinhas:

• Restrição de fonte por tarefa: um agente de conformidade analisando atualizações regulatórias deveria buscar apenas em domínios .gov e publicadores aprovados, não na web aberta.
• Escopo temporal: um agente de inteligência de mercado resumindo “os resultados desta semana” nunca deveria trazer análises de trimestres anteriores, mesmo que estejam bem ranqueadas para a consulta.
• Permissão/bloqueio dinâmico por chamada: uma plataforma multitenant atendendo clientes diferentes pode precisar de políticas de domínio distintas por requisição, sem criar alvos separados para cada cliente.
• Garantia de atualidade do conteúdo: um agente de suporte ao cliente respondendo “o que mudou na última versão” deveria retornar apenas documentação publicada nos últimos 7 dias.

Como funciona: o fluxo da requisição

O ciclo de vida de uma requisição filtrada funciona da seguinte forma: o agente envia um tools/call com a consulta e os filtros; o Gateway mescla os filtros de tempo de execução com a política de nível administrativo; executa a consulta filtrada contra o índice web; aplica conformidade nos resultados brutos; e retorna apenas os resultados verificados para o agente embasar sua resposta.

Todo o ciclo acontece no lado do servidor. Não há loop de filtragem no cliente, nenhum pós-processamento e nenhuma ida e volta adicional.

O modelo de filtragem em camadas: admin + tempo de execução

Um princípio central desse lançamento é que os filtros de tempo de execução podem restringir, mas nunca ampliar o escopo definido por um administrador. Isso garante que a política corporativa seja sempre respeitada, independentemente do que uma chamada em tempo de execução solicite.

As listas de domínios no nível administrativo são configuradas durante a criação do recurso de conector. A lógica de mesclagem funciona assim:

• Listas de inclusão (allowlist): a lista efetiva é a interseção entre as listas admin e runtime. Se o admin permite [a.com, b.com, c.com] e a chamada runtime inclui [b.com, c.com, d.com], apenas b.com e c.com são pesquisados. O domínio d.com está fora da lista admin e é silenciosamente descartado.
• Listas de exclusão (denylist): a lista efetiva é a união entre as listas admin e runtime. Se o admin bloqueia [x.com] e a chamada runtime exclui [y.com], ambos ficam bloqueados.

Ou seja: uma chamada runtime não pode pesquisar um domínio que o admin não autorizou, e não pode desbloquear um domínio que o admin negou. Os filtros runtime só conseguem restringir ainda mais o espaço de busca.

Para detalhes completos de configuração e regras de composição, consulte a documentação de configuração de filtros de domínio no Guia do Desenvolvedor.

Comportamento de conformidade dos filtros

Quando os filtros estão ativos, o Web Search prioriza precisão em detrimento de abrangência. Resultados que não podem ser verificados contra os critérios do filtro são excluídos em vez de retornados sem filtragem:

• Com filtro de domínio ativo: resultados sem um domínio reconhecível são excluídos.
• Com filtro de data ativo: resultados sem uma data de publicação reconhecida são excluídos.

É possível receber menos resultados com filtros ativos, mas todos os resultados recebidos satisfazem os critérios especificados.

Como começar

O Web Search é entregue pelo AgentCore Gateway, uma capacidade do Amazon Bedrock AgentCore que oferece um endpoint gerenciado, compatível com o Protocolo de Contexto de Modelo (MCP — Model Context Protocol), para conectar agentes a ferramentas.

Pré-requisitos

• Um Amazon Bedrock AgentCore Gateway com um alvo Web Search fixado na versão 1.2.0 ou posterior do conector.
• Permissões de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management): o agente ou aplicação chamadora precisa de bedrock-agentcore:InvokeGateway no Nome de Recurso Amazon (ARN — Amazon Resource Name) do gateway, e a função de serviço do Gateway precisa de bedrock-agentcore:InvokeWebSearch. Consulte a documentação de configuração do papel de serviço do Gateway para a política completa.
• O SDK AWS mais recente (Python, JavaScript, Java, .NET, Go, Ruby ou PHP).

Passo 1: Criar um alvo Web Search com a versão 1.2.0

Use o SDK AWS para Python (Boto3) para criar (ou atualizar) um alvo fixado na versão 1.2.0, com políticas de domínio no nível administrativo. Se você já tem um alvo Web Search na versão 1.1.0, pode usar UpdateGatewayTarget para fixá-lo na 1.2.0 em vez de criar um novo alvo. Para opções adicionais de configuração, incluindo a CLI do AgentCore e o console, consulte a documentação de configuração da ferramenta Web Search.

import boto3

gateway_client = boto3.client("bedrock-agentcore-control", region_name="us-east-1")

# Create a Web Search target pinned to version 1.2.0 with admin-level domain filtering
target = gateway_client.create_gateway_target(
    gatewayIdentifier="your-gateway-id",
    name="web-search-filtered",
    targetConfiguration={
        "mcp": {
            "connector": {
                "source": {"connectorId": "web-search", "version": "1.2.0"},
                "configurations": [
                    {
                        "name": "WebSearch",
                        "parameterValues": {
                            "domainFilter": {
                                "include": [
                                    "approved-wire-1.com",
                                    "approved-wire-2.com",
                                    "sec.gov",
                                    "investor.gov",
                                ],
                                "exclude": ["unreliable-source.net"],
                            }
                        },
                    }
                ],
            }
        }
    },
    credentialProviderConfigurations=[
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ],
)

print(f"Target ID: {target['targetId']}")
print(f"Status: {target['status']}")

Passo 2: Invocar com filtros em tempo de execução

Imagine um agente que monitora ações de enforcement da SEC para uma equipe jurídica. A equipe confia apenas em sec.gov como fonte primária e precisa de ações do mês corrente, não de registros históricos. Veja o payload tools/call que o agente envia:

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "tools/call",
  "params": {
    "name": "WebSearch",
    "arguments": {
      "query": "latest SEC enforcement actions 2026",
      "filters": {
        "domainFilter": {
          "include": ["sec.gov"],
          "exclude": []
        },
        "publishedDateFilter": {
          "from": "2026-07-01T00:00:00Z",
          "to": "2026-08-04T23:59:59Z"
        }
      }
    }
  }
}

O agente recebe apenas resultados de sec.gov publicados nas últimas cinco semanas. Não há comentários jurídicos de terceiros nem registros desatualizados nos resultados.

Nota: o nome da ferramenta no tools/call segue o padrão <nome-do-alvo>___WebSearch. Para o alvo criado anteriormente, seria web-search-filtered___WebSearch.

Exemplos de código por caso de uso

A seguir estão exemplos de como usar o cliente MCP criado a partir do AgentCore Gateway com os novos filtros em tempo de execução. Para criar o cliente MCP, consulte a documentação com exemplos de código para criação do cliente MCP.

Exemplo 1: Assistente de pesquisa clínica com requisitos de citação regulatória

Um assistente para a equipe de assuntos regulatórios de uma farmacêutica, onde a política da empresa exige que toda resposta cite apenas FDA, NIH ou ClinicalTrials.gov:

import json

# Pharma research assistant: only approved regulatory sources
compliance_request = json.dumps({
    "jsonrpc": "2.0",
    "id": "req-001",
    "method": "tools/call",
    "params": {
        "name": "WebSearch",
        "arguments": {
            "query": "FDA drug approval process 2026 guidance",
            "maxResults": 10,
            "filters": {
                "domainFilter": {
                    "include": ["fda.gov", "nih.gov", "clinicaltrials.gov"]
                }
            }
        }
    }
})

# Send via your MCP client (SigV4-signed or OAuth-authenticated)
response = mcp_client.send(compliance_request)
results = json.loads(response)

# Every result is from fda.gov, nih.gov, or clinicaltrials.gov
for result in results["result"]["content"]:
    print(result["text"])

Exemplo 2: Agente de atualização de ações, apenas cobertura desta semana

Um agente que gera atualizações de ações ao longo do dia de negociação, garantindo que apenas resultados dos últimos 7 dias sejam retornados:

from datetime import datetime, timedelta, timezone

# Calculate the 7-day window
now = datetime.now(timezone.utc)
seven_days_ago = now - timedelta(days=7)

stock_update_request = json.dumps({
    "jsonrpc": "2.0",
    "id": "req-002",
    "method": "tools/call",
    "params": {
        "name": "WebSearch",
        "arguments": {
            "query": "semiconductor stocks latest developments",
            "maxResults": 15,
            "filters": {
                "publishedDateFilter": {
                    "from": seven_days_ago.strftime("%Y-%m-%dT%H:%M:%SZ"),
                    "to": now.strftime("%Y-%m-%dT%H:%M:%SZ")
                }
            }
        }
    }
})

response = mcp_client.send(stock_update_request)

Exemplo 3: Conformidade de relações com investidores — fontes primárias e trimestre atual

Um agente para preparar rascunhos de análise de resultados, com duas regras rígidas: apenas fontes primárias (registros SEC e páginas oficiais de investidores) e apenas publicações do trimestre atual:

# IR compliance agent: primary sources + current quarter only
financial_request = json.dumps({
    "jsonrpc": "2.0",
    "id": "req-003",
    "method": "tools/call",
    "params": {
        "name": "WebSearch",
        "arguments": {
            "query": "AMZN quarterly earnings report Q2 2026",
            "maxResults": 10,
            "filters": {
                "domainFilter": {
                    "include": ["sec.gov", "investor.gov"],
                    "exclude": ["example-crowd-commentary-1.com", "example-crowd-commentary-2.com"]
                },
                "publishedDateFilter": {
                    "from": "2026-04-01T00:00:00Z",
                    "to": "2026-08-04T23:59:59Z"
                }
            }
        }
    }
})

response = mcp_client.send(financial_request)

Exemplo 4: Plataforma SaaS com políticas de fonte por tenant

Uma plataforma de agentes de pesquisa como serviço atendendo clientes de saúde, jurídico e financeiro — cada um com políticas de fonte contratualmente acordadas. Um único alvo de gateway serve 200 tenants, cada um com sua própria política de fonte, aplicada dinamicamente em tempo de execução usando o SDK Strands Agents:

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp.mcp_client import MCPClient
from mcp.client.streamable_http import streamablehttp_client

# Per-tenant domain policies (from your config database)
TENANT_POLICIES = {
    "tenant-healthcare": {
        "include": ["pubmed.ncbi.nlm.nih.gov", "who.int", "cdc.gov"],
        "exclude": ["example-consumer-health-site.com"],
    },
    "tenant-legal": {
        "include": ["law.cornell.edu", "supremecourt.gov", "uscourts.gov"],
        "exclude": [],
    },
    "tenant-finance": {
        "include": ["sec.gov", "federalreserve.gov", "example-approved-wire.com"],
        "exclude": ["example-social-forum-site.com"],
    },
}

def search_for_tenant(tenant_id: str, query: str, days_back: int = 30):
    """Execute a policy-compliant web search for a specific tenant."""
    from datetime import datetime, timedelta, timezone

    policy = TENANT_POLICIES[tenant_id]
    now = datetime.now(timezone.utc)
    date_from = (now - timedelta(days=days_back)).strftime("%Y-%m-%dT%H:%M:%SZ")

    def create_transport():
        return streamablehttp_client(
            gateway_url,
            headers={"Authorization": f"Bearer {get_token()}"},
        )

    mcp_client = MCPClient(create_transport)
    model = BedrockModel(
        model_id="us.anthropic.claude-sonnet-4-20250514-v1:0",
        max_tokens=2048,
    )

    with mcp_client:
        tools = mcp_client.list_tools_sync()
        agent = Agent(model=model, tools=tools)

        # The agent's system prompt instructs it to pass these filters
        # on every WebSearch invocation
        system_prompt = f"""You are a research assistant. When using WebSearch, ALWAYS include these filters in your tool call:
- domainFilter.include: {policy['include']}
- domainFilter.exclude: {policy['exclude']}
- publishedDateFilter.from: {date_from}
Never search outside approved domains."""

        result = agent(query, system_prompt=system_prompt)
        return result.message

# Usage
answer = search_for_tenant(
    "tenant-healthcare",
    "What are the latest clinical trial results for GLP-1 drugs?"
)

Importante: a filtragem baseada em prompt de sistema (como mostrada acima) depende do agente seguir as instruções — não é uma aplicação rígida. Para aplicação forçada, configure os domínios permitidos no nível do alvo (lista de inclusão admin). Filtros runtime passados diretamente no payload do tools/call fornecem aplicação no nível da API que não pode ser contornada pelo modelo.

Referência do esquema de entrada

O objeto filters introduzido na versão 1.2.0 do conector adiciona domainFilter (listas de inclusão/exclusão, até 100 domínios cada) e publishedDateFilter (limites inclusivos em UTC no formato ISO-8601) aos campos existentes query e maxResults. Para o esquema de entrada completo e referência campo a campo, consulte o esquema de entrada na documentação do Amazon Bedrock AgentCore.

Disponibilidade e zero egresso de dados

A filtragem de domínio e data em tempo de execução está disponível hoje nas regiões US East (Norte da Virgínia) (us-east-1), Europe (Irlanda) (eu-west-1) e Asia Pacific (Tóquio) (ap-northeast-1) para o Web Search no Amazon Bedrock AgentCore.

Além dos filtros, esse lançamento também expande a disponibilidade do Web Search para duas novas regiões AWS: eu-west-1 (Dublin) e ap-northeast-1 (Tóquio). Clientes na Europa e na Ásia-Pacífico podem agora invocar o Web Search a partir de um endpoint regional mais próximo de suas cargas de trabalho, reduzindo latência e oferecendo um ponto de entrada baseado na União Europeia (UE) para organizações com requisitos de proximidade de dados.

O Web Search se beneficia da arquitetura de zero egresso de dados do AgentCore: as consultas de busca são servidas inteiramente dentro da infraestrutura AWS. As consultas dos clientes não são enviadas a um mecanismo de busca de terceiros nem roteadas para fora da AWS. Para organizações em setores regulamentados — como serviços financeiros, saúde e governo — isso elimina toda uma categoria de revisão de conformidade.

Compatibilidade retroativa

Esses recursos são totalmente compatíveis com versões anteriores:

• Sem quebras de compatibilidade. A versão 1.2.0 é uma versão menor. Os novos campos são aditivos e o objeto filters é opcional. Chamadas de API existentes sem filtros continuam funcionando exatamente como antes.
• Suporte a SDK. Disponível nos SDKs AWS (Python/Boto3, JavaScript/TypeScript, Java, .NET, Go, Ruby e PHP), Interface de Linha de Comando (CLI — Command Line Interface) da AWS e CLI do AgentCore.
• Suporte ao console. O console AWS para alvos Web Search do AgentCore agora exibe as entradas de lista de inclusão e exclusão de domínios na interface de configuração do conector.

Conclusão

A filtragem de domínio e data de publicação em tempo de execução oferece aos desenvolvedores que constroem sobre o Amazon Bedrock AgentCore Gateway a precisão por chamada necessária para criar agentes confiáveis e em conformidade com políticas — sem abrir mão da simplicidade de uma ferramenta de busca gerenciada no lado do servidor. Seja restringindo um agente a fontes regulatórias aprovadas, limitando resultados às últimas 24 horas ou aplicando dinamicamente políticas específicas por tenant, o Web Search no AgentCore mantém o controle com zero egresso de dados, autenticação nativa IAM e sem dependências externas.

Para começar, acesse: documentação de filtragem do Web Search no Amazon Bedrock AgentCore Developer Guide, preços do Amazon Bedrock AgentCore e página do produto Web Search no AgentCore.

Fonte

Domain and publish date filters for Web Search on AgentCore (https://aws.amazon.com/blogs/machine-learning/domain-and-publish-date-filters-for-web-search-on-agentcore/)

O problema: agentes de IA pensam antes de responder

Integrar um agente de Inteligência Artificial (IA) a um pipeline serverless parece simples à primeira vista — basta invocar o agente e aguardar a resposta. O problema é que agentes de IA, ao contrário de funções tradicionais, levam tempo para raciocinar. Dependendo do prompt, do modelo e do documento processado, esse tempo raramente é instantâneo. E essa latência muda completamente a forma como você deveria chamar o agente.

A implementação mais comum — e mais ingênua — é usar uma função AWS Lambda que invoca o agente e fica bloqueada aguardando a resposta. Enquanto a função espera, ela não faz absolutamente nada, mas continua sendo cobrada por cada segundo de execução. É exatamente esse desperdício que a AWS aborda em um post técnico recente sobre o Amazon Bedrock AgentCore.

Por que o custo ocioso acontece — e onde ele realmente cai

Para entender o problema, é importante separar os dois lados da chamada, pois cada um tem um modelo de cobrança diferente.

O Amazon Bedrock AgentCore Runtime opera com um modelo baseado em consumo: enquanto o agente aguarda a resposta de um modelo de linguagem de grande escala (LLM) ou de uma chamada de ferramenta via Protocolo de Contexto de Modelo (MCP), você paga pela memória alocada, mas não pelo processamento central (CPU). O agente, portanto, não desperdiça compute enquanto espera.

O problema está do outro lado: a função Lambda, o container ou a instância do Amazon Elastic Compute Cloud (Amazon EC2) que fez a chamada síncrona fica completamente bloqueada. Ela mantém toda a sua alocação de compute — e você paga por isso — até o agente responder. O custo do chamador acaba rastreando diretamente o tempo de processamento do agente.

A solução é liberar o compute do chamador durante a espera e retomar o pipeline apenas quando o agente tiver um resultado. A AWS apresenta três padrões que fazem exatamente isso.

O pipeline de exemplo

Para comparar os padrões em condições iguais, a AWS usa um pipeline de validação de documentos para financiamento imobiliário — um cenário simples e deliberadamente genérico, que serve como substituto para qualquer fluxo que chame um agente lento e precise agir sobre o resultado.

O pipeline tem cinco estágios:

• Extração: uma função Lambda realiza o reconhecimento óptico de caracteres (OCR) e extrai o texto do documento.
• Identificação: outra função Lambda classifica o documento e define flags de roteamento (shouldOrganize, shouldValidate).
• Roteamento: um estado Choice direciona o fluxo com base nessas flags.
• Organização e Validação: um estado Parallel organiza o documento enquanto, em um ramo separado, o agente do AgentCore valida o conteúdo. Esse ramo de validação é o único que muda entre os padrões.
• Resultado: uma função Lambda processa o veredicto do agente e decide a próxima ação.

Um único agente do Amazon Bedrock AgentCore atende todos os quatro cenários. Ele inspeciona cada invocação e escolha como responder: se receber um task token do AWS Step Functions, acorda aquela execução ao terminar. Se receber um callback ID de uma durable function, acorda a função. Se não receber nenhum dos dois, retorna o veredicto diretamente na resposta. Isso significa que é possível trocar o padrão de orquestração sem precisar reimplantar o agente.

O anti-padrão: chamada bloqueante

A implementação mais direta chama o agente e aguarda a resposta na mesma função Lambda. Funciona e é fácil de implementar — por isso é tão comum. Mas a função permanece ativa e sendo cobrada durante todo o tempo em que o agente está processando.

// The Lambda function blocks here until the agent responds
const response = await agentcore.send(
  new InvokeAgentRuntimeCommand({
    agentRuntimeArn: AGENT_RUNTIME_ARN,
    payload: new TextEncoder().encode(JSON.stringify(payload)),
    runtimeSessionId: sessionId,
  })
);
// The function stays alive and billed for the entire time the agent is thinking.

A duração cobrada da função acaba sendo aproximadamente igual ao tempo de processamento do agente. Os três padrões a seguir eliminam esse custo ocioso.

Padrão 1: Task-token callback com função despachante

Este padrão mantém uma função Lambda no caminho para lógica customizada, mas remove o custo ocioso. O Step Functions invoca a função com a integração waitForTaskToken, que passa um task token e pausa a execução. A função usa o token para iniciar o agente e retorna em poucos segundos. A execução permanece pausada — sem cobrar nada por compute — até que o agente chame SendTaskSuccess com aquele token para retomá-la.

// Start the agent, pass the task token, and return without waiting
const response = await agentcore.send(
  new InvokeAgentRuntimeCommand({
    agentRuntimeArn: AGENT_RUNTIME_ARN,
    payload: new TextEncoder().encode(JSON.stringify({
      ...payload,
      taskToken
    })),
    runtimeSessionId: sessionId,
  })
);
// Returning here does not complete the step. Step Functions stays paused until
// the agent calls SendTaskSuccess with this task token.
return { dispatched: true };

O estado correspondente no Step Functions passa o token do contexto e define um timeout e heartbeat como proteção, para que um agente silencioso falhe a execução de forma limpa em vez de deixá-la pausada indefinidamente:

"ValidateDispatch": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
  "Parameters": {
    "FunctionName": "${ValidateDispatcherFunctionArn}",
    "Payload": {
      "taskToken.$": "$$.Task.Token",
      "document.$": "$.document",
      "extractedText.$": "$.extract.extractedText",
      "executionId.$": "$$.Execution.Id"
    }
  },
  "TimeoutSeconds": 120,
  "HeartbeatSeconds": 60,
  "Next": "AgentCoreValidation"
}

Custo: a função Lambda roda apenas o tempo necessário para iniciar o agente e retornar — alguns segundos, independentemente de quanto tempo o agente leva depois. Você paga pelo despacho breve, não pela espera.

Padrão 2: Integração direta de serviço

Quando não há necessidade de código customizado ao redor da chamada ao agente, é possível remover a função despachante completamente. O Step Functions pode chamar o Amazon Bedrock AgentCore diretamente por meio de sua integração com o SDK da AWS — especificamente o AgentCore Harness (InvokeHarness) — e a resposta do agente flui diretamente para o próximo estado. O ramo de validação se torna um único estado Task:

"ValidateDirect": {
  "Type": "Task",
  "Resource": "arn:aws:states:::aws-sdk:bedrockagentcore:invokeAgentRuntime",
  "Parameters": {
    "AgentRuntimeArn": "${AgentRuntimeArn}",
    "RuntimeSessionId.$": "States.Hash($$.Execution.Id, 'SHA-256')",
    "Payload.$": "States.JsonToString($.prep.agentInput)"
  },
  "ResultSelector": {
    "raw.$": "$.Response"
  },
  "TimeoutSeconds": 120,
  "Next": "ParseVerdict"
}

Custo: não há função Lambda no caminho, logo não há compute ocioso de Lambda para pagar. O Step Functions segura a espera, e um workflow Standard cobra por transição de estado — não pela duração da espera. O custo significativo durante o processamento é o próprio agente.

Padrão 3: Lambda durable function

Se você prefere expressar a orquestração como código em um único lugar em vez de uma máquina de estados, uma Lambda durable function oferece o mesmo comportamento de custo. Com o SDK @aws/durable-execution-sdk-js, os estágios do pipeline se tornam chamadas context.step, o trabalho paralelo se torna context.parallel, e a espera pelo agente se torna context.waitForCallback. Durante essa espera, a função é suspensa e não cobra por compute. O agente a retoma com SendDurableExecutionCallbackSuccess.

// Suspend the function until the agent calls back
const result = await ctx.waitForCallback(
  "validate-agentcore",
  async (callbackId) =>
    dispatchAgentCore(callbackId, document, extractedText, executionId),
  { timeout: { seconds: 120 } }
);

Custo: uma única função mantém todo o pipeline, mas não cobra por compute enquanto está suspensa aguardando o agente. Você paga pelos curtos períodos de execução entre as suspensões — a mesma economia do padrão task-token.

Medindo a diferença na prática

A AWS apresenta um exemplo concreto de uma execução real com o padrão task-token para ilustrar a relação entre os valores:

• Estado ValidateDispatch no Step Functions ficou ativo por 19,6 segundos
• Duração cobrada da função Lambda despachante: 4,8 segundos
• Tempo de espera sem nenhuma função Lambda rodando: ~14,8 segundos

O ponto não é o número em si — o tempo de processamento do agente varia com o prompt, o modelo e o documento. O que importa é a relação: o tempo cobrado do despachante permanece fixo e curto, enquanto o tempo de processamento do agente pode crescer. Com a chamada bloqueante, esses dois valores seriam praticamente iguais.

Como escolher o padrão certo

A AWS resume os trade-offs da seguinte forma:

• Anti-padrão bloqueante: adequado apenas para protótipos ou agentes com tempo de resposta muito curto. Custo do chamador equivale ao tempo total do agente.
• Padrão 1 — Task-token: ideal quando você precisa de lógica customizada antes e depois da chamada ao agente. Requer configuração de Gerenciamento de Identidade e Acesso (IAM), heartbeat e timeout. Custo do chamador: apenas o despacho.
• Padrão 2 — Integração direta: melhor para orquestração pura, sem código customizado. Um único estado Task, sem Lambda no caminho. Custo: zero de Lambda.
• Padrão 3 — Durable function: preferível quando você quer toda a orquestração como código em um único lugar. Bom para fluxos assíncronos complexos. Custo do chamador: apenas os curtos períodos de execução.

Boas práticas recomendadas

A AWS lista algumas práticas importantes para quem for adotar esses padrões em produção:

• Proteja-se contra agentes que nunca respondem: defina TimeoutSeconds em todo estado waitForTaskToken para que a execução falhe com States.Timeout em vez de ficar pausada indefinidamente. Se o agente envia heartbeats, configure também HeartbeatSeconds para detecção mais rápida de falhas.
• Use um ID de sessão estável entre tentativas: defina o sessionId com um valor derivado do contexto de execução (como o nome da execução no Step Functions) para que novas tentativas retomem a mesma sessão do agente em vez de iniciar uma nova.
• Ative o AWS X-Ray: habilite o rastreamento ativo no Step Functions e no Lambda. O X-Ray mostra exatamente quanto tempo o agente passou processando versus quanto tempo o chamador ficou esperando, confirmando que o padrão realmente liberou compute durante o intervalo.
• Dimensione a função despachante para velocidade, não para a carga do agente: o despachante apenas serializa uma requisição e invoca um endpoint. 256 MB de memória e 30 segundos de timeout geralmente são suficientes. O trabalho pesado acontece no lado do agente.

Considerações de custo

Esses padrões geram cobranças por compute Lambda, transições de estado no Step Functions e armazenamento de execução de durable functions. O custo do Amazon Bedrock AgentCore Runtime e da inferência do modelo é o mesmo em todos os quatro casos — a arquitetura muda apenas a sobrecarga de orquestração e, no anti-padrão bloqueante, o compute ocioso desperdiçado do Lambda.

Código completo disponível no GitHub

O exemplo completo, incluindo o agente, as definições da máquina de estados e a durable function, está disponível no repositório sample-bedrock-agentcore-async-stepfunctions no GitHub. Para implantações em produção, a AWS recomenda o uso do Amazon Bedrock Guardrails para aplicar controles de IA responsável nas entradas e saídas do agente.

Fonte

Asynchronous patterns for calling Amazon Bedrock AgentCore agents in serverless pipelines (https://aws.amazon.com/blogs/machine-learning/asynchronous-patterns-for-calling-amazon-bedrock-agentcore-agents-in-serverless-pipelines/)

O problema: conhecimento preso no histórico de tickets

Equipes de suporte de TI resolvem milhares de chamados por mês. Cada ticket fechado carrega algo valioso: o sintoma relatado, a causa raiz identificada e a correção aplicada pelo engenheiro. O problema é que esse conhecimento fica preso no histórico do ticket — e o próximo profissional que enfrentar o mesmo problema provavelmente não vai encontrá-lo.

A base de conhecimento existente tem o problema inverso: ela cresce, mas cresce de forma desorganizada. Artigos duplicados se acumulam, conteúdos ficam desatualizados e a qualidade varia conforme quem escreveu e quando. Um engenheiro buscando uma resposta precisa vasculhar rascunhos quase idênticos, alguns precisos e outros defasados por várias versões do produto.

Foi para atacar esses dois lados do problema que a AWS desenvolveu o KnowledgeForge: uma solução que minera tickets resolvidos para gerar novos artigos e, ao mesmo tempo, cura a base existente — classificando, desduplicando, pontuando qualidade e reescrevendo conteúdo fraco. Um gestor de conhecimento revisa e aprova o resultado antes de qualquer publicação.

Os blocos de construção AWS por trás da solução

A arquitetura do KnowledgeForge apoia-se em três serviços principais: Amazon Bedrock para geração e melhoria de conteúdo, Amazon S3 Vectors para detecção de duplicatas e AWS Step Functions para orquestração. Os padrões aplicados aqui são reutilizáveis em qualquer pipeline de processamento de documentos em larga escala com IA generativa.

O ciclo fechado de ciclo de vida da base de conhecimento

O KnowledgeForge opera em dois subsistemas que se alimentam mutuamente. A geração transforma clusters de tickets em novos artigos de rascunho. Quando um grupo de tickets relacionados descreve o mesmo problema, o sistema escreve um artigo para a base de conhecimento e um documento de análise de causa raiz a partir desse cluster. A curadoria então leva cada artigo — tanto os recém-gerados quanto os já existentes — por quatro etapas: classificação por tipo, verificação de duplicatas, pontuação de qualidade e melhoria do conteúdo fraco.

O ciclo se fecha porque a curadoria armazena um vetor para cada artigo, e a geração lê esses vetores antes de escrever qualquer coisa nova. Em alto nível, um artigo percorre cinco estágios:

• Ingestão — Tickets resolvidos e artigos existentes chegam ao Amazon S3, rastreados por um catálogo de dados.
• Geração — Clusters de tickets se tornam novos artigos de rascunho no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate.
• Curadoria — Cada artigo é classificado, desduplicado, pontuado e melhorado por um fluxo do AWS Step Functions em AWS Lambda.
• Revisão humana — Artigos enriquecidos vão ao ServiceNow para aprovação do gestor de conhecimento, e a decisão é gravada no Amazon DynamoDB.
• Ciclo fechado — A curadoria incorpora cada artigo ao índice Amazon S3 Vectors, e a geração reutiliza esses vetores na próxima execução.

Gerando artigos a partir de clusters de incidentes

A geração começa com um cluster de tickets que compartilham um tema. Um processo upstream agrupa incidentes resolvidos pelo problema que descrevem e deposita o resultado em um bucket do Amazon S3 como arquivo JSON, com escopo por cliente. Cada tema traz palavras-chave, escopo do artigo e uma amostra de descrições e notas de trabalho dos tickets.

Antes de escrever, o sistema se ancora no que já existe. Para cada tema, ele recupera os cinco artigos existentes mais similares do índice Amazon S3 Vectors daquele cliente e os passa ao modelo como contexto de referência. Essa abordagem de Geração Aumentada por Recuperação (RAG) mantém a terminologia consistente e reduz procedimentos inventados.

A geração roda no Anthropic Claude Sonnet 4.5 via Amazon Bedrock. Para cada tema, o modelo produz dois documentos com estrutura fixa:

• Artigo da base de conhecimento: Título e resumo, sintomas, causa raiz, passos de resolução, prevenção e tópicos relacionados.
• Documento de análise de causa raiz: Resumo executivo, descrição do problema, impacto ao cliente, análise dos cinco porquês, solução de contorno e resolução, ações corretivas e preventivas, linha do tempo dos eventos-chave e código de causa.

O pipeline usa streaming de resposta do Amazon Bedrock para que o container monte cada documento conforme os tokens chegam, sem esperar pela resposta completa.

Por que containers em vez de funções

A geração roda no Amazon ECS com AWS Fargate por causa do perfil da carga de trabalho. Gerar dois documentos completos para um tema pode levar vários minutos, e um arquivo com muitos temas pode manter uma unidade de trabalho rodando por bastante tempo. A carga também chega em rajadas — períodos tranquilos seguidos de grandes lotes de uma vez. Um serviço de containers de longa duração que escala a contagem de tarefas conforme a profundidade da fila, e reduz quando a fila esvazia, se encaixa bem nesse padrão.

Detectando artigos duplicados com Amazon S3 Vectors

Duplicatas aparecem de várias formas: dois artigos descrevem a mesma correção com palavras diferentes, um artigo mais novo substitui um mais antigo, ou um engenheiro copia um artigo, muda duas linhas e salva como novo. A correspondência por palavras-chave não captura essas variações, então o pipeline compara por significado.

Cada artigo recebe um embedding de 1.024 dimensões gerado pelo Amazon Titan Text Embeddings V2, armazenado em um índice Amazon S3 Vectors por cliente. Um novo artigo é incorporado, o índice é consultado pelos vetores mais próximos, e qualquer resultado dentro de um limiar de distância cosseno estreito é considerado duplicata. O sistema começa com distância cosseno de 0,05 (similaridade de 0,95 ou mais) e um top-K de 5, ajustado por amostragem de pares sinalizados.

Quando o sistema encontra um par duplicado, mantém o artigo mais recente e aposenta o desatualizado. A versão mais nova e precisa vence — que é exatamente o comportamento que um engenheiro de suporte espera. Para detalhes sobre o Amazon S3 Vectors, consulte o Guia do Usuário do Amazon S3.

Reutilizar o índice dessa forma também ajuda em reexecuções: embeddings custam uma chamada ao modelo para serem produzidos. Uma reexecução lê o vetor armazenado em vez de recalculá-lo, economizando tempo e gasto com Amazon Bedrock quando um lote precisa rodar novamente.

Orquestrando a curadoria em escala com AWS Step Functions

A curadoria processa lotes de artigos que precisam de orquestração para distribuir o trabalho entre workers e se recuperar de falhas. O AWS Step Functions oferece isso com um mapa distribuído em duas fases, gerenciando o estado do fluxo, aplicando retentativas e tratamento de erros, e distribuindo o trabalho sem código de coordenação customizado. Para entender como o mapa distribuído funciona, consulte o Guia do Desenvolvedor do AWS Step Functions.

Um agendamento diário no Amazon EventBridge inicia a execução. Uma função AWS Lambda encontra clientes com artigos novos ou alterados, agrupa as mudanças em lotes e coloca cada lote em uma fila Primeiro a Entrar, Primeiro a Sair (FIFO) do Amazon Simple Queue Service (Amazon SQS). A fila FIFO ordena lotes por cliente entre execuções, usando o ID do cliente como chave do grupo de mensagens, de modo que clientes diferentes ainda rodem em paralelo.

A máquina de estados roda em duas fases, cada uma como mapa distribuído para que os artigos de um lote sejam processados de forma concorrente:

• Fase 1 — Classificar e incorporar: Cada artigo é classificado por tipo e recebe um embedding vetorial.
• Fase 2 — Desduplicar, pontuar e melhorar: O pipeline encontra duplicatas, pontua qualidade e melhora conteúdo abaixo do limiar.

Passando ponteiros, não payloads

Uma execução do Step Functions carrega estado entre etapas, com limite de 256 KB. Artigos da base de conhecimento com corpo HTML completo ultrapassam esse limite rapidamente. Em vez de passar o conteúdo do artigo pelo estado da máquina, o sistema escreve o lote no Amazon S3 e passa apenas a localização pelo fluxo. Cada worker do mapa lê o que precisa diretamente do Amazon S3, mantendo o payload de estado pequeno independentemente do tamanho dos artigos.

Recuperando-se de falhas

Dois mecanismos impedem que um lote com problema derrube toda a execução:

• Fila de mensagens mortas (DLQ): Um lote que falha repetidamente é separado para investigação em vez de bloquear a fila atrás dele.
• Circuit breaker (melhor esforço): Após três falhas consecutivas, o dispatcher para de iniciar novos lotes e redefine os artigos afetados ao estado inicial. O contador de falhas vive na memória de uma função Lambda aquecida, portanto não é compartilhado entre containers concorrentes e é reiniciado quando um novo job começa.

Tornando as chamadas ao Amazon Bedrock confiáveis em escala

Três controles mantêm a geração previsível sob carga:

• Timeout de tempo de parede: Um limite rígido em cada execução para que uma resposta lenta não mantenha um worker aberto indefinidamente.
• Retentativa automática com backoff: O cliente Amazon Bedrock roda em modo adaptativo, retentando automaticamente ao encontrar throttling, com backoff exponencial em chamadas de melhoria de conteúdo mais longas.
• Fallback de guardrail: Um guardrail do Amazon Bedrock filtra conteúdo indesejado na saída do modelo. Se o guardrail for limitado por throttling, o pipeline processa o artigo sem ele e registra um aviso, mantendo o fluxo durante picos de carga.

Um quarto controle trata saídas truncadas. Respostas de melhoria de conteúdo têm um orçamento de tokens, e um artigo longo pode atingi-lo, deixando a resposta JSON cortada. O sistema detecta o sinal de “parado no limite de tokens” e retenta com o dobro do orçamento, até o teto do modelo.

Pontuando qualidade antes e depois da melhoria

Nem todo artigo precisa de melhoria, e a melhoria nem sempre ajuda. Uma pontuação de qualidade decide. Cada artigo é avaliado em dez dimensões ponderadas, da maior para a menor peso:

• Completude
• Acionabilidade
• Estrutura
• Coerência
• Legibilidade
• Valor para autoatendimento
• Atualidade
• Prontidão para automação
• Gramática
• Segurança

O total ponderado produz uma pontuação única, e um limiar configurável decide se o artigo passa como está ou vai para melhoria. Artigos abaixo do limiar passam por melhoria de conteúdo, também via Amazon Bedrock.

Há um desafio prático aqui: um modelo pedido para melhorar prosa frequentemente também altera tags de imagem e hiperlinks, quebrando-os. Placeholders resolvem isso. Antes da melhoria, o sistema troca cada imagem e link por um token numerado, melhora a prosa ao redor desses tokens e restaura a mídia real depois. O modelo nunca vê a marcação bruta, então títulos e estrutura sobrevivem intactos.

Após a melhoria, o artigo é pontuado novamente. A nova versão só é mantida se sua pontuação superar a original. Caso contrário, o original prevalece. Essa verificação antes e depois permite melhorar conteúdo automaticamente sem silenciosamente piorar a biblioteca.

Isolamento por cliente em infraestrutura compartilhada

O sistema atende muitos clientes em infraestrutura compartilhada, e uma base de conhecimento é exatamente o tipo de dado que os clientes esperam mantido separado. O isolamento é projetado desde o início: cada cliente recebe sua própria cópia de tudo que toca seu conteúdo:

• Um perfil de configuração
• Um índice Amazon S3 Vectors
• Um conjunto de prompts de modelo
• Um guardrail do Amazon Bedrock
• Uma chave de criptografia do AWS KMS

Como esses recursos são por cliente, os dados de cada um ficam dentro de seu próprio limite. A verificação de duplicatas roda apenas contra o índice daquele cliente, a melhoria de conteúdo usa os prompts daquele cliente, e os dados são criptografados sob a chave daquele cliente. Não existe pool compartilhado onde artigos de um cliente possam aparecer nos resultados de outro.

Resultados e lições aprendidas

Como cada cliente flui por seu próprio grupo de mensagens FIFO no Amazon SQS, adicionar um cliente adiciona um fluxo paralelo de trabalho em vez de desacelerar os demais. A vazão real depende do tamanho dos artigos, da latência do modelo e das cotas do Amazon Bedrock de cada conta.

Quatro lições se destacam na experiência de construção da solução:

• Reutilizar o índice vetorial como detector de duplicatas transformou um problema difícil em uma consulta de vizinho mais próximo.
• Passar um ponteiro do Amazon S3 pelo Step Functions em vez do corpo do artigo eliminou uma classe inteira de falhas por tamanho de estado.
• Pontuar qualidade nos dois lados da melhoria tornou seguro rodar o processo automaticamente.
• Tratar o throttling do guardrail como aviso manteve o pipeline saudável durante picos de carga.

O ponto mais amplo é o próprio ciclo fechado: conteúdo gerado alimenta a curadoria, e a curadoria fundamenta a próxima rodada de geração, de modo que a base de conhecimento melhora conforme o sistema roda.

Como começar

Para construir um pipeline similar, a AWS sugere os seguintes passos:

• Crie um índice vetorial usando a documentação do Amazon S3 Vectors.
• Incorpore uma amostra dos seus próprios artigos e carregue os vetores.
• Execute a consulta de vizinho mais próximo para sinalizar duplicatas.
• Adicione o mapa distribuído do AWS Step Functions para processar artigos em lotes.
• Aplique a porta de qualidade pontuação-melhoria-repontuação.

O código completo está disponível no repositório aws-samples/sample-knowledgeforge no GitHub. Para aprofundamento, consulte o Guia do Usuário do Amazon Bedrock, o Guia do Desenvolvedor do AWS Step Functions e o Guia do Usuário do Amazon S3.

Fonte

KnowledgeForge: mining gold from the ITSM ticket graveyard (https://aws.amazon.com/blogs/machine-learning/knowledgeforge-mining-gold-from-the-itsm-ticket-graveyard/)

O que foi anunciado

No início de agosto de 2026, a AWS lançou o Web Search no Amazon Bedrock, uma ferramenta nativa do lado do servidor que permite ancorar as respostas dos modelos de fundação em informações atuais da web — tudo isso mantendo os dados dentro do ambiente seguro da AWS, sem nenhuma saída de dados para fora do ambiente.

Agora, a AWS expande esse recurso com uma novidade importante: o parâmetro external_web_access, que permite ao Web Search buscar conteúdo diretamente da web pública, dando aos modelos acesso às informações mais recentes disponíveis na internet.

Como funciona o acesso externo

Para habilitar o acesso externo, é necessário conceder a permissão do Gerenciamento de Identidade e Acesso (IAM) bedrock-websearch:ExternalWebAccess à identidade que faz a requisição. O parâmetro external_web_access já vem com o valor padrão true, então basta garantir a permissão correta.

Com isso habilitado, o Web Search passa a buscar conteúdo ao vivo da web pública — ideal para casos de uso que precisam das informações mais atualizadas possíveis, como:

• Placar de jogos em tempo real
• Preços dinâmicos de produtos ou ativos
• Documentações recém-publicadas

Mantendo os dados dentro da AWS

Para quem lida com dados sensíveis e precisa garantir que nenhuma informação saia do ambiente AWS, a configuração é simples: basta definir external_web_access: false. Com essa opção, o Web Search passa a servir resultados exclusivamente a partir do índice web e do grafo de conhecimento internos da Amazon, sem que nenhum dado da requisição ultrapasse o perímetro da AWS.

Essa flexibilidade é um ponto importante do design do recurso: a equipe pode escolher entre frescor das informações (acesso externo ativo) e controle total dos dados (acesso externo desativado), dependendo do caso de uso.

Disponibilidade regional

O acesso externo via Web Search está disponível nas seguintes regiões da AWS:

• Leste dos EUA (Norte da Virgínia)
• Leste dos EUA (Ohio)
• Oeste dos EUA (Oregon)

Saiba mais

Para se aprofundar no tema, a AWS disponibiliza um post detalhado no blog: Introdução ao Web Search no Amazon Bedrock para ancoragem de modelos de fundação. A documentação oficial sobre como controlar o acesso externo está disponível em Controlando o acesso externo à web no Guia do Usuário do Amazon Bedrock. Para informações sobre custos, consulte a página de preços do Amazon Bedrock.

Fonte

Launching External Web Access for Web Search on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-web-access-web-search/)

Novidades no Web Search do Amazon Bedrock AgentCore

A AWS anunciou melhorias importantes para o Web Search dentro do Amazon Bedrock AgentCore. O serviço passa a suportar filtros por domínio e filtros por data de publicação, oferecendo aos agentes de Inteligência Artificial (IA) um controle mais preciso sobre quais fontes e janelas de tempo são consideradas em cada busca.

O que é o Amazon Bedrock AgentCore?

O Amazon Bedrock AgentCore é a infraestrutura da AWS voltada para construção, conexão e otimização de agentes de IA. O componente Web Search permite que esses agentes fundamentem suas respostas em dados atuais da web — um recurso essencial para aplicações que precisam de informações em tempo real.

O que muda com os novos filtros?

Filtro por domínio em tempo de execução

Com o filtro de domínio em tempo de execução, os agentes conseguem restringir os resultados de busca a fontes confiáveis ou bloquear domínios indesejados — e isso acontece por chamada, sem necessidade de reconfiguração por parte dos administradores. Na prática, cada chamada de ferramenta pode incluir listas de domínios permitidos (include) e bloqueados (exclude).

Filtro por data de publicação

Já o filtro por data de publicação permite que os agentes delimitem os resultados a uma janela de tempo específica, usando limites de data inclusivos de início e fim. Isso garante que as respostas reflitam apenas conteúdo recente e relevante para o contexto da consulta.

Novidades para administradores

Além dos controles por chamada, os administradores também ganham novidades: agora há suporte a allowlist (lista de permissões) no nível do gateway, e o limite máximo de domínios por lista foi ampliado para até 100 domínios.

Para quem essas funcionalidades são mais relevantes?

Segundo a AWS, essas capacidades são especialmente úteis para:

• Setores regulados, que precisam garantir que as respostas dos agentes venham apenas de fontes autorizadas;
• Fluxos de trabalho de pesquisa, onde a procedência e a atualidade das informações são críticas;
• Aplicações que exigem controle rigoroso sobre as fontes de informação e a recência dos dados.

Expansão regional

Outra novidade relevante é a expansão geográfica do serviço. O Web Search Tool agora está disponível também nas regiões Europa (Irlanda) — eu-west-1 e Ásia-Pacífico (Tóquio) — ap-northeast-1, somando-se à disponibilidade já existente na região Leste dos EUA (Norte da Virgínia) — us-east-1.

Saiba mais

Para quem quiser se aprofundar, a AWS disponibilizou um blog técnico sobre os filtros de domínio e data de publicação, além da documentação oficial do produto Amazon Bedrock AgentCore.

Fonte

Web Search in Amazon Bedrock AgentCore adds domain and published date filtering, expands to Europe and Asia Pacific (https://aws.amazon.com/about-aws/whats-new/2026/08/web-search-amazon-bedrock/)