Chunking Strategies for RAG

Introdução

Na lição anterior, exploramos como os vector stores nos permitem armazenar e recuperar embeddings de forma eficiente, resolvendo o desafio de buscar em milhões de documentos em milissegundos. Vimos que a busca por vizinhos mais próximos aproximada (ANN) é a tecnologia-chave que torna o RAG escalável.

Isso nos leva a uma questão fundamental no processo de ingestão de dados: o que exatamente transformamos em um embedding? Se um documento de regras de negócio tem 50 páginas, ou um arquivo de código-fonte tem milhares de linhas, criar um único embedding para o documento inteiro seria ineficaz. Perderíamos a granularidade necessária para encontrar a resposta precisa para uma consulta específica. A solução é o chunking: o processo de dividir documentos grandes em pedaços (chunks) menores e semanticamente significativos.

Nesta lição, nosso objetivo é aplicar várias estratégias de chunking para segmentar documentos longos de forma eficaz para RAG. Exploraremos um espectro de técnicas, desde métodos simples baseados em tamanho até abordagens sofisticadas que entendem a estrutura do seu conteúdo, seja ele prosa, documentação técnica ou código-fonte.

1. Por Que o Chunking é Crucial?

Antes de mergulharmos nas técnicas, é vital entender por que o chunking é uma das etapas mais críticas em um pipeline de RAG. Uma estratégia de chunking mal executada pode arruinar a qualidade das respostas do seu sistema.

O problema central é a perda de contexto. Se um chunk termina no meio de uma frase ou separa um conceito em duas partes, o LLM recebe informações fragmentadas e desconexas, levando a respostas sem sentido ou alucinações. O chunking não é apenas sobre tamanho — é sobre sentido.

Toda estratégia de chunking envolve um trade-off fundamental:

• Chunks pequenos: Aumentam a precisão da busca (é mais fácil encontrar uma correspondência exata para uma consulta específica), mas podem não conter contexto suficiente para que o LLM gere uma resposta completa.
• Chunks grandes: Preservam mais contexto, mas podem diluir a relevância do sinal, tornando a busca menos precisa e potencialmente incluindo informações irrelevantes no prompt do LLM.

Seu desafio é encontrar o equilíbrio certo para os seus tipos de documentos e padrões de consulta.

2. Uma Hierarquia de Estratégias de Chunking

Vamos explorar as estratégias de chunking em uma progressão lógica, do mais simples ao mais avançado. A estrutura a seguir é inspirada no excelente guia "The 5 Levels of Text Splitting" de Greg Kamradt.

Nível 1: Fixed-Size Chunking (Character e Token)

Esta é a abordagem mais básica: dividir o texto em blocos de tamanho fixo, seja por contagem de caracteres ou de tokens.

• Chunk Size: O número de caracteres ou tokens em cada chunk.
• Chunk Overlap: O número de caracteres ou tokens do final de um chunk que são repetidos no início do próximo. O overlap ajuda a preservar o contexto em torno dos pontos de divisão, mitigando o problema de cortar uma frase ao meio.

Embora simples, essa abordagem é "cega" à estrutura do texto e frequentemente resulta em divisões inoportunas.

Nível 2: Recursive Character Splitting

Esta é a estratégia mais recomendada como ponto de partida para a maioria das aplicações de RAG. Em vez de usar um tamanho fixo cegamente, ela tenta dividir o texto de forma inteligente, respeitando sua estrutura natural.

Ela funciona com uma lista hierárquica de separadores. Por padrão, a ordem costuma ser:

1. Quebras de parágrafo (\n\n)
2. Quebras de linha (\n)
3. Espaços ( )
4. Caracteres (como último recurso)

O algoritmo tenta dividir o texto pelo primeiro separador da lista. Se os chunks resultantes ainda forem maiores que o chunk_size definido, ele passa para o próximo separador da lista e tenta novamente com esses chunks grandes. Esse processo recursivo garante que as divisões ocorram em limites semanticamente lógicos sempre que possível.

Nível 3: Document-Specific Splitting

Aqui é onde o chunking se torna realmente poderoso para o seu projeto. A ideia é adaptar a estratégia de divisão à estrutura inerente do tipo de documento que você está processando. Para seu agente de código, isso é essencial.

