Quando um sistema de RAG dá uma resposta errada ou pela metade, o modelo geralmente não é o motivo. O chunking é. Se a passagem que contém a resposta nunca chega ao contexto recuperado, nenhum modelo consegue responder a partir dela, e nenhuma quantidade de ajuste de prompt muda isso. O chunking decide o que pode ser recuperado, o que o torna a primeira coisa a inspecionar e a última coisa que a maioria dos times observa.

O Amazon Bedrock Knowledge Bases permite escolher uma estratégia de chunking quando você cria uma fonte de dados. Essa única escolha silenciosamente define o teto da sua qualidade de retrieval. Erre nisso e você vai passar semanas culpando o modelo de embedding, o reranker ou o LLM por um problema que vive em como você corta os documentos.

Por que chunking é a decisão estrutural

O retrieval opera sobre chunks, não sobre documentos. Cada chunk é convertido em um vetor, e no momento da consulta você busca os top-k chunks mais próximos da pergunta. Dois tipos de falha decorrem diretamente do tamanho do chunk.

Chunks grandes demais diluem o embedding. Um chunk de 2000 tokens cobrindo quatro subtópicos produz um único vetor que é a média dos quatro, então ele combina fracamente com tudo e fortemente com nada. O chunk certo fica enterrado sob quase-acertos. Chunks pequenos demais cortam o contexto. Uma definição separada do seu exemplo, ou um passo separado do seu aviso, é recuperada de forma limpa mas chega sem o texto ao redor que a tornava útil. A resposta está tecnicamente presente e praticamente incompleta.

O trabalho de uma estratégia de chunking é cortar em fronteiras que fazem sentido, para que cada chunk seja uma ideia coerente, autocontida o suficiente para responder e específica o suficiente para rankear bem.

As três estratégias que o Bedrock oferece

Chunking de tamanho fixo

Divide a cada N tokens com alguma sobreposição. É o padrão e o mais barato, e funciona bem para conteúdo uniforme, rico em prosa, onde as mudanças de tópico são graduais. É ativamente ruim para documentos estruturados, porque corta onde quer que o contador de tokens caia: no meio de uma tabela, no meio de uma lista, entre um título e o parágrafo que ele introduz. A sobreposição amortece o dano mas não o remove. Recorra ao tamanho fixo quando seu corpus é homogêneo e você quer uma linha de base, não porque é o padrão.

Chunking semântico

Divide pelo significado. O chunking semântico mede a similaridade de embedding entre frases adjacentes e começa um novo chunk onde o tópico muda, então as fronteiras caem entre ideias em vez de em uma contagem fixa de tokens. Esse é o padrão certo para conteúdo misto: FAQs, artigos de conhecimento, prosa mista onde cada resposta ou conceito quer permanecer inteiro. Custa mais para construir o índice porque ele faz embedding enquanto faz chunking, mas a diferença de qualidade de retrieval em corpora heterogêneos é o motivo para pagar esse custo.

Chunking hierárquico

Constrói chunks pai e filho. Chunks filhos pequenos são convertidos em embedding e combinados para retrieval preciso, mas o chunk pai maior é o que é retornado ao modelo, então você rankeia pela especificidade e responde com contexto. Isso se encaixa em documentos com estrutura real, manuais técnicos, contratos legais, qualquer coisa com seções e subseções, onde uma consulta acerta uma cláusula estreita mas o modelo precisa da seção ao redor para usá-la corretamente. É o mais elaborado de raciocinar e o melhor encaixe quando seus documentos têm uma hierarquia genuína a explorar.

Avalie o retrieval antes de culpar o modelo

O hábito mais útil de todos é separar a questão do retrieval da questão da geração. Antes de mexer no prompt ou trocar o modelo, pergunte uma coisa: para um conjunto de perguntas reais, o chunk que contém a resposta apareceu no contexto recuperado?

  • Construa um pequeno conjunto de avaliação: de 30 a 50 perguntas reais, cada uma com a passagem de origem que a responde.
  • Execute apenas o retrieval. Para cada pergunta, verifique se a passagem correta aparece nos top-k resultados. Essa taxa de acerto é o seu teto de retrieval.
  • Se a passagem correta não está sendo recuperada, a qualidade da geração é irrelevante. A correção é chunking, embeddings, ou top-k, não o modelo.
  • Só depois que o retrieval traz de forma confiável a passagem certa é que faz sentido trabalhar em como o modelo a usa.

A maioria dos times pula isso e vai direto para prompt engineering, o que explica por que passam tanto tempo em um problema que uma medição de taxa de acerto de retrieval teria localizado em uma tarde. Se o retrieval está perdendo a resposta metade das vezes, você tem um problema de chunking disfarçado de modelo.

Um ponto de partida prático

Comece com chunking semântico para conteúdo de conhecimento geral, migre para hierárquico quando seus documentos têm estrutura de seção clara e as respostas dependem do contexto ao redor, e mantenha o tamanho fixo apenas para prosa grande e uniforme onde você quer velocidade e simplicidade. Depois meça a taxa de acerto de retrieval, mude uma variável, e meça de novo. Chunking não é um valor de configuração que você define e esquece. É o botão com mais influência sobre se o seu sistema de RAG é bom ou não.

A conclusão

A qualidade do RAG é decidida antes mesmo do modelo rodar, no momento em que você corta seus documentos em chunks. Tamanho fixo é uma linha de base, semântico é o padrão sensato para conteúdo misto, e hierárquico vence quando estrutura importa. Meça a taxa de acerto de retrieval em um conjunto de perguntas reais primeiro, porque se a resposta nunca entra no contexto, o modelo nunca foi o problema.

Leia isto a seguir

Para o lado de armazenamento e infraestrutura de rodar busca vetorial em escala, as notas de campo de nuvem estão em ercan.cloud, e o hub está em ercanermis.com.