Author: Make.com Service User

Validação de Quotas no SageMaker HyperPod

A AWS anunciou uma melhoria significativa no console do SageMaker HyperPod: a plataforma agora valida automaticamente as quotas de serviço da sua conta antes de iniciar o processo de criação de clusters. Essa validação prévia permite que você confirme a disponibilidade suficiente de recursos antes que o provisionamento realmente comece, evitando falhas desnecessárias e economizando tempo.

O Desafio de Provisionar Clusters de IA/ML em Larga Escala

O SageMaker HyperPod é o serviço da AWS projetado para provisionar clusters resilientes destinados à execução de cargas de trabalho de IA e Aprendizado de Máquina (IA/ML), incluindo o desenvolvimento de modelos de ponta como Modelos de Linguagem Grande (LLMs), modelos de difusão e modelos de fundação (FMs).

Quando você cria clusters de IA/ML em larga escala, é essencial garantir que sua conta possua quotas suficientes para instâncias, armazenamento e recursos de rede. Anteriormente, essa validação de quotas exigia verificações manuais em vários serviços da AWS, o que frequentemente resultava em tentativas de criação de cluster falharem e consumiam tempo significativo caso você não solicitasse aumentos de limites de quotas com antecedência.

Como a Validação Automática Funciona

A nova capacidade de validação de quotas no console do SageMaker HyperPod verifica automaticamente as quotas em nível de conta contra a configuração do seu cluster. Esse processo inclui a validação de:

• Limites de tipo de instância
• Tamanhos de volume do EBS (Elastic Block Store)
• Quotas relacionadas à VPC (Virtual Private Cloud)

O resultado da validação é apresentado em uma tabela clara que exibe a utilização esperada, os valores de quota aplicados e o status de conformidade para cada quota. Quando há risco de exceder alguma quota, você recebe um alerta de aviso com links diretos para o console de Quotas de Serviço, facilitando a solicitação de aumentos quando necessário.

Disponibilidade e Próximos Passos

Esse recurso está disponível em todas as regiões da AWS que oferecem suporte ao Amazon SageMaker HyperPod. Para consultar a lista completa das verificações de validação de quota executadas, consulte a documentação técnica do SageMaker HyperPod.

Fonte

Amazon SageMaker HyperPod now validates service quotas before creating clusters on console (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-sagemaker-hyperpod-validates-service-quotas/)

Nova Funcionalidade de Sensibilidade Configurável

A AWS expandiu as capacidades do Amazon Lex com a introdução de três níveis de sensibilidade para detecção de atividade de voz (VAD — Voice Activity Detection). Essa adição permite que os desenvolvedores personalizem o comportamento dos bots de conversação de acordo com as características acústicas do ambiente onde serão deployados.

A detecção de atividade de voz é um componente essencial em sistemas de conversação por voz. Ela funciona identificando quando um usuário começa e termina de falar, filtrando ruídos de fundo e garantindo que o bot processe apenas as falas reais. Com a nova funcionalidade, essa detecção pode ser ajustada de maneira mais granular.

Os Três Níveis de Sensibilidade

Padrão (Default)

O modo Padrão é recomendado para a maioria dos cenários. Ele foi calibrado para ambientes com níveis típicos de ruído de fundo, equilibrando sensibilidade e precisão sem requerir configurações especiais. Para empresas iniciando com bots conversacionais, este é o ponto de partida mais seguro.

Alta (High)

O nível Alto foi projetado para espaços com ruído consistente e moderado — escritórios movimentados, áreas de varejo ou lojas são exemplos típicos. Este modo oferece maior tolerância ao ruído mantendo a capacidade de capturar intenções de fala claras, sendo útil em ambientes corporativos ou comerciais dinâmicos.

Máxima (Maximum)

O nível Máximo fornece a maior tolerância a ruído ambiental e é indicado para cenários de alta perturbação sonora — pisos de manufatura, canteiros de obra, ou ambientes externos com ruído significativo. Este é o modo mais robusto para situações desafiadoras acusticamente.

Como Configurar

A configuração da sensibilidade do VAD é realizada diretamente no designer de IA Conversacional do Amazon Connect. Os desenvolvedores podem estabelecer o nível de sensibilidade ao criar uma nova localidade de bot ou ao atualizar uma localidade existente, oferecendo flexibilidade para ajustes contínuos conforme o bot é refinado em produção.

Disponibilidade

