Blog

A maior revisão do MCP desde o lançamento

O Protocolo de Contexto de Modelo (MCP, na sigla em inglês) publicou sua especificação 2026-07-28 — a revisão mais abrangente e significativa desde o lançamento do protocolo. Com essa versão, o MCP passa a ser um protocolo sem estado (stateless), capaz de escalar em infraestruturas HTTP convencionais. Além da mudança no transporte, a nova versão introduz um sistema de extensões com governança formal, reforça a autorização com alinhamento mais próximo às práticas corporativas de OAuth 2.0 e OpenID Connect (OIDC), e estabelece garantias de ciclo de vida que reduzem rupturas futuras.

Para quem já utiliza o AgentCore Gateway, funcionalidade do Amazon Bedrock AgentCore, a adoção da nova versão é uma simples mudança de configuração via chamada UpdateGateway. Clientes existentes continuam funcionando exatamente como antes — não há nenhuma etapa por alvo. Se você já conhece as mudanças da especificação, pode ir direto para a seção Atualizando seu AgentCore Gateway.

O que muda com a nova especificação e por que isso importa

Esta versão contém mudanças incompatíveis com versões anteriores do protocolo MCP. A transição para o modelo sem estado é uma mudança estrutural que os mantenedores do protocolo consideram necessária para resolver desafios de escala em implantações corporativas. No entanto, a introdução de mudanças que quebram compatibilidade com novas versões não deve ser a norma daqui em diante. Para facilitar atualizações compatíveis com versões anteriores em revisões futuras, os mantenedores introduziram melhorias de governança na especificação: uma política de ciclo de vida de funcionalidades, um framework de extensões e um requisito de suíte de conformidade.

A atualização é opcional. Nada muda até que você e seus clientes ajam. O AgentCore Gateway anuncia as versões do protocolo que suporta por meio de um único campo de configuração. Clientes selecionam uma versão em cada requisição. Adicionar a versão 2026-07-28 a um gateway que também anuncia 2025-11-25 não altera nada para clientes que solicitam a versão mais antiga. Apenas um cliente que requisitar 2026-07-28 receberá o novo comportamento.

1. MCP agora é sem estado (stateless)

Nas versões anteriores do protocolo, toda interação HTTP com fluxo contínuo (Streamable HTTP) com um servidor MCP começava com um handshake de inicialização, no qual cliente e servidor trocavam versões do protocolo e capacidades. O servidor então emitia um cabeçalho Mcp-Session-Id que todas as requisições subsequentes precisavam carregar. Isso vinculava o cliente ao servidor que emitiu o identificador de sessão, exigindo sessões persistentes no balanceador de carga ou um armazenamento de sessão compartilhado para escalar horizontalmente.

Ao remover as sessões, servidores MCP remotos passam a se comportar como endpoints HTTPS padrão, escalando de forma limpa em cargas de trabalho corporativas. Os documentos de proposta de evolução do protocolo SEP-2575 e SEP-2567 removem esses requisitos da nova versão do protocolo. Com a versão 2026-07-28, cada requisição passa a carregar versão do protocolo, informações do cliente e capacidades do cliente dentro do parâmetro _meta, eliminando a necessidade do handshake de inicialização. Clientes que precisam descobrir o que um servidor suporta podem chamar o novo método server/discover a qualquer momento.

O resultado prático é que uma única chamada de ferramenta é completamente autocontida — não requer nenhum contexto de sessão anterior e pode ser roteada para qualquer instância de servidor.

