Estrategias de chunking para RAG: cómo dividir documentos correctamente

El chunking es la operación de dividir documentos en fragmentos más pequeños antes de generar embeddings. Parece trivial pero es el paso que más afecta a la calidad del RAG, por delante del modelo de embeddings y del vector store.

Un documento mal dividido produce embeddings que mezclan conceptos distintos o pierden el contexto necesario para responder bien. No hay reranker ni modelo potente que corrija un chunking malo.

Por qué el chunking importa tanto

El principio fundamental del RAG es que recuperas fragmentos específicos, no documentos completos. Para que el retrieval funcione, cada fragmento tiene que:

Ser suficientemente pequeño para que el embedding capture un concepto claro y específico
Ser suficientemente grande para que el fragmento tenga sentido por sí solo y tenga contexto suficiente para responder la pregunta
Respetar las fronteras semánticas del documento (párrafos, secciones, frases completas)

El chunking es el equilibrio entre estos tres requisitos.

Estrategias de chunking

1. Fixed-size chunking (por tokens o caracteres)

La estrategia más simple: divide el texto cada N tokens, con un overlap de X tokens entre fragmentos consecutivos.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,      # tokens por chunk
    chunk_overlap=64,    # overlap entre chunks
    length_function=len,
)
chunks = splitter.split_text(document)

Ventajas: Predecible, fácil de implementar, funciona para texto genérico.

Problemas: Puede cortar en mitad de frases, párrafos o incluso palabras. Si el documento tiene estructura (headers, tablas, listas), la ignora completamente.

Cuándo usar: Como punto de partida para prototipado. En producción, casi siempre se puede mejorar.

Tamaño recomendado: 256-512 tokens para Q&A factual, 512-1024 tokens para síntesis y resúmenes.

2. Recursive character splitting (recomendado como base)

Divide primero por párrafos (\n\n), luego por frases (\n), luego por espacios, respetando los separadores naturales del texto.

splitter = RecursiveCharacterTextSplitter(
    separators=["\n\n", "\n", ".", " ", ""],
    chunk_size=512,
    chunk_overlap=50,
)

Es la estrategia por defecto en LangChain y LlamaIndex porque equilibra bien simplicidad y respeto por la estructura del texto. Mejor que fixed-size para la mayoría de casos.

3. Semantic chunking

En lugar de dividir por tamaño, agrupa frases con contenido semánticamente relacionado. Dos frases que hablan del mismo concepto quedan en el mismo chunk aunque superen el tamaño objetivo.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai.embeddings import OpenAIEmbeddings

splitter = SemanticChunker(
    OpenAIEmbeddings(),
    breakpoint_threshold_type="percentile",
)
chunks = splitter.split_text(document)

Ventajas: Chunks con coherencia semántica real. Mejor calidad de embeddings.

Inconvenientes: Más lento (requiere embeddings durante el chunking), tamaño de chunks variable e impredecible, más costoso.

Cuándo usar: Documentos con temática variada donde el chunking estructural no captura bien los límites conceptuales. Documentos largos sin estructura clara.

4. Document structure-based chunking

Divide respetando la estructura del documento: secciones marcadas por headers (H1, H2, H3), listas como unidades propias, tablas como chunks completos.

from langchain.text_splitter import MarkdownHeaderTextSplitter

headers = [
    ("#", "Header 1"),
    ("##", "Header 2"),
    ("###", "Header 3"),
]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
chunks = splitter.split_text(markdown_document)
# Cada chunk incluye los headers como metadatos

Ventajas: Preserva la jerarquía del documento. Chunks con significado completo. Los metadatos de sección mejoran el filtrado.

Cuándo usar: Documentación técnica, manuales, artículos estructurados, bases de conocimiento. Cualquier documento con estructura explícita.

5. Parent-child chunking (hierarchical chunking)

Almacena dos niveles de chunks: chunks pequeños (child) para el retrieval preciso, y chunks grandes (parent) para el contexto en la generación.