Este recurso está disponível em todas as regiões comerciais da AWS onde o Amazon Connect e o Lex operam. Para mais detalhes técnicos sobre implementação e boas práticas, consulte a documentação do Amazon Lex. Você também pode explorar o site do Amazon Connect para entender como estas duas soluções trabalham em conjunto na criação de experiências de autoatendimento para clientes finais.

Fonte

Amazon Lex launches configurable voice activity detection sensitivity (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-lex-configurable-voice-activity-detection-sensitivity/)

O Desafio da Inferência em Larga Escala

Modelos de linguagem estão crescendo em escala de forma exponencial. Em 2023, o Falcon 180B era o maior modelo de código aberto disponível. Menos de um ano depois, a Meta lançou o Llama 3.1, um modelo denso com 405 bilhões de parâmetros. No meio de 2025, o DeepSeek V3 superou ambos, com 671 bilhões de parâmetros no total, dos quais 37 bilhões são ativos por token.

Esses gigantescos modelos entregam desempenho excepcional em tarefas variadas—desde busca multimodal e geração de código até raciocínio de nível PhD. Porém, implantá-los em produção permanece impraticável para a maioria das organizações. O problema não é apenas técnico, mas financeiro: modelos com mais de 100 bilhões de parâmetros demandam GPUs de alto desempenho, enorme largura de banda de memória e consumo substancial de energia. Escalar para milhares de usuários simultaneamente se torna economicamente insustentável.

Quantização Pós-Treinamento: Uma Solução Prática

A quantização pós-treinamento (PTQ) oferece um caminho viável. Convertendo pesos e ativações de 16 ou 32 bits para inteiros de 8 ou 4 bits após o treinamento, a PTQ consegue reduzir o tamanho do modelo em 2 a 8 vezes, diminuir os requisitos de largura de banda de memória e acelerar operações matriciais—tudo sem necessidade de retreinamento.

Um exemplo prático: o modelo DeepSeek-V3 base requer uma instância ml.p5e.48xlarge (com 1128 GB de memória GPU H100) para inferência. Sua variante quantizada pode rodar em instâncias menores como ml.p5.48xlarge (640 GB de H100) ou até ml.p4de.24xlarge (640 GB de A100). Essa eficiência é alcançada aplicando quantização de baixa precisão aos canais de peso menos influentes, mantendo em precisão total aqueles que mais impactam as respostas de ativação.

Modelos quantizados existem graças às contribuições de comunidades de desenvolvedores. Projetos como Unsloth AI e QuixiAI investem tempo e recursos significativos em otimizações. Esses modelos podem ser implantados perfeitamente no Amazon SageMaker AI com apenas algumas linhas de código.

Entendendo Pesos e Ativações

Em redes neurais, pesos são parâmetros estáticos aprendidos durante o treinamento—os coeficientes fixos que moldam como entradas se combinam. Ativações, por sua vez, são valores dinâmicos produzidos em cada camada quando dados passam pela rede, representando a resposta de cada neurônio.

A notação W_xA_y descreve a precisão de ambos: W_x é a largura em bits dos pesos (4-bit ou 8-bit, por exemplo) e A_y é a largura em bits das ativações (8-bit ou 16-bit). W4A16, por exemplo, significa pesos armazenados como inteiros de 4 bits enquanto ativações permanecem em ponto flutuante de 16 bits.

W4A16 Simétrico e Assimétrico

Quantização simétrica de 4 bits centra o intervalo ao redor de zero. Com apenas 16 níveis de quantização, o modelo fica propenso a erro se a distribuição de pesos não for perfeitamente centrada em zero. Quantização assimétrica resolve isso introduzindo um deslocamento de ponto zero, mapeando o mínimo de peso para o inteiro representável mais baixo e o máximo para o mais alto. Na prática, W4A16 assimétrico supera significativamente a abordagem simétrica em precisão do modelo.

W8A8: Quantização Completa

W8A8 quantiza tanto pesos quanto ativações para 8 bits, permitindo inferência inteira pura. Enquanto quantização de pesos para 8 bits é relativamente simples, ativações apresentam desafios em transformadores devido a outliers—valores ocasionalmente muito grandes em certas camadas. Técnicas como SmoothQuant resolvem isso redistribuindo a dificuldade de quantização, redimensionando canais de ativação outlier e ampliando os correspondentes canais de peso. Com essas calibrações, modelos conseguem W8A8 com perda mínima de desempenho, e hardware moderno pode explorar aritmética INT8 otimizada para multiplicação matricial mais rápida.

W8A16: Quantização Apenas de Pesos