A remoção da sessão de protocolo não impede suporte a aplicações com estado. Quando servidores precisam de continuidade entre chamadas, é possível seguir padrões estabelecidos para requisições HTTP, passando um ID explícito como parâmetro de ferramenta. Veja o exemplo abaixo de como criar um carrinho e adicionar itens a ele:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_basket
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"create_basket","arguments":{},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Response:
{"jsonrpc":"2.0","id":1,
 "result":{"resultType":"complete","content":[{"type":"text","text":"Created basket bsk_a1b2c3"}],"structuredContent":{"basket_id":"bsk_a1b2c3"},"isError": false}}

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: add_item
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"add_item","arguments":{"basket_id": "bsk_a1b2c3", "sku": "shoes"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

O AgentCore Gateway sempre protegeu os agentes da maior parte da mecânica de sessão do MCP. Com a versão 2026-07-28, isso fica mais simples em ambos os lados: a primeira chamada de ferramenta de um agente é uma requisição autocontida, em vez de um handshake seguido de uma chamada. Cada requisição carrega um cabeçalho Mcp-Protocol-Version. O gateway serve a requisição nessa versão quando ela estiver em supportedVersions, ou a rejeita com HTTP 400 (código -32022) e lista as versões suportadas quando não estiver.

2. Roteamento, cache e rastreamento sem precisar analisar o corpo da requisição

Nas versões anteriores, a operação executada por uma requisição era opaca para qualquer intermediário entre cliente e servidor. Balanceadores de carga, API gateways e limitadores de taxa precisavam analisar o corpo JSON-RPC para determinar qual método estava sendo chamado.

A versão 2026-07-28 resolve isso de três formas:

• Cabeçalhos de intenção: Toda requisição HTTP com fluxo contínuo agora expõe sua intenção em cabeçalhos padrão: Mcp-Method e Mcp-Name (SEP-2243) viajam fora do corpo, dando aos intermediários informações suficientes para rotear, limitar e monitorar apenas na camada HTTP.
• Metadados de frescor para cache: Respostas a operações de listagem e leitura de recursos agora incluem metadados explícitos de validade, ttlMs e cacheScope, inspirados na semântica do HTTP Cache-Control (SEP-2549). Clientes podem armazenar em cache uma resposta de tools/list por uma duração conhecida sem manter uma conexão persistente.
• Rastreamento distribuído formal: A especificação agora reserva as chaves de Contexto de Rastreamento W3C (traceparent, tracestate, baggage) dentro de _meta (SEP-414), formalizando o que vários SDKs já haviam adotado na prática. Um rastreamento distribuído originado em sua aplicação pode agora se propagar por toda a cadeia de chamadas e ser renderizado como uma árvore de spans unificada em qualquer coletor compatível com OpenTelemetry.

3. Interações servidor-para-cliente sem conexões persistentes

Um protocolo sem estado ainda precisa de uma forma para o servidor se comunicar de volta com o cliente durante uma chamada. O MCP tem três dessas interações: elicitação (o servidor pede input ao usuário final), roots (o servidor solicita diretórios e arquivos disponíveis no sistema de arquivos) e sampling (o servidor pede ao modelo do cliente para gerar uma resposta).

Nas versões anteriores, entregar essas requisições significava que o servidor mantinha um fluxo SSE (Server-Sent Events) aberto de volta para o cliente. Com a nova versão, requisições iniciadas pelo servidor só são permitidas enquanto o servidor está ativamente processando uma requisição do cliente (SEP-2260). Cada prompt que um usuário vê remonta a algo que ele ou seu agente iniciou.

As Requisições de Múltiplas Rodadas (SEP-2322) substituem o fluxo de longa duração anterior. O servidor embute perguntas em um InputRequiredResult e externaliza o estado por meio de um token opaco requestState, em vez de enviar uma pergunta via SSE. Veja o exemplo:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Delete 3 files?",
        "requestedSchema": {
          "type": "object",
          "properties": {
            "confirm": {
              "type": "boolean"
            },
            "required": ["confirm"]
          }
        }
      }
    },
    "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
  }
}

Os clientes coletam as respostas do usuário e reemitem a chamada original com as respostas e o requestState. Tudo que o servidor precisa está no payload, então qualquer instância de servidor pode retomar a operação.

4. Desacoplando extensões da especificação principal

Até agora, extensões do MCP eram um conceito informal sem governança. O documento SEP-2133 introduz um sistema formal. Cada extensão carrega um ID em formato DNS reverso, é negociada por meio de um mapa de extensões nas capacidades de cliente e servidor, vive em um repositório dedicado com mantenedores delegados e segue seu próprio ciclo de lançamento independente da especificação principal.

Uma nova Trilha de Extensões dentro do processo SEP define como uma extensão avança de experimental para status oficial. Em vez de cada nova ideia competir por espaço na especificação principal e forçar uma versão com quebra de compatibilidade, capacidades agora podem amadurecer como extensões opcionais em seus próprios cronogramas.

5. Endurecimento da autorização

Seis SEPs alinham a especificação de autorização do MCP com implantações de produção de OAuth 2.0 e OpenID Connect (OIDC). A autorização de entrada do gateway — seja IAM (SigV4) ou OAuth/JWT — não é alterada pela versão do protocolo. O mesmo vale para os provedores de credenciais de saída. Atualizar a versão do protocolo não requer alteração de credenciais ou configuração de autorizador.

6. Tratamento de erros e depreciações

Nas versões anteriores do protocolo, quase tudo retornava como HTTP 200 com um erro dentro do corpo JSON-RPC, incluindo falhas de transporte. Com a versão 2026-07-28, as camadas de transporte e aplicação são separadas de forma limpa. Falhas de transporte retornam códigos de status HTTP reais. Resultados no nível de aplicação permanecem no corpo:

