Chunking: cómo los sistemas de recuperación trocean un texto

El término procede de los sistemas de recuperación, no de los buscadores. Cuando un sistema necesita responder con una cita concreta, guardar el documento entero le resulta inútil, porque tendría que devolver miles de palabras para justificar una sola frase. Por eso lo parte antes de guardarlo. Cada trozo resultante es un chunk, y ese chunk es la unidad más pequeña que el sistema puede recuperar y entregar al modelo.

Conviene separar tres cosas que suelen mezclarse. Un párrafo es una decisión de redacción tuya. Una sección HTML es una decisión de maquetación. Un chunk es una decisión del sistema que ingiere tu documento, tomada con parámetros que tú no fijas ni ves. Publicar párrafos de tres líneas no obliga a nadie a usar esos límites como frontera de fragmento.

La segunda distinción es de propiedad, y es la que ordena todo lo demás. Si montas un buscador interno o un asistente sobre tu documentación, el chunking es tuyo: eliges el método, el tamaño y el solapamiento, y respondes de la calidad del resultado. Si la pregunta es cómo aparecer en una respuesta de ChatGPT o en la búsqueda de Google, el troceado ocurre dentro de una tubería ajena y cerrada. La diferencia no es académica, porque determina qué puedes optimizar de verdad y qué solo puedes suponer.

Hay cuatro familias de método. La primera corta por longitud fija, contando tokens o caracteres, y es la más simple y la más ciega, porque la frontera cae donde cae. La segunda añade solapamiento: repite el final de un fragmento al principio del siguiente para que una frase partida siga apareciendo entera en algún sitio. La tercera corta por estructura, aprovechando encabezados, apartados o filas de tabla como frontera natural. La cuarta corta por semejanza semántica, midiendo dónde cambia el tema y partiendo justo ahí.

Los valores concretos dependen del sistema. El motor RAG de Vertex AI, de Google, arranca con 1.024 tokens por fragmento y 256 de solapamiento, pero eso es el valor por defecto de un producto y no una recomendación general. La propia documentación describe el compromiso sin resolverlo: un fragmento pequeño produce representaciones más precisas, y uno grande produce representaciones más generales que pueden perder detalles.

El fallo característico aparece cuando el contexto se queda al otro lado de la frontera. Anthropic lo ilustra con un fragmento que dice que los ingresos crecieron un 3 % respecto al trimestre anterior, sin nombrar la empresa ni el periodo. Recuperado solo, ese trozo no sirve para nada, porque no contiene ninguna de las palabras por las que alguien preguntaría. La respuesta que propusieron fue anteponer a cada fragmento una frase que lo sitúa en su documento antes de indexarlo. En su propia evaluación, eso bajó los fallos de recuperación del 5,7 % al 3,7 %; combinado con búsqueda léxica bajó al 2,9 %, y añadiendo una fase de reordenación al 1,9 %.

La decisión que cuelga de esto es presupuestaria. Si operas tu propia recuperación, el tamaño y la frontera de los fragmentos son la palanca más barata que tienes sobre la calidad de las respuestas, por delante de cambiar de modelo. Merece la pena medirla con tus documentos y tus preguntas reales antes de tocar cualquier otra cosa.

Si lo que quieres es aparecer citado en buscadores y asistentes, la respuesta honesta resulta más incómoda. Google documenta un sistema llamado passage ranking, que identifica secciones concretas de una página para valorar mejor su pertinencia, y lo presentó como una mejora aplicable al 7 % de las consultas. Documenta qué hace ese sistema. No documenta con qué fronteras trabaja, ni publica que la longitud de tus párrafos influya en ellas.

Sobre el consejo que se deriva de ahí sí existe una fuente directa, y dice justo lo contrario del consejo. Google afirma en su guía de optimización para funciones generativas que no hace falta partir el contenido en trozos diminutos para que la IA lo entienda, y que sus sistemas manejan varios temas dentro de una misma página. La partida presupuestaria de reescribir un sitio entero en micropárrafos no tiene, por tanto, respaldo documental. Lo que sí resiste el examen es más modesto y además es buena edición: que cada sección se entienda sola.

• Aclara primero de quién es el chunking. Si es tuyo, mídelo con tus datos. Si es de un tercero, trátalo como un parámetro que no controlas y desconfía de quien te venda lo contrario.
• Haz que cada sección se sostenga sola. Sujeto explícito al principio, sin «esto», «lo anterior» ni «como decíamos» cruzando un encabezado.
• Repite el nombre propio en lugar del pronombre cuando el referente quedó en otro apartado. Cuesta una palabra y salva el fragmento.
• Cierra el dato con su contexto en el mismo bloque: la cifra con su unidad, su fecha y su ámbito, no repartidas entre dos apartados.
• Usa los encabezados como frontera real y no como adorno tipográfico, para que un troceado por estructura caiga donde tú quieres que caiga.
• Si operas tu propio sistema, mide antes de copiar. Un juego de treinta preguntas reales con la respuesta correcta anotada vale más que cualquier cifra recomendada en un artículo.

• Reescribir la web en párrafos de dos líneas para «ser citado». Google dice expresamente que no hace falta trocear el contenido en piezas diminutas, así que ese esfuerzo solo se justifica si mejora la lectura.
• Copiar un tamaño de fragmento sin saber quién lo midió. Las cifras que circulan salen de experimentos concretos, con un modelo concreto y una tarea concreta, y no se trasladan sin más.
• Confundir passage ranking con chunking. Lo primero es un sistema de clasificación documentado por Google; lo segundo es un paso de preparación en sistemas de recuperación. Coinciden en la intuición y no en el mecanismo.
• Dejar el solapamiento en cero y descubrir después que las definiciones importantes caen justo en la costura entre dos fragmentos.
• Partir tablas, listas y pasos numerados por la mitad. Media tabla recuperada sin su cabecera es ruido con aspecto de dato.