W8A16 usa 8-bit para pesos mantendo ativações em 16-bit. É uma abordagem segura que reduz tamanho sem riscos significativos de perda de qualidade. Para cargas de trabalho limitadas por memória (comuns em LLMs com pequenos batch sizes), W8A16 oferece aceleração notável.

Algoritmos Principais: AWQ e GPTQ

Quantização Consciente de Ativação (AWQ)

AWQ é uma técnica PTQ que visa quantização apenas de pesos em precisão muito baixa (tipicamente 4-bit) mantendo ativações em precisão maior como FP16. O conceito central é que nem todos os pesos contribuem igualmente à saída do modelo. Um pequeno subconjunto de pesos salientes influencia desproporcionalmente as predições.

Ao identificar e preservar aproximadamente 1% dos canais críticos—aqueles associados aos maiores valores de ativação—AWQ consegue fechar drasticamente a lacuna entre modelos quantizados de 4-bit e seus equivalentes FP16 em termos de perplexidade. A técnica usa distribuições de ativação para encontrar pesos que realmente importam, diferente de métodos tradicionais baseados em magnitude.

AWQ resolve a ineficiência de hardware introduzindo escala por canal. Durante quantização, amplifica pesos de canais ativação-salientes para reduzir erro relativo de quantização e dobra a escala inversa no modelo, sem rescalonamento explícito durante inferência. Tudo isso acontece sem retreinamento—usa apenas um pequeno conjunto de calibração para estimar estatísticas de ativação e derivar fatores de escala analiticamente.

Quantização de Transformadores Pré-Treinados Generativos (GPTQ)

GPTQ é outro método PTQ que adota abordagem orientada por compensação de erro. Opera camada por camada, visando preservar a saída de cada camada tão próxima quanto possível da original. Segue estratégia sequencial gulosa: em cada passo, um peso ou pequeno grupo é quantizado enquanto pesos não quantizados são ajustados para compensar o erro introduzido.

O processo usa aproximação de estatísticas de segunda ordem, especificamente aproximação da matriz Hessiana, que estima sensibilidade da saída a mudanças em cada peso. Esse procedimento é às vezes chamado quantização de cérebro ótimo, onde GPTQ quantiza pesos em ordem que minimiza erro de saída acumulado. Apesar da sofisticação, GPTQ permanece método PTQ de uma única passagem—não requer retreinamento ou ajuste fino iterativo.

Implementação Prática no Amazon SageMaker AI

A AWS oferece um fluxo de trabalho completo para quantização usando amazon-sagemaker-generativeai GitHub repository. O processo envolve três etapas principais com o pacote vllm-project/llm-compressor:

Etapa 1: Carregamento do Modelo

Carregue pesos do modelo sem anexá-los a um acelerador. A biblioteca llm-compressor detecta automaticamente hardware disponível e descarrega pesos conforme necessário. Como executa quantização camada por camada, o modelo inteiro não precisa caber em memória do acelerador simultaneamente.

model = AutoModelForCausalLM.from_pretrained(
    args.model_id,
    torch_dtype="auto",
    device_map=None,
    trust_remote_code=True
)

tokenizer_or_processor = AutoTokenizer.from_pretrained(
    args.model_id,
    trust_remote_code=True
)

Etapa 2: Seleção de Dataset de Calibração

Um dataset de calibração durante PTQ estima intervalos de ativação e distribuições estatísticas em um LLM pré-treinado sem retreinamento. Ferramentas como llm-compressor usam esse pequeno dataset representativo para executar passagens diretas e coletar estatísticas que guiam quantização de pesos e ativações.

Etapa 3: Execução da PTQ

O método oneshot em llm-compressor realiza PTQ de passagem única usando receita especificada, aplicando quantização de pesos, ativações (e opcionalmente sparsidade) em uma passagem:

oneshot(
    model=model,
    dataset=processed_dataset,
    recipe=recipe,
    max_seq_length=args.max_sequence_length,
    num_calibration_samples=args.num_calibration_samples,
    output_dir=save_dir,
    trust_remote_code_model=True
)

Resultados de Desempenho

Testes cobriram três modelos—Llama-3.1-8B-Instruct, Llama-3.3-70B-Instruct e Qwen2.5-VL-7B-Instruct—em diferentes instâncias de GPU. As métricas principais avaliadas foram:

• Utilização de Memória GPU: Quantização resulta em redução de 30-70% no consumo de memória GPU
• Latência fim-a-fim: Tempo total de entrada para saída final
• Tempo para primeiro token: Crítico para aplicações interativas e streaming
• Latência entre tokens: Tempo médio entre saídas sucessivas
• Throughput: Tokens gerados por segundo

Para o modelo Llama-3.1-8B, quantização com AWQ em W4A16 assimétrico reduziu uso de memória de 17.9 GB para 7.9 GB (56% de redução). Latência fim-a-fim sob concorrência de 128 requisições simultâneas caiu de 56.67 segundos no modelo base para 35.83 segundos (37% melhoria).

Throughput também melhorou significativamente. Modelos quantizados com W4A16 em concorrência de 8 requisições simultâneas atingiram throughput 2-3 vezes maior comparado ao modelo base, permitindo processamento mais eficiente de cargas de trabalho grandes ou suporte a mais sessões de usuário simultâneas.

Conclusão

Técnicas de quantização pós-treinamento como AWQ e GPTQ comprovam ser soluções efetivas para implantar modelos de fundação em produção. Os testes abrangentes em diferentes tamanhos e arquiteturas de modelos demonstram que PTQ reduz significativamente utilização de memória GPU. Os benefícios são evidentes em todas as métricas principais: modelos quantizados mostram melhor throughput e latência reduzida em cenários de alta concorrência.

A AWS oferece um caminho simplificado através do Amazon SageMaker AI, tornando o processo de quantização acessível e escalável. Organizações podem implementar e servir modelos quantizados para inferência em tempo real, simplificando a jornada do desenvolvimento até produção. Para explorar quantização mais profundamente, consulte o llm-compressor e o repositório GitHub.

Fonte

Accelerating LLM inference with post-training weight and activation using AWQ and GPTQ on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/accelerating-llm-inference-with-post-training-weight-and-activation-using-awq-and-gptq-on-amazon-sagemaker-ai/)

Compreendendo o desafio das buscas multimodais

Os mecanismos de busca convencionais enfrentam limitações significativas quando precisam lidar com diferentes tipos de conteúdo. Abordagens tradicionais dependem de buscas por palavras-chave, de embeddings textuais para processamento de linguagem natural, ou de buscas híbridas, mas nenhuma consegue processar efetivamente consultas visuais. Essa fragmentação cria uma lacuna considerável entre o que o usuário quer encontrar e o que o sistema consegue recuperar.

O problema é estrutural: arquiteturas típicas separam o processamento de conteúdo visual do textual, perdendo contexto no processo. Quando um usuário faz uma busca por texto, o sistema procura nas descrições de produtos usando correspondência de palavras-chave ou embeddings textuais. Quando tenta buscar por imagens, recorre a pipelines de visão computacional separados com integração limitada ao conteúdo textual. Essa separação complexifica toda a arquitetura e degrada a experiência do usuário.

Além disso, usar múltiplos modelos de embedding exige ciclos distintos de manutenção e otimização. Consultas que envolvem diferentes modalidades não conseguem ser processadas nativamente em um único sistema. Os escores de similaridade entre conteúdo visual e textual operam em espaços matemáticos diferentes, dificultando classificações consistentes entre tipos de conteúdo. Essa separação força mapeamentos complexos que frequentemente não funcionam bem, levando as organizações a manter sistemas de embedding isolados que criam silos de dados e limitam funcionalidades.

Em e-commerce, o desafio é ainda maior. Páginas de produtos combinam imagens, descrições, especificações e às vezes vídeos de demonstração, criando um cenário de conteúdo complexo que os buscadores tradicionais não conseguem integrar adequadamente.

O conceito de embeddings multimodais

Embeddings multimodais mapeiam texto, imagens, áudio e vídeo para um espaço vetorial compartilhado onde conteúdo semanticamente similar se agrupa naturalmente. Por exemplo, quando um modelo processa a consulta textual “vestido vermelho de verão” junto com uma imagem de um vestido vermelho, ambas as entradas geram vetores próximos um do outro no espaço de embedding, refletindo sua similaridade semântica e desbloqueando recuperação de conteúdo através de diferentes modalidades.

Utilizando embeddings multimodais, é possível buscar entre diferentes tipos de conteúdo sem precisar manter sistemas separados para cada modalidade. Isso resolve o problema dos sistemas multimodais segmentados, onde organizações gerenciam múltiplos modelos de embedding que são praticamente impossíveis de integrar efetivamente porque embeddings de diferentes modalidades simplesmente não são compatíveis entre si.

