RAG sem banco vetorial: quando full-text search resolve melhor

O que é RAG sem banco vetorial

RAG, ou Retrieval-Augmented Generation, e a técnica de buscar informações relevantes em uma base de dados antes de mandar a pergunta para um modelo de linguagem. A ideia e simples: em vez do modelo responder só com o que aprendeu no treinamento, ele recebe um contexto extra buscado na hora.

Quando RAG virou popular, o banco de dados vetorial virou sinonimo de RAG. Pinecone, Weaviate, Qdrant, Milvus: todo tutorial começava instalando um desses. A lógica parecia óbvia, já que embeddings são vetores e vetores precisam de banco vetorial.

Só que essa equivalência e um exagero. Busca por similaridade semântica e apenas uma forma de recuperar contexto relevante. Para uma fatia grande dos casos reais, técnicas mais antigas como full-text search com BM25 fazem o trabalho igual ou melhor, com muito menos peca nova no sistema.

Como funciona

Busca vetorial funciona transformando texto em embeddings, vetores numéricos que capturam significado semântico, e depois comparando distancia entre vetores para achar o que é mais parecido. Isso e ótimo quando a pergunta usa palavras diferentes do documento, mas o sentido e o mesmo.

Full-text search com BM25, o algoritmo por trás do Elasticsearch e do PostgreSQL tsvector, funciona por correspondência lexical ponderada. Ele conta quantas vezes um termo aparece, penaliza termos muito comuns e favorece documentos onde o termo e raro e relevante.

A diferença prática: buscas vetoriais brilham em linguagem natural ambígua. Busca lexical brilha quando o usuário já sabe termos técnicos, nomes de função, códigos de erro ou jargão específico do domínio. Muita base de conhecimento técnica se encaixa exatamente nesse segundo caso.

Principais recursos

As abordagens sem banco vetorial dedicado trazem algumas vantagens concretas:

• Menos infraestrutura: usar o banco relacional que você já tem, sem subir um serviço novo.
• Busca híbrida: combinar BM25 com filtros estruturados (data, categoria, autor) de forma nativa em SQL.
• Debug mais simples: resultado de full-text search e explicável, você ve exatamente por que um documento apareceu.
• Latência previsível: índices invertidos são maduros ha décadas, sem as surpresas de performance de índices vetoriais em escala.
• Custo menor: sem taxa de serviço gerenciado de banco vetorial, sem custo extra de embeddings para reindexar.

Como começar: instalação ou acesso passo a passo

Se você já usa PostgreSQL, o caminho mais direto e o módulo tsvector nativo, disponível desde versões antigas do banco.

ALTER TABLE documentos ADD COLUMN search_vector tsvector;
UPDATE documentos SET search_vector = to_tsvector('portuguese', conteúdo);
CREATE ÍNDEX idx_search ON documentos USING GIN(search_vector);

Para projetos que precisam de mais recursos de ranking e faceted search, Elasticsearch ou OpenSearch são alternativas maduras, com suporte a BM25 configurável e agregações.

Docker run -d --name elasticsearch -p 9200:9200 \
  -e discovery.type=single-node \
  Docker.elastic.co/elasticsearch/elasticsearch:8.15.0

Depois disso, a integração com o LLM segue igual a qualquer pipeline RAG: buscar os top-k documentos, montar o prompt com esse contexto e chamar o modelo.

Exemplo prático

Imagine uma base de documentação interna de uma API com 500 páginas. Um desenvolvedor pergunta: como faço autenticação com refresh token no endpoint /auth/refresh.

Com full-text search, a query busca literalmente os termos refresh token e /auth/refresh, que são exatamente os termos usados na documentação. O resultado bate na primeira tentativa, sem gerar embedding nenhum.

SELECT titulo, conteúdo,
  ts_rank(search_vector, query) AS relevância
FROM documentos, plainto_tsquery('portuguese', 'refresh token auth') query
WHERE search_vector @@ query
ORDER BY relevância DESC
LIMIT 5;

Esse resultado alimenta o prompt do LLM, que gera a resposta final citando o trecho correto da documentação. Zero infraestrutura de banco vetorial precisou entrar no caminho.

Comparação com alternativas

As alternativas mais comuns hoje são busca vetorial pura, busca lexical pura (BM25) e busca híbrida, que combina as duas com um passo de reranking.

Busca vetorial pura vence quando a pergunta do usuário e muito diferente do vocabulário da base, como perguntas em linguagem coloquial sobre conteúdo técnico formal. Busca lexical pura vence quando o domínio tem vocabulário controlado, como código, logs, tickets de suporte com nomenclatura padronizada.

Busca híbrida, hoje suportada nativamente por bancos como Elasticsearch, Weaviate e Postgres com extensões, tende a dar o melhor dos dois mundos, mas custa mais complexidade de manutenção e tuning dos pesos entre os dois métodos.

Pontos positivos e limitações

O ponto forte de abandonar o banco vetorial e a simplicidade operacional. Times pequenos ganham tempo não precisando aprender uma peca de infraestrutura nova, monitorar mais um serviço ou pagar por mais um SaaS.

A limitação real aparece quando o domínio tem muita variação linguística, sinónimos, gírias ou quando o usuário formula perguntas muito diferentes do texto original. Nesses casos, BM25 sozinho perde recall de forma perceptivel.

Casos de uso reais

Startup com documentação técnica interna: equipe pequena, domínio com vocabulário controlado (nomes de API, códigos de erro). Full-text search resolve com Postgres que já esta em produção.

SaaS de atendimento ao cliente: perguntas dos usuários finais em linguagem natural e coloquial, muita variação de fraseado. Aqui busca vetorial ou híbrida tende a performar melhor.

Ferramenta de busca em código-fonte: desenvolvedores buscam por nomes exatos de função, classe ou variável. Busca lexical com boa tokenização de código supera busca semântica na maioria dos casos.

Base de conhecimento jurídica ou medica: terminologia técnica específica, mas com muitos sinónimos entre termos leigos e termos formais. Busca híbrida costuma ser o equilíbrio certo.

Dicas e boas práticas

Vale a pena?

Vale a pena considerar full-text search antes de qualquer outra coisa se a sua base tem vocabulário controlado, se o time e pequeno e se você já tem um banco relacional em produção. A complexidade extra de um banco vetorial só se paga quando o ganho de qualidade e mensurável.

Para quem tem linguagem muito variável entre pergunta e documento, ou trabalha com múltiplos idiomas e sinónimos, busca vetorial ou híbrida ainda faz sentido. O próximo passo e simples: teste full-text search primeiro, meca a qualidade real com perguntas reais, e só evolua para vetorial se o recall não for suficiente.