Capítulo 3 — Frameworks avanzados de chunking

Tercera entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. Donde las elecciones ingenuas degradan en silencio todo lo que viene después — y donde dos técnicas recientes han cambiado lo que es posible en la frontera.

Por qué existe este capítulo

Una vez que los documentos están parseados, la siguiente decisión es también la más consecuente: cómo romperlos en piezas lo bastante pequeñas para embeberlas y lo bastante grandes para seguir significando algo por sí solas. Esto es chunking. Un chunk que separa una definición de su matiz se recupera con confianza y está equivocado. Un chunk que junta cinco temas no relacionados diluye cada embedding que toca. El sistema de recuperación que construyas encima sólo puede rescatar lo que el paso de chunking preservó, y los modos de fallo aquí son silenciosos — el retriever sigue devolviendo candidatos, el modelo sigue produciendo respuestas fluidas y sólo el usuario nota que las respuestas están sutilmente equivocadas.

3.1 El espectro del chunking

Ayuda ordenar las estrategias por cuánto saben del documento. En un extremo, el chunking de tamaño fijo no sabe nada — cuenta tokens y corta. Rápido, determinista y aceptable para texto corto estilísticamente uniforme (transcripciones de chat, entradas de FAQ, reseñas de clientes). Sobre documentos técnicos estructurados es un desastre silencioso. El chunking recursivo aplica una lista priorizada de separadores — párrafos, después saltos de línea, después frases, después palabras — cortando por el límite de mayor prioridad que quepa bajo el tamaño objetivo. Casi tan barato como el de tamaño fijo y sustancialmente mejor. Es el valor por defecto correcto para la mayoría de los equipos.

El chunking semántico mueve la decisión de sintaxis a significado: embebe cada frase, recorre la secuencia y marca límites de tema donde la similitud entre frases adyacentes cae por debajo de un umbral. Funciona bien en prosa larga con pistas estructurales débiles (informes de analistas, transcripciones de entrevistas) y mal en documentos técnicos estructurados donde las referencias cruzadas densas y el boilerplate repetido confunden a los embeddings de frase. El chunking consciente de la estructura trata el documento parseado como un árbol y trocea por él — por sección, por nivel de encabezado, por función de código. Bien hecho es la forma más fiel de chunking; hecho sin un parser consciente del layout aguas arriba, no produce nada distinto del chunking recursivo, porque la estructura no se extrajo nunca. Estos cuatro son alternativas, no un stack que desplegar a la vez.

3.2 El mito del solapamiento y el precipicio de contexto

Casi todos los tutoriales recomiendan un solapamiento del 15-20%. La intuición es correcta hasta cierto punto — el solapamiento evita pérdidas en los bordes — pero la curva se aplana rápido. El primer 10% recupera la mayor parte del beneficio. Pasado el 25% más o menos, la precisión es prácticamente plana mientras el coste sube en tres ejes: la factura de embeddings escala lineal con el número de chunks, el tamaño del índice y la latencia de consulta crecen, y los mejores resultados del retriever empiezan a ser cuasi duplicados entre sí. Una consulta del usuario casa con un pasaje en los chunks A, B y C; la ventana de contexto se consume sin que llegue información nueva; el reranker gasta su presupuesto reordenando variantes del mismo contenido. Un equipo tirando de un 30-40% de solapamiento debería leerlo como una señal de que el chunker está mal, no de que el solapamiento se queda corto.

Relacionado pero distinto está el precipicio de contexto: la caída abrupta en la calidad de recuperación cuando un chunk pierde los términos ancla que lo hacían encontrable. Un párrafo que abre con "La enmienda de 2023 a la Política 47-B obligó a todas las sucursales a…" y luego describe el requisito en frases posteriores. Corta tras la apertura y el chunk que describe el requisito ya no menciona la política, la enmienda ni el año. Se recuperará con confianza para consultas no relacionadas y fallará en las canónicas. La recuperación es top-k — o el chunk sale o no sale, sin degradación elegante. El precipicio es el modo de fallo dominante en corpus técnicos, donde pronombres y formas cortas arrastran el antecedente a lo largo de una sección.

