O que Ninguém Me Contou Sobre RAG Quando Comecei a Estudar Retrieval

Índice

O que é Information Retrieval
Tokenização
Pré-processamento de Texto
Como Modelos de IA Enxergam Tokens
Os Três Modelos de Retrieval
TF-IDF
Vetores e Cosine Similarity
Boolean Retrieval e Índices Invertidos
BM25
Retrieval como Base do RAG
Referências e Próximos Passos

1 O que é Information Retrieval

Toda vez que alguém me pergunta por que um sistema de IA está dando respostas ruins, minha primeira pergunta é sempre a mesma: "o que está sendo recuperado antes de chegar no modelo?". Em 90% dos casos, o problema está ali.

Information Retrieval é a área da computação dedicada a encontrar informações relevantes em grandes volumes de dados com base em uma consulta. Está presente em mecanismos de busca, e-commerces, sistemas de recomendação, assistentes virtuais e, cada vez mais, como a camada crítica debaixo de qualquer sistema de RAG.

1.1 Uma perspectiva histórica que importa

Não é por acaso que IR tem décadas de pesquisa acumulada. O sistema SMART, desenvolvido nos anos 1960, introduziu conceitos que usamos até hoje: representação vetorial de documentos e pesagem de termos. O BM25 foi publicado no final dos anos 1990 e ainda é o algoritmo padrão de busca em produção em 2026. Algoritmos de ranqueamento por estrutura de links revolucionaram o campo em 1998, indo além do conteúdo textual puro.

Por que isso importa? Porque quando alguém me propõe substituir BM25 por embeddings neurais "porque é mais moderno", minha resposta é: mostre os números. Décadas de refinamento não se descartam sem evidência. E frequentemente os dados mostram que BM25 bem configurado supera embeddings mal implementados.

1.2 Os três pilares

Indexação é a preparação dos dados antes da busca. Cada documento é processado, dividido em partes menores e armazenado em uma estrutura que permite recuperação rápida. Um índice bem construído é a diferença entre resposta em milissegundos e varredura que levaria horas. Em sistemas com bilhões de documentos, não há outra opção.

Querying é a interpretação da consulta do usuário. O que parece simples esconde complexidade real: como tratar sinônimos? Erros de digitação? Intenções diferentes por trás da mesma frase? A maioria dos sistemas que vejo em produção subestima essa etapa e paga o preço em qualidade de resultados.

Ranking é onde a diferença real é feita. Encontrar documentos que correspondem à consulta é fácil. Colocá-los na ordem certa é difícil. Estudos de UX mostram que usuários raramente passam da segunda posição nos resultados. Se o documento certo está na posição 15, para o usuário é como se não existisse.

1.3 Métricas que realmente uso

Precisão@K: dos K primeiros resultados, quantos são relevantes? Uso quando o sistema tem limite de exibição e resultados irrelevantes no topo causam dano real à experiência.

Recall@K: de todos os documentos relevantes do corpus, quantos aparecem no top-K? Uso em sistemas onde deixar escapar um documento crítico é inaceitável, como sistemas médicos ou de compliance.

MRR (Mean Reciprocal Rank): média do recíproco da posição do primeiro resultado relevante. É minha métrica favorita para sistemas onde o usuário quer a resposta, não uma lista. Reflete bem a experiência real.

A escolha de qual métrica otimizar não é técnica. É uma decisão de produto que precisa ser tomada antes de qualquer linha de código.

1.4 Por que IR virou competência obrigatória para quem trabalha com IA

Com RAG (Retrieval Augmented Generation), Information Retrieval deixou de ser território exclusivo de engenheiros de busca. Todo time que constrói aplicações com LLMs precisa entender retrieval.

A lógica é simples: o LLM só pode responder bem com base no contexto que recebe. Se o retrieval entrega contexto errado, o modelo vai gerar uma resposta errada, independentemente de quão sofisticado ele seja. Não existe LLM bom o suficiente para compensar retrieval ruim de forma consistente.

2 Tokenização

Tokenização é o passo onde a maioria das pessoas não para para pensar. É o primeiro passo do pipeline, então qualquer erro aqui se propaga por todo o sistema. Já vi sistemas com meses de desenvolvimento quebrados por uma inconsistência de tokenização que levou minutos para encontrar e cinco segundos para corrigir.

