Un writeup práctico en Towards Data Science esta semana, firmado por Priyansh Bhardwaj, explica por qué la mayoría de las fallas de RAG en producción son fallas de chunking, no de recuperación ni de generación. El insight que ancla el texto es fácil de citar: "El LLM no es el cuello de botella. El cuello es la decisión de dónde termina un chunk y empieza el siguiente". El artículo pasa del argumento abstracto a cuatro modos de falla concretos y mejoras medidas desde una estrategia de chunking consciente del tipo de documento. Para cualquiera que haya enviado un sistema RAG y lo haya visto devolver respuestas técnicamente plausibles pero sutilmente erróneas, los modos de falla van a parecer familiares.

Los cuatro patrones que señala Bhardwaj son todos comunes y todos caros de debuggear. El corte en fronteras lógicas es el peor: un chunk termina con "los contratistas siguen el proceso de onboarding estándar como se describe en la Sección 4" y el siguiente empieza con "a menos que estén contratados en un proyecto clasificado bajo el Anexo B", produciendo dos fragmentos, cada uno incorrecto en aislamiento, cuya combinación el recuperador puede no reensamblar nunca. Las ventanas de tokens de tamaño fijo (los 512 tokens con 50 tokens de solapamiento que siguen siendo el default en demasiados stacks) cortan alegremente excepciones de tres párrafos y listas numeradas por la mitad, porque son ciegas a la estructura. El aplanado de tablas convierte grillas en largas secuencias de valores huérfanos separados de sus encabezados. La extracción de PDF sin conciencia de layout compone todo lo anterior, porque el stream de texto subyacente ya no coincide con la estructura visual en la que el autor se apoyaba.

El remedio recomendado no es emocionante y es exactamente el correcto. Rutear según el tipo de documento. La documentación estructurada con jerarquía clara (specs, runbooks) quiere chunking jerárquico y AutoMergingRetriever. El contenido narrativo (políticas, guías, prosa explicativa) quiere SentenceWindowNodeParser con una ventana de contexto de 3 oraciones. El contenido mixto y no estructurado quiere chunking semántico, con la advertencia honesta sobre el costo de latencia. Los PDFs y las slides necesitan preprocesamiento consciente de layout vía PyMuPDF o pdfplumber antes de cualquier chunking. El benchmark de Bhardwaj sobre el switch a contenido narrativo es poco glamoroso pero real: el context recall subió de 0,72 a 0,88 y la precisión contextual de 0,71 a 0,83 con solo matchear el chunker a la forma del documento. Esos son el tipo de números que obtenés cuando dejás de tratar a RAG como un problema de modelo y empezás a tratarlo como un problema de ingeniería de contenido.

Si tu sistema RAG está en producción y nunca instrumentaste el chunking como fuente de falla, ese es el lugar donde mirar primero. Pasos concretos: muestreá 50 consultas recientes donde la respuesta fue incorrecta o magra, leé los chunks recuperados a mano, y contá cuántos están condenados solo por las fronteras de chunk, sin importar qué modelo genere a partir de ellos. Ese número casi siempre es más grande que lo que los equipos esperan. El segundo paso es dejar de tratar a tu corpus como homogéneo; ruteá por tipo de documento, porque el chunker que funciona para un PDF de 200 páginas de política no va a funcionar para un catálogo de SKUs cargado de tablas. Esto se empareja con el artículo de memweave de ayer. Los dos están haciendo el mismo punto más amplio desde ángulos distintos. Las decisiones de infraestructura que se ven más emocionantes (vector DBs más grandes, modelos más nuevos, contextos más largos) generalmente no son donde viven tus problemas de calidad. Las decisiones aburridas sobre cómo se corta e indexa tu data, sí.