Blog

O problema clássico do ovo e da galinha no processamento de documentos

Quem já trabalhou com Processamento Inteligente de Documentos (IDP) conhece bem o dilema inicial: antes de extrair informações de documentos, você precisa de um schema que defina o que deve ser extraído. Mas como criar esses schemas quando você tem milhares de documentos sem saber quais tipos existem na coleção? Fazer isso manualmente, em escala, consome tempo e recursos consideráveis, tornando difícil justificar o investimento em iniciativas de IDP.

Para resolver exatamente esse problema, a AWS apresentou a funcionalidade de descoberta multi-documento no IDP Accelerator. Ela atua como uma etapa de pré-processamento automatizada, analisando documentos desconhecidos, agrupando-os por tipo e gerando schemas prontos para uso.

O que é o IDP Accelerator

O IDP Accelerator é uma solução escalável, serverless e de código aberto para processamento automatizado de documentos e extração de informações. Para configurá-lo para tipos específicos de documentos, é necessário um arquivo de configuração que define as classes e os campos a serem extraídos. Um exemplo mínimo está disponível no repositório GitHub do IDP Accelerator.

O IDP Accelerator já contava com um Módulo de Descoberta capaz de gerar uma configuração de classe a partir de um único documento de exemplo. O problema é que esse recurso exige que o usuário já conheça as classes de documentos e consiga identificar um exemplo representativo para cada uma. A nova funcionalidade multi-documento remove esse pré-requisito, acelerando o caminho para aplicar o IDP Accelerator a coleções de documentos sem rótulo.

Como a solução funciona

A nova funcionalidade está integrada ao Módulo de Descoberta existente como uma capacidade “Múltiplos Documentos”, ao lado da opção “Documento Único” já disponível. A orquestração é feita por uma máquina de estados do AWS Step Functions e por funções do AWS Lambda para computação serverless.

Os documentos são processados a partir de um bucket do Amazon Simple Storage Service (Amazon S3) ou de um arquivo Zip enviado diretamente. Os modelos disponíveis pelo Amazon Bedrock geram os schemas, que são automaticamente integrados ao arquivo de configuração do IDP Accelerator.

O fluxo completo acontece em três grandes etapas: geração de embeddings, agrupamento de documentos e geração agêntica de schemas — com uma etapa adicional de análise e reflexão ao final.

Detalhes técnicos do pipeline

Geração de embeddings

O processo começa convertendo cada documento em um embedding vetorial — uma representação numérica das características visuais do documento. Para documentos com múltiplas páginas, apenas a primeira página é utilizada.

A solução usa embeddings visuais em vez de texto extraído por OCR (Reconhecimento Óptico de Caracteres). A razão é que embeddings visuais capturam layout, formatação e pistas estruturais que distinguem tipos de documentos mesmo quando o conteúdo textual é semelhante. O modelo padrão adotado é o Cohere Embed v4, disponível pelo Amazon Bedrock. A etapa de embedding já trata automaticamente questões como compressão de imagem, lógica de retry e controle de taxa de requisições.

Agrupamento de documentos

Com os embeddings gerados, a solução precisa descobrir quantos tipos de documentos existem na coleção. Para isso, utiliza o silhouette score (pontuação de silhueta), uma métrica que mede o quão bem separados estão os grupos entre si e o quão compactos são os documentos dentro de cada grupo.

Usando o algoritmo k-means, o sistema testa valores de k (número de grupos) de 2 a 20 por padrão e seleciona o agrupamento com a maior pontuação de silhueta. Para garantir grupos significativos, cada cluster precisa ter pelo menos dois documentos. Se necessário, o limite superior de k é reduzido abaixo de 20 para satisfazer essa restrição.

Validação da abordagem de embeddings e clustering

Para validar a abordagem, a AWS realizou experimentos com o Cohere Embed v4 sobre um subconjunto do dataset OCR-benchmark, disponível no bucket de conjunto de testes implantado com o stack CloudFormation do IDP Accelerator. Esse subconjunto contém 293 documentos distribuídos em 9 tipos: cheque bancário, contrato de locação comercial, extrato de cartão de crédito, nota de entrega, inspeção de equipamento, glossário, formulário de petição, imóvel e escala de turnos.

O objetivo era verificar se o k-means conseguia identificar corretamente esses agrupamentos usando o modelo de embedding. O resultado foi expressivo: a maior pontuação de silhueta ocorreu exatamente em k=9, correspondendo ao número real de tipos de documentos no dataset.

Para visualizar os resultados, foi gerado um gráfico t-SNE (Incorporação de Vizinhos Estocásticos Distribuídos em t — t-SNE), uma técnica de visualização que reduz dados de alta dimensionalidade para um espaço bidimensional preservando as relações entre os pontos. O gráfico mostrou os clusters claramente separados, cada um correspondendo a um tipo de documento.

O agrupamento atingiu um Índice Rand Ajustado (ARI) e uma Informação Mútua Normalizada (NMI) perfeitos, ambos com valor 1.0. O ARI mede o quão bem o agrupamento corresponde aos grupos reais, enquanto o NMI quantifica a informação compartilhada entre os clusters previstos e os reais. Cada cluster mapeou um-para-um para uma classe de documento real com 100% de pureza.

Esses resultados demonstram que embeddings multimodais de alta qualidade permitem classificação de documentos totalmente não supervisionada — sem nenhum dado de treinamento rotulado. Vale ressaltar, porém, que o desempenho nesse dataset de benchmark não garante resultados similares em outras coleções de documentos, pois as características específicas de cada dataset influenciam diretamente a qualidade dos resultados.

Geração agêntica de schemas

Após a identificação dos clusters, o pipeline entra na fase agêntica. Para cada cluster, um Strands Agent é invocado para determinar o tipo de documento e gerar um schema. A escolha pelo Strands Agents se deve à abordagem orientada pelo modelo, que oferece ao LLM a flexibilidade de raciocinar autonomamente sobre cada schema.

O agente precisa visualizar documentos em diferentes posições dentro do cluster para capturar toda a variedade antes de gerar o schema — por exemplo, um documento próximo ao centro, um na periferia e um a distância intermediária. Uma abordagem determinística e fixa de amostragem não funcionaria aqui, pois a qualidade do agrupamento depende fortemente dos documentos específicos de cada coleção.

Para isso, o agente conta com duas ferramentas especializadas:

• Ferramenta de Análise de Cluster — Recupera IDs de documentos ordenados por distância do centróide do cluster, permitindo que o agente amostre estrategicamente ao longo do espectro de variação dentro do cluster.
• Ferramenta de Visualização de Documento — Busca e comprime imagens de documentos para inspeção visual, tratando automaticamente as restrições de tamanho para a janela de contexto do modelo.

O prompt de sistema do agente incorpora conhecimento de domínio sobre convenções de JSON Schema e requisitos da configuração do IDP Accelerator. O agente é instruído a:

• Amostrar documentos estrategicamente, parando cedo se já tiver cobertura suficiente.
• Gerar JSON Schemas com metadados adequados, definições de tipo e descrições.
• Incluir anotações específicas do IDP Accelerator como x-aws-idp-document-type e x-aws-idp-evaluation-method. O campo x-aws-idp-evaluation-method é utilizado pela extensão de avaliação baseada no Stickler.
• Criar definições reutilizáveis ($defs) para estruturas comuns como endereços, itens de linha e informações fiscais.
• Aplicar métodos de avaliação adequados conforme o tipo de campo: EXACT para strings, NUMERIC_EXACT para números e LLM para objetos complexos ou aninhados.

Os agentes rodam em paralelo, então não é necessário esperar que um cluster termine para o próximo começar.

Análise e reflexão dos schemas

Após cada agente gerar seu schema de forma independente, uma etapa de análise avalia a diferenciação entre os resultados. Ela verifica se os agrupamentos descobertos estão bem separados ou se há sobreposições, e se os schemas gerados são completos e consistentes. O sistema identifica redundâncias ou duplicações entre tipos de documentos e apresenta recomendações concretas, como mesclar clusters ou refinar definições de campos. O resultado final é um relatório de qualidade com uma visão geral legível das classes identificadas, visível nos detalhes do job de descoberta no IDP Accelerator.

Como executar a descoberta multi-documento

Passo 1: Criar uma nova configuração

Acesse a seção de Configuração no console do IDP Accelerator e selecione Visualizar/Editar Configuração. Escolha Schema de Documento > Limpar Tudo para criar uma configuração vazia. Em seguida, selecione Salvar como Versão, forneça um nome descritivo e confirme.

