Transformers.js e embeddings: busca semântica sem infraestrutura de servidor

Um erro clássico de busca: o usuário digita "notebook barato" e recebe uma página de resultados vazia, porque na base o produto se chama "laptop econômico". O Machine Learning Mastery publicou uma análise detalhada de como substituir a busca por palavras-chave por busca semântica, usando Transformers.js e sentence embeddings direto no navegador, sem backend de servidor.

Qual é o problema da busca tradicional

A busca por palavras-chave compara caracteres, não significado. Se a consulta e o documento não coincidem literalmente, não há resultado, mesmo quando as palavras são sinônimas. É um bug que as equipes reproduzem repetidamente: adicionam sinônimos manualmente, ajustam stop words, integram o ElasticSearch — e ainda assim deixam escapar formulações fora do padrão.

O problema é sistêmico. Os usuários não pensam em como o produto se chama na base: eles descrevem o que precisam. "Cooler silencioso", "notebook para estudar", "celular com boa câmera" são consultas que um mecanismo de palavras-chave ou não entende ou responde com um resultado irrelevante.

A busca semântica resolve a questão de outra forma: ela converte o texto em um vetor numérico (embedding) que reflete o significado. "Notebook barato" e "laptop econômico" ficam próximos no espaço vetorial, porque são semanticamente semelhantes. Em vez de comparar strings, o mecanismo calcula a similaridade de cosseno entre os vetores da consulta e dos documentos.

Como funciona o Transformers.js

O Transformers.js é um port em JavaScript da biblioteca Transformers, da Hugging Face. Ele executa modelos de linguagem direto no navegador ou no Node.js, sem API de servidor. Os modelos são carregados como pesos ONNX e executados via WebAssembly ou WebGPU.

Para a busca semântica, são necessários modelos de sentence embedding, treinados para transformar frases em vetores densos de dimensão fixa. Uma escolha popular para começar é o `all-MiniLM-L6-v2`, do Sentence-Transformers: ele pesa cerca de 25 MB, não exige GPU e é rápido o suficiente para rodar no código do cliente.

Arquitetura básica da busca:

• Inicializar o pipeline: `pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2')`
• Indexar a base: passar cada documento pelo modelo e salvar os vetores
• Na consulta: vetorizar o texto do usuário da mesma forma
• Calcular a similaridade de cosseno entre o vetor da consulta e todos os vetores do índice
• Retornar os top-N documentos com maior índice de proximidade

Para bases pequenas (até alguns milhares de registros), o índice fica direto na memória ou no `localStorage`, sem necessidade de infraestrutura de servidor.

Vantagens e limitações reais

A principal vantagem é o backend zero. Tudo roda no cliente: o modelo é baixado uma única vez e os embeddings são calculados localmente. A abordagem serve para portais de documentação, blogs estáticos, dashboards internos e qualquer coisa que funcione sem um servidor permanente.

As limitações também são relevantes. A busca linear O(n) começa a ficar lenta com dezenas de milhares de documentos; nesse cenário é preciso indexação HNSW, por meio de bibliotecas como `hnswlib-node`. Modelos de embedding de uso geral podem errar em vocabulário altamente especializado: nesses casos, funciona melhor um modo híbrido, com BM25 para correspondência exata e embeddings para a correspondência semântica.

O que isso significa

A barreira para adotar busca inteligente caiu bastante. Antes, isso exigia uma stack Python no servidor, um banco de dados vetorial e uma API separada. Agora, um desenvolvedor de front-end pode adicionar busca semântica a um site estático com poucas linhas de JavaScript — e ela funcionará até offline.