O Dia Em Que Meu RAG “Funcionava” Mas Não Encontrava Nada

Eu tinha um pipeline de RAG rodando. O modelo era bom. O banco de vetores era rápido. Os embeddings estavam corretos. E mesmo assim, uma em cada três queries retornava respostas irrelevantes ou incompletas.

Passei dias investigando o modelo, o prompt, o threshold de similaridade. Nada. O problema era algo que eu tinha tratado como “decisão trivial” na primeira hora do projeto: como eu estava cortando os documentos.

Uma frase crucial — a resposta exata para a query do usuário — estava sendo partida no meio entre dois chunks. Nenhum dos dois chunks fazia sentido sozinho. A busca vetorial não encontrava nenhum deles como relevante. E o modelo, sem contexto adequado, improvisava.

Essa experiência me ensinou algo que o benchmark FloTorch de fevereiro de 2026 depois confirmou com dados: 80% das falhas de RAG vêm da camada de ingestão e chunking, não do LLM. A maioria dos desenvolvedores gasta semanas otimizando prompts e trocando modelos enquanto o retrieval silenciosamente retorna contexto errado a cada três queries.

O chunking é o herói silencioso — ou o vilão devastador — do seu pipeline.

O Paradoxo de 2026: Simples Vence Complexo

Antes de entrar nas estratégias, preciso compartilhar o resultado que mais me surpreendeu este ano.

O benchmark FloTorch (fevereiro de 2026) testou 7 estratégias de chunking em 50 artigos acadêmicos com milhares de queries. O resultado chocou a comunidade:

Chunking recursivo de 512 tokens ficou em primeiro lugar com 69% de precisão. Chunking semântico — que soa mais sofisticado — ficou em 54%, produzindo fragmentos com média de apenas 43 tokens (pequenos demais para carregar contexto suficiente).

A análise da Digital Applied confirmou: a escolha de chunking pode balançar o recall em até 9% no mesmo corpus. E a regra universal de overlap (sobreposição) “não é mais segura de assumir” — um estudo sistemático de janeiro de 2026 usando SPLADE e Mistral-8B encontrou que overlap não trouxe benefício mensurável, apenas aumentou custo de indexação.

A lição: sofisticação nem sempre é melhor. A estratégia “chata” de 512 tokens recursivos superou abordagens que custam 14x mais para processar.

As Abordagens Clássicas

1. Tamanho Fixo (Fixed-Size Chunking)

A mais simples. Define um limite estrito de tokens — por exemplo, cortar a cada 500 tokens. É “cega”: corta no token 500 mesmo que isso parta uma frase vital ao meio.

Quando usar: protótipos rápidos, testes iniciais, validação de que RAG funciona para seu caso de uso. Implementação em 5 minutos.

Quando evitar: qualquer coisa em produção onde precisão importa.

2. Com Sobreposição (Overlap Chunking)

Adiciona uma margem de sobreposição — cada bloco “herda” tokens do anterior (tipicamente 10-20% de overlap). Para um chunk de 500 tokens, 50-100 tokens compartilhados.

O benefício: evita perda abrupta de contexto nas bordas. A ressalva de 2026: o estudo de janeiro mostrou que em certos cenários, overlap não ajuda e só aumenta custo de armazenamento. Teste no seu corpus antes de assumir que precisa.

3. Recursivo (Recursive Chunking)

Em vez de cortar às cegas, usa separadores naturais da linguagem humana. Primeiro tenta dividir por parágrafos; se o bloco ainda for grande demais, divide por frases; depois por sentenças. Respeita a estrutura do texto.

O padrão ouro para início de projetos. O benchmark FloTorch coloca recursivo 512 tokens como #1 em precisão entre as 7 estratégias testadas. Equilibra velocidade, custo e qualidade. Minha recomendação pessoal: comece aqui.

O Próximo Nível

4. Semântico (Semantic Chunking)

Aqui deixamos de lado o número de palavras e focamos no significado. O sistema gera embeddings para cada frase, mede similaridade entre elas, e agrupa frases que pertencem ao mesmo conceito. Quando o assunto muda, corta.

A teoria é elegante. Na prática, os dados de 2026 são ambíguos. O FloTorch colocou semântico em 54% — abaixo do recursivo. O Chonkie benchmark mostrou que é 14x mais lento (0,33 MB/s vs 4,82 MB/s para token-based). Um corpus de 10 GB que indexa em minutos com splitting por token leva horas com semântico.

