¿Cuál es el mejor tamaño de chunk para RAG?

No hay una respuesta universal, pero un buen punto de partida son 400 a 512 tokens con un solapamiento del 10 al 20 %. Luego ajústalo a tu tipo de consulta: 128 a 256 tokens para la búsqueda precisa de hechos, y 512 a 1024 tokens para consultas analíticas o de resumen. Evalúa un par de tamaños con tus propias preguntas en lugar de fiarte de un único valor por defecto.

¿Es el chunking semántico mejor que el de tamaño fijo?

No de forma fiable. El chunking semántico agrupa frases por tema, lo que suena mejor, pero los benchmarks muestran que sus mejoras frente al chunking recursivo o de tamaño fijo son inconsistentes y a menudo no justifican el cómputo adicional de embeddings. El chunking fijo y el recursivo siguen siendo líneas base sólidas y baratas: empieza por ahí y pasa al semántico solo si tu evaluación muestra una mejora real.

¿Qué es el late chunking y cuándo debo usarlo?

El late chunking genera primero el embedding del documento completo con un modelo de embedding de contexto largo y luego agrupa los embeddings de tokens en chunks, de modo que el vector de cada chunk lleva contexto de todo el documento, no solo de su propio texto. Úsalo para documentos largos con dependencias de largo alcance, donde un pasaje solo cobra sentido con el contexto anterior.

¿De verdad mejora la precisión la recuperación contextual?

Sí, de forma medible. Anthropic informó de que anteponer a cada chunk una nota de contexto generada por un LLM redujo los fallos de recuperación en el top-20 un 35 % con embeddings contextuales, un 49 % al combinarlo con BM25 contextual, y un 67 % al añadir reranking, todo a unos 1,02 $ por millón de tokens de documento usando caché de prompts. Compensa sobre todo en corpus de alto valor donde un pasaje perdido sale caro.

¿Con qué estrategia de chunking debería empezar?

Con chunking recursivo de unos 500 tokens y un 15 % de solapamiento. Respeta los límites naturales, es barato y es una línea base sólida para la mayoría de los contenidos. Añade división sensible a la estructura para PDF y manuales, recuperación de documento padre cuando las respuestas necesiten más contexto, y recuperación contextual solo donde lo que está en juego justifique el coste adicional.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Estrategias de chunking para RAG: tamaños, solapamiento y qué funciona

El chunking fija el techo de calidad de un RAG antes incluso de que se ejecute la recuperación. Esta guía compara las seis estrategias que dominan la práctica, da cifras concretas de tamaño y solapamiento, y explica cuál encaja con cada tipo de consulta.

Por qué el chunking determina la calidad del RAG

El chunk es la unidad que tu recuperador realmente obtiene, así que los límites del chunk fijan el techo de todo lo que viene después. Si los chunks son demasiado pequeños, cada embedding carece de señal suficiente para ser encontrado de forma fiable; si son demasiado grandes, la señal del pasaje relevante se promedia y diluye el vector hasta que deja de coincidir con la consulta. Si fallas en el chunking, ningún reranker ni un modelo más grande recuperarán el recall: el pasaje correcto nunca llegó a recuperarse. Por eso el chunking, y no la elección del modelo, suele ser lo primero que hay que ajustar.

Las seis estrategias que dominan la práctica

La práctica actual se agrupa en seis enfoques:

Tamaño fijo: tramos iguales de tokens o caracteres con solapamiento. El más antiguo, barato y reproducible, y una línea base sorprendentemente sólida.
Recursivo: divide según una jerarquía de separadores (párrafo → línea → frase) para no superar un límite de tamaño respetando los límites naturales. La opción por defecto recomendada.
Semántico: agrupa frases por similitud de embedding para que cada chunk trate un solo tema. Las mejoras frente al recursivo son inconsistentes y suponen un coste adicional de cómputo de embeddings.
Sensible a la estructura: divide según la estructura del documento (encabezados, secciones, páginas, markdown). El mejor para PDF, manuales y documentos financieros.
Late chunking: primero genera el embedding del documento completo con un modelo de contexto largo y luego agrupa los embeddings de tokens en chunks, de modo que cada chunk lleva contexto global.
Recuperación contextual: antepone a cada chunk un texto de contexto generado por un LLM antes de indexarlo.

Empieza por el recursivo; recurre a los demás cuando tus documentos o tipos de consulta lo exijan.

Tamaño de chunk y solapamiento: cifras concretas

No existe un tamaño óptimo universal, pero sí buenos puntos de partida. Empieza en torno a 400–512 tokens con un solapamiento del 10–20 % (unos 50–100 tokens en un chunk de 500 tokens). Luego ajusta el tamaño al tipo de consulta: los chunks pequeños (128–256 tokens) favorecen la búsqueda precisa de hechos y palabras clave, mientras que los más grandes (512–1024 tokens) favorecen las consultas analíticas y de resumen, donde importa el hilo narrativo.

El solapamiento evita que el significado quede cortado en un límite: demasiado poco fragmenta el contexto, demasiado infla el índice y duplica recuperaciones. El benchmark de NVIDIA halló que un solapamiento de en torno al 15 % era óptimo en documentos financieros, y que el chunking a nivel de página daba la precisión más alta y consistente en corpus mixtos, con las consultas factuales alcanzando su pico entre 256–512 tokens y las analíticas por encima de 1024.

Avanzado: recuperación contextual y late chunking

Dos técnicas más recientes atacan el mismo problema: un chunk que dice "los ingresos aumentaron un 15 %" no sirve de nada si no puedes saber de qué empresa o trimestre se trata.