Passo 2: Executar a descoberta multi-documento

Com a configuração criada, acesse a seção de Descoberta e selecione a opção Múltiplos Documentos. Escolha a versão de configuração recém-criada e configure a fonte de documentos: selecione Caminho S3 ou Upload Zip, escolha o bucket de origem e especifique o prefixo S3 onde os documentos estão armazenados. Os documentos precisam estar em um dos buckets existentes do IDP Accelerator (Discovery Bucket, Test Bucket ou Input Bucket) para usar a opção de bucket de origem. Clique em Iniciar Descoberta para acionar a máquina de estados.

Passo 3: Monitorar o job e visualizar os resultados

Uma nova entrada aparecerá na tabela de jobs de Descoberta Multi-Documento, mostrando o status de execução, a etapa atual e metadados. Após a conclusão, acesse os detalhes do job para visualizar o Relatório de Qualidade. As classes descobertas e seus schemas JSON são automaticamente integrados ao arquivo de configuração.

Boas práticas para melhores resultados

Antes de executar o job de descoberta multi-documento em larga escala, vale considerar algumas recomendações:

• Como o workflow processa apenas a primeira página de cada PDF, certifique-se de que os arquivos de entrada sejam documentos individuais. Pacotes com múltiplos documentos ainda não são suportados.
• Após obter os resultados iniciais, revise o relatório de qualidade com cuidado para identificar problemas como clusters sobrepostos ou distribuições desiguais de documentos antes de finalizar os schemas.
• Se a qualidade dos schemas for inconsistente entre clusters, verifique se a coleção tem uma distribuição muito desigual de tipos de documentos. Executar o job em um subconjunto mais balanceado pode ajudar o agente a produzir clusters e schemas mais confiáveis.

Próximos passos após a descoberta

O que fazer depois depende do que o workflow encontrou nos documentos:

• Schemas limpos e baixa sobreposição no relatório: o caminho está livre para executar o IDP em escala. Os schemas já estão automaticamente adicionados ao campo de classes do arquivo de configuração do IDP Accelerator.
• Relatório indicou clusters sobrepostos: revise as recomendações e use-as para refinar os schemas gerados, o que pode incluir mesclar schemas similares em uma única classe ou ajustar definições de campos para reduzir sobreposição.
• Qualidade inconsistente entre clusters: verifique a distribuição dos tipos de documentos na coleção e considere executar o job em um subconjunto mais balanceado.

Conclusão

A funcionalidade de descoberta multi-documento resolve um desafio clássico no processamento de documentos: você precisa de schemas para processar documentos, mas precisa processar documentos para construir schemas. A solução combina embeddings visuais, agrupamento automático e geração agêntica de schemas com LLMs multimodais, transformando uma coleção opaca de documentos desconhecidos em classes e schemas estruturados, prontos para revisão humana.

Quem quiser experimentar ou contribuir com a solução pode acessar o repositório GitHub do IDP Accelerator para abrir issues ou pull requests.

Fonte

