As 7 estratégias de chunking que definem se seu RAG funciona ou não

As 7 estratégias de chunking que definem se seu RAG funciona ou não

Despejar texto bruto em janelas de tokens de tamanho fixo e chamar isso de pipeline RAG é receita para alucinação. RAG (Retrieval-Augmented Generation) é essencialmente uma prova com consulta: o sistema busca os trechos certos em uma base de conhecimento e entrega ao LLM para sintetizar a resposta. Mas a qualidade dessa resposta depende inteiramente de como você fatia os documentos — sua estratégia de chunking.

A abordagem ingênua de fatiar documentos em arrays estáticos de 512 tokens rasga fronteiras semânticas ao meio, destruindo contexto antes mesmo de o modelo de embedding conseguir processá-lo. Separe um qualificador negativo do sujeito, ou divida a definição de uma função em dois vetores, e o recuperador fica efetivamente cego.

Este guia cobre as sete estratégias que separam um RAG que funciona de um que só gasta tokens.

1. Chunking por tamanho fixo com sobreposição

O conceito: fatiar o texto estritamente por contagem de tokens, usando uma janela deslizante para capturar contexto nas bordas.

Como funciona: um tokenizador rápido mapeia texto para array de inteiros, fatia em blocos uniformes (ex: 512 tokens) e os sobrepõe por uma margem fixa (ex: 50 tokens) antes de decodificar de volta para strings.

Atenção: é estruturalmente cego. Você inevitavelmente partirá um bloco try/except ao meio ou separará um pronome de seu antecedente. A sobreposição mitiga parcialmente, mas aumenta o inchaço do banco vetorial e o custo computacional linearmente com a taxa de overlap.

Quando usar: logs homogêneos, streams de texto plano sem estrutura — onde a latência de ingestão é a prioridade máxima.

2. Sentence-Window Retrieval (Small-to-Big)

O conceito: gerar embedding de um chunk granular para maximizar a precisão da busca vetorial e, na montagem do prompt, devolver ao LLM a janela expandida de contexto ao redor.

Como funciona: na ingestão, documentos são parseados em sentenças individuais. Cada sentença recebe embedding e é armazenada com um ponteiro de metadados para as sentenças vizinhas. Na recuperação, o banco vetorial retorna as top-k sentenças mais próximas, e o middleware as substitui pela janela de texto expandida antes de enviar ao modelo gerador.

Atenção: injeção de contexto redundante é um risco real. Se duas sentenças adjacentes passarem do threshold de similaridade, seu middleware precisa de deduplicação baseada em grafo das janelas sobrepostas. Sem isso, você estoura a janela de contexto do LLM.

Quando usar: literatura médica, textos jurídicos e domínios onde os fatos são densamente empacotados e altamente matizados.

3. Chunking estrutural (document-aware)

O conceito: dividir documentos ao longo de suas fronteiras lógicas de Markdown ou DOM (H1, H2, parágrafos, itens de lista), não por limites arbitrários de tokens.

Como funciona: o pipeline usa parsers para construir uma árvore da estrutura do documento, fatia os nós-folha (parágrafos e listas) e prefixa cada chunk com a hierarquia de cabeçalhos pai (ex: “H1: Resultados Q3 > H2: Fatores de Risco > [Chunk]”). Isso preserva contexto global independentemente de onde o chunk parar espacialmente.

Atenção: tamanhos de nó são não-determinísticos e variam muito. Uma subseção grande pode exceder o limite de 512 ou 1024 tokens do modelo de embedding, forçando fallback para chunking por token — o que quebra a integridade estrutural que você pagou ciclos de CPU para parsear.

Quando usar: documentos corporativos formatados, documentação de APIs, contratos — onde a hierarquia de cabeçalhos define a carga semântica.

4. Chunking semântico (baseado em embeddings)

O conceito: determinar dinamicamente as fronteiras dos chunks medindo a distância entre vetores de sentenças sequenciais e dividindo quando a deriva semântica excede um threshold.

Como funciona: deslize uma janela de sentenças pelo texto, gerando embeddings leves para cada uma. Calcule a similaridade de cosseno entre a sentença i e i+1. Se a similaridade cair abaixo de um hiperparâmetro epsilon (ajustado empiricamente), insira uma fronteira rígida de chunk. Essa queda sinaliza mudança de tópico.

