O problema que a AWS resolveu

Quem já trabalhou com políticas de Automated Reasoning checks (Verificações de Raciocínio Automatizado) no Amazon Bedrock Guardrails sabe que o maior atrito no processo não é criar a política — é afinar ela. O ciclo de diagnosticar falhas, editar regras manualmente, retestar e repetir consumia tempo considerável de especialistas. A AWS anunciou o refinamento automático de políticas, que automatiza justamente a parte de diagnóstico e correção desse ciclo.

Vale lembrar o que são os Automated Reasoning checks: eles traduzem linguagem natural para lógica formal e aplicam técnicas de verificação automatizada para produzir um resultado — VALID, INVALID, SATISFIABLE, IMPOSSIBLE ou TRANSLATION_AMBIGUOUS. Em traduções sem ambiguidade, o recurso entrega até 99% de precisão de verificação, conforme reportado no anúncio de disponibilidade geral.

O pipeline de dois passos que explica tudo

Para entender o refinamento, é preciso ter clareza sobre como uma política funciona internamente. O processo tem dois passos sequenciais:

• Passo de tradução: o texto em linguagem natural (entrada e saída) é mapeado para atribuições de variáveis, usando as descrições de variáveis definidas na política.
• Passo de validação: as regras formais da política são aplicadas sobre essas atribuições para chegar a um resultado final.

Quando um teste falha, o problema está em um desses dois passos. É exatamente por isso que o refinamento automático oferece dois modos distintos, cada um mirando uma etapa diferente do pipeline.

Os dois tipos de falha — e como identificá-los

Falha tipo 1: problema nas regras (a lógica está errada)

Nesse cenário, a tradução funcionou corretamente — as variáveis certas receberam os valores certos — mas o resultado da validação não corresponde ao esperado. O problema está nas regras: alguma está permissiva demais, restritiva demais ou simplesmente ausente. O modelo entendeu a pergunta perfeitamente, mas aplicou a lógica errada.

Falha tipo 2: tradução ambígua (a linguagem está errada)

Quando um teste retorna TRANSLATION_AMBIGUOUS, significa que o motor de validação chegou a resultados diferentes dependendo de qual interpretação seguiu. As causas mais comuns incluem variáveis com definições sobrepostas (por exemplo, “tempo de serviço” e “meses de emprego” descrevendo o mesmo conceito), descrições vagas, formatos de valor inconsistentes (5 versus 0,05 para representar “5%”) e nomes de variáveis que já embutem negações, o que confunde os modelos de tradução.

Modo 1: Refinamento Iterativo — corrigindo as regras

O Refinamento Iterativo (ITERATIVELY_REFINE_POLICY) é indicado quando a tradução está correta, mas o resultado da validação não bate com o esperado. Antes desse recurso, corrigir uma política com 10 a 30 regras exigia que um especialista rastreasse cada regra manualmente, formulasse hipóteses e editasse lógica formal SMT-LIB à mão. Esse trabalho agora se resume a uma etapa de revisão e aprovação.

Como funciona

O motor recebe três entradas: a definição atual da política (regras, variáveis e tipos), um documento-fonte com o texto autoritativo em linguagem natural, e — opcionalmente — um feedback em linguagem natural descrevendo explicitamente o que deve mudar. Por exemplo: “Atualize o requisito de tempo de serviço para licença parental de 12 para 6 meses, conforme a seção 3 do documento revisado.”

Internamente, o motor gera uma proposta de mudança, simula o efeito sobre os testes salvos, verifica se os testes que falhavam agora passam e ajusta caso necessário. Esse ciclo acontece de forma transparente — o que o usuário recebe é o resultado convergido: um diff mostrando exatamente quais regras e variáveis foram alteradas e como cada teste é afetado.

Fluxo via API (Boto3)

O refinamento é executado como um fluxo assíncrono. O processo tem quatro etapas: exportar a definição atual da política, iniciar o fluxo, aguardar a conclusão e recuperar as mudanças propostas.

import boto3
bedrock = boto3.client("bedrock")

# Export the current policy definition (required input to the workflow).
policy_definition = bedrock.export_automated_reasoning_policy_version(
    policyArn=policy_arn,
)["policyDefinition"]

with open("hr-leave-policy.pdf", "rb") as f:
    source_document = f.read()

response = bedrock.start_automated_reasoning_policy_build_workflow(
    policyArn=policy_arn,
    buildWorkflowType="ITERATIVELY_REFINE_POLICY",
    sourceContent={
        "policyDefinition": policy_definition,
        "workflowContent": {
            "iterativeRefinementContent": {
                "documents": [
                    {
                        "document": source_document,
                        "documentName": "hr-leave-policy.pdf",
                        "documentContentType": "pdf",
                    }
                ],
                "feedback": "Update the tenure requirement from 12 to 6 months per section 3.",
            }
        },
    },
)
build_workflow_id = response["buildWorkflowId"]

A chamada retorna imediatamente com um buildWorkflowId. O fluxo passa pelos estados SCHEDULED → BUILDING até atingir COMPLETED, FAILED ou CANCELLED. A convergência leva tipicamente de um a alguns minutos, dependendo do tamanho da política.

import time

while True:
    workflow = bedrock.get_automated_reasoning_policy_build_workflow(
        policyArn=policy_arn,
        buildWorkflowId=build_workflow_id,
    )
    status = workflow["status"]
    if status in ("COMPLETED", "FAILED", "CANCELLED"):
        break
    time.sleep(10)

if status == "COMPLETED":
    assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets(
        policyArn=policy_arn,
        buildWorkflowId=build_workflow_id,
        assetType="POLICY_DEFINITION",
    )
    proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"]

A definição retornada é o DRAFT proposto. Para confirmar as mudanças, basta chamar update_automated_reasoning_policy com essa definição. Para ver o que mudou, compare com a definição exportada antes de iniciar o fluxo.

Modo 2: Refinamento de Variáveis Ambíguas — corrigindo a linguagem

Quando os testes retornam TRANSLATION_AMBIGUOUS, nenhuma quantidade de edição de regras vai resolver o problema — a raiz está na linguagem usada para descrever as variáveis. O Refinamento de Variáveis Ambíguas (RESOLVE_POLICY_AMBIGUITIES) identifica quais descrições de variáveis causam interpretações conflitantes e propõe definições mais precisas.

O que ele corrige

O modo detecta padrões como variáveis sobrepostas (duas variáveis descrevendo o mesmo conceito), descrições incompletas ou vagas, formatos de valor inconsistentes e nomes de variáveis que embutem negações. Quando variáveis sobrepostas são detectadas, pode ser proposta uma fusão: uma variável é eliminada e as regras que a referenciavam são atualizadas para usar a variável sobrevivente.

Um exemplo típico de proposta antes/depois:

• Antes: tenureMonths: “How long the employee has worked in months.”
• Depois (proposto): tenureMonths: “The number of complete months the employee has been continuously employed. When users mention years of service, convert to months (for example, 2 years = 24 months). This variable captures references to employment duration, length of service, time at the company, or seniority.”

Fluxo via API

O padrão assíncrono é o mesmo do Refinamento Iterativo. A diferença é que esse modo analisa as variáveis da política diretamente e não exige documento-fonte nem testes anexados — apenas a definição atual da política em sourceContent.

response = bedrock.start_automated_reasoning_policy_build_workflow(
    policyArn=policy_arn,
    buildWorkflowType="RESOLVE_POLICY_AMBIGUITIES",
    sourceContent={
        "policyDefinition": policy_definition,
    },
)
build_workflow_id = response["buildWorkflowId"]

O polling e a recuperação dos resultados seguem exatamente o mesmo padrão mostrado para o Refinamento Iterativo, usando assetType="POLICY_DEFINITION".

O princípio inegociável: aprovação humana em todas as mudanças

Os dois modos compartilham uma propriedade fundamental: nenhuma alteração entra em vigor sem aprovação explícita. O motor de refinamento tem autoridade para sugerir. O usuário tem autoridade para confirmar. Nenhuma mudança chega à política DRAFT — muito menos à produção — sem que o responsável aceite a proposta.

A tela de revisão mostra simultaneamente o diff das mudanças propostas (regras adicionadas, editadas ou removidas; variáveis alteradas; tipos de variáveis customizados modificados) e o impacto de cada mudança sobre todos os testes salvos. Se os testes que falhavam agora passam e os que passavam continuam passando, a proposta pode ser aceita com confiança.

Walkthrough A: corrigindo um problema de regra

Considere uma política de elegibilidade de licença parental de RH com um teste falhando. O assistente informa que um funcionário em regime de meio período com 8 meses de tempo de serviço é elegível para licença parental. O teste espera INVALID, mas a política retorna VALID.

Ao inspecionar o resultado do teste, as variáveis estão corretamente capturadas: monthsOfContinuousService = 8 e employmentStatus = PART_TIME. O resultado é VALID porque a única regra de suporte concede elegibilidade após 6 meses de serviço contínuo, sem nenhuma regra que exclua funcionários de meio período. A tradução está correta — o problema é de lógica.

Ao acionar o Refinamento Iterativo com o documento-fonte e o feedback “Add a rule that explicitly makes part-time employees ineligible for parental leave”, o motor propõe duas mudanças: remove a regra que concedia elegibilidade apenas por tempo de serviço e adiciona uma regra que exclui funcionários de meio período. O teste que falhava passa a ser aprovado, sem regressões nos demais.

Walkthrough B: corrigindo um problema de linguagem

Na mesma política de RH, um teste retorna TRANSLATION_AMBIGUOUS. O resultado mostra duas interpretações: uma mapeou “2 anos de serviço” para tenureMonths = 24 e outra para monthsOfService = 24. Duas variáveis descrevem o mesmo conceito — essa sobreposição é a raiz da ambiguidade.

O Refinamento de Variáveis Ambíguas não exige documento-fonte. Ao ser acionado, ele propõe eliminar monthsOfService, atualizar as regras que a referenciavam para usar tenureMonths e expandir a descrição dessa variável para incluir instruções explícitas de conversão e sinônimos. Após aceitar a proposta, o teste que retornava TRANSLATION_AMBIGUOUS passa a produzir um resultado definitivo.

Validando com o Relatório de Fidelidade

Após aplicar qualquer refinamento, a AWS recomenda gerar um Relatório de Fidelidade (GENERATE_FIDELITY_REPORT) para verificar se a política atualizada ainda representa fielmente o documento-fonte. O relatório fornece três métricas: pontuação de cobertura (0,0–1,0), pontuação de precisão (0,0–1,0) e ancoragem por regra, que vincula cada regra às declarações específicas do documento que a sustentam. Comparar os relatórios antes e depois do refinamento é a forma mais confiável de detectar se uma correção fez a política se desviar da intenção original.

