AWS conectou 3 agentes de IA para verificar substituicoes de componentes aeronauticos

Quando uma peca necessaria e descontinuada, nao basta encontrar um componente com nome parecido. O engenheiro precisa recuperar as especificacoes; comparar tensao, peso, interfaces e faixa de temperatura; verificar a geometria do involucro; descobrir o prazo de entrega; e reunir tudo isso em um documento para revisao. Na aviacao, um erro nesse processo pode custar muito mais do que varios dias de trabalho manual.

A AWS apresentou o prototipo de um assistente que divide essa tarefa entre tres agentes especializados. Um busca pecas adequadas, o segundo verifica tolerancias tecnicas e o terceiro trabalha com a documentacao e com informacoes atualizadas sobre o ciclo de vida dos componentes. Ha um limite importante: o sistema coleta evidencias e prepara um rascunho da avaliacao, mas nao autoriza a substituicao. A palavra final continua sendo do engenheiro.

Como uma solicitacao percorre o sistema

Imagine que uma roda de reacao para um satelite tenha ficado indisponivel. Um engenheiro pede ao sistema que verifique o risco de o modelo ser descontinuado, encontre alternativas e as compare com a peca original.

Primeiro, um pequeno componente de planejamento determina a sequencia de acoes. O agente de catalogo procura candidatos no banco de dados de pecas. O agente de avaliacao compara suas especificacoes. O agente de conhecimento recupera informacoes de descricoes tecnicas, desenhos e fontes da web. Se varios especialistas tiverem trabalhado na solicitacao, um modelo separado combina os resultados em uma unica resposta.

Essa separacao nao e util apenas do ponto de vista organizacional. Cada agente tem acesso somente as ferramentas necessarias. O agente de busca nao pode alterar os resultados da avaliacao, enquanto o agente de avaliacao nao realiza buscas abertas por fornecedores. Isso reduz o numero de acoes inesperadas e simplifica a auditoria.

Onde os modelos nao sao encarregados dos calculos

A parte mais robusta da solucao e que as verificacoes de tolerancia sao executadas por codigo Python convencional. Para cada categoria de componentes, os parametros e as regras criticas sao definidos com antecedencia: correspondencia exata da tensao, aumento de peso permitido, compatibilidade da interface e outras restricoes.

Com os mesmos dados de entrada, a verificacao sempre produz o mesmo resultado. Um modelo de linguagem pode explicar a tabela e formatar um memorando, mas nao tem permissao para alterar um status como “aprovado”, “violacao” ou “revisao necessaria”. Depois de cada avaliacao, o sistema salva um registro de acoes, permitindo que o revisor veja nao apenas a conclusao, mas tambem o caminho percorrido ate ela.

Esse e um bom padrao para qualquer processo de alta responsabilidade. O modelo atua onde sao necessarios busca, analise de documentos e texto coerente. O codigo responde pelas regras que precisam ser reproduzidas sem interpretacao criativa.

Por que a busca multimodal e necessaria

Parte dos dados de engenharia nao esta em tabelas. O torque pode aparecer apenas em um grafico, a posicao de um conector em uma fotografia e as dimensoes de montagem em um desenho. O Amazon Nova Multimodal Embeddings coloca texto e imagens em um espaco de busca compartilhado. Assim, uma consulta sobre uma especificacao pode retornar o diagrama necessario, enquanto uma imagem enviada pode localizar uma peca semelhante.

Fotografias de dois componentes tambem sao comparadas por similaridade de cosseno, depois da qual o modelo descreve diferencas visiveis nos elementos de fixacao, conectores e formato do involucro. No entanto, a semelhanca visual continua sendo apenas uma evidencia auxiliar. O resultado da verificacao e determinado pelos requisitos de engenharia definidos previamente.

As limitacoes da abordagem sao evidentes. As regras de tolerancia precisam ser mantidas manualmente, a qualidade da resposta depende da completude do banco de dados e a busca na web nao substitui a confirmacao do fabricante. A demonstracao usa apenas sete pecas ficticias e, portanto, comprova a ideia arquitetural, nao a prontidao para uma certificacao real.

A conclusao pratica para desenvolvedores e simples: nao criem um unico agente onisciente. Separem a busca, os calculos e a preparacao do documento; transfiram as verificacoes criticas para codigo deterministico; preservem as fontes e o registro de acoes; e deixem as decisoes com consequencias para uma pessoa. E exatamente esse limite que transforma uma demonstracao impressionante de agentes em uma ferramenta que pode ser discutida seriamente com engenheiros e auditores.