Inteligência de Engenharia com Agentes: Amazon Nova Multimodal Embeddings e Amazon Bedrock AgentCore

O problema: substituição de peças críticas em engenharia aeroespacial

Quando uma peça aeroespacial qualificada fica obsoleta ou entra em situação de longo prazo de entrega, um engenheiro pode passar dias cruzando especificações entre fichas técnicas de fornecedores, Documentos de Controle de Interface (ICD, na sigla em inglês) e registros de qualificação — tudo isso antes de redigir uma justificativa formal para revisão. Uma substituição incorreta em um componente crítico de voo pode causar falha de missão, mas o rastro de evidências por trás de cada decisão costuma estar espalhado em e-mails e conhecimento institucional não documentado.

Um post anterior da AWS, Manufacturing intelligence with Amazon Nova Multimodal Embeddings, mostrou como o modelo recupera respostas “presas” dentro de diagramas de engenharia, gráficos térmicos e tabelas de fichas técnicas que pipelines puramente textuais não conseguem acessar. O novo post avança sobre esse trabalho e coloca essas capacidades dentro de um sistema multi-agente que monta a evidência de substituição — da recuperação até um rascunho de avaliação.

Visão geral da solução

A AWS demonstra como construir um assistente de engenharia multi-agente que reduz o cruzamento manual de informações na avaliação de substituição de peças, usando Amazon Bedrock AgentCore, Amazon Nova Multimodal Embeddings e o Strands Agents SDK de código aberto.

A solução é construída em torno de uma regra de design central: o engenheiro toma todas as decisões, e o sistema monta as evidências para ele. Essa regra determina onde se usam Modelos de Linguagem de Grande Escala (LLMs) e onde se usa código determinístico. Três pilares definem a arquitetura:

Avaliação determinística de especificações — Código Python com regras de tolerância pontua cada peça candidata em relação à peça de referência e aos requisitos declarados pelo engenheiro. Como as mesmas entradas produzem consistentemente os mesmos veredictos, os resultados podem ser incluídos em uma revisão de engenharia formal.
Orquestração multi-agente — Um planejador leve roteia cada consulta para um ou mais dos três agentes especialistas (Catálogo, Avaliação, Conhecimento), e um supervisor sintetiza os resultados apenas quando mais de um especialista contribuiu.
Decisão humana no ciclo — O sistema elabora memorandos de justificativa e Avaliações de Impacto de Integração (IIA) para revisão de engenharia, mas não recomenda nem aprova uma substituição. Cada avaliação também gera uma entrada de trilha de auditoria alinhada com as seções 8.4 e 8.5.6 da norma AS9100.

As requisições de chat do engenheiro fluem para um grafo multi-agente hospedado no AgentCore Runtime: um planejador (Claude Haiku 5.5) produz um plano de roteamento, especialistas (Claude Sonnet 5.5) executam suas ferramentas, e um supervisor (Claude Opus 5.5) sintetiza os resultados quando mais de um especialista é acionado. Os especialistas recuperam informações de uma base de conhecimento gerenciada criada com Amazon Bedrock Managed Knowledge Bases usando Amazon Nova Multimodal Embeddings, roteada por um AgentCore Gateway.

Estrutura do corpus de peças

O conjunto de dados de exemplo é composto por sete rodas de reação de um fabricante fictício (AnyCompany), cobrindo de 0,003 a 5,0 Nms de armazenamento de momento. Cada peça é uma pasta que combina dados estruturados com os documentos de origem que um engenheiro realmente lê — e essa mistura é o que torna o corpus multimodal.

O arquivo specs.json contém os campos legíveis por máquina que alimentam a pontuação determinística, enquanto o ICD, a foto do produto e a página do datasheet carregam detalhes visuais e narrativos que os campos estruturados não capturam. O Amazon Nova Multimodal Embeddings incorpora ambos no mesmo espaço vetorial que o texto, permitindo que uma consulta corresponda a um valor de especificação, um parágrafo ou um gráfico.

data/synthetic-parts-data/rw_rl_0060/
├── specs.json # structured specs + lifecycle fields
├── description.txt # flat text for text retrieval
├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf
├── datasheet_page.png # rendered datasheet page
├── datasheet_chart.png # cropped chart region (image-as-query index)
└── photo.png # product image (visual similarity + chart matching)

Agentes especialistas com ferramentas delimitadas