Boas práticas

• Inspecione a tradução antes de escolher o modo. Abra o resultado do teste falhando e verifique as atribuições de variáveis. Se as variáveis certas têm os valores certos mas o resultado está errado, use Refinamento Iterativo. Se as atribuições estão erradas ou o resultado é TRANSLATION_AMBIGUOUS, use Refinamento de Variáveis Ambíguas.
• Delimite os inputs para limitar o escopo da mudança. Um documento-fonte focado em uma parte específica da política, combinado com feedback objetivo em formato “se-então”, produz propostas mais precisas e revisáveis do que apontar o motor para um manual de 40 páginas com instruções vagas.
• Confie no painel de resultados de testes, não apenas no diff. Um diff aparentemente limpo que causa regressão em testes que passavam não é uma correção válida.
• Compare Relatórios de Fidelidade antes de versionar. O refinamento otimiza para fazer testes passarem — essa otimização pode distanciar uma regra do que o documento-fonte realmente diz.

Casos de uso em setores regulados

A AWS destaca aplicações práticas em múltiplos setores: em RH, manuais de benefícios atualizados anualmente podem ser ingeridos pelo Refinamento Iterativo para propor atualizações de regras sem que o time precise tocar em lógica formal. Em serviços financeiros, variáveis sobrepostas como debtToIncomeRatio e DTI são consolidadas pelo Refinamento de Variáveis Ambíguas para suportar validação determinística. Em saúde e manufatura, equipes de conformidade podem refinar políticas iterativamente mantendo trilha de auditoria completa por meio de snapshots versionados e Relatórios de Fidelidade.

Recursos adicionais

• Documentação: documentação de Automated Reasoning checks
• Guia prático: Como minimizar alucinações de IA generativa com Automated Reasoning checks
• Chatbot com reescrita iterativa: implementação de referência do chatbot com Automated Reasoning checks e código de exemplo no GitHub
• Agente de formalização de políticas: exemplo open-source de agente que guia especialistas pelo processo em linguagem natural
• Exemplos de código: exemplos de Automated Reasoning checks no GitHub
• Resultados de clientes: caso Amazon Logistics | caso PitCrew | caso PwC Responsible AI in Education | recursos de IA Responsável da AWS
• Funcionalidades relacionadas: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore
• Orientações de IA responsável: AWS Well-Architected Responsible AI Lens

Fonte

Automated Reasoning policy refinement in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/automated-reasoning-policy-refinement-in-amazon-bedrock/)

Da prototipagem à produção: o desafio muda de forma

Quando um agente de Inteligência Artificial (IA) sai do ambiente de prototipagem e vai para produção, o tipo de problema que surge muda completamente. No início, o esforço é fazer o agente funcionar. Em produção, o desafio passa a ser mantê-lo rápido, estável e econômico.

A AWS publicou a segunda parte de sua série sobre depuração e otimização de agentes com o AgentCore Observability, recurso do Amazon Bedrock AgentCore. Enquanto a Parte 1 tratou de agentes quebrados — com loops infinitos e erros de invocação de ferramentas —, esta edição foca em agentes que funcionam corretamente, mas que apresentam problemas de performance: respostas lentas e crescimento descontrolado de memória em sessões longas.

Esses problemas são insidiosos: não disparam alertas de erro, mas corroem a confiança do usuário e aumentam custos ao longo do tempo. O artigo da AWS demonstra como usar o AgentCore Observability em conjunto com o Amazon CloudWatch para diagnosticar e corrigir esses cenários de forma sistemática.

Cenário 3: Gargalos de desempenho

Um agente com gargalo de desempenho é aquele que completa suas tarefas corretamente, mas demora demais para responder. O que é “demais” depende do contexto: 5 segundos podem ser aceitáveis para um processo em lote, mas inviáveis para um chatbot de atendimento ao cliente.

O padrão típico de degradação é gradual: o agente começa com 2 segundos de resposta, mas à medida que novas ferramentas são integradas e mais memória é acumulada, a latência sobe para 5, depois 10 segundos, até se tornar inutilizável. A taxa de erros permanece baixa — o que dificulta a detecção por alertas tradicionais.

Como identificar o gargalo

O primeiro passo é identificar as requisições com alta latência. Para isso, o artigo sugere consultar o CloudWatch buscando invocações do agente que ultrapassem o orçamento de desempenho definido para o seu caso de uso:

fields @timestamp, RequestId, Latency
| filter Operation like /InvokeAgent/
| filter Latency > 3000
| sort Latency desc
| limit 50

Essa consulta retorna as invocações que levaram mais de 3 segundos, ordenadas por latência. A partir de um RequestId representativo, é possível analisar a linha do tempo da requisição para entender onde o tempo está sendo gasto:

fields @timestamp, Operation, Duration, SpanName
| filter RequestId = "<RequestId>"
| sort @timestamp asc

Operações que consomem tempo de forma desproporcional são os principais suspeitos: recuperação de memória, invocação de ferramentas, geração de tokens e operações sequenciais que poderiam rodar em paralelo.

Para verificar especificamente a latência de recuperação de memória:

fields @timestamp, MemoryRetrievalLatency, MemoryNamespace
| filter RequestId = "<RequestId>"
| stats avg(MemoryRetrievalLatency), max(MemoryRetrievalLatency) by MemoryNamespace

A recuperação de memória deve ser concluída em menos de 200 milissegundos. Valores acima disso indicam organização ineficiente da memória. Para identificar ferramentas lentas:

fields @timestamp, ToolName, ToolLatency
| filter RequestId = "<RequestId>"
| sort ToolLatency desc

Causas raiz e como corrigir

O artigo da AWS aponta três causas principais de gargalos de desempenho:

• Execução lenta de ferramentas: ferramentas externas que demoram segundos para responder por conta de falta de otimização, sobrecarga ou latência de rede. O efeito se amplifica com chamadas sequenciais — uma ferramenta de 2 segundos chamada três vezes resulta em 6 segundos de espera.
• Geração excessiva de tokens: Modelos de Fundação (FM — Foundation Models) geram tokens de forma sequencial. Uma resposta de 500 tokens demora 5 vezes mais do que uma de 100 tokens, impactando latência e custo.
• Processamento sequencial: executar operações independentes uma após a outra, em vez de em paralelo, aumenta desnecessariamente o tempo total de resposta.

As correções recomendadas incluem: implementar cache, connection pooling e indexação adequada de banco de dados para ferramentas lentas; substituir grandes namespaces únicos por partições temáticas (preferências, histórico, conhecimento de domínio) para reduzir o espaço de busca na memória; otimizar prompts para respostas mais diretas e concisas; e paralelizar chamadas de ferramentas independentes. Chamadas sequenciais que somam 4,5 segundos (2s + 1,5s + 1s) caem para apenas 2 segundos quando paralelizadas — uma redução de 50% ou mais com esforço mínimo.

A imagem acima ilustra uma linha do tempo de rastreamento OpenTelemetry com 17 spans distribuídos em três operações sequenciais de execute_event_loop_cycle. As ferramentas customer_lookup e order_history são executadas uma após a outra, com cada ciclo aguardando o anterior terminar — padrão que compõe a latência a cada invocação de ferramenta.

Cenário 4: Problemas de memória em sessões longas

Agentes que mantêm sessões prolongadas — como assistentes de atendimento ao cliente, pesquisa ou monitoramento — acumulam contexto ao longo do tempo. Sem uma estratégia de gerenciamento de memória adequada, esse crescimento se torna ilimitado: o agente atinge limites de tokens, perde contexto importante ou esgota a memória disponível, resultando em falhas inesperadas de sessão.

Sintomas a observar

Os sinais de alerta incluem: sessões anormalmente longas, uso de tokens crescendo linearmente com a duração da sessão, latência de recuperação de memória aumentando progressivamente e sessões encerrando com erros de memória esgotada ou janela de contexto excedida.

O exemplo acima mostra os detalhes de sessão do agente memorygrowth_Agent: 6 traces, 15,7 mil tokens consumidos e latência média de 3.757 ms por trace em uma única sessão. O uso de tokens cresce a cada invocação sucessiva, demonstrando acumulação ilimitada de contexto — padrão que em sessões de horas leva ao esgotamento da janela de contexto e falhas inesperadas.

Como diagnosticar

Para identificar sessões longas com alto uso de memória, o artigo sugere a seguinte consulta no CloudWatch:

fields @timestamp, SessionId, SessionDuration, MemorySize, TokenUsage
| filter SessionDuration > 3600
| sort MemorySize desc
| limit 20

Essa consulta retorna sessões com mais de uma hora de duração, ordenadas pelo tamanho da memória. A partir de um SessionId com uso anormalmente alto, é possível examinar os padrões de extração de memória para verificar se a consolidação está ocorrendo:

fields @timestamp, MemoryExtractionStatus, MemoryExtractionLatency, MemoriesExtracted
| filter SessionId = "<SessionId>"
| sort @timestamp asc

A extração de memória deve ocorrer regularmente ao longo da sessão. Lacunas prolongadas sem extração indicam que o agente não está consolidando memórias adequadamente. Para verificar falhas de extração:

fields @timestamp, ErrorMessage, MemoryExtractionStatus
| filter SessionId = "<SessionId>"
| filter MemoryExtractionStatus = "Failed"

Falhas na extração de memória impedem o agente de consolidar contexto, causando crescimento ilimitado. As causas mais comuns incluem: limite de tokens excedido durante a sumarização, formatos de memória inválidos, timeouts de rede ao gravar no armazenamento de memória e erros de permissão que bloqueiam atualizações.

Para analisar a organização dos namespaces de memória:

fields @timestamp, MemoryNamespace, MemoryCount, MemorySize
| filter SessionId = "<SessionId>"
| stats sum(MemoryCount) as TotalMemories, sum(MemorySize) as TotalSize by MemoryNamespace
| sort TotalSize desc

Um único namespace com milhares de memórias é um sinal claro de que o agente precisa de melhor organização de memória.

Como corrigir

Para resolver problemas de memória, a AWS recomenda verificar se as estratégias de memória incluem uma configuração de consolidação, para que o AgentCore Memory mescle e sumarize registros ao longo do tempo em vez de acumulá-los indefinidamente. Também é importante organizar registros usando templates de namespace nas definições de estratégia, garantindo que a recuperação fique restrita ao contexto relevante. O parâmetro eventExpiryDuration controla por quanto tempo os eventos brutos persistem (entre 7 e 365 dias). Para mais detalhes, a AWS disponibiliza documentação sobre como o AgentCore Memory funciona e sobre a implementação do AgentCore Memory.