A ideia é simples: antes de qualquer processamento, o texto precisa ser dividido em unidades discretas que o computador possa manipular. Essas unidades são os tokens.

2.1 Os três tipos e quando uso cada um

Word Tokenization é meu ponto de partida padrão para retrieval e indexação. Divide texto em palavras individuais. Para a maioria dos sistemas de busca, é tudo que você precisa.

Sentence Tokenization uso quando preciso manter coerência contextual, especialmente na criação de chunks para RAG. Dividir um documento em sentenças antes de agrupar em chunks garante que eu não vou cortar uma ideia no meio.

Character Tokenization raramente uso em retrieval. Tem seu lugar em correção ortográfica e idiomas com sistemas de escrita complexos, mas para busca em português, word tokenization cobre 95% dos casos.

2.2 Implementação

A pergunta que sempre recebo: por que não usar texto.split(" ")? Porque texto real não é limpo. Pontuação colada ("fascinante." vs "fascinante"), hifens em compostos ("pré-processamento"), contrações, URLs, datas. Uma divisão ingênua por espaço vai criar inconsistências que aparecem como bugs misteriosos três semanas depois. O word_tokenize do NLTK lida com isso.

Para produção com volume alto, prefiro o spaCy. É mais rápido e tem melhor suporte a casos especiais:

2.3 A regra que não abro mão

Use exatamente a mesma função de tokenização nos documentos e nas queries. Sem exceção.

Parece óbvio. Mas já revisei sistemas onde o pipeline de indexação usava spaCy e o pipeline de busca usava NLTK. Os resultados eram inconsistentes de formas que eram quase impossíveis de reproduzir. Encapsule em uma função e chame dos dois lados.

3 Pré-processamento de Texto

Se eu tivesse que escolher uma etapa para revisar em qualquer sistema de retrieval com problemas, escolheria o pré-processamento. É onde mais encontro bugs silenciosos que degradam a qualidade sem gerar nenhum erro.

A afirmação que faço com convicção: a maioria dos sistemas de RAG com problemas de qualidade tem o problema aqui, não no LLM. Antes de trocar o modelo ou ajustar o prompt, revise o pré-processamento.

3.1 O pipeline que uso como padrão

Lowercase é sempre a primeira operação. "Machine" e "machine" são a mesma palavra. Sem normalização, elas viram tokens distintos no índice, diluindo relevância.

Remoção de caracteres não alfanuméricos elimina ruído. Pontuações, símbolos, caracteres especiais raramente carregam informação útil para busca.

Aqui preciso ser cuidadoso com o domínio. Em código-fonte, _ e . têm significado. Em documentos financeiros, % e $ são essenciais. A regra não é remover tudo que não seja letra. É remover o que não carrega informação relevante para o seu corpus específico.

Remoção de stopwords descarta palavras tão frequentes que aparecem em todo documento e não ajudam a diferenciar um do outro.

Exceção que sempre incluo: em sistemas com suporte a busca booleana, preservo "e", "ou" e "não" como operadores lógicos.

Stemming vs Lemmatização: uso stemming quando velocidade importa mais que precisão linguística. Uso lemmatização quando estou num domínio onde formas corretas das palavras são relevantes. Para a maioria dos sistemas de busca em produção, stemming com RSLPStemmer é suficiente.

3.2 A função que coloco em todo projeto

3.3 Os erros que vejo com mais frequência

Pré-processamento diferente em documentos e queries é o mais comum e o mais traiçoeiro porque o sistema não retorna erro. Ele simplesmente retorna resultados piores.

Normalizar acentos no índice mas não na query, ou o contrário, quebra matches de forma silenciosa. Se você decide normalizar ("informação" vira "informacao"), faça nos dois lados.

Usar stemming muito agressivo em domínios técnicos. "neural" e "neurologia" reduzidos à mesma raiz num sistema médico cria matches incorretos que são difíceis de explicar para os usuários.

Não filtrar tokens de comprimento 1. Após remoção de caracteres e stopwords, sobram letras soltas que poluem o índice.

4 Como Modelos de IA Enxergam Tokens

Esta seção é sobre evitar uma confusão conceitual que vejo frequentemente, inclusive em engenheiros experientes: tokens de LLMs e tokens de retrieval são coisas diferentes com propósitos diferentes.

