Índice do artigofaltam 7 min de leitura
Numa medição com 638 perguntas reais, a busca por palavra levou o documento correto ao top 10 em 96,2% das perguntas cujo alvo era um artigo. Sem embeddings, sem banco vetorial e sem custo por consulta.
Pergunte a qualquer material introdutório sobre RAG por onde começar e a resposta será a mesma: gere embeddings dos seus documentos e guarde num banco vetorial. Isso virou o passo um por repetição, não por evidência sobre o seu caso.
Fomos medir. Construímos um índice sobre 374 documentos usando busca por palavra, do tipo que existe há décadas, e avaliamos com perguntas escritas por pessoas reais. O resultado não diz que embeddings são inúteis. Diz que a ordem em que a indústria recomenda montar o sistema é ruim para quem está começando.
Resumo do artigo
- Em corpus institucional de algumas centenas de documentos, a busca por palavra entrega resultado suficiente para validar o projeto inteiro, a custo zero por consulta.
- O desempenho depende do tipo de alvo: 96,2% quando o documento correto tem corpo de texto, 67,8% quando o alvo é uma entrada curta de FAQ.
- A fraqueza real da busca por palavra é sinônimo e paráfrase, e ela é previsível: dá para saber de antemão se o seu caso sofre disso.
- Comece pelo simples não por economia, mas porque sem linha de base você não consegue provar que o banco vetorial melhorou alguma coisa.
A resposta curta
Se a sua base tem algumas centenas de documentos, se quem pergunta usa mais ou menos o mesmo vocabulário dos documentos e se tudo está no mesmo idioma, a busca por palavra provavelmente resolve, e resolve rápido o bastante para você descobrir se o projeto é viável antes de gastar.
Se o seu caso é o oposto, e principalmente se o vocabulário de quem pergunta é sistematicamente diferente do vocabulário de quem escreveu os documentos, aí o banco vetorial resolve um problema que você realmente tem.
O erro não é usar embeddings. É adotá-los no passo um, sem linha de base, e ficar sem saber o que exatamente eles melhoraram.
O que um banco vetorial faz, sem jargão
Busca por palavra encontra documentos que contêm as palavras da pergunta, dando mais peso às palavras raras. Se você procura "prazo de garantia", ela acha textos com essas palavras e ignora um texto que diz a mesma coisa com outras palavras.
Busca vetorial funciona por proximidade de significado. Cada trecho e cada pergunta viram uma lista de números que representa o sentido, e o sistema procura os trechos cujos números estão mais próximos dos da pergunta. É por isso que ela relaciona "prazo de garantia" com "período de cobertura" mesmo sem uma palavra em comum.
Dito assim, a segunda parece obviamente melhor, e é aí que a decisão costuma ser tomada. A pergunta que falta é outra: com que frequência, na sua base, a resposta certa está escrita com palavras diferentes das que o usuário usa?
Em documentação corporativa a resposta costuma ser "menos do que se imagina", porque quem pergunta normalmente aprendeu o vocabulário na própria empresa.
O custo dessa capacidade extra não é só o serviço. Embeddings adicionam um passo pago na indexação e outro em cada consulta, e criam uma segunda representação dos dados que precisa ficar sincronizada com o texto. Índice e texto dessincronizados é uma das fontes de bug mais desagradáveis de um RAG, porque o sistema responde com confiança usando uma versão que não existe mais.
O teste: 638 perguntas, nenhum embedding
Montamos o índice sobre o conteúdo público da X-Apps, que é conteúdo institucional em português: artigos, páginas de serviço, cases e perguntas frequentes. A avaliação usou perguntas escritas pelo time de conteúdo, cada uma com o documento de origem conhecido, e o teste remove do índice o texto das próprias perguntas para simular pergunta inédita.
A diferença entre as duas primeiras barras é a informação mais útil do gráfico, e ela não é sobre o algoritmo. Quando o documento correto tem corpo de texto, sobra material para casar com a pergunta e o acerto é alto. Quando o alvo é uma entrada curta de FAQ e o teste removeu justamente aquele texto, resta pouco para encontrar.
Ou seja: boa parte do que parece limitação da busca é, na verdade, escassez de texto no documento alvo. Trocar o método de busca não cria conteúdo.
Onde a busca por palavra ganha
Ela ganha em três frentes que costumam ser subestimadas na hora de escolher.
A primeira é operacional. O índice inteiro dos nossos 2.563 trechos ocupa 2,15 MB e é montado em 0,4 segundo. Ele cabe no pacote de deploy, não precisa de banco e não precisa de sincronização.
Mais importante: ele não pode ficar dessincronizado do texto publicado, porque os dois são gerados no mesmo processo. Isso elimina uma classe inteira de bug, aquela em que o sistema responde com confiança citando uma versão que não existe mais.
A segunda é o termo exato, e essa é uma vantagem real e frequentemente ignorada. Código de produto, número de norma, nome de campo, sigla interna e referência de contrato precisam casar literalmente. Busca por significado é justamente a que pode aproximar dois códigos parecidos e diferentes, o que em base técnica é pior que não achar.
A terceira é diagnóstico. Quando a busca por palavra erra, dá para ver por quê: as palavras estão lá, ou não estão. Quando a busca por proximidade erra, a explicação é uma distância entre listas de números, e melhorar aquilo é tentativa e erro.
Onde ela perde de verdade
Há casos em que a busca por palavra é a ferramenta errada, e a parte útil é que eles são identificáveis antes de qualquer teste. São três, e nenhum depende de medir para reconhecer.
O caso mais claro é vocabulário divergente. Se o cliente escreve "ticket", o atendente escreve "chamado" e a norma escreve "ocorrência", a busca por palavra trata os três como assuntos diferentes.
Isso é comum quando o público externo consulta documentação escrita por engenharia, ou quando a empresa passou por fusão e tem dois vocabulários convivendo dentro da mesma base.
O segundo é multilíngue. Perguntar em português e ter a resposta escrita em inglês é exatamente o problema que a busca por significado resolve e a busca por palavra não resolve de jeito nenhum.
O terceiro é a pergunta curta e dependente de contexto. Na nossa coleta, 87 de 730 perguntas não carregavam nenhum termo distintivo do documento que deveria respondê-las. São perguntas como "e no caso do plano anual?", claríssimas para quem estava lendo a página e sem endereço nenhum como consulta isolada. Embeddings ajudam um pouco aqui, mas a correção principal é outra: reescrever a pergunta com o contexto da conversa antes de buscar.
Por que a recomendação padrão é a oposta
Vale entender a origem, porque ela explica o descompasso sem precisar atribuir má intenção a ninguém.
O exemplo que popularizou o padrão é a busca semântica sobre grandes coleções heterogêneas, em que o vocabulário de quem pergunta realmente não tem relação com o de quem escreveu. Nesse formato, embeddings são a peça que faz o sistema existir, e o tutorial correto começa por eles.
O caso corporativo típico tem outro formato: menos documentos, um domínio só, vocabulário compartilhado e um problema de conteúdo maior que o de busca. O tutorial foi copiado; o formato do problema, não.
O que cada caminho custa de verdade
| Critério | Busca por palavra | Busca vetorial | Híbrida |
|---|---|---|---|
| Custo por consulta | Nenhum | Uma chamada paga por pergunta | Uma chamada paga por pergunta |
| Custo de indexação | Segundos de processamento | Chamada paga por trecho, repetida a cada mudança | Igual à vetorial |
| Infraestrutura | Um arquivo no deploy | Banco ou serviço externo, com sincronização | Os dois caminhos, mais a combinação |
| Termo exato e código | Forte | Fraco, aproxima códigos parecidos | Forte |
| Sinônimo e paráfrase | Fraco | Forte | Forte |
| Multilíngue | Não resolve | Resolve | Resolve |
| Diagnóstico de erro | Direto, dá para ver a causa | Opaco, exige tentativa e erro | Intermediário |
A coluna marcada é o ponto de partida recomendado, não a melhor opção em todos os cenários. As duas linhas de fraqueza da primeira coluna são reais.
A leitura honesta dessa tabela é que a híbrida ganha em capacidade e perde em simplicidade, e que ela é o destino natural de um projeto que começou pelo simples e mediu o ganho de cada peça adicionada.
O critério de decisão
Duas perguntas resolvem a escolha na maioria dos casos, e nenhuma delas é sobre tecnologia.
Para saber em que quadrante você está, não é preciso construir nada. Pegue trinta perguntas reais da operação e confira se as palavras que aparecem nelas aparecem também nos documentos que as respondem. Se aparecem na maioria, você está na metade de baixo.
Como não pagar duas vezes quando migrar
Começar simples só é vantagem se a migração depois for barata, e ela é, desde que duas coisas sejam feitas desde o primeiro dia.
A primeira é separar a etapa de fatiar documentos da etapa de indexar. O trabalho de transformar documentos em trechos com metadados é o mesmo nos dois caminhos, e ele é a maior parte do esforço. Se essa etapa produzir uma estrutura independente do método de busca, adicionar embeddings depois é acrescentar um consumidor da mesma saída.
A segunda é ter o conjunto de avaliação pronto antes. Ele é o que transforma a migração numa decisão medida em vez de uma reforma por fé. Com linha de base, você adiciona embeddings, roda as mesmas perguntas e vê o número mudar. Sem linha de base, você troca o sistema, sente que melhorou e não tem como saber.
Fontes e método
Os números vêm de um protótipo de recuperação sobre o conteúdo público da X-Apps, executado em 31 de agosto de 2026: 374 documentos, 2.563 trechos, 14.519 termos no índice, montado em 0,4 segundo.
A avaliação usou 730 perguntas escritas pelo time de conteúdo com documento de origem conhecido, das quais 638 foram avaliadas após descartar 5 sem corpo de documento e 87 sem termo distintivo em comum com o documento esperado. O regime remove do índice o texto das próprias perguntas.
Não comparamos aqui contra uma implementação vetorial no mesmo corpus, então este artigo não afirma quanto embeddings melhorariam esses números. Ele afirma que a linha de base lexical é alta o suficiente para validar o projeto e para servir de referência a qualquer decisão seguinte.
Perguntas frequentes
Dá, e em corpus pequeno costuma ser o começo certo. No nosso índice de 2.563 trechos, uma busca por palavra levou o documento correto ao top 10 em 96,2% das perguntas cujo alvo era um artigo, sem nenhum embedding.
Quando o vocabulário de quem pergunta é sistematicamente diferente do vocabulário dos documentos, quando o corpus passa do que cabe em memória, ou quando é preciso buscar em vários idiomas ao mesmo tempo. Fora disso, ele resolve um problema que talvez você não tenha.
Sinônimo e paráfrase. Se o usuário escreve ticket e o manual escreve chamado, a busca por palavra não relaciona os dois. Também sofre com pergunta curta que depende do contexto da conversa.
É rodar os dois métodos e combinar os resultados em uma lista só. Costuma ser melhor que qualquer um isolado, e é o destino natural de um projeto que começou pelo caminho simples e mediu o ganho de cada peça.
Além do serviço em si, ele adiciona um passo pago na indexação e outro em cada consulta, e cria uma segunda cópia dos dados que precisa ficar sincronizada com o texto. É complexidade operacional permanente, não só uma linha no orçamento.
Construa a busca por palavra primeiro e meça com perguntas reais. Ela vira sua linha de base, e qualquer coisa mais sofisticada passa a ter que provar em quanto melhora. Sem linha de base, a decisão é fé.