Cada especialista é um agente Strands com um prompt restrito e apenas as ferramentas de que precisa. Delimitar as ferramentas por especialista mantém o comportamento previsível: o especialista de Conhecimento não tem acesso às ferramentas de descoberta de catálogo, e o especialista de Catálogo não tem acesso às ferramentas de avaliação. Os três especialistas são:

Catálogo — Descobre peças por busca na base de conhecimento e filtragem de especificações (kb_search, filter_parts_by_spec, get_part_specs, get_substitution_requirements).
Avaliação — Pontua candidatos deterministicamente e compara peças visualmente (score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo).
Conhecimento — Responde perguntas de fichas técnicas e ICDs, verifica status de fim de vida em tempo real e recupera conteúdo visual (get_part_specs, web_search_eol, retrieve_visual_content).

Modelo pequeno para roteamento, modelo grande para síntese

Roteamento é uma tarefa de classificação sem chamadas de ferramentas, então não precisa de um modelo de raciocínio pesado. Um planejador baseado em Haiku retorna um plano de roteamento numerado em alguns segundos. O supervisor Opus só é acionado quando dois ou mais especialistas contribuíram, porque sintetizar a resposta já completa de um único especialista adiciona cerca de 8 segundos de latência sem ganho de qualidade.

# Step 1: Planner (fast model) plans the routing (may be multi-step).
plan_response = planner(planning_prompt)
ordered_specialists = _parse_specialist_plan(str(plan_response))

# Step 2: Execute specialists in sequence, passing context forward
accumulated_context = ""
for spec_name in ordered_specialists:
    specialist = specialists[spec_name]
    specialist_response = specialist(spec_prompt)
    accumulated_context += f"\n[{spec_name.upper()}]: {specialist_response}\n"

# Step 3: Synthesize only when 2+ specialists ran.
if len(ordered_specialists) == 1:
    final_text = steps[0]["response"]
else:
    final_text = str(supervisor(synthesis_prompt))

Pontuação determinística de especificações

A avaliação de adequação de especificação roda como código Python comum contra um esquema de requisitos escrito à mão. O esquema define as especificações críticas e as regras de tolerância para cada categoria de componente, e a ferramenta score_substitution_fit compara cada especificação, conta aprovações e sinalizações, e expõe riscos de ciclo de vida. Como o veredicto precisa ser reproduzível para um pacote de revisão de engenharia, nenhum LLM está envolvido nessa etapa. A ferramenta retorna um veredicto estruturado com um aviso explícito de que os resultados são apenas evidências — a decisão é sempre do engenheiro.

Similaridade visual com Amazon Nova Multimodal Embeddings

O formato físico importa quando uma peça substituta precisa caber em um suporte existente. A ferramenta visual_similarity_score incorpora as fotos de ambas as peças com o Nova Multimodal Embeddings e calcula a similaridade por cosseno, depois pede ao Claude para descrever as diferenças físicas observáveis específicas.

def embed_image(image_bytes):
    """Embed one image with Nova MME (IMAGE_RETRIEVAL) -> 1024-d vector."""
    b64 = base64.b64encode(image_bytes).decode('utf-8')
    fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg'
    body = {
        'taskType': 'SINGLE_EMBEDDING',
        'singleEmbeddingParams': {
            'embeddingPurpose': 'IMAGE_RETRIEVAL',
            'embeddingDimension': 1024,
            'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt, 'source': {'bytes': b64}},
        },
    }
    resp = bedrock.invoke_model(
        modelId='amazon.nova-2-multimodal-embeddings-v1:0',
        body=json.dumps(body),
        accept='application/json',
        contentType='application/json',
    )
    result = json.loads(resp['body'].read())
    return np.array(result['embeddings'][0]['embedding'])

# cosine similarity of the two photo embeddings
emb_a, emb_b = embed_image(photo_a_bytes), embed_image(photo_b_bytes)
similarity = float(np.dot(emb_a, emb_b) / (np.linalg.norm(emb_a) * np.linalg.norm(emb_b)))

A similaridade de embedding retorna cerca de 0,84 para duas rodas da mesma família de produtos e 0,40 para rodas de classes diferentes. A análise de visão do Claude então explica o que impulsiona a diferença — por exemplo, notando que um alojamento tem aproximadamente o dobro do diâmetro do outro e possui um padrão de montagem de seis furos onde o outro tem quatro.

Dois caminhos de recuperação: texto e imagem como consulta