Uma arquitetura de modelo único garante que a geração de embeddings seja consistente em todos os tipos de conteúdo. Conteúdo relacionado, como imagens de produtos, vídeos e suas descrições, gera embeddings similares graças aos objetivos de treinamento conjunto. As aplicações conseguem gerar embeddings para todos os tipos de conteúdo usando pontos de extremidade idênticos da API e mesmas dimensões vetoriais, reduzindo significativamente a complexidade do sistema.

Caso de uso: buscas em e-commerce

Imagine um cliente que vê uma camiseta em um programa de TV e deseja encontrar itens similares para comprar. Ele pode fotografar o item com seu telefone ou tentar descrever o que viu em texto e usar isso para buscar um produto. Os mecanismos tradicionais lidam razoavelmente bem com buscas em texto que referenciam metadados, mas não conseguem executar quando clientes desejam usar imagens para buscar ou descrever atributos visuais de um item.

Essa experiência de “da TV para o carrinho de compras” demonstra como buscas visuais e textuais trabalham juntas. O cliente envia uma foto, e o sistema a compara contra catálogos de produtos que contêm tanto imagens quanto descrições. O fluxo de trabalho multimodal em e-commerce funciona através de etapas bem definidas: o usuário inicia com uma consulta (texto, imagem ou ambas), essa entrada é transformada em um embedding através de um modelo unificado, a similaridade é calculada contra o catálogo pré-indexado, e resultados são ranqueados pela relevância.

Como o Amazon Nova Multimodal Embeddings ajuda

Amazon Nova Multimodal Embeddings processa texto, documentos, imagens, vídeos e áudio através de uma única arquitetura de modelo. Disponível através de Amazon Bedrock, o modelo converte diferentes modalidades de entrada em embeddings numéricos dentro do mesmo espaço vetorial, permitindo cálculos diretos de similaridade independentemente do tipo de conteúdo.

O Amazon Nova lida com diferentes tipos de consultas de busca através do mesmo modelo, criando tanto novas capacidades de busca quanto vantagens técnicas. Independentemente de o usuário enviar imagens, inserir descrições em texto, ou combinar ambas as abordagens, o processo funciona da mesma maneira.

Capacidades de busca multimodal

Quando clientes enviam imagens, o sistema as converte em embeddings e busca contra o catálogo de produtos usando similaridade de cosseno. O resultado são produtos com características visuais similares, independentemente de como são descritos em texto. Consultas textuais funcionam da mesma forma — clientes conseguem descrever o que desejam e encontrar produtos visualmente similares, mesmo quando as descrições de produtos usam palavras diferentes.

Se o cliente envia uma imagem com uma descrição em texto, o sistema processa ambas as entradas através do mesmo modelo de embedding para escoring de similaridade unificado. O sistema também extrai atributos de produtos de imagens automaticamente através de marcação automática de produtos, suportando geração de tags semânticas que vai além da categorização manual.

Vantagens técnicas

A arquitetura unificada oferece vários benefícios sobre embeddings de texto e imagem separados. O design de modelo único e espaço semântico compartilhado desbloqueiam casos de uso novos que não são alcançáveis gerenciando múltiplos sistemas de embedding. Aplicações geram embeddings para todos os tipos de conteúdo usando os mesmos pontos de extremidade da API e dimensões vetoriais.

Um modelo único lida com todas as cinco modalidades, então conteúdo relacionado, como imagens de produtos e suas descrições, produz embeddings similares. É possível calcular distâncias entre qualquer combinação de texto, imagens, áudio e vídeo para medir o quão similares eles são.

O modelo Matryoshka representation learning oferece suporte a múltiplas dimensões de embedding: 3072, 1024, 384 e 256. O aprendizado de embedding Matryoshka armazena as informações mais importantes nas primeiras dimensões e detalhes menos críticos em dimensões posteriores. É possível truncar a partir do final para reduzir espaço de armazenamento mantendo precisão para o caso de uso específico.

Arquitetura da solução

Três componentes principais são necessários para construir essa abordagem: geração de embeddings, armazenamento vetorial e busca por similaridade. Catálogos de produtos passam por pré-processamento para gerar embeddings para todos os tipos de conteúdo. O processamento de consultas converte entradas do usuário em embeddings usando o mesmo modelo. A busca por similaridade compara embeddings de consultas contra embeddings de produtos armazenados.