Automate schema generation for intelligent document processing (https://aws.amazon.com/blogs/machine-learning/automate-schema-generation-for-intelligent-document-processing/)

Soberania digital chega à era da IA

A nuvem e a inteligência artificial estão transformando indústrias e sociedades em ritmo acelerado — da pesquisa científica à experiência do cliente, passando pela otimização de processos e serviços públicos. Nesse contexto, a Amazon Web Services (AWS) publicou um posicionamento detalhado sobre como aborda a soberania de IA, tema que vem ganhando espaço crescente nas discussões regulatórias e estratégicas em todo o mundo.

Em 2022, a AWS formalizou seu compromisso com controle e escolha por meio do AWS Digital Sovereignty Pledge — uma promessa de oferecer aos clientes o conjunto mais avançado de controles de soberania disponível na nuvem. Com a aceleração da adoção de IA, a empresa passou a trabalhar ativamente para ajudar clientes a adotar inovação em IA sem abrir mão dos requisitos de soberania.

O ponto de partida da abordagem da AWS é reconhecer que soberania digital — e soberania de IA — significa coisas diferentes para diferentes partes interessadas. Cada país e região tem requisitos próprios, em constante evolução, sem uma orientação uniforme sobre quais cargas de trabalho ou setores precisam estar em conformidade. Ainda assim, a empresa identificou temas recorrentes: soberania de dados (incluindo residência de dados e restrições de acesso por operadores) e soberania operacional (incluindo resiliência, sobrevivência e independência). A soberania de IA adiciona uma camada a essas bases, incorporando considerações como a preservação de normas culturais, valores e idiomas locais nas saídas dos modelos.

Controle e escolha em toda a pilha de IA

Para a AWS, garantir soberania de IA exige controle e escolha em toda a pilha tecnológica — uma infraestrutura abrangente que combina computação, redes, gerenciamento de dados, controles de segurança, serviços de aplicação especializados e talentos. Isso inclui a capacidade de fazer escolhas deliberadas sobre localização, dependências, serviços e parceiros, alinhadas às necessidades específicas de cada cliente, aos requisitos regulatórios e aos objetivos de inovação.

No campo do hardware, os clientes podem escolher entre uma ampla gama de chips otimizados para IA — incluindo silicon desenvolvido pela própria AWS e chips da NVIDIA, AMD e Intel — para selecionar o componente mais adequado para cada carga de trabalho.

Opções de implantação para diferentes necessidades

A AWS oferece um leque de opções para levar a nuvem até onde o cliente mais precisa, incluindo AWS AI Factories, AWS Outposts, AWS Local Zones, AWS Dedicated Local Zones, AWS Regions e o AWS European Sovereign Cloud.

Para clientes que precisam de implantações dedicadas para cargas de trabalho de missão crítica em IA, as AWS AI Factories são uma opção relevante. Trata-se de implantações fisicamente isoladas e exclusivas para o cliente, que combinam infraestrutura de IA de última geração — incluindo aceleradores AWS Trainium, GPUs NVIDIA, redes e armazenamento dedicados. As AI Factories atendem às necessidades de soberania de IA ao entregar capacidades de IA on-premises para treinamento, ajuste fino e inferência em tempo real de forma segura.

Portfólio de serviços de IA

O portfólio de IA da AWS cobre desde modelos de base (FMs) via Amazon Bedrock, passando por ofertas de aprendizado de máquina como o Amazon SageMaker, serviços de aplicação como o Amazon Q, e ferramentas para desenvolvedores como o Kiro. O objetivo declarado é dar aos clientes controle sobre seus dados e liberdade de escolha em como implantam IA.

Com o Amazon Bedrock, os clientes podem escolher entre centenas de modelos de provedores como AI21 Labs, Anthropic, Amazon, Cohere, Mistral AI e OpenAI. Eles podem avaliar e selecionar os FMs mais adequados às suas necessidades, escolher onde implantá-los e fazer ajuste fino dos modelos de forma privada com seus próprios dados. Um ponto importante destacado pela AWS: nenhum dado inserido ou gerado pelo Amazon Bedrock é utilizado para treinar o Amazon Nova ou qualquer modelo de terceiros.

Apoio às estratégias nacionais de IA

Estratégias de IA bem-sucedidas exigem a construção de um ambiente holístico — que nutra talentos locais, apoie startups, desenvolva aplicações específicas para cada setor e fomente parcerias público-privadas. A nuvem transformou a IA de uma tecnologia exclusiva, que exigia investimentos massivos, em uma ferramenta acessível para inovação em todos os setores e tamanhos de organização.

Embora a infraestrutura técnica receba grande parte da atenção nas discussões sobre soberania de IA, as dimensões culturais e estratégicas dos modelos de base nacionais são igualmente críticas. Esses modelos não são apenas ferramentas computacionais — eles podem codificar elementos de conhecimento cultural, nuances linguísticas e contexto social, tornando a relevância local uma consideração de design, não um detalhe secundário.

Modelos treinados localmente podem refletir currículos educacionais nacionais e valores culturais, além de compreender sistemas jurídicos locais, práticas de negócios e estruturas regulatórias. Modelos treinados em idiomas locais, dialetos e contextos culturais apoiam a diversidade linguística e ajudam línguas sub-representadas a ganhar espaço em produtos e serviços de IA.

Para personalizar modelos, os clientes podem usar o Amazon SageMaker AI para especialização por domínio, voz e avaliação de modelos quanto à precisão. Dois exemplos práticos ilustram essa capacidade:

• O primeiro Modelo de Linguagem de Grande Escala (LLM) grego disponível, lançado em março de 2024, foi o Meltemi — construído sobre o Mistral-7B, rodando em infraestrutura AWS e continuamente pré-treinado para ampliar sua proficiência no idioma grego usando um conjunto de dados de 28,5 bilhões de tokens em grego. O Meltemi está disponível no HuggingFace.
• O SEA-LION — uma família de LLMs multilíngues e de código aberto para o Sudeste Asiático — foi treinado inteiramente na AWS com clusters de GPU gerenciados. A equipe concluiu um modelo de 3 bilhões de parâmetros em apenas 3 meses, um cronograma 60% mais rápido do que projetos comparáveis em infraestrutura on-premises.

Controle verificável sobre o acesso aos dados

Soberania não se resume a onde os dados residem — trata-se de quem pode acessá-los e em que condições. No contexto de IA, a restrição de acesso vai além da infraestrutura e passa a cobrir as entradas e saídas do modelo, os processos de treinamento e os ambientes operacionais onde a IA é executada. Diferentemente da infraestrutura tradicional, as cargas de trabalho de IA introduzem novas superfícies de acesso: o próprio modelo, os dados usados para treiná-lo e o pipeline de inferência pelo qual passam dados sensíveis.

Para garantir a confidencialidade e a integridade dos dados dos clientes, todas as instâncias modernas do Amazon Elastic Compute Cloud (Amazon EC2) — incluindo as que oferecem aceleradores de IA como AWS Inferentia e AWS Trainium — são respaldadas pelas capacidades de segurança do AWS Nitro System. Por design, não existe mecanismo que permita a qualquer funcionário da AWS acessar dados de clientes em instâncias EC2 baseadas no Nitro. O NCC Group, empresa independente de cibersegurança, validou o design do Nitro System.

À medida que agentes de IA passam a executar ações em sistemas em nome dos usuários, controlar quem e o que pode acessar recursos — e garantir supervisão humana adequada — torna-se fundamental. O AWS Identity and Access Management (IAM) garante que apenas usuários e aplicações autorizados possam acessar recursos de IA, por meio de permissões granulares e trilhas de auditoria abrangentes. Para agentes de IA e cargas de trabalho automatizadas, o Amazon Bedrock AgentCore Identity fornece gerenciamento de identidade e credenciais, para que os agentes operem com as permissões certas — e nada além disso.

Transparência e certificações

A transparência é apresentada como um pilar central do compromisso de soberania digital da AWS. A empresa fornece medidas técnicas, controles operacionais e proteções contratuais que dão aos clientes controle sobre onde localizam seus dados, quem pode acessá-los e como são utilizados.

Entre as iniciativas de transparência, a AWS menciona a atualização de seus Termos de Serviço para refletir os compromissos de proteção técnica (como o AWS Nitro System), além de fornecer comprometimentos detalhados sobre como lida com solicitações de terceiros para dados de clientes. Um blog sobre o CLOUD Act foi disponibilizado para ajudar clientes a tomar decisões informadas sobre soberania.

No campo da IA responsável, a AWS destaca que foi o primeiro grande provedor de serviços em nuvem a obter a certificação acreditada ISO/IEC 42001 para serviços de IA — um padrão internacional de sistema de gestão que define requisitos e controles para promover o desenvolvimento e uso responsável de sistemas de IA. A certificação cobre o Amazon Bedrock, o Amazon Q Business, o Amazon Textract e o Amazon Transcribe. Em novembro de 2025, a AWS concluiu com sucesso sua primeira auditoria de vigilância para ISO 42001:2023 sem nenhuma não-conformidade.

A empresa também suporta mais de 140 padrões de segurança e certificações de conformidade que seus clientes e parceiros podem herdar para cumprir leis e regulamentações locais.

Compromisso contínuo com a soberania

A mensagem central da AWS é que o compromisso com soberania não é estático — à medida que a nuvem e a IA evoluem, a empresa declara que continuará oferecendo os controles e recursos de soberania mais avançados disponíveis. O objetivo é garantir que os clientes possam aproveitar o poder transformador da IA sem abrir mão de capacidades, desempenho, inovação, segurança e escala.

Para organizações brasileiras que lidam com dados sensíveis, operam em setores regulados ou simplesmente querem entender melhor como a soberania de IA se aplica às suas operações, o posicionamento detalhado da AWS oferece um mapa útil das ferramentas e compromissos disponíveis na plataforma.

Fonte

Enabling AI sovereignty on AWS (https://aws.amazon.com/blogs/security/enabling-ai-sovereignty-on-aws/)

Expansão regional das instâncias G6 no SageMaker Studio

A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 G6 nos notebooks do SageMaker Studio em duas novas regiões: Oriente Médio (Dubai) e Ásia-Pacífico (Malásia). Para equipes que operam nessas localidades, isso representa acesso direto a hardware de alto desempenho para cargas de trabalho de inteligência artificial e aprendizado de máquina, sem necessidade de rotear para outras regiões.

O que são as instâncias G6?

As instâncias G6 são equipadas com até 8 GPUs NVIDIA L4 Tensor Core, cada uma com 24 GB de memória, e processadores AMD EPYC de terceira geração. Em termos práticos, isso significa uma capacidade de processamento paralelo significativa para tarefas que exigem alto poder computacional em IA.

Um ponto de destaque técnico: as instâncias G6 oferecem desempenho 2x superior para inferência de aprendizado profundo em comparação com as instâncias EC2 G4dn. Para times que já utilizam G4dn e buscam mais eficiência sem migrar para arquiteturas completamente diferentes, essa é uma evolução direta e relevante.

Casos de uso suportados

Segundo a AWS, as instâncias G6 no SageMaker Studio são indicadas para uma variedade de cenários práticos, incluindo:

• Teste interativo de implantação de modelos
• Treinamento interativo de modelos
• Fine-tuning e inferência de IA generativa
• Processamento de linguagem natural (PLN)
• Tradução de idiomas
• Visão computacional
• Motores de recomendação

O ambiente de notebooks do SageMaker Studio permite que essas atividades sejam realizadas de forma interativa, o que facilita iterações rápidas durante o desenvolvimento e a experimentação de modelos.

Como começar

Para quem deseja configurar e utilizar as instâncias G6 no SageMaker Studio, a AWS disponibiliza guias de desenvolvedor com instruções detalhadas para os ambientes JupyterLab e CodeEditor dentro do SageMaker Studio. Para consultar os valores dessas instâncias, as informações de preço estão disponíveis na página de preços do SageMaker.

Fonte

Announcing Region Expansion of G6 instances on SageMaker Studio notebooks (https://aws.amazon.com/about-aws/whats-new/2026/03/g6-region-expansion-sagemaker-studio-notebooks/)

O problema com APIs de busca tradicionais em fluxos de agentes

Se você está construindo agentes de IA para pesquisa, verificação de fatos ou inteligência competitiva, a qualidade da informação em tempo real é determinante. O problema é que a maioria das APIs de busca genéricas não foi projetada para esse tipo de fluxo: elas retornam páginas cheias de HTML e snippets curtos otimizados para navegação humana, não dados estruturados que um agente possa consumir diretamente. O resultado prático é que os desenvolvedores acabam precisando construir camadas adicionais — crawlers customizados, parsers e lógica de ranqueamento — só para transformar esse conteúdo em algo utilizável dentro do workflow do agente.

É exatamente essa lacuna que a integração entre o Strands Agents SDK e a Exa busca resolver, oferecendo uma camada de busca e recuperação de conteúdo nativa para IA, construída diretamente na interface de ferramentas do SDK.

O que é o Strands Agents SDK

O Strands Agents SDK é um framework open source da AWS para construção de agentes de IA com uma abordagem orientada ao modelo. Em vez de escrever workflows com cada passo codificado manualmente, o desenvolvedor fornece um modelo, um prompt de sistema e uma lista de ferramentas. O próprio modelo decide o que fazer a seguir: quais ferramentas chamar, em que ordem e quando a tarefa está concluída.

No centro do SDK está o chamado agent loop. A cada iteração, o modelo recebe todo o histórico da conversa — incluindo cada chamada de ferramenta anterior e seu resultado. Se o modelo precisar de mais informações, ele solicita uma ferramenta; o Strands Agents a executa e devolve o resultado. O loop continua até que o modelo produza uma resposta final. Essa acumulação de contexto ao longo das iterações é o que permite que agentes resolvam tarefas de múltiplos passos que vão além do que uma única chamada a um Modelo de Linguagem de Grande Escala (LLM) consegue fazer.

O SDK já vem com mais de 40 ferramentas pré-construídas cobrindo operações de arquivo, execução de shell, busca na web, APIs da AWS, memória, execução de código e muito mais. Ele também suporta o Protocolo de Contexto de Modelo (MCP — Model Context Protocol), então ferramentas expostas por servidores MCP ficam disponíveis para o agente sem trabalho adicional de integração. Adicionar novas ferramentas — incluindo as da Exa — segue o mesmo padrão: basta incluí-las na lista tools=[] e o modelo aprende a usá-las a partir das suas assinaturas.

O que é a Exa e por que ela é diferente

A Exa é uma engine de busca em escala web construída especificamente para LLMs e agentes de IA. Diferente de buscadores tradicionais, a Exa entende o significado de uma consulta, não apenas suas palavras-chave. Uma busca como “startups construindo soluções climáticas” retorna startups reais do setor climático, mesmo que essas páginas nunca usem exatamente essa frase — o modelo faz a correspondência por similaridade semântica, não por sobreposição de strings.

Os resultados chegam como conteúdo limpo e estruturado, sem anúncios ou ruído de Otimização para Mecanismos de Busca (SEO — Search Engine Optimization), prontos para serem consumidos diretamente por um LLM.

As duas ferramentas da integração

A integração com a Exa está disponível através do pacote strands-agents-tools e expõe duas capacidades ao agente:

• exa_search: realiza buscas na web com suporte a múltiplos modos — auto, fast, instant e deep — e permite filtrar resultados por categoria (notícias, artigos acadêmicos, repositórios GitHub, PDFs, perfis de pessoas, relatórios financeiros), domínio, data e conteúdo textual. Também é possível solicitar conteúdo e resumos junto com os resultados em uma única chamada.
• exa_get_contents: recupera o conteúdo completo de URLs que o agente já descobriu — seja de uma busca anterior ou do próprio raciocínio do modelo. A ferramenta verifica primeiro um cache de conteúdo para acelerar requisições repetidas; se o conteúdo não estiver em cache ou se o agente precisar da versão mais atual, ela pode fazer live crawling automaticamente.

Os quatro modos de busca do exa_search são:

• Instant (~200ms): para aplicações em tempo real como autocomplete, sugestões ao vivo e agentes de voz.
• Fast (~450ms): otimizado para velocidade, adequado para fluxos agenticos onde o agente faz dezenas de chamadas de busca sequenciais.
• Auto (~1s) — Recomendado: latência balanceada com resultados de alta qualidade. Ponto de partida indicado para a maioria dos casos de uso.
• Deep (~3-6s): executa buscas paralelas em variações da consulta para cobertura máxima. Ideal para tarefas de pesquisa onde completude importa mais que velocidade.

Configuração em poucas linhas

Para usar a integração, são necessários Python 3.10 ou superior, uma conta AWS com acesso ao Amazon Bedrock e uma chave de API da Exa. A instalação dos pacotes é feita com:

pip install strands-agents strands-agents-tools

Com os pacotes instalados, o processo tem três passos. Primeiro, configure a chave de API da Exa como variável de ambiente:

export EXA_API_KEY="your_exa_api_key_here"

Depois, importe e registre as ferramentas no agente:

from strands import Agent
from strands_tools.exa import exa_search, exa_get_contents

agent = Agent(tools=[exa_search, exa_get_contents])

Com as ferramentas registradas, o agente já pode intercalar busca e extração de conteúdo naturalmente como parte do seu fluxo de raciocínio:

response = agent(
    "Search for the most recent trends in AI agents and provide a concise summary of key developments")

Exemplo prático: o assistente de pesquisa profunda

Para demonstrar como as duas ferramentas funcionam em conjunto, a AWS apresenta um assistente de pesquisa profunda que executa um fluxo de múltiplos passos. Dado um tema de pesquisa, o agente realiza quatro buscas direcionadas em diferentes tipos de fonte, extrai o conteúdo completo dos resultados mais promissores e sintetiza tudo em um relatório estruturado — tudo dentro de uma única invocação do agente, com múltiplas chamadas de ferramentas acontecendo no loop de raciocínio.

A configuração do agente usa o Claude Sonnet via Amazon Bedrock:

from strands import Agent
from strands.models.bedrock import BedrockModel
from strands_tools.exa import exa_search, exa_get_contents

def create_research_agent() -> Agent:
    model = BedrockModel(
        model_id="us.anthropic.claude-sonnet-4-6",
        region_name="us-west-2",
        max_tokens=20000,
    )
    return Agent(
        model=model,
        system_prompt=load_system_prompt(),
        tools=[exa_search, exa_get_contents],
    )

O fluxo de seis etapas

Um prompt de sistema define o fluxo de pesquisa, guiando o agente por seis etapas. Cada etapa instrui o agente a chamar as ferramentas da Exa com parâmetros diferentes, ajustados para o tipo de conteúdo buscado:

• Etapa 1 — Visão geral: uma varredura ampla usando o modo auto para construir entendimento fundacional sobre o tema, com até 5 resultados e resumos contextuais.
• Etapa 2 — Notícias recentes: foco em fontes de notícias com filtro de data para os últimos 30 dias, com limite de cache de 24 horas para garantir frescor.
• Etapa 3 — Artigos acadêmicos: busca na categoria research paper com extração estruturada via esquema JSON para capturar descobertas principais, metodologia e conclusões de cada artigo.
• Etapa 4 — Projetos no GitHub: implementações open source são encontradas pela categoria github, com destaque para os trechos mais relevantes do repositório.
• Etapa 5 — Mergulho profundo: o agente muda de descoberta para extração. As duas ou três URLs mais promissoras das etapas anteriores têm seu conteúdo completo recuperado com exa_get_contents, usando live crawling forçado (max_age_hours: 0) e rastreamento de subpáginas para referências, citações e metodologia.
• Etapa 6 — Síntese: nenhuma ferramenta é chamada. Tudo o que foi coletado nas etapas anteriores alimenta a geração de um relatório estruturado com sumário executivo, visão geral do tema, desenvolvimentos recentes, pesquisas-chave, ferramentas e implementações, e lista completa de fontes com URLs.

O design central do exemplo é que diferentes tipos de fonte requerem parâmetros diferentes — mas não ferramentas diferentes. As mesmas duas ferramentas da Exa são reutilizadas em todo o fluxo com configurações variadas a cada etapa.

Por que esse fluxo multi-etapas é superior a uma busca simples

• Respostas fundamentadas: cada afirmação no relatório final rastreia de volta a uma URL de origem, reduzindo alucinações.
• Uso eficiente de tokens: resumos gerados no momento da busca e extração mantêm o conteúdo conciso, para que o LLM trabalhe com conhecimento destilado em vez de dumps brutos de páginas.
• Profundidade autônoma: o agente itera entre tipos de fonte (notícias, artigos, repositórios de código, páginas completas) sem direcionamento humano, cobrindo um terreno que uma única busca não conseguiria.

Rastreabilidade com Amazon Bedrock AgentCore Observability

Um pipeline de seis etapas com múltiplas chamadas de ferramentas é difícil de depurar sem rastreamento estruturado. O Amazon Bedrock AgentCore Observability, construído sobre o OpenTelemetry, instrumenta toda a execução do agente com mudanças mínimas de código. Cada chamada de ferramenta e cada invocação de LLM se torna um span com relações pai-filho.

No dashboard de Observabilidade de IA Generativa (GenAI — Generative AI) do CloudWatch, cada execução de pesquisa aparece como um trace completo. É possível inspecionar parâmetros de chamada por invocação de exa_search ou exa_get_contents (verificando se o agente usou a categoria, intervalo de datas e limites de conteúdo corretos em cada etapa), latência por etapa e consumo de tokens por invocação de LLM.

Fluxos agenticos são não-determinísticos: a mesma consulta pode produzir resultados de busca diferentes, seleções de URL diferentes para o mergulho profundo e saídas de síntese diferentes. Os dados de trace transformam a depuração de adivinhação em inspeção.

Boas práticas para usar as ferramentas da Exa

A AWS destaca algumas recomendações para otimizar qualidade, latência e custo ao integrar as ferramentas da Exa em agentes. Para mais detalhes sobre tipos de busca, modos de conteúdo e filtragem avançada, a documentação de boas práticas da Exa é o recurso indicado:

• Comece com auto e ajuste conforme necessário: o modo auto funciona bem para a maioria das consultas. Mude para deep em tarefas de pesquisa onde perder uma fonte relevante tem custo alto, e para fast ou instant quando o agente faz muitas buscas sequenciais e a latência acumulada importa mais que a completude por consulta.
• Controle o tamanho do conteúdo para gerenciar o orçamento de tokens: defina maxCharacters no campo highlights (o padrão é 4.000 caracteres) para evitar que respostas muito longas consumam tokens desnecessariamente.

Limpeza de recursos

Este exemplo não cria nenhum recurso persistente na AWS. Se não precisar mais da chave de API da Exa, basta revogá-la pelo painel da Exa.

Conclusão

A combinação entre o Strands Agents SDK e a Exa oferece um caminho para construir agentes de IA fundamentados em informações web atuais e precisas. A busca semântica da Exa, o filtro por categoria, os resumos com esquemas JSON e o live crawling são expostos através de apenas duas ferramentas e algumas linhas de configuração.

Como o assistente de pesquisa profunda demonstra, é possível construir um agente multi-etapas que busca em notícias, artigos acadêmicos e repositórios de código, extrai conteúdo completo dos melhores resultados e sintetiza tudo em um relatório fundamentado — tudo guiado por um único prompt de sistema. O agente direciona tipos de fonte com filtros de categoria, controla recência com intervalos de data, formata saída com esquemas JSON e gerencia frescor com live crawling. O fluxo completo é rastreável pelo Amazon Bedrock AgentCore Observability, transformando comportamento não-determinístico em spans inspecionáveis e depuráveis.

O padrão vai além de pesquisa: inteligência competitiva, suporte técnico, análise de mercado e outros domínios onde agentes precisam de informações web em tempo real são casos de uso igualmente aplicáveis. Para começar, experimente o exemplo do assistente de pesquisa profunda com suas próprias perguntas, obtenha sua chave de API da Exa, explore a documentação do Amazon Bedrock e compartilhe seu feedback no repositório GitHub do Strands Agents.

Fonte

Building web search-enabled agents with Strands and Exa (https://aws.amazon.com/blogs/machine-learning/building-web-search-enabled-agents-with-strands-and-exa/)

O que é o Claude Platform on AWS

A AWS anunciou a disponibilidade geral do Claude Platform on AWS, um serviço que oferece acesso direto à plataforma nativa da Anthropic — a mesma experiência disponível quando se contrata o Claude diretamente — mas tudo operando pela conta AWS já existente do cliente. Nenhum contrato separado, nenhuma credencial adicional, nenhum relacionamento de cobrança paralelo.

Vale destacar: a AWS é o primeiro provedor de nuvem a disponibilizar esse acesso integrado à experiência nativa do Claude Platform.

O que está incluído na experiência nativa

Com o Claude Platform on AWS, as equipes têm acesso ao mesmo conjunto de APIs e funcionalidades disponíveis diretamente pela Anthropic. Isso inclui:

• Messages API
• Claude Managed Agents (beta)
• Advisor tool (beta)
• Web search e web fetch
• MCP connector (beta)
• Agent Skills (beta)
• Code execution
• Files API (beta)

Para a lista completa de capacidades, a Anthropic mantém a documentação oficial do Claude Platform.

Como funciona a integração com a AWS

A proposta central do serviço é eliminar a fricção operacional de gerenciar um relacionamento separado com a Anthropic. A integração se apoia em três pilares do ecossistema AWS:

• Autenticação: as equipes utilizam as próprias credenciais AWS IAM para acessar o Claude Platform. Sem contas extras ou chaves de API independentes para administrar.
• Faturamento: o consumo é cobrado pelo AWS Marketplace em modelo por uso (consumption basis), permitindo acompanhar os gastos com IA junto aos demais serviços AWS no mesmo painel.
• Auditoria: toda a atividade é registrada no AWS CloudTrail, possibilitando monitorar, auditar e investigar o uso de IA da mesma forma que qualquer outro serviço AWS.

Um ponto importante de arquitetura: o Claude Platform on AWS é operado pela Anthropic, e as requisições e dados são processados fora do perímetro de segurança da AWS. Isso o torna adequado para equipes que não possuem requisitos específicos de residência de dados por região. O serviço complementa os modelos Claude disponíveis no Amazon Bedrock — são abordagens distintas para cenários distintos.

Como começar: três passos até a primeira chamada de API

O Claude Platform on AWS pode ser ativado pelo AWS Marketplace. Para instruções detalhadas, a documentação oficial orienta sobre como configurar a conta. Após a ativação, o caminho até a primeira chamada de API envolve três etapas.

Passo 1: Criar um workspace

Um workspace permite separar projetos, ambientes ou times, mantendo cobrança e administração centralizadas. Ele também funciona como o recurso principal de Gerenciamento de Identidade e Acesso (IAM) da AWS para o Claude Platform on AWS. O acesso a workspaces específicos é concedido ou negado por meio de políticas IAM usando o ARN do workspace — a documentação de políticas IAM traz exemplos práticos.

O workspace é criado a partir do Claude Console, acessível dentro do Console do Claude Platform on AWS.

Passo 2: Autenticar

O serviço suporta dois métodos de autenticação: IAM com AWS Signature Version 4 e chaves de API. A recomendação é usar credenciais IAM temporárias para ambientes que exigem maior nível de segurança, e chaves de API para exploração e testes iniciais.

Após gerar uma chave de API no console, as variáveis de ambiente necessárias são configuradas assim:

# Your API key
export ANTHROPIC_API_KEY=<YOUR API KEY HERE>

# Your regional endpoint for Claude Platform on AWS
export ANTHROPIC_BASE_URL=https://aws-external-anthropic.<YOUR REGION HERE>.api.aws

# Your workspace ID (find in Claude Platform on AWS Console → Workspaces)
export ANTHROPIC_WORKSPACE_ID=<YOUR WORKSPACE ID HERE>

Passo 3: Fazer a primeira chamada de API

Com as variáveis configuradas, basta instalar os SDKs do cliente Anthropic e realizar chamadas de API:

from anthropic import Anthropic
import os

client = Anthropic(
    default_headers={"anthropic-workspace-id": os.environ["ANTHROPIC_WORKSPACE_ID"]},
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello!"}],
)

print(message)

A Anthropic disponibiliza notebooks de introdução com mais exemplos de código para quem quiser explorar além do básico.

Usando na prática com Claude Code e Claude Cowork

Com a configuração concluída, é possível apontar o Claude Code, o Claude Cowork ou qualquer outro cliente de API para o workspace usando as variáveis de ambiente ou configurações adequadas:

export ANTHROPIC_API_KEY=<YOUR API KEY HERE>
export ANTHROPIC_BASE_URL=https://aws-external-anthropic.<YOUR REGION HERE>.api.aws

# For Claude Cowork, set the "anthropic-workspace-id" in your inference configuration.
# For Claude Code use the following:
export ANTHROPIC_CUSTOM_HEADERS='{"anthropic-workspace-id":"<YOUR WORKSPACE ID HERE>"}'

# For the Anthropic SDK
export ANTHROPIC_WORKSPACE_ID=<YOUR WORKSPACE ID HERE>

Uma vez conectados, os clientes passam a contar com funcionalidades como busca na web, conectores MCP, agent skills, execução de código e upload de arquivos — tudo pelo Claude Platform on AWS.

Monitoramento, auditoria e custos

O uso pode ser acompanhado diretamente no Claude Console, com detalhamentos por workspace, principal IAM da AWS e período de tempo.

No ambiente AWS, o CloudTrail registra todas as requisições ao Claude Platform on AWS — sejam elas originadas do SDK da Anthropic, do Claude Code ou do Cowork. Operações de workspace são registradas como eventos de gerenciamento por padrão, e o registro de eventos de dados pode ser habilitado para capturar a atividade de inferência. Mais detalhes sobre tipos de eventos e configuração de logging estão disponíveis na documentação de monitoramento e logging.

Como o faturamento passa pelo AWS Marketplace, os custos aparecem no AWS Cost Explorer junto aos demais serviços de nuvem. A alocação de gastos por equipe ou projeto pode ser feita com resource tags.

Disponibilidade por região

O Claude Platform on AWS está disponível nas seguintes regiões: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), South America (São Paulo), Europe (Dublin), Europe (London), Europe (Frankfurt), Europe (Milan), Europe (Zurich), Europe (Paris), Europe (Stockholm), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Jakarta), Asia Pacific (Sydney) e Asia Pacific (Melbourne).

Conclusão

O Claude Platform on AWS representa uma integração relevante para equipes que já operam na AWS e querem adotar as APIs nativas da Anthropic sem abrir mão da governança, auditoria e faturamento centralizados que o ambiente AWS oferece. A combinação com o Amazon Bedrock — que permanece como opção para quem precisa de residência de dados por região — amplia as possibilidades de escolha conforme o perfil de cada organização.

Para começar, acesse o Console do Claude Platform on AWS ou explore a documentação.

Fonte

Introducing Claude Platform on AWS: Anthropic’s native platform, through your AWS account (https://aws.amazon.com/blogs/machine-learning/introducing-claude-platform-on-aws-anthropics-native-platform-through-your-aws-account/)

O problema que o texto sozinho não resolve

Se você trabalha com documentação técnica industrial — aeroespacial, automotiva, manufatura pesada — sabe bem como esses arquivos são: especificações escritas misturadas com desenhos de engenharia, diagramas CAD, fotografias de inspeção, gráficos de análise térmica e curvas de fadiga. O conteúdo relevante muitas vezes não está em nenhum parágrafo de texto. Está dentro de um gráfico de contorno térmico, numa tabela desenhada dentro de um desenho técnico, ou num fluxograma com anotações visuais.

Sistemas de recuperação de informação baseados apenas em texto tratam esses documentos extraindo o texto via Reconhecimento Óptico de Caracteres (OCR) e indexando as strings resultantes. Funciona razoavelmente quando a resposta está escrita em prosa, mas falha quando a informação está codificada visualmente — relações espaciais em diagramas, padrões em imagens de inspeção, valores quantitativos em gráficos e tabelas desenhadas.

É exatamente esse gap que o Amazon Nova Multimodal Embeddings se propõe a fechar, mapeando texto, imagens e páginas de documentos num mesmo espaço vetorial compartilhado. Uma consulta em texto pode recuperar um diagrama de engenharia, e uma consulta por imagem pode recuperar uma especificação escrita — porque ambas as modalidades compartilham o mesmo sistema de coordenadas vetoriais.

O que é o Amazon Nova Multimodal Embeddings

O Amazon Nova Multimodal Embeddings está disponível no Amazon Bedrock e gera embeddings para texto, imagens e documentos de múltiplas páginas. As três modalidades — texto, imagem e documento — são projetadas num único espaço vetorial compartilhado, o que permite calcular similaridade de cosseno diretamente entre um embedding de texto e um embedding de imagem.

O modelo oferece dimensões configuráveis: 256, 384, 1024 ou 3072. Dimensões maiores capturam mais detalhes semânticos, mas exigem mais armazenamento e processamento nas buscas por similaridade. No estudo publicado pela AWS, foram utilizadas 1024 dimensões como equilíbrio prático entre qualidade de recuperação e custo.

O modelo também suporta um nível de detalhe chamado DOCUMENT_IMAGE, um modo de processamento projetado para páginas com conteúdo misto — gráficos, tabelas e diagramas anotados. Para cargas de recuperação, o modelo aceita um parâmetro purpose configurado como GENERIC_INDEX (para documentos sendo indexados) ou GENERIC_RETRIEVAL (para consultas). Essa abordagem de embedding assimétrico melhora o espaço vetorial para recuperação sem exigir formatação manual das consultas.

Arquitetura da solução: dois pipelines em paralelo

Para demonstrar o valor da abordagem multimodal, a AWS construiu dois pipelines de recuperação paralelos sobre o mesmo conjunto de dados, comparando a qualidade de geração de respostas entre eles.

O conjunto de dados contém 15 imagens técnicas independentes (diagramas CAD, relatórios de inspeção, gráficos de teste, especificações de materiais, fluxogramas de processo) e cinco PDFs de múltiplas páginas (procedimentos de montagem, relatórios de teste a quente, avisos de mudança de engenharia, certificações de material e relatórios de não conformidade). Todos os documentos contêm dados sintéticos de manufatura aeroespacial.

• Pipeline A — Multimodal: cada imagem é embeddada diretamente e cada página de PDF é processada como imagem de documento usando o Amazon Nova Multimodal Embeddings, sendo então ingerida num índice do Amazon S3 Vectors.
• Pipeline B — Baseline somente texto: cada imagem e página de PDF é enviada ao Amazon Nova 2 Lite para extração de texto via OCR, o texto extraído é embeddado usando o Amazon Nova Multimodal Embeddings (entrada apenas de texto) e ingerido num índice separado no Amazon S3 Vectors.

Os documentos de origem percorrem dois caminhos paralelos: o Pipeline A embeda imagens diretamente com o Amazon Nova Multimodal Embeddings, enquanto o Pipeline B extrai texto via OCR antes de embeddar. Ambos armazenam vetores no Amazon S3 Vectors. No momento da consulta, o contexto recuperado alimenta o Amazon Nova 2 Lite para geração de respostas, e um juiz baseado em Modelo de Linguagem Grande (LLM) pontua cada resposta em relação ao gabarito.

A seguir, três documentos de exemplo do conjunto de dados: um diagrama CAD de montagem de bico, um relatório de inspeção de solda e uma curva de fadiga S-N do Inconel 718 — cada tipo apresentando informações difíceis de capturar apenas por extração de texto.

Implementação passo a passo

O código completo está disponível no notebook de referência no GitHub. Os pré-requisitos incluem uma conta AWS com acesso ao Amazon Bedrock na região us-east-1, acesso habilitado para os modelos amazon.nova-2-multimodal-embeddings-v1:0 e us.amazon.nova-2-lite-v1:0, e permissões de Gerenciamento de Identidade e Acesso (IAM) para as APIs do Amazon Bedrock InvokeModel, Amazon S3 e Amazon S3 Vectors.

Gerando embeddings multimodais

Gerar um embedding para uma imagem técnica requer uma única chamada InvokeModel ao Amazon Bedrock. A requisição especifica os bytes da imagem, a dimensão desejada do embedding e o nível de detalhe. Para imagens independentes como diagramas CAD, usa-se STANDARD_IMAGE. Para páginas de PDF com conteúdo misto, DOCUMENT_IMAGE produz resultados melhores:

import base64, json, boto3

bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0"

with open("dataset/nozzle_assembly_diagram.png", "rb") as f:
    b64_data = base64.b64encode(f.read()).decode("utf-8")

request_body = {
    "taskType": "SINGLE_EMBEDDING",
    "singleEmbeddingParams": {
        "embeddingPurpose": "GENERIC_INDEX",
        "embeddingDimension": 1024,
        "image": {
            "format": "png",
            "detailLevel": "STANDARD_IMAGE",
            "source": {"bytes": b64_data},
        },
    },
}

response = bedrock_runtime.invoke_model(
    modelId=MODEL_ID,
    body=json.dumps(request_body),
    accept="application/json",
    contentType="application/json",
)

embedding = json.loads(response["body"].read())["embeddings"][0]["embedding"]
print(f"Embedding dimension: {len(embedding)}")  # 1024

Construindo o índice no Amazon S3 Vectors

O Amazon S3 Vectors fornece uma camada gerenciada de armazenamento e consulta vetorial. É necessário criar um bucket de vetores e um índice configurado para similaridade de cosseno, depois ingerir os embeddings em lotes de 50:

s3vectors = boto3.client("s3vectors", region_name="us-east-1")

# Create vector bucket and index
s3vectors.create_vector_bucket(vectorBucketName="manufacturing-vectors")
s3vectors.create_index(
    vectorBucketName="manufacturing-vectors",
    indexName="manufacturing-multimodal",
    dataType="float32",
    dimension=1024,
    distanceMetric="cosine",
)

# Ingest a batch of embeddings with metadata
vectors = [
    {
        "key": "img-nozzle_assembly_diagram",
        "data": {"float32": embedding},
        "metadata": {
            "source_file": "nozzle_assembly_diagram.png",
            "type": "image",
        },
    }
]

s3vectors.put_vectors(
    vectorBucketName="manufacturing-vectors",
    indexName="manufacturing-multimodal",
    vectors=vectors,
)

Consultando o índice

No momento da consulta, gera-se um embedding de texto com o purpose GENERIC_RETRIEVAL e chama-se query_vectors para recuperar os documentos mais similares. O purpose GENERIC_RETRIEVAL instrui o modelo a otimizar o embedding para correspondência consulta-documento:

query = "What is the torque specification for the chamber flange bolts?"

request_body = {
    "taskType": "SINGLE_EMBEDDING",
    "singleEmbeddingParams": {
        "embeddingPurpose": "GENERIC_RETRIEVAL",
        "embeddingDimension": 1024,
        "text": {"truncationMode": "END", "value": query},
    },
}

response = bedrock_runtime.invoke_model(
    modelId=MODEL_ID,
    body=json.dumps(request_body),
    accept="application/json",
    contentType="application/json",
)

query_embedding = json.loads(response["body"].read())["embeddings"][0]["embedding"]

results = s3vectors.query_vectors(
    vectorBucketName="manufacturing-vectors",
    indexName="manufacturing-multimodal",
    queryVector={"float32": query_embedding},
    topK=5,
    returnDistance=True,
    returnMetadata=True,
)

for v in results["vectors"]:
    print(f" {v['key']} (distance: {v['distance']:.4f})")

Essa consulta recupera a imagem de especificações de torque e o diagrama de padrão de parafusos de flange como os principais resultados — ambos contêm a resposta. Um sistema baseado apenas em texto dependeria da extração OCR ter capturado corretamente os valores de torque do desenho técnico, o que nem sempre é confiável para diagramas técnicos complexos.

Metodologia de avaliação

A avaliação foi realizada em duas etapas: qualidade de recuperação (o sistema encontra os documentos corretos?) e qualidade de geração (um modelo de linguagem consegue produzir uma resposta correta a partir do contexto recuperado?).

Avaliação de recuperação

Para cada consulta, gera-se um embedding de texto com purpose GENERIC_RETRIEVAL, consulta-se o índice multimodal no S3 Vectors e comparam-se os documentos retornados com os IDs de documentos relevantes do gabarito. Três métricas são calculadas em K=3, 5 e 10:

• Recall@K: fração de documentos relevantes encontrados nos K primeiros resultados
• Média da Posição Recíproca (MRR): mede quão alto o primeiro resultado relevante aparece
• Ganho Cumulativo Descontado Normalizado (NDCG@K): dá mais crédito quando documentos relevantes aparecem mais alto na lista

Avaliação de geração com LLM-as-Judge

Para a avaliação de geração, ambos os pipelines recuperam os cinco principais resultados para cada consulta. O pipeline multimodal passa as imagens recuperadas diretamente ao Amazon Nova 2 Lite como contexto multimodal. O pipeline somente texto passa o texto extraído por OCR como contexto em string. Cada resposta gerada é pontuada em relação ao gabarito usando o Anthropic Claude Sonnet 4.5 como juiz LLM, numa escala de 1 a 5.

Resultados: a diferença é expressiva

Métricas de recuperação multimodal

O pipeline multimodal alcança 90% de recall em K=5, o que significa que ele encontra a maioria dos documentos relevantes dentro dos cinco primeiros resultados, subindo para 96% em K=10. Um MRR de 0,92 indica que o primeiro resultado relevante tipicamente aparece na posição 1. As duas consultas onde o recall fica abaixo de 1,0 em K=10 envolvem documentos com informação relevante dividida entre um PDF e uma imagem independente.

Qualidade de geração: texto vs. multimodal

Os resultados de geração mostram uma diferença muito significativa entre os dois pipelines:

Pipeline	Nota média do juiz	Normalizado (0–1)
Multimodal (MME)	4,88 / 5	0,977
Somente texto (OCR)	2,00 / 5	0,400

O pipeline multimodal obteve pontuação superior em 88% das consultas (23 de 26), com média de 4,88 de 5. O pipeline somente texto atingiu média 2,00, com 17 das 26 consultas recebendo nota 1 (completamente errado). Conteúdo visual como gráficos de contorno de análise térmica, curvas de fadiga, diagramas de fluxo de processo e rótulos de callout em CAD apresentaram as maiores melhorias.

Esses resultados demonstram que a qualidade da recuperação afeta diretamente a qualidade das respostas. Quando o sistema recupera os documentos corretos mas passa apenas o texto OCR ao gerador, perde a informação visual da qual a resposta depende. O pipeline multimodal evita essa conversão com perda de informação passando as imagens originais a um gerador multimodal.

Complexidade de implementação e custo

Além da acurácia, o pipeline multimodal é mais simples de construir e mais barato de operar. O pipeline somente texto exige duas chamadas de modelo por documento (uma para extração de texto OCR e outra para embedding de texto), além de engenharia de prompt para lidar com layouts variados de documentos. O pipeline multimodal requer uma única chamada de embedding por documento, sem etapa intermediária de extração — reduzindo tanto a complexidade de implementação quanto o custo de ingestão por documento em aproximadamente metade.

Limpeza de recursos

Para evitar custos contínuos, é recomendado deletar os índices e o bucket do S3 Vectors após concluir a avaliação. O notebook de referência no GitHub inclui os comandos de limpeza (comentados por segurança). O trecho abaixo mostra como deletar os índices e o bucket de vetores:

# Delete indexes
s3vectors.delete_index(vectorBucketName=S3_VECTOR_BUCKET, indexName=MME_INDEX)
s3vectors.delete_index(vectorBucketName=S3_VECTOR_BUCKET, indexName=TEXT_ONLY_INDEX)

# Delete vector bucket
s3vectors.delete_vector_bucket(vectorBucketName=S3_VECTOR_BUCKET)

A inferência de embedding no Amazon Bedrock é cobrada por requisição, sem infraestrutura persistente para gerenciar.

Conclusão

Embeddings multimodais fecham uma lacuna de recuperação que sistemas somente texto não conseguem endereçar em coleções de documentos com conteúdo visual significativo. No conjunto de dados de manufatura aeroespacial deste estudo, o pipeline multimodal alcançou 90% de recall em K=5 (96% em K=10) e qualidade de geração quase perfeita (4,88/5), enquanto o pipeline somente texto ficou em 2,00/5 porque o OCR não conseguiu capturar de forma confiável as informações de diagramas de engenharia, gráficos térmicos e fluxogramas de processo.

Com o Amazon Nova Multimodal Embeddings no Amazon Bedrock, essa capacidade pode ser construída sem gerenciar infraestrutura de modelos de embedding. O Amazon S3 Vectors fornece uma camada de armazenamento e consulta vetorial que não requer gerenciamento de cluster ou planejamento de capacidade. Para experimentar, basta clonar o código de exemplo no GitHub e executá-lo no Amazon SageMaker AI ou no ambiente local. O pipeline pode ser adaptado para documentos de manufatura próprios substituindo o conjunto de dados e as consultas de exemplo.

Recursos adicionais

• Documentação do Amazon Nova Multimodal Embeddings
• Busca crossmodal com Amazon Nova Multimodal Embeddings
• Relatório técnico do Amazon Nova Multimodal Embeddings
• Documentação do Amazon S3 Vectors

Fonte

Manufacturing intelligence with Amazon Nova Multimodal Embeddings (https://aws.amazon.com/blogs/machine-learning/manufacturing-intelligence-with-amazon-nova-multimodal-embeddings/)

Dados corporativos e IA: um problema de escala e confiança

Ambientes corporativos lidam com dezenas de milhões de linhas de dados, controles de acesso em nível de linha e coluna, e dezenas de datasets distribuídos por múltiplas áreas de negócio. Quando um executivo faz uma pergunta sobre esses dados, a resposta costuma demorar horas — ou dias. O gargalo raramente é a falta de dados; é a distância entre a pergunta e uma resposta confiável.

A AWS anunciou cinco novas capacidades do Amazon Quick que atacam exatamente esse problema. O objetivo é permitir que profissionais de dados entreguem insights baseados em IA com velocidade, precisão e governança — mesmo em ambientes de grande escala.

1. Dataset Q&A: converse diretamente com seus dados

Imagine que um VP de produto pergunta: “Como está evoluindo o churn neste produto?” Hoje, responder isso significa ou encontrar o dashboard certo (se ele existir para aquele recorte específico) ou esperar que um analista escreva e valide uma consulta. O tempo entre a pergunta e a resposta confiável é medido em horas ou dias.

O recurso Dataset Q&A reduz esse intervalo. O usuário conecta um ou mais datasets ao agente de chat — ou a um Quick Space com ativos mistos — e faz a pergunta em linguagem natural. O sistema gera SQL e executa a consulta sobre o dataset completo, com milhões de linhas e sem amostragem, retornando resultados em segundos.

Mas gerar SQL a partir de uma pergunta é a parte simples. O que torna o recurso robusto é o que acontece antes disso: o sistema resolve ambiguidades na própria pergunta (quando o usuário fala em “crescimento”, está falando de transações, clientes, receita ou unidades?), determina os campos, agregações e filtros corretos, e aplica as definições de negócio que os analistas forneceram via metadados do dataset.

A segurança também é preservada: as políticas de acesso em nível de linha e coluna já configuradas para dashboards são automaticamente aplicadas às consultas geradas por IA, sem nenhuma configuração adicional. O resultado é que o usuário vai da pergunta à resposta verificada sem abrir um ticket para o time de dados.

2. Explicações: verificando o raciocínio por trás da resposta

Velocidade é necessária, mas não suficiente. Em analytics corporativo, onde a precisão computacional importa, é preciso ver como a resposta foi construída. O recurso de explicações do chat exibe a cadeia completa de raciocínio: as ferramentas invocadas, o SQL gerado, os filtros aplicados, as suposições feitas e um resumo em linguagem simples para stakeholders não técnicos.

Para engenheiros de Business Intelligence (BI) e analistas de dados, isso funciona como um acelerador no ciclo de desenvolvimento. É possível fazer perguntas de referência, inspecionar o raciocínio, adicionar contexto e ajustar guardrails. O que antes levava semanas de testes iterativos passa a ser resolvido em sessões focadas.

Um exemplo concreto: o programa AWS Technical Field Communities usou o Dataset Q&A e melhorou a precisão das consultas em mais de 48%, reduzindo o tempo de resolução de 90 minutos para menos de 5 minutos entre mais de 15.000 membros. Você pode ler mais detalhes no post de lançamento do Dataset Q&A e no artigo Beyond BI: como o Dataset Q&A do Amazon Quick impulsiona a próxima geração de decisões baseadas em dados.

3. Enriquecimento semântico: ensinando IA a falar a língua do negócio

A precisão do Dataset Q&A depende diretamente de quanto o sistema entende o vocabulário do negócio. Uma coluna chamada revenue não diz nada sobre se o valor é bruto ou líquido, antes ou depois de devoluções, em regime de competência ou caixa. Uma coluna chamada active_customers não revela se o critério de atividade é de 12 ou 24 meses. Esse não é um problema de inteligência do modelo — é um problema de informação.

O recurso de Dataset Enrichment (Enriquecimento de Dataset) permite que os autores fechem essa lacuna sem precisar de configurações complexas. No nível do dataset, é possível fornecer uma descrição em linguagem simples do que os dados representam e instruções livres sobre como o sistema deve raciocinar. Por exemplo: “receita aqui é líquida após devoluções; para comparações ano a ano, use fiscal_year, não calendar_year”. Também é possível fazer upload de um arquivo de metadados de um catálogo de dados ou wiki interno.

No nível da coluna, os campos podem ser organizados em pastas lógicas, com descrições e anotações para casos de borda. O investimento é de minutos. O retorno é que, quando alguém faz uma pergunta, o Quick aplica as definições que o time já acordou. Para mais detalhes, consulte a documentação de Dataset Enrichment no Guia do Usuário do Amazon Quick.

4. Descoberta e orquestração: encontrando a fonte certa para cada pergunta

Enriquecer um único dataset resolve parte do problema. Em uma empresa típica, um usuário pode ter acesso a dezenas de datasets e dashboards cobrindo vendas, operações, finanças, RH e pesquisa de mercado. Para responder uma pergunta em linguagem natural, o sistema precisa identificar o ativo de dados correto e escolher a abordagem mais adequada. Errar em qualquer um desses pontos resulta em respostas irrelevantes ou incorretas, independentemente da capacidade do modelo.

O sistema agêntico do Quick possui uma camada semântica que busca entre os ativos estruturados — dashboards, datasets ou tópicos — para identificar a fonte correta antes de construir a consulta. Ele interpreta a intenção e o contexto da pergunta, indo além da correspondência simples de palavras-chave. Se um usuário pergunta sobre “escalações” mas o dashboard relevante usa o termo “tickets”, o sistema ainda consegue rotear para o ativo correto.

Para perguntas de múltiplas etapas — como “Como está evoluindo o churn e o que está causando isso na região Sudeste?” — o sistema identifica quais agentes e ferramentas especializadas acionar em cada etapa, planeja a sequência e monta uma resposta coerente a partir de múltiplas capacidades trabalhando em conjunto. Melhorias nessa camada de descoberta e orquestração resultam em menos erros de fonte, seleção de ferramentas mais precisa e maior confiança nas respostas — especialmente em perguntas ambíguas ou complexas que abrangem múltiplos domínios analíticos.

5. Geração de dashboards com IA: de dias para minutos

Dashboards operacionais ocupam um lugar único na tomada de decisão corporativa que ferramentas conversacionais não substituem. Um bom dashboard concentra indicadores antecedentes e consequentes, métricas organizadas por função e horizonte temporal, e controles de filtro em uma única superfície compartilhada. Essa densidade oferece a equipes com diferentes papéis e perguntas um ponto de alinhamento comum.

Construir um dashboard envolve selecionar as visualizações certas, organizar abas de forma lógica, criar campos calculados, adicionar controles de filtro e iterar sobre o layout — tarefas que consomem dias ou semanas de trabalho manual especializado. Boa parte desse esforço é mecânica depois que a intenção analítica está clara: o gargalo é a construção, não o raciocínio.

A geração de dashboards com IA elimina essa fase de construção. O autor seleciona até três datasets e descreve o que quer ver — as perguntas de negócio, as métricas e como quer que a informação seja organizada. Antes de qualquer construção, é possível revisar e editar um plano. O Amazon Quick então produz múltiplas abas organizadas com visualizações adequadas aos dados, controles de filtro para que stakeholders possam segmentar por diferentes dimensões, e campos calculados como crescimento ano a ano e comparações mês a mês.

O resultado é uma análise nativa do Amazon Quick — não uma imagem estática ou exportação pontual. Ela se integra aos fluxos de publicação existentes, padrões de embedding e pipelines de Integração e Entrega Contínuas (CI/CD). O autor pode refinar as visualizações após a geração, publicar como dashboard, compartilhar, incorporar ou agendar relatórios, exatamente como faria com um criado manualmente.

Durante o acesso antecipado, autores relataram redução de 90% ou mais no tempo de criação de dashboards. Saiba mais no post Gere dashboards a partir de prompts em linguagem natural no Amazon Quick.

6. Acesso a dados em tempo real: Direct Query em tabelas Apache Iceberg no S3

Todas as capacidades descritas acima dependem da qualidade dos dados sobre os quais operam. Empresas estão cada vez mais construindo seus ambientes de dados sobre formatos de tabela open source como o Apache Iceberg, por conta da performance, economia e flexibilidade que esses formatos oferecem. Mas havia uma desconexão persistente: para analisar esses dados em uma ferramenta de BI ou consultá-los via agente de IA, era necessário movê-los para uma camada OLAP intermediária. Cada salto adicionava latência, custo e mais um ponto onde a atualidade dos dados podia se degradar.

A AWS eliminou esse salto. O Amazon Quick agora pode se conectar diretamente a tabelas Apache Iceberg armazenadas em buckets S3 Table, sem necessidade de um motor intermediário. O data lake passa a ser a fonte diretamente pronta para analytics.

Os autores podem escolher entre o modo SPICE — para dashboards com alta concorrência e latência abaixo de um segundo — ou o modo Direct Query (Consulta Direta), para cenários onde a atualidade dos dados é mais importante. No modo Direct Query, tanto dashboards tradicionais quanto agentes de IA conversacionais leem dos mesmos dados ao vivo. É possível ver uma transação em um gráfico, métrica ou resposta de chat instantes após ela chegar ao bucket S3 Table via pipeline de streaming.

Para organizações adotando arquiteturas modernas centradas no data lake, isso representa uma simplificação significativa: uma única camada de dados governada servindo tanto consumidores humanos quanto de IA, sem replicação ou orquestração adicional.

Construído para as pessoas que constroem analytics

Essas capacidades removem trabalho repetitivo do fluxo de analytics sem remover as pessoas que fornecem julgamento, governança e expertise de domínio. O analista de negócio ainda decide como o churn deve ser calculado. O engenheiro de dados ainda governa quem pode acessar o quê. O analista ainda cuida da experiência para seus stakeholders.

O que muda é o esforço necessário para transformar expertise em analytics confiável e em escala. Onde antes levava dias construir um dashboard, agora leva minutos. Onde verificar uma resposta de IA exigia reexecutar consultas manualmente, agora requer uma seleção. Onde importar contexto de negócio significava configuração elaborada de tópicos, agora basta um upload de arquivo.

Todas essas capacidades estão disponíveis hoje em todas as regiões AWS onde o Amazon Quick está disponível.

Fonte

Amazon Quick: Accelerating the path from enterprise data to AI-powered decisions (https://aws.amazon.com/blogs/machine-learning/amazon-quick-accelerating-the-path-from-enterprise-data-to-ai-powered-decisions/)