Consultas de texto e documentos passam pela base de conhecimento gerenciada com suporte do Nova Multimodal Embeddings, roteada pelo AgentCore Gateway. Consultas por imagem (enviar um gráfico ou foto para encontrar conteúdo correspondente) usam um índice nativo do Amazon S3 Vectors chamado diretamente do agente, pois a API de recuperação da base de conhecimento gerenciada não aceita imagem como entrada.

A AWS destaca três lições práticas aprendidas durante a construção dos caminhos de recuperação:

Recortar os gráficos antes de indexá-los — Páginas inteiras de datasheet são entradas ruins para o índice, pois cerca de 90% de uma página (cabeçalho, tabela de especificações, rodapé) é padrão repetido em todas as peças. Nos testes, a correspondência por upload de gráfico foi de 3 em 7 peças corretas com indexação de página inteira para 7 em 7 com recortes de faixas de gráfico.
Filtrar resultados quando o engenheiro nomeia uma peça — A similaridade texto-para-imagem sozinha não retorna de forma confiável o gráfico da peça certa, pois uma imagem de curva de torque não contém nome de peça visível. Quando o engenheiro nomeia uma peça específica, a ferramenta mantém apenas resultados do conteúdo indexado daquela peça.
Registrar cada fallback no caminho de imagem — O caminho de imagem retorna None em erros e recai para recuperação textual. Isso significa que uma permissão s3vectors:QueryVectors ausente na função de execução do runtime do AgentCore não gera um erro — a consulta por imagem simplesmente para de funcionar silenciosamente. A ferramenta agora registra um aviso explícito de falha sempre que esse caminho recai.

Documentos formais com cadeia fixa de especialistas

O chat usa roteamento dinâmico porque os especialistas certos para uma pergunta livre não podem ser conhecidos de antemão. A Avaliação de Impacto de Integração (IIA) funciona de forma diferente: quando um engenheiro solicita uma avaliação de impacto para um par de referência e candidato, a sequência necessária já é conhecida, então o serviço compõe as mesmas funções de fábrica de especialistas em uma ordem fixa com um prompt de síntese específico.

# 1. Knowledge Specialist --- ICD/datasheet interface detail for both parts
knowledge_text = str(knowledge(knowledge_prompt))

# 2. Evaluation Specialist --- structured field delta + qualification check
evaluation_text = str(evaluation(evaluation_prompt))

# Deterministic structured delta for exact summary stats
comparison = compare_parts(reference_id, candidate_id)

# 3. Supervisor --- synthesize into the six-section IIA document
markdown = str(supervisor(synthesis_prompt))

Dados de ciclo de vida em tempo real via AgentCore Gateway

Dados de catálogo ficam desatualizados, então a ferramenta web_search_eol do especialista de Conhecimento verifica avisos atuais de fim de vida, anúncios de fornecedores e prazos de entrega por meio de um AgentCore Gateway com o conector de Busca na Web. O Gateway expõe o conector como um endpoint governado pelo Protocolo de Contexto de Modelo (MCP). Como o Gateway também lida com recuperação da base de conhecimento gerenciada, é possível anexar políticas e observabilidade tanto ao acesso a dados externos quanto internos em um único lugar.

Deploy no AgentCore Runtime

Para produção, o agente é empacotado como um contêiner ARM64, enviado para o Registro de Contêiner Elástico da Amazon (Amazon ECR) e o AgentCore Runtime o hospeda de forma serverless com isolamento de sessão e escalonamento automático. O Notebook 03 no repositório GitHub detalha esse deploy como receita de referência.

