Texto ruidoso em RAG: erros de digitação e OCR que quebram suas buscas

O problema silencioso que quebra buscas em RAG

Um usuário digita “assurance décennale” em um chatbot corporativo, mas o documento original grafa “décennale”. Uma letra a menos — e a busca literal não encontra nada. Perguntas reais chegam com erros de digitação, e documentos reais têm os seus próprios. Antes de qualquer recuperação funcionar, alguém precisa corrigir a grafia dos dois lados.

Esse é o problema do texto ruidoso em RAG (Retrieval-Augmented Generation). De fora, parece um problema de corretor ortográfico. Na prática, a causa se divide em três fontes distintas, e o corretor clássico resolve apenas uma delas.

Este guia é uma expansão da série Enterprise Document Intelligence, de Kezhan Shi, publicada no Towards Data Science. Ele mostra onde o corretor ortográfico clássico funciona, onde ele falha, e por que os embeddings carregam o restante do problema — com estratégias práticas para cada cenário.

Prós e contras da abordagem

✅ O que você ganha ao tratar o ruído de texto de forma consciente:

• Recuperação muito mais precisa em corpora com tickets, chat logs e PDFs escaneados;
• Pipeline híbrido determinístico (SymSpell + Metaphone) que é auditável e O(1), com LLM apenas como fallback;
• Custo controlado: o embedding corta milhões de chunks para ~10 candidatos antes de chamar o LLM;
• Camada de correção ortográfica que cresce com o tempo, específica do domínio;
• Entendimento claro de quando limpar documentos e quando deixar os embeddings absorverem o ruído.

⚠️ O que você NÃO ganha:

• Não existe correção mágica: a limpeza é um processo contínuo, não um projeto de uma vez só;
• Números de similaridade (cosseno) variam conforme o modelo de embedding — a ordenação importa mais que o valor absoluto;
• Distância de Levenshtein não serve como sinal de recuperação em chunks de tamanhos diferentes.

As três fontes de ruído

O mesmo sintoma — um token que não casa literalmente com o que deveria — tem três origens diferentes:

A caixa de ferramentas clássica de correção ortográfica foi construída para o primeiro caso. Os outros dois são os que mais machucam pipelines empresariais — e são exatamente os que os embeddings absorvem bem.

Quarenta anos de correção ortográfica clássica

Antes dos embeddings e LLMs, correção ortográfica era um problema de engenharia resolvido. Cinco técnicas cobrem quase tudo que rodou em produção entre 1980 e hoje:

1. Distância de Levenshtein

O número mínimo de edições de um caractere (inserir, apagar, substituir) para transformar uma palavra em outra. É a base de quase todo corretor das últimas quatro décadas. Roda em tempo O(n·m): rápido para uma palavra, mas caro em um documento de 50 mil palavras.

from rapidfuzz.distance import Levenshtein
Levenshtein.distance("coverage", "covrage")  # 1 (apaga o 'o')
Levenshtein.distance("coverage", "covarage")  # 1 (insere 'a')

2. BK-tree

A árvore de Burkhard-Keller (1973) indexa o dicionário para que todas as palavras a distância k de uma consulta sejam alcançáveis em ~O(log n), usando a desigualdade triangular. É o que faz aspell e hunspell parecerem instantâneos.

import pybktree
tree = pybktree.BKTree(Levenshtein.distance, ["coverage", "average", "overage", "leverage"])
tree.find("covrage", n=1)  # [(1, 'coverage')]

3. Soundex e Metaphone

Códigos fonéticos que mapeiam palavras que soam parecidas para a mesma chave. Úteis até hoje para sobrenomes, nomes de medicamentos e pós-processamento de voz-para-texto.

from jellyfish import soundex, metaphone
soundex("Smith"), soundex("Smyth")  # ('S530', 'S530')
metaphone("through"), metaphone("thru")  # ('0R', '0R')

4. SymSpell

A variante moderna e rápida. Pré-computa todas as deleções até distância k de cada palavra do dicionário e guarda em hash. A consulta vira um join de hash, sub-milissegundo para 100 mil palavras em um núcleo de CPU. O dicionário deve ser construído do próprio corpus, não de uma lista genérica.

from symspellpy import SymSpell, Verbosity
sym = SymSpell(max_dictionary_edit_distance=2)
sym.create_dictionary_entry("coverage", count=1000)
sym.lookup("covrage", Verbosity.CLOSEST, max_edit_distance=2)

5. n-gramas de caracteres

Indexa cada palavra como um conjunto de substrings de n caracteres e pontua similaridade por sobreposição de Jaccard. É a base do Elasticsearch (edge-ngram) e do pg_trgm no PostgreSQL.

Onde o clássico falha (e os embeddings vencem)