Boas práticas para produção

Além dos cenários de diagnóstico, o artigo da AWS apresenta um conjunto de boas práticas para evitar esses problemas antes que ocorram.

Instrumentação abrangente

Ative a instrumentação completa para agentes em produção, sistemas de memória e gateways. Configure logs do CloudWatch, métricas do CloudWatch e rastreamentos OpenTelemetry. Não espere que usuários reportem problemas — configure alarmes para métricas críticas com os seguintes limites sugeridos: taxa de erros acima de 5%, latência no percentil 95 (P95) acima de 3 segundos e uso de tokens por sessão.

Dashboards operacionais

A AWS recomenda criar um dashboard principal com: total de invocações nas últimas 24 horas, taxa de erros atual comparada ao baseline, latências P50/P95/P99, tendências de uso de tokens e contagem de sessões ativas. Dashboards por agente devem mostrar padrões de invocação específicos, distribuição de uso de ferramentas, tendências de consumo de memória, distribuição de tipos de erro e custo por sessão. Revisar esses dashboards diariamente ajuda a identificar tendências antes que se tornem problemas.

Avaliação contínua com AgentCore Evaluators e Insights

Para monitorar a precisão das ferramentas em escala, a AWS oferece o AgentCore Evaluators, que inspeciona sessões de agentes em tempo real e as pontua com base em critérios de qualidade predefinidos — sem necessidade de revisão manual de traces após falhas. O AgentCore Insights (preview) complementa os Evaluators com análise de triagem, extração de intenção do usuário e resumo de execução.

Limpeza de recursos

Após testar as técnicas de otimização, a AWS orienta remover os recursos criados para evitar cobranças desnecessárias. Para recursos do CloudWatch, exclua dashboards de teste, remova alarmes criados para fins de teste e considere arquivar ou excluir grupos de logs antigos. Para recursos do AgentCore, exclua agentes de teste pelo console do AgentCore, remova namespaces de memória de teste e delete integrações de ferramentas temporárias.

Para excluir grupos de logs do CloudWatch via CLI:

aws logs delete-log-group --log-group-name /aws/bedrock-agentcore/your-agent-name

Para remover alarmes do CloudWatch:

aws cloudwatch delete-alarms --alarm-names your-alarm-name

Também vale revisar as configurações de retenção de logs do CloudWatch e considerar o uso do CloudWatch Logs Data Protection para reduzir custos de armazenamento de logs mais antigos.

Próximos passos

O artigo da AWS recomenda ativar o AgentCore Observability para agentes em produção como primeiro passo — essa configuração única fornece a base para todo o diagnóstico descrito. Em seguida, configurar alarmes no CloudWatch para métricas críticas, criar runbooks de troubleshooting documentando as consultas utilizadas, os limites que indicam problemas e as correções aplicadas.

A prática deliberada em ambientes não produtivos também é sugerida: introduzir falhas intencionalmente e praticar o diagnóstico usando os fluxos de trabalho apresentados, construindo familiaridade com as ferramentas antes de precisar delas em produção. Para mais informações, a documentação do AgentCore está disponível na documentação oficial do AgentCore e o Guia do Usuário do CloudWatch traz boas práticas adicionais de monitoramento.

Fonte

