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.