estratégias de chunking

#Por que o chunking pesa tanto quanto o modelo de embedding

O chunking é a operação que divide um documento em trechos antes de indexá-los: cada trecho recebe um vetor, e é um trecho, nunca o documento inteiro, que será recuperado e depois enviado ao modelo de linguagem. Tudo o que vem a seguir depende dessa divisão. Se a frase que responde à pergunta for dividida entre dois trechos, nenhum deles a contém por inteiro e a busca não a encontra; se o trecho mistura três assuntos, seu vetor é uma média imprecisa que não se assemelha fortemente a nenhuma pergunta. Um embedding mais potente não corrige uma divisão inadequada, pois só pode vetorizar o que lhe é fornecido.

Um estudo da Chroma sobre a avaliação de estratégias de divisão mostra isso: métodos heurísticos, como o RecursiveCharacterTextSplitter, muitas vezes produzem bons resultados na prática quando bem configurados, e os resultados variam significativamente conforme o tamanho e a sobreposição escolhidos. Este guia, portanto, não promete nenhum ganho geral expresso em números: a única coisa confiável é medir nos seus documentos.

#Qual tamanho de chunk escolher

Não existe um tamanho universal, mas existem referências. No estudo da Chroma, a estratégia recursiva supera a divisão por tokens para tamanhos de 400 tokens ou menos sem sobreposição, e o comportamento difere para tamanhos maiores e com sobreposição. A configuração padrão da ferramenta de busca de arquivos da OpenAI, 800 tokens com 400 de sobreposição, obtém neste teste um recall ligeiramente abaixo da média e as pontuações mais baixas nas demais métricas. As referências abaixo decorrem desses resultados, sem pretensão de exatidão para o seu corpus.

#Tokens ou caracteres: a armadilha das unidades

As bibliotecas não contam todas na mesma unidade. O SentenceSplitter do LlamaIndex expressa chunk_size e chunk_overlap em tokens, com 1024 e 200 por padrão de acordo com sua documentação. Outras ferramentas, incluindo o RecursiveCharacterTextSplitter do LangChain, contam por padrão em caracteres; verifique o parâmetro length_function da sua versão. Definir « 500 » em um ou outro resulta em chunks cujos tamanhos diferem por um fator de aproximadamente quatro. Segunda restrição: o modelo de embedding tem seu próprio comprimento máximo de entrada. O modelo BGE-M3 aceita entradas de até 8 192 tokens de acordo com sua ficha; outros modelos de embedding, mais antigos ou mais leves, aceitam muito menos, e, quando esse limite é ultrapassado, o final do trecho é ignorado. Verifique o limite do seu modelo antes de escolher o tamanho e faça a contagem com o tokenizer do modelo, em vez de estimar a olho.

#Sobreposição: útil, mas nem sempre

A sobreposição repete o final de um chunk no início do seguinte, para que uma frase cortada no limite entre os chunks permaneça legível em pelo menos um deles. Isso tem um custo: mais chunks, um índice maior e duplicatas nos resultados. O estudo da Chroma observa que reduzir a sobreposição melhora a pontuação IoU, uma métrica que penaliza informações redundantes. A sobreposição se justifica se você dividir o texto em blocos de tamanho fixo; ela tem menos importância se você já fizer os cortes nos limites dos parágrafos e títulos, pois nesse caso eles coincidem com divisões naturais do texto.

0 tokens

Suficiente com divisão por parágrafos ou por estrutura; o mais econômico.

10 a 15% do tamanho

Bom equilíbrio quando a divisão é feita por frases ou caracteres.

Mais de 25 %

Raramente justificado: muita redundância, trechos quase idênticos nos resultados.

#Estratégias de divisão, da mais simples à mais cara

#1. Por número fixo de caracteres

Dividir a cada N caracteres ou tokens, sem analisar o texto. É o método mais simples e mais destrutivo: corta no meio de palavras, frases e tabelas. Reservar para protótipos.

#2. Por parágrafos ou por frases

Dividir nas quebras de linha duplas ou na pontuação, depois agrupar as unidades até atingir o tamanho desejado. Uma melhoria clara sem custo, pois cada chunk começa e termina em um limite natural.

#3. Recursivo

Primeiro, tentamos dividir o texto por separadores de maior escala (parágrafo, linha, frase, espaço) e só recorremos à divisão por caractere como último recurso. Esse é o comportamento padrão nos principais frameworks e uma base sólida: o estudo da Chroma constata que esse tipo de divisão, quando bem parametrizado, costuma apresentar bons resultados.

#4. De acordo com a estrutura do documento

Respeitam-se os títulos, listas, tabelas e blocos de código. O MarkdownNodeParser do LlamaIndex, por exemplo, divide o texto de acordo com os títulos e associa a cada nó o caminho dos títulos que levam até ele, dando ao trecho um contexto que seu texto isolado não tem. É a melhor escolha para documentação técnica, wikis e páginas HTML exportadas.

#5. Semântica

Calcula-se um embedding por frase e, depois, divide-se o texto nos pontos em que a similaridade cai entre duas frases vizinhas. No LlamaIndex, o SemanticSplitterNodeParser recebe um buffer_size (número de frases comparadas juntas, 1 por padrão) e um breakpoint_percentile_threshold (95 por padrão; um valor mais baixo cria mais nós). O custo é um cálculo adicional de embeddings durante a indexação, e o benefício não está comprovado: um estudo de outubro de 2024 sobre três tarefas de recuperação conclui que os custos computacionais da segmentação semântica não são justificados por ganhos consistentes de desempenho. Teste essa abordagem no seu corpus antes de adotá-la.

#6. Hierárquico (pai e filho)

Indexamos pequenos chunks para garantir a precisão da busca e enviamos ao modelo o bloco pai maior para fornecer contexto. O HierarchicalNodeParser do LlamaIndex gera esse tipo de hierarquia, por exemplo, com três níveis de 2048, 512 e 128 tokens, conforme sua documentação. É a solução para trechos longos: não usar apenas chunks pequenos nem apenas grandes.

#Implementações com LlamaIndex

from llama_index.core.node_parser import SentenceSplitter

splitter = SentenceSplitter(chunk_size=400, chunk_overlap=40)  # en tokens
nodes = splitter.get_nodes_from_documents(docs)

from llama_index.core.node_parser import MarkdownNodeParser

parser = MarkdownNodeParser()
nodes = parser.get_nodes_from_documents(docs)
# le chemin des titres est stocké dans les métadonnées de chaque nœud

from llama_index.core.node_parser import HierarchicalNodeParser, get_leaf_nodes

parser = HierarchicalNodeParser.from_defaults(chunk_sizes=[2048, 512, 128])
nodes = parser.get_nodes_from_documents(docs)
leaves = get_leaf_nodes(nodes)  # ce sont les feuilles qu'on vectorise

from llama_index.core.node_parser import SemanticSplitterNodeParser
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

embed = HuggingFaceEmbedding(model_name="BAAI/bge-m3")
splitter = SemanticSplitterNodeParser(embed_model=embed, buffer_size=1, breakpoint_percentile_threshold=95)
nodes = splitter.get_nodes_from_documents(docs)

#Fornecer novamente contexto a cada chunk

Um trecho retirado do seu documento perde seus pontos de referência: 'O prazo é de 30 dias' não diz de que se trata. Três práticas simples resolvem isso. Anteceder cada chunk com o título do documento e o caminho da seção; armazenar essas informações como metadados para filtrar (por data, por fonte, por tipo de documento); e, para trechos que começam por um pronome ou uma referência ('esta cláusula'), considerar o nível pai na divisão hierárquica. Muitas vezes, uma única linha de contexto antes do texto é suficiente, e ela custa muito menos do que trocar de modelo.

#Avaliar seu chunking antes de fixá-lo

1. 01
   Escrever 30 a 50 perguntas reais

   Perguntas que seus usuários fariam, cada uma acompanhada do trecho da fonte esperado; escreva essas perguntas antes de ver os resultados.
2. 02
   Indexar com duas ou três configurações

   Por exemplo, 250, 400 e 700 tokens, com sobreposição de 0 e 10%. Mantenha os outros parâmetros iguais.
3. 03
   Medir o recall nos 5 primeiros resultados

   Para cada pergunta, o trecho esperado está entre os 5 primeiros resultados? O percentual indica o recall@5.
4. 04
   Ver também a precisão e a redundância

   Um recall idêntico com resultados mais variados é um melhor ajuste. Conte os duplicados no top 5.
5. 05
   Ler os erros um a um

   Para cada pergunta mal respondida, abra o chunk que deveria ter fornecido a resposta: ele foi cortado, é amplo demais ou contém um trecho corrompido? A causa determina a correção.

#Armadilhas frequentes

Tabelas desestruturadas

Um extrator de PDF que transforma uma tabela em texto linear gera linhas de células sem sentido: extraia a estrutura antes da divisão em trechos.

Blocos de código cortados

Um segmentador que não leva em conta a sintaxe divide um bloco no meio; use uma segmentação baseada na estrutura.

Documentos mistos

Um chunk metade francês, metade inglês, gera um vetor médio pouco útil: se o corpus for misto, separe por língua.

Chunks quase vazios

Um título só (« 3.2.1 Obrigações ») sem o texto seguinte é ruído: filtre os chunks muito curtos ou combine-os com o próximo.

Mudar o chunking sem reindexar

A divisão em trechos fica definida na indexação: qualquer mudança exige recalcular os vetores. Planeje um script de reindexação desde o início.

#Perguntas frequentes sobre o chunking

• Adicionar um reranker ao seu pipeline
• Busca híbrida BM25 + vetorial
• Os melhores modelos de embeddings para francês
• RAG local com ChromaDB e Ollama
• LlamaIndex na prática

• Fonte: Chroma, Evaluating Chunking Strategies for Retrieval
• Fonte: Is Semantic Chunking Worth the Computational Cost ?
• Fonte: LlamaIndex, analisadores de nó
• Fonte: ficha do Hugging Face de BAAI/bge-m3