Chunking II: semántico, jerárquico y por página

Segunda de las tres entregas sobre troceado. En la anterior vimos las estrategias que cortan por longitud; aquí van las que cortan por lo que dice el texto o por cómo está construido el documento, y el patrón que separa lo que se indexa de lo que se entrega al modelo. Con una advertencia por delante: todas cuestan más que la división recursiva, y no todas la superan.

Troceado semántico: cortar donde cambia el tema

La división recursiva corta por separadores tipográficos. El troceado semántico corta donde cambia el significado, y para saberlo usa el propio modelo de embeddings.

El procedimiento es directo: se parte el texto en frases, se calcula el embedding de cada una y se recorre la secuencia midiendo la similitud entre ventanas de dos o tres frases consecutivas —una frase suelta da una señal demasiado ruidosa—. Donde la similitud cae por debajo de un umbral hay una frontera semántica, y ahí se corta.

El umbral no se fija con un número absoluto, porque la escala de similitud varía mucho entre modelos y corpus. Funciona fijarlo por percentil sobre el propio documento: calcular todas las distancias entre frases consecutivas y cortar en el cinco o el diez por ciento de mayores saltos, con lo que el método se adapta solo a un texto homogéneo o variado.

El resultado son fragmentos de longitud muy desigual, cada uno con una unidad temática real. En textos donde el tema cambia sin aviso tipográfico —transcripciones, actas, informes escritos de corrido— eso mejora la recuperación de forma perceptible.

Lo que cuesta

Hay que embeber todas las frases del corpus antes de decidir el troceado y volver a embeber después los fragmentos resultantes: del orden del doble del coste de indexación normal, con bastante más latencia. Para un corpus que se reindexa a menudo, no es un detalle. Además hay que poner límites duros, porque el método puede producir un fragmento de tres frases y otro de cuatro mil tokens: en la práctica siempre se implementa con un mínimo y un máximo impuestos sobre la decisión semántica, lo que lo convierte en un híbrido.

Conviene decirlo claro: en corpus con estructura tipográfica decente aporta poco sobre una división recursiva bien configurada, porque el autor ya marcó las fronteras y son mejores que las que deduce el modelo. Brilla exactamente donde no hay marcas.

Troceado por estructura del documento

Si la ingesta conservó la jerarquía —y en la entrega 08 insistimos en que debe conservarla—, la opción más barata y más eficaz suele ser trocear por ella. En Markdown o HTML la estructura es explícita: cada encabezado abre una sección. El troceado recorre el árbol y emite un fragmento por sección, bajando de nivel sólo cuando la sección excede el máximo y agrupando secciones contiguas muy cortas. Es la lógica recursiva de la entrega anterior, pero con separadores que significan algo.

La ventaja que casi nadie aprovecha es que la jerarquía da un camino de títulos que se puede anteponer a cada fragmento. Un fragmento encabezado por «Manual de instalación > Configuración de red > Cortafuegos» se representa mucho mejor que el mismo texto sin cabecera, sobre todo cuando el cuerpo usa pronombres y elipsis: «el puerto debe abrirse» no dice nada; con el camino delante, dice bastante. Cuesta unos pocos tokens por fragmento y es de los mayores beneficios que se obtienen con tan poco trabajo.

El mismo razonamiento sirve para cualquier documento con estructura propia: un artículo en normativa, una función en código, cada par pregunta-respuesta, cada ficha de catálogo. La regla es que si el documento tiene una unidad natural de significado, esa es la unidad de troceado, y la longitud sólo interviene para partir las que se pasen de largo.

Troceado por página

Trocear por página es la estrategia más simple después del tamaño fijo, y está infravalorada por lo poco sofisticada que parece.

Tiene dos argumentos a favor. La citabilidad: si la unidad indexada es la página, la cita es «página 14 del documento X», que es lo que un humano necesita para verificarla en el original; donde alguien tiene que comprobar la respuesta contra el PDF firmado, eso vale más que un punto de precisión. Y que en muchos documentos la página es una unidad razonable: fichas técnicas, formularios, informes maquetados por asunto, presentaciones.

Sus problemas son evidentes: un párrafo se parte entre la 7 y la 8, una tabla larga se reparte entre tres páginas, y el tamaño es irregular —una página densa ronda los 700 u 800 tokens y una portada, veinte—. El apaño habitual es trocear dentro de la página cuando se excede el máximo y arrastrar la última frase de la anterior como solapamiento. En todo caso, guardar el número de página como metadato aunque el troceado no sea por página es prácticamente obligatorio: no cuesta nada y habilita citas verificables.

El patrón padre-hijo

