Estratégias de chunking

O Studio divide todo documento enviado em chunks antes de gerar os embeddings. A estratégia controla onde essas divisões acontecem.

Como o chunking funciona

Todo chunker segue um padrão de duas fases:

1. Split — quebra o documento em limites definidos (parágrafos, frases, tokens ou uma regex personalizada)
2. Pack — junta divisões adjacentes até o tamanho máximo do chunk

Isso está documentado no guia de text splitters do LangChain, que enuncia o princípio: "no resulting merged split should exceed the designated chunk size." LlamaIndex, Chonkie e Unstructured seguem a mesma convenção.

A etapa de empacotamento é o que mantém os chunks aproximadamente uniformes. Ela também significa que um chunk normalmente abrange várias divisões — um limite exato de divisão não é a mesma coisa que um limite de chunk. A maioria das surpresas do tipo "por que minha regex não gera um chunk por match" vem daí.

Configurações comuns a todas as estratégias

O guia de chunking do Pinecone cobre os trade-offs de tamanho e overlap.

Estratégias

Auto

O Studio inspeciona o arquivo e escolhe o chunker adequado:

• .json, .jsonl, .yaml, .yml → chunking estrutural (registros nunca são cortados no meio; registros pequenos ainda podem ser agrupados até o tamanho do chunk)
• .csv, .xlsx, .xls, .tsv → agrupados por linha, com os cabeçalhos preservados
• Todo o resto (.pdf, .docx, .txt, .md, .html, .pptx, …) → estratégia Text

O roteamento é baseado no tipo MIME detectado e no formato do conteúdo, não apenas na extensão — um arquivo .txt que contém JSON válido é tratado de forma estrutural.

Escolha Auto, a menos que você tenha confirmado que ela não está gerando os chunks que você quer.

Text

Splitter hierárquico que percorre uma lista de separadores: réguas horizontais → títulos markdown → parágrafos (\n\n) → linhas (\n) → pontuação de frase (. ! ?) → pontuação de oração (; ,) → espaços. Ele tenta primeiro o maior separador e recua quando um pedaço ainda está grande demais.

É o mesmo algoritmo do RecursiveCharacterTextSplitter do LangChain, o padrão de fato para texto corrido.

Use para texto corrido em geral.

Recursive

Mesmo algoritmo da Text, mas você fornece a própria hierarquia de separadores ou escolhe uma receita pronta (plain, markdown, code).

O padrão de receitas vem do Chonkie, que traz conjuntos de separadores prontos para tipos comuns de conteúdo.

Use Recursive quando o seu conteúdo tem marcadores estruturais que os separadores padrão da Text não capturam — dividir código em \nclass , \nfunction e depois \n\n, por exemplo.

Sentence

Divide nos limites de frase (. , ! , ? , com tratamento de abreviações) e empacota frases inteiras até o tamanho do chunk. Uma frase nunca é cortada no meio, a menos que ela sozinha exceda o limite.

Essa é a técnica por trás do SentenceSplitter do LlamaIndex, que é o padrão recomendado para texto corrido naquele stack.

Use quando a integridade das frases importa — perguntas e respostas, textos jurídicos ou qualquer conteúdo em que cortes no meio da frase prejudiquem a compreensão.

Token

Janela deslizante de tamanho fixo alinhada aos limites de palavras. Ignora parágrafos e frases.

O LlamaIndex oferece o equivalente com o TokenTextSplitter. É útil quando o processamento posterior exige chunks de tamanho uniforme; caso contrário, prefira Text ou Sentence.

Regex

Divide em cada match de um padrão regex que você fornece e, por padrão, empacota as divisões até o tamanho do chunk — o mesmo comportamento de junção de todos os outros chunkers. Uma regex de limite precisa como (?=\n\s*\{\s*"id"\s*:) ainda vai gerar chunks com vários matches se esses matches forem pequenos o bastante para caber juntos. Isso é padrão no LangChain, LlamaIndex, Chonkie e Unstructured.

Use Regex quando o seu conteúdo tem delimitadores explícitos que não se encaixam em nenhuma outra estratégia.

Limites estritos

A estratégia Regex tem uma caixa de seleção opcional "Each match is its own chunk (don't merge)". Quando ativada:

• Cada match da regex se torna um chunk próprio
• Divisões adjacentes não são empacotadas juntas
• O overlap é desativado
• Divisões que excedem o tamanho do chunk continuam sendo subdivididas nos limites de palavras

Isso equivale ao parâmetro join=False do txtai e ao padrão split_length=1 do DocumentSplitter do Haystack. A maioria das bibliotecas não expõe isso diretamente porque espera que você use um parser estrutural — veja "Um registro por chunk" abaixo.

Ative quando cada match for um registro discreto (um par de pergunta e resposta, uma entrada de log) e você precisar que cada um fique isolado na busca.

Como escolher

Escolha Auto, a menos que você tenha um motivo para não escolher.

Se Auto não servir:

• A integridade das frases importa → Sentence
• Seu conteúdo tem marcadores estruturais que a Text não conhece → Recursive
• Você precisa de chunks de tamanho uniforme → Token
• Você tem delimitadores explícitos → Regex
• Cada registro precisa ser um chunk próprio → veja abaixo

Um registro por chunk

Transformar cada registro (cada par de pergunta e resposta, cada linha de log, cada linha de planilha) em um chunk próprio é chunking estrutural, não chunking por regex. Há dois caminhos:

1. Converta para JSONL (um registro por linha) e faça o upload. A estratégia Auto do Studio trata o arquivo como dado estruturado e nunca corta um registro no meio. Registros pequenos ainda podem ser agrupados até o tamanho do chunk — para forçar um registro por chunk, reduza o tamanho máximo do chunk para algo próximo ao tamanho de um registro. Veja o JSONNodeParser do LlamaIndex e o chunking baseado em elementos do Unstructured.

2. Use Regex com limites estritos ativados quando não for possível reestruturar a origem.

Prefira a opção 1. Parsers estruturais lidam com registros aninhados, delimitadores escapados e entradas malformadas que a regex não resolve.

Leituras complementares

• LangChain — Text Splitters
• LlamaIndex — Node Parsers
• Chonkie
• Unstructured — Chunking
• Pinecone — Chunking Strategies

FAQ