Chunking I: tamaño fijo, solapamiento y división recursiva

Segunda entrega del bloque dedicado al corpus, y primera de tres sobre troceado. Aquí van las dos estrategias con las que empieza todo el mundo, las que resuelven la mayoría de los casos y las que hay que dominar antes de plantearse cualquiera de las sofisticadas que vienen después.

Por qué hay que trocear

Después de la ingesta tienes documentos completos en texto limpio. La pregunta razonable es por qué no indexarlos enteros. Hay tres razones, y ninguna es opcional.

La primera es técnica: los modelos de embeddings —los que convierten texto en un vector que representa su significado, como vimos en la entrega 03— tienen una ventana de entrada limitada, del orden de unos cientos de tokens en los más usados y unos pocos miles en los generosos. Lo que exceda se trunca en silencio: de un contrato de sesenta páginas se indexaría la primera.

La segunda es de representación, y es la más importante. Un embedding es un único punto en el espacio del significado. Un documento largo trata de veinte cosas distintas y su vector acaba siendo el promedio de todas: un punto en el centro que no está cerca de ninguna. La granularidad del troceado es, literalmente, la resolución con la que el sistema puede buscar.

La tercera es económica. El fragmento recuperado se pega en el prompt y se paga por token de entrada. Recuperar documentos completos multiplica la factura y degrada la respuesta, porque un contexto muy largo diluye la atención del modelo. Y hay un cuarto motivo, menos citado: la citabilidad. Si el sistema devuelve trescientas palabras con la respuesta dentro, el usuario la verifica en cinco segundos; si devuelve el PDF entero, no verifica nada.

La unidad de medida: tokens frente a caracteres

Conviene medir en tokens, porque son la unidad real con la que trabajan tanto el modelo de embeddings como el generador: el límite de la ventana está en tokens y la factura se calcula en tokens.

La conversión no es fija: depende del tokenizador y del idioma. Como orden de magnitud, en español un token viene a ser algo menos de cuatro caracteres, así que 500 tokens rondan los 1.800 o 2.000 caracteres, entre 300 y 350 palabras. Con dos advertencias: el español consume más tokens que el inglés para decir lo mismo, porque los tokenizadores están optimizados para inglés, y el texto técnico —códigos, referencias, cifras— se fragmenta mucho más, de modo que las estimaciones por caracteres se quedan cortas justo en los documentos que peor toleran el truncado. Contar con el tokenizador real del modelo cuesta poco; contar por caracteres vale para prototipar, con un margen del veinte por ciento.

Tamaño fijo con solapamiento

La estrategia más simple: recorrer el texto y cortar cada N tokens, haciendo que cada fragmento repita los últimos M tokens del anterior. Ese M es el solapamiento.

El solapamiento existe por una razón concreta: un corte ciego cae entre la afirmación y su condición. «El plazo de devolución es de treinta días» queda en un fragmento y «salvo en productos personalizados, en los que no se admite devolución» en el siguiente; recuperado el primero, la respuesta es falsa. El solapamiento hace que la frontera aparezca completa en al menos uno de los dos.

Su virtud es la previsibilidad: tamaño uniforme, coste de indexación calculable y una implementación de diez líneas. Su defecto es que ignora lo que dice el texto: corta por la mitad tablas, listas numeradas y párrafos. Sigue siendo defendible cuando el corpus es prosa homogénea sin estructura marcada —transcripciones, notas sin formato— o como línea base contra la que comparar algo más elaborado, que es más sensato que empezar por lo complejo sin saber cuánto aporta.

División recursiva por separadores

Es la estrategia por defecto razonable para casi todo, y se usa mucho más de lo que se explica. La idea: en vez de cortar por posición, cortar por los separadores naturales del texto, ordenados de mayor a menor jerarquía. Primero por dobles saltos de línea, que separan párrafos; si un trozo sigue siendo grande, por saltos simples; si aún lo es, por final de frase; después por espacios, y en el extremo por caracteres. El proceso baja de nivel sólo donde hace falta, y por eso es recursivo.

Así los cortes caen en fronteras semánticas siempre que se puede: un documento de párrafos cortos se trocea por párrafos completos, y sólo en el párrafo kilométrico se baja a frases. El resultado tiene tamaños desiguales, y eso es exactamente lo que se busca.

Pseudocódigo

funcion trocear(texto, separadores, maximo, solape):
    # separadores va de mayor a menor jerarquía,
    # p. ej. ["\n\n", "\n", ". ", " ", ""]

    si contar_tokens(texto) <= maximo:
        devolver [texto]

    si separadores está vacío:
        devolver cortar_por_tokens(texto, maximo, solape)

    sep    = separadores[0]
    resto  = separadores[1:]
    piezas = texto.dividir(sep)

    fragmentos = []
    para cada pieza en piezas:
        si contar_tokens(pieza) <= maximo:
            fragmentos.añadir(pieza)
        sino:
            # la pieza sigue siendo grande: bajar de nivel
            fragmentos.extender( trocear(pieza, resto, maximo, solape) )

    devolver fusionar(fragmentos, maximo, solape)


