Estratégias de Chunking para RAG: 7 Métodos, Ranqueados por Dados de Recuperação (2026)

Estratégias de Chunking para RAG: 7 Métodos, Ranqueados por Dados de Recuperação (2026)

As estratégias de chunking para RAG decidem o que seu retriever consegue encontrar antes mesmo de qualquer query rodar. O estudo da Chroma de julho de 2024 rodou 472 queries em cinco corpus com o text-embedding-3-large, e o splitter que você escolhe move o recall em cerca de cinco pontos: 86,7% para um splitter de tokens simples, 91,7% para o baseado em GPT-4o, com cinco chunks recuperados por query. A precisão oscila muito mais. Ao longo do relatório completo, ela vai de 1,5% a 8,0%, o que transforma sua escolha de tamanho de chunk numa decisão de custo vestida de qualidade, e todo guia da primeira página lista os mesmos sete métodos sem mostrar qual recupera melhor.

Principais Aprendizados

• O chunking divide os documentos antes do embedding; os pontos de divisão decidem o que seu retriever consegue ou não encontrar.
• No estudo da Chroma de julho de 2024 com 472 queries, o recall ficou entre 86,7% e 91,7% nos splitters medidos.
• A precisão varia várias vezes mais que o recall, então o tamanho do chunk é, sobretudo, uma decisão de custo de tokens.
• Comece com 512 tokens e 10% de sobreposição, depois ajuste contra seu próprio conjunto de avaliação.

Qual Estratégia de Chunking para RAG Você Deve Usar? (Ranking)

Para a maioria das equipes trabalhando com texto corrido, recursive character chunking com 512 tokens e 10% de sobreposição é o padrão correto. Ele respeita limites de parágrafo e frase, não custa nada a mais e, no benchmark de 472 queries da Chroma, ficou 3,2 pontos de recall atrás do splitter baseado em LLM. Saia dele apenas quando seus documentos tiverem estrutura forte ou seu conjunto de avaliação provar o contrário.

Nossa leitura: comece com recursive character. Nos dados da Chroma, ele fica atrás apenas dos splitters de cluster e LLM em recall, e a precisão de 3,9% do splitter LLM significa que você alimenta o gerador com quase o dobro de ruído por token relevante. A maioria das equipes não tem um problema de chunking; tem um problema de tamanho de chunk que nunca mediu.

O Que os Dados Realmente Dizem Sobre Tamanho de Chunk?

A única comparação pública direta entre estratégias de chunking para RAG é o relatório técnico da Chroma "Evaluating Chunking Strategies for Retrieval" (Brandon Smith e Anton Troynikov, publicado em 3 de julho de 2024). Eles rodaram 472 queries em 5 corpus (328.208 tokens), fizeram o embedding de tudo com o text-embedding-3-large da OpenAI e recuperaram 5 chunks por query. As linhas abaixo vêm da tabela do apêndice do relatório para todos os corpus no text-embedding-3-large com 5 chunks recuperados, então são diretamente comparáveis entre si:

A tabela de resultados principais da Chroma, que reporta um cenário de recuperação diferente, coloca a melhor precisão do chunker de cluster em 8,0% com 87,3% de recall, e estende a faixa de precisão de todos os seus splitters de 1,5% (KamradtSemanticChunker) a 8,0%. Fonte: Chroma Research, Evaluating Chunking Strategies

"Introducing Contextual Retrieval" da Anthropic (publicado em 19 de setembro de 2024) ataca o problema por outro ângulo. A taxa de falha de recuperação top-20 da linha de base deles era 5,7%; só os embeddings contextuais a derrubaram para 3,7% (redução de 35%), o BM25 contextual por cima levou a 2,9% (49%) e o reranking empurrou para 1,9% (67%). A Anthropic não publica o tamanho exato de chunk nem a sobreposição usados, então trate isso como evidência no nível do método, não do tamanho. Fonte: Anthropic, Contextual Retrieval.

Nossa leitura: três conclusões tiradas da aritmética. Primeira, a escolha do splitter vale recall de verdade, e a Chroma diz isso sem rodeios: algumas estratégias superam outras em até 9% de recall. Na tabela de resultados principais, o recall vai de 83,6% (KamradtSemanticChunker) a 91,9% (LLMSemanticChunker) e, dentro das linhas de recuperação de 5 acima, ainda varia de 86,7% a 91,7%. A precisão se move várias vezes mais nos mesmos dados: 1,5% a 8,0%, uma amplitude de 5,3x contra 1,1x do recall. Então o recall é onde você ganha alguns pontos, e a precisão e o custo de tokens são onde a escolha realmente aperta. Segunda, o splitter baseado em LLM compra o melhor recall com a pior precisão: você paga uma chamada de LLM por documento e alimenta o gerador com mais ruído. Terceira, os números da Anthropic mostram que enriquecer chunks com contexto (5,7% para 3,7%) moveu a taxa de falha mais do que qualquer escolha de splitter na tabela da Chroma. Enriqueça os chunks antes de reajustar o splitter. O reranking recupera chunks que seu splitter estragou, e a busca híbrida combina BM25 com recuperação vetorial pela mesma razão.

