Estratégias de chunking: como o texto é fatiado antes de virar citação

Quatro formas de fatiar um documento

Não existe tamanho de chunk universal — a escolha depende da estrutura do documento de origem. As quatro abordagens mais usadas em pipelines de RAG:

Overlap: a cola semântica entre blocos

Overlap é a porção de texto repetida entre o fim de um chunk e o início do próximo. Sem ele, uma frase partida na fronteira entre dois blocos perde força de recuperação nos dois lados. Se alguém buscar por uma entidade cujo nome ficou dividido entre o final do Bloco 1 e o início do Bloco 2, nenhum dos dois chunks isoladamente representa bem essa entidade.

Por que “mandar o documento inteiro” não substitui o chunking

Com janelas de contexto de centenas de milhares a milhões de tokens, é tentador achar que fatiar texto virou desnecessário. Um estudo de Stanford e UC Berkeley — hoje publicado na Transactions of the Association for Computational Linguistics — mostrou o motivo pelo qual isso é um erro de arquitetura: o efeito conhecido como “Lost in the Middle”.

O experimento reposicionou o documento com a resposta certa em diferentes pontos de um contexto longo, cercado de documentos-distração. O resultado forma uma curva em U: a precisão é mais alta quando a informação relevante está no início ou no fim do contexto, e cai de forma consistente quando ela está no meio — mesmo em modelos explicitamente projetados para contexto longo.

Vale uma ressalva honesta: pesquisas mais recentes, testando modelos de contexto longo de última geração, encontraram esse efeito atenuado ou ausente em algumas tarefas simples de busca factual — sinal de que os labs vêm mitigando o problema, não de que ele deixou de existir estruturalmente. Para conteúdo que compete em pipelines de RAG com chunking explícito (o cenário real da maioria das buscas por IA hoje), a lição prática se mantém: não conte com o modelo para “encontrar” a informação em qualquer lugar do texto.

As outras duas razões para fatiar mesmo com contexto gigante

Além do Lost in the Middle, dois fatores de engenharia pura sustentam o chunking mesmo quando a janela de contexto permite enviar tudo:

Latência. Processar um documento inteiro exige atenção computacional proporcionalmente maior. Para sistemas que precisam responder rápido — busca dinâmica, chat de atendimento — blocos menores e mais precisos reduzem o tempo até o primeiro token de resposta.

Custo. Enviar milhares de tokens redundantes a cada consulta encarece a operação. O chunking cirúrgico garante que só os três ou cinco blocos que de fato respondem à pergunta sejam enviados ao modelo — o resto do documento nunca precisa entrar na requisição.

Como escrever para sobreviver ao corte

• 01 Estruture por H2/H3 como se cada seção fosse lida isolada. É provável que seja — o corte estrutural trata cada seção como unidade própria.
• 02 Repita a entidade em vez de usar pronome. Se “esse sistema” foi citado três parágrafos acima, mas os parágrafos caem em chunks diferentes, o segundo bloco perde o sujeito da frase. Prefira nomear de novo: “[Nome do produto] executa esta automação”.
• 03 Não deixe a resposta principal depender do parágrafo anterior. Cada bloco autônomo deve fazer sentido sozinho, sem precisar do que veio antes para ser entendido.
• 04 Evite misturar dois tópicos no mesmo bloco. Se dois assuntos cabem sob o mesmo H2, considere dividir em H3 separados — reduz o risco de diluição semântica dentro de um único chunk.