4.1 BPE: a lógica por trás da tokenização de LLMs

Modelos como GPT usam BPE (Byte Pair Encoding). Em vez de dividir por palavras, o BPE aprende um vocabulário de subpalavras a partir dos dados de treinamento. O processo começa com caracteres individuais e iterativamente mescla os pares mais frequentes até atingir o tamanho de vocabulário alvo (tipicamente 50.000 a 100.000 tokens).

O efeito prático: palavras frequentes em inglês viram tokens únicos. Palavras raras, de idiomas menos representados no treinamento ou terminologia muito específica são divididas em fragmentos. "computadores" em português pode virar dois ou três tokens.

Cada token recebe um Token ID, um inteiro único. Esses IDs não têm relação de significado entre si. IDs numericamente próximos não têm nada em comum semanticamente. São etiquetas arbitrárias de lookup table.

4.2 O impacto prático que mais importa no dia a dia

A mesma frase em português que gerava ~90 tokens no GPT-3 gera ~50 tokens no GPT-4. Versões mais antigas quebravam palavras acentuadas em múltiplos fragmentos. As versões mais recentes compactam muito melhor.

Isso impacta custo e context window. Uso tiktoken para estimar antes de colocar em produção:

4.3 Tokens não são embeddings: a distinção que importa

Tokens e Token IDs são a primeira camada: transformam texto em números para processamento computacional. Não carregam significado semântico.

Embeddings são vetores de alta dimensão gerados numa camada posterior da rede neural. Capturam significado e relações semânticas. "machine learning" e "aprendizado de máquina" têm embeddings próximos porque o modelo aprendeu que aparecem em contextos similares. Seus Token IDs não têm nenhuma relação.

Se você está construindo busca semântica, precisa de embeddings, não de Token IDs. São tecnologias diferentes para propósitos diferentes.

5 Os Três Modelos de Retrieval

Existe uma tendência de tratar os modelos de retrieval como uma evolução linear: Boolean é velho, Vector Space é melhor, embeddings neurais são o estado da arte. Não é assim que funciona na prática.

Cada modelo responde de forma diferente à pergunta fundamental: o que significa um documento ser relevante para uma consulta? E dependendo do caso de uso, a resposta certa é diferente.

5.1 Boolean Retrieval

Opera em lógica binária pura. Um documento satisfaz a condição ou não. Sem gradação, sem ranking por relevância.

Operadores: AND (ambos os termos presentes), OR (pelo menos um), NOT (primeiro presente, segundo ausente).

Uso Boolean quando os critérios são absolutamente não negociáveis. Sistemas de compliance que precisam garantir presença de termos regulatórios. Buscas jurídicas com artigos obrigatórios. Filtros de metadados antes de um segundo estágio semântico.

A limitação é conhecida e real: encontra palavras, não significados. "machine learning" não retorna documentos sobre "aprendizado de máquina".

5.2 Vector Space Model

Representa documentos e consultas como vetores e mede similaridade entre eles. Introduz gradação: quão similar é este documento à consulta?

Uso quando semântica importa mais que correspondência exata. Quando usuários descrevem o que querem em vez de nomear documentos. Quando quero ranking por relevância, não filtragem binária.

5.3 Probabilistic Retrieval

Trata relevância como probabilidade. Considera frequência dos termos, raridade no corpus e comprimento do documento. O BM25 é a implementação padrão e vejo ele funcionar bem em praticamente todos os corpora que já trabalhei.

5.4 Comparação honesta

	Boolean	Vector Space	Probabilístico
Resultado	Binário	Gradual	Por score
Produz ranking?	Não	Sim	Sim
Captura semântica?	Não	Parcialmente	Parcialmente
Sensível ao comprimento?	Não	Parcialmente	Trata explicitamente
Meu uso	Filtros obrigatórios	Exploração	Ranqueamento geral

Na prática, a combinação que funciona melhor é Boolean para filtros de metadados (categoria, data, fonte) e BM25 ou embeddings para ranqueamento do conteúdo.

5.5 Como meço qual funciona melhor

Monto um conjunto de perguntas com respostas esperadas antes de qualquer implementação. Isso me dá uma linha de base para comparar abordagens com dados reais, não com intuição.

