El Chunking es una Decisión Arquitectónica, No un Paso de Limpieza

Llevo meses viendo el mismo patrón. Un equipo me contacta porque su RAG “no da buenas respuestas”. Reviso el pipeline y siempre encuentro lo mismo: semanas invertidas en elegir el modelo de embedding perfecto, el vector store más rápido, el LLM más capaz. ¿Y el chunking? Diez líneas copiadas de la documentación de LangChain. chunk_size=512, overlap de 50, y a producción.

Ese descuido es, consistentemente, el error más caro de todo el stack.

Lo que divides y cómo lo divides determina lo que tu sistema puede recuperar. Un LLM no puede razonar sobre información que el retriever nunca le pasa. Y el retriever no puede pasar lo que no está bien indexado. La cadena de fallos empieza aquí, en cómo troceas el texto. Todo lo que viene después —el reranking, el prompt, el modelo— trabaja con lo que el chunking le da.

Antes de complicarlo: qué es realmente el chunking

Para entender por qué esto importa tanto, piensa en el chunking como meter el contenido de tus documentos en cajas. Cada caja recibe una etiqueta automática — el embedding, el vector — que describe lo que hay dentro. Cuando un usuario hace una pregunta, el sistema busca las cajas cuya etiqueta más se parece a esa pregunta.

El tamaño y el corte de cada caja lo determinan todo. Si la caja es demasiado grande y mezcla cinco temas, la etiqueta es un resumen vago de todo: se parece un poco a muchas preguntas pero no se parece mucho a ninguna. Si la caja es demasiado pequeña — media oración, sin contexto — la etiqueta puede ser precisa, pero cuando el LLM abre la caja no encuentra suficiente material para responder. Y si el corte es malo — a mitad de tabla, a mitad de idea — la etiqueta es confusa Y el contenido está incompleto. Pierdes por los dos lados.

El objetivo es que cada caja contenga una idea completa: lo suficientemente específica para que su etiqueta sea encontrable, y lo suficientemente completa para que cuando la abras tenga lo que necesitas. Eso es todo. Todo lo que viene a continuación — las estrategias, los benchmarks, las técnicas avanzadas — son formas de conseguir esto.

Dónde se manifiestan los problemas

En concreto, un mal chunking afecta tres variables que no puedes compensar más adelante:

Recall — ¿Aparece el fragmento correcto entre los que devuelve el retriever? Un chunk de 2.048 tokens que habla de cinco temas tiene un vector que es el promedio de todo eso: no se parece lo suficiente a ninguna query concreta. Y un chunk de 50 tokens sin contexto le falta las palabras que harían match con la pregunta. En los dos casos, el fragmento que necesitas no aparece.

Precisión del contexto — ¿Lo que el LLM recibe le basta para responder bien? He visto chunks que el retriever localiza correctamente pero que al modelo no le sirven de nada porque empiezan a mitad de un razonamiento. Les falta el párrafo anterior, la definición del término, el “de qué estamos hablando aquí”. El chunk correcto con contexto insuficiente genera una respuesta que parece correcta pero no lo es.

Faithfulness — ¿El LLM se inventa cosas? Un fragmento que dice “la ciudad implementó el nuevo protocolo en enero” sin mencionar qué ciudad ni qué protocolo es una invitación a que el modelo rellene los huecos con lo que le parezca. Y lo hará con total confianza.

Estas tres variables son el techo. Ningún reranker, ningún prompt engineering, ningún modelo más potente las compensa si el chunking las degrada de entrada.

Lo que dicen los benchmarks cuando dejas de adivinar

Durante años, el folklore del sector vendía dos ideas contradictorias: que los chunks semánticos siempre ganan porque “respetan el flujo natural del texto”, y que más contexto por chunk siempre es mejor porque el LLM tiene más con qué trabajar.

Las dos son falsas. Y tenemos datos para demostrarlo.

El equipo de Vecta sometió 7 estrategias de chunking a un corpus de 50 documentos académicos reales — casi un millón de tokens, desde astrofísica hasta ciencias sociales. Lo interesante es cómo lo midieron: normalizaron la cantidad de contexto que recibía el LLM (~2.000 tokens en todos los casos). La mayoría de comparativas no hacen esto — si usas top-k=10, la estrategia con chunks grandes mete 10x más contexto que la de chunks pequeños, y claro, gana por volumen, no por calidad. Vecta aisló la variable que importa: cómo de buenos son los trozos en sí mismos.

Antes de ver los resultados, conviene entender qué hace cada estrategia, porque los nombres no son nada intuitivos:

Fixed-size es la opción bruta: corta cada N tokens, punto. Le da igual si estás a mitad de una frase, de un párrafo o de una tabla. Trocea y listo.