Documento
  └─ Chunk padre (1000 tokens) — para contexto
       ├─ Chunk hijo (128 tokens) — para retrieval
       ├─ Chunk hijo (128 tokens)
       └─ Chunk hijo (128 tokens)

El proceso:

Indexa los chunks pequeños (hijos) para la búsqueda semántica
Cuando encuentras un chunk hijo relevante, recuperas el chunk padre completo para el contexto
El LLM recibe más contexto, el retrieval es más preciso

# LlamaIndex tiene soporte nativo para esto
from llama_index.node_parser import HierarchicalNodeParser

parser = HierarchicalNodeParser.from_defaults(
    chunk_sizes=[2048, 512, 128]  # niveles de granularidad
)

Ventajas: Combina precisión en retrieval con contexto suficiente para la generación.

Cuándo usar: Documentos largos donde los chunks pequeños pierden el contexto pero los grandes producen mucho ruido. Ideal para documentación técnica extensa.

6. Sentence window chunking

Variante del parent-child: indexa frases individuales, pero al recuperar devuelve la frase más un número configurable de frases vecinas como contexto.

Ventajas: Máxima precisión en retrieval, contexto dinámico.

Cuándo usar: Cuando la precisión es crítica y las frases son la unidad natural de información (textos legales, manuales de procedimientos).

Parámetros clave

Tamaño del chunk (chunk_size)

| Caso de uso | Tamaño recomendado | |------------|-------------------| | Q&A factual de documentos cortos | 256-512 tokens | | Soporte técnico, documentación | 512-768 tokens | | Análisis de documentos legales | 768-1024 tokens | | Síntesis y resúmenes | 1024-2048 tokens |

Regla general: Empieza con 512 tokens. Sube si el sistema dice "no hay información suficiente" en casos donde debería haberla. Baja si la respuesta mezcla conceptos distintos.

Overlap

El overlap es el número de tokens que se repiten al final de un chunk y al inicio del siguiente. Previene que información importante quede partida entre dos chunks.

Sin overlap: se pierden ideas que cruzan la frontera entre chunks
Overlap excesivo (>25%): infla el índice y añade duplicidad

Recomendación: 10-15% del tamaño del chunk. Para 512 tokens → ~50-75 tokens de overlap.

Errores frecuentes

Usar el mismo tamaño para todo: Un manual técnico de 500 páginas y un tweet no necesitan la misma estrategia. Adapta el chunking al tipo de contenido.

Ignorar la limpieza previa: Los PDFs, en particular, suelen tener headers y footers repetidos en cada página, números de página, artefactos de OCR. Limpiar el texto antes del chunking mejora mucho la calidad.

No añadir metadatos a los chunks: El chunk sin metadatos es un texto anónimo. Añadir fuente, sección, fecha, tipo de documento permite filtrar antes de la búsqueda y enriquece la respuesta.

# Ejemplo: chunk con metadatos
{
  "content": "El contrato de arrendamiento tiene una duración de 12 meses...",
  "metadata": {
    "source": "contrato_2025_01.pdf",
    "section": "Cláusula 3 — Duración",
    "page": 4,
    "doc_type": "contrato",
    "created_at": "2025-01-15"
  }
}

No revisar los chunks manualmente: Antes de indexar 10.000 documentos, revisa una muestra aleatoria de 20-30 chunks. La mayoría de problemas de chunking se detectan en 10 minutos de revisión manual.

Proceso recomendado

Limpia el texto (elimina artefactos, normaliza formato)
Elige la estrategia base según la estructura del documento
Añade metadatos durante el chunking
Revisa manualmente una muestra
Indexa y prueba con las consultas reales esperadas
Ajusta el tamaño y overlap según los resultados

Recursos relacionados:

Qué es RAG — fundamentos del pipeline completo
Checklist de RAG — 34 puntos de control antes de producción
Cómo mejorar la precisión de un sistema RAG — optimización post-chunking
Cómo elegir base de datos vectorial — el siguiente paso tras el chunking