6 TF-IDF

TF-IDF tem décadas, mas ainda uso em produção. Não por nostalgia, mas porque para muitos casos de uso ele resolve o problema com uma fração da complexidade de alternativas neurais.

A intuição: uma palavra que aparece muito num documento específico, mas raramente no corpus geral, é provavelmente o que caracteriza aquele documento. É exatamente isso que TF-IDF mede.

6.1 A matemática, de forma direta

TF (Term Frequency): frequência do termo no documento, normalizada pelo tamanho:

IDF (Inverse Document Frequency): raridade do termo no corpus:

onde N é o total de documentos e df(t) é o número de documentos que contêm t.

Score final: TF-IDF(t, d) = TF × IDF

O logaritmo no IDF é importante: sem ele, um termo que aparece em apenas 1 de 10.000 documentos receberia IDF = 10.000, dominando qualquer cálculo. Com log, vira ~4.

6.2 Implementação com scikit-learn

O parâmetro ngram_range=(1, 2) é algo que quase sempre incluo. Bigramas capturam contexto que unigramas ignoram: "machine learning" como bigrama é mais informativo que "machine" e "learning" separados. "não funciona" tem significado diferente de "funciona".

6.3 Quando ainda uso TF-IDF em 2026

Quando velocidade é crítica e latência de embeddings não é aceitável. Para corpora com terminologia muito específica não bem coberta por modelos genéricos. Como baseline antes de qualquer abordagem mais complexa. E como componente lexical em pipelines híbridos.

A regra que sigo: se TF-IDF atinge os requisitos de qualidade, não adiciono complexidade. Se não atinge, os resultados do TF-IDF me dizem onde está o gap e o que preciso melhorar.

6.4 Limitações que preciso conhecer

Sem semântica: "machine learning" e "aprendizado de máquina" são completamente diferentes para o TF-IDF. Sem ordem: trata documentos como saco de palavras. Sensível ao corpus: valores de IDF mudam conforme o corpus muda, exigindo reindexação. Em sistemas dinâmicos com inserções frequentes, isso é um custo operacional real.

7 Vetores e Cosine Similarity

A transformação que está no coração de todo retrieval moderno: texto vira vetor, busca vira geometria.

7.1 A intuição geométrica

Com um vocabulário de 3 termos, cada documento é um ponto num espaço tridimensional:

Doc1 está na mesma posição que a query. Doc2 está próximo. Doc3 está numa direção completamente diferente. Na realidade, o vocabulário tem milhares de dimensões, mas a lógica é idêntica.

7.2 Por que Cosine Similarity e não distância euclidiana

Distância euclidiana é sensível à magnitude dos vetores. Um documento longo sobre o mesmo assunto que um documento curto ficaria artificialmente distante. Cosine Similarity mede o ângulo entre vetores, independente do comprimento. Dois documentos que "apontam na mesma direção" têm alta similaridade, mesmo que um seja 10 vezes maior que o outro.

7.3 Sistema de busca vetorial completo

7.4 A universalidade do princípio

O que gosto nessa abordagem é a uniformidade da interface. Com TF-IDF, com Word2Vec, com embeddings de modelos como text-embedding-3-small, o padrão é sempre o mesmo: vetorize os documentos, vetorize a query, calcule cosine similarity, ordene.

A interface é idêntica. O que muda é a qualidade semântica do vetor e o custo computacional de gerá-lo.

7.5 Visualizando similaridade entre documentos

Uma análise que sempre faço ao iniciar com um novo corpus: a matriz de similaridade entre todos os documentos. Revela agrupamentos naturais, documentos quase duplicados e outliers semânticos antes de qualquer busca.

Quando vejo pares com similaridade acima de 0.95, geralmente são documentos duplicados ou quase duplicados que vão criar ruído no retrieval.

8 Boolean Retrieval e Índices Invertidos

Boolean Retrieval é frequentemente descrito como tecnologia legada. Discordo. É a ferramenta certa para um conjunto específico de problemas, e esses problemas aparecem com frequência em sistemas corporativos.

8.1 O índice invertido: a estrutura que torna tudo possível

Um índice invertido mapeia cada termo para a lista de documentos que o contém:

