Qual é o melhor tamanho de chunk para RAG?

Não há uma resposta universal, mas um bom ponto de partida é de 400 a 512 tokens com 10 a 20 % de sobreposição. Em seguida, ajuste ao seu tipo de consulta: 128 a 256 tokens para busca precisa de fatos, e 512 a 1024 tokens para consultas analíticas ou de resumo. Avalie alguns tamanhos com suas próprias perguntas em vez de confiar em um único valor padrão.

O chunking semântico é melhor que o de tamanho fixo?

Não de forma confiável. O chunking semântico agrupa frases por tópico, o que soa melhor, mas os benchmarks mostram que seus ganhos em relação ao chunking recursivo ou de tamanho fixo são inconsistentes e muitas vezes não justificam a computação extra de embedding. O chunking fixo e o recursivo continuam sendo linhas de base fortes e baratas: comece por aí e só mude para o semântico se sua avaliação mostrar um ganho real.

O que é late chunking e quando devo usá-lo?

O late chunking gera primeiro o embedding do documento inteiro com um modelo de embedding de contexto longo e depois agrupa os embeddings dos tokens em chunks, de modo que o vetor de cada chunk carrega contexto de todo o documento, não apenas do seu próprio texto. Use-o para documentos longos com dependências de longo alcance, em que um trecho só faz sentido com o contexto anterior.

A recuperação contextual realmente melhora a precisão?

Sim, de forma mensurável. A Anthropic relatou que antepor a cada chunk uma nota de contexto gerada por LLM reduziu as falhas de recuperação no top-20 em 35 % com embeddings contextuais, 49 % combinado com BM25 contextual, e 67 % com reranking adicionado, tudo a cerca de US$ 1,02 por milhão de tokens de documento usando cache de prompts. Compensa sobretudo em corpora de alto valor onde um trecho perdido sai caro.

Com qual estratégia de chunking devo começar?

Com chunking recursivo de cerca de 500 tokens e 15 % de sobreposição. Ele respeita os limites naturais, é barato e é uma linha de base forte para a maioria dos conteúdos. Adicione divisão sensível à estrutura para PDFs e manuais, recuperação de documento pai quando as respostas precisarem de mais contexto, e recuperação contextual apenas onde o que está em jogo justificar o custo extra.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Estratégias de chunking para RAG: tamanhos, sobreposição e o que funciona

O chunking define o teto de qualidade do RAG antes mesmo de a recuperação começar. Este guia compara as seis estratégias que dominam a prática, fornece números concretos de tamanho e sobreposição e explica qual se encaixa em cada tipo de consulta.

Por que o chunking determina a qualidade do RAG

O chunk é a unidade que o seu recuperador de fato busca, então os limites dos chunks definem o teto de tudo o que vem depois. Chunks pequenos demais fazem com que cada embedding fique sem sinal suficiente para ser encontrado de forma confiável; chunks grandes demais diluem o sinal do trecho relevante, tornando o vetor incapaz de corresponder à consulta. Se você erra no chunking, nenhum reranker ou modelo maior vai resgatar o recall: o trecho certo nunca foi recuperado. É por isso que o chunking, e não a escolha do modelo, costuma ser o primeiro parâmetro a ajustar.

As seis estratégias que dominam a prática

A prática atual se agrupa em seis abordagens:

Tamanho fixo: trechos iguais de tokens ou caracteres com sobreposição. A mais antiga, barata e reproduzível, e uma linha de base surpreendentemente forte.
Recursivo: divide segundo uma hierarquia de separadores (parágrafo → linha → frase) para não ultrapassar um limite de tamanho respeitando os limites naturais. O padrão recomendado.
Semântico: agrupa frases por similaridade de embedding para que cada chunk trate de um único tópico. Os ganhos em relação ao recursivo são inconsistentes e custam computação extra de embedding.
Sensível à estrutura: divide com base na estrutura do documento (títulos, seções, páginas, markdown). A melhor para PDFs, manuais e documentos financeiros.
Late chunking: gera primeiro o embedding do documento inteiro com um modelo de contexto longo e depois agrupa os embeddings dos tokens em chunks, de modo que cada chunk carrega contexto global.
Recuperação contextual: antepõe a cada chunk um trecho de contexto gerado por LLM antes da indexação.

Comece pelo recursivo; recorra aos demais quando seus documentos ou tipos de consulta exigirem.

Tamanho do chunk e sobreposição: números concretos

Não existe um tamanho universalmente ideal, mas há bons pontos de partida. Comece com cerca de 400–512 tokens e 10–20 % de sobreposição (cerca de 50–100 tokens em um chunk de 500 tokens). Em seguida, ajuste o tamanho ao tipo de consulta: chunks pequenos (128–256 tokens) favorecem a busca precisa de fatos e palavras-chave, enquanto chunks maiores (512–1024 tokens) favorecem consultas analíticas e de resumo, em que o fluxo narrativo importa.

A sobreposição evita que o significado seja cortado em um limite: pouca demais fragmenta o contexto, muita infla o índice e duplica recuperações. O benchmark da NVIDIA encontrou cerca de 15 % de sobreposição como ideal em documentos financeiros, e que o chunking em nível de página entregou a precisão mais alta e mais consistente em corpora mistos, com consultas factuais atingindo o pico entre 256–512 tokens e as analíticas acima de 1024.

Avançado: recuperação contextual e late chunking

Duas técnicas mais recentes atacam o mesmo problema: um chunk que diz "a receita aumentou 15 %" é inútil se você não sabe de qual empresa ou trimestre se trata.

