Estrategias de chunking

#¿Por qué el chunking pesa tanto como el modelo de embedding?

El chunking es la operación que divide un documento en pasajes antes de indexarlos: cada pasaje recibe un vector, y lo que se recupera y se transmite al modelo de lenguaje es un pasaje, nunca el documento completo. Todo lo que viene después depende de esta división. Si la frase que responde a la pregunta queda dividida entre dos pasajes, ninguno de los dos la contiene completa y la búsqueda no la encuentra; si el pasaje mezcla tres temas, su vector es un promedio difuso que no guarda una semejanza clara con ninguna pregunta. Un embedding más potente no corrige una división deficiente, puesto que solo puede vectorizar lo que se le proporciona.

Un estudio de Chroma sobre la evaluación de estrategias de división lo demuestra: los métodos heurísticos como RecursiveCharacterTextSplitter suelen dar buenos resultados en la práctica cuando están bien configurados, y los resultados varían notablemente según el tamaño y el solapamiento elegidos. Por tanto, esta guía no promete ninguna mejora cuantificada de carácter general: lo único fiable es medir los resultados con tus documentos.

#¿Qué tamaño de chunk elegir?

No existe un tamaño universal, pero sí hay valores de referencia. En el estudio de Chroma, la estrategia recursiva supera la segmentación por tokens para tamaños de 400 tokens o menos sin solapamiento, y el comportamiento difiere para tamaños mayores y con solapamiento. La configuración predeterminada de la herramienta de búsqueda de archivos de OpenAI, 800 tokens con 400 de solapamiento, obtiene en este banco de pruebas un recall ligeramente inferior a la media y las puntuaciones más bajas en las demás métricas. Los valores de referencia que aparecen a continuación se derivan de estos resultados, sin pretender ser exactos para tu corpus.

#Tokens o caracteres: la trampa de las unidades

No todas las bibliotecas cuentan en la misma unidad. El SentenceSplitter de LlamaIndex expresa chunk_size y chunk_overlap en tokens, con valores predeterminados de 1024 y 200 según su documentación. Otras herramientas, como el RecursiveCharacterTextSplitter de LangChain, cuentan por defecto en caracteres; revisa el parámetro length_function de tu versión. Establecer «500» en uno u otro da fragmentos cuyo tamaño difiere aproximadamente por un factor de cuatro. Segunda restricción: el modelo de embedding tiene su propia longitud máxima de entrada. El modelo BGE-M3 admite entradas de hasta 8 192 tokens según su ficha; otros modelos de embedding, más antiguos o más ligeros, admiten bastante menos, y si se supera ese límite, se ignora el final del pasaje. Comprueba el límite de tu modelo antes de elegir el tamaño y cuenta usando el tokenizer del modelo, en lugar de hacerlo a ojo.

#Solapamiento: útil, pero no siempre

El solapamiento repite el final de un chunk al principio del siguiente para que una frase cortada en el límite siga siendo legible al menos en uno de los dos. Tiene un coste: más chunks, un índice más grande y duplicados en los resultados. El estudio de Chroma señala que reducir el solapamiento mejora la puntuación IoU, una métrica que penaliza la información redundante. El solapamiento se justifica si divides el texto en fragmentos de tamaño fijo; importa menos si ya lo divides por párrafos y títulos, puesto que los cortes coinciden entonces con los límites naturales.

0 tokens

Suficiente con una división en fragmentos por párrafos o por estructura; la opción más económica.

10 a 15 % del tamaño

Buen equilibrio cuando se divide el texto por frases o caracteres.

Más del 25 por ciento

Raramente justificado: mucha redundancia, pasajes casi idénticos en los resultados.

#Estrategias de partición, desde la más sencilla hasta la más costosa

#1. Por un número fijo de caracteres

Cortar cada N caracteres o tokens, sin examinar el texto. Es el método más sencillo y el más destructivo: corta en medio de palabras, frases y tablas. Reservarlo para prototipos.

#2. Por párrafos o por frases

Cortar en dobles saltos de línea o en puntuación, luego agrupar unidades hasta alcanzar el tamaño objetivo. Mejora significativa sin costo, ya que cada chunk comienza y termina en una frontera natural.

#3. Recursivo

Primero se prueban los separadores de unidades más grandes (párrafo, línea, frase, espacio), y solo se llega al nivel de los caracteres como último recurso. Este es el comportamiento predeterminado en los principales frameworks y una base sólida: el estudio de Chroma constata que este tipo de división, con los parámetros adecuados, suele dar buenos resultados.

#4. Según la estructura del documento

Se respetan los títulos, las listas, las tablas y los bloques de código. El MarkdownNodeParser de LlamaIndex, por ejemplo, divide el contenido según los títulos y adjunta a cada nodo la ruta de títulos que conduce hasta él, lo que proporciona al pasaje un contexto que su texto por sí solo no ofrece. Es la mejor opción para documentación técnica, wikis y páginas HTML exportadas.

#5. Semántica