Sistemas de armazenamento vetorial precisam suportar as dimensões de embedding escolhidas e fornecer operações eficientes de busca por similaridade. As opções incluem bancos de dados vetoriais específicos para esse propósito, bancos de dados tradicionais com extensões vetoriais, ou serviços vetoriais centrados em nuvem como Amazon S3 Vectors, um recurso de Amazon S3 que oferece suporte nativo para armazenar e consultar embeddings vetoriais diretamente dentro de S3.

Implementação prática

Pré-requisitos

Para usar a funcionalidade efetivamente, alguns aspectos-chave são necessários para essa implementação. Uma conta AWS com permissões de acesso ao Amazon Bedrock para o modelo Amazon Nova Multimodal Embeddings. Os serviços adicionais necessários incluem S3 Vectors. Um notebook está disponível no repositório de exemplos do Amazon Nova para seguir passo a passo.

Configuração de bucket e índice vetorial

O primeiro passo é criar a infraestrutura de armazenamento vetorial para embeddings. S3 Vectors é um serviço gerenciado para armazenar e consultar vetores de alta dimensionalidade em escala. O bucket atua como contêiner para os dados vetoriais, enquanto o índice define a estrutura e características de busca. O índice é configurado com métrica de distância de cosseno, que mede similaridade baseada na direção do vetor em vez de sua magnitude, tornando-o ideal para embeddings normalizados de modelos fornecidos por serviços como Amazon Nova Multimodal Embeddings.

# Configuração S3 Vectors
s3vector_bucket = "amzn-s3-demo-vector-bucket-crossmodal-search"
s3vector_index = "product"
embedding_dimension = 1024
s3vectors = boto3.client("s3vectors", region_name="us-east-1")

# Criar bucket de vetores S3
s3vectors.create_vector_bucket(vectorBucketName=s3vector_bucket)

# Criar índice
s3vectors.create_index(
    vectorBucketName=s3vector_bucket,
    indexName=s3vector_index,
    dataType='float32',
    dimension=embedding_dimension,
    distanceMetric='cosine'
)

Pré-processamento do catálogo de produtos

O próximo passo é gerar embeddings. Tanto imagens de produtos quanto descrições textuais requerem geração e armazenamento de embeddings com metadados apropriados para recuperação. A API Amazon Nova Embeddings processa cada modalidade independentemente, convertendo descrições de produtos e imagens de produtos em vetores de 1024 dimensões. Esses vetores vivem em um espaço semântico unificado, o que significa que um embedding de texto e um embedding de imagem do mesmo produto estarão geometricamente próximos um do outro.

# Inicializar cliente Nova Embeddings
class NovaEmbeddings:
    def __init__(self, region='us-east-1'):
        self.bedrock = boto3.client('bedrock-runtime', region_name=region)
        self.model_id = "amazon.nova-2-multimodal-embeddings-v1:0"
    
    def embed_text(self, text: str, dimension: int = 1024, purpose: str = "GENERIC_INDEX"):
        request_body = {
            "taskType": "SINGLE_EMBEDDING",
            "singleEmbeddingParams": {
                "embeddingDimension": dimension,
                "embeddingPurpose": purpose,
                "text": {
                    "truncationMode": "END",
                    "value": text
                }
            }
        }
        response = self.bedrock.invoke_model(modelId=self.model_id, body=json.dumps(request_body))
        result = json.loads(response['body'].read())
        return result['embeddings'][0]['embedding']
    
    def embed_image(self, image_bytes: bytes, dimension: int = 1024, purpose: str = "GENERIC_INDEX"):
        request_body = {
            "taskType": "SINGLE_EMBEDDING",
            "singleEmbeddingParams": {
                "embeddingDimension": dimension,
                "embeddingPurpose": purpose,
                "image": {
                    "format": "jpeg",
                    "source": {"bytes": base64.b64encode(image_bytes).decode()}
                }
            }
        }
        response = self.bedrock.invoke_model(modelId=self.model_id, body=json.dumps(request_body))
        result = json.loads(response['body'].read())
        return result['embeddings'][0]['embedding']

embeddings = NovaEmbeddings()

O código a seguir gera os embeddings e envia os dados para o armazenamento vetorial:

# Gerar embeddings e fazer upload para Amazon S3 Vectors
def get_product_text(product):
    name = product.get('item_name', [{}])[0].get('value', '') if isinstance(product.get('item_name'), list) else str(product.get('item_name', ''))
    brand = product.get('brand', [{}])[0].get('value', '') if product.get('brand') else ''
    return f"{name}. {brand}".strip()

vectors_to_upload = []
batch_size = 10
catalog = []