La recuperación contextual de Anthropic antepone a cada chunk una nota de contexto de 50–100 tokens, generada por un LLM, antes tanto del embedding como de la indexación BM25. Frente a una tasa base de fallos del 5,7 % en el top-20, los embeddings contextuales redujeron los fallos un 35 %, añadir BM25 contextual los redujo un 49 %, y añadir reranking los redujo un 67 %, todo ello a unos 1,02 $ por millón de tokens de documento con caché de prompts.

El late chunking de Jina invierte el proceso: genera el embedding del documento completo con un modelo de contexto largo (hasta ~8192 tokens) y luego agrupa los embeddings de tokens contextualizados en chunks, de modo que cada embedding de chunk ya lleva contexto entre chunks. Úsalo para documentos largos con dependencias de largo alcance.

Recuperación de documento padre y metadatos

Dos refinamientos resultan rentables casi en todos los casos. La recuperación de documento padre ("de pequeño a grande") desacopla la granularidad de la recuperación de la generación: indexa chunks hijos pequeños (≈100–500 tokens) para una coincidencia precisa, pero devuelve al modelo la sección padre más grande (≈500–2000 tokens) para que tenga el contexto circundante. Y el enriquecimiento de metadatos —adjuntar fuente, encabezado de sección, número de página y marcas de tiempo a cada chunk— mejora el filtrado, permite citas y eleva la precisión de la recuperación con independencia del tamaño del chunk.

Elegir y ajustar en osFoundry

Una guía rápida de decisión: el recursivo es la opción por defecto segura; sensible a la estructura o a nivel de página para documentos estructurados; semántico para prosa temáticamente densa; late chunking para documentos largos con un embedder de contexto largo; recuperación contextual para corpus de alto valor donde la pérdida de contexto sale cara; documento padre cuando necesitas precisión y contexto a la vez.

osFoundry trata todo esto como configuración, no como código. El chunking automático trae un valor por defecto recursivo sensato, y el pipeline RAG personalizado te permite ajustar tamaño, solapamiento y estrategia por base de conocimiento, con el reranking y la recuperación de documento padre como conmutadores de etapa del pipeline. Como las etapas son configurables, puedes hacer pruebas A/B de la configuración de chunking con tu propia distribución de consultas —factuales frente a analíticas— manteniendo fijo el resto del stack, que es exactamente el flujo de trabajo de parámetros ajustables que recomienda la investigación.

Frequently asked questions

¿Cuál es el mejor tamaño de chunk para RAG?: No hay una respuesta universal, pero un buen punto de partida son 400 a 512 tokens con un solapamiento del 10 al 20 %. Luego ajústalo a tu tipo de consulta: 128 a 256 tokens para la búsqueda precisa de hechos, y 512 a 1024 tokens para consultas analíticas o de resumen. Evalúa un par de tamaños con tus propias preguntas en lugar de fiarte de un único valor por defecto.
¿Cuánto solapamiento deben tener los chunks?: Del diez al veinte por ciento del tamaño del chunk, es decir, unos 50 a 100 tokens en un chunk de 500 tokens. El solapamiento evita que el significado quede cortado en un límite; demasiado poco fragmenta el contexto en la división, y demasiado infla el índice y provoca recuperaciones casi duplicadas. NVIDIA halló que en torno al 15 % era óptimo en documentos financieros.
¿Es el chunking semántico mejor que el de tamaño fijo?: No de forma fiable. El chunking semántico agrupa frases por tema, lo que suena mejor, pero los benchmarks muestran que sus mejoras frente al chunking recursivo o de tamaño fijo son inconsistentes y a menudo no justifican el cómputo adicional de embeddings. El chunking fijo y el recursivo siguen siendo líneas base sólidas y baratas: empieza por ahí y pasa al semántico solo si tu evaluación muestra una mejora real.
¿Qué es el late chunking y cuándo debo usarlo?: El late chunking genera primero el embedding del documento completo con un modelo de embedding de contexto largo y luego agrupa los embeddings de tokens en chunks, de modo que el vector de cada chunk lleva contexto de todo el documento, no solo de su propio texto. Úsalo para documentos largos con dependencias de largo alcance, donde un pasaje solo cobra sentido con el contexto anterior.
¿De verdad mejora la precisión la recuperación contextual?: Sí, de forma medible. Anthropic informó de que anteponer a cada chunk una nota de contexto generada por un LLM redujo los fallos de recuperación en el top-20 un 35 % con embeddings contextuales, un 49 % al combinarlo con BM25 contextual, y un 67 % al añadir reranking, todo a unos 1,02 $ por millón de tokens de documento usando caché de prompts. Compensa sobre todo en corpus de alto valor donde un pasaje perdido sale caro.
¿Qué es la recuperación de documento padre (de pequeño a grande)?: Desacopla cómo haces la coincidencia de qué devuelves. Indexas chunks hijos pequeños para una coincidencia precisa, pero cuando uno coincide entregas al modelo la sección padre más grande para que tenga el contexto circundante. Así obtienes el recall de los chunks pequeños y la coherencia de los grandes sin renunciar a ninguno.
¿Con qué estrategia de chunking debería empezar?: Con chunking recursivo de unos 500 tokens y un 15 % de solapamiento. Respeta los límites naturales, es barato y es una línea base sólida para la mayoría de los contenidos. Añade división sensible a la estructura para PDF y manuales, recuperación de documento padre cuando las respuestas necesiten más contexto, y recuperación contextual solo donde lo que está en juego justifique el coste adicional.