Optimizing production agents with Amazon Bedrock AgentCore Observability (https://aws.amazon.com/blogs/machine-learning/optimizing-production-agents-with-amazon-bedrock-agentcore-observability/)

O problema que a AWS decidiu resolver

Times de dados em grandes organizações já investiram muito em plataformas de catálogo — AWS Glue, Databricks Unity Catalog, Snowflake Horizon, Collibra, dbt. Nessas ferramentas, engenheiros e analistas definem descrições de tabelas, semântica de colunas, relacionamentos entre chaves primárias e estrangeiras, termos de glossário e métricas de negócio. É um trabalho cuidadoso, que leva tempo e exige alinhamento entre áreas.

O problema é que esse contexto rico raramente chega até o usuário final. Quando um gerente de vendas ou um diretor financeiro vai fazer uma pergunta em linguagem natural para uma ferramenta de análise com Linguagem Natural para SQL (Text2SQL), a resposta que recebe é tão boa quanto o contexto semântico disponível na camada de consumo — e esse contexto, na maioria das vezes, precisa ser recriado manualmente.

Três desafios se acumulam nesse cenário:

• Descoberta limitada: com milhares de tabelas em catálogos corporativos, encontrar os ativos certos para um relatório específico é como procurar uma agulha no palheiro. Não há como descrever o que você precisa e deixar o sistema encontrar.
• Fragmentação semântica: metadados ricos que já existem nos catálogos upstream — descrições de negócio, definições de colunas, relacionamentos — não fluem automaticamente. Curadoras precisam recriar tudo do zero, com risco real de inconsistência. “Receita” significa bruta ou líquida? “Cliente ativo” é quem comprou nos últimos 30 ou 90 dias? Essas definições existem upstream, mas exigem re-entrada manual.
• Tempo de entrega em semanas: a combinação de descoberta manual e recriação manual faz com que o caminho entre o dado e o insight demore semanas. E quando as definições upstream mudam, os metadados criados manualmente ficam desatualizados — gerando o que a AWS chama de “deriva semântica”, que corrói a confiança nas respostas da IA ao longo do tempo.

O problema, como a AWS aponta, não está no upstream. Os metadados existem. A governança está definida. Os relacionamentos estão mapeados. O gargalo é a última milha: traduzir esse contexto de catálogo em uma experiência consumível que entregue respostas de IA confiáveis e dashboards determinísticos para os usuários finais.

O que é a Agentic Catalog Experience

A AWS anunciou a Agentic Catalog Experience no Amazon Quick como um fluxo de trabalho com Inteligência Artificial (IA) que ajuda curadoras de dados a definir rapidamente seu escopo de contexto, herdar semântica dos catálogos upstream e habilitar usuários finais para perguntas e respostas fundamentadas em dados confiáveis.

No centro dessa experiência está o Quick Agent, um agente de IA com escopo definido para tarefas de descoberta, criação e herança dentro do contexto do catálogo. Ele usa o contexto semântico da conexão com o catálogo para:

• Resumir o catálogo completo de forma acessível;
• Conduzir uma conversa em linguagem natural com a curadora;
• Identificar as tabelas e relacionamentos mais relevantes para o caso de uso informado;
• Avaliar a prontidão dos metadados disponíveis.

Com uma única confirmação conversacional, o agente cria automaticamente Datasets e Tópicos gerados pelo catálogo, com metadados herdados do upstream — sem configuração manual, sem troca de contexto, sem semanas de setup.

Como o fluxo funciona na prática

Descoberta de ativos em linguagem natural

Em vez de navegar por milhares de tabelas, a curadora descreve o que precisa em linguagem natural. Por exemplo: “Sou analista sênior do time de Finanças. Preciso de tabelas para relatórios de receita trimestral e análise de custos.” O Quick Agent pesquisa em todo o catálogo e retorna as tabelas mais relevantes, considerando descrições de negócio, tags, classificações Gold/Silver/Bronze, scores de qualidade, scores de saúde das tabelas e termos de glossário.

Criação em massa de datasets pelo agente

Após a curadora selecionar as tabelas desejadas, o Quick Agent cria as representações de catálogo (Datasets) em escala, em um único fluxo guiado. O caminho padrão de criação é via Consulta Direta (DirectQuery), o que significa que o catálogo upstream permanece como fonte de verdade — nenhum dado é copiado ou movido. Os Datasets com semântica herdada recebem um indicador visual “Semantics Inherited” e seus metadados são somente leitura. As autoras podem sincronizar os metadados herdados sob demanda, usando o botão de sincronização.

Herança de semântica e relacionamentos

O Quick Agent carrega metadados específicos do catálogo para os ativos que cria. A herança hoje é deliberadamente focada em duas áreas:

• Definições de tabelas e colunas para Datasets: descrições de negócio e definições de colunas são herdadas diretamente, garantindo que curadoras e usuários finais tenham o contexto semântico necessário.
• Relacionamentos de chaves primárias e estrangeiras para Tópicos: o agente detecta os relacionamentos e os usa para sugerir e criar construções multi-dataset (Tópicos) com joins em esquema estrela e snowflake pré-configurados.

Vale destacar que todos os metadados disponíveis — classificações Gold/Silver, scores de qualidade, tags e scores de saúde — são utilizados durante a descoberta para encontrar as tabelas certas. Mas a herança para dentro dos Datasets é intencionalmente limitada a definições de tabelas e colunas por ora. A AWS indica que novos tipos de metadados serão adicionados aos Datasets ao longo do tempo.

Consumo imediato

Os Datasets e Tópicos criados ficam disponíveis para uso imediato: é possível iniciar uma conversa de Perguntas e Respostas (Q&A) com os novos Datasets, construir visualizações determinísticas com contexto semântico já configurado e compartilhar os Datasets com usuários de negócio para análise self-service. Após a criação, os metadados alimentam o Amazon Quick semantic store, que potencializa o re-ranking e o contexto unificado para Q&A com IA.

Princípio de design: consumidor, não catálogo

Um ponto importante da arquitetura é que o Amazon Quick é posicionado como consumidor de metadados de catálogos upstream — não como um catálogo dedicado. Isso tem implicações práticas:

• Sem duplicação de dados: Datasets gerados pelo catálogo usam DirectQuery. Nenhum dado é copiado ou movido.
• Metadados consumidos como contexto: a semântica herdada é somente leitura no Amazon Quick e alimenta o semantic store para re-ranking e fundamentação das respostas de IA. O catálogo upstream permanece como fonte autoritativa.
• Sincronização manual sob demanda: autoras podem atualizar os metadados herdados a qualquer momento. Sincronização automática agendada está no roadmap.
• Extensibilidade com transparência: Datasets gerados pelo catálogo exibem a semântica herdada como somente leitura. Se uma autora optar por editar um Dataset, o Amazon Quick exibe uma notificação clara informando que a edição cria um Dataset customizado e que a sincronização semântica deixa de se aplicar. Isso dá controle total às autoras enquanto preserva a integridade do catálogo por padrão.

Catálogos suportados atualmente

No momento do anúncio, a Agentic Catalog Experience suporta dois catálogos:

• AWS Glue Data Catalog: autenticação via Função de Gerenciamento de Identidade e Acesso da AWS (IAM Role ARN — Amazon Resource Name).
• Databricks Unity Catalog: autenticação via OAuth 2.0 ou Token de Acesso Pessoal (Personal Access Token).

Suporte para plataformas adicionais de catálogo está previsto para breve.

O que é herdado de cada catálogo

A herança de metadados é focada para manter os Datasets limpos e prontos para produção:

• Para Datasets (definições de tabelas e colunas): descrições técnicas e de negócio de tabelas; descrições e nomes de exibição de colunas; tipos de dados e nulabilidade; termos de glossário e sinônimos.
• Para Tópicos (relacionamentos): relacionamentos de chaves primárias e estrangeiras; definições de relacionamentos e cardinalidade; modelos de esquema estrela e snowflake.

Como fica a experiência para o usuário final

Para ilustrar o impacto prático, a AWS descreve o seguinte cenário: um gerente de vendas pergunta “Quais foram nossas vendas do quarto trimestre por região?”. Por trás dos panos, o agente de IA busca nos Datasets gerados pelo catálogo usando descrições de negócio e termos de glossário, identifica a tabela sales.revenue_by_product (classificação Gold, qualidade de 98%), aplica os joins pré-configurados do Tópico para combinar as dimensões relevantes e respeita as regras de mascaramento de Informações de Identificação Pessoal (PII — Personally Identifiable Information) provenientes dos metadados do catálogo. O resultado é uma resposta confiável e fundamentada em segundos.

A curadora definiu o contexto uma única vez com o Quick Agent — e todos os usuários finais se beneficiam imediatamente.

Contexto empresarial unificado

A Agentic Catalog Experience não opera de forma isolada. Combinada com as capacidades mais amplas do Amazon Quick — incluindo integração com Slack, Outlook, documentos e bases de conhecimento — os usuários finais recebem contexto empresarial completo:

• Dados estruturados dos catálogos via Datasets gerados pelo catálogo;
• Contexto não estruturado de documentos, e-mails e conversas;
• Regras de negócio de termos de glossário e definições de métricas.

Esse contexto unificado viabiliza respostas de IA prontas para produção, fundamentadas nos dados e na semântica específicos de cada organização.

Conectando ao AWS Glue Data Catalog: visão geral do fluxo

Para começar com a Agentic Catalog Experience via AWS Glue Data Catalog, a AWS orienta a criação de uma conexão de fonte de dados no Amazon Quick. Uma conexão com o Glue Data Catalog funciona em conjunto com uma conexão com o Amazon Athena: o Glue fornece os metadados (definições de tabelas, colunas e relacionamentos), enquanto o Athena fornece o caminho de consulta aos dados armazenados no Amazon Simple Storage Service (Amazon S3).

Após criar ambas as conexões, a curadora acessa a fonte de dados e escolhe “Explorar dados” para abrir o Quick Agent com escopo definido para aquela conexão específica. O agente resume os catálogos e bancos de dados disponíveis, identifica o schema (estrela, snowflake, etc.), detecta relacionamentos entre as tabelas e, com uma única confirmação, cria todos os Datasets e o Tópico com os joins pré-configurados. O Tópico fica imediatamente disponível para perguntas em linguagem natural.

O mesmo fluxo se aplica ao Databricks Unity Catalog: cria-se a fonte de dados, escolhe-se “Explorar dados”, o agente resume o catálogo e, com uma confirmação, cria Datasets e um Tópico com os joins do schema estrela já configurados. Usuários finais conseguem então responder perguntas complexas que cruzam múltiplas tabelas relacionadas.

O resultado em perspectiva

A proposta da Agentic Catalog Experience é clara: reduzir o tempo de configuração de semanas para minutos, eliminar a recriação manual de metadados que já existem nos catálogos upstream e garantir que as respostas de IA sejam fundamentadas em definições de negócio confiáveis — não em suposições.

Para times de dados brasileiros que já investiram em plataformas como AWS Glue ou Databricks Unity Catalog, essa integração representa uma mudança significativa no custo operacional de habilitar usuários de negócio para análise self-service com IA.

Fonte

Announcing the Agentic Catalog Experience in Amazon Quick (https://aws.amazon.com/blogs/machine-learning/announcing-the-agentic-catalog-experience-in-amazon-quick/)

Um novo marco em modelos de IA de código aberto

Modelos de IA com pesos abertos (open-weight) evoluíram a ponto de suportar tarefas complexas como fluxos de trabalho agênticos de múltiplas etapas, raciocínio avançado e programação de longa duração. Mas à medida que essas capacidades crescem, a infraestrutura necessária para hospedá-los também cresce — e chegamos a um ponto em que arquiteturas com trilhões de parâmetros exigem hardware de ponta, GPUs de alto desempenho e frameworks de serving otimizados.

Em 27 de julho de 2026, a Moonshot AI lançou o Kimi K3: um modelo com 2,8 trilhões de parâmetros baseado em arquitetura Mistura de Especialistas (MoE — Mixture of Experts) e que se tornou o primeiro modelo open-weight a atingir a classe dos 3 trilhões de parâmetros. O diferencial do Kimi K3 é entregar inteligência de nível frontier mantendo os pesos publicamente disponíveis — o que permite que organizações hospedem um dos modelos mais capazes do mundo em sua própria infraestrutura.

A AWS publicou um guia técnico detalhando como implantar o Kimi K3 utilizando duas abordagens: o Amazon SageMaker HyperPod e o Amazon Elastic Kubernetes Service (Amazon EKS).

O que é o Kimi K3

O Kimi K3 é construído sobre uma arquitetura diferenciada que combina três componentes principais: Kimi Delta Attention (KDA), Gated Multi Head Latent Attention (MLA) e o framework Stable LatentMoE. O modelo distribui seus 2,8 trilhões de parâmetros entre 896 especialistas, ativando apenas 16 por token — o que significa que aproximadamente 104 bilhões de parâmetros ficam ativos em cada passagem direta (forward pass). Esse design resulta em uma melhoria de 2,5x na eficiência de escalonamento em relação ao seu predecessor, o Kimi K2.

Confira as principais especificações técnicas do modelo:

• Total de Parâmetros: 2,8 trilhões
• Parâmetros Ativos por Token: 104 bilhões
• Arquitetura: Mistura de Especialistas (MoE)
• Quantidade de Especialistas: 896 (16 ativados por token)
• Janela de Contexto: 1 milhão de tokens
• Modalidade: Multimodal nativo (Texto + Visão)
• Data de Lançamento: 27 de julho de 2026

O modelo se destaca em tarefas de programação de longa duração, fluxos de trabalho agênticos e raciocínio complexo. Suporta nativamente chamadas de ferramentas (tool calling), saída estruturada e um modo de raciocínio sempre ativo para resolução de problemas em múltiplas etapas.

Disponibilidade e formato do modelo

Os pesos abertos do Kimi K3 estão disponíveis no Hugging Face sob o identificador moonshotai/Kimi-K3. Os pesos são distribuídos no formato MXFP4 (Microscaling Floating Point 4-bit), que oferece um equilíbrio eficiente entre qualidade do modelo e eficiência de memória para implantações de inferência em larga escala.

Dado o tamanho e a arquitetura do modelo, o serving do Kimi K3 requer um container de inferência vLLM day-0. No momento da publicação do guia original, os commits do vLLM para o Kimi K3 estavam disponíveis em vllm/vllm-openai:kimi-k3, com previsão de integração ao container principal do vLLM nas próximas versões. O vLLM oferece suporte nativo a arquiteturas MoE, paralelismo tensorial (tensor parallelism) e ao formato de quantização MXFP4, sendo o engine de serving recomendado para esse modelo.

Requisitos de infraestrutura

Implantar um modelo dessa escala exige GPU compute substancial. O Kimi K3 requer a instância p6-b300 (ml.p6-b300.48xlarge), que oferece 8 GPUs NVIDIA B300 Blackwell Ultra com interconexões de alta largura de banda — necessárias para inferência tensorial paralela eficiente em todo o pool de especialistas.

A AWS disponibiliza dois mecanismos principais para provisionar essa capacidade:

• Flexible Training Plans (para SageMaker HyperPod): Fornecem reservas de capacidade comprometida que podem ser alocadas ao seu cluster HyperPod, garantindo que os recursos de GPU estejam disponíveis para cargas de trabalho de inferência contínuas.
• Capacity Blocks: Permitem reservar instâncias EC2 GPU por um período definido, garantindo acesso à capacidade p6-b300 sem compromissos de longo prazo. As cargas de trabalho no Amazon EKS consomem essas reservas direcionando-se à capacidade reservada.

Opção 1: Implantando no Amazon SageMaker HyperPod

O Amazon SageMaker HyperPod com o Inference Operator oferece o caminho mais direto para implantar o Kimi K3. O Inference Operator é instalado automaticamente durante a criação do cluster e abstrai toda a complexidade de orquestração de containers, carregamento do modelo e gerenciamento de endpoints.

Pré-requisito 1: Criando o cluster SageMaker HyperPod com orquestração EKS

Antes de implantar o modelo, é necessário provisionar um cluster HyperPod. Os passos são:

• Acesse o console do Amazon SageMaker AI e selecione HyperPod Clusters > Cluster Management > Create HyperPod cluster.
• Escolha Orchestrated by Amazon EKS.
• Selecione Quick setup para provisionar com configurações padrão de rede, armazenamento e IAM, ou Custom setup para integrar com VPC, subnets e grupos de segurança existentes.
• Em Orchestration, crie um novo cluster EKS ou anexe um existente.
• Verifique se a opção Use default Helm charts and add-ons está selecionada para que o Inference Operator e outros operadores necessários sejam instalados automaticamente.
• Em Instance groups, adicione um grupo de workers configurado com o tipo de instância ml.p6-b300.48xlarge.
• Revise a configuração e clique em Submit para iniciar o provisionamento.

Para o guia completo, consulte a documentação Criando um cluster SageMaker HyperPod com orquestração Amazon EKS.

Pré-requisito 2: Provisionando capacidade com um Flexible Training Plan

O tipo de instância ml.p6-b300.48xlarge requer capacidade reservada. Um Flexible Training Plan (FTP) fornece uma reserva de capacidade comprometida para os nós com GPU Blackwell, garantindo que as instâncias p6-b300 estejam disponíveis ao seu cluster sem concorrência com o pool sob demanda geral.

• Acesse o console do SageMaker e selecione um bloco FTP com base no seu cronograma e quantidade de instâncias.
• Na configuração do grupo de instâncias, escolha Training plan como fonte de capacidade.
• Selecione um plano existente que cubra capacidade ml.p6-b300.48xlarge ou crie uma nova reserva especificando a quantidade de instâncias e a duração desejadas.
• Defina a Target Availability Zone para corresponder à zona onde a capacidade do seu training plan está alocada.

Quando o cluster atingir o estado Active com nós p6-b300 saudáveis, o ambiente estará pronto para implantar o modelo.

Implantando o modelo no HyperPod

Para implantar o Kimi K3 no HyperPod, aplique o seguinte manifesto InferenceEndpointConfig ao seu cluster. O YAML também está disponível no repositório GitHub:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: kimik3
spec:
  modelName: Kimi-K3
  instanceType: ml.p6-b300.48xlarge
  invocationEndpoint: v1/chat/completions
  replicas: 1
  modelSourceConfig:
    huggingFaceModel:
      modelId: moonshotai/Kimi-K3
      modelSourceType: huggingface
  worker:
    image: vllm/vllm-openai:kimi-k3
    modelInvocationPort:
      containerPort: 8000
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: 8
      requests:
        nvidia.com/gpu: 8
    args:
      - "--model"
      - "moonshotai/Kimi-K3"
      - "--trust-remote-code"
      - "--load-format"
      - "fastsafetensors"
      - "--enable-prefix-caching"
      - "--enable-auto-tool-choice"
      - "--tool-call-parser"
      - "kimi_k3"
      - "--reasoning-parser"
      - "kimi_k3"
      - "--served-model-name"
      - "Kimi-K3"
      - "--moe-backend"
      - "auto"
      - "--tensor-parallel-size"
      - "8"
      - "--no-enable-flashinfer-autotune"
    environmentVariables:
      - name: "VLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION"
        value: "1"

Aplique essa configuração com:

kubectl apply -f kimi-k3.yaml

O Inference Operator cuida do download do modelo a partir do Hugging Face, agendamento do container, verificações de saúde e prontidão do endpoint. Quando o endpoint atingir o estado de pronto, ele expõe uma API compatível com OpenAI no caminho de invocação configurado.

Opção 2: Implantando no Amazon EKS

Para equipes que preferem gerenciar sua própria infraestrutura Kubernetes, é possível implantar o Kimi K3 em um cluster Amazon EKS independente, provisionando a capacidade de GPU via EC2 Capacity Blocks — que permitem reservar instâncias p6-b300 por uma duração definida sem compromissos de longo prazo.

O projeto AI on EKS fornece uma receita de cluster pronta para inferência que automatiza o provisionamento de ponta a ponta. Em linhas gerais, a implantação envolve as seguintes etapas:

1. Provisionar o cluster EKS

Use os módulos Terraform fornecidos para criar um cluster EKS otimizado para GPU, incluindo rede VPC, node groups gerenciados e as funções e políticas IAM necessárias para cargas de trabalho com GPU.

2. Reservar capacidade de GPU com Capacity Blocks

Crie uma reserva de Capacity Block para instâncias p6-b300.48xlarge na sua Zona de Disponibilidade alvo. Os Capacity Blocks garantem que os nós GPU solicitados estarão disponíveis durante a janela de tempo reservada. Quando a reserva se tornar ativa, as instâncias ingressam no cluster EKS como nós workers.

3. Instalar drivers de GPU e o device plugin

A receita instala o NVIDIA device plugin e os drivers de GPU no node group, permitindo que o Kubernetes descubra e agende workloads nas GPUs disponíveis.

4. Implantar o servidor de inferência vLLM

Um Helm chart ou manifesto Kubernetes implanta o container vLLM com os argumentos específicos para o Kimi K3, incluindo tensor-parallel size de 8, o formato de carregamento MXFP4 e a configuração do backend MoE. O identificador do modelo aponta para o repositório do Hugging Face ou, alternativamente, é possível sincronizar os pesos do modelo para o Amazon Simple Storage Service (Amazon S3) para carregamento mais rápido. Os argumentos de serving espelham os mostrados na configuração do HyperPod acima.

5. Expor o endpoint de inferência

Um Kubernetes Service (tipo LoadBalancer ou via controller de Ingress) expõe o servidor vLLM na porta 8000, disponibilizando o endpoint /v1/chat/completions compatível com OpenAI para as aplicações.

6. Validar a implantação

Confirme a implantação enviando uma requisição de teste ao endpoint e verificando uma resposta bem-sucedida do modelo.

Para o guia completo de implantação, incluindo módulos Terraform, valores do Helm e instruções passo a passo, consulte a receita Kimi K3 no AI on EKS.

Invocando o endpoint

Após a implantação, o endpoint do Kimi K3 expõe uma API de chat completions compatível com OpenAI. É possível invocá-lo usando o SDK Python da OpenAI ou um simples comando curl.

Usando o SDK Python da OpenAI

from openai import OpenAI

client = OpenAI(
    base_url="http://:8000/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="Kimi-K3",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain the benefits of mixture of experts architectures."}
    ],
    temperature=0.7,
    max_tokens=1024
)