funcion fusionar(piezas, maximo, solape):
    # agrupa piezas contiguas mientras quepan,
    # para no dejar fragmentos ridículamente cortos
    salida  = []
    actual  = ""
    para cada pieza en piezas:
        si contar_tokens(actual + pieza) <= maximo:
            actual = actual + separador_original + pieza
        sino:
            si actual no está vacío:
                salida.añadir(actual)
            # arrancar el siguiente con la cola del anterior
            actual = cola_de(actual, solape) + pieza
    si actual no está vacío:
        salida.añadir(actual)
    devolver salida

Dos detalles que se pasan por alto. El primero es la función de fusión: sin ella, un documento de párrafos de dos líneas produce cientos de fragmentos diminutos, cada uno con su vector y ninguno con contexto suficiente. El segundo es la lista de separadores, que debe adaptarse al documento: para Markdown, anteponer los encabezados; para código, los saltos entre funciones; para transcripciones, el cambio de interlocutor. Un separador bien elegido rinde más que cualquier ajuste fino del tamaño.

Cómo elegir tamaño y solapamiento

No hay un número universal, pero sí un razonamiento que evita ir a ciegas. La pregunta que decide es: ¿cuánto texto hace falta, como mínimo, para que una respuesta típica se entienda sin nada más?

Fragmentos pequeños, de 200 a 300 tokens, dan precisión alta: el vector representa una idea concreta y la recuperación es exacta para preguntas puntuales. A cambio se pierde el contexto: el fragmento dice «este plazo no se aplicará» sin decir a qué plazo.

Fragmentos grandes, de 800 a 1.200 tokens, conservan el contexto y responden bien a preguntas sobre un procedimiento completo. A cambio, el vector se difumina y el fragmento entra en el prompt con mucho texto irrelevante alrededor de la respuesta.

Como punto de partida razonable, la horquilla de 400 a 600 tokens con un solapamiento de entre el diez y el quince por ciento funciona en una mayoría de corpus de prosa técnica en español. A partir de ahí, ajustes por tipo de documento:

• Preguntas frecuentes y fichas de producto: 150 a 300 tokens y poco o ningún solapamiento; cada unidad ya es autocontenida.
• Normativa, contratos, procedimientos: 500 a 800 tokens y solapamiento generoso, porque las condiciones y las excepciones cuelgan de la frase anterior.
• Artículos y documentación técnica: 400 a 600 tokens, troceando por encabezados cuando existan.
• Transcripciones: 800 tokens o más, porque el sentido se reparte entre turnos y una intervención suelta no dice nada.
• Código y documentación de API: por unidad sintáctica, aunque los tamaños queden desiguales.

Dos límites acotan la horquilla por arriba. La ventana del modelo de embeddings: pasarse significa truncado silencioso. Y el presupuesto de contexto del generador: si vas a entregar ocho fragmentos y quieres quedarte por debajo de unos 4.000 tokens de contexto, el tamaño medio no puede pasar de 500. El troceado se decide junto con el número de fragmentos que vas a recuperar, no aislado.

El coste de un solapamiento excesivo

El solapamiento parece gratis y no lo es. Un ejemplo con números: un corpus de 10 millones de tokens troceado a 500 sin solapamiento da 20.000 fragmentos; con un diez por ciento, unos 22.200; con un cincuenta por ciento, 40.000. El doble de vectores, el doble de coste de embedding, el doble de almacenamiento y el doble de candidatos que recorrer, para el mismo contenido.

Y hay un coste peor que el económico. Con solapamiento alto, los primeros resultados suelen ser versiones desplazadas del mismo pasaje: el sistema devuelve cinco resultados que en realidad son uno, desperdicia el presupuesto de contexto y pierde la diversidad necesaria para responder bien. Es un fallo silencioso, porque las métricas de similitud salen estupendas y la respuesta es peor.

La regla práctica: entre el diez y el veinte por ciento del tamaño, y por debajo del diez cuando el troceado ya respeta fronteras naturales, porque entonces el problema que resuelve casi no existe.

Límites de estas dos estrategias

Ambas comparten una limitación de fondo: deciden dónde cortar mirando la forma del texto, no lo que dice. Un cambio de tema en mitad de un párrafo largo pasa desapercibido, y dos párrafos sobre lo mismo acaban separados porque el contador llegó al límite entre ellos. También ignoran la estructura del documento cuando existe: si la ingesta conservó títulos y secciones, trocear por longitud desaprovecha esa información, y hay documentos en los que la sección es la unidad de significado.

Aun así, conviene resistir la tentación de saltar a lo complejo. Un troceado recursivo bien configurado, con separadores adaptados al corpus, es competitivo en la mayoría de los proyectos y cuesta una tarde. Lo sofisticado se justifica cuando se han medido las carencias de esta línea base, no antes.

Qué viene ahora

La siguiente entrega recoge esas carencias: troceado semántico, que decide los cortes por la deriva de significado entre frases; troceado por estructura del documento y por página; y el patrón padre-hijo, que indexa fragmentos pequeños y entrega el bloque grande al que pertenecen. Con criterios para saber cuándo cada uno justifica su complejidad.

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.