for product in tqdm(sampled_products, desc="Processing products"):
    img_path = get_image_path(product)
    text = get_product_text(product)
    product_id = product.get('item_id', str(len(catalog)))
    
    with open(img_path, 'rb') as f:
        img_bytes = f.read()
    
    # Gerar embeddings
    text_emb = embeddings.embed_text(text)
    image_emb = embeddings.embed_image(img_bytes)
    
    # Armazenar no catálogo local
    catalog.append({
        'text': text,
        'image_path': str(img_path),
        'text_emb': text_emb,
        'image_emb': image_emb,
        'product_id': product_id
    })
    
    # Preparar vetores para upload em S3
    vectors_to_upload.extend([
        {
            "key": f"text-{product_id}",
            "data": {"float32": text_emb},
            "metadata": {"product_id": product_id, "text": text, "image_path": str(img_path), "type": "text"}
        },
        {
            "key": f"image-{product_id}",
            "data": {"float32": image_emb},
            "metadata": {"product_id": product_id, "text": text, "image_path": str(img_path), "type": "image"}
        },
        {
            "key": f"combined-{product_id}",
            "data": {"float32": np.mean([text_emb, image_emb], axis=0).tolist()},
            "metadata": {"product_id": product_id, "text": text, "image_path": str(img_path), "type": "combined"}
        }
    ])
    
    # Upload em lotes
    if len(vectors_to_upload) >= batch_size * 3:
        s3vectors.put_vectors(vectorBucketName=s3vector_bucket, indexName=s3vector_index, vectors=vectors_to_upload)
        vectors_to_upload = []

# Upload dos vetores restantes
if vectors_to_upload:
    s3vectors.put_vectors(vectorBucketName=s3vector_bucket, indexName=s3vector_index, vectors=vectors_to_upload)

Processamento de consultas

Esse código lida com entrada do cliente através da API. Consultas de texto, uploads de imagens, ou combinações se convertem no mesmo formato vetorial usado para o catálogo de produtos. Para consultas multimodais que combinam texto e imagem, é aplicada fusão por média para criar um vetor de consulta único que captura informações de ambas as modalidades.

def search_s3(query=None, query_image=None, query_type='text', search_mode='combined', top_k=5):
    """
    Buscar usando S3 Vectors
    query_type: 'text', 'image', ou 'both'
    search_mode: 'text', 'image', ou 'combined'
    """
    # Obter embedding de consulta
    if query_type == 'both':
        text_emb = embeddings.embed_text(query)
        with open(query_image, 'rb') as f:
            image_emb = embeddings.embed_image(f.read())
        query_emb = np.mean([text_emb, image_emb], axis=0).tolist()
        query_image_path = query_image
    elif query_type == 'text':
        query_emb = embeddings.embed_text(query)
        query_image_path = None
    else:
        with open(query_image, 'rb') as f:
            query_emb = embeddings.embed_image(f.read())
        query_image_path = query_image

Busca por similaridade vetorial

O próximo passo é adicionar recuperação multimodal usando a API de consulta S3 Vectors. O sistema encontra a correspondência de embedding mais próxima à consulta, independentemente se foi texto ou imagem. É usado cosseno como métrica de distância, que mede o ângulo entre vetores em vez de sua distância absoluta. Essa abordagem funciona bem para embeddings normalizados e é eficiente em recursos, tornando-a adequada para catálogos grandes quando associada a algoritmos de vizinho aproximado mais próximo.

# Consultar S3 Vectors
response = s3vectors.query_vectors(
    vectorBucketName=s3vector_bucket,
    indexName=s3vector_index,
    queryVector={"float32": query_emb},
    topK=top_k,
    returnDistance=True,
    returnMetadata=True,
    filter={"metadata.type": {"equals": search_mode}}
)

Classificação de resultados

Os escores de similaridade computados por S3 Vectors fornecem o mecanismo de classificação. A similaridade de cosseno entre embeddings de consulta e catálogo determina a ordem de resultados, com escores mais altos indicando correspondências melhores. Em sistemas de produção, normalmente seria coletado dados de cliques e julgamentos de relevância para validar que a classificação se correlaciona com comportamento real do usuário. S3 Vectors retorna valores de distância que são convertidos em escores de similaridade (1 – distância) para interpretação intuitiva onde valores mais altos indicam correspondências mais próximas.

