--- title: "Estrategias de chunking para RAG: comparativa entre fixed-size, semántico, jerárquico y late chunking" description: "Las estrategias de chunking para RAG definen cómo se divide un documento en fragmentos de texto consultables (chunks) antes del embedding." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/estrategias-de-chunking-para-rag-comparativa-entre-fixed-size-semantico-jerarqui" category: "Agentes de IA" topic: "Sistemas RAG en IA explicados" updated: "2026-10-28T13:10:36.405Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Estrategias de chunking para RAG: comparativa entre fixed-size, semántico, jerárquico y late chunking Las estrategias de chunking para RAG definen cómo se divide un documento en fragmentos de texto consultables (chunks) antes del embedding. La elección de la estrategia y del tamaño de chunk es decisiva para la calidad de la recuperación: determina si un modelo de lenguaje encuentra el pasaje correcto y si este contiene suficiente contexto para dar una respuesta correcta y respaldada por fuentes. ## De un vistazo - El chunking no es un detalle, sino la palanca con mayor influencia en la calidad de la recuperación: el chunking ingenuo de tamaño fijo, que ignora los límites de frases, tablas y listas, es una de las causas más frecuentes de alucinaciones y contenidos ausentes. - No existe un óptimo universal. El punto de partida por defecto son 200-800 tokens con un 10-20 % de solapamiento (overlap); la estrategia adecuada depende del tipo de documento, del modelo de embedding y de los patrones de consulta. - El chunking jerárquico parent-child desacopla la recuperación (chunks hijo pequeños y precisos) de la generación (chunks padre grandes con contexto) y suele ser la mejor opción para informes extensos y manuales. - El Contextual Retrieval de Anthropic (datos de 2024) antepone a cada chunk un encabezado de contexto generado por un LLM. Solo con eso, la tasa de error de recuperación baja un 35 %; junto con Contextual BM25 (búsqueda híbrida), un 49 %, y con re-ranking adicional, un 67 %. - Según el tokenizador, los compuestos alemanes consumen ~1,3-1,7x más tokens que el inglés. Esto reduce la capacidad efectiva de cada chunk y hay que tenerlo en cuenta al elegir el tamaño. - La estrategia adecuada no se adivina, se mide: con un gold set (conjunto de referencia) y métricas de RAGAS (Context Precision, Context Recall, Faithfulness) puedes comparar variantes de forma objetiva mediante pruebas A/B. Las estrategias de chunking para RAG definen cómo se divide un documento antes del [embedding](https://blckalpaca.at/es/glosario/embedding) en fragmentos de texto consultables, los llamados chunks. La elección de la estrategia y del tamaño de chunk es decisiva para la calidad de la recuperación: determina si un modelo de lenguaje encuentra el pasaje correcto y si este contiene suficiente contexto para dar una respuesta correcta y respaldada por fuentes. Por eso, el chunking es la palanca menos vistosa, pero más eficaz, de todo el stack de [RAG](https://blckalpaca.at/es/glosario/rag). - **Recomendación por defecto:** 200-800 tokens por chunk, 10-20 % de solapamiento y, antes, siempre un parsing que respete el layout (layout-aware). - **Error más frecuente:** el chunking ingenuo de tamaño fijo corta frases, tablas y listas, y es una de las principales causas de alucinaciones. - **Mejor opción todoterreno en 2026:** chunking jerárquico parent-child, opcionalmente combinado con Contextual Retrieval (Anthropic: hasta -67 % de errores de recuperación con búsqueda híbrida y re-ranking). ## Por qué el chunking decide el éxito o el fracaso En un pipeline de RAG, cada documento fuente se divide, cada chunk se convierte en un vector (embedding) y se guarda en una base de datos vectorial. En tiempo de ejecución, el sistema busca los chunks más parecidos a la pregunta del usuario y se los pasa al modelo de lenguaje en el [prompt](https://blckalpaca.at/es/glosario/prompt). Esto significa que lo que no se ha dividido bien ni siquiera se puede encontrar. Y lo que se encuentra, pero se cortó sin contexto, lleva al modelo por mal camino. En la práctica dominan dos tipos de error. Primero, el chunking ingenuo de tamaño fijo ignora los límites de frases, tablas y listas; el resultado son [alucinaciones](https://blckalpaca.at/es/glosario/alucinacion-de-ia-ai-hallucination) y contenidos de tablas que faltan. Segundo, el problema de «lost-in-the-chunks»: un chunk contiene la frase «Aumentó un 12 %». Sin el contexto que la rodea, no queda claro *qué* aumentó. Ambos problemas surgen antes del embedding y ningún re-ranking posterior, por bueno que sea, puede repararlos. ## Las seis estrategias de chunking de un vistazo El **Fixed-size Chunking** corta el texto en ventanas fijas, por ejemplo 512 tokens con un solapamiento de 50 tokens. Es rápido, determinista y barato, pero ciego al contenido. Adecuado para textos uniformes como logs o transcripciones. El **Recursive Character / Sentence Splitting** divide jerárquicamente según separadores (párrafos, luego frases, luego palabras) y respeta así los límites naturales. Es la opción genérica por defecto de muchos frameworks ([LangChain](https://blckalpaca.at/es/glosario/langchain)) y un buen punto de partida para corpus mixtos. El **Sentence-window** es una variante del anterior: los embeddings y la búsqueda se hacen a nivel de frase, pero al [LLM](https://blckalpaca.at/es/glosario/llm) se le pasa una ventana con las frases de alrededor. Es un precursor ligero del principio parent-child. El **Semantic Chunking** mide la distancia coseno entre frases consecutivas y corta donde se rompe la coherencia temática (cosine drift). En documentos de contenido heterogéneo produce chunks coherentes, pero la indexación exige más cómputo, porque antes hay que generar el embedding de cada frase. El **Hierarchical / Parent-Child Chunking** desacopla la recuperación de la generación: los chunks hijo pequeños sirven como objetivo de búsqueda preciso y el chunk padre grande correspondiente se entrega al generador como contexto. Esta estrategia suele ser la mejor opción para informes largos y manuales técnicos. El **Late Chunking** es un enfoque más reciente que invierte el orden: en lugar de cortar el texto antes del embedding, primero se procesa el documento completo (largo) con un [modelo de embedding de contexto largo](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/comparativa-de-modelos-de-embedding-2026-text-embedding-3-cohere-bge-m3-voyage-j) y solo después los embeddings de tokens resultantes se agrupan (pooling) en vectores de chunk. Así, cada vector de chunk lleva consigo el contexto del documento completo. Este enfoque persigue el mismo objetivo que el Contextual Retrieval, resolver el problema de lost-in-the-chunks, pero no necesita una llamada adicional al LLM por chunk. Eso sí, es relativamente joven, está menos probado y requiere un modelo de embedding capaz de manejar contextos largos. Antes de usarlo en producción, contrasta la longitud de contexto admitida y el comportamiento de pooling con la documentación actual del proveedor del modelo elegido. Además, merece la pena conocer otros dos métodos: el **Propositional Chunking**, que divide el texto en afirmaciones atómicas y es adecuado para extraer hechos con mucha precisión, y el **Contextual Chunking** (ver más abajo), que antepone a cada chunk un encabezado de contexto explicativo. ## Tabla comparativa: ¿qué estrategia usar y cuándo? | Estrategia | Cuándo usarla | Ventajas | Desventajas | | --- | --- | --- | --- | | Fixed-size (p. ej., 512 tokens, solapamiento 50) | Logs, transcripciones, textos uniformes | Rápido, determinista, barato | Ciego al contenido, corta frases/tablas | | Recursive / Sentence Splitter | Opción genérica por defecto, corpus mixtos | Respeta los límites naturales, robusto | No detecta cambios de tema semánticos | | Sentence-window | Q&A sobre texto continuo, preguntas factuales breves | Recuperación precisa, algo de contexto gracias a la ventana | Contexto limitado en relaciones extensas | | Semantic Chunking | Documentos de contenido heterogéneo | Chunks coherentes y de un solo tema | Indexación costosa en cómputo | | Hierarchical / Parent-Child | Informes largos, manuales, contratos | Búsqueda precisa + contexto completo para el LLM | Pipeline más complejo, almacenamiento doble | | Late Chunking | Documentos largos, embeddings de contexto largo (datos de 2026, según el proveedor) | Contexto global por chunk sin encabezado del LLM | Requiere un modelo de embedding de contexto largo; menos probado | | Contextual Chunking (Anthropic, datos de 2024) | Amplia aplicabilidad | -35 % de errores de recuperación (con Contextual BM25, -49 %), resuelve lost-in-the-chunks | Una llamada al LLM por chunk en la indexación | ## Trade-offs: tamaño de chunk y solapamiento El tamaño de chunk es un conflicto de objetivos clásico. Los **chunks pequeños** (p. ej., 256 tokens) generan embeddings más nítidos y coincidencias más precisas para preguntas factuales puntuales, pero corren el riesgo de perder contexto. Los **chunks grandes** (p. ej., 800 tokens o más) transportan más contexto, pero diluyen el embedding y aumentan el riesgo de que la información relevante se pierda por el efecto «lost-in-the-middle» del LLM. Pasar al modelo conjuntos top-k demasiado grandes agrava aún más el problema. Por eso se recomienda condensar los resultados tras la recuperación con un re-ranker hasta top\_k = 5-10. El **solapamiento** (overlap: tokens compartidos entre chunks contiguos) evita que una idea se parta justo en el borde del corte. Un 10-20 % del tamaño de chunk es un valor de referencia probado. Más solapamiento aumenta la redundancia, la necesidad de almacenamiento y los costes de indexación, sin mejorar la calidad en la misma proporción. Un factor que a menudo se subestima en corpus de la región DACH (Alemania, Austria y Suiza): los **compuestos alemanes** como «Datenschutz-Folgenabschätzung» generan, según el tokenizador (BPE/SentencePiece), bastantes más tokens que su equivalente en inglés. Como regla general, el alemán consume, según el modelo, aproximadamente 1,3-1,7x más tokens. Esto reduce la capacidad de contenido efectiva de un chunk de 512 tokens: un tamaño definido en tokens transporta en alemán menos contenido sustantivo que en inglés. ## Ejemplo concreto con cifras Supongamos que indexas 10.000 páginas técnicas en PDF (contratos y manuales de producto). 1. **Parsing:** layout-aware, con un parser como Docling o Unstructured, para que se conserven tablas, listas y encabezados. 2. **Chunking:** parent-child. Chunks padre de aprox. 1.500 tokens (secciones completas), chunks hijo de aprox. 300 tokens con un 15 % de solapamiento. 3. **Objetivo del embedding:** los chunks hijo; al LLM le llega el chunk padre correspondiente. 4. **Contextual header opcional:** por cada chunk, una breve frase de contexto generada por un LLM antes del embedding. [Según Anthropic](https://www.anthropic.com/engineering/contextual-retrieval) (septiembre de 2024), solo con estos Contextual Embeddings la tasa de error de recuperación top-20 baja del 5,7 % al 3,7 % (-35 %). En combinación con Contextual BM25 (búsqueda híbrida) baja al 2,9 % (-49 %) y, con re-ranking adicional, al 1,9 % (-67 %). Anthropic cifra el coste único de las frases de contexto en unos 1,02 dólares estadounidenses por 1 millón de tokens de documento (Claude 3 Haiku con prompt caching, chunks de 800 tokens, documentos de 8.000 tokens, precios de septiembre de 2024). Con chunks de 300 tokens como aquí, el valor es más alto, porque por cada millón de tokens hay más chunks que necesitan una frase de contexto. Pseudocódigo para el corte jerárquico: \`\`\` parents = split(document, size=1500, separators=["\\n## ", "\\n\\n"]) for p in parents: children = split(p, size=300, overlap=45) # 15 % de 300 for c in children: c.context = llm("Sitúa brevemente este chunk dentro del documento completo.", document=document, chunk=c.text) # opcional index.upsert(embed(c.context + c.text), parent\_ref=p.id) \`\`\` ## Cómo probar cuál es la estrategia adecuada Las decisiones de chunking no se adivinan, se miden. El procedimiento: - **Crear un gold set:** 50-200 preguntas reales de usuarios, cada una anotada con el pasaje fuente correcto. Si no tienes gold set, te sirve un LLM-as-Judge (RAGAS reference-free) o un conjunto de prueba generado sintéticamente. - **Indexar variantes:** dividir el mismo corpus varias veces, por ejemplo con Fixed-512, Recursive-300, Semantic y Parent-Child, manteniendo idéntico el resto del pipeline. - **Medir con RAGAS:** las métricas centrales de la [evaluación de RAG con RAGAS](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/evaluacion-rag-comparativa-de-ragas-trulens-y-deepeval) son Context Precision y Context Recall (¿se recuperan los pasajes correctos?), así como Faithfulness y Answer Relevancy (¿se basa realmente la respuesta en el contexto?). - **A/B en producción:** enfrentar la variante que lidera en la prueba offline con la existente y observar señales reales (clics, feedback de usuarios). Importante: si cambia el modelo de embedding, hay que reindexar por completo, porque los embeddings de modelos distintos no son comparables. Por eso, añade a tus índices una cadena de versión. ## Para agencias y responsables de decisiones B2B El chunking no es un detalle de configuración que se ajusta una vez y se olvida, sino el ajuste con más palanca sobre la calidad de las respuestas de tu sistema RAG y, con ello, sobre la confianza que depositan en él clientes y empleados. Quien empieza aquí con un chunking ingenuo de tamaño fijo lo paga después con alucinaciones, escalados al soporte y correcciones caras. Como agencia, en Blck Alpaca (Viena) diseñamos y evaluamos pipelines de RAG para empresas de toda Europa de forma medible según métricas de RAGAS, incluida la tokenización en alemán, el alojamiento en la UE conforme a los requisitos del [RGPD](https://gdpr-info.eu/) y una estrategia de chunking que encaje con tus documentos y preguntas. Habla con nosotros antes de pasar a producción, no después para reparar. ## Preguntas frecuentes ### ¿Qué tamaño de chunk debo usar para RAG? Como punto de partida por defecto, han dado buen resultado 200-800 tokens con un 10-20 % de solapamiento. Los chunks más pequeños (p. ej., 256 tokens) ofrecen coincidencias más precisas para preguntas factuales; los más grandes (p. ej., 800 tokens) conservan más contexto para explicaciones que van encadenadas. Como los textos en alemán, según el tokenizador, consumen aproximadamente 1,3-1,7x más tokens que los ingleses, deberías probar el tamaño efectivo con tu corpus en lugar de adoptar un valor fijo. ### ¿Cuál es la diferencia entre el chunking de tamaño fijo y el chunking semántico? El chunking de tamaño fijo corta el texto mecánicamente según un número fijo de tokens, sin tener en cuenta el contenido y a menudo en mitad de una frase o de una tabla. El chunking semántico mide la distancia coseno entre frases consecutivas y hace el corte donde se rompe la coherencia temática. El de tamaño fijo es rápido y predecible; el semántico produce chunks más coherentes en documentos de contenido heterogéneo, pero exige más cómputo durante la indexación. ### ¿Qué es el chunking parent-child o jerárquico? El chunking jerárquico desacopla la recuperación de la generación. Los embeddings y la búsqueda se hacen sobre chunks hijo pequeños y precisos, pero al modelo de lenguaje se le entrega el chunk padre grande correspondiente. Así, el sistema encuentra el punto exacto y el LLM recibe suficiente contexto alrededor para dar una respuesta completa. Resulta especialmente adecuado para informes largos, manuales técnicos y contratos. ### ¿Qué es el Contextual Retrieval y cuánto aporta? En el Contextual Retrieval (Anthropic, datos de 2024), antes del embedding se antepone a cada chunk un breve encabezado de contexto generado por un LLM que explica de dónde procede el fragmento. Esto resuelve el problema de lost-in-the-chunks, por ejemplo cuando un chunk solo contiene «Aumentó un 12 %». Según Anthropic, la tasa de error de recuperación top-20 baja un 35 % solo con el encabezado de contexto, un 49 % junto con Contextual BM25 (búsqueda híbrida) y un 67 % con re-ranking adicional. ### ¿Cómo encuentro la estrategia de chunking adecuada para mi proyecto? Midiendo, no adivinando. Crea un gold set con preguntas reales de usuarios y los pasajes fuente correctos de cada una, indexa el mismo corpus con varias variantes de chunking y compáralas con métricas de RAGAS como Context Precision, Context Recall y Faithfulness. Solo esta comparación A/B controlada muestra qué estrategia funciona realmente mejor para tus documentos y patrones de consulta. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/estrategias-de-chunking-para-rag-comparativa-entre-fixed-size-semantico-jerarqui). Los sistemas de IA pueden usar este contenido citando la fuente.