Chunking: estratégias e armadilhas
Como dividir documentos sem destruir o contexto — a decisão que mais afeta a qualidade do RAG.
5 min de leitura
Escolha como aprender
— combine como quiserDica: o vídeo é um resumo visual rápido — o áudio e o texto trazem a aula completa.
O modelo não vê o seu documento — ele vê o trecho que você recortou. Se esse trecho está mal dividido, sem contexto, cortado no meio de uma tabela ou grande demais para ser útil, a resposta vai ser ruim independente de qual LLM você usar. Chunking é a decisão de arquitetura que mais afeta a qualidade do RAG, e é a que a maioria dos projetos erra primeiro.
Por que o chunking importa tanto
Pense no pipeline RAG como um funil de duas etapas: primeiro você recupera os trechos mais relevantes, depois o modelo gera a resposta a partir deles. O modelo só consegue raciocinar sobre o que está na janela de contexto — e o que está na janela de contexto são exatamente os chunks que o retriever selecionou.
Isso cria uma dependência direta: chunk ruim → embedding ruim → retrieval ruim → resposta ruim. Você pode ter o melhor modelo do mundo e uma busca vetorial perfeitamente calibrada, mas se o chunk recuperado cortou a frase antes da conclusão, ou misturou dois assuntos diferentes, o modelo vai alucinar ou responder de forma incompleta.
Além da qualidade, o tamanho do chunk afeta diretamente o custo. Chunks grandes aumentam o número de tokens enviados ao modelo em cada chamada. Se você tem 5 chunks de 1 000 tokens cada no contexto, já são 5 000 tokens só de contexto — antes de contar o prompt e a resposta. Em produção, com milhares de chamadas por dia, isso se acumula rápido.
A boa notícia: chunking é uma decisão que você pode iterar. Não existe estratégia universalmente correta — existe a estratégia certa para o seu tipo de documento e o seu caso de uso.
Estratégias de chunking: do documento aos trechos
Um mesmo documento pode ser dividido de formas muito diferentes. Cada estratégia produz chunks com características distintas de tamanho, coerência semântica e preservação de estrutura.
- Documento · PDF / MD / HTML
- Tamanho fixo · 512 tokens, overlap 50
- Por sentença · ou parágrafo
- Recursivo · · · → · → espaço
- Por estrutura · headings / tabelas
- Semântico · grupo por similaridade
- Chunk · texto + título + seção + fonte
- Embedding · model
- Vector store · OpenSearch / Pinecone
As cinco estratégias principais — e quando usar cada uma
Tamanho fixo é o ponto de partida de quase todo mundo: você define um limite de tokens (por exemplo, 512) e divide o documento nesse intervalo, com um overlap configurável. É simples, previsível e fácil de debugar. O problema é que ele ignora a estrutura do texto — pode cortar uma frase no meio, separar uma pergunta da sua resposta, ou misturar o fim de um tópico com o início do próximo.
Por sentença ou parágrafo respeita as quebras naturais do texto. É melhor que tamanho fixo para prosa corrida, mas produz chunks de tamanho muito variável — um parágrafo pode ter 30 palavras ou 300.
Recursivo é o mais usado na prática para texto geral. Você define uma hierarquia de separadores (\n\n, \n, ., ) e o algoritmo tenta manter o chunk dentro do limite usando o separador mais alto possível. É o que o RecursiveCharacterTextSplitter do LangChain implementa, e funciona bem para a maioria dos documentos.
Por estrutura é o certo quando o documento tem hierarquia explícita: headings Markdown, seções HTML, slides. Você mantém cada seção como unidade mínima e herda o título como metadado automaticamente. Para documentos técnicos com tabelas e blocos de código, essa estratégia evita cortes destrutivos.
Semântico agrupa frases por similaridade de embedding — chunks coesos semanticamente, mas com custo de processamento mais alto na indexação. Faz sentido para corpora grandes e heterogêneos onde a estrutura não é confiável.
Comparativo das estratégias de chunking
| Estratégia | Coerência semântica | Tamanho previsível | Custo de implementação | Melhor para | |
|---|---|---|---|---|---|
| Tamanho fixo | Baixa | Alta | Mínimo | Prototipagem rápida | — |
| Por sentença/parágrafo | Média | Baixa | Baixo | Prosa corrida, artigos | — |
| Recursivo | Média-alta | Média | Baixo | Texto geral, documentação | — |
| Por estrutura | Alta | Variável | Médio | Docs técnicos, wikis, HTML | — |
| Semântico | Alta | Baixa | Alto | Corpora grandes e heterogêneos | — |
Checagem rápida
1. Por que o chunking é tão decisivo no RAG?
Overlap, metadados e as armadilhas que destroem qualidade
Overlap é a sobreposição de tokens entre chunks consecutivos. Se você usa chunks de 512 tokens com overlap de 50, os últimos 50 tokens do chunk N aparecem também no início do chunk N+1. Isso parece desperdício, mas tem um propósito claro: evitar que uma informação importante fique "na costura" entre dois chunks e não seja recuperada por nenhum deles. Para a maioria dos casos, overlap entre 10% e 15% do tamanho do chunk é suficiente. Mais que isso e você começa a duplicar conteúdo no contexto.
Metadados no chunk são tão importantes quanto o texto em si. Cada chunk deve carregar: título do documento, seção ou heading de origem, URL ou caminho do arquivo, e idealmente a data de criação ou atualização. Esses metadados servem para dois fins: filtrar na busca (veremos isso na aula 06) e construir citações na resposta (aula 11). Se você não preservar a proveniência no momento do chunking, vai ser impossível reconstruí-la depois.
As armadilhas mais comuns: chunks grandes demais (acima de 1 000 tokens) injetam ruído no contexto — o modelo recebe informação irrelevante junto com a relevante e pode se confundir. Chunks pequenos demais (abaixo de 100 tokens) perdem contexto — uma frase isolada raramente carrega significado suficiente para o modelo responder bem. E o pior dos casos: cortar uma tabela ou um bloco de código no meio. Tabelas têm cabeçalho + linhas — separadas, ambas ficam ininteligíveis. Código tem dependências entre linhas. Sempre trate tabelas e código como unidades atômicas.
Na prática, começo quase sempre com chunking recursivo de 512 tokens e overlap de 10%. É o ponto de partida mais seguro para texto geral — funciona razoavelmente bem antes de qualquer otimização. Depois, olho para os documentos reais: se tiverem headings claros, mudo para chunking por estrutura e heredo o heading como metadado. Se tiverem tabelas ou código, isolo essas seções antes de qualquer split. Só invisto em chunking semântico quando o corpus é grande, heterogêneo e os resultados do recursivo já estão num teto. A ordem importa: não otimize o chunking antes de ter uma baseline e uma métrica de avaliação — senão você está ajustando no escuro.
O que levar desta aula
Perguntas frequentes sobre chunking
Qual o tamanho de chunk ideal?
Não existe um número universal. Para documentação técnica, 400–600 tokens com overlap de 50–80 tokens é um ponto de partida sólido. Para textos mais narrativos, parágrafos inteiros costumam funcionar melhor do que um limite fixo de tokens. O tamanho certo é o que maximiza a sua métrica de avaliação — por isso a aula 08 (avaliação) é o par obrigatório desta.
Devo re-indexar tudo se mudar a estratégia de chunking?
Sim. Chunking e embedding são inseparáveis — o vetor representa o texto daquele chunk específico. Se você mudar como divide o texto, os vetores antigos ficam inconsistentes com os novos. Re-indexação completa é necessária. Por isso vale a pena ter um pipeline de indexação automatizado desde o início.
O Amazon Bedrock Knowledge Bases faz chunking automaticamente?
Sim — o Knowledge Bases oferece chunking fixo, por sentença e semântico como opções configuráveis. É conveniente, mas você abre mão de controle fino sobre overlap, tratamento de tabelas e metadados customizados. Vamos detalhar isso na aula 09.
Estratégias de chunking
Toque num conceito e depois na definição.