• Método desconhecido: Versões 2025-* retornam erro JSON-RPC no corpo com HTTP 200; versão 2026-07-28 retorna HTTP 404.
• Versão de protocolo não suportada: Versões 2025-* variam; versão 2026-07-28 retorna HTTP 400, código -32022, com lista de versões suportadas no corpo.
• Campo vinculado a cabeçalho ausente ou inconsistente: Versões 2025-* variam; versão 2026-07-28 retorna HTTP 400, código -32020.
• Capacidade de cliente obrigatória ausente: Não aplicável nas versões 2025-*; versão 2026-07-28 retorna código -32021.

A especificação também reatribui o código de erro “recurso não encontrado” do MCP-específico -32002 para o padrão JSON-RPC -32602 Invalid Params (SEP-2164). Se seu cliente corresponder ao código -32002 em algum lugar, audite esses caminhos de código.

Além disso, na versão 2026-07-28: logging/setLevel é descontinuado, e um cliente que o chama é rejeitado. Para optar pela entrega de logs, defina o campo de metadados por requisição io.modelcontextprotocol/logLevel.

Três funcionalidades principais são depreciadas sob a nova política de ciclo de vida de funcionalidades do protocolo (SEP-2577):

• Roots — substituído por parâmetros de ferramenta, URIs de recurso ou configuração de servidor
• Sampling — substituído por integração direta com APIs de provedores de LLM
• Logging — substituído por stderr para transportes stdio e OpenTelemetry para observabilidade estruturada

Essas depreciações são consultivas. Os métodos, tipos e flags de capacidade permanecem funcionais nesta versão e em qualquer versão da especificação publicada dentro de doze meses a partir dela. No entanto, novas implementações não devem depender dessas funcionalidades.

7. Suporte a esquemas JSON Schema 2020-12

Os campos inputSchema e outputSchema de ferramentas agora suportam o vocabulário completo do JSON Schema 2020-12 (SEP-2106). Esquemas de entrada mantêm o requisito de raiz type: "object", mas ganham palavras-chave de composição (oneOf, anyOf, allOf), condicionais e referências internas ($ref, $defs). Esquemas de saída não têm restrição de tipo raiz, e structuredContent pode ser qualquer valor JSON válido. Implementações não devem seguir URIs $ref externos automaticamente e devem impor limites de profundidade e tempo durante a validação.

Como decidir se você está pronto para atualizar

Antes de habilitar a nova versão, responda três perguntas:

• Seus clientes estão prontos? Seus agentes alcançam o Gateway por meio de SDKs de cliente MCP. Verifique se os SDKs que seus frameworks de agente e aplicações host usam já enviaram suporte para 2026-07-28. Os SDKs de Nível 1 (Tier 1) já deveriam ter enviado suporte durante a janela de dez semanas do candidato a lançamento. Consulte a documentação do MCP SDK para a lista atual de níveis.
• Algo que você executa depende de comportamento removido ou alterado? Audite: sessões de protocolo usadas para carregar estado de aplicação, logging/setLevel, código de cliente que corresponde ao código de erro literal -32002, e qualquer dependência de Roots, Sampling ou Logging.
• Você controla ambos os lados? Não é necessário. A seleção de versão acontece por requisição, então um gateway com duas versões serve clientes antigos e novos simultaneamente. Você pode atualizar clientes e o gateway em cronogramas independentes, em qualquer ordem.

Atualizando seu AgentCore Gateway

Para clientes do AgentCore Gateway, adotar a versão 2026-07-28 é uma mudança de configuração. Seu AgentCore Gateway pode suportar múltiplas versões do protocolo simultaneamente. Você pode adicionar 2026-07-28 à lista de supportedVersions do gateway com uma única chamada UpdateGateway. Não é necessário recriar o gateway ou fazer alterações nas configurações individuais de alvos do gateway.

O comando UpdateGateway substitui o supportedVersions pelo conjunto que você envia — ele não acrescenta. Leia a configuração atual primeiro, depois envie a lista completa que você deseja que o gateway anuncie:

# 1. Read the current configuration.
aws bedrock-agentcore-control get-gateway \
    --gateway-identifier <gateway-id>

# 2. Advertise 2026-07-28 alongside the existing version.
aws bedrock-agentcore-control update-gateway \
    --name <gateway-name> \
    --role-arn <gateway-role-arn> \
    --protocol-type MCP \
    --authorizer-type <gateway-authorizer-type> \
    --gateway-identifier <gateway-id> \
    --protocol-configuration '{
      "mcp": {
        "supportedVersions": ["2025-11-25", "2026-07-28"]
      }
    }'