A recuperação contextual da Anthropic antepõe a cada chunk uma nota de contexto de 50–100 tokens gerada por LLM, antes tanto do embedding quanto da indexação BM25. Frente a uma taxa base de falha de 5,7 % no top-20, os embeddings contextuais reduziram as falhas em 35 %, adicionar BM25 contextual as reduziu em 49 %, e adicionar reranking as reduziu em 67 %, tudo a cerca de US$ 1,02 por milhão de tokens de documento com cache de prompts.

O late chunking da Jina inverte o processo: gera o embedding do documento completo com um modelo de contexto longo (até ~8192 tokens) e depois agrupa os embeddings de tokens contextualizados em chunks, de modo que cada embedding de chunk já carrega contexto entre chunks. Use-o para documentos longos com dependências de longo alcance.

Recuperação de documento pai e metadados

Dois refinamentos compensam quase sempre. A recuperação de documento pai ("do pequeno para o grande") desacopla a granularidade de recuperação da geração: indexa chunks filhos pequenos (≈100–500 tokens) para correspondência precisa, mas devolve ao modelo a seção pai maior (≈500–2000 tokens) para que ele tenha o contexto circundante. E o enriquecimento de metadados — anexar fonte, título da seção, número de página e carimbos de tempo a cada chunk — melhora a filtragem, permite citações e eleva a precisão de recuperação independentemente do tamanho do chunk.

Escolher e ajustar no osFoundry

Um guia rápido de decisão: o recursivo é o padrão seguro; sensível à estrutura ou em nível de página para documentos estruturados; semântico para prosa tematicamente densa; late chunking para documentos longos com um embedder de contexto longo; recuperação contextual para corpora de alto valor onde a perda de contexto sai cara; documento pai quando você precisa de precisão e contexto ao mesmo tempo.

O osFoundry trata tudo isso como configuração, não como código. O chunking automático vem com um padrão recursivo sensato, e o pipeline RAG personalizado permite ajustar tamanho, sobreposição e estratégia por base de conhecimento, com o reranking e a recuperação de documento pai como chaves de etapa do pipeline. Como as etapas são configuráveis, você pode fazer testes A/B das configurações de chunking na sua própria distribuição de consultas — factuais versus analíticas — mantendo fixo o restante do stack, que é exatamente o fluxo de trabalho de parâmetros ajustáveis recomendado pela pesquisa.

Frequently asked questions

Qual é o melhor tamanho de chunk para RAG?: Não há uma resposta universal, mas um bom ponto de partida é de 400 a 512 tokens com 10 a 20 % de sobreposição. Em seguida, ajuste ao seu tipo de consulta: 128 a 256 tokens para busca precisa de fatos, e 512 a 1024 tokens para consultas analíticas ou de resumo. Avalie alguns tamanhos com suas próprias perguntas em vez de confiar em um único valor padrão.
Quanta sobreposição os chunks devem ter?: De dez a vinte por cento do tamanho do chunk, ou seja, cerca de 50 a 100 tokens em um chunk de 500 tokens. A sobreposição evita que o significado seja cortado em um limite; pouca demais fragmenta o contexto na divisão, e muita infla o índice e causa recuperações quase duplicadas. A NVIDIA encontrou cerca de 15 % como ideal em documentos financeiros.
O chunking semântico é melhor que o de tamanho fixo?: Não de forma confiável. O chunking semântico agrupa frases por tópico, o que soa melhor, mas os benchmarks mostram que seus ganhos em relação ao chunking recursivo ou de tamanho fixo são inconsistentes e muitas vezes não justificam a computação extra de embedding. O chunking fixo e o recursivo continuam sendo linhas de base fortes e baratas: comece por aí e só mude para o semântico se sua avaliação mostrar um ganho real.
O que é late chunking e quando devo usá-lo?: O late chunking gera primeiro o embedding do documento inteiro com um modelo de embedding de contexto longo e depois agrupa os embeddings dos tokens em chunks, de modo que o vetor de cada chunk carrega contexto de todo o documento, não apenas do seu próprio texto. Use-o para documentos longos com dependências de longo alcance, em que um trecho só faz sentido com o contexto anterior.
A recuperação contextual realmente melhora a precisão?: Sim, de forma mensurável. A Anthropic relatou que antepor a cada chunk uma nota de contexto gerada por LLM reduziu as falhas de recuperação no top-20 em 35 % com embeddings contextuais, 49 % combinado com BM25 contextual, e 67 % com reranking adicionado, tudo a cerca de US$ 1,02 por milhão de tokens de documento usando cache de prompts. Compensa sobretudo em corpora de alto valor onde um trecho perdido sai caro.
O que é recuperação de documento pai (do pequeno para o grande)?: Ela desacopla como você faz a correspondência do que você devolve. Você indexa chunks filhos pequenos para correspondência precisa, mas quando um corresponde, entrega ao modelo a seção pai maior para que ele tenha o contexto circundante. Isso lhe dá o recall dos chunks pequenos e a coerência dos grandes sem abrir mão de nenhum dos dois.
Com qual estratégia de chunking devo começar?: Com chunking recursivo de cerca de 500 tokens e 15 % de sobreposição. Ele respeita os limites naturais, é barato e é uma linha de base forte para a maioria dos conteúdos. Adicione divisão sensível à estrutura para PDFs e manuais, recuperação de documento pai quando as respostas precisarem de mais contexto, e recuperação contextual apenas onde o que está em jogo justificar o custo extra.