Limites honestos: os dois estudos usam um único modelo de embedding, corpus apenas em inglês, e nenhum dos dois é um teste controlado do seu corpus. Em 472 queries, a diferença entre o melhor e o pior splitter foi de cerca de 5 pontos de recall com 5 chunks recuperados, e uma diferença proporcionalmente muito maior em precisão.

Por Que o Tamanho do Chunk Decide a Qualidade da Recuperação?

O tamanho do chunk define a granularidade da sua chave de recuperação. Um chunk de 400 tokens produz um embedding focado que casa com queries específicas; um chunk de 4.000 tokens faz a média de muitos temas e não casa com nada com precisão. Chunks pequenos recuperam a passagem exata, mas podem fragmentar uma resposta entre vários resultados. Chunks grandes mantêm o contexto junto, mas enfraquecem o sinal do embedding.

O teto de contexto do modelo de embedding também importa. Se seu modelo limita a 512 tokens de entrada e você manda 800, o final é truncado em silêncio. Seu embedding representa dois terços do chunk. Nenhum erro é registrado.

Depois, o lado do gerador. Liu et al. mostraram em "Lost in the Middle" (arXiv 2307.03172, 2023) que a precisão do LLM cai mais de 20% quando o documento relevante está no meio de um contexto longo. Recuperar cinco chunks de 1.000 tokens despeja 5.000 tokens no prompt, e a resposta de que você precisa pode cair na posição em que o modelo lê pior. Chunks menores mantêm a passagem relevante mais perto de uma posição que o modelo trata bem.

Pense nisso como o índice de uma biblioteca. Uma ficha que diz "Seção 4.2, parágrafo 3: política de reembolso" te leva à página. Uma ficha que diz "tudo sobre comércio no século 20" te leva ao prédio. Seu embedding é a ficha. Monte uma aplicação RAG de ponta a ponta para ver onde o chunking se encaixa no pipeline, e leia nosso guia de engenharia de contexto para entender como os chunks recuperados viram tokens do prompt. O guia de chunking da Pinecone enquadra o mesmo tradeoff pelo lado do banco de dados vetorial.

Chunking de Tamanho Fixo e Recursivo (Comece Aqui)

O tamanho fixo é a linha de base contra a qual você mede tudo; o recursivo é o que você realmente coloca em produção.

Chunking de tokens de tamanho fixo

Divida a cada N tokens, independentemente do conteúdo.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

A resposta certa para: texto corrido sem estrutura de cabeçalhos, protótipos rápidos e qualquer comparação de linha de base. Não é burro. É o grupo de controle.

Chunking recursivo de caracteres

O RecursiveCharacterTextSplitter do LangChain divide numa hierarquia de separadores: primeiro \n\n (parágrafos), depois \n (linhas), depois . (frases), depois (palavras). Cada chunk fica abaixo de chunk_size respeitando o maior limite natural que couber.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

A lista de separadores é a parte que todo concorrente omite. O splitter tenta \n\n primeiro e só desce para . quando um parágrafo excede o chunk_size. Se seu Markdown tem cabeçalhos, adicione "## " antes de "\n\n" para as seções ficarem inteiras.

Aritmética da sobreposição de chunks: com 512 tokens e sobreposição de 50 tokens, o passo é 462. Um documento de 10.000 tokens produz ceil(10000 / 462) = 22 chunks. Total de tokens com embedding: 22 x 512 = 11.264, ou seja, você refaz o embedding de cerca de 12,6% do corpus como sobreposição. Esse é o custo de armazenamento e API para impedir que frases de fronteira fiquem órfãs.

Como Funciona o Chunking Semântico, e Ele Vale o Custo?

O chunking semântico faz o embedding de cada frase, mede a distância de cosseno entre embeddings de frases vizinhas e divide onde essa distância supera um limiar de percentil (comumente o 95º). Os chunks quebram em mudanças de tema, não em contagens arbitrárias de tokens. O notebook "5 Levels of Text Splitting" do Greg Kamradt originou essa abordagem de ponto de quebra por percentil, e o estudo da Chroma faz o benchmark dos chunkers dele pelo nome.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

A conta de custo é a parte que ninguém coloca na frente. O chunking semântico faz o embedding do seu corpus duas vezes: uma para calcular as distâncias entre frases e achar os pontos de quebra, outra para fazer o embedding dos chunks resultantes para indexação. No preço do text-embedding-3-large da OpenAI, US$ 0,13 por 1M de tokens, um corpus de 10M de tokens custa US$ 1,30 para indexar normalmente e US$ 2,60 com chunking semântico. Você paga o dobro antes de uma única query rodar.

O que isso compra? Nas linhas de recuperação de 5 da Chroma, o chunker semântico baseado em cluster atingiu 89,0% de recall e 6,7% de precisão contra 88,5% e 7,0% do recursive no mesmo tamanho de 200 tokens. Na tabela de resultados principais, o mesmo chunker registra a melhor precisão do estudo, 8,0%, com 87,3% de recall. Meio ponto de recall para um lado ou para o outro, e um resultado de precisão que troca de sinal dependendo do cenário de recuperação que você lê, pelo dobro da conta de embedding. Nosso veredito: o chunking semântico compensa em corpus com temas variados (arquivos de notícias, coleções de artigos) onde limites fixos rotineiramente cortam no meio de um tema. Para corpus homogêneos (documentação de produto, uma base de conhecimento), o recursive te entrega 95% da qualidade pela metade do custo. Se você roda modelos de embedding localmente com o Ollama, o custo do embedding duplo vira tempo de computação.

Chunking Consciente do Documento: Markdown, HTML e Código

A divisão consciente da estrutura usa os limites do próprio documento (cabeçalhos, itens de lista, definições de função) em vez de contagens de caracteres. Um H2 de Markdown é um limite semântico que um humano colocou de propósito; um splitter de caracteres o tritura.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Para código, os limites são nós da AST. Os NodeParsers do LlamaIndex vêm com splitters conscientes da linguagem que quebram em definições de função e classe. O detalhe crítico: mantenha o bloco de imports e a assinatura da classe envolvente anexados a cada chunk de função. Um corpo de função sem seus imports é ruído impossível de embeddar, então coloque ambos no início de cada chunk e o embedding captura o que a função faz e de que ela depende.

Para RAG de código especificamente: divisão por limites de AST, imports no início, 256-512 tokens por função, sobreposição zero.

E Quanto a Late Chunking, Hierárquico e Agêntico?

Essas são as estratégias avançadas de chunking para RAG por trás do burburinho do "RAG 2.0", e as três estão com cobertura de SERP de 1/10.

Late chunking

O late chunking, apresentado por Günther et al. em "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, setembro de 2024), primeiro faz o embedding do documento inteiro com um modelo de contexto longo, depois agrupa os embeddings no nível de token em vetores de chunk, de modo que cada chunk carrega o contexto do documento todo e "custa US$ 40/mês" sabe a que "isso" se refere. O abstract afirma recuperação superior em várias tarefas, mas não publica nenhum número de destaque que pudéssemos verificar. O artigo da Weaviate explica a mecânica e também para antes de uma comparação controlada. Estado da evidência: promissor, não quantificado.

Chunking hierárquico (pai-filho)

Indexe chunks pequenos (256 tokens) para recuperação; devolva o pai (1.024 tokens) ao gerador. O retriever acha a agulha; o gerador recebe o palheiro ao redor. Você mantém dois níveis de índice e um mapeamento pai-filho. Nenhum benchmark público isola o efeito.

Chunking baseado em LLM / agêntico

O LLMSemanticChunker do estudo da Chroma usa o GPT-4o para decidir os pontos de divisão por documento: 91,7% de recall (o mais alto) e 3,9% de precisão (a mais baixa). Você paga uma chamada de LLM por documento no momento da indexação (cerca de US$ 100 para um corpus de 10.000 documentos) e alimenta o gerador com mais ruído. Reserve-o para corpus genuinamente irregulares: petições jurídicas, PDFs escaneados sem cabeçalhos extraíveis.

Qual Tamanho de Chunk Combina com Seu Modelo de Embedding?

O máximo de tokens de entrada do seu modelo de embedding é um teto de truncamento, não uma recomendação. Um modelo que aceita 8.192 tokens não faz embeddings melhores em 8.192 do que em 512. A qualidade degrada com a diluição muito antes do teto: o modelo faz a média do significado por mais tokens e o vetor deriva em direção ao centroide do corpus. A coluna de recomendação abaixo é a interpretação da Techsy, não a orientação dos fornecedores.

Fontes: guia de embeddings da OpenAI, docs do Cohere embed, docs de embeddings do Voyage, model card do BGE.

O padrão: modelos com teto duro de 512 tokens (Cohere v3, BGE) exigem chunks bem abaixo de 512, porque o truncamento é silencioso. Manda 600 tokens para um deles e os últimos 88 somem do embedding sem nenhum erro registrado. Modelos com tetos grandes (OpenAI, Voyage, Cohere v4) toleram chunks maiores, mas não recompensam por isso. O comprimento máximo de entrada de um modelo é um limite de truncamento, não uma recomendação.

Combine isso com nosso ranking dos melhores modelos de embedding para RAG, o que um score MTEB realmente mede e embeddings do Voyage, OpenAI e Cohere lado a lado antes de se comprometer com um modelo.

Como Fazer Chunking de Documentos em Outros Idiomas?

Tokenizers não são neutros em relação ao idioma. Petrov et al. mostraram em "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) que o mesmo texto traduzido entre idiomas pode diferir em comprimento tokenizado em até 15x. Até modelos no nível de caracteres e de bytes mostram diferença de mais de 4x para alguns pares de idiomas. Um chunk de 512 tokens guarda muito menos significado em turco, árabe ou japonês do que em inglês.

Aqui está a mesma frase tokenizada com a codificação cl100k_base do tiktoken (o tokenizer do GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Contagens geradas com o tiktoken cl100k_base, 30 de julho de 2026.

Orientação prática: com um tamanho fixo de chunk de 512 tokens, seus chunks em turco e japonês guardam cerca de 37% do significado que seus chunks em inglês guardam, e seus chunks em árabe guardam cerca de 26%. Faça o chunking por contagem de caracteres ou de frases por idioma, ou aumente o orçamento de tokens proporcionalmente (cerca de 1.400 para turco, 2.000 para árabe). Idiomas CJK não têm limites de palavra por espaço em branco, então splitters de caracteres se comportam de forma diferente. A morfologia do árabe empacota vários marcadores gramaticais em tokens únicos, inflando ainda mais as contagens.

Uma Árvore de Decisão para Escolher Sua Estratégia de Chunking

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Três prescrições rápidas. Chatbot de documentação: MarkdownHeaderTextSplitter com 512 tokens, sobreposição zero, caminho de cabeçalhos nos metadados. Assistente de busca em código: divisão por limites de AST com 256-512 tokens por função, imports no início. Corpus corporativo misto: roteie por tipo de documento na ingestão e armazene no banco de dados vetorial onde você guarda os chunks com metadados de tipo para ajuste por tipo depois. Esse roteamento por documento é a totalidade do chunking adaptativo para aplicações RAG.

Ferramentas: LangChain vs LlamaIndex vs Chonkie

Não vendemos nenhuma delas; as três páginas mais bem ranqueadas para esta palavra-chave são blogs de fornecedores com CTAs de produto.

Fontes: docs do LangChain, NodeParsers do LlamaIndex, docs do Chonkie.

As três implementam os mesmos algoritmos centrais, então escolha com base no que seu pipeline já usa. Para o stack mais amplo de ferramentas RAG além dos splitters e Qdrant, Chroma e pgvector comparados para armazenamento, veja nossos guias do cluster.

Como a Techsy Aborda o Chunking

Em projetos RAG de clientes, a equipe da Techsy começa com 512 tokens e 10% de sobreposição e não toca no splitter até termos montado um conjunto de avaliação de 20-50 perguntas a partir dos chamados reais de suporte do cliente. O conjunto de avaliação vem primeiro; depois mudamos uma variável por vez: tamanho, sobreposição, estratégia. Nenhuma troca de splitter sem um número de antes e depois nas mesmas perguntas. Peça uma consulta gratuita para um segundo par de olhos no seu pipeline de recuperação.

Sobre o Autor

Mert Batur é cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre o stack de ferramentas LLM que a equipe da Techsy realmente usa em produção, incluindo o trabalho de RAG e recuperação por trás das bases de conhecimento dos clientes. Conecte-se no LinkedIn.

Perguntas Frequentes

O que é chunking em RAG?

Chunking é a etapa de pré-processamento que divide os documentos em segmentos menores antes do embedding, para que o retriever possa casar queries com passagens focadas em vez de arquivos inteiros. Os pontos de divisão determinam o que seu sistema consegue ou não encontrar no momento da query.

Qual é a melhor estratégia de chunking para RAG?

Para a maioria dos sistemas em produção com documentos gerais, o chunking recursivo de caracteres com 512 tokens e 10% de sobreposição é o padrão mais forte. No estudo de 472 queries da Chroma (julho de 2024), ele marcou 88,5% de recall, a 3,2 pontos do método baseado em LLM mais caro, sem nenhum custo adicional.

Qual é o tamanho ótimo de chunk para RAG?

Comece com 512 tokens. Desça para 256 se seu modelo de embedding limitar a 512 tokens de entrada (Cohere v3, BGE) ou se suas queries esperam respostas de uma frase. Suba para 1.024 apenas se seu conjunto de avaliação mostrar respostas de vários parágrafos sendo fragmentadas. Sempre meça contra suas próprias perguntas.

Quanta sobreposição de chunk devo usar?

10-20% do tamanho do chunk (50-100 tokens em 512). A sobreposição impede que frases de fronteira fiquem órfãs: um fato dividido entre dois chunks aparece completo em pelo menos um. Acima de 20%, você refaz o embedding de uma parte grande demais do corpus para retornos decrescentes. A maioria das equipes fica em 10% e nunca mais revisita isso.

Chunking semântico é melhor que chunking de tamanho fixo?

Marginalmente, e pelo dobro do custo de embedding. O benchmark da Chroma de julho de 2024 mostrou o chunker semântico baseado em cluster com 89,0% de recall e 6,7% de precisão contra 88,5% de recall e 7,0% de precisão do recursive no mesmo tamanho de token, com o resultado de melhor precisão de 8,0% vindo de um cenário de recuperação diferente. Vale a pena para corpus com temas variados; difícil de justificar para conjuntos de documentos homogêneos.

O tamanho do chunk depende do modelo de embedding?

Sim. Modelos com teto de entrada de 512 tokens (BGE, Cohere v3) exigem chunks bem abaixo de 512 porque o truncamento é silencioso. Modelos com tetos de 8.192 ou mais toleram chunks maiores, mas não recompensam por isso; a qualidade do embedding degrada com a diluição antes do teto. Veja a tabela de combinação acima para pontos de partida por modelo.

Como faço chunking de código para um sistema RAG?

Divida em limites de AST (definições de função e classe) em vez de contagens de tokens. Mantenha cada chunk em 256-512 tokens por função, coloque o bloco de imports do arquivo e a assinatura da classe envolvente no início e use sobreposição zero, já que funções são unidades autocontidas. O CodeSplitter do LlamaIndex e os splitters conscientes de linguagem do LangChain cuidam disso.

O que é late chunking?

O late chunking primeiro faz o embedding do documento inteiro com um modelo de contexto longo, depois agrupa os embeddings no nível de token em vetores de chunk. O embedding de cada chunk carrega o contexto do documento todo, resolvendo o problema do "a que 'isso' se refere?". Apresentado por Günther et al. (arXiv 2409.04701, setembro de 2024). Nenhum benchmark público comparativo quantifica o ganho até agora.

Como faço chunking de documentos em outros idiomas além do inglês?

As contagens de tokens não são neutras em relação ao idioma. A mesma frase consumiu 2,7x mais tokens em turco e japonês do que em inglês, e 3,9x em árabe (tiktoken cl100k_base). Um orçamento fixo de 512 tokens dá silenciosamente menos significado a chunks em outros idiomas. Faça o chunking por contagem de caracteres ou frases por idioma, ou aumente o orçamento proporcionalmente.

Como sei se meu chunking está realmente funcionando?

Monte um conjunto de avaliação de 20-50 perguntas a partir de queries reais de usuários antes de tocar no splitter. Pontue hit@5 e MRR contra seus chunks atuais. Mude uma variável (tamanho, sobreposição, estratégia), rode de novo, compare. Sem um conjunto de avaliação, você está ajustando no feeling. Vinte perguntas bastam para começar.

Resumo Final

• Comece com chunking recursivo de caracteres com 512 tokens e 10% de sobreposição. Padrão correto para texto corrido.
• Entre as quatro famílias de splitters que alguém já mediu, as 472 queries da Chroma movem o recall cerca de 5 pontos e a precisão várias vezes mais. Ajuste primeiro pela precisão e pelo custo.
• Combine o tamanho do chunk com o teto de entrada do seu modelo de embedding. Um modelo com teto de 512 tokens exige chunks abaixo de 512.
• Enriqueça os chunks com contexto (queda da taxa de falha de 5,7% para 3,7% da Anthropic) antes de reajustar o splitter.
• Monte o conjunto de avaliação primeiro. Toda decisão de splitter sem um número de antes e depois é um palpite.

Para o pipeline completo em torno da sua escolha de chunking, veja montar uma aplicação RAG de ponta a ponta. Ainda em dúvida entre recuperação e fine-tuning? RAG ou fine-tuning detalha quando cada um vence.