Lotook
Para dividir documentos em chunks de forma eficaz para RAG, primeiro separe os arquivos seguindo a estrutura existente, aplique às seções grandes demais um limite de comprimento em tokens com sobreposição em nível de frase e associe metadados de origem a cada trecho. A escolha entre fragmentação por tokens, semântica e baseada na estrutura depende de o corpus conter texto uniforme, assuntos que mudam ou tabelas e títulos formatados.
Por que a fragmentação para RAG determina a qualidade da recuperação?
Retrieval-Augmented Generation (RAG) divide os documentos de origem em trechos menores antes de gerar seus embeddings e armazená-los em um índice de busca. No momento da consulta, o sistema recupera os chunks mais relevantes e os passa a um modelo de linguagem junto com a pergunta do usuário. A fragmentação determina a unidade de recuperação porque um documento inteiro costuma ser amplo demais para corresponder bem a uma pergunta específica e grande demais para caber junto com outros candidatos na janela de contexto do modelo.
Quando Patrick Lewis e colegas apresentaram o framework em seu artigo da NeurIPS de 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks), o experimento dividiu cada artigo da Wikipedia em chunks sem sobreposição de cerca de 100 palavras, produzindo aproximadamente 21 milhões de trechos. Essa divisão em blocos de 100 palavras foi uma configuração experimental de 2020 para a Wikipedia, não um padrão de produção para 2026. Em novembro de 2026, o RAG moderno em produção geralmente funciona como um pipeline de engenharia modular (fragmentar, gerar embeddings, indexar, recuperar e gerar), em vez da configuração original de DPR e BART diferenciável de ponta a ponta.
Quais são os três principais métodos de fragmentação para RAG?
Os métodos de fragmentação para RAG se dividem em três famílias: divisão por tokens, semântica e baseada na estrutura. Cada família determina onde um trecho começa e termina usando comprimento, significado ou marcação do documento.
| Método de fragmentação | Sinal de divisão | Melhor aplicação | Principal risco | Custo de indexação |
|---|---|---|---|---|
| Fragmentação por tokens (ou comprimento) | Janela fixa de tokens ou caracteres com sobreposição deslizante | Texto uniforme, texto simples ou limite de comprimento após divisões estruturais | Corta frases, linhas de tabelas, blocos de código ou definições ao meio | Baixo |
| Fragmentação semântica | Queda da similaridade entre embeddings de frases vizinhas | Texto sem formatação em que os assuntos mudam no meio do documento sem títulos | Indexação mais lenta e cara; chunks de tamanhos desiguais | Alto |
| Fragmentação baseada na estrutura | Títulos, parágrafos, listas, tabelas, blocos de código ou páginas | Markdown, HTML, documentação de API, cláusulas jurídicas e manuais estruturados | Estrutura fraca em PDFs digitalizados; seções individuais ainda podem ser enormes | Baixo a médio |
1. Fragmentação por tokens e caracteres
A fragmentação por tokens divide o texto em janelas de comprimento fixo medido em tokens ou caracteres, frequentemente com sobreposição deslizante. Medir em tokens acompanha o funcionamento dos modelos: modelos de embedding e LLMs têm limites rigorosos de tokens, APIs são cobradas por token e o mesmo parágrafo pode ser tokenizado de forma diferente entre famílias de modelos. A contagem de caracteres é apenas uma aproximação.
As equipes geralmente começam com uma janela que caiba no limite do modelo de embedding (tutoriais costumam começar com algumas centenas de tokens) e a ajustam após verificar falhas de recuperação. O principal risco de uma janela fixa é ignorar a sintaxe e o layout, cortando uma frase, linha de tabela, bloco de código ou definição e deixando de fora a oração que responde à pergunta.
2. Fragmentação semântica
A fragmentação semântica divide o texto quando o significado muda, por exemplo quando a similaridade entre embeddings de frases vizinhas diminui ou aparece um limite no discurso, em vez de usar uma contagem rígida de tokens. Manter uma ideia completa em um chunk ajuda na recuperação quando os assuntos mudam no meio de um documento sem títulos.
Porém, a fragmentação semântica é mais lenta e cara para indexar porque a própria divisão pode exigir chamadas para gerar embeddings. Um limiar de similaridade com ruído também pode dividir o texto demais ou de menos, produzindo tamanhos desiguais, e a similaridade entre frases não é automaticamente melhor para tabelas, formulários ou código.
3. Fragmentação baseada na estrutura
A fragmentação baseada na estrutura usa a estrutura existente do documento para o primeiro corte: títulos Markdown ou HTML, parágrafos, listas, seções, páginas, blocos de código delimitados ou limites de tabelas. Como observa o AWS Prescriptive Guidance sobre RAG, preservar a estrutura do documento mantém intacto o contexto logicamente relacionado. Um chunk que começa em um título de política de reembolso e contém toda a seção é mais fácil de recuperar e citar do que uma janela iniciada no meio de uma frase.
Como muitos PDFs e documentos digitalizados não têm títulos claros (e um único título pode abranger 20 páginas), pipelines de produção geralmente combinam métodos:
- Primeiro divida hierarquicamente pela estrutura: Divida o documento por seção ou título e depois por parágrafo ou bloco, mantendo blocos de código, tabelas e listas intactos.
- Em seguida aplique um limite de comprimento em tokens: Se uma seção continuar grande demais, divida-a com uma janela de tokens.
- Use divisões alternativas para texto não estruturado: Para PDFs digitalizados ou seções longas sem estrutura, recorra a divisões por página, janelas de tokens ou limites semânticos.
Como configurar a sobreposição de chunks e os metadados de RAG?
A sobreposição de chunks e os metadados dos trechos evitam a perda de orações nos limites e conectam os fragmentos recuperados aos documentos de origem.
Configurando a sobreposição de chunks
A sobreposição repete o fim de um chunk no começo do seguinte para que uma frase ou definição em um limite apareça inteira em pelo menos um trecho recuperado. Ela funciona como uma precaução simples quando janelas fixas ou divisões alternativas cortam um raciocínio ao meio.
Dimensione a sobreposição para cobrir uma ou duas frases típicas do corpus, mantendo-a pequena o suficiente para não armazenar quase o mesmo chunk duas vezes. A sobreposição aumenta os tokens que você transforma em embeddings, armazena e recupera, ampliando o índice e adicionando resultados vizinhos quase duplicados. Se a recuperação retornar chunks quase duplicados com frequência, reduza a sobreposição ou o tamanho dos chunks, ou adicione uma etapa de deduplicação após a recuperação.
Associando metadados de RAG
Metadados de RAG são campos estruturados armazenados junto a cada chunk, incluindo:
- ID ou URL do documento de origem e título
- Caminho da seção ou dos títulos e número da página
- Data de criação ou atualização e tipo de documento (política, ticket, referência de API)
- Rótulos de acesso e permissão, idioma e um ID estável do chunk
As equipes podem manter os metadados fora do embedding quando IDs brutos ou carimbos de data e hora prejudicariam a similaridade, ou colocar campos selecionados (como o título de uma seção) no início do texto usado no embedding quando melhorarem a recuperação. Os metadados atendem a três necessidades de produção:
- Citações: Sua interface ou modelo pode citar um arquivo, título e número de página em vez de apenas um trecho.
- Filtros de permissão e versão: Recupere apenas a versão mais recente de uma política, um produto específico ou documentos que o usuário tem permissão para ver. As permissões devem estar nos filtros do índice, não apenas no prompt, pois colocar documentos privados em um índice RAG sem filtros os expõe a qualquer pessoa que possa consultar o sistema.
- Depuração e atualizações: Quando um documento de origem mudar, divida-o novamente, gere novos embeddings e retire os IDs antigos dos chunks para que dados desatualizados não causem erros factuais.
Como saber se seus chunks são grandes ou pequenos demais?
Examinar os chunks recuperados para perguntas reais dos usuários mostra se os trechos estão grandes demais ou fragmentados.
Sinais de que seus chunks são grandes demais
- Respostas escondidas: A recuperação retorna uma seção longa que menciona o termo da consulta, mas esconde a resposta real, de modo que o modelo precisa procurá-la ou a deixa passar.
- Prompts lotados: Apenas alguns chunks cabem no prompt, então uma correspondência mediana ocupa o espaço de outras melhores.
- Maior custo e latência: Enviar muitos tokens irrelevantes aumenta o gasto e o tempo de resposta.
- Mais distração: O ruído extra piora o context rot, situação em que o modelo tem o fato correto em um prompt grande, mas se apoia na memória do treinamento ou em uma frase vizinha incorreta.
Sinais de que seus chunks são pequenos demais
- Fragmentos sem contexto: Um chunk recuperado não pode ser entendido sem a frase anterior (como uma frase que informa uma exceção para planos empresariais sem mencionar a regra).
- Respostas de várias etapas divididas: Uma definição e sua exceção, uma função e seus parâmetros ou uma política e sua data de vigência ficam em chunks separados, e top-k retorna apenas uma parte.
- Fragmentos quase idênticos: Você recupera muitos fragmentos repetitivos e ainda não obtém uma ideia completa, enquanto as citações ficam confusas porque cada frase é uma fonte própria.
Para ajustar os tamanhos na prática, examine perguntas reais e os chunks recuperados e pergunte se uma pessoa que recebesse apenas esses trechos conseguiria responder. Se a frase necessária estiver em um chunk vizinho não recuperado, ajuste a sobreposição, as regras estruturais ou o tamanho. Se ela estiver no chunk recuperado cercada por texto não relacionado, divida em partes menores ou recupere menos chunks, mais focados.
Como a fragmentação para RAG afeta o context rot?
A fragmentação para RAG atua diretamente contra o context rot, a queda na qualidade do raciocínio, no seguimento de instruções e na capacidade de recordar de um modelo à medida que um prompt fica mais longo ou carregado, mesmo muito abaixo do limite de contexto anunciado.
RAG existe para que você não precise colocar todo o corpus no prompt. Porém, recuperar chunks grandes demais ou aumentar top-k por segurança e encher o prompt com muitos chunks vagamente semelhantes recria um contexto longo e ruidoso. Mais contexto não significa automaticamente mais precisão. Manter os chunks focados reduz a quantidade de informações no prompt, mas uma boa fragmentação, sozinha, não corrige um modelo de embedding ruim nem elimina alucinações de IA quando um modelo ignora o texto recuperado.
FAQ
Devo medir o tamanho dos chunks de RAG em tokens ou caracteres?
Meça o tamanho dos chunks de RAG em tokens sempre que possível. Modelos de embedding e de linguagem aplicam limites de contexto em tokens, e o uso de APIs é cobrado por token. A contagem de caracteres é apenas uma aproximação, pois o mesmo parágrafo pode gerar quantidades diferentes de tokens conforme idiomas, blocos de código e famílias de modelos. Usar o tokenizador do seu modelo de embedding evita truncamentos inesperados durante a indexação.
A fragmentação semântica é sempre melhor que a por tokens?
A fragmentação semântica não é automaticamente melhor que a fragmentação por tokens ou baseada na estrutura. Dividir quando a similaridade entre frases diminui ajuda a manter ideias juntas em texto não estruturado, mas exige trabalho adicional de embedding durante a indexação, cria chunks de tamanhos desiguais e pode dividir demais ou de menos com um limiar ruidoso. Em documentos formatados, dividir por títulos, tabelas e blocos de código é mais rápido e segue os limites pretendidos pelo autor.
Como devo dividir tabelas e blocos de código para RAG?
Tabelas, faturas, cláusulas jurídicas e código exigem regras baseadas na estrutura que mantenham os blocos intactos. Uma divisão ingênua por caracteres ou tokens no meio de uma tabela Markdown ou do corpo de uma função produz chunks inutilizáveis que separam valores dos cabeçalhos das colunas ou quebram a sintaxe. Mantenha blocos de código, tabelas e listas inteiros sempre que possível e aplique alternativas baseadas na estrutura apenas quando um único bloco ultrapassar os limites do modelo.
Os metadados devem ser incluídos no embedding do chunk?
Incluir metadados no texto usado para gerar o embedding é uma decisão de projeto que depende do campo. Colocar um título de documento ou caminho de títulos de seção no início do texto do chunk costuma ajudar na recuperação quando os parágrafos dependem do título para fornecer contexto. Identificadores brutos, carimbos de data e hora e rótulos de acesso devem permanecer em campos de metadados separados e filtráveis para não prejudicar a similaridade dos embeddings.
O que acontece quando um documento de origem muda?
Quando um documento de origem muda, seu pipeline de ingestão deve dividi-lo novamente, gerar novos embeddings e retirar os IDs antigos dos chunks do índice. Deixar chunks desatualizados ativos junto aos atualizados faz com que o sistema de recuperação apresente políticas antigas ou trechos conflitantes, transformando uma falha de manutenção do índice em um erro factual na resposta final.