Sem índice invertido, uma busca por "machine" exige percorrer todos os documentos. Com 10 milhões de documentos, é inviável. Com o índice, é uma consulta direta seguida de operações de conjunto. É por isso que o Google responde em milissegundos com índice de bilhões de páginas.

Operações booleanas viram operações de conjunto:

AND → interseção
OR → união
NOT → diferença

8.2 Implementação do zero

8.3 Produção com Whoosh

8.4 Quando uso Boolean em sistemas modernos

Em sistemas de RAG, uso Boolean para filtros de metadados antes do ranqueamento semântico. Documentos de uma fonte específica, dentro de um período de datas, de uma categoria determinada. Isso é mais eficiente e mais preciso do que tentar capturar esses critérios via similaridade semântica.

9 BM25

BM25 é meu algoritmo padrão para retrieval lexical. Antes de qualquer discussão sobre embeddings ou modelos neurais, o BM25 é o baseline que precisa ser estabelecido.

9.1 O que BM25 resolve que TF-IDF simples não resolve

Saturação de frequência: no TF-IDF, contribuição de um termo cresce linearmente com a frequência. Um documento que menciona "machine" 100 vezes recebe contribuição 10 vezes maior que um que menciona 10 vezes. BM25 introduce saturação: após as primeiras ocorrências, mais repetições adicionam pouco ao score. O parâmetro k1 (default 1.2) controla isso.

Normalização por comprimento: documentos longos naturalmente têm mais ocorrências de qualquer termo. BM25 normaliza pelo comprimento do documento em relação ao comprimento médio do corpus. O parâmetro b (default 0.75) controla a intensidade. Isso faz muita diferença em corpora com documentos de comprimentos muito variados.

9.2 Implementação

Ponto importante sobre stopwords: ao contrário do que recomendo para outros modelos, não removo stopwords antes do BM25. O modelo foi projetado para lidar com elas via IDF. Removê-las pode degradar resultados porque certas palavras aparentemente irrelevantes carregam contexto que o BM25 sabe ponderar.

9.3 Tuning dos parâmetros

Os defaults (k1=1.2, b=0.75) funcionam bem para a maioria dos casos. Mas experimento com ajustes quando:

Corpus com documentos muito curtos (tweets, títulos, cabeçalhos): reduzo b para 0.3 a 0.5. Penalizar documentos curtos não faz sentido quando todos são curtos.

Corpus muito técnico onde repetição de termos é informativa: aumento k1 para 1.8 a 2.0. Dou mais peso para frequência alta de termos específicos.

Corpus homogêneo em comprimento: reduzo b, pois normalização por comprimento tem menos valor quando os documentos têm tamanho similar.

9.4 BM25 no Elasticsearch

9.5 Quando BM25 supera embeddings

Terminologia muito específica que não está bem coberta em modelos genéricos: nomes de medicamentos, siglas técnicas, identificadores de produtos, nomenclatura jurídica específica. Esses termos foram subrepresentados no treinamento dos modelos de embedding. BM25 trabalha com o vocabulário real do seu corpus.

Consultas exatas onde o usuário usa a terminologia correta.

Ambientes com restrições de latência ou sem GPU.

E sempre como baseline: se seu sistema com embeddings não supera BM25, o problema não é falta de sofisticação. É bug na implementação mais complexa.

10 Retrieval como Base do RAG

Chegando no ponto onde tudo converge. RAG (Retrieval Augmented Generation) é hoje a forma mais prática e eficaz de construir sistemas de IA generativa com informações atualizadas e específicas de domínio. E o retrieval é a camada que determina se o sistema funciona ou não.

10.1 As limitações dos LLMs que o RAG resolve

São estáticos: treinados até uma data de corte. O que aconteceu depois é invisível.

São generalistas: não conhecem documentos internos da sua empresa, bases de conhecimento proprietárias, contratos específicos.

Alucinam: quando não têm a informação, frequentemente geram respostas plausíveis mas incorretas. Não é bug, é característica: redes neurais generativas sempre produzem texto plausível, mesmo sem a informação real.

RAG resolve os três: recupera documentos relevantes da sua base de conhecimento e os fornece como contexto antes de gerar a resposta.

10.2 A arquitetura que funciona em produção

Fase offline:

Fase online:

10.3 Pipeline RAG completo

10.4 Onde os sistemas de RAG falham de verdade

Depois de revisar dezenas de pipelines com problemas, os padrões de falha são sempre os mesmos:

Chunking inadequado. Chunks muito grandes diluem informação específica entre ruído. Chunks muito pequenos perdem contexto necessário para o LLM formular uma resposta coerente. Não existe tamanho universal. Depende do tipo de documento, da natureza das queries e do limite de contexto do modelo.

Pré-processamento inconsistente. O problema mais comum. Documentos e queries processados de formas diferentes criam discrepâncias que fazem documentos relevantes não serem recuperados. Sem mensagem de erro. Resultados simplesmente piores.

Vocabulário de domínio não coberto. Termos técnicos muito específicos ausentes nos embeddings genéricos. BM25 resolve isso naturalmente. Embeddings de modelos genéricos não.

Rank collapse. Todos os chunks com scores muito próximos, tornando o ranking inútil. Geralmente indica corpus homogêneo demais, pré-processamento muito agressivo ou query muito genérica.

10.5 A arquitetura de RAG que uso em produção

Mas cheguei aqui iterativamente, com dados mostrando onde cada etapa adicional resolvia um problema real. Não comecei com toda essa complexidade.

10.6 A sequência que recomendo

Comece simples. BM25 com chunking por sentenças e pré-processamento consistente. Avalie com um conjunto de perguntas e respostas esperadas. Meça precisão e recall antes de qualquer outra coisa.

Só avance onde os dados mostrarem gap. Se BM25 perde documentos relevantes por questões semânticas, adicione embeddings. Se a latência é problema, otimize o índice primeiro. Se documentos irrelevantes passam, adicione filtros booleanos por metadados.

Sofisticação tem custo. Reranking neural adiciona latência. Fine-tuning de embeddings adiciona custo de treinamento e manutenção. Hybrid retrieval adiciona complexidade de infraestrutura. Cada um desses custos precisa ser justificado por ganho mensurável em qualidade.

A regra que me guia: um sistema simples que funciona bem é melhor do que um sistema complexo que funciona mais ou menos.

11 Referências e Próximos Passos

Bibliotecas usadas neste guia

Biblioteca	Uso	Instalação
`nltk`	Tokenização, stopwords, stemming	`pip install nltk`
`spacy`	NLP em produção	`pip install spacy`
`scikit-learn`	TF-IDF, cosine similarity	`pip install scikit-learn`
`rank-bm25`	Algoritmo BM25	`pip install rank-bm25`
`whoosh`	Índice invertido, Boolean search	`pip install whoosh`
`tiktoken`	Contagem de tokens OpenAI	`pip install tiktoken`
`sentence-transformers`	Embeddings semânticos	`pip install sentence-transformers`

Onde ir a partir daqui

Embeddings e busca semântica: text-embedding-3-small da OpenAI e Sentence Transformers permitem busca por significado. O próximo nível natural depois de dominar BM25.

Reranking neural: modelos cross-encoder como ms-marco-MiniLM refinam o ranking após o primeiro estágio. Adicionam latência, mas ganho de qualidade costuma ser significativo.

Hybrid RAG com RRF: combinação de BM25 e embeddings com Reciprocal Rank Fusion. É a abordagem que melhor performa na maioria dos benchmarks que conheço.

Chunking avançado: semantic chunking divide por coerência semântica em vez de tamanho fixo. Late chunking gera embeddings do documento inteiro antes de chunkar. Ambos melhoram a qualidade dos chunks recuperados.

Avaliação de RAG: RAGAS, TruLens e LangSmith para avaliar end-to-end. Sem métricas, você não sabe se está melhorando.

Vector databases: Qdrant, Weaviate, Chroma e Pinecone para armazenamento e busca em escala. Cada um tem trade-offs diferentes em latência, custo e operação.

A mensagem central que fica

Domine os fundamentos antes de correr para a complexidade. Um pipeline com BM25 bem configurado e pré-processamento consistente vai superar um sistema de embeddings mal implementado. Sempre.

Meça. Itere com dados reais. Avance em complexidade onde os números justificarem, não onde parecer mais sofisticado.

Os artigos individuais de cada seção estão disponíveis na série completa do blog.