Estratégias de chunking para RAG comparadas: por que o seu retriever encontra metade da resposta

Se o seu sistema de recuperação encontra parte da resposta na maioria das vezes, ele provavelmente falha mais do que o seu painel indica. Um conjunto de artigos de outubro sobre chunking, e um experimento cuidadoso que comparou cinco das ideias deles lado a lado, apontam para a mesma lição: a forma como você corta um documento decide o que pode ser encontrado, e o melhor corte depende de quanto contexto você pode se dar ao luxo de enviar.

Por que o chunking voltou à pauta

A geração aumentada por recuperação (RAG) corta os seus documentos em pedaços, encontra os pedaços que correspondem a uma pergunta e os entrega a um modelo. O modelo só pode usar o que recebe. The Bottleneck Is Retrieval, Not Reading (arXiv, 18 de outubro) testou dez modelos de fronteira e três de pesos abertos e encontrou o mesmo padrão em todos: a recuperação traz de forma confiável alguns dos chunks de que uma pergunta com vários fatos precisa, mas não todos, e o chunking remove o contexto do documento que liga uma passagem a outra.

Três artigos de outubro atacam isso por lados diferentes.

QESChunker (27 de outubro) trata o chunking como otimização. Dadas perguntas de exemplo e as frases que as respondem, ele escolhe os pontos de corte que mantêm recuperável o máximo de evidência. Sem sobreposição, a programação dinâmica encontra a melhor resposta exata; com sobreposição, o problema é NP-difícil, e uma passada gulosa chega a um limite comprovado do melhor.

StrucChunk (19 de outubro) usa a estrutura que o autor já escreveu. Ele nunca corta no meio de uma cláusula, resolve referências cruzadas como "ver Seção 4.2" antes da indexação e combina busca por palavras-chave (BM25) com embeddings densos. Em 501 perguntas sobre o Código de Processo Penal da Índia, o Recall@5 subiu de 0,557 para 0,804, e os autores atribuem 88% desse ganho só ao chunking.

SpectRAG (27 de outubro) deixa de tratar os chunks como independentes. Ele constrói sobre eles um grafo ponderado a partir de adjacência, hierarquia de seções, entidades compartilhadas e citações, espalha a relevância dos primeiros resultados da busca por esse grafo e monta um contexto dentro de um orçamento fixo de tokens.

Um experimento, cinco chunkers

Vishal Mysore colocou essas ideias umas contra as outras em um laboratório no navegador que qualquer pessoa pode rodar de novo. O documento é um manual fictício de um observatório escrito como um manual de políticas, com seções numeradas, definições e referências cruzadas. A recuperação é só BM25, então todo número é determinístico. Cada chunker tem os mesmos limites: chunks de até 450 caracteres e um orçamento de contexto de 120 palavras.

Os cinco chunkers foram uma janela fixa que corta a cada poucas centenas de caracteres, uma janela de frases que agrupa frases inteiras, um chunker que respeita a estrutura no estilo do StrucChunk (um chunk por seção numerada, com o caminho de títulos anexado e as definições referenciadas coladas) e o QESChunker nas versões exata e com sobreposição.

Todos os chunkers mantiveram cada frase de evidência intacta em algum lugar. As diferenças estão em se os pedaços certos podem ser encontrados e caber no orçamento.

O que os resultados dizem

O recall parcial engana. Todas as estratégias encontraram pelo menos uma frase de evidência para 69 a 92% das perguntas. Os chunkers padrão montaram a resposta completa menos de um quarto das vezes. Um pipeline avaliado por acertos parciais pareceria saudável enquanto três em cada quatro respostas com vários fatos eram construídas sobre metade da evidência.

Chunks pequenos e estruturados vencem quando o contexto é apertado. Os chunks do tamanho de uma seção tiveram em média 285 caracteres, contra cerca de 400 das janelas, então cabem dois ou três em 120 palavras onde cabe uma janela. Com um orçamento de 40 palavras, só o chunker que respeita a estrutura passou de 10%. Com 300 palavras, os chunkers de janela já o tinham alcançado, e com 400 o ultrapassaram, enquanto o que respeita a estrutura se estabilizou em 77%. Com um orçamento generoso, quase qualquer chunker puxa a evidência, porque você está enviando uma grande parte do documento.

O tamanho do chunk e o orçamento precisam ser definidos juntos. Com chunks de 800 caracteres, as janelas fixa e de frases marcaram 0%: uma janela de 800 caracteres tem cerca de 130 palavras, mais que o orçamento de 120 palavras, então nenhum chunk coube. Essa é a falha que acontece quando uma pessoa ajusta o chunker e outra ajusta o prompt.

O chunker comprovadamente ótimo ficou em último. A versão exata do QESChunker marcou 15% nas perguntas reservadas. Ele é ótimo para o seu objetivo, que recompensa manter as frases de evidência inteiras. O jeito mais barato de manter uma regra inteira é cortar logo antes dela, e em um manual a linha antes de uma regra é o seu título. O título acabou no fim de um chunk e a regra no começo do seguinte, então uma busca por palavras-chave pelo título encontrou o chunk errado. Nenhum dos seus chunks começava em um título. A lição é geral: um chunker otimiza o que você escreve, e evidência intacta não é o mesmo que evidência encontrável. A versão com sobreposição foi muito melhor, 46% nas perguntas reservadas e 83% nas perguntas em que foi ajustada. Essa diferença é o alerta para qualquer chunker treinado com perguntas de exemplo: o índice é moldado em torno das perguntas que você pensou em fazer.

Um grafo de chunks ajuda onde as definições são centrais. Passar o chunking que respeita a estrutura para a recuperação por grafo o elevou de 62% para 69%. Para "Is flash photography allowed on the dome floor?", o BM25 puro colocou a definição da zona de luz vermelha em terceiro lugar, e ela deixou de caber no orçamento. No modo grafo, duas outras seções fazem referência cruzada a essa definição, então a relevância fluiu para ela e ela entrou. Desligar a resolução de referências cruzadas apagou o ganho. Nos chunkers de janela, o grafo não ajudou, e nas janelas de frases ele derrubou a pontuação de 23% para 15%.

Algumas falhas não são problemas de chunking. "My 8-year-old is coming. What rule applies on the terrace?" falhou em todos, porque a regra diz "children under 10" e não compartilha nenhuma palavra com a pergunta. Essa lacuna exige recuperação densa ou híbrida, reescrita de consultas ou um reranker.

O que mudar no seu pipeline

Para documentos com estrutura real, como contratos, políticas, manuais e especificações, faça o chunking por seção, anexe o caminho de títulos e resolva as referências cruzadas na indexação, para que uma regra vá junto com a definição de que depende. Ferramentas como Docling e Unstructured recuperam essa estrutura de PDFs; Chonkie cuida do chunking em si.

Meça respostas completas, não acertos parciais. Uma pergunta com vários fatos respondida com metade da evidência é uma resposta errada que parece certa. O Ragas pode medir o context recall por pergunta.

Defina o tamanho do chunk e o orçamento de contexto no mesmo lugar, e teste com o orçamento que você realmente envia. O melhor chunker com 120 palavras não foi o melhor com 400.

Se você testar um método supervisionado ou baseado em grafo, confira se o objetivo dele corresponde ao retriever que você usa. Dois artigos de setembro reforçam isso por outros ângulos: um estudo com 54 configurações concluiu que as escolhas de parser e de chunker interagem, sem nenhum retriever melhor em todos os casos, e uma comparação de seis pipelines sobre cerca de 464.000 artigos concluiu que o reranking e a late interaction mexem mais na qualidade do que ajustes na primeira etapa. Um terceiro, sobre profundidade de recuperação adaptativa, relata F1 mais de 36% melhor e 14% menos tokens em consultas fáceis ao escolher quantos chunks buscar para cada tipo de pergunta.

Nossa opinião: o chunking decide o que pode ser recuperado; o retriever decide o que é. Corrija o primeiro com estrutura, o segundo com busca híbrida e um reranker como o Cohere Rerank 5 ou o Jina Reranker v3.5, e avalie os dois pelo critério de a resposta inteira chegar.