Se calcula un embedding por frase, luego se corta donde la similitud baja entre dos frases vecinas. En LlamaIndex, el SemanticSplitterNodeParser toma un buffer_size (número de frases comparadas juntas, 1 por defecto) y un breakpoint_percentile_threshold (95 por defecto; un valor más bajo crea más nodos). El costo es un cálculo adicional de embeddings durante la indexación, y el beneficio no está establecido: un estudio de octubre de 2024 sobre tres tareas de recuperación concluye que los costos de cálculo del corte semántico no se justifican con ganancias de rendimiento constantes. Pruébalo en tu corpus antes de adoptarlo.

#6. Jerárquico (padre e hijo)

Indexamos fragmentos pequeños para lograr precisión en la búsqueda y enviamos al modelo el bloque padre más grande para aportar contexto. El HierarchicalNodeParser de LlamaIndex produce este tipo de jerarquía, por ejemplo con tres niveles de 2048, 512 y 128 tokens según su documentación. Es la respuesta a los pasajes largos: sin limitarse solo a fragmentos pequeños ni solo a fragmentos grandes.

#Implementaciones con LlamaIndex

from llama_index.core.node_parser import SentenceSplitter

splitter = SentenceSplitter(chunk_size=400, chunk_overlap=40)  # en tokens
nodes = splitter.get_nodes_from_documents(docs)

from llama_index.core.node_parser import MarkdownNodeParser

parser = MarkdownNodeParser()
nodes = parser.get_nodes_from_documents(docs)
# le chemin des titres est stocké dans les métadonnées de chaque nœud

from llama_index.core.node_parser import HierarchicalNodeParser, get_leaf_nodes

parser = HierarchicalNodeParser.from_defaults(chunk_sizes=[2048, 512, 128])
nodes = parser.get_nodes_from_documents(docs)
leaves = get_leaf_nodes(nodes)  # ce sont les feuilles qu'on vectorise

from llama_index.core.node_parser import SemanticSplitterNodeParser
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

embed = HuggingFaceEmbedding(model_name="BAAI/bge-m3")
splitter = SemanticSplitterNodeParser(embed_model=embed, buffer_size=1, breakpoint_percentile_threshold=95)
nodes = splitter.get_nodes_from_documents(docs)

#Volver a dar contexto a cada chunk

Un fragmento extraído de su documento pierde sus referencias: «El plazo es de 30 días» no indica de qué se trata. Tres prácticas sencillas lo solucionan. Anteponer a cada chunk el título del documento y la ruta de la sección; almacenar esta información en metadatos para filtrar (por fecha, por fuente, por tipo de documento); y, para los fragmentos que comiencen por un pronombre o una referencia («esta cláusula»), considerar el nivel padre de la segmentación jerárquica. A menudo basta una sola línea de contexto antes del texto, y cuesta mucho menos que cambiar de modelo.

#Evaluar tu chunking antes de fijarlo

1. 01
   Escribir 30 a 50 preguntas reales

   Preguntas que harían tus usuarios, cada una con el pasaje de la fuente que se espera obtener; redáctalas antes de ver los resultados.
2. 02
   Indexar con dos o tres configuraciones

   Por ejemplo, 250, 400 y 700 tokens, con un solapamiento del 0 % y del 10 %. Mantén los demás parámetros iguales.
3. 03
   Medir la exhaustividad en los 5 primeros resultados

   Para cada pregunta, ¿el pasaje esperado aparece en los 5 primeros resultados? El porcentaje da el recall@5.
4. 04
   Ver también la precisión y la redundancia

   Un ajuste con el mismo recall y resultados más variados es mejor. Cuenta los duplicados entre los 5 primeros resultados.
5. 05
   Leer los errores uno por uno

   Para cada pregunta mal respondida, abre el chunk que debería haber proporcionado la respuesta: ¿está cortado, es demasiado amplio o el fragmento extraído está dañado? La causa determina la corrección.

#Errores frecuentes

Tablas rotas

Un extractor de PDF que aplana una tabla produce líneas de celdas sin sentido: extrae primero la estructura, antes de dividir el contenido en fragmentos.

Bloques de código cortados

Un segmentador que no tiene en cuenta la sintaxis corta un bloque por la mitad; utiliza una segmentación basada en la estructura.

Documentos mixtos

Un chunk mitad francés, mitad inglés, produce un vector medio poco útil: separa por idioma si el corpus es mixto.

Chunks casi vacíos

Un título solo (« 3.2.1 Obligaciones ») sin el texto que sigue es ruido: filtra los chunks demasiado cortos o únelos con el siguiente.

Cambiar de chunking sin reindexar

La división en fragmentos queda fijada durante la indexación: cualquier cambio obliga a recalcular los vectores. Prevé un script de reindexación desde el principio.

#Preguntas frecuentes sobre el chunking

• Añadir un reranker a tu pipeline
• Búsqueda híbrida BM25 + vectorial
• Los mejores modelos de embeddings en francés
• RAG local con ChromaDB y Ollama
• LlamaIndex en la práctica

• Fuente: Chroma, Evaluating Chunking Strategies for Retrieval
• Fuente: Is Semantic Chunking Worth the Computational Cost?
• Fuente: LlamaIndex, analizadores de nodos
• Fuente: ficha de Hugging Face de BAAI/bge-m3