Dê ao corretor uma palavra errada com correção clara no dicionário, e ele resolve em microssegundos. O problema é que as outras duas fontes de ruído — transcrição rápida (fronteiras embaralhadas, acentos perdidos, substituições de palavras reais) e erros de OCR (ligaduras quebradas, “l” virando “1”) — fazem a distância de edição crescer com o tamanho da frase. E o grep não retorna nada.

Os embeddings carregam os dois casos: o cosseno de uma frase com erro de digitação ou corrompida por OCR fica na mesma faixa de recuperação que um match limpo, porque o embedding enxerga a frase como um todo — e ruído por caractere em um token mal move o vetor quando os tokens vizinhos carregam o sentido.

A divisão prática para RAG empresarial

A estratégia recomendada é um cascade de normalização em dois caminhos:

Para corpora volumosos, a receita do cascade página → linha → LLM:

• Embede no nível de linha, não de página — chunks menores diluem menos o sinal;
• Use embeddings como método primário, não BM25 (embeddings absorvem typos; BM25 os amplifica);
• Mantenha um dicionário de especialista mapeando formas canônicas para variantes vistas no corpus (coverage → covarge, covrage, coverag…);
• Deixe um LLM ler o top-k retornado pelo embedding — a chamada a nível de linha custa frações de centavo por candidato.

O fallback via LLM deve corrigir apenas a grafia, sem reformular:

CORRECTION_PROMPT = (
    "Fix the spelling of this question. Do not change the meaning, "
    "do not rephrase, do not add information. Output the corrected "
    "question on a single line, nothing else.\n\n{query}"
)

Cada correção feita pelo LLM deve ser registrada em log. Com o tempo, as correções mais frequentes viram candidatas ao índice SymSpell, ao dicionário do especialista ou ao mapa de abreviações — o fallback fica gradualmente redundante.

Troubleshooting

❌ Sintoma: a busca retorna vazio para consultas com typos óbvios.
→ Causa: recuperação baseada em BM25 amplifica o erro em vez de absorvê-lo.
→ Solução: troque o método primário por embeddings e use BM25 apenas como sinal secundário.

❌ Sintoma: Levenshtein ordena chunks corretamente, mas nenhum limiar separa os relevantes.
→ Causa: distância escala com a diferença de tamanho, não com a distância semântica.
→ Solução: use Levenshtein palavra-a-palavra contra o dicionário, nunca como primitivo de recuperação.

❌ Sintoma: OCR quebra ligaduras e confunde “l” com “1”.
→ Causa: o documento passou por escaneamento e o erro se espalha por vários caracteres.
→ Solução: confie no embedding para o chunk inteiro; limpe apenas documentos canônicos de alto valor.

❌ Sintoma: o dicionário do SymSpell não sugere termos do próprio negócio.
→ Causa: dicionário construído de lista genérica, não do corpus.
→ Solução: construa o dicionário a partir do próprio corpus, para que as correções caiam nos termos que aparecem nos documentos.

❌ Sintoma: custo de LLM sobe ao corrigir milhões de chunks.
→ Causa: LLM chamado em cada chunk em vez de apenas no top-k.
→ Solução: deixe o embedding cortar de milhões para ~10 candidatos e só então chame o LLM na linha única.

FAQ

Corretor ortográfico clássico resolve o problema de RAG?
Não sozinho. Ele resolve erros de digitação de palavra única contra um dicionário, mas falha em ruído de transcrição rápida e erros de OCR — que são a maioria em corpora empresariais.

Por que embeddings absorvem typos?
Porque enxergam a frase como um todo. Ruído por caractere em um token move pouco o vetor quando os tokens ao redor preservam o sentido, mantendo o cosseno na faixa de um match limpo.

Devo limpar todos os documentos antes de indexar?
Não. Limpe uma vez os documentos canônicos de alto valor. Para corpora volumosos e de baixo valor por documento, otimize a busca em vez de limpar tudo.

BM25 ou embeddings para recuperação com texto ruidoso?
Embeddings como primário. BM25 amplifica typos; embeddings os absorvem.

Como manter a correção ortográfica atualizada?
Trate qualidade de dados como melhoria contínua: registre cada falha de consulta, deixe o especialista curar a correção e o dicionário crescer. Em seis meses você terá uma camada específica do domínio que nenhuma ferramenta pronta produz.

Para onde isso caminha

À medida que agentes de RAG assumem mais fluxos de trabalho em empresas, o ruído de texto deixa de ser um detalhe e vira um diferencial competitivo. A direção é clara: menos limpeza massiva, mais recuperação projetada para o ruído — com embeddings como primeira linha e LLMs usados cirurgicamente no topo. Quem dominar essa divisão vai extrair respostas úteis de dados que hoje ficam invisíveis.