Chunking III: LLM-based, late chunking y recuperación contextual

Tercera y última entrega sobre troceado, y la primera de nivel avanzado del bloque: dejar que un modelo decida los cortes, embeber el documento entero antes de trocearlo y enriquecer cada fragmento con contexto generado. Todas funcionan, ninguna es gratis, y la idea es que sepas calcular cuánto cuestan antes de adoptarlas.

El problema que todas intentan resolver

Un fragmento separado de su documento pierde todo lo que el documento le daba. «El plazo se amplía a sesenta días en ese supuesto» es una frase clara dentro de un contrato e inútil dentro de un índice vectorial: no dice qué plazo, ni cuál es el supuesto, ni de qué contrato hablamos. Su embedding representa una frase genérica sobre plazos, y por eso no aparece cuando preguntan por el plazo de resolución de ese contrato.

El fenómeno se llama pérdida de contexto por troceado y afecta sobre todo a pronombres, elipsis y a cualquier documento donde el sujeto se enuncia una vez al principio y luego se da por sabido, que es como está escrita casi toda la documentación técnica y jurídica. El troceado por estructura y el patrón padre-hijo de la entrega anterior lo mitigan; las tres técnicas de hoy lo atacan de frente.

Troceado decidido por un modelo

La idea más directa: pasarle el documento a un modelo y pedirle que marque dónde empieza y acaba cada unidad de significado, con la expectativa de que decida mejor que un contador de tokens o un umbral de similitud.

Hay dos formas de implementarlo. La agéntica, en la que el modelo devuelve directamente los fragmentos, es la más demostrada y la más problemática: puede reescribir el texto en lugar de trocearlo, inventar contenido o alterar cifras. Si se adopta, la salida debe ser índices de corte, nunca texto, comprobando que la reconstrucción coincide con el original. La segunda, más contenida y más útil, le pide una tarea acotada: dada una lista numerada de párrafos, decir en qué números hay cambio de tema. No manipula texto, sólo emite números, y el troceado lo hace el código: más barato, verificable y sin posibilidad de alucinar contenido.

Aun así el coste de indexación es alto: el corpus entero pasa por el modelo, un orden de magnitud o más por encima de lo que cuesta embeberlo, y una reindexación de minutos se convierte en una de horas. Casi nunca es la primera técnica que conviene adoptar: rinde en corpus pequeños, heterogéneos y de mucho valor por documento, y es dinero mal gastado en cientos de miles de documentos homogéneos.

Late chunking

El late chunking —troceado tardío— es la más elegante de las tres. El troceado normal corta el documento y embebe cada trozo aislado; el tardío hace lo contrario: embeber primero el documento completo con un modelo de contexto largo, y trocear después.

Para entender por qué es posible hay que recordar cómo funciona un modelo de embeddings por dentro: no produce un vector, sino uno por cada token, y al final los promedia. Esos vectores por token son contextuales: gracias a la atención, el del token «plazo» ya ha «visto» todo el documento y lleva incorporado que hablamos de un contrato de mantenimiento.

El truco consiste en no promediar todo el documento, sino quedarse con la secuencia de vectores por token y promediar después por tramos: los tokens del fragmento 1 dan su vector, y así sucesivamente. Cada fragmento tiene el suyo, calculado a partir de representaciones que vieron el documento entero.

El fragmento del ejemplo queda así representado como lo que es —una cláusula de plazo de ese contrato concreto— sin haber añadido una palabra al texto: no hay generación, ni reescritura, ni riesgo de invención. Y el coste de indexación es prácticamente el de un embedding normal, porque se pasa el mismo texto por el mismo modelo una sola vez.

Los requisitos, que son estrictos

Tres condiciones, las tres limitantes. Hace falta un modelo de embeddings de contexto largo; los de ventana corta no sirven. Hace falta acceso a los vectores por token, la salida intermedia del modelo: las APIs comerciales devuelven un único vector por texto y no la exponen, así que obliga a alojar el modelo uno mismo. Y los documentos que superan la ventana hay que partirlos en macrobloques, entre los cuales se vuelve a perder el contexto.

Aporta con documentos largos y muy autorreferenciales, y siempre que ya se autoaloje el modelo. Si dependes de una API comercial de embeddings, hoy no está disponible, y ese es el filtro que decide en la mayoría de los proyectos.

Recuperación contextual

La tercera vía es la más bruta y la más fácil: si al fragmento le falta contexto, escríbeselo delante.