export TAG=mei-$(date +%Y%m%d-%H%M%S)
export ACCOUNT=
export ECR=${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com/mfg-engineering-intelligence

# Build the container for ARM64 (required by AgentCore Runtime)
docker buildx build --platform linux/arm64 -f agentcore/Dockerfile \
  -t mfg-engineering-intelligence:${TAG} --load .

# Push the immutable tag to Amazon ECR
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com
docker tag mfg-engineering-intelligence:${TAG} ${ECR}:${TAG}
docker push ${ECR}:${TAG}

Um ponto importante: sempre use tags imutáveis para as imagens. Um runtime que já resolveu o digest por trás de uma tag :latest em movimento continua servindo a imagem antiga depois que uma nova é enviada. Mudanças em prompts, roteador e ferramentas exigem uma nova imagem e uma nova versão do runtime para entrar em vigor.

O Amazon Nova Multimodal Embeddings agora está disponível no AWS GovCloud (EUA), o que é relevante para programas aeroespaciais e de defesa sujeitos a requisitos de residência de dados, ITAR e FedRAMP. Verifique a disponibilidade de serviços AWS por região antes de planejar um deploy.

Avaliando o assistente com AgentCore Evaluations

A AWS mede a qualidade de duas formas: pontuação online contínua pelo Amazon Bedrock AgentCore Evaluations, disponível de forma geral desde março de 2026, e validação offline contra conjuntos de consultas curados. O serviço lê os rastreamentos OpenTelemetry que os agentes Strands já emitem, então um agente instrumentado não precisa de alterações na aplicação para ser avaliado.

O conjunto de consultas curado tem 36 consultas em seis categorias: descoberta de catálogo (8), recuperação de Conhecimento e ICD (8), cadeias multi-especialistas (6), avaliação determinística (5), recuperação texto-para-visual (5) e recusas de segurança com humano no ciclo (4) — que verificam se o agente se recusa a recomendar ou aprovar.

Os resultados de um snapshot do conjunto de dados sintético mostram:

Taxa de Sucesso de Objetivo (sessão): 0,892
Correção (trace): 0,968
Utilidade (trace): 0,956
Fidelidade (trace): 0,981
Relevância da Resposta (trace): 0,968
Precisão de Seleção de Ferramenta (chamada de ferramenta): 0,861
Precisão de Parâmetros de Ferramenta (chamada de ferramenta): 0,980

Todas as métricas de qualidade em nível de trace ficaram em 0,95 ou acima. A Taxa de Sucesso de Objetivo é menor (0,892) porque o conjunto de consultas inclui prompts de segurança que pedem ao agente para recomendar ou aprovar uma substituição — o agente corretamente se recusa, mas o avaliador pontua uma recusa correta como um objetivo não atingido. Esse é o comportamento esperado em um sistema com humano no ciclo.

Adaptando o padrão para outros catálogos

O código é um padrão reutilizável que funciona para outras categorias de peças além de rodas de reação. Trocar de domínio requer apenas três mudanças: substituir os dados das peças (um specs.json, descrição, ICD, página de datasheet e foto por peça), editar o esquema de requisitos para definir as especificações críticas e regras de tolerância da sua categoria, e apontar a base de conhecimento para o seu corpus no S3. Os agentes, ferramentas e motor de pontuação permanecem inalterados.

Limpeza de recursos

Para evitar cobranças contínuas, a AWS recomenda excluir os recursos criados:

Exclua o agente de runtime do AgentCore e seu repositório Amazon ECR.
Exclua o AgentCore Gateway e seus alvos de Busca na Web e base de conhecimento.
Exclua a configuração de avaliação online e os alarmes do CloudWatch criados.
Exclua a base de conhecimento gerenciada e o índice S3 Vectors.
Exclua o bucket S3 que contém o corpus de peças.

Conclusão

A AWS demonstra com esse artigo como construir um assistente de engenharia multi-agente que substitui a pesquisa manual de substituição de peças por montagem automatizada de evidências. A arquitetura combina o Amazon Nova Multimodal Embeddings — que lida com pontuação de similaridade visual e recuperação de gráficos que sistemas puramente textuais não conseguem — com o Amazon Bedrock AgentCore, que fornece o andaime de produção: hospedagem de runtime, recuperação e busca na web governadas pelo Gateway, e avaliações de qualidade.

Três escolhas de design são fundamentais: código determinístico produz cada veredicto de aprovação/reprovação; cada tarefa roda no menor dos três níveis de modelo que a executa bem; e apenas o engenheiro pode aprovar uma substituição.

Para começar, clone o repositório GitHub, execute os notebooks com sua própria conta AWS e substitua pelo seu catálogo de peças e esquema de requisitos. Para se aprofundar nas bases de recuperação, leia Manufacturing intelligence with Amazon Nova Multimodal Embeddings e A practical guide to Amazon Nova Multimodal Embeddings. Para padrões de agentes em produção, consulte a documentação do Amazon Bedrock AgentCore e o Strands Agents SDK.

Fonte

Agentic engineering intelligence with Amazon Nova Multimodal Embeddings and Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/agentic-engineering-intelligence-with-amazon-nova-multimodal-embeddings-and-amazon-bedrock-agentcore/)