Recursive character splitting es más lista. Tiene un tamaño objetivo (por ejemplo, 512 tokens) e intenta respetar la estructura natural del texto para llegar a él. Primero intenta cortar por párrafos. Si un párrafo es demasiado largo, baja a oraciones. Si una oración no cabe, baja a palabras. Solo corta a nivel de carácter como último recurso. No entiende el contenido — simplemente busca los puntos de corte más naturales dentro del tamaño que le pides.

Semantic chunking sí intenta entender el contenido. Vectoriza el texto oración a oración y corta cuando detecta un cambio de tema — cuando la similitud entre oraciones consecutivas cae por debajo de un umbral. La promesa es que cada chunk habla de una sola idea coherente.

Propositional chunking va un paso más allá: descompone el texto en hechos atómicos. “Marc firmó el contrato en enero con condiciones preferentes” se convierte en tres chunks separados: “Marc firmó un contrato”, “El contrato se firmó en enero”, “El contrato tiene condiciones preferentes”. Cada proposición es autónoma e independiente.

Los resultados del estudio de Vecta:

Estrategia	Precisión de respuesta	F1 de recuperación
Recursive character splitting (512 tokens)	69%	0.92
Semantic chunking	54%	0.42
Propositional chunking	51%	—
Fixed-size chunking (extremos)	< 50%	—

Sí, la estrategia más básica de las “inteligentes” ganó. Por 15 puntos porcentuales. Recursive character splitting — que no entiende nada del contenido, solo respeta la estructura del texto — machacó al semantic chunking, que en teoría es superior porque “entiende el contenido”.

NVIDIA llegó a la misma conclusión en su benchmark de 2024 sobre FinanceBench y KG-RAG. Probaron tamaños desde 128 hasta 2.048 tokens: 128 fue el peor resultado del estudio (0.421 de precisión), 2.048 mostró retornos decrecientes claros. La zona segura: 512-1.024 tokens con un 15% de solapamiento.

Por qué el chunking semántico falla donde importa

El resultado del semántico parece contradictorio: si es la estrategia que “entiende el contenido”, ¿cómo puede perder contra una que solo busca saltos de párrafo?

Porque optimiza la cosa equivocada. Busca que cada chunk sea temáticamente puro — que hable de una sola cosa. Y para conseguirlo, corta agresivamente. En los tests de Vecta, los chunks semánticos promediaron 43 tokens. Cuarenta y tres. Una media oración. El retriever los localiza con precisión quirúrgica, pero cuando el LLM los recibe están tan pelados de contexto que no puede hacer nada útil con ellos. Es como encontrar la pieza exacta del puzzle pero no tener las piezas de alrededor para saber dónde encaja.

El chunking proposicional lleva esto al extremo: promedio de 11.2 palabras por chunk. Cada hecho aislado en su propio fragmento. Funciona en benchmarks diseñados para recuperar datos sueltos. En producción, con consultas que requieren razonar juntando varias oraciones: 51% de precisión. No me arriesgaría.

Segmentación por página: el ganador que nadie menciona

Esto me sorprendió cuando lo vi por primera vez. En el benchmark de NVIDIA, usar cada página física del documento como chunk obtuvo la mayor precisión media (0.648) con la desviación estándar más baja (0.107) de todas las estrategias.

Tiene sentido si lo piensas: los PDFs bien formateados — informes financieros, documentos legales, manuales técnicos — organizan la información siguiendo límites de página que coinciden con unidades lógicas de contenido. La paginación ya es un chunking natural, hecho por el autor del documento.

Funciona especialmente bien cuando citar por número de página tiene valor (legal, compliance, auditoría). No funciona con exports de texto continuo donde las páginas son arbitrarias.

La paradoja de precisión-recall y cómo la resolvemos

El problema de fondo es que chunks pequeños y grandes optimizan objetivos opuestos:

Chunks pequeños: el vector es específico, el retriever los encuentra, pero el LLM recibe contexto insuficiente.
Chunks grandes: el LLM tiene contexto, pero el vector diluye la señal y el retriever ignora lo relevante.

La arquitectura padre-hijo resuelve esta tensión. La idea es directa: busca en fino, responde en amplio.

Para que se entienda con un ejemplo: imagina un contrato de 40 páginas. Los “hijos” son oraciones individuales — “el plazo de entrega será de 30 días naturales”. Los “padres” son secciones completas — toda la cláusula de condiciones de entrega, con su contexto, excepciones y penalizaciones. Solo los hijos van al índice vectorial.

