Você Precisa de Embeddings? Um Guia de Decisão

"Devemos subir um serviço de embeddings?" é uma decisão de infraestrutura que a maioria dos times toma por padrão, não por evidência. Aqui estão os sinais que apontam para cada lado, e um teste que você roda no seu próprio corpus em uma tarde, antes de qualquer fatura chegar.

Sinais de que BM25 sobre metadados curados basta

Suas consultas nomeiam coisas. Serviços, códigos de erro, nomes de projeto, pessoas, SKUs. A busca lexical é mais forte exatamente onde consultas contêm nomes, e dentro de uma empresa a maioria contém.

Você tem metadados curados, ou pode produzi-los. Títulos, aliases e resumos curtos dão ao BM25 algo denso para agarrar. Na nossa medição, dar peso aos campos curados (título, aliases) fechou completamente a lacuna para a busca híbrida: recall@5 = 1.00 a 1.3 ms p95, BM25 sobre SQLite, sem embeddings, sem banco vetorial, sem GPU.

Quem chama é um agente, não uma pessoa. Agentes reformulam e tentam de novo a custo desprezível, e numa arquitetura de entrar e caminhar a busca só precisa abrir a porta certa; a caminhada pelos nós linkados faz o resto.

Uma língua dominante no corpus e nas consultas.

Sinais de que você quer vetores

Humanos digitando paráfrases. Usuários finais descrevem em vez de nomear, e compartilham pouco vocabulário com seus documentos.

Recuperação entre línguas. A consulta chega numa língua, os documentos vivem em outra.

Sem metadados e sem orçamento de escrita. Corpos crus fatiados, sem títulos que mereçam peso, não deixam nada para a busca lexical agarrar.

Deriva de vocabulário que você não consegue resolver com alias. Um domínio em que o mesmo conceito ganha dez nomes de dez times.

Quando vários desses valem ao mesmo tempo, embeddings não são overhead. São a ferramenta correta, e fingir o contrário seria fingir que a nossa carga de trabalho é a de todo mundo.

O teste: uma tarde, não uma migração

1. Monte um gold set. Cinquenta consultas reais, tiradas de logs de busca ou de colegas, cada uma pareada com o documento que deveria respondê-la.
2. Rode a busca lexical que você já tem. SQLite FTS5 ou tsvector do Postgres, uma noite de setup. Dê peso aos campos de título e alias acima do corpo do texto; na nossa medição, esse peso foi a diferença inteira.
3. Meça recall@5. Se o documento-alvo aparece no top cinco quase sempre, um embedder estaria melhorando um número quase sem espaço sobrando na etapa de entrada.
4. Só então teste o híbrido. Adicione um modelo de embedding, rode de novo o mesmo gold set e precifique o delta medido contra a infraestrutura permanente que ele exige: o serviço, o índice, o pipeline de re-embedding.

Uma nota de honestidade: nossos números vêm do nosso corpus e dos nossos conjuntos de perguntas, e os publicamos como tal, harness incluído. A alegação não é que o seu corpus vai bater 1.00. A alegação é que isso é mensurável nos seus próprios dados antes de qualquer dinheiro se mover.

Onde o MonkeyLLM se posiciona

O padrão é a ponta barata. A busca de entrada é BM25 sobre SQLite, com pesos no passaporte de cada nó (um cartão curado: título, resumo, tags), e esses passaportes são produzidos automaticamente na ingestão: 1.71 s por documento, com 100% dos resumos passando num contrato de sessenta tokens. O embedder é opcional e suportado, não removido: aponte um binding de modelo para qualquer endpoint de embeddings compatível com OpenAI e a busca de entrada vira híbrida, sem mudança de schema.

A medição por trás desse padrão, e o argumento mais longo, está em BM25 sobre SQLite vs um banco vetorial.

Rode no seu corpus

O teste de gold set custa uma tarde e resolve a discussão com os seus próprios dados. Se o número lexical segurar, suba uma floresta em quatro comandos, mantenha tudo no seu próprio hardware e pule a linha de embeddings do orçamento até ela merecer o lugar. Código em github.com/JimmyWesley/MonkeyLLM, todo o resto em monkeyllm.com.