Embedding é uma das ferramentas mais bem resolvidas de recuperação de informação. Você transforma cada documento em um vetor, transforma a pergunta em outro vetor e ordena por proximidade. É barato, é rápido e escala para milhões de itens.
E tem um limite que é conceitual, não de implementação: proximidade de sentido não é resposta. Um parágrafo pode ser o mais parecido com a pergunta do acervo inteiro e não responder nada.
A tarefa
Encontrar, dentro de um acervo, o trecho que responde a uma pergunta escrita em linguagem natural — e saber quando nenhum responde.
Note que são duas coisas. A primeira, embedding faz bem. A segunda, ele não faz, porque distância vetorial sempre tem um vencedor.
O contrato de cada lado
| Embeddings | Jev (jev-1.13.0) | |
|---|---|---|
| O que mede | Proximidade de sentido entre dois textos | Se o candidato satisfaz um critério que você escreveu |
| O que devolve | Uma lista ordenada por distância | Uma decisão tipada por candidato, com probabilidade |
| Como se lê a incerteza | Pela distância, que não é calibrada e muda de escala por corpus | Pela distribuição de probabilidades e pela confiança |
| “Não existe resposta” | Não é representável: o vizinho mais próximo sempre existe | É uma pergunta de sim ou não à parte |
| Custo de busca | Depois de indexado, procurar entre milhões é quase gratuito | Uma chamada por lote de candidatos, cobrada em tokens de entrada |
| Custo de entrada | Depende do fornecedor do modelo de embedding | US$ 0,042 por milhão, com saída gratuita |
Onde o Jev ganha
Ele decide, em vez de ordenar por semelhança. A pergunta deixa de ser “quanto este trecho se parece com a consulta” e passa a ser “este trecho responde a esta pergunta”, que é o que você realmente quer saber.
O ganho está medido. O cookbook oficial de reordenação montou listas curtas de 30 passagens por consulta com BM25, sobre um corpus de 3.565 passagens de decisões judiciais, em 40 consultas. A passagem correta estava entre as 30 em 100% das consultas — ou seja, a camada de baixo fez o trabalho dela. Depois de uma pergunta de sim ou não por par consulta-candidato:
| Métrica | Só a lista do BM25 | Depois da reordenação |
|---|---|---|
| Acerto em primeiro lugar | 5% | 18% |
| Acerto entre os cinco primeiros | 15% | 35% |
| Acerto entre os dez primeiros | 38% | 62% |
São números do experimento da TypeSafe, com o modelo jev-1.12, naquele
corpus. A receita inteira está em
reranking de busca.
Ele sabe dizer que a resposta não está lá. Uma pergunta separada de existência resolve o que a distância não resolve. Na receita de busca linha a linha, a consulta sobre arbitragem recebeu existência 0,14 enquanto a melhor linha marcava 0,86 de relevância. Em busca interna, essa diferença é a distância entre “não temos isso documentado” e dez resultados inúteis.
O critério é editável. “Relevante” no seu domínio é o que você escreveu no
criteria. Em um índice vetorial, relevância é o que o modelo de embedding
aprendeu, e você não muda isso com uma linha de texto.
Onde os embeddings ganham
Escala, e com folga. Depois de indexado, comparar a consulta com um milhão
de vetores custa praticamente nada e leva milissegundos. Avaliar um milhão de
documentos com o Jev seria um milhão de textos passando pelo state. Não é a
mesma ordem de grandeza, e nenhuma tabela de preço muda isso.
Custo por item indexado, pago uma vez. O vetor é calculado na ingestão e reaproveitado em todas as buscas futuras. Uma decisão do Jev vale para aquela pergunta e aquele candidato.
Eles não precisam de pergunta. Agrupamento, deduplicação, recomendação por similaridade e detecção de quase-duplicatas são tarefas em que não existe critério escrito — existe geometria.
Latência de busca. Um índice vetorial responde em poucos milissegundos. Mesmo com a latência declarada de 70 a 500 milissegundos do Jev, e com as nossas cinco medições de 18/09/2026 entre 270 e 802 milissegundos incluindo rede, a busca vetorial é mais rápida por uma ordem de grandeza.
Eles funcionam sem você saber o que procura. Exploração de um acervo novo, mapa de temas, vizinhos de um documento: tudo isso é semelhança pura.
Como escolher
Na prática, quase nunca é um ou outro. É uma arquitetura de duas camadas.
- Camada de baixo, para reduzir o acervo: embedding, BM25, ou os dois. O papel dela é produzir uma lista curta com alta chance de conter a resposta — e, no experimento oficial, a lista de 30 continha a resposta em 100% dos casos.
- Camada de cima, para decidir sobre a lista curta: o Jev. Uma pergunta por candidato, mais uma pergunta de existência sobre o conjunto.
- Se a sua busca já acerta o que precisa, não acrescente uma camada. O ganho do experimento veio de um cenário em que o topo estava ruim: 5% em primeiro lugar.
- Se a saída é texto para uma pessoa ler, nenhum dos dois escreve — e vale lembrar que o Jev só decide.
O caso completo está em busca interna, e o índice desta seção em comparativos.
Perguntas frequentes
O Jev substitui embeddings numa busca?
Normalmente não; ele entra depois. Embedding gera a lista curta de candidatos de forma barata sobre milhões de itens, e o Jev decide sobre essa lista. O cookbook oficial de reordenação usa BM25 para montar listas de 30 candidatos e aplica uma pergunta por par.
Quanto a reordenação melhorou no experimento oficial?
Em 40 consultas jurídicas do CLERC, sobre 3.565 passagens, a acurácia em primeiro lugar foi de 5% para 18% e a de estar entre os dez primeiros foi de 38% para 62%. Entre os cinco primeiros, de 15% para 35%. São números do cookbook da TypeSafe, com o modelo jev-1.12.
Por que não passar o Jev em todos os documentos?
Porque cada avaliação é uma chamada com o texto no state, e o custo escala com o volume de tokens. Embedding é comparação vetorial: depois de indexado, procurar entre milhões custa quase nada. É por isso que a camada de baixo continua sendo busca vetorial ou textual.
Quanto custou o experimento de reordenação?
1.200 chamadas, uma pergunta por par, 1.536.002 tokens de entrada e 25.200 de saída, com custo total de US$ 0,0645. O próprio cookbook observa que fazer uma pergunta por par é uma escolha didática e que uma aplicação real agruparia várias perguntas sobre o mesmo par.
Como saber que a resposta não existe no acervo?
Com uma pergunta separada de sim ou não sobre existência. Na receita de busca linha a linha, uma consulta sobre arbitragem recebeu existência 0,14 mesmo com a melhor linha marcando 0,86 de relevância: havia texto parecido e não havia resposta.