3.3 Ajustar el tamaño del chunk al tipo de consulta

El tamaño del chunk se debate a menudo como si hubiera una única respuesta correcta. No la hay, porque la respuesta correcta depende de qué consultas reciba el sistema. Una consulta factual — "¿cuál era la franquicia de la póliza 47-B en 2024?" — quiere 150-300 tokens, suficientemente estrechos para ser precisos, suficientemente anchos para desambiguar. Una consulta de razonamiento — "resume los cambios entre las versiones de 2023 y 2024 y explica cómo afectan a la renovación" — quiere 800-1.200 tokens para preservar el tejido conector dentro de una sección. El tamaño óptimo difiere entre 4 y 8 veces entre ambos, y el tráfico de producción suele ser una mezcla.

Dos respuestas productivas. La indexación multi-granularidad almacena el mismo corpus con varios tamaños de chunk y enruta las consultas por clasificación de intención. La recuperación jerárquica indexa chunks pequeños para precisión pero devuelve sus secciones padre para contexto — un único índice, condicionado en tiempo de consulta, más común en producción porque degrada de forma elegante cuando la clasificación de intención falla. El patrón parent-document es una de las técnicas de mayor valor en la literatura de recuperación en producción.

3.4 Recuperación contextual y late chunking

La frontera es reconocer que el chunk y el embedding son problemas separables. Dos técnicas recientes explotan esa separación en direcciones opuestas. La recuperación contextual, popularizada por Anthropic en 2024, envía cada chunk junto con el documento completo a un LLM barato y pide una descripción de una o dos frases de dónde se sitúa el chunk — "Este chunk discute el cambio en el cálculo de la franquicia introducido por la enmienda de 2024 a la Política 47-B" — y luego la antepone al texto del chunk antes de embeber. El chunk se vuelve encontrable para consultas que el texto subyacente nunca nombró. Las ganancias reportadas rondan una reducción del 49% en los fallos de recuperación en la evaluación de Anthropic, más con búsqueda híbrida y reranking encima. El truco que la hace económica es el caché de prompt: envía el documento una vez, procesa cada chunk contra la versión cacheada.

El late chunking, introducido por Jina AI en 2024, ataca el mismo problema desde el otro lado. El documento entero pasa por un modelo de embedding de contexto largo en una sola pasada, produciendo embeddings a nivel de token ya contextualizados sobre todo el documento. Sólo entonces se trocea el documento, y el embedding de cada chunk se calcula por pooling sobre sus tokens ahora contextualizados. Sin llamadas extra al LLM; los embeddings heredan el contexto a nivel de documento implícitamente. La restricción es que el modelo de embedding tiene que soportarlo de forma nativa (jina-embeddings-v3/v4 y algunos modelos de investigación lo hacen) y el documento tiene que caber en la ventana del modelo. Para documentos que caben, el late chunking iguala a la recuperación contextual con una fracción del coste de indexación. Para documentos que no, la recuperación contextual es más general. Las dos no se excluyen mutuamente, y los sistemas serios en producción suelen correr ambas con un paso de deduplicación encima.

Lo que prepara el Capítulo 3

El chunking convierte un documento parseado en una población de unidades recuperables. Cada unidad necesita un sitio donde vivir — almacenada, indexada, consultada con baja latencia, actualizada cuando el corpus cambia. Ese sitio es la base de datos vectorial, y la elección de la base de datos vectorial es un tipo distinto de decisión que la del chunking. El chunking es un problema de software con costes de software. La elección de base de datos es un problema de software con consecuencias de infraestructura, operativas y regulatorias, y la elección equivocada puede llevar seis meses deshacer.

Próximamente — Capítulo 4: Elegir la base de datos vectorial correcta. Arquitecturas dedicadas frente a extensiones, los líderes gestionados, el campo open-source y los tres ejes — residencia, operación y coste total — que normalmente deciden la elección real.