Chunking para Código (C#, JS, Dart) e Documentação Técnica (Markdown):

Você não pode tratar código-fonte como prosa. Dividir uma função ao meio ou separar uma declaração de classe de seus métodos seria desastroso. Em vez disso, você deve usar estratégias que entendam a sintaxe do código.

• Recursive Splitting com Separadores de Código: A maneira mais eficaz é usar o RecursiveCharacterTextSplitter com uma lista de separadores personalizada para a linguagem. Para C#, por exemplo, a hierarquia poderia ser ["\nclass ", "\nvoid ", "\npublic ", "\nprivate ", "\n\n", "\n", " "]. Isso prioriza a manutenção de classes e métodos inteiros.
• Markdown-Aware Splitting: Para arquivos README.md e documentos de arquitetura, use os cabeçalhos (##, ###) como separadores principais para manter seções lógicas unidas.

Chunking para PDFs com Tabelas e Imagens:

Documentos de regras de negócio podem vir em formatos complexos como PDFs. Uma simples extração de texto transformaria tabelas em texto desformatado e ignoraria imagens.

• Table-Aware Chunking: Use ferramentas como a biblioteca unstructured para extrair tabelas como unidades completas (por exemplo, em formato HTML ou Markdown) e inseri-las como chunks separados.
• Image Handling: Para imagens ou gráficos, uma abordagem é usar um modelo multimodal (como GPT-4 Vision) para gerar um resumo textual da imagem. Esse resumo pode ser então embarcado e recuperado.

Nível 4: Semantic Splitting

As estratégias anteriores se baseiam na estrutura física do texto (parágrafos, funções, etc.). O semantic splitting vai além, dividindo o texto com base no seu significado.

O processo geral é:

1. Dividir o documento em unidades pequenas, como frases.
2. Gerar um embedding para cada frase.
3. Calcular a similaridade (distância de cosseno) entre embeddings de frases consecutivas.
4. Identificar "pontos de quebra": locais onde a similaridade cai drasticamente, indicando uma mudança de tópico. Esses pontos se tornam os limites dos chunks.

Essa abordagem cria chunks que são semanticamente muito coerentes, mas é computacionalmente mais cara, pois requer a geração de embeddings durante a própria etapa de chunking.

Nível 5: Agentic & LLM-based Chunking

Esta é a fronteira da pesquisa em chunking. A ideia é usar um LLM para decidir como dividir o texto. Em vez de seguir regras fixas, você instrui o modelo a analisar o documento e identificar as seções lógicas.

Por exemplo, você pode dar ao LLM um documento e um prompt como: "Você é um especialista em análise de documentos. Identifique as seções lógicas neste documento e sugira onde dividi-lo em chunks semanticamente coerentes. Retorne os títulos das seções e suas posições."

Essa abordagem é a mais flexível e ciente do contexto, mas também a mais lenta e cara.

3. Framework Prático: Qual Estratégia Usar?

Com tantas opções, como decidir qual usar? A resposta é: comece simples e use uma abordagem híbrida baseada no tipo de conteúdo.

Aqui está um plano de ação para o seu projeto específico:

1. Ponto de Partida (Default): Use Recursive Character Splitting para todo o conteúdo que for prosa (documentos de texto, artigos). É o melhor equilíbrio entre desempenho e simplicidade. Comece com um chunk_size entre 512 e 1024 tokens e um chunk_overlap de 10-20%.

2. Para Documentos de Regras de Negócio (Google Drive):

   • Se forem documentos de texto (Google Docs), use o Recursive Character Splitting.
   • Se forem PDFs com tabelas e formatação complexa, use uma ferramenta como unstructured.io para fazer o partition_pdf e extrair tabelas e texto de forma estruturada.

3. Para Guias de Arquitetura (Markdown em repositórios Git):

   • Use RecursiveCharacterTextSplitter.from_language(language="markdown"). Isso usará os cabeçalhos (#, ##, etc.) como separadores prioritários, mantendo as seções do documento intactas.

4. Para Código-Fonte (C#, React/JS, Dart/Flutter):

   • Use RecursiveCharacterTextSplitter.from_language com as respectivas linguagens (language="c_sharp", language="js", language="dart" se suportado pela biblioteca, ou crie uma lista de separadores customizada). O objetivo é agrupar por classes e funções. Isso é crítico para que o agente receba blocos de código lógicos e funcionais como contexto.

Conclusão

Nesta lição, você aprendeu que o chunking é uma etapa decisiva no sucesso de um sistema RAG. Vimos que não existe uma única "melhor" estratégia; a abordagem ideal depende intrinsecamente da natureza dos seus dados.

Principais Pontos:

• O chunking equilibra o trade-off entre a precisão da busca (chunks menores) e a preservação do contexto (chunks maiores).
• Recursive Character Splitting é o ponto de partida recomendado para a maioria dos textos, por ser simples e respeitar a estrutura do documento.
• Para um projeto complexo como o seu, uma abordagem híbrida é necessária:
  • Use divisores cientes da linguagem para código-fonte.
  • Use divisores cientes de Markdown para documentação técnica.
  • Use ferramentas de parsing de documentos (como unstructured) para PDFs complexos.
• Semantic e LLM-based chunking são técnicas avançadas e caras, que devem ser consideradas quando a máxima qualidade é necessária e o custo não é um fator limitante.

Na Próxima Lição:

Até agora, cobrimos os três pilares da ingestão de dados para RAG: transformar texto em embeddings, dividir documentos em chunks e armazenar tudo em um vector store. Com nosso banco de conhecimento pronto, o próximo passo é construir o fluxo de recuperação. A próxima lição, "Orquestrar o pipeline fundamental de RAG: recuperar chunks relevantes para uma consulta e aumentar o prompt do LLM", unirá todas essas peças. Veremos como pegar uma consulta do usuário, encontrar os chunks mais relevantes em nosso vector store e passá-los para o LLM para gerar uma resposta informada.