print(response.choices[0].message.content)

Usando curl

curl -X POST http://:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Kimi-K3",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Explain the benefits of mixture of experts architectures."}
    ],
    "temperature": 0.7,
    "max_tokens": 1024
  }'

Substitua <ENDPOINT_URL> pelo endpoint de serviço exposto pelo seu HyperPod Inference Operator ou pela configuração de ingress do EKS.

Limpeza dos recursos

Para evitar cobranças contínuas, é recomendável excluir os recursos criados durante a implantação quando não forem mais necessários.

Para implantações no SageMaker HyperPod:

• Exclua o InferenceEndpointConfig executando kubectl delete -f kimi-k3.yaml.
• No console do SageMaker AI, navegue até HyperPod Clusters, selecione seu cluster e escolha Delete.
• Libere ou cancele sua reserva de Flexible Training Plan, se não for mais necessária.

Para implantações no Amazon EKS:

• Exclua o deployment do vLLM e os Kubernetes Services associados.
• Encerre o node group de GPU ou exclua o cluster EKS usando Terraform (terraform destroy).
• Libere sua reserva de Capacity Block, se ainda não tiver expirado.

Para detalhes de preços sobre instâncias p6-b300 e reservas de Capacity Block, consulte a página de preços do Amazon EC2.

Links úteis

• Exemplo Kimi K3 no SageMaker HyperPod
• Receita Kimi K3 no AI on EKS
• Criando um Cluster SageMaker HyperPod (Documentação AWS)
• Kimi K3 no Hugging Face
• Documentação do vLLM

Conclusão

O Kimi K3 representa uma nova fronteira em capacidades de modelos open-weight, e a AWS disponibiliza a infraestrutura e os serviços gerenciados para implantá-lo em escala. Seja pela abordagem simplificada do HyperPod Inference Operator ou pela flexibilidade de um cluster EKS autogerenciado, a combinação de instâncias GPU p6-b300, serving com vLLM e pesos quantizados em MXFP4 entrega uma implantação com verificações de saúde integradas, recuperação automática e verificação de prontidão do endpoint para o maior modelo aberto do mundo.

Fonte