Uma análise de janeiro 2026 encontrou algo surpreendente: sentence chunking igualou o semântico até ~5.000 tokens — por uma fração do custo.

Quando vale a pena: textos complexos onde conceitos mudam abruptamente (papers acadêmicos multidisciplinares, documentos legais com cláusulas distintas). Quando não vale: corpus grandes onde custo de processamento importa.

5. Recuperação Contextual (Contextual Retrieval)

A técnica de elite em 2026. Antes de salvar qualquer chunk no banco de vetores, um LLM analisa o bloco e o enriquece com contexto do documento inteiro.

Em vez de salvar “O lucro cresceu 10%”, o LLM transforma em: “Na divisão de nuvem da empresa X, no terceiro trimestre de 2025, o lucro cresceu 10%.”

A pesquisa da Anthropic sobre Contextual Retrieval mostrou ganhos significativos de precisão. Mas o custo é proporcional: cada chunk exige uma chamada de LLM para enriquecimento. Para milhões de documentos, o orçamento estoura.

O paper CDTA (Cross-Document Topic-Aligned) da UIUC (janeiro 2026) levou isso ao extremo: chunking que reconstrói conhecimento no nível do corpus inteiro. Em HotpotQA (raciocínio multi-hop), atingiu 0,93 de faithfulness vs 0,83 para contextual retrieval e 0,78 para semântico — 12% acima da melhor prática da indústria (p < 0,05).

O “Context Cliff”: Por Que Chunks Não São Só Tamanho

Um achado de janeiro de 2026 que mudou como eu penso sobre chunking: existe um “context cliff” — um penhasco de contexto — por volta de 2.500 tokens onde a qualidade da resposta cai abruptamente. Acima desse ponto, chunks maiores não são melhores — são piores.

Isso se conecta com o fenômeno de “lost in the middle” e o context rot que eu discuti no post sobre janela de contexto. A atenção do modelo se concentra no começo e no final do input. Informação no meio é processada com menos confiança. Chunks de 2.500+ tokens empurram informação crítica para a “zona morta” do meio.

A recomendação prática: chunks entre 256-512 tokens são o sweet spot para a maioria dos casos de uso. Grandes o suficiente para carregar contexto. Pequenos o suficiente para evitar o context cliff.

Meu Playbook Atualizado

Depois de apanhar bastante e pesquisar os benchmarks de 2026, aqui está o que eu uso:

Passo 1: Comece com recursivo 512 tokens. É o #1 do FloTorch. Implementação simples. Custo baixo. Precisão surpreendentemente alta. Adicione 10-15% de overlap, mas teste se realmente ajuda no seu corpus específico.

Passo 2: Implemente retrieval híbrido. Combine busca vetorial (dense) com BM25 (keyword). Muitas falhas que parecem ser de chunking são na verdade de retrieval — a busca vetorial pura não encontra matches por keyword.

Passo 3: Adicione re-ranking. Depois da busca inicial, use um cross-encoder para reordenar por relevância real. Isso compensa imprecisões do chunking.

Passo 4: Contextual Retrieval seletivo. Aplique enriquecimento contextual apenas nos documentos mais críticos (contratos, regulamentos, manuais de segurança). Não em todo o corpus. O custo não justifica para documentação genérica.

Passo 5: Monitore precisão de retrieval. Não assuma que funciona. Implemente métricas (RAGAS, faithfulness, answer relevancy) e monitore em produção. 80% dos problemas de RAG estão no chunking/retrieval — e você só descobre monitorando.

Conclusão: O Herói Silencioso (Ou o Vilão)

Chunking não é sexy. Não aparece em demos. Ninguém posta thread no Twitter sobre “minha nova estratégia de chunking”. Mas é a decisão que mais impacta a qualidade do seu RAG — mais que o modelo, mais que o prompt, mais que o banco de vetores.

E o resultado mais contra-intuitivo de 2026 é que a estratégia “simples” frequentemente vence a “sofisticada”. Recursivo 512 tokens superou semântico em benchmark rigoroso. O overlap nem sempre ajuda. E chunks menores (256-512) superam chunks maiores na maioria dos cenários.

Sofisticação é tentadora. Mas resultados são o que importa. E os dados de 2026 estão dizendo algo claro: comece simples, meça, e adicione complexidade apenas quando os dados justificarem.

Compartilhe se isso salvou seu pipeline:

80% das falhas de RAG vêm do chunking. E a estratégia mais simples costuma ser a melhor. Os dados de 2026 provaram — e meu bolso confirma.

Leia Também