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)}") # 1024Construindo 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/)
Leave a Reply