Deploying Kimi K3 on AWS (https://aws.amazon.com/blogs/machine-learning/deploying-kimi-k3-on-aws/)

O problema silencioso da degradação de modelos em produção

Desenvolver modelos de Aprendizado de Máquina (ML) é um processo caro e demorado. Equipes investem meses construindo pipelines de treinamento para alcançar alta acurácia em casos como detecção de fraudes, pontuação de crédito ou previsão de demanda. O problema? Depois que o modelo vai para produção, sua performance pode se degradar silenciosamente — e as equipes só percebem semanas depois, quando os clientes já reclamaram.

Analistas de fraude começam a ver falsos positivos disparando. Gerentes de crédito notam que aplicações que deveriam ser bloqueadas estão passando. Planejadores de estoque se deparam com excesso de inventário por causa de previsões superestimadas. A AWS publicou uma solução de meta-monitoramento de inferência para endereçar exatamente esse gap, fornecendo uma camada de governança que fica acima dos pipelines de inferência em produção e rastreia continuamente a qualidade das predições.

O que é meta-monitoramento de inferência?

A ideia central é criar um sistema que monitore os monitores — ou seja, que acompanhe de forma contínua as métricas de qualidade de dados e de modelo, visualize tendências e dispare alertas automáticos sempre que deriva de dados (data drift) ou deriva de modelo (model drift) for detectada. Isso transforma a resposta reativa a incidentes em governança proativa.

A solução apresentada pela AWS combina serviços gerenciados — Amazon SageMaker AI, Amazon Athena, AWS Lambda, Amazon EventBridge e Amazon Quick — com ferramentas open source como o SageMaker AI MLflow App e o Evidently AI.

Arquitetura da solução

O sistema é estruturado em torno de uma tabela central Athena Iceberg, que unifica os pipelines de treinamento, inferência e monitoramento. A configuração completa pode ser provisionada via um template CloudFormation disponível no repositório, que cria a Nuvem Privada Virtual (VPC), sub-redes, domínio SageMaker AI, perfil de usuário e espaço JupyterLab automaticamente.

A arquitetura usa cinco tabelas Athena Iceberg como lago de dados central:

• training_data: armazena 80% dos dados usados no treinamento do modelo.
• evaluation_data: os 20% restantes, usados como baseline de monitoramento de deriva — não os dados de treinamento, porque essa fatia congelada é contra a qual as métricas de cada modelo registrado são medidas.
• inference_responses: captura cada predição com suas features, scores de confiança e timestamps.
• ground_truth_updates: armazena confirmações assíncronas de rótulos que são mescladas de volta aos registros de inferência.
• monitoring_responses: armazena as saídas dos cálculos de deriva, incluindo o ARN do pacote de modelo e o ID do snapshot Iceberg.

Os quatro notebooks da solução

1. Pipeline de treinamento

O notebook 1_training_pipeline.ipynb configura o treinamento de ponta a ponta usando o dataset de fraude em cartão de crédito do Kaggle. O pipeline faz a ingestão dos dados do Amazon S3, aplica uma divisão determinística por hash no campo transaction_id para garantir que as partições de treino e avaliação sejam estáveis entre execuções, e registra métricas e artefatos no SageMaker AI MLflow App. É possível substituir os dados pelo seu próprio dataset seguindo as instruções de Bring your own dataset.

2. Implantação do modelo

O notebook 2_deployment.ipynb implanta um handler customizado em um endpoint de inferência do SageMaker AI. O handler escreve todas as inferências no Amazon Simple Queue Service (SQS), que são processadas por uma função Lambda de logging. Essa função agrupa até 10 predições — ou o que chegar em 30 segundos — e persiste os registros nas tabelas Athena Iceberg.

3. Monitoramento de inferência

O notebook 3_inference_monitoring.ipynb simula o fluxo de inferência com dados derivados para fins de teste. Em ambiente de produção, esse passo seria substituído pelas aplicações de negócio que enviam requisições ao endpoint. O ground truth — ou seja, a confirmação se uma predição estava correta — também é simulado aqui, introduzindo 15% de imprecisão para induzir deriva de modelo. Em produção, esse ground truth viria de processos reais, como investigações de fraude ou confirmações de chargeback.

Após ter dados suficientes, a Lambda de deriva entra em ação com dois checks independentes:

• Deriva de dados: compara a distribuição das features de inferência recentes com a fatia de treinamento congelada (referenciada pelo training_snapshot_id no baseline.json). Usa o preset DataDriftPreset do Evidently AI com distância Jensen-Shannon — que varia de 0 a 1 e é uniforme para features numéricas e categóricas — com threshold fixo de 0,1.
• Deriva de modelo: compara predições recentes com ground truth confirmado versus a fatia de avaliação congelada (evaluation_snapshot_id), rastreando ROC-AUC, precisão, recall e F1 via ClassificationPreset do Evidently.

A solução introduz um campo normalizado chamado drift_magnitude — calculado como score / threshold — para que features possam ser comparadas independentemente do teste estatístico utilizado. O valor 1,0 significa “no limiar”, acima de 1,0 significa “derivado”, e quanto maior, mais severo. Isso resolve um problema clássico: p-valores e distâncias têm direções opostas (p-valor menor = mais deriva; distância maior = mais deriva), o que tornaria a comparação direta impossível. Para mais detalhes sobre como interpretar os números, consulte a história completa da deriva no repositório.

Cada modelo registrado carrega um artefato baseline.json congelado que registra as métricas obtidas em evaluation_data, o ID do snapshot Iceberg daquela fatia exata e o SHA do commit de código que o produziu. A Lambda de deriva usa esses ponteiros a cada execução, garantindo que o sistema sempre compare produção contra a versão precisa dos dados e do código do modelo implantado. As tabelas Apache Iceberg garantem que as atualizações sejam compatíveis com ACID.

Se precisar de janelas de deriva mais curtas (minutos em vez de dias), o repositório documenta como configurar isso em Configuring Shorter Drift Windows.

4. Dashboard de governança

O notebook 4_governance_dashboard.ipynb cria uma análise pré-construída no Amazon Quick com 3 abas e 32 visuais que consultam a tabela monitoring_responses no Athena:

• Model Drift Trends (11 visuais): degradação de ROC-AUC, métricas de classificação e contagem de execuções por versão de modelo e snapshot de treinamento.
• Data Drift Trends (10 visuais): proporção de colunas derivadas ao longo do tempo, taxa de detecção de deriva e correlação com volume de inferência.
• Feature Drift Trends (11 visuais): ranking de features por drift_magnitude, heatmaps de feature × tempo e feature × versão de modelo, e gráfico de “reincidentes”.

A codificação de severidade por cores usa bandas categóricas calculadas a partir do drift_magnitude: Baixo (<1,0), Moderado (≥1,0) e Significativo (≥3,0). Isso significa que uma célula vermelha tem o mesmo significado independentemente de qual teste estatístico a produziu.

O Amazon Quick também suporta criação de visuais por linguagem natural. É possível, por exemplo, pedir um gráfico de série temporal das 5 features mais derivadas nos últimos 30 dias, com linha de referência no magnitude = 1,0, ou um diagrama Sankey mostrando como as distribuições de predição mudaram da semana de baseline para a semana atual.

Dois backends de monitoramento independentes

A solução oferece dois backends de visualização que consomem as mesmas tabelas Athena — MLflow e Amazon Quick — como consumidores paralelos, não como uma pilha dependente. Desabilitar um não afeta o outro.

• Amazon Quick: ideal para endpoints online com tráfego contínuo. Dashboards atualizados por schedule, fatiados por versão de modelo, endpoint, snapshot ou feature. Adequado para comitês de risco de modelo e revisões executivas.
• MLflow: ideal para inferência em batch ou jobs discretos. Rastreamento de experimentos por execução, comparação de hiperparâmetros e hospedagem dos relatórios HTML interativos do Evidently como artefatos.

O MLflow responde “o que mudou entre essa execução e a última?”, enquanto o Quick responde “como ficaram os últimos 90 dias de deriva em todas as versões de modelo e endpoints?”.

Custos e otimizações

Toda a computação escala para zero quando ociosa: endpoints serverless cobram apenas por invocações reais, Lambdas executam sob demanda, queries Athena rodam só quando disparadas, e o EventBridge não tem custo entre execuções agendadas.

O particionamento das tabelas Iceberg reduz os custos de scan do Athena em 10 a 100 vezes. O batching da Lambda (100 registros por invocação) minimiza os custos de execução, e o auto scaling do endpoint serverless elimina o desperdício de provisionamento.

A solução completa — incluindo SageMaker AI MLflow Apps, SageMaker Serverless Inference, Lambda, EventBridge, Athena, S3, SQS, SNS e Quick — custa aproximadamente US$ 60 por mês, dependendo do tipo de instância e dos padrões de uso. Implantações de alto volume escalam linearmente, sem planejamento de capacidade antecipado ou instâncias reservadas. Consulte sempre a página de preços do SageMaker AI para valores atualizados.

Importante: a solução cria recursos AWS cobráveis. As cobranças acumulam até que os recursos sejam removidos. Use o notebook 6_optional_cleanup.ipynb para garantir que tudo seja deletado quando não for mais necessário.

Próximos passos

Para começar, clone o repositório de boas práticas de MLOps no GitHub. A partir daí, é possível estender a solução para casos como:

• Monitoramento multi-modelo: rastrear múltiplos endpoints a partir de uma única infraestrutura de monitoramento, comparando padrões de deriva entre modelos.
• Gatilhos de retreinamento automatizado: conectar alertas de deriva a um SageMaker Pipeline que inicia retreinamento automaticamente quando a deriva excede um threshold sustentado.
• Métricas de deriva customizadas: adicionar testes específicos do domínio além dos defaults do Evidently, como KPIs de negócio (taxa de aprovação, impacto financeiro de falsos positivos, métricas de estabilidade populacional em segmentos críticos).

Fonte

Inference meta-monitoring for Amazon SageMaker AI endpoints with Amazon Quick (https://aws.amazon.com/blogs/machine-learning/inference-meta-monitoring-for-amazon-sagemaker-ai-endpoints-with-amazon-quick/)

O problema que todo time de IA generativa conhece bem

Você finalmente tem uma aplicação de IA generativa funcionando em produção. Os prompts estão ajustados, as respostas são consistentes e os usuários estão satisfeitos. Então aparece um modelo novo no Amazon Bedrock — mais rápido, mais barato, mais capaz — e você precisa decidir se vai migrar.

Na teoria, a decisão deveria ser simples. Na prática, equipes gastam dias ou semanas reescrevendo prompts, rodando testes e comparando resultados manualmente. Multiplique esse esforço por cada template de prompt em produção e por cada modelo candidato a avaliar, e você tem um problema que cresce proporcionalmente à ambição do projeto.

É exatamente esse gargalo que a AWS endereça com o lançamento do Advanced Prompt Optimization no Amazon Bedrock: uma ferramenta que otimiza prompts para até 5 modelos simultaneamente, comparando desempenho original e otimizado em um único job.

Por que esse problema trava o ciclo de desenvolvimento

A migração e a otimização de prompts afetam quatro pontos críticos no ciclo de vida de aplicações de IA generativa:

• Dependência excessiva de modelo: times evitam migrar porque o custo de reajuste é alto demais, mesmo quando um modelo mais novo reduziria latência e custo de inferência.
• Desempenho abaixo do potencial: prompts escritos para um modelo raramente aproveitam as capacidades plenas de outro.
• Cegueira para regressões: sem avaliação sistemática contra resultados esperados, é impossível distinguir “diferente” de “pior”. Times colocam saídas degradadas em produção sem perceber.
• Ciclos de iteração lentos: cada mudança de prompt exige testes manuais de A/B, mantendo engenheiros em loops de avaliação em vez de construindo funcionalidades.

Como o Advanced Prompt Optimization funciona

O Amazon Bedrock Advanced Prompt Optimization opera de trás para frente a partir da sua métrica de avaliação. Em vez de reescrever prompts de forma heurística, o sistema funciona em um loop de feedback no estilo de aprendizado por reforço — sem alterar os pesos do modelo:

• Você fornece um template de prompt, exemplos de entradas (texto ou multimodal), respostas esperadas opcionais e uma métrica de avaliação.
• O otimizador envia o template e as entradas para os modelos de inferência escolhidos.
• Ele avalia as respostas contra a métrica e reescreve o prompt.
• O loop se repete (avaliar, reescrever, avaliar) até otimizar iterativamente o prompt.

A saída inclui os prompts original e otimizado. Para cada um, você recebe pontuações de avaliação, tempo até o primeiro token (TTFT — Time to First Token) por amostra e estimativas de custo de inferência com preços sob demanda. A arquitetura é agnóstica de modelo: um único job pode ter como alvo até 5 modelos ao mesmo tempo, entregando uma comparação direta de qualidade, latência e custo.

O que é TTFT?

TTFT (Time to First Token — Tempo até o Primeiro Token) mede a velocidade com que o modelo começa a responder: o tempo entre o envio da requisição e o recebimento do primeiro token. É um indicador útil de latência percebida, como um chatbot que começa a digitar. Como o TTFT reflete condições reais de infraestrutura em tempo real, leia valores de execução única como um sinal direcional — e combine com contagens de tokens de saída para ter o panorama completo de latência.

Dois casos de uso, três modos de avaliação

O Advanced Prompt Optimization pode ser usado de duas formas:

• Migração de modelo: selecione seu modelo atual como baseline e até 4 candidatos. Você recebe prompts otimizados para cada um e uma comparação lado a lado.
• Melhoria no mesmo modelo: selecione apenas seu modelo atual. Você obtém um prompt melhor sem mudar nada mais.

Para cada template de prompt, você escolhe um dos três métodos de avaliação:

• Função AWS Lambda: ideal para métricas concretas (acurácia, F1, ROUGE, correspondência de JSON etc.). Você fornece uma função Lambda com lógica de pontuação compute_score.
• LLM-as-a-Judge (LLM como Juiz): indicado para tarefas abertas (sumarização, raciocínio, geração). Você fornece um prompt de rubrica e escolhe o modelo juiz.
• Critérios de direcionamento (Steering Criteria): para voz de marca, formato e restrições de segurança. Você define até 5 critérios em linguagem natural.

Se você omitir todos os campos de avaliação, o sistema usa um padrão embutido que combina acurácia, completude da resposta e pontuação de estilo de escrita. A AWS recomenda definir sua própria métrica para melhores resultados. Se você tiver mais de um objetivo, pode criar uma métrica composta com pesos para cada critério — mas a saída da métrica deve ser um único número.

Suporte multimodal

O Advanced Prompt Optimization suporta entradas multimodais: arquivos PNG, JPG, JPEG, GIF, WebP e PDF referenciados via URIs do Amazon S3 (Simple Storage Service). Isso permite otimizar prompts para análise de documentos, classificação de imagens, resposta visual a perguntas e outras tarefas que combinam texto com entrada visual.

Preparando o dataset de entrada (formato JSONL)

O arquivo de entrada usa formato JSONL (JSON Lines), com um objeto JSON por linha — cada linha é um template de prompt a otimizar. Para detalhes completos, consulte a documentação técnica. O schema principal é:

{
  "version": "bedrock-2026-05-14",
  "templateId": "unique-id-for-this-template",
  "promptTemplate": "Your prompt with {{variableName}} placeholders",
  "evaluationSamples": [
    {
      "inputVariables": [
        {"variableName": "value"}
      ],
      "referenceResponse": "Expected output (optional but recommended)"
    }
  ]
}

Em seguida, adicione um dos campos de método de avaliação. Para mais detalhes, consulte a documentação técnica de avaliação. Abaixo, o snippet para a opção de métrica via AWS Lambda:

{
  "evaluationMetricLambdaArn": "arn:aws:lambda:us-west-2:111122223333:function:my-metric",
  "customEvaluationMetricLabel": "my_score_name"
}

Para a opção LLM-as-a-Judge:

{
  "customLLMJConfig": {
    "customLLMJPrompt": "Your rubric. Use {{prompt}}, {{response}}, {{referenceResponse}} as placeholders.",
    "customLLMJModelId": "us.anthropic.claude-opus-4-6-v1"
  },
  "customEvaluationMetricLabel": "my_judge_metric"
}

No customLLMJPrompt, referencie 3 placeholders com chaves duplas: {{prompt}} (o prompt completamente renderizado), {{response}} (a saída do modelo) e {{referenceResponse}} (a resposta esperada). O Advanced Prompt Optimization substitui esses valores para cada candidato e amostra antes de enviar a rubrica ao modelo juiz. Para detalhes, veja como usar um LLM como juiz.

Para a opção de critérios de direcionamento:

{
  "steeringCriteria": [
    "be concise",
    "use professional tone",
    "avoid speculation"
  ]
}

Criando e acompanhando um job via API (boto3)

É possível conduzir todo o fluxo com boto3. O código abaixo cria um job com dois modelos candidatos:

import boto3

bedrock = boto3.client("bedrock", region_name="us-west-2")

response = bedrock.create_advanced_prompt_optimization_job(
    jobName="my-migration-job",
    modelConfigurations=[
        {"modelId": "us.amazon.nova-2-lite-v1:0"},          # candidate 1
        {"modelId": "us.anthropic.claude-haiku-4-5-20251001-v1:0"},  # candidate 2
    ],
    inputConfig={
        "s3Uri": "s3://amzn-s3-demo-bucket/inputs/prompts.jsonl"
    },
    outputConfig={
        "s3Uri": "s3://amzn-s3-demo-bucket/outputs/migration-job/"
    },
)

job_arn = response["jobArn"]
print(f"Job submitted: {job_arn}")

Um job roda de forma assíncrona. Para verificar o status a cada 60 segundos:

import time

while True:
    info = bedrock.get_advanced_prompt_optimization_job(jobIdentifier=job_arn)
    status = info["jobStatus"]
    print(f"Status: {status}")
    if status in ("Completed", "Failed", "Stopped"):
        break
    time.sleep(60)

Quando o job é concluído, ele escreve automaticamente um arquivo de resultados JSONL no local de saída do S3 definido na criação. Para baixá-lo:

# Results land at: s3://output-uri/job-id/advanced_prompt_optimization_results.jsonl
s3 = boto3.client("s3")
job_id = job_arn.rsplit("/", 1)[-1]
result_key = f"outputs/migration-job/{job_id}/advanced_prompt_optimization_results.jsonl"
s3.download_file("amzn-s3-demo-bucket", result_key, "results.jsonl")

Resultados reais: o que esperar de ganhos

A AWS divulgou resultados de 4 jobs reais rodados na região US East (N. Virginia), cada um com 5 amostras de avaliação. Os números são ilustrativos do tipo de ganho que o otimizador entrega — não constituem um benchmark formal. É possível reproduzi-los com os datasets do repositório de tutoriais no GitHub.

• XSum (sumarização) — Steering, Claude Haiku 4.5: Quality Score de 0,550 para 0,743 (+35%). Os critérios de direcionamento produziram respostas mais curtas, reduzindo tokens de saída de 51 para 28. O prompt otimizado cresceu de 720 para 1.601 tokens de entrada.
• NESTFUL (chamada de função) — Lambda, Nova 2 Lite: acurácia de 0,267 para 0,647 (+143%). O prompt cresceu de ~1,3K para ~3,8K tokens de entrada ao adicionar regras explícitas de decomposição e exemplos.
• MM-VQA (resposta visual a documentos) — Lambda, Claude Haiku 4.5: ROUGE-L de 0,339 para 0,777 (+129%), com crescimento de apenas ~7% nos tokens de entrada (30.998 para 33.057). O otimizador afiou o prompt em vez de alongá-lo.
• IFBench (seguimento de instruções) — LLM-as-a-Judge, Kimi K2.5: aderência a restrições de 0,413 para 0,890 (+115%). O caso mais intensivo em tokens, com crescimento expressivo para detalhar as restrições que o modelo deve satisfazer.

Entendendo os trade-offs de custo e latência

Prompts otimizados não mudam apenas a qualidade — eles mudam o que você paga e o tempo de esposta. O Bedrock cobra por token de entrada e de saída, sendo os tokens de saída geralmente mais caros. O padrão observado nos 4 runs é consistente: otimização entregou grandes ganhos de qualidade, e todo prompt otimizado usou mais tokens no total.

O aumento variou de ~7% a mais (MM-VQA) até várias vezes mais (IFBench). Quando a saída encolhe — como em XSum e MM-VQA — isso suaviza o aumento total de custo. O otimizador entrega as contagens exatas de tokens e pontuações, permitindo calcular o custo real para o seu volume de tráfego e escolher o trade-off adequado para cada workload.

Vale destacar: você pode moldar a saída diretamente adicionando um objetivo nos critérios de avaliação que recompense respostas mais curtas. O otimizador então favorecerá prompts que as produzam.

Limites e boas práticas

Antes de rodar um job, é útil conhecer os limites por job:

• Templates por job: 10
• Amostras de avaliação por template: 100
• Modelos por job: 5
• Variáveis de texto por template: 20
• Arquivos multimodais por amostra: 100
• Critérios de direcionamento por template: 5

Algumas práticas importantes:

• Escolha um único método de avaliação por template — combinar steeringCriteria com customLLMJConfig ou evaluationMetricLambdaArn não é suportado.
• Use chaves duplas ({{variavel}}) nos templates, não chaves simples.
• Dê a cada variável em inputVariables seu próprio objeto.
• Misture exemplos fáceis e difíceis no dataset. Um conjunto só com exemplos fáceis não desafia o otimizador; um conjunto só com difíceis não deixa nada para ele aprender.
• Para LLM-as-a-Judge, há atualmente 3 modelos juiz disponíveis: anthropic.claude-opus-4-6-v1, anthropic.claude-sonnet-4-5-20250929-v1:0 e anthropic.claude-sonnet-4-6. Consulte as regiões, modelos e cotas suportados para disponibilidade por região.

Recursos para aprofundamento

• Como o Advanced Prompt Optimization funciona
• Referência de API: CreateAdvancedPromptOptimizationJob
• GitHub: notebooks de tutorial para os três modos de avaliação
• Documentação: como preparar seu dataset de entrada

Fonte

Migrate your prompts to new models and optimize them on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/migrate-your-prompts-to-new-models-and-optimize-them-on-amazon-bedrock/)

GPT-5.6 no Amazon Bedrock: três modelos, uma novidade importante

A AWS anunciou que os modelos OpenAI GPT-5.6 Sol, Terra e Luna estão agora disponíveis no Amazon Bedrock. A família cobre três níveis de capacidade:

• GPT-5.6 Sol: para raciocínio complexo e trabalhos de codificação agêntica
• GPT-5.6 Terra: para cargas de trabalho de produção do dia a dia
• GPT-5.6 Luna: para tarefas rápidas e de alto volume, como classificação e sumarização

Junto com os novos modelos, o GPT-5.6 introduz o cache explícito de prompts no Amazon Bedrock — um recurso que permite controlar com precisão quais partes do prompt são armazenadas em cache e reutilizadas entre requisições. Tokens lidos do cache são cobrados com 90% de desconto (confira a página de preços do Amazon Bedrock) e ficam disponíveis por 30 minutos. O ganho é maior em fluxos de trabalho agênticos, onde instruções de sistema, definições de ferramentas e documentos de referência se repetem em muitas chamadas.

Como começar com o GPT-5.6 no Amazon Bedrock

Os modelos GPT-5.6 são servidos pela Responses API compatível com OpenAI, no endpoint bedrock-mantle. A autenticação recomendada usa tokens de curta duração gerados a partir das credenciais AWS:

pip install openai aws-bedrock-token-generator

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-2"
client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",
    api_key=provide_token(region=REGION),  # short-term token from your AWS credentials
)