Cuando alguien pregunta “cuál es el plazo de entrega”, el retriever encuentra la oración exacta vía el hijo. Pero el LLM recibe la sección completa del padre, con todo el contexto que necesita para dar una respuesta que tenga sentido — no solo “30 días naturales” sino “30 días naturales salvo en los supuestos X e Y, donde el plazo se extiende a 45 días”.

En due diligence de M&A, búsqueda de arte previo en patentes o análisis de historiales clínicos, esta es la arquitectura que me encuentro en producción. No porque sea la más sofisticada — no lo es — sino porque resuelve el problema real sin añadir una complejidad que no puedas mantener.

Dos técnicas avanzadas que merecen atención

Late Chunking (Jina AI)

El chunking convencional corta antes de vectorizar. Eso destruye las referencias cruzadas: si el segmento 1 habla de “Berlín” y el segmento 10 dice “la ciudad implementó un impuesto”, el embedding del segmento 10 no tiene ni idea de que “la ciudad” es Berlín.

Late Chunking le da la vuelta. Primero pasa el documento completo por el modelo de embeddings — así cada token ya “sabe” qué hay antes y después de él en el documento. Después corta en chunks y genera los vectores. La diferencia es que cada embedding ya incorpora el contexto global, no solo el de su trozo. En el ejemplo anterior, el segmento 10 mantiene la huella de “Berlín” aunque su texto no lo mencione.

En los benchmarks BEIR de Jina, las mejoras son consistentes: nDCG@10 sube de 64.20% a 66.10% en SciFact y de 33.25% a 33.84% en FiQA2018. No es un salto enorme, pero escala con la longitud del documento — cuanto más largo, más referencias cruzadas rescata.

El requisito es un modelo de contexto largo tipo jina-embeddings-v3. Con Ada-002 o modelos de ventana corta, la técnica no aplica. Y el coste computacional de la ingestión sube, porque procesas cada documento entero antes de cortar.

Contextual Retrieval (Anthropic)

Anthropic atacó el mismo problema desde el otro lado: en lugar de procesar todo primero, añade contexto a cada chunk antes de vectorizarlo. Le pasa al LLM el chunk aislado junto con el documento completo, y el modelo genera una descripción contextual que se antepone al texto antes de embedizar.

Contextual Retrieval redujo las recuperaciones fallidas en un 49%. Con reranking, la reducción de errores llega al 67%.

El coste es obvio: tienes que procesar cada chunk con un LLM antes de indexarlo. Anthropic lo mitiga con prompt caching, pero sigue siendo caro para bases grandes. Y aquí viene el dato que más me gusta de su paper: si tu corpus tiene menos de 200.000 tokens (~500 páginas), probablemente es más eficiente meter todo el conocimiento en el prompt con caché y ahorrarte el pipeline RAG entero. A veces la mejor arquitectura es no construir una.

Cuidado con enriquecer demasiado los chunks

Cuando descubres Contextual Retrieval — o cualquier técnica que inyecte metadatos en el chunk — la tentación es pensar que más contexto siempre ayuda. He caído en esa trampa.

En un proyecto con documentación legal, añadimos a cada chunk un resumen del documento, el título de la sección y las entidades principales. La idea era darle al vector más señal para que el retriever afinara mejor. Lo que conseguimos fue lo contrario: cuando el usuario preguntaba por una cláusula específica, el sistema devolvía el contrato correcto pero la cláusula equivocada. Cada vez.

El problema es intuitivo una vez lo ves: si todos los chunks de un mismo documento comparten el mismo resumen y las mismas entidades, sus vectores convergen. El embedding deja de representar lo que dice ese chunk y empieza a representar de qué va el documento en general. La señal local — que es la que necesitas para encontrar el fragmento exacto — se ahoga en el contexto global.

Y esto pasa con cualquier tipo de enriquecimiento: títulos, resúmenes, entidades extraídas, contexto generado por LLM. Todo lo que añadas desplaza el vector. Un poco ayuda. Demasiado, y tus chunks se vuelven indistinguibles entre sí dentro del mismo documento.

Mi regla práctica: que el texto que añadas no supere un tercio del texto original del chunk. Y siempre — siempre — mide el impacto con tus queries reales antes y después del enriquecimiento. La señal de alarma es clara: si las respuestas son vagamente correctas pero no específicas (aciertan el documento pero fallan la sección), probablemente estás diluyendo los vectores.

Documentos con tablas: el pipeline vectorial no es suficiente

Todo lo anterior asume texto narrativo. Los documentos corporativos reales son otra cosa: informes financieros con tablas anidadas, contratos con matrices de condiciones, inventarios con columnas cruzadas.