Aquí está la idea más rentable de esta entrega, la que resuelve el conflicto de fondo del troceado: para buscar bien conviene un fragmento pequeño, porque su vector representa una idea concreta; para responder bien conviene uno grande, porque el modelo necesita contexto alrededor de la frase relevante. Los dos requisitos son incompatibles si el fragmento indexado y el entregado son el mismo objeto.

La solución es separarlos. Se trocea el documento dos veces: en bloques grandes (los padres) y, dentro de cada uno, en fragmentos pequeños (los hijos). Sólo se indexan los hijos. Cuando la búsqueda devuelve un hijo, el sistema no entrega ese hijo al modelo: entrega su padre. Se busca con precisión y se responde con contexto.

Un ejemplo con números

Manual técnico de 200 páginas, unos 100.000 tokens.

• Padres: troceado por secciones, tamaño medio 2.000 tokens. Salen unos 50 padres. No se embeben; se guardan en un almacén por clave, que puede ser la propia base de datos o cualquier almacén de documentos.
• Hijos: dentro de cada padre, troceado recursivo a 250 tokens con solapamiento mínimo. Salen unos ocho hijos por padre: 400 fragmentos indexados, cada uno con un metadato id_padre.

Llega la pregunta «¿qué puertos hay que abrir en el cortafuegos para la réplica?». La búsqueda vectorial devuelve cinco hijos. Tres pertenecen al padre «Configuración de red», uno al padre «Requisitos previos» y otro al padre «Resolución de problemas». El sistema los agrupa por padre, deduplica y recupera tres padres distintos: unos 6.000 tokens de contexto muy pertinente, en lugar de cinco fragmentos sueltos de 250 tokens (1.250 tokens) que probablemente no contendrían la tabla de puertos completa.

La deduplicación es una ventaja poco comentada: cinco resultados se convierten en tres contextos coherentes y completos, en vez de cinco recortes solapados. El coste añadido es modesto —una consulta extra al almacén de padres, del orden de milisegundos si están en la misma base de datos— y el riesgo es pasarse: si los padres son enormes y la búsqueda devuelve muchos, vuelve el efecto «perdido en el medio». Un tope duro sobre el número de padres y sobre el total de tokens de contexto es obligatorio.

Variantes del mismo patrón

La misma idea admite formas más ligeras: indexar un resumen de cada bloque y entregar el bloque completo; indexar preguntas hipotéticas generadas a partir del bloque, lo que acerca el texto indexado a la forma en que los usuarios preguntan; o indexar el fragmento pequeño y entregar sus vecinos inmediatos, sin jerarquía explícita, que consigue buena parte del beneficio con una fracción del trabajo. Esta última es la que conviene probar primero: guardar en cada fragmento la referencia al anterior y al siguiente y expandir al responder se implementa en una tarde y no toca la indexación.

Cuándo justifica cada uno su complejidad

• Por estructura: siempre que el documento tenga estructura. Es más barato que la división recursiva por longitud y da mejores resultados. No hay razón para no hacerlo.
• Por página: cuando la verificación humana contra el original es un requisito, o cuando el corpus son documentos maquetados página a página. Nunca como única estrategia en documentos de prosa continua.
• Padre-hijo: cuando las respuestas exigen contexto amplio y la evaluación muestra que el sistema recupera el fragmento correcto pero responde de forma incompleta. Ese síntoma es la señal de que toca.
• Semántico: cuando el corpus carece de estructura tipográfica y los fragmentos mezclan temas de forma visible. Es el más caro de los cuatro y el que más veces se adopta sin haber comprobado que hacía falta.

Límites y riesgos

Tres advertencias antes de complicarse.

La primera es que estas estrategias no se pueden comparar de oído. La diferencia entre un troceado bueno y uno mediocre se ve en las métricas de recuperación sobre un conjunto de preguntas con respuesta conocida, no en la impresión de leer diez respuestas. Sin ese conjunto de evaluación, cambiar de estrategia es cambiar de opinión, no mejorar el sistema.

La segunda es que cambiar el troceado obliga a reindexar todo el corpus: recalcular todos los embeddings, con su coste y su ventana de indisponibilidad. Conviene decidirlo con datos y no tres veces.

La tercera es que el troceado jerárquico introduce estado nuevo que mantener: si se actualiza un padre y sus hijos quedan apuntando a una versión anterior, el sistema devuelve contexto obsoleto sin ninguna señal de error. Ese problema, y los demás del corpus vivo, son el asunto de la entrega 13.

Qué viene ahora

La siguiente entrega cierra el troceado con el nivel avanzado: dejar que un modelo decida dónde cortar, el late chunking —embeber el documento completo con un modelo de contexto largo y agrupar después los vectores— y la recuperación contextual, que antepone a cada fragmento un resumen del documento. Todas cuestan bastante más en indexación, así que dedica el mismo espacio a cuándo no compensan.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.