El procedimiento: por cada fragmento se llama a un modelo pasándole el documento (o un resumen) y el fragmento, con una instrucción del tipo «escribe dos o tres frases que sitúen este fragmento dentro del documento». Esas frases se anteponen y el conjunto es lo que se embebe y se indexa.

El fragmento del ejemplo pasaría a algo como «Este fragmento pertenece al contrato de mantenimiento de equipos suscrito con la empresa X, apartado sobre plazos de resolución de incidencias graves. El plazo se amplía a sesenta días en ese supuesto». Ahora sí se recupera cuando alguien pregunta por los plazos de ese contrato, y además se recupera por palabra clave, porque el texto contiene los términos. Eso importa más de lo que parece: mejora la búsqueda densa y la léxica a la vez, y se lleva especialmente bien con la búsqueda híbrida que veremos en la entrega 15.

Lo que cuesta de verdad

Una llamada al generador por fragmento: un corpus de 100.000 fragmentos son 100.000 llamadas. El coste no está en la salida —dos o tres frases— sino en la entrada: si a cada llamada se le pasa el documento completo, se paga el documento tantas veces como fragmentos tenga.

Dos mitigaciones cambian el orden de magnitud. La caché de prompt de los proveedores: si el documento va al principio y sólo cambia el fragmento del final, la parte cacheada se cobra a una fracción del precio. Y no pasar el documento entero sino un resumen generado una vez por documento más el camino de títulos: pierde algo de fidelidad y baja mucho el coste.

Queda un coste que no se elimina: cada fragmento crece entre un diez y un veinte por ciento, y si se entrega con el prefijo incluido se paga ese aumento en cada consulta, para siempre. Conviene decidir si el prefijo se usa sólo para indexar —se embebe con él pero se entrega el fragmento limpio— o también para responder. Lo primero suele ser lo correcto.

Tabla de decisión

Las dos primeras filas cuestan casi nada y hay que hacerlas siempre. Las cuatro siguientes se evalúan una a una contra la línea base, con un conjunto de preguntas de referencia, y se adoptan sólo si la mejora medida justifica el coste medido.

Cuándo no compensa

Vale la pena enumerar las situaciones en que son gasto sin retorno, porque son más frecuentes que las contrarias.

• Cuando el corpus cambia a diario. Todo lo que encarece la indexación multiplica su coste por la frecuencia de reindexación: un corpus que se actualiza cada hora no puede permitirse una llamada por fragmento.
• Cuando los fragmentos ya son autocontenidos. Preguntas frecuentes, fichas de producto, artículos sueltos: no hay contexto perdido que recuperar.
• Cuando el problema real está en otro sitio. Si el sistema falla porque la ingesta destrozó las tablas, porque no hay búsqueda híbrida y las referencias alfanuméricas no se encuentran, o porque falta filtrado por metadatos, ninguna de estas técnicas lo va a arreglar.
• Cuando no hay forma de medir la mejora. Adoptar una técnica cuyo coste conoces y cuya ganancia no puedes cuantificar no se puede defender ni revertir con criterio.

Hay además un riesgo específico de la recuperación contextual y del troceado por modelo: introducen texto generado dentro del corpus. Si el resumen antepuesto contiene un error, ese error queda indexado y puede acabar en una respuesta como si fuera fuente. Usar el prefijo sólo para indexar contiene el riesgo; si se entrega al generador, hay que muestrear su calidad como la de cualquier otro contenido.

El orden sensato de adopción

Con las tres entregas sobre la mesa, el orden que evita gastar de más está claro. Primero, división recursiva con separadores adaptados al corpus y un tamaño elegido con el criterio de la entrega 09. Segundo, camino de títulos antepuesto y metadatos de sección y página, que cuestan casi nada. Tercero, patrón padre-hijo o expansión a vecinos, si la evaluación muestra respuestas incompletas con recuperación correcta. Y sólo entonces, con un problema identificado, alguna de las técnicas de hoy. Saltarse los tres primeros pasos para implementar el cuarto es el error más caro de este bloque, y se comete a menudo.

Qué viene ahora

La siguiente entrega trata de lo que más rinde por unidad de esfuerzo en todo el bloque: los metadatos. Qué guardar junto a cada fragmento, cómo se filtra antes o después de la búsqueda, cómo se extraen automáticamente y por qué un buen esquema suele mejorar el sistema más que cambiar de modelo de embeddings.

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.