Um writeup prático no Towards Data Science esta semana, assinado por Priyansh Bhardwaj, explica por que a maioria das falhas de RAG em produção são falhas de chunking, e não de recuperação ou geração. O insight que ancora o texto é fácil de citar: "O LLM não é o gargalo. O gargalo é a decisão sobre onde um chunk termina e o próximo começa". O artigo vai além do argumento abstrato com quatro modos de falha concretos e melhorias medidas a partir de uma estratégia de chunking ciente do tipo de documento. Para quem já enviou um sistema RAG e o viu retornar respostas tecnicamente plausíveis mas sutilmente erradas, os modos de falha vão parecer familiares.

Os quatro padrões que Bhardwaj aponta são todos comuns e todos caros de debugar. O corte em fronteiras lógicas é o pior: um chunk termina com "os contratados seguem o processo de onboarding padrão como descrito na Seção 4" e o próximo começa com "a menos que estejam engajados em um projeto classificado sob o Anexo B", produzindo dois fragmentos, cada um errado em isolamento, cuja combinação o recuperador pode nunca reagregar. As janelas de tokens de tamanho fixo (os 512 tokens com 50 de sobreposição que continuam sendo padrão em muitos stacks) cortam alegremente exceções de três parágrafos e listas numeradas no meio, porque são cegas à estrutura. O achatamento de tabelas transforma grades em longas sequências de valores órfãos divorciados dos seus cabeçalhos. A extração de PDF sem consciência de layout compõe tudo isso, porque o stream de texto subjacente deixa de corresponder à estrutura visual em que o autor se apoiava.

O remédio recomendado não é empolgante e é exatamente certo. Rotear por tipo de documento. Documentação estruturada com hierarquia clara (specs, runbooks) quer chunking hierárquico e AutoMergingRetriever. Conteúdo narrativo (políticas, guias, prosa explicativa) quer SentenceWindowNodeParser com uma janela de contexto de 3 sentenças. Conteúdo misto e não estruturado quer chunking semântico, com a ressalva honesta sobre custo de latência. PDFs e slides precisam de pré-processamento ciente de layout via PyMuPDF ou pdfplumber antes de qualquer chunking. O benchmark de Bhardwaj sobre a troca para conteúdo narrativo é pouco glamouroso mas real: o context recall foi de 0,72 para 0,88 e a precisão contextual de 0,71 para 0,83 só combinando o chunker ao formato do documento. Esse é o tipo de número que você obtém quando para de tratar RAG como problema de modelo e começa a tratá-lo como problema de engenharia de conteúdo.

Se o seu sistema RAG está em produção e você nunca instrumentou o chunking como fonte de falha, é aí que olhar primeiro. Passos concretos: amostre 50 consultas recentes em que a resposta veio errada ou rala, leia os chunks recuperados na mão, e conte quantos estão condenados apenas pelas fronteiras de chunk, independentemente de qual modelo gere a partir deles. Esse número quase sempre é maior do que os times esperam. O segundo passo é parar de tratar seu corpus como homogêneo; roteie por tipo de documento, porque o chunker que funciona para um PDF de 200 páginas de política não vai funcionar para um catálogo de SKUs carregado de tabelas. Isso emparelha com o artigo sobre memweave de ontem. Ambos estão fazendo o mesmo ponto maior por ângulos diferentes. As escolhas de infraestrutura que parecem mais empolgantes (vector DBs maiores, modelos mais novos, contextos mais longos) geralmente não são onde moram seus problemas de qualidade. As escolhas chatas sobre como seus dados são cortados e indexados, sim.