Chunking: cortar texto é fácil. Cortar sem destruir o contexto é outra história

Na etapa de ingestão de um pipeline RAG, antes de qualquer embedding ser gerado, existe uma decisão que parece trivial e não é: como dividir um documento grande em pedaços menores. Cortar errado ali não aparece como erro óbvio depois. Aparece como busca que devolve resultado impreciso, sem deixar claro que o problema começou lá atrás, no corte.

Corte por tamanho fixo: simples, previsível, e descuidado com sentido

A abordagem mais direta divide o texto em blocos de um número fixo de caracteres ou tokens, sem considerar onde uma frase ou ideia termina. É rápida de implementar e previsível em termos de tamanho de cada pedaço, o que facilita controlar quanto contexto cada chunk vai ocupar depois. O problema é justamente a falta de consideração por sentido: um corte de tamanho fixo pode terminar no meio de uma frase, separando uma afirmação da condição que a qualifica, ou pode juntar o final de um parágrafo com o início de outro completamente sem relação.

Quando isso acontece, o embedding gerado para aquele chunk representa uma mistura de ideias parciais, o que prejudica tanto a precisão da busca (o chunk pode não corresponder bem a nenhuma pergunta específica) quanto a utilidade do resultado recuperado (mesmo encontrado, o trecho pode não fazer sentido completo sozinho).

Corte por frase ou parágrafo: respeitando fronteira natural do texto

Dividir por sentença ou parágrafo usa a própria estrutura do texto como guia de corte, preservando unidades de sentido que já existiam na escrita original. Isso reduz bastante o problema de cortar uma ideia ao meio, porque o ponto de corte coincide com um ponto onde o próprio autor do texto já sinalizou uma pausa natural.

A limitação aparece quando um parágrafo é curto demais para carregar contexto suficiente sozinho, ou longo demais para caber dentro do limite de tamanho desejado para o chunk. Nesses casos, ainda é preciso alguma regra adicional para agrupar parágrafos pequenos ou dividir parágrafos grandes, o que reintroduz parte da complexidade que essa abordagem tentava evitar.

Chunking semântico: cortar onde o assunto muda, não onde o texto acaba

Uma abordagem mais sofisticada usa os próprios embeddings para decidir onde cortar: gerar representações vetoriais de segmentos pequenos de texto (frase por frase, por exemplo) e identificar pontos onde a similaridade entre segmentos consecutivos cai de forma significativa, sinal de que o assunto mudou. O corte acontece nesses pontos de transição, em vez de num limite arbitrário de caracteres ou numa fronteira sintática fixa como parágrafo.

Isso tende a produzir chunks mais coerentes tematicamente, ao custo de mais processamento na etapa de ingestão, porque calcular esses embeddings intermediários e comparar similaridade entre segmentos é trabalho adicional que os métodos anteriores não exigem.

Overlap: uma rede de segurança contra corte na fronteira errada

Independente da estratégia de corte escolhida, sempre existe risco de uma informação relevante ficar dividida entre dois chunks adjacentes, cada um carregando só metade do contexto necessário para fazer sentido completo. Overlap resolve isso parcialmente: em vez de cortar de forma seca, um pedaço do final de um chunk se repete no início do próximo, garantindo que informação próxima a uma fronteira de corte apareça inteira em pelo menos um dos dois chunks.

O custo do overlap é redundância: o mesmo texto acaba armazenado (e embeddado) mais de uma vez, aumentando o volume total de dado no vector store proporcionalmente ao tamanho da sobreposição escolhida.

O tamanho do chunk afeta recall e precisão de formas opostas

Chunks pequenos tendem a favorecer precisão: cada um representa uma ideia mais específica, o que facilita encontrar exatamente o trecho relevante para uma pergunta pontual. Em compensação, um chunk pequeno pode não carregar contexto suficiente para ser útil sozinho, prejudicando recall quando a resposta completa depende de informação espalhada por mais de um trecho.

Chunks grandes fazem o caminho inverso: carregam mais contexto por padrão, o que ajuda recall ao reduzir a chance de perder informação relevante, mas diluem a representação vetorial ao misturar várias ideias num único embedding, prejudicando a precisão de encontrar exatamente o pedaço mais relevante entre vários candidatos parecidos.

Não existe estratégia certa universal, existe estratégia certa para o documento

Nenhuma das abordagens acima é superior em todos os casos. Documentação técnica bem estruturada, com seções e parágrafos claros, costuma se beneficiar de corte por parágrafo. Texto corrido, sem estrutura clara, tende a se beneficiar mais de chunking semântico, apesar do custo extra. A pergunta que deveria guiar a escolha nunca é “qual método é mais avançado”, é “qual corte preserva melhor o sentido específico desse tipo de documento”.