Capítulo 3 — Frameworks Avançados de Chunking
Terceiro post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Onde escolhas ingênuas degradam, no silêncio mais quieto, tudo o que vem depois — e onde duas técnicas recentes mudaram o que é possível na fronteira.
Por que este capítulo existe
Uma vez parseados os documentos, a próxima decisão é também a mais consequente: como quebrá-los em pedaços pequenos o bastante para embedar e grandes o bastante para ainda significar algo por conta própria. Isso é chunking. Um chunk que separa uma definição do seu qualificador vai ser recuperado com confiança e estará errado. Um chunk que junta cinco tópicos sem relação dilui todo embedding que toca. O sistema de recuperação que você constrói por cima só consegue preservar o que o passo de chunking preservou, e os modos de falha aqui são silenciosos — o retriever ainda retorna candidatos, o modelo ainda produz respostas fluentes, e só o usuário percebe que as respostas estão sutilmente erradas.
3.1 O espectro do chunking
Ajuda ordenar as estratégias pelo quanto sabem do documento. Numa ponta, chunking de tamanho fixo não sabe nada — conte tokens, corte. Rápido, determinístico, aceitável para texto curto estilisticamente uniforme (transcrições de chat, entradas de FAQ, avaliações de clientes). Em documentos técnicos estruturados é um desastre silencioso. Chunking recursivo aplica uma lista priorizada de separadores — parágrafos, depois quebras de linha, depois frases, depois palavras — dividindo na fronteira de maior prioridade que caiba no tamanho-alvo. Quase tão barato quanto o de tamanho fixo e substancialmente melhor. Este é o default certo para a maioria dos times.
Chunking semântico move a decisão da sintaxe para o significado: embed cada frase, ande pela sequência, marque fronteiras de tópico onde a similaridade entre frases adjacentes cai abaixo de um limiar. Funciona bem em prosa longa onde pistas estruturais são fracas (relatórios de analista, transcrições de entrevista) e mal em documentos técnicos estruturados onde referências cruzadas densas e boilerplate repetido confundem os embeddings de frase. Chunking consciente de estrutura trata o documento parseado como uma árvore e segmenta por ela — por seção, por nível de cabeçalho, por função no código. Bem feito é a forma mais fiel; sem um parser consciente de layout a montante produz o mesmo do chunking recursivo, porque a estrutura nunca foi extraída. Essas quatro são alternativas, não uma pilha para empilhar junto.
3.2 O mito do overlap e o penhasco de contexto
Quase todo tutorial recomenda overlap de 15–20%. A intuição até está certa — overlap previne perdas de fronteira — mas a curva achata rápido. Os primeiros 10% recuperam a maior parte do benefício. Passando uns 25%, a acurácia está essencialmente plana enquanto o custo sobe em três eixos: contas de embedding escalam linearmente com a contagem de chunks, tamanho de índice e latência de query crescem, e os top resultados do retriever começam a ser quase-duplicatas uns dos outros. Uma query do usuário casa com uma passagem nos chunks A, B e C; a janela de contexto é consumida sem chegar informação nova; o reranker queima orçamento reordenando variantes do mesmo conteúdo. Um time mirando 30–40% de overlap deveria ler isso como sinal de que o chunker está errado, não de que o overlap está baixo.
Aparentado mas distinto é o penhasco de contexto: a queda abrupta na qualidade de recuperação quando um chunk perde os termos-âncora que o tornavam encontrável. Um parágrafo que abre com "A emenda de 2023 à Política 47-B exigiu que todas as agências..." e descreve a exigência nas frases seguintes. Corte depois da abertura, e o chunk descritor da exigência não menciona mais a política, a emenda nem o ano. Vai ser recuperado com confiança para queries não relacionadas e errar as canônicas. Recuperação é top-k — ou o chunk emerge ou não, sem degradação suave. O penhasco é o modo dominante de falha em corpora técnicos, onde pronomes e formas curtas carregam o antecedente para a frente ao longo de uma seção.
3.3 Casar tamanho de chunk ao tipo de query
Tamanho de chunk é frequentemente debatido como se houvesse uma única resposta certa. Não há, porque a resposta certa depende das queries que o sistema vai receber. Uma query factual — "qual foi a franquia da política 47-B em 2024?" — quer 150–300 tokens, estreito o bastante para ser preciso, largo o bastante para desambiguar. Uma query de raciocínio — "sumarize as mudanças entre as versões de 2023 e 2024 e explique como elas afetam a renovação" — quer 800–1.200 tokens para preservar o tecido conjuntivo dentro de uma seção. O tamanho ótimo difere em 4–8x entre as duas, e o tráfego em produção é geralmente uma mistura.
Duas respostas produtivas. Indexação multi-granularidade armazena o mesmo corpus em múltiplos tamanhos de chunk e roteia queries por classificação de intenção. Recuperação hierárquica indexa chunks pequenos para precisão mas devolve as seções-pai para contexto — um índice, condicionado em tempo de query, mais comum em produção porque degrada bem quando a classificação de intenção falha. O padrão parent-document é uma das técnicas de maior valor na literatura de recuperação em produção.
3.4 Recuperação contextual e late chunking
A fronteira é o reconhecimento de que o chunk e o embedding são preocupações separáveis. Duas técnicas recentes exploram essa separação em direções opostas. Recuperação contextual, popularizada pela Anthropic em 2024, manda cada chunk mais o documento inteiro para um LLM barato e pede uma descrição de uma ou duas frases de onde o chunk se encaixa — "Este chunk discute a mudança nos cálculos de franquia introduzida pela emenda de 2024 à Política 47-B" — e prepende isso ao texto do chunk antes de embedar. O chunk vira encontrável para queries que o texto subjacente nunca nomeou. Ganhos reportados são da ordem de 49% de redução em falhas de recuperação na avaliação da Anthropic, mais com busca híbrida e reranking por cima. O truque que torna isso econômico é prompt caching: mande o documento uma vez, processe cada chunk contra a versão cacheada.
Late chunking, introduzido pela Jina AI em 2024, ataca o mesmo problema pelo outro lado. O documento inteiro passa por um modelo de embedding de contexto longo numa única passada, produzindo embeddings em nível de token já contextualizados sobre o documento todo. Só então o documento é chunkado, com o embedding de cada chunk agregado a partir dos seus tokens agora contextualizados. Nenhuma chamada extra de LLM; os embeddings herdam o contexto em nível de documento implicitamente. A restrição é que o modelo de embedding tem que suportar isso nativamente (jina-embeddings-v3/v4 e alguns modelos de pesquisa suportam) e o documento tem que caber na janela do modelo. Para documentos que cabem, late chunking iguala a recuperação contextual a uma fração do custo de indexação. Para documentos que não cabem, recuperação contextual é mais geral. Os dois não são mutuamente exclusivos, e sistemas de produção sérios frequentemente rodam os dois com um passo de deduplicação por cima.
O que o Capítulo 3 prepara
Chunking transforma um documento parseado em uma população de unidades recuperáveis. Cada unidade precisa de algum lugar para morar — armazenada, indexada, consultada com baixa latência, atualizada conforme o corpus muda. Esse lugar é o banco de dados vetorial, e a escolha do banco vetorial é outro tipo de decisão. Chunking é problema de software com custo de software. Seleção de banco é problema de software com consequências de infraestrutura, operação e regulação, e a escolha errada pode levar seis meses para desfazer.
Próximo — Capítulo 4: Escolhendo o Banco de Dados Vetorial Certo. Arquiteturas dedicadas versus extensões, as líderes gerenciadas, o campo open-source, e os três eixos — residência, ops e custo total — que geralmente decidem a escolha real.
