Chunking em RAG: como dividir documentos corretamente

Chunking é a etapa em que um documento longo é dividido em pedaços menores antes de virar embedding e entrar num banco de dados vetorial. Ela acontece antes de tudo — antes da busca, antes do reranking, antes da resposta gerada pelo modelo — e por isso costuma ser o gargalo silencioso de sistemas de RAG: se o pedaço de texto recuperado não faz sentido sozinho, nenhuma etapa seguinte consegue compensar.

O que é chunking, exatamente?

Um LLM não lê o documento inteiro a cada pergunta. Em um pipeline de [RAG](/artigo/rag-retrieval-augmented-generation-o-que-e-como-funciona), o texto é dividido em partes menores — os chunks — que são transformadas em [embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia) e armazenadas num [banco de dados vetorial](/artigo/banco-de-dados-vetorial-o-que-e-como-funciona). Quando alguém faz uma pergunta, o sistema busca os chunks mais parecidos com ela, e só esses trechos — não o documento inteiro — entram no contexto enviado ao modelo. Chunking é, portanto, a decisão de onde cortar o texto para que cada pedaço continue fazendo sentido sozinho.

Por que o tamanho do chunk decide a qualidade da resposta

Segundo a documentação oficial do LangChain sobre text splitters, chunks menores tendem a reduzir o custo de recuperação e geração — menos tokens ocupando a [janela de contexto](/artigo/tokens-janela-de-contexto-llm) do modelo — mas correm o risco de perder informação contextual mais ampla, já que o embedding é calculado só sobre aquele pedaço pequeno. Chunks maiores preservam esse contexto, mas podem incluir informação irrelevante que dilui a resposta final.

As principais estratégias de chunking

Frameworks como LangChain e LlamaIndex documentam abordagens diferentes para dividir texto, cada uma com um trade-off entre simplicidade e preservação de estrutura:

• Divisão por tamanho fixo: corta o texto a cada N caracteres ou tokens, sem olhar para a estrutura do conteúdo. É a mais simples e a mais propensa a cortar frases ao meio.
• Divisão recursiva por caracteres: tenta preservar parágrafos e frases inteiras. Segundo a documentação do LangChain, o RecursiveCharacterTextSplitter divide o texto seguindo uma lista de separadores, na ordem quebra de parágrafo, quebra de linha, espaço e caractere vazio — o que mantém parágrafos e sentenças juntos sempre que possível.
• Divisão por sentenças: separa o texto em frases completas antes de agrupá-las em chunks. É a estratégia padrão do SentenceSplitter da LlamaIndex, segundo a documentação oficial do framework.
• Chunking hierárquico e sentence window: técnicas da LlamaIndex que mantêm referência entre um chunk e seus vizinhos ou seu nó pai, permitindo recuperar contexto adicional só quando necessário.
• Chunking semântico: em vez de um tamanho fixo, mede a similaridade de embedding entre frases consecutivas e cria um novo chunk quando essa similaridade cai abaixo de um limite — abordagem descrita em guias técnicos como o da Pinecone sobre estratégias de chunking.

Chunk size e chunk overlap: como escolher

chunk_size define o tamanho máximo de cada pedaço; chunk_overlap define quanto do fim de um chunk se repete no início do próximo, para não perder informação que ficou na fronteira entre dois pedaços — essa é a definição usada pela documentação do LangChain. Como ponto de partida, a documentação da LlamaIndex mostra que o SentenceSplitter usa por padrão chunk_size de 1024 tokens com chunk_overlap de 200 tokens; a documentação da DataStax RAGStack, por sua vez, recomenda começar com 1024 tokens e overlap de 128. Nenhum desses números é uma regra fixa — são pontos de partida para testar com o seu conteúdo e o seu modelo de embedding.

from langchain_text_splitters import RecursiveCharacterTextSplitter

# valores de partida — ajuste testando com o seu conteúdo
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    length_function=len,
    is_separator_regex=False,
)

chunks = text_splitter.create_documents([texto_do_documento])

Chunking semântico: quando vale a pena

Chunking semântico tende a produzir recuperação mais precisa porque cada chunk reflete uma unidade de sentido, não um número arbitrário de caracteres — mas isso tem custo: cada frase do documento precisa passar por um modelo de embedding antes mesmo de decidir onde cortar, o que aumenta o tempo e o custo de indexação. Para bases pequenas ou pouco atualizadas, esse custo extra costuma compensar. Para bases grandes que mudam com frequência, a divisão recursiva por caracteres continua sendo o ponto de partida mais usado na prática.

Erros comuns ao dividir documentos para RAG

• Cortar tabelas, blocos de código ou listas no meio, quebrando a estrutura que dava sentido ao conteúdo.
• Usar o mesmo tamanho de chunk para todo tipo de documento — um contrato jurídico e um changelog de código não se comportam da mesma forma.
• Não usar overlap nenhum, perdendo informação que ficou exatamente na fronteira entre dois chunks.
• Escolher o tamanho do chunk sem testar contra perguntas reais dos usuários — chunking é uma decisão que precisa ser validada, não só configurada.
• Ignorar o limite de tokens do modelo de embedding: chunks maiores que esse limite são truncados silenciosamente.

Quando revisitar sua estratégia de chunking

Alguns sinais indicam que o chunking está prejudicando o RAG: respostas incompletas mesmo quando a informação existe na base, trechos recuperados que fazem sentido isolados mas não respondem à pergunta, ou um banco de dados vetorial cheio de chunks quase idênticos por causa de overlap excessivo. Nesses casos, o problema geralmente não está no modelo de linguagem nem no [banco de dados vetorial](/artigo/banco-de-dados-vetorial-o-que-e-como-funciona) — está na forma como o texto foi cortado antes de virar embedding.

Chunking é uma decisão de arquitetura, não um detalhe de implementação: ela influencia diretamente a qualidade do retrieval e, por consequência, tudo que vem depois — do [fine-tuning como alternativa](/artigo/fine-tuning-llms-o-que-e-como-funciona-quando-usar) até os riscos cobertos em [Segurança em RAG](/artigo/seguranca-em-rag-riscos-como-proteger).