# Extrair e classificar resultados por similaridade
ranked_results = []
for result in response['vectors']:
    metadata = result['metadata']
    distance = result.get('distance', 0)
    similarity = 1 - distance  # Converter distância em escore de similaridade
    ranked_results.append({
        'product_id': metadata['product_id'],
        'text': metadata['text'],
        'image_path': metadata['image_path'],
        'similarity': similarity,
        'distance': distance
    })

# Resultados são classificados por S3 Vectors (melhores correspondências primeiro)
return ranked_results

Por que isso importa

Amazon Nova Multimodal Embeddings resolve o problema central de busca multimodal usando um único modelo em vez de gerenciar sistemas separados. É possível usar o Amazon Nova Multimodal Embeddings para construir buscas que funcionam independentemente de clientes enviarem imagens, inserirem descrições em texto, ou combinarem ambas as abordagens.

A implementação é direta usando as APIs do Amazon Bedrock, e as dimensões de embedding Matryoshka permitem otimizar para requisitos específicos de precisão e custo. As dimensões de embedding Matryoshka mantêm qualidade de embedding em diferentes dimensões com degradação de desempenho previsível, permitindo que aplicações se otimizem para casos de uso específicos.

Próximos passos

Amazon Nova Multimodal Embeddings está disponível em Amazon Bedrock. Consulte Usando Nova Embeddings para referências de API, exemplos de código e padrões de integração para arquiteturas comuns. O repositório de exemplos AWS contém exemplos de implementação para embeddings multimodais.

Fonte

Crossmodal search with Amazon Nova Multimodal Embeddings (https://aws.amazon.com/blogs/machine-learning/crossmodal-search-with-amazon-nova-multimodal-embeddings/)

O que é Amazon Quick

A AWS anunciou a expansão do Amazon Quick, sua plataforma de workspace alimentada por inteligência artificial que funciona como um colega de trabalho baseado em agentes. O serviço foi desenvolvido para ajudar organizações a obter respostas a partir de seus dados empresariais e a passar rapidamente de insights para ações concretas.

O desafio da fragmentação de ferramentas

À medida que as organizações adotam agentes de IA e trabalham com ferramentas empresariais tradicionais — como sistemas de CRM, suporte ao cliente, ferramentas de colaboração e outras — os usuários enfrentam uma realidade fragmentada. Precisam alternar constantemente entre diferentes interfaces, repetir informações de contexto e, muitas vezes, compilar manualmente resultados de diversos sistemas. Tudo isso gera perda de tempo e sobrecarga cognitiva.

O Amazon Quick foi construído justamente para resolver esse problema, permitindo que os usuários trabalhem com agentes de terceiros e ferramentas empresariais a partir de uma única interface unificada.

Novos agentes de terceiros disponíveis

Na nova expansão, o Amazon Quick agora permite invocar agentes especializados de três principais fornecedores: Box, Canva e PagerDuty. Isso abre possibilidades para automação e consulta de dados que antes exigiam mudanças de contexto. Por exemplo, um usuário pode extrair insights sobre incidentes diretamente do PagerDuty, gerar uma apresentação usando a Canva e consultar documentos armazenados no Box — tudo dentro da mesma sessão no Quick.

Expansão da biblioteca de ações integradas

Além dos agentes de terceiros, o Amazon Quick expandiu significativamente suas ações integradas. O serviço agora inclui integrações nativas com GitHub, Notion, Canva, Box, Linear, Hugging Face, Monday.com, HubSpot, Intercom e outras plataformas. Essa expansão permite que usuários executem tarefas como criar issues no GitHub, resumir notas de reuniões no Notion, gerenciar seu CRM e muito mais — sem sair do Quick.

Conectando aplicações além das integrações prontas

Para cenários que vão além das integrações pré-configuradas, o Amazon Quick oferece aos clientes a capacidade de aproveitar conectores customizados baseados no Model Context Protocol (Protocolo de Contexto de Modelo — MCP) e OpenAPI. Esses padrões abertos permitem conectar o Quick a milhares de aplicações adicionais, oferecendo flexibilidade para ambientes corporativos complexos.

Disponibilidade

Todos esses recursos estão disponíveis em todos os Regiões da AWS onde o Amazon Quick já opera. Para explorar as opções de integração em detalhes, o serviço oferece documentação técnica abrangente.

Para saber mais sobre as integrações suportadas, consulte o Guia de Integrações Suportadas do Amazon Quick e o Guia Específico de Integrações.

Fonte

Amazon Quick adds third-party AI agents and expands built-in actions library (https://aws.amazon.com/about-aws/whats-new/2026/01/3p-agent-in-quick/)