El chunking en sistemas RAG ha pasado de ser una decisión trivial a un punto crítico de la arquitectura. Dos años de investigación académica y aplicaciones empresariales han revelado que la forma en que fragmentamos los documentos determina el techo de recuperación de información, y que la mayoría de las configuraciones por defecto están lejos de ser óptimas. En lugar de centrarse únicamente en el tamaño del fragmento, los estudios más recientes indican que el verdadero desafío no es dónde cortar, sino qué se pierde al cortar. Cada vez que un sistema de recuperación falla, la causa suele estar en la ingesta, no en el modelo generativo ni en el reranker. El problema fundamental es la pérdida de contexto: un fragmento aislado puede carecer de las referencias necesarias para ser interpretado correctamente, lo que reduce drásticamente su utilidad para responder consultas. Las estrategias más prometedoras, como la recuperación por documento padre o el enriquecimiento contextual previo a la incrustación, abordan directamente esa carencia sin depender de splitters más complejos. De hecho, técnicas como el contextual retrieval de Anthropic lograron reducir hasta un 49% las fallas de recuperación antes de aplicar reranking, simplemente añadiendo un breve resumen situacional a cada fragmento durante la indexación. Esto no implica que el tamaño o el solapamiento sean irrelevantes, pero su impacto es menor de lo que se pensaba: barrer valores entre 200 y 400 tokens con un splitter recursivo que respeta la estructura del documento suele dar mejores resultados que los defaults de 1000 tokens. La interacción con el modelo de embedding también es clave: lo que funciona con text-embedding-3-large puede no ser óptimo con otro modelo, por lo que es recomendable fijar el embedding y reajustar el chunking al cambiarlo.

Para las empresas que construyen sistemas RAG en producción, estas lecciones tienen implicaciones directas. No se trata solo de elegir un splitter, sino de integrar el chunking en un flujo de medición continua: construir un conjunto etiquetado de consultas, medir recall@k y la tasa de hechos completos en contexto, y ajustar en consecuencia. Herramientas como las que desarrollamos en aplicaciones a medida permiten automatizar estos procesos de evaluación y despliegue, asegurando que la ingesta de documentos no se convierta en un cuello de botella. Además, trabajamos con ia para empresas que implementan desde asistentes virtuales hasta sistemas avanzados de búsqueda semántica, y la experiencia demuestra que la mayoría de los equipos dedica semanas a depurar el recuperador cuando el verdadero problema está aguas arriba. La automatización de procesos de ingesta, combinada con una correcta gestión del chunking, puede marcar la diferencia entre un sistema RAG que funciona en demos y uno que responde de forma fiable en entornos reales.

La investigación también ha puesto el foco en la calidad de la extracción previa al chunking. Las tablas, gráficos y documentos escaneados suelen llegar al splitter como texto plano sin estructura, lo que inutiliza cualquier estrategia de fragmentación por buena que sea. Aquí entran en juego tecnologías como los parsers conscientes del diseño o los modelos de visión que reconstruyen la información antes de dividirla. En proyectos que combinan servicios cloud aws y azure con pipelines de datos, es habitual encontrarse con PDFs empresariales que ocultan información valiosa tras un formato visual. Nuestra aproximación desde servicios inteligencia de negocio y power bi también se beneficia de estas técnicas, porque la calidad del chunking impacta directamente en la fiabilidad de los paneles y alertas que se alimentan de datos extraídos mediante RAG. Incluso en entornos donde se requiere ciberseguridad y auditoría de datos, un chunking deficiente puede generar falsos negativos en la detección de información sensible.

Una tendencia emergente es el uso de agentes IA que orquestan consultas complejas sobre múltiples documentos. Estos agentes dependen de que los fragmentos recuperados contengan el contexto necesario para tomar decisiones, y aquí es donde técnicas como el late chunking de Jina AI o la indexación contextual están demostrando su valor. Sin embargo, la recomendación práctica para la mayoría de los equipos es empezar con lo básico: un splitter recursivo que respete encabezados y párrafos, tamaños entre 200 y 400 tokens, solapamiento mínimo solo para evitar cortes en medio de una idea, y una capa de recuperación por documento padre que devuelva el bloque completo. Luego, medir y optimizar con datos reales. En software a medida desarrollamos soluciones que integran estas mejores prácticas de forma nativa, permitiendo a las organizaciones centrarse en el valor del negocio sin tener que reinventar la rueda cada vez que un documento cambia de formato o un modelo de embedding se actualiza. La lección más valiosa de los últimos dos años es que el chunking no es un detalle de implementación, sino una decisión estratégica que establece el límite superior de lo que un sistema RAG puede ofrecer.