Chunking em RAG: como dividir documentos e melhorar respostas
Chunking em RAG divide documentos em fragmentos pesquisáveis. Entenda estratégias, tamanho, sobreposição e testes para melhorar a recuperação e as respostas.
Uma base de conhecimento pode conter a resposta exata e, ainda assim, um sistema RAG não encontrá-la.
Muitas vezes, o problema começou antes da busca: o documento foi dividido de um jeito que separou a informação do contexto necessário para compreendê-la.
Chunking em RAG é o processo de transformar documentos em fragmentos menores, pesquisáveis e adequados à recuperação.
Esses fragmentos, chamados de chunks, costumam ser convertidos em embeddings e armazenados para que os trechos mais relevantes sejam encontrados quando uma pergunta chega.
Dividir tudo a cada 500 caracteres parece simples, mas pode cortar uma definição ao meio, separar uma tabela do título ou criar trechos tão genéricos que vários deles parecem igualmente relevantes.
No extremo oposto, blocos muito grandes carregam ruído, consomem mais contexto e dificultam localizar a passagem precisa.
Neste guia, você entenderá como o chunking afeta a qualidade de um RAG, quais estratégias existem, quando usar sobreposição e como testar tamanho, estrutura e contexto com dados do seu próprio projeto.
O que é chunking em RAG?
Chunking é a divisão de uma fonte maior — como manual, contrato, página, planilha ou transcrição — em unidades menores que podem ser indexadas e recuperadas separadamente.
Em um sistema de RAG em IA, cada unidade precisa ser pequena o bastante para favorecer uma busca precisa, mas completa o suficiente para continuar fazendo sentido fora do documento original.
O conceito faz parte da preparação da memória externa usada pelo sistema. O trabalho que consolidou o termo Retrieval-Augmented Generation combinou a memória paramétrica do modelo com uma memória não paramétrica recuperada de um índice. Em aplicações atuais, o chunk é uma das unidades candidatas a entrar nessa memória recuperada.
Chunk não é sinônimo de página nem precisa ter comprimento uniforme. Pode representar uma seção com título, um conjunto de parágrafos relacionados, uma linha de tabela acompanhada de cabeçalhos ou uma função de código com a documentação necessária.
Por que a divisão dos documentos afeta as respostas?
A recuperação compara a consulta com as unidades indexadas. Se uma regra e sua exceção estiverem em chunks diferentes, o sistema pode recuperar apenas metade da orientação.
Se o título “Política de reembolso internacional” ficou longe do parágrafo “o prazo é de 15 dias”, esse parágrafo isolado perde a informação que o distingue de outras políticas.
Chunks pequenos aumentam a granularidade e podem aproximar a busca da passagem exata.
Porém, também multiplicam itens no índice e removem relações importantes. Chunks grandes preservam mais vizinhança, mas misturam assuntos, tornam os embeddings menos específicos e ocupam mais espaço na janela enviada ao modelo.
Por isso, chunking não é apenas uma etapa de formatação. Ele define o que a busca consegue enxergar como uma unidade coerente e influencia relevância, fundamentação, latência e custo.
Como o chunking entra no pipeline de RAG
- Os arquivos são extraídos e normalizados. Cabeçalhos, parágrafos, tabelas e metadados precisam ser reconhecidos.
- Uma regra de chunking transforma cada documento em unidades pesquisáveis.
- Cada chunk recebe metadados e, na busca semântica, é convertido em vetor.
- Os vetores e o conteúdo são armazenados em um banco de dados vetorial ou mecanismo equivalente.
- Quando chega uma pergunta, a busca recupera os chunks candidatos, possivelmente combina busca lexical, filtros e reranking.
- Os melhores trechos entram no contexto do modelo, que produz a resposta.
Uma falha no começo atravessa todo o fluxo. Melhorar o prompt final não recompõe um trecho que foi extraído sem cabeçalho ou uma tabela cuja coluna perdeu o significado.
Antes de ajustar a geração, vale inspecionar o texto realmente indexado.
O que caracteriza um bom chunk?
Um bom chunk costuma concentrar uma ideia, preservar as referências necessárias e informar sua origem. Lido isoladamente, ele permite identificar sobre quem ou sobre o que fala, em qual seção aparece e se há condições associadas.
- Coesão: as frases tratam do mesmo assunto ou cumprem uma função conjunta.
- Autonomia: pronomes, títulos e referências não tornam o trecho ambíguo demais.
- Granularidade útil: a unidade corresponde ao tipo de pergunta que o usuário fará.
- Metadados: fonte, seção, data, versão, produto e permissões acompanham o conteúdo.
- Limites naturais: títulos, parágrafos, itens e blocos de código são respeitados sempre que possível.
Principais estratégias de chunking
Não existe uma técnica única para todo corpus. O guia de arquitetura da IBM sobre chunking compara abordagens por tamanho, frase, conteúdo, página e estrutura, destacando que a escolha depende da fonte e dos requisitos da aplicação.
Tamanho fixo
Divide o texto após um número definido de caracteres ou tokens. É rápido, previsível e forma uma boa linha de base.
Sua limitação é ignorar o significado: uma sentença, uma lista ou uma cláusula pode ser cortada no ponto menos conveniente.
Divisão recursiva
Tenta separar primeiro por unidades maiores, como seções e parágrafos. Se elas excederem o limite, usa separadores menores, como sentenças e palavras.
Continua simples, mas costuma preservar melhor os limites naturais do que o corte fixo puro.
Estrutura do documento
Usa títulos Markdown, tags HTML, capítulos, artigos de uma norma ou elementos do arquivo.
Funciona bem quando a estrutura é confiável. Uma seção curta pode permanecer inteira; uma seção extensa pode ser subdividida enquanto herda o caminho de títulos.
Sentenças e parágrafos
Agrupa unidades linguísticas completas até atingir um limite. É útil para FAQs, mensagens e textos bem escritos.
Parágrafos, entretanto, variam muito: alguns têm uma linha; outros ocupam uma página. Por isso, ainda é necessário controlar máximos.
Chunking semântico
Procura mudanças de assunto por similaridade ou por um modelo e cria limites onde o significado se desloca.
Pode gerar unidades mais coesas em textos irregulares, mas aumenta processamento, parâmetros e dificuldade de depuração. O nome “semântico” não garante melhora automática.
Páginas e layout visual
Preserva páginas, caixas, tabelas e coordenadas reconhecidas por um parser de layout.
É importante em PDFs nos quais a posição carrega significado. A página, porém, é um limite de impressão: uma seção pode começar em uma e terminar na seguinte.
Chunking contextual e hierárquico
O sistema pode indexar uma unidade pequena, mas recuperar também seu bloco pai, ou acrescentar a cada fragmento um resumo curto de onde ele aparece. A proposta de Contextual Retrieval da Anthropic, por exemplo, adiciona contexto específico antes de criar embeddings e índice lexical. A ideia ajuda quando trechos isolados perdem empresa, período, produto ou seção.
Como escolher o tamanho dos chunks
Não há um tamanho universal. Comece pelo menor trecho que responde com segurança às perguntas reais e pelo maior trecho que ainda mantém foco.
O intervalo precisa considerar densidade do texto, idioma, modelo de embedding, recuperador, quantidade de resultados e janela de contexto disponível.
Medir em tokens aproxima o limite usado pelos modelos; medir em caracteres é mais fácil, mas varia em relação à tokenização. O importante é registrar a unidade para comparar configurações corretamente.
Parâmetros de plataformas servem como referência operacional, não como receita.
Em agosto de 2026, a documentação da OpenAI para arquivos de vector stores informa que a estratégia automática usa atualmente até 800 tokens com 400 de sobreposição e permite personalização.
Esse padrão pode mudar e não prova que a mesma combinação seja ideal para outro corpus.
Quando usar sobreposição entre chunks
Sobreposição, ou chunk overlap, repete parte do final de um fragmento no início do próximo.
Ela reduz a chance de uma informação importante desaparecer justamente na fronteira de um corte fixo e pode preservar antecedente, definição ou continuação.
O recurso é menos necessário quando a divisão respeita seções autônomas.
Em excesso, cria duplicatas quase idênticas, aumenta armazenamento, faz resultados repetidos ocuparem o top-k e envia conteúdo redundante ao modelo.
Antes de ampliar overlap, verifique se melhorar o parser ou escolher limites naturais resolve a causa.
Exemplos por tipo de documento
| Fonte | Ponto de partida | Cuidado principal |
|---|---|---|
| Manual de produto | Seção e subtítulo, com subdivisão por tamanho | Herdar produto, versão e caminho de títulos |
| FAQ | Um par pergunta-resposta por chunk | Não separar pergunta da resposta |
| Contrato ou norma | Cláusula, artigo e seus incisos relacionados | Manter definições, exceções e vigência |
| PDF com tabelas | Bloco de layout ou tabela completa com cabeçalhos | Evitar linhas sem nome de coluna e unidade |
| Base de código | Função, classe ou módulo com assinatura e documentação | Preservar dependências e caminho do arquivo |
| Transcrição | Turnos agrupados por tópico e tempo | Manter falante e referência temporal |
Essas sugestões são hipóteses iniciais. Um manual de suporte consultado por código de erro pode exigir busca lexical; um contrato consultado por comparação pode precisar recuperar a cláusula e também a seção pai.
Como preservar contexto sem criar blocos gigantes
O contexto perdido pode ser devolvido de maneira seletiva. Acrescente ao chunk o caminho de títulos, o nome do documento, a versão e uma identificação curta do assunto.
Em tabelas, repita cabeçalhos; em transcrições, mantenha falante e data; em normas, preserve o artigo pai.
Outra opção é a recuperação pai-filho: unidades pequenas são usadas para encontrar correspondência, mas o sistema entrega ao modelo uma seção maior associada.
Também é possível recuperar vizinhos apenas quando necessário ou resumir o contexto global antes da indexação.
Essa decisão faz parte da engenharia de contexto. O objetivo não é preencher a janela, e sim selecionar evidências suficientes, distintas e rastreáveis.
Estudos como o LongRAG mostram que unidades maiores também podem ser úteis em determinadas configurações, reforçando que “menor é sempre melhor” não é uma regra.
Como testar uma estratégia de chunking
1. Monte perguntas representativas
Reúna perguntas reais ou plausíveis e marque quais passagens contêm a evidência necessária.
Inclua buscas exatas, perguntas conceituais, exceções, comparação entre seções e casos sem resposta. Sem esse conjunto, a equipe tende a aprovar os exemplos que já funcionam.
2. Compare poucas configurações
Escolha uma linha de base simples e altere uma variável por vez. Compare, por exemplo, divisão recursiva com e sem cabeçalhos; depois teste dois tamanhos e uma sobreposição moderada.
Se estratégia, embedding, top-k e prompt mudarem juntos, será difícil explicar o resultado.
3. Avalie recuperação antes da resposta
Verifique se o top-k contém a passagem correta, em qual posição ela aparece e quanto conteúdo duplicado foi recuperado. Inspecione falhas por tipo de documento e pergunta.
Uma resposta ruim pode vir de recuperação insuficiente ou de geração inadequada; separar as etapas reduz o diagnóstico por tentativa e erro.
4. Meça a resposta final e os custos
Depois da recuperação, avalie correção, cobertura, citação, fidelidade às fontes e comportamento quando não há evidência.
Registre também número de chunks, tokens enviados, armazenamento e latência. Um guia de evals em IA ajuda a transformar esse processo em comparação repetível.
Erros comuns no chunking em RAG
- Copiar um tamanho recomendado sem testar o próprio corpus.
- Indexar texto extraído de PDF sem inspecionar ordem, tabelas, hifenização e OCR.
- Remover títulos para “limpar” o conteúdo e perder o contexto que diferencia seções.
- Usar grande sobreposição como solução para qualquer corte ruim.
- Permitir que chunks de versões antigas e novas concorram sem metadados.
- Avaliar apenas a resposta final e não observar o que foi recuperado.
- Mudar o chunking sem reconstruir o índice correspondente.
- Ignorar filtros de acesso ao copiar trechos de documentos restritos.
Checklist prático
- Defina quais perguntas o sistema precisa responder.
- Inspecione a extração antes de criar embeddings.
- Respeite títulos, parágrafos, listas, tabelas e código.
- Faça o chunk carregar fonte, seção, versão e permissões.
- Comece com uma técnica simples e reproduzível.
- Teste tamanhos em tokens e registre os valores usados.
- Use overlap apenas quando a fronteira realmente causa perda.
- Meça recuperação, resposta, latência e custo.
- Guarde a configuração junto da versão do índice.
- Reavalie quando o corpus ou o padrão de perguntas mudar.
Perguntas frequentes
Qual é o melhor tamanho de chunk para RAG?
Não existe um valor universal. O melhor tamanho recupera evidência suficiente com pouco ruído para as perguntas do projeto.
Use padrões de ferramentas como linha de base e compare alternativas em um conjunto de avaliação.
Chunk overlap é sempre necessário?
Não. A sobreposição ajuda em cortes por tamanho, mas pode ser dispensável quando cada unidade respeita uma seção autônoma.
Overlap excessivo aumenta duplicação e pode reduzir a diversidade dos resultados.
É melhor medir chunks em caracteres ou tokens?
Tokens são mais próximos dos limites dos modelos e do custo de processamento.
Caracteres simplificam a implementação, mas a relação entre caracteres e tokens varia por idioma e conteúdo.
A comparação precisa usar sempre a mesma unidade e o mesmo tokenizador.
Um PDF deve ser dividido por página?
Somente quando a página representa uma unidade lógica útil. Em relatórios e livros, uma ideia pode atravessar a quebra de página.
Use análise de layout, títulos e blocos, mantendo o número da página como metadado para citação.
Chunking semântico sempre melhora o RAG?
Não. Ele pode criar limites mais coerentes, mas adiciona custo e complexidade. Em documentos bem estruturados, a divisão por títulos pode ser mais transparente e eficiente. O ganho deve aparecer nas métricas de recuperação e resposta.
É preciso reindexar ao mudar o chunking?
Sim. Alterar limites muda o conteúdo e normalmente os embeddings, IDs e metadados das unidades. Crie uma nova versão do índice, execute os testes e faça a troca controlada, mantendo possibilidade de retorno.
Conclusão
Chunking em RAG define a matéria-prima da recuperação. Um fragmento precisa ser localizável sem perder o contexto que o torna correto.
Tamanho, sobreposição e técnica são meios para alcançar esse equilíbrio, não metas isoladas.
Comece com uma estratégia simples, preserve a estrutura da fonte e compare configurações usando perguntas reais.
Quando a passagem certa aparece de forma consistente, com contexto suficiente e pouca redundância, o modelo recebe condições melhores para responder com precisão e mostrar de onde veio a informação.