El enfoque habitual es linealizar las tablas a Markdown antes de indexar. Lo he visto en prácticamente todos los pipelines que he auditado, y el problema siempre es el mismo: pierdes las relaciones entre filas y columnas. Cuando alguien pregunta “¿cuál fue la facturación del Q3 para el producto X?”, el retriever necesita cruzar una fila con una columna. En texto plano linealizado, esa relación no existe — es una cadena de celdas donde la estructura espacial ha desaparecido.

Lo que mejor me ha funcionado es separar los flujos. El texto narrativo va por el pipeline vectorial estándar. Las tablas se extraen como datos estructurados — JSON, CSV, o directamente se consultan vía text-to-SQL si están en base de datos. Intentar que un único pipeline vectorial maneje ambos es pedirle algo para lo que no está diseñado.

Si no puedes separar los flujos (por tiempo, por complejidad, por volumen), la segmentación por página suele ser el mejor compromiso: mantiene la tabla completa dentro de un chunk y le da al LLM contexto suficiente para interpretar filas y columnas. No es perfecto, pero es pragmático y funciona razonablemente bien en la mayoría de casos.

Cómo elijo estrategia en la práctica

Esto es literalmente lo que hago cuando arranco un proyecto RAG nuevo. No es un framework — es el proceso que me funciona:

Corpus heterogéneo, presupuesto limitado → Recursive character splitting, 512-1.024 tokens, overlap del 15-20%. Sin más. Esto cubre el 80% de los casos y gana en benchmarks independientes. Calibra hacia 512 para queries factuales específicas; hacia 1.024 para queries analíticas que necesitan contexto.

PDFs bien estructurados (legal, financiero, técnico) → Segmentación por página. Es lo más estable que hay y lo más simple de implementar.

Queries complejas donde no puedes permitirte perder detalle → Padre-hijo. Requiere indexar dos niveles y mantener vinculación, pero es la arquitectura más robusta cuando el recall incompleto tiene coste real.

Documentos largos con muchas referencias cruzadas → Late Chunking con jina-embeddings-v3. Coste computacional en ingestión, pero la mejora es consistente.

Texto + tablas con queries que cruzan ambos → Separa los pipelines: vectorial para texto, estructurado para tablas. Si no puedes, segmentación por página como compromiso.

Puedes costear ingestión con LLM → Contextual Retrieval. El -49% en retrieval failures es real. Pero no te pases enriqueciendo: que el contexto añadido no supere un tercio del chunk original, o empezarás a diluir vectores sin darte cuenta.

El modelo de embedding importa menos de lo que crees

He visto equipos gastar semanas evaluando modelos de embedding del MTEB leaderboard buscando un punto más de rendimiento, cuando el cuello de botella era unos chunks que cortaban tablas por la mitad. Es como comprar una cámara de 100 megapíxeles y ponerle un objetivo desenfocado.

Un estudio que cruzó 90 combinaciones de chunking + embeddings en 7 dominios de arXiv confirma la intuición: la combinación ganadora fue text-embedding-3-small con SentenceSplitter (512 tokens, overlap de 200). El modelo “pequeño” de OpenAI, con chunking simple, superó a BGE-M3 y sus 1.024 dimensiones.

BGE-M3 es un modelo excelente, pero es lento — duplica tiempos de ingestión sin GPUs H100 — y más sensible a la jerga de dominio. Funciona bien en textos financieros, baja en astrofísica. Los modelos compactos dan resultados más estables entre dominios y son más baratos de operar.

La lección es siempre la misma: arregla la segmentación antes de escalar el modelo de embedding. Un modelo grande con chunks malos pierde contra un modelo pequeño con chunks bien hechos.

Lo que me llevo después de ver muchos RAGs en producción

El chunking es el techo de rendimiento de tu sistema. El LLM más capaz, el vector store más rápido y el reranker más sofisticado no recuperan información que entró mal indexada.

La pregunta correcta no es “¿qué chunk size recomienda la documentación de LangChain?” Es “¿qué estructura tienen mis documentos y qué tipo de preguntas va a hacer mi sistema?” Un día de experimentación con recursive splitting vs. parent-child vs. page-level, medida con RAGAS sobre tus queries reales, da más información que cualquier artículo — incluido este.

Y si introduces contexto adicional en los chunks — resúmenes, títulos, metadatos — ve con cuidado. La dilución vectorial es silenciosa: el sistema sigue respondiendo, pero con el documento correcto en la sección equivocada.

Eso es más peligroso que una respuesta vacía.

Este artículo forma parte de una serie sobre arquitectura de sistemas RAG en producción. Los siguientes cubrirán embeddings y modelos de recuperación, hybrid search y reranking, y evaluación con RAGAS.