Uma requisição básica com a Responses API fica assim:

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions="You are a concise technical assistant.",
    input="What is Amazon Bedrock?",
    max_output_tokens=500,
)
print(response.output_text)

Os três identificadores de modelo são openai.gpt-5.6-sol, openai.gpt-5.6-terra e openai.gpt-5.6-luna. O GPT-5.6 Sol está disponível em US East (N. Virginia) e US East (Ohio). Terra e Luna também estão disponíveis em US West (Oregon). Consulte a disponibilidade completa por região em Modelos suportados por região AWS no Amazon Bedrock.

Controlando o nível de raciocínio

O GPT-5.6 suporta níveis de esforço de raciocínio: none, low, medium, high e xhigh, sendo medium o padrão. Níveis mais altos dedicam mais raciocínio a problemas complexos; none oferece menor latência para tarefas diretas:

response = client.responses.create(
    model="openai.gpt-5.6-luna",
    input="Classify this ticket as bug, feature request, or question: 'App crashes on login.'",
    reasoning={"effort": "none"},
)

Uma dica prática ao migrar do GPT-5.5 ou GPT-5.4: comece com o nível de esforço atual e teste um nível abaixo. O GPT-5.6 é mais eficiente em tokens, e muitas cargas de trabalho mantêm a qualidade com configuração menor.

