Chunking es dividir una fuente en unidades recuperables. Un sistema RAG no busca «el
documento» en abstracto: indexa fragmentos y decide cuáles caben en el contexto de la
consulta. El tamaño y los límites de esos fragmentos condicionan todo el pipeline.
El equilibrio
Chunks demasiado grandes: conservan contexto, pero mezclan temas, cuestan más tokens y
devuelven ruido.
Chunks demasiado pequeños: son precisos, pero pierden definiciones, referencias y
relaciones necesarias para interpretar el fragmento.
Mucho overlap: evita cortes bruscos, pero duplica almacenamiento y puede llenar el top-k
con copias casi iguales.
No existe un número universal. Código, contratos, tickets y manuales tienen estructuras
distintas.
Estrategias
Por estructura: títulos, párrafos, listas, funciones o secciones. Suele ser el mejor
punto de partida porque respeta unidades humanas.
Por tamaño fijo: ventanas de caracteres o tokens con solapamiento. Es simple, pero puede
cortar una idea a la mitad.
Semántica: detecta cambios de tema. Puede mejorar coherencia a cambio de más cómputo y
complejidad.
Jerárquica: recupera un fragmento pequeño y entrega también su sección o documento padre.
Conserva procedencia
Cada chunk debería guardar:
ID estable del documento y del fragmento;
título, sección y posición;
URL o ruta canónica;
fecha, versión y permisos;
texto original suficiente para citar;
relación con su padre y vecinos cuando sea útil.
Sin metadata no puedes filtrar acceso, reconstruir contexto ni producir
citas confiables.
Cómo evaluarlo
Prepara preguntas reales y marca qué fragmentos contienen la respuesta. Después compara si el
chunk correcto aparece en los primeros resultados, cuánto ruido acompaña y cuántos tokens
consume. Cambiar chunking obliga a regenerar embeddings e índice y a repetir la evaluación.
[!TIP]
Empieza respetando la estructura del documento. Ajusta tamaño y overlap sólo cuando los
fallos observados indiquen qué se está cortando o mezclando.