Nos últimos artigos da série, cobrimos desde a geometria da busca vetorial e os custos astronômicos de infraestrutura até a criação de Evals automatizados no CI/CD com a Tríade do RAG.
Mas existe uma pergunta brutal que 99% dos times de IA esquecem de fazer antes de gastar milhares de dólares em APIs de embedding e bancos vetoriais em RAM:
"A busca semântica do meu RAG é realmente melhor do que um algoritmo estatístico criado na década de 1970?"
Antes de existir o OpenAI, o DeepSeek ou os vetores densos de 1.536 dimensões, a Ciência da Computação já havia resolvido a busca de dados. E a ferramenta criada em 1972 por Karen Spärck Jones — o TF-IDF — continua sendo o teste de sanidade mais importante que o seu sistema de IA pode passar.
Se você não avalia o seu RAG contra o TF-IDF, você não está fazendo engenharia; está apenas pagando caro por abstração.
1. O que é o TF-IDF? (A genialidade de 1972)
O TF-IDF (Term Frequency - Inverse Document Frequency) é uma métrica estatística projetada para medir o quão importante uma palavra é para um documento dentro de um conjunto de dados.
A matemática por trás dele se divide em duas partes simples e elegantes:
A. Term Frequency (TF) — Frequência do Termo
Mede a frequência com que uma palavra aparece em um texto específico. Se a palavra "kernel" aparece 10 vezes em um bloco de código, ela é estatisticamente relevante para aquele bloco.
TF(termo, documento) = (Ocorrências do termo no documento) / (Total de palavras no documento)
B. Inverse Document Frequency (IDF) — Frequência Inversa no Corpus
Criado por Karen Spärck Jones, o IDF é a verdadeira sacada do algoritmo. Ele penaliza palavras extremamente comuns (como "de", "que", "para", "sistema") e dá um peso gigantesco para palavras raras e informativas (como "posix_spawn", "exceção_404", "contrato_v2").
IDF(termo) = log( Total de documentos no banco / Documentos que contêm o termo )
A pontuação final é o produto das duas partes:
Score TF-IDF = TF × IDF
O resultado é um vetor esparso onde apenas as palavras realmente distintivas da pergunta e do documento ganham destaque matemático.
2. Por que usar uma matemática de 50 anos atrás para avaliar IA?
Modelos de embedding densos (redes neurais) tentam mapear o significado semântico de uma frase. Isso é ótimo para entender que "cachorro" e "cão" são coisas parecidas.
Porém, modelos de embedding sofrem de um mal grave: a diluição de termos exatos.
Quando o seu usuário busca por um número de protocolo específico (PROT-2026-X), um código de erro do sistema (ERR_CONNECTION_REFUSED), ou um nome próprio técnico, a busca vetorial falha com frequência. O modelo esmaga essa informação exata dentro de um vetor contínuo, perdendo o detalhe.
O TF-IDF (e sua evolução direta usada na indústria, o BM25) faz exatamente o oposto: ele é implacável com a presença exata do termo.
3. O TF-IDF como Baseline de Avaliação no CI/CD
Na engenharia de software, você não avalia um sistema novo sem compará-lo com uma linha de base (baseline). O TF-IDF serve exatamente como essa linha de base de custo zero e velocidade ultrarrápida.
Quando você monta a sua suíte de avaliação com o seu Golden Dataset, o seu pipeline de testes deve rodar duas buscas em paralelo:
- Busca A: Vetores densos (GPT-4 / DeepSeek) rodando no seu banco vetorial.
- Busca B: Busca estatística via TF-IDF / BM25 rodando direto na CPU/Disco.
Se a Busca A não superar a pontuação de Context Precision e Recall da Busca B no seu conjunto de dados, o seu RAG tem uma falha estrutural.
Significa que você está pagando por chamadas de API, mantendo gigabytes de memória RAM alocados na nuvem e adicionando latência de rede para entregar um resultado pior do que um script estatístico dos anos 70 rodando em milissegundos na CPU.
4. Como o TF-IDF detecta falhas e salva o seu orçamento
A comparação contra o TF-IDF revela instantaneamente três patologias comuns no seu RAG:
- 1. Padrões de Chunking Ruins: Se o TF-IDF encontra o documento correto e a sua busca vetorial não, o seu tamanho de chunk provavelmente está diluindo os conceitos.
- 2. Alucinações de Semântica: A busca vetorial pode retornar documentos que "soam" no mesmo tom da pergunta, mas não contêm a resposta real. O TF-IDF expõe esse ruído ao mostrar que a interseção de palavras relevantes é nula.
- 3. Decisão de Arquitetura Híbrida: Quando você percebe onde o TF-IDF vence (termos exatos) e onde o vetor vence (conceitos abstratos), você finalmente entende por que precisa de Busca Híbrida (Vetor + BM25) com um re-ranker no final.
Conclusão: Respeite a história da Ciência da Computação
A onda do desenvolvimento baseado em hype fez muitos times esquecerem as ferramentas fundamentais que a Ciência da Computação levou décadas para aperfeiçoar.
O TF-IDF não é uma tecnologia obsoleta; é um dos algoritmos mais elegantes, eficientes e matematicamente sólidos já criados. Ele não gasta GPU, não tem custo por token, executa em microsegundos e serve como o espelho da verdade para o seu sistema de IA.
Antes de contratar mais infraestrutura ou trocar para o modelo de IA da semana, faça o dever de casa da engenharia: rode um benchmark contra o TF-IDF. A resposta pode economizar milhares de dólares do seu projeto.
Top comments (2)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
This is a strong argument for treating retrieval as an empirical engineering problem rather than assuming dense embeddings are automatically superior. I would extend your benchmark beyond TF IDF versus vectors by testing BM25, hybrid retrieval with Reciprocal Rank Fusion, and a cross encoder reranker against the same golden dataset.
The most important metric is not raw similarity but Recall@K, MRR, nDCG, Context Precision, Context Recall, latency, and cost per successful retrieval. I would also segment evaluations by query class: exact identifiers, natural language, synonyms, multilingual queries, and compositional questions.
An even stronger CI pipeline could automatically detect when embedding changes, chunking changes, or corpus growth causes retrieval regression. That turns retrieval quality into an observable production contract instead of a subjective tuning exercise.
Excellent reminder that simple baselines often expose expensive architectural mistakes. I would enjoy comparing RAG evaluation strategies with you.
I would like to get to know you better. Would you please contact me? t_g_@kanelim1997