Cache de prompts: implícito e explícito

O cache de prompts permite que o Amazon Bedrock evite reprocessar partes do prompt que se repetem entre requisições. No GPT-5.6, leituras do cache são cobradas com 90% de desconto em relação aos tokens de entrada sem cache, enquanto escritas no cache custam 1,25 vezes a taxa normal. O modelo é projetado para o padrão escreve uma vez, lê muitas vezes. Para taxas atuais, consulte a página de preços do Amazon Bedrock.

O GPT-5.6 suporta dois modos de cache:

• Implícito (padrão): o Amazon Bedrock posiciona automaticamente o ponto de cache e tenta maximizar a taxa de acerto. Funciona sem nenhuma mudança no código existente.
• Explícito: você marca o limite do cache com precisão, controlando exatamente onde o prefixo reutilizável termina.

Cache implícito

No modo implícito, o cache já está ativo por padrão. Um prefixo estável de pelo menos 1.024 tokens pode ser armazenado e reutilizado sem nenhuma mudança no código:

# Implicit caching: no caching parameters needed
response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions=SYSTEM_INSTRUCTIONS,  # stable prefix, >= 1,024 tokens
    input=user_question,
)
details = response.usage.input_tokens_details
print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

Cache explícito

O modo explícito oferece controle direto sobre o limite do cache. Prefixos em cache ficam disponíveis por pelo menos 30 minutos. Três parâmetros controlam o comportamento:

• prompt_cache_breakpoint: marca o fim exato do prefixo reutilizável em um bloco de conteúdo
• prompt_cache_key: identificador estável que direciona requisições ao mesmo cache
• prompt_cache_options: controla o modo (implícito ou explícito) e o TTL

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    prompt_cache_key="support-app:kb-v1",  # same key across all requests
    input=[
        {
            "type": "message",
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": SYSTEM_INSTRUCTIONS,  # long, static: guidelines, KB excerpts (>= 1,024 tokens)
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{
                "type": "input_text",
                "text": user_question,  # changes on every request
            }],
        },
    ],
    extra_body={"prompt_cache_options": {"mode": "explicit"}},
)

Verificando o comportamento do cache

Cada resposta reporta exatamente o que o cache fez, no objeto usage.input_tokens_details:

• cached_tokens: tokens lidos do cache, cobrados com 90% de desconto
• cache_write_tokens: tokens escritos no cache, cobrados a 1,25x a taxa normal

details = response.usage.input_tokens_details
print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

A tabela abaixo ilustra o padrão esperado ao reutilizar um prefixo de 3.626 tokens com a mesma prompt_cache_key:

Requisição	input_tokens	cached_tokens	cache_write_tokens	Entrada nova
Primeira (fria)	3.682	0	3.626	56
Segunda	3.671	3.626	0	45
Terceira	3.662	3.626	0	36

A primeira requisição escreve o prefixo no cache. A partir da segunda, o prefixo é lido com desconto enquanto apenas a nova entrada do usuário é processada à taxa normal. Para monitoramento agregado, o endpoint bedrock-mantle publica métricas de inferência e tokens no Amazon CloudWatch sob o namespace AWS/BedrockMantle (veja Monitoramento de inferência do bedrock-mantle com métricas do CloudWatch).

Cache em um loop agêntico

Fluxos de trabalho agênticos são onde o cache explícito brilha. Em um loop de chamadas de ferramentas, o prompt de sistema e as definições de ferramentas se repetem a cada turno enquanto a conversa cresce no final — encaixe perfeito para um breakpoint após o conteúdo estático. O exemplo abaixo constrói um assistente de resposta a incidentes:

import json

SYSTEM_PROMPT = "..."  # long runbook and instructions (>= 1,024 tokens)
MAX_TURNS = 10
TOOLS = [
    {"type": "function", "name": "get_service_health", "description": "Get health status for a microservice", "parameters": {"type": "object", "properties": {"service": {"type": "string"}}, "required": ["service"]}},
    {"type": "function", "name": "get_recent_deploys", "description": "List deployments in the last N hours", "parameters": {"type": "object", "properties": {"hours": {"type": "integer"}}, "required": ["hours"]}},
]

conversation = [
    {"type": "message", "role": "developer", "content": [{"type": "input_text", "text": SYSTEM_PROMPT, "prompt_cache_breakpoint": {"mode": "explicit"}}]},
    {"type": "message", "role": "user", "content": [{"type": "input_text", "text": "Is checkout-service healthy? If not, was there a recent deploy?"}]},
]

for turn in range(MAX_TURNS):
    response = client.responses.create(
        model="openai.gpt-5.6-sol",
        prompt_cache_key="incident-agent:session-42",
        input=conversation,
        tools=TOOLS,
        extra_body={"prompt_cache_options": {"mode": "explicit", "ttl": "30m"}},
    )
    tool_calls = [o for o in response.output if o.type == "function_call"]
    if not tool_calls:
        print(response.output_text)
        break
    for call in tool_calls:
        # execute_tool is your implementation: call the real system
        # and return a JSON-serializable result
        result = execute_tool(call.name, json.loads(call.arguments))
        conversation.append({"type": "function_call", "call_id": call.call_id, "name": call.name, "arguments": call.arguments})
        conversation.append({"type": "function_call_output", "call_id": call.call_id, "output": json.dumps(result)})

O primeiro turno escreve o prefixo do prompt de sistema no cache. Cada turno seguinte lê esse prefixo com desconto enquanto processa apenas as novas chamadas de ferramentas e resultados. O TTL de 30 minutos cobre confortavelmente sessões de agente com vários minutos de duração.

Quando usar cada modo

A tabela abaixo resume a recomendação de modo conforme o tipo de carga de trabalho:

• Prompts que se repetem exatamente (análise de documentos em lote, scoring com prompt fixo): implícito funciona sem mudanças; explícito oferece o mesmo resultado com controle determinístico
• Prefixo estável + sufixo variável (assistentes de chat, RAG, loops agênticos): explícito, com um breakpoint após o conteúdo estático
• Múltiplas seções com frequências de mudança diferentes (ferramentas, prompt de sistema, documentos longos, conversa): explícito, com até 4 breakpoints para controle granular

Se não quiser usar cache de prompts no GPT-5.6+, é possível usar o modo explícito sem fornecer breakpoints explícitos. Isso desativa o comportamento de cobrança do cache, mas partes dos prompts ainda podem ser armazenadas nos sistemas do Bedrock para oferecer menor latência.

Migrando para o GPT-5.6

Ponto de partida 1: GPT-5.5 ou GPT-5.4 no Amazon Bedrock

A migração é uma simples troca de ID de modelo. O endpoint, a autenticação e o formato da Responses API permanecem idênticos. Ao trocar o ID do modelo, adicione um breakpoint explícito após o conteúdo estático e revise o nível de esforço de raciocínio — muitas cargas de trabalho mantêm a qualidade com um nível abaixo do atual.

Ponto de partida 2: Responses API em outra plataforma

São necessárias três mudanças: a URL base, a autenticação e o ID do modelo. O código de tratamento de requisições e respostas permanece igual:

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-2"
client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",  # 1. endpoint
    api_key=provide_token(region=REGION),                            # 2. auth
)
response = client.responses.create(
    model="openai.gpt-5.6-terra",                                    # 3. model ID
    instructions=SYSTEM_PROMPT,
    input=user_input,
)

Ponto de partida 3: Chat Completions API em outra plataforma

O GPT-5.6 no Amazon Bedrock usa a Responses API, então cargas de trabalho escritas contra a Chat Completions API precisam portar o tratamento de requisições e respostas. O mapeamento é direto:

• messages=[{role, content}] → instructions="..." (sistema) + input="..."
• max_completion_tokens → max_output_tokens
• response.choices[0].message.content → response.output_text
• tools=[{"type": "function", "function": {...}}] → tools=[{"type": "function", "name": ..., ...}] (formato flat)
• response.usage.prompt_tokens / completion_tokens → response.usage.input_tokens / output_tokens

# Before: Chat Completions on another platform
response = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "What is Amazon Bedrock?"},
    ],
    max_completion_tokens=200,
)
print(response.choices[0].message.content)

# After: Responses API on Amazon Bedrock
response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions="You are a concise assistant.",
    input="What is Amazon Bedrock?",
    max_output_tokens=200,
)
print(response.output_text)

Validação e rollout gradual

Independente do ponto de partida, a AWS recomenda tratar a migração como um projeto de engenharia estruturado: inventariar os modelos e APIs em uso, construir um conjunto de prompts representativos para comparação, estabelecer uma baseline de cache monitorando cached_tokens e cache_write_tokens, e aumentar o tráfego gradualmente mantendo a configuração anterior disponível para rollback.

Conclusão

O GPT-5.6 Sol, Terra e Luna trazem os modelos de fronteira mais recentes da OpenAI para o Amazon Bedrock. Com o cache explícito de prompts, equipes que operam agentes e fluxos de LLM com contexto repetido — instruções, ferramentas, documentos de referência — podem converter esse contexto de entrada com preço cheio em leituras de cache com desconto. O que é necessário: um breakpoint após o conteúdo estático, uma chave de cache consistente e dois campos de uso para monitorar.

Para saber mais, consulte o anúncio de lançamento do GPT-5.6 e a documentação de cache de prompts do Amazon Bedrock. Para detalhes de preços, acesse a página de preços do Amazon Bedrock. Para monitorar cargas de trabalho em produção, veja Monitoramento de inferência do bedrock-mantle com métricas do CloudWatch. Experimente o GPT-5.6 com seus próprios prompts no console do Amazon Bedrock e compartilhe seu feedback no AWS re:Post para Amazon Bedrock.

Fonte

Introducing explicit prompt caching for OpenAI GPT-5.6 models on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock/)