Definición
El chunking es partir los documentos en fragmentos antes de indexarlos para una búsqueda semántica. Es el paso menos vistoso de un RAG y el que más determina si funciona o no.
La razón por la que hay que trocear son dos límites. Uno técnico: un modelo de embeddings tiene un máximo de entrada, y un manual de 200 páginas no cabe. Otro de calidad, más importante: un vector que resume 200 páginas no significa nada. Al comprimir un documento entero en un único punto, se pierde todo lo específico. La búsqueda deja de encontrar.
Un buen chunk es un trozo que responde a algo por sí solo. Ese es el criterio, y todo lo demás son detalles de implementación.
Estrategias, de peor a mejor
Por número fijo de caracteres. Cortar cada 1.000 caracteres. Es lo que hace todo el mundo el primer día y funciona regular: parte frases por la mitad y separa una pregunta de su respuesta.
Por número de tokens con solapamiento. Igual, pero contando tokens y repitiendo los últimos 50-100 al principio del siguiente chunk. Ese solapamiento evita que una idea que cae justo en el corte se pierda. Es el mínimo aceptable.
Recursiva por separadores. Intenta cortar primero por doble salto de línea, si no cabe por salto simple, si no por punto, si no por espacio. Respeta párrafos y frases. Es el estándar sensato hoy.
Por estructura del documento. Aprovechar los encabezados del Markdown o del HTML, los artículos de un contrato, las filas de una tabla. Cada sección es un chunk. Da los mejores resultados cuando el documento tiene estructura de verdad.
Semántica. Cortar donde el tema cambia, detectándolo por la distancia entre embeddings de frases consecutivas. Es lo más caro de calcular y no siempre gana a la estructura.
Ejemplo práctico
En el CRM de IMDICA indexamos el manual de operaciones, que son procedimientos numerados: P-01 recepción, P-04 salidas, P-07 calidad...
Primer intento, corte fijo cada 1.000 caracteres. Preguntas del tipo "¿qué hago si falta material en una recepción?" devolvían fragmentos que empezaban a media frase y mezclaban el final de un procedimiento con el principio del siguiente. El modelo respondía mezclando dos procesos distintos, con toda la seguridad del mundo.
Segundo intento, corte por la estructura: cada procedimiento y cada subapartado, un chunk. Mejoró muchísimo, pero apareció otro problema. Un chunk que decía "Si hay diferencias, se anota en el parte y se avisa al comercial" recuperado suelto no dice de qué procedimiento es. El modelo no sabía si hablaba de recepción o de expedición.
Solución final, la que suele funcionar: cada chunk lleva su contexto delante. Al texto del fragmento se le antepone el título del documento y la ruta de encabezados: "Manual de operaciones › P-04 Recepción de mercancía › Diferencias". Cuesta unos pocos tokens por chunk y arregla la mitad de los fallos de recuperación.
Qué tamaño usar
No hay un número universal, pero sí un marco:
- Chunks pequeños (200-400 tokens) — Recuperación más precisa, menos ruido en el contexto. Bien para FAQ, definiciones y fichas. Riesgo: pierdes contexto alrededor.
- Chunks medianos (500-800 tokens) — El punto por defecto razonable para documentación y manuales.
- Chunks grandes (1.000-1.500 tokens) — Conservan el hilo del razonamiento. Bien para textos narrativos o legales. Riesgo: cada resultado ocupa mucha ventana de contexto y mete ruido.
Solapamiento habitual: entre el 10 % y el 20 % del tamaño del chunk.
Errores comunes
- Ignorar la estructura que el documento ya tiene. Si hay encabezados, úsalos: alguien ya hizo el trabajo de decidir dónde empieza y acaba una idea.
- Chunks sin contexto propio. Un fragmento tiene que poder leerse solo. Añádele título y sección.
- Partir tablas. Media tabla sin su cabecera es basura. Las tablas se tratan aparte.
- No guardar metadatos. Documento de origen, fecha, sección, permisos. Sin eso no puedes filtrar ni citar la fuente.
- Elegir el tamaño a ojo y no volver a tocarlo. Es un parámetro que hay que medir con evals, como cualquier otro.
- Reindexar todo cada vez que cambia un documento. Guarda un hash por chunk y reindexa solo lo que cambió.
Cuándo replantearlo
Si tu RAG responde mal, mira qué chunks recuperó antes de tocar el prompt o cambiar de modelo. En mi experiencia, la mayoría de fallos de un RAG no son del modelo generando: son del sistema recuperando el fragmento equivocado. Y eso casi siempre se arregla en el chunking o con reranking.