O AgentCore Gateway funciona com qualquer uma das seguintes versões do protocolo: 2025-03-26, 2025-06-18, 2025-11-25 e 2026-07-28.

Confirme que a nova versão está ativa chamando seu gateway com os novos cabeçalhos:

curl -s https://<your-gateway-endpoint>/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json,text/event-stream" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/list" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Uma resposta bem-sucedida confirma que o gateway serviu a requisição na versão 2026-07-28. Uma rejeição com código -32022 significa que a versão ainda não está no supportedVersions do gateway, e o corpo da resposta lista o que o gateway atualmente anuncia.

Para reverter, basta enviar a lista sem 2026-07-28. Requisições especificando a versão removida serão rejeitadas com um corpo de resposta listando as versões que o gateway ainda suporta. Certifique-se de que os clientes que você já migrou possam fazer fallback antes de remover a versão que eles estão solicitando.

Como funciona a seleção de versão

Clientes selecionam uma versão em cada requisição, não por meio de um handshake único. Cada requisição MCP declara sua versão no cabeçalho MCP-Protocol-Version, e o gateway a honra quando está em supportedVersions:

• Uma requisição nomeando uma versão que o gateway anuncia é servida nessa versão.
• Em um gateway com duas versões (por exemplo, 2026-07-28 e 2025-11-25), uma requisição 2026-07-28 recebe o novo comportamento e uma requisição 2025-11-25 recebe o comportamento anterior.
• Uma requisição nomeando uma versão que o gateway não anuncia é rejeitada com HTTP 400 e código -32022. O corpo da resposta lista as versões que o gateway suporta.
• Uma requisição que omite o cabeçalho recebe a versão padrão, 2025-03-26. Se esse padrão não estiver no supportedVersions do gateway, a requisição é rejeitada.

Isso permite um rollout em três etapas: adicionar 2026-07-28 junto às versões existentes, migrar clientes no seu próprio ritmo e, somente após todos os clientes solicitarem a nova versão, reduzir a lista.

Se o seu gateway está na frente de um servidor MCP alvo que atualiza para 2026-07-28 antes dos seus clientes, ele traduz entre versões — um cliente 2025-* pode chamar ferramentas comuns em um alvo 2026-07-28 e receber resultados no formato esperado, sem precisar atualizar. No entanto, essa tradução não suporta atualmente chamadas de elicitação e sampling de servidores para clientes.

Conclusão

A versão MCP 2026-07-28 é a maior revisão do protocolo já feita, e foi projetada para ser a última revisão que quebra compatibilidade. O modelo sem estado dá ao MCP uma base que escala em infraestrutura HTTP comum, enquanto as Extensões MCP dão espaço para novas capacidades evoluírem em seus próprios cronogramas.

Com o Amazon Bedrock AgentCore Gateway, adicionar suporte à versão mais recente do protocolo é apenas uma chamada UpdateGateway. Para começar, consulte a documentação do AgentCore Gateway, revise a especificação MCP 2026-07-28 e seu changelog, e tente habilitar a nova versão em um gateway hoje. Para detalhes completos, veja também o changelog em relação à versão 2025-11-25 e o anúncio do candidato a lançamento no blog do MCP. Se você tiver feedback sobre a especificação, os mantenedores aceitam issues no repositório da especificação MCP. Para dúvidas sobre o AgentCore Gateway, entre em contato pelo AWS re:Post ou pelos canais habituais de suporte da AWS.

Fonte

How AgentCore Gateway supports the MCP 2026-07-28 spec (https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/)

O que mudou

A AWS anunciou que o modo Enhanced do AWS DataSync agora oferece suporte ao Amazon EFS (Elastic File System) e ao Amazon FSx for Lustre como locais de origem ou destino nas transferências de dados.

Contexto: o que é o AWS DataSync

O AWS DataSync é um serviço seguro de transferência de dados em alta velocidade, projetado para simplificar a movimentação de dados pela rede. Ele já era amplamente utilizado para migrações e sincronizações entre diferentes sistemas de armazenamento da AWS.

A diferença entre o modo Basic e o modo Enhanced

Até agora, quem precisava mover dados de ou para o Amazon EFS e o Amazon FSx for Lustre estava limitado ao modo Basic do DataSync. Com a novidade, esses mesmos clientes podem migrar para o modo Enhanced, que traz vantagens importantes:

• Processamento de dados em paralelo, aumentando a velocidade das transferências
• Remoção das limitações de contagem de arquivos
• Fornecimento de métricas detalhadas sobre as transferências realizadas

Casos de uso beneficiados

A expansão do modo Enhanced para o EFS e o FSx for Lustre abre caminho para simplificar fluxos de trabalho em cenários de grande escala, como:

• Migrações de grande volume de dados
• Treinamento de modelos de IA agêntica e aprendizado de máquina
• Computação de alto desempenho (HPC)
• Processamento de dados genômicos
• Renderização de mídia

Disponibilidade

O recurso já está disponível em todas as Regiões AWS onde o AWS DataSync é oferecido. Para começar a usar, acesse o console do AWS DataSync. Para mais detalhes técnicos, consulte a documentação oficial do AWS DataSync.

Fonte

AWS DataSync Enhanced mode now supports Amazon EFS and Amazon FSx for Lustre (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-datasync-amazon-efs-fsx-lustre/)

O que foi anunciado

A AWS adicionou uma nova capacidade ao AWS Glue Data Quality: o suporte a estatísticas de distribuição para perfilamento de dados. O recurso chega por meio de um componente chamado Distribution Analyzer, que permite gerar perfis de frequência sobre os dados armazenados nos seus pipelines — sem a necessidade de escrever código personalizado para isso.

Como funciona o Distribution Analyzer

O Distribution Analyzer é utilizado dentro da Linguagem de Definição de Qualidade de Dados (DQDL — Data Quality Definition Language), já existente no Glue Data Quality. Por meio dele, é possível gerar dois tipos de saída dependendo do tipo da coluna:

• Histogramas para colunas numéricas
• Distribuições de valores para colunas categóricas, de data e booleanas

O recurso também suporta contagens de intervalos personalizadas (custom bin counts), o que permite explorar a forma e os padrões dos dados no nível de granularidade mais relevante para cada caso de uso.

Por que isso importa para quem trabalha com dados

Entender como os dados estão distribuídos é uma etapa fundamental para construir pipelines confiáveis. Com as estatísticas de distribuição, equipes de dados conseguem identificar rapidamente assimetrias (skewness), outliers e padrões inesperados nos datasets — tudo isso sem precisar desenvolver lógica customizada para cada análise.

Outro ponto relevante é a integração nativa: o Distribution Analyzer se encaixa diretamente nos rulesets DQDL já existentes. Ou seja, é possível adicionar o perfilamento de distribuição junto com as verificações de qualidade de dados atuais, tudo em uma única execução de avaliação.

Onde os resultados ficam armazenados

As estatísticas de distribuição geradas são armazenadas no Amazon S3, o que facilita consultas futuras por meio de serviços como o Amazon Athena. Além disso, os dados também ficam acessíveis via APIs, permitindo integração com workflows de monitoramento e ferramentas de visualização, incluindo o SageMaker Unified Studio.

Disponibilidade

O recurso de estatísticas de distribuição do AWS Glue Data Quality já está disponível em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US).

Para saber mais sobre o Glue Data Quality, consulte a documentação oficial do AWS Glue Data Quality. Para começar a usar o Distribution Analyzer, acesse a documentação de Analyzers.

Fonte

AWS Glue Data Quality now supports distribution statistics for data profiling (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-glue-data-quality-distribution-profiling)

O limite do RAG em tarefas analíticas complexas

Se você já usou Geração Aumentada por Recuperação (RAG) para analisar centenas de documentos ao mesmo tempo — como em processos de due diligence financeira ou revisões de conformidade regulatória — provavelmente já esbarrou nas suas limitações. A busca por similaridade consegue recuperar fragmentos relevantes, mas frequentemente perde as conexões que existem entre documentos diferentes.

Para ilustrar o problema, imagine uma firma de private equity avaliando uma aquisição de R$ 500 milhões. A equipe de due diligence precisa analisar demonstrações financeiras de 12 subsidiárias ao longo de 5 anos, mais de 200 contratos com fornecedores, relatórios de conformidade ambiental de 8 instalações e mais de 50 casos jurídicos. Quando um analista pergunta sobre os riscos financeiros consolidados considerando os termos atuais com fornecedores e os litígios pendentes, a busca por similaridade do RAG simplesmente não consegue montar essa resposta — as informações relevantes estão espalhadas por centenas de documentos sem nenhuma similaridade lexical entre elas.

É exatamente esse tipo de problema que a técnica TAKC (Task-Aware Knowledge Compression — Compressão de Conhecimento Orientada a Tarefas) se propõe a resolver.

O que é TAKC e como funciona

A ideia central do TAKC é usar um LLM (Modelo de Linguagem de Grande Escala) para produzir resumos mais curtos e focados em tarefas específicas — com resumos diferentes para tarefas diferentes. O ponto-chave é que documentos diferentes exigem informações diferentes dependendo do contexto de uso.

Um relatório anual comprimido para análise financeira precisa preservar receitas, margens e dados de fluxo de caixa. O mesmo relatório comprimido para uma revisão de conformidade precisa reter citações regulatórias e históricos de violações. Uma sumarização genérica tenta cobrir tudo e acaba diluindo a densidade de informação para qualquer caso de uso específico.

O TAKC comprime os documentos pela lente de uma tarefa específica: mantém o que importa e descarta o resto. Essa compressão acontece offline, uma vez por documento por tipo de tarefa. No momento da consulta, o sistema recupera a representação já comprimida em vez do documento original e responde com base nessa versão. Se a representação comprimida não tiver detalhes suficientes, um analisador de complexidade de consulta redireciona a pergunta para um nível de compressão menor, que retém mais contexto.

Diferente do RAG, o TAKC dá acesso a toda a base de conhecimento em forma comprimida — não apenas aos top-k fragmentos retornados por uma busca por similaridade. Isso preserva as conexões entre documentos, porque a compressão processa os documentos de forma integrada. A redução de tokens varia de 8x a 64x, sempre priorizando as informações relevantes para a tarefa.

Compressão em múltiplos níveis

Nem toda consulta exige o mesmo nível de detalhe. Uma pergunta como “Qual foi a receita do terceiro trimestre?” precisa de muito menos contexto do que um pedido para analisar as relações entre prazos de pagamento a fornecedores e o fluxo de caixa trimestral entre subsidiárias.

O TAKC resolve isso mantendo quatro níveis de compressão para cada tipo de tarefa:

• Leve (8x): reduz aproximadamente 87,5% do contexto. Preserva detalhes suficientes para raciocínio em múltiplas etapas e síntese entre documentos.
• Médio (16x): redução de aproximadamente 93,8%. Adequado para consultas analíticas de complexidade moderada.
• Alto (32x): redução de aproximadamente 96,9%. Atende buscas factuais e perguntas bem definidas.
• Ultra (64x): redução de aproximadamente 98,4%. Indicado para tarefas de classificação e buscas por palavras-chave.

Um analisador de complexidade de consulta roteia automaticamente cada pergunta para o nível adequado, com base em sinais como o comprimento da consulta, o tipo de pergunta e a presença de linguagem analítica. Perguntas factuais simples chegam ao cache mais comprimido; consultas analíticas complexas usam o cache menos comprimido. Tudo isso acontece de forma transparente para o usuário.

Na prática, a maioria das consultas empresariais são buscas simples que podem ser atendidas pelos níveis de maior compressão com custo mínimo. As consultas complexas, menos frequentes, consomem orçamentos maiores de contexto apenas quando necessário.

Arquitetura na AWS

A implementação roda na AWS como dois pipelines serverless desacoplados: um para ingestão e outro para consultas.

O AWS Lambda foi escolhido para computação porque cada invocação é de curta duração e orientada a eventos. O Amazon API Gateway expõe a interface de consulta como um endpoint REST. O Amazon ElastiCache Serverless cuida do cache com leituras em chaves compostas (takc:{task}:{rate}) sem necessidade de gerenciamento de shards. O Amazon Cognito gerencia emissão e renovação de tokens JWT sem código de autenticação customizado.

Pipeline de ingestão

Quando um documento chega ao Amazon S3 sob um prefixo de tipo de tarefa (por exemplo, raw-data/financial/), uma notificação de evento S3 aciona uma função AWS Lambda. Essa função divide o documento em segmentos de 256 tokens com sobreposição de 50 tokens para evitar perda de informação nas bordas. Em seguida, invoca de forma assíncrona uma função Lambda de compressão para cada segmento, permitindo processamento paralelo.

A segunda função chama o Amazon Bedrock para comprimir os segmentos nos quatro níveis de compressão. Cada chamada de compressão inclui um prompt orientado à tarefa que instrui o modelo sobre quais informações preservar. Veja um exemplo de prompt para análise financeira:

TASK: Financial analysis. Preserve revenue metrics, margins, cash flow, debt obligations, and financial risk indicators.
COMPRESSION TARGET: Reduce to approximately 1/16 of original length.
INSTRUCTIONS:
- Focus on facts and relationships relevant to the task
- Preserve numerical data and metrics
- Maintain entities and their attributes
- Keep causal relationships and dependencies
- Remove redundant or irrelevant information

O modelo sabe o que preservar porque o prompt especifica exatamente o que importa para aquela tarefa — é isso que torna a abordagem orientada à tarefa, em vez de uma compressão genérica.

As saídas comprimidas são armazenadas no Amazon ElastiCache Serverless com chaves como takc:financial:medium e têm backup no S3 para durabilidade. As entradas de cache usam TTL de 24 horas. Se uma entrada for removida ou expirar, a função de consulta recorre ao backup no S3 e repovoа o cache na leitura.

Pipeline de consulta

O usuário se autentica pelo Amazon Cognito, recebe um JWT (JSON Web Token) e envia a consulta pelo Amazon API Gateway. O AWS WAF (Firewall de Aplicação Web) fica na frente da API para limitação de taxa e proteção contra ameaças. Uma função Lambda analisa a complexidade da consulta por heurísticas, recupera o cache comprimido adequado do ElastiCache e envia o contexto comprimido junto com a consulta ao Amazon Bedrock para inferência.

As chamadas de compressão ao Bedrock — que são mais custosas — acontecem apenas uma vez durante a ingestão. O caminho de consulta é apenas uma busca no cache mais a inferência sobre o contexto comprimido.

Stack completo de serviços

O stack utiliza o Amazon Bedrock (Anthropic Claude 3 Haiku, Claude 3 Sonnet e Amazon Titan Text) para compressão e inferência. A seleção de modelo é configurável via valores de contexto do CDK sem alterações de código. O AWS Lambda (Python 3.12+) trata o processamento de dados e a lógica de consulta. O Amazon ElastiCache Serverless armazena o cache comprimido, enquanto o Amazon S3 guarda dados brutos, segmentos e backups do cache (criptografados com KMS). O Amazon API Gateway expõe os endpoints REST, e o Amazon Cognito fornece autenticação baseada em JWT. O AWS WAF protege a API com limitação de taxa e regras de segurança gerenciadas. O Amazon CloudWatch oferece monitoramento e métricas, e o AWS Key Management Service (AWS KMS) gerencia as chaves de criptografia.

Toda a infraestrutura é definida como um único stack do AWS Cloud Development Kit (AWS CDK) e implantada com um único comando.

Comparativo de custos

A tabela abaixo mostra o consumo de tokens de entrada para uma base de conhecimento de 100.000 tokens consultada 1.000 vezes por dia (tokens de saída são excluídos porque o tamanho da resposta é independente do tamanho do contexto):

• Contexto completo: 100.000 tokens por consulta → 100.000.000 tokens/dia → 100% do custo
• RAG (top-10 fragmentos): ~10.000 tokens → 10.000.000/dia → 10%
• TAKC Leve (8x): ~12.500 tokens → 12.500.000/dia → 12,5%
• TAKC Médio (16x): ~6.250 tokens → 6.250.000/dia → 6,25%
• TAKC Alto (32x): ~3.125 tokens → 3.125.000/dia → 3,1%
• TAKC Ultra (64x): ~1.563 tokens → 1.563.000/dia → 1,6%

O TAKC exige um custo inicial de compressão — chamadas únicas ao Bedrock durante a ingestão. Esse custo se amortiza em bases de conhecimento que mudam com pouca frequência e são consultadas repetidamente. Para bases de conhecimento que mudam a cada hora, o modelo de recuperação por consulta do RAG pode ser mais prático.

Quando escolher TAKC, RAG ou ambos

Cada abordagem tem seu cenário ideal:

• TAKC é mais indicado quando: as consultas exigem raciocínio entre documentos e síntese; a base de conhecimento muda diariamente ou menos; os tipos de tarefa são bem definidos; é necessário considerar o corpus completo; e a rastreabilidade da fonte não é obrigatória.
• RAG é mais indicado quando: as consultas são buscas factuais pontuais; a base de conhecimento muda a cada hora ou mais; os padrões de consulta são imprevisíveis; apenas alguns documentos são relevantes; e o usuário precisa rastrear a resposta até o documento-fonte.

Na prática, sistemas em produção frequentemente se beneficiam das duas abordagens. O RAG trata buscas rápidas com eficiência. O TAKC trata consultas analíticas onde abordagens baseadas em recuperação perdem conexões importantes. Um analisador de complexidade de consulta pode rotear entre eles. Para cargas de trabalho reguladas que exigem tanto raciocínio entre documentos quanto auditabilidade, é possível combinar TAKC para a resposta analítica e RAG para recuperar os documentos-fonte de suporte na trilha de auditoria.

Como implantar a implementação de referência

Para implantar a implementação de referência, são necessários: uma conta AWS com acesso a modelos do Amazon Bedrock, a CLI do AWS CDK, Python 3.12 ou superior e Node.js 18 ou superior.

Clone o repositório aws-samples/sample-bedrock-takc-compression e implante o stack CDK:

git clone https://github.com/aws-samples/sample-bedrock-takc-compression
cd sample-bedrock-takc-compression/cdk
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk deploy

Após a implantação, faça o upload de um documento para o bucket S3:

aws s3 cp your-document.pdf s3://$(aws cloudformation describe-stacks --stack-name TakcStack \
  --query 'Stacks[0].Outputs[?OutputKey==`DataBucketName`].OutputValue' \
  --output text)/raw-data/financial/

Aguarde 2 a 3 minutos para que o pipeline de ingestão segmente e comprima o documento nos quatro níveis. Em seguida, consulte o endpoint da API:

curl -X POST $(aws cloudformation describe-stacks --stack-name TakcStack \
  --query 'Stacks[0].Outputs[?OutputKey==`ApiEndpoint`].OutputValue' \
  --output text)/query \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"question": "What are the key financial risks?"}'

O sistema cuida automaticamente da segmentação, compressão em múltiplos níveis, cache e roteamento de consultas sem configuração adicional.

Para evitar cobranças contínuas após os testes, esvazie o bucket S3 e destrua o stack CDK:

aws s3 rm s3://$(aws cloudformation describe-stacks --stack-name TakcStack \
  --query 'Stacks[0].Outputs[?OutputKey==`DataBucketName`].OutputValue' \
  --output text) --recursive

cd sample-bedrock-takc-compression/cdk
source .venv/bin/activate
cdk destroy

A chave KMS é retida com uma janela de exclusão pendente de 30 dias. Para agendar sua exclusão imediatamente:

aws kms schedule-key-deletion --key-id <key-id> --pending-window-in-days 7

Conclusão

Tarefas analíticas complexas que abrangem centenas de documentos exigem mais do que recuperação de fragmentos. O TAKC oferece uma abordagem construída para esse cenário: comprima a base de conhecimento completa offline pela lente de tarefas específicas, armazene essas representações em múltiplos níveis de fidelidade e direcione o nível de compressão adequado para a complexidade de cada consulta.

A implementação na AWS usa o Amazon Bedrock para compressão e inferência, o Amazon ElastiCache Serverless para cache e uma arquitetura totalmente serverless que escala conforme a demanda. O código de referência, a infraestrutura CDK e os scripts de implantação estão disponíveis em aws-samples/sample-bedrock-takc-compression.

Referências

• Documentação do Amazon Bedrock
• Documentação do Amazon ElastiCache Serverless
• Guia de engenharia de prompts do Amazon Bedrock

Fonte

Beyond RAG: Task-aware knowledge compression for enterprise AI on AWS (https://aws.amazon.com/blogs/machine-learning/beyond-rag-task-aware-knowledge-compression-for-enterprise-ai-on-aws/)

O que foi anunciado

A AWS anunciou duas novas capacidades para o AWS Glue Data Quality: suporte à detecção de anomalias em avaliações baseadas no Catálogo (GDC) e a possibilidade de gravar os resultados das avaliações diretamente em tabelas do AWS Glue Data Catalog. Ambas as funcionalidades funcionam tanto em jobs de ETL (Extração, Transformação e Carga) quanto em avaliações diretas no Catálogo, garantindo uma experiência consistente de qualidade de dados independentemente do tipo de fluxo de trabalho utilizado.

Detecção de anomalias com Machine Learning

Com o suporte à detecção de anomalias para tabelas do GDC, a AWS permite identificar mudanças inesperadas nas estatísticas dos dados — como quedas repentinas em valores distintos ou picos no número de linhas — sem a necessidade de escrever regras com limites explícitos. O mecanismo usa previsão de séries temporais com ML (Machine Learning) para detectar esses desvios automaticamente.

Essa capacidade é especialmente útil para engenheiros de dados que monitoram centenas de tabelas no GDC e precisam que problemas sejam identificados de forma automática, sem intervenção manual constante.

Gravação de resultados no Glue Data Catalog

A segunda novidade é a capacidade de armazenar os resultados das avaliações diretamente em tabelas do GDC. Isso inclui:

• Resultados das regras de qualidade de dados
• Métricas de profiling (perfilamento dos dados)
• Previsões de anomalias com intervalos de confiança

Com isso, cria-se um histórico consultável de todas as avaliações de qualidade realizadas. Independentemente de a avaliação ter sido executada em um job ETL ou diretamente em uma tabela do Catálogo, os resultados podem ser consultados a qualquer momento usando SQL padrão.

Disponibilidade

As funcionalidades de detecção de anomalias e armazenamento de resultados no GDC estão disponíveis em todas as regiões comerciais da AWS e nas regiões do AWS GovCloud (US). Para começar a usar, a AWS disponibiliza a documentação oficial do AWS Glue Data Quality.

Fonte

AWS Glue Data Quality now supports anomaly detection and writing results to the AWS Glue Data Catalog (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-glue-data-quality-catalog-anomaly-detection-write-results)