Atenção: latência e custo de ingestão sobem significativamente. Você está forçando um forward pass pelo encoder para cada sentença antes de gerar o embedding final do chunk. E o epsilon é notoriamente frágil — quase impossível de calibrar globalmente em conjuntos heterogêneos de documentos.

Quando usar: transcrições de áudio, notas de reunião, textos narrativos longos sem formatação estrutural mas com mudanças temáticas imprevisíveis.

5. Chunking hierárquico (parent-child)

O conceito: criar uma árvore de chunks onde múltiplos nós-filho granulares mapeiam para um único nó-pai abrangente. Recupere filhos suficientes e você ganha o pai inteiro.

Como funciona: o texto é chunkado em múltiplas granularidades (ex: 256 tokens e 1024 tokens). Os chunks de 256 tokens recebem embedding e são mapeados para seu pai de 1024 tokens via chaves estrangeiras de metadados no banco vetorial. Se mais de x% dos filhos de um pai forem recuperados pela busca ANN, o query planner faz merge e troca os filhos pelo chunk pai.

Atenção: gerenciar o mapeamento relacional pai-filho em um banco vetorial distribuído fica complexo rapidamente. Deleções e atualizações exigem invalidações em cascata pela árvore, e a lógica de merge no momento da recuperação adiciona latência ao caminho crítico.

Quando usar: quando o escopo das consultas é altamente variável — de extração pontual de fatos a sumarização ampla de seções inteiras.

6. Chunking proposicional (agentic, orientado por LLM)

O conceito: usar um LLM ajustado por instrução para ler um fluxo de texto e injetar pontos de quebra estruturais baseados em compreensão contextual, ou extrair proposições atômicas.

Como funciona: um documento é enviado a um LLM rápido com um prompt de sistema estrito instruindo-o a gerar um array JSON de breakpoints naturais ou proposições factuais distintas. O pipeline de ingestão então fatia o documento bruto ao longo dessas fronteiras sintetizadas e gera embeddings das proposições extraídas.

Atenção: isso garante ingestão não-determinística. O LLM vai alucinar breakpoints, gerar JSON malformado ou silenciosamente descartar texto durante a extração — qualquer um desses causa perda irrecuperável de dados no índice. Também é significativamente mais lento que chunking programático.

Quando usar: datasets altamente valiosos e irregulares onde a qualidade do chunk define a viabilidade do produto — mas apenas quando a ingestão roda em fila assíncrona, não em stream de tempo real.

7. Chunking multimodal com preservação de tabelas

O conceito: isolar tabelas, gráficos e figuras do texto padrão, extraí-los como objetos distintos, sumarizá-los para vetorização e manter ponteiros de volta aos dados tabulares brutos.

Como funciona: um parser determinístico de layout ou Vision-Language Model (VLM) identifica uma tabela. O pipeline extrai o HTML/Markdown bruto, usa um LLM para gerar um sumário denso dos insights semânticos da tabela e faz embedding apenas do sumário. A camada de recuperação busca o sumário via ANN, mas passa a tabela Markdown bruta para o prompt final de geração.

Atenção: se uma tabela depende do texto ao redor para fazer sentido (ex: “Resultados na Tabela 1 abaixo, normalizados contra o grupo controle”), isolá-la remove o grounding necessário e cria referências fantasmas. Esquemas de tabelas muito largas também podem exceder os limites de sequência de modelos de geração antigos.

Quando usar: relatórios financeiros, artigos científicos ou documentos pesadamente quantitativos onde tokenizadores de texto recursivos padrão destroem o alinhamento espacial de colunas.

Além do chunking: o que importa em produção

O centésimo dia em produção não é mais sobre estratégia de chunking. É sobre gerenciamento de ciclo de vida do índice, sincronização de estado e remoção de dados obsoletos. Atualizações de documentos inevitavelmente criarão chunks órfãos e fragmentados no seu banco. Se você não estiver implementando UUIDs determinísticos baseados em hashes criptográficos de conteúdo e aplicando políticas estritas de TTL (Time-To-Live), seu banco vetorial vai inchar com blocos de texto desatualizados.

Pare de obcecar por benchmarks do modelo de embedding mais novo se sua estratégia de chunking é uma reflexão tardia. O recuperador denso mais capaz do mundo não consegue recuperar significado semântico que já foi mutilado por um pipeline de ingestão ingênuo. Trate o chunking como um problema fundamental de modelagem de dados, teste suas fronteiras agressivamente e construa seu sistema esperando falha estrutural.