Estrategias de chunking para RAG: tamaño, solapamiento y qué funciona de verdad
Trocear mal sus documentos es la causa número uno de respuestas pobres en un sistema RAG, incluso cuando el modelo de lenguaje y la base vectorial son excelentes. Aquí compara las cuatro estrategias de chunking más usadas (tamaño fijo, por frases, semántico y consciente de la estructura), entiende cómo el tamaño del chunk afecta la calidad de las respuestas y se lleva valores por defecto que funcionan bien en la práctica.
Qué es el chunking y por qué decide la calidad de sus respuestas
El chunking es el proceso de dividir un documento largo en fragmentos más pequeños (chunks) antes de indexarlos. Cada fragmento se convierte en un vector mediante embeddings y queda listo para que un sistema de búsqueda híbrida lo recupere cuando alguien hace una pregunta. Si quiere entender el recorrido completo de una pregunta, desde que se formula hasta que se genera la respuesta citando pasajes, puede repasar cómo funciona RAG paso a paso.
El chunking importa porque el modelo nunca lee el documento entero: lee únicamente los dos, tres o cinco fragmentos que el motor de búsqueda considera más relevantes para esa pregunta concreta. Si esos fragmentos están mal cortados (una frase partida por la mitad, una tabla sin su cabecera, una cláusula sin el artículo al que pertenece), la respuesta será incompleta o directamente incorrecta, por muy bueno que sea el modelo que la redacta.
Las cuatro estrategias de chunking que debe conocer
Chunking de tamaño fijo
Es el método más simple: se corta el texto cada N caracteres o N tokens, sin mirar el contenido. Es rápido de implementar y predecible en coste, pero puede partir una frase o una idea justo por la mitad, dejando dos chunks que, por separado, no significan nada. Funciona razonablemente bien para texto plano homogéneo (transcripciones, notas), pero es el que peor se comporta con documentos estructurados como contratos o manuales.
Chunking por frases y párrafos
En lugar de cortar a ciegas, se respeta la puntuación: se agrupan frases completas hasta alcanzar un tamaño objetivo, o se usa el párrafo como unidad natural. Es sencillo de aplicar, preserva el sentido de cada frase y suele dar mejores resultados que el tamaño fijo con muy poco esfuerzo adicional. Su límite aparece en documentos con párrafos muy desiguales: algunos chunks quedan minúsculos y otros demasiado largos.
Chunking semántico
Aquí se usan los propios embeddings para detectar dónde cambia realmente el tema dentro de un texto, y se corta ahí en lugar de a un tamaño fijo. El resultado son chunks de longitud variable pero coherentes: cada uno trata de una sola idea. Es la estrategia que mejor preserva el sentido en documentos densos (informes, memorias, artículos largos), pero exige más cálculo en la fase de indexación, lo que puede encarecer o ralentizar el proceso si se aplica a volúmenes grandes de documentos.
Chunking consciente de la estructura (structure-aware)
Esta estrategia usa la jerarquía real del documento (encabezados de Markdown, títulos de Word, artículos de una ley, secciones de un PDF) como puntos de corte naturales. Cada chunk corresponde a una sección o cláusula completa, con su título como contexto. Es la opción más robusta para contratos, normativa, documentación técnica y cualquier texto con una estructura clara, porque evita separar una regla de su excepción o un procedimiento de su advertencia de seguridad.
El solapamiento (overlap): cuánto poner y por qué
El solapamiento consiste en repetir una pequeña porción del final de un chunk al principio del siguiente. Sin solapamiento, una definición o una fórmula que caiga justo en el límite entre dos fragmentos puede perderse por completo: ni el chunk anterior ni el siguiente la contienen de forma completa. Con solapamiento, esa frontera se cubre por duplicado y el motor de búsqueda tiene más probabilidades de recuperar la información intacta.
- Un solapamiento del 10-20% del tamaño del chunk suele ser suficiente para la mayoría de documentos.
- Documentos muy densos (normativa, contratos) toleran bien un solapamiento algo mayor, cercano al 20-25%.
- Un solapamiento excesivo (más del 30%) infla el índice sin mejorar mucho la calidad, y encarece cada consulta porque hay más texto que procesar.
- El solapamiento no sustituye a un buen punto de corte: primero se elige dónde cortar (frase, sección), y después se añade el margen de solapamiento.
Cómo el tamaño del chunk afecta la calidad de las respuestas
No existe un tamaño universal, pero el efecto del tamaño es predecible: chunks pequeños ganan precisión en la búsqueda pero pierden contexto; chunks grandes ganan contexto pero pierden precisión y diluyen la relevancia. La tabla siguiente resume el compromiso.
Efecto del tamaño de chunk en la calidad de las respuestas
| Tamaño de chunk | Ventaja principal | Riesgo típico |
|---|---|---|
| Pequeño (100-200 tokens) | Alta precisión en la búsqueda, poco ruido por chunk | Contexto insuficiente, respuestas fragmentadas o incompletas |
| Medio (300-500 tokens) | Buen equilibrio entre precisión y contexto para la mayoría de preguntas | Ninguno destacable; es el punto de partida razonable en la mayoría de casos |
| Grande (800-1500 tokens) | Mucho contexto disponible en un solo fragmento | Relevancia diluida, mayor coste por consulta, riesgo de mezclar temas distintos |
Pruebe antes de fijar el tamaño definitivo
Elija un tamaño de partida, indexe un conjunto representativo de documentos y lance 15-20 preguntas reales que sus usuarios harían. Revise los pasajes citados en cada respuesta: si faltan datos o aparecen fragmentos irrelevantes, es la señal más fiable de que el tamaño o el solapamiento necesitan ajuste. Puede apoyarse en la guía para verificar una respuesta de IA con sus fuentes.
Valores por defecto según el tipo de documento
Si necesita un punto de partida sin pasar semanas probando combinaciones, estos valores orientativos funcionan bien en la mayoría de casos reales.
Tamaños de chunk por defecto según tipo de documento
| Tipo de documento | Estrategia recomendada | Tamaño orientativo |
|---|---|---|
| Contratos y normativa (RGPD, PRL) | Consciente de la estructura, por artículo o cláusula | 200-400 tokens por cláusula, overlap 20% |
| Manuales técnicos y documentación de producto | Consciente de la estructura, por sección o encabezado | 300-600 tokens, overlap 15% |
| FAQs y bases de conocimiento internas | Por frases o párrafos | 150-300 tokens, overlap 10% |
| Informes largos y memorias (financieros, CSRD) | Semántico o por estructura con overlap generoso | 400-700 tokens, overlap 20% |
| Emails y conversaciones | Por mensaje o hilo completo | Variable: un mensaje o turno equivale a un chunk |
Si gestiona documentos muy variados (contratos, manuales, FAQs) dentro de una misma base, lo más práctico no es elegir una única estrategia para todo, sino dejar que el sistema de indexación aplique la lógica adecuada según el formato de cada archivo. Es lo que hace Kopik al subir PDF, Word, texto o Markdown a una base de conocimiento: extrae, trocea e indexa para búsqueda híbrida (texto completo más expansión semántica) sin que tenga que decidir manualmente el tamaño de chunk de cada documento.
Errores habituales al trocear documentos
- Usar siempre el mismo tamaño de chunk para todos los documentos, sin tener en cuenta si son contratos, manuales o FAQs.
- No añadir solapamiento, lo que corta definiciones, fórmulas o tablas justo en el límite entre dos fragmentos.
- Trocear tablas por filas sueltas sin repetir la cabecera de columnas en cada chunk, lo que destruye su significado.
- Ignorar los encabezados y la jerarquía del documento al dividir PDFs largos, perdiendo el contexto de a qué sección pertenece cada fragmento.
- Elegir chunks enormes «por si acaso», lo que diluye la relevancia de la búsqueda y encarece cada consulta al enviar más tokens de los necesarios al modelo.
- No medir: poner en producción un chunking sin probarlo antes con preguntas reales ni revisar los pasajes citados en las respuestas.
El coste también entra en la ecuación: cuantos más chunks (y más grandes) se recuperan para responder una pregunta, más tokens se envían al modelo, y eso se refleja en el precio por consulta. Si quiere entender qué está pagando realmente en una base de datos vectorial o en un servicio de RAG, conviene repasar el precio de una base de datos vectorial antes de dimensionar sus chunks al alza sistemáticamente.
Un chunking cuidado también reduce el riesgo de que el modelo invente datos: cuando los fragmentos recuperados son coherentes y completos, hay menos necesidad de que el sistema «rellene huecos» con información no verificada. Puede profundizar en este mecanismo en el artículo sobre cómo reducir las alucinaciones de la IA.
Pruebe su propio chunking sin escribir código
Suba sus PDF, Word o Markdown a una base de conocimiento y compruebe cómo queda indexado el contenido antes de integrarlo por API o MCP en su flujo de trabajo.
Preguntas frecuentes
Preguntas frecuentes
¿Cuál es el mejor tamaño de chunk para RAG?
No hay un valor único válido para todos los casos. Un punto de partida razonable es 300-500 tokens con un solapamiento del 10-20%, ajustando hacia arriba o hacia abajo según si sus documentos son densos y estructurados (contratos, normativa) o más conversacionales (FAQs, emails). La única forma fiable de confirmarlo es probar con preguntas reales y revisar los pasajes citados en las respuestas.
¿Qué es el chunking semántico y merece la pena aplicarlo?
El chunking semántico usa embeddings para detectar cambios de tema dentro de un texto y corta ahí, en lugar de a un tamaño fijo. Da chunks más coherentes y mejora la calidad de las respuestas en documentos densos, pero exige más cálculo durante la indexación. Merece la pena en informes largos o memorias técnicas; para FAQs cortas o emails, el chunking por frases suele bastar.
¿Cuánto solapamiento debo usar entre chunks?
Entre el 10% y el 20% del tamaño del chunk cubre la mayoría de casos. Documentos muy densos, como contratos o normativa, toleran bien un solapamiento algo mayor, cercano al 20-25%, para evitar que una cláusula quede partida entre dos fragmentos. Más del 30% suele encarecer la indexación sin aportar mejoras apreciables.
¿El tamaño de chunk afecta al coste de las consultas?
Sí. Cuantos más chunks (y más grandes) se recuperan para responder a una pregunta, más tokens se envían al modelo de lenguaje, y eso se refleja en el coste por consulta. Chunks demasiado grandes «por si acaso» no solo diluyen la relevancia de la búsqueda, también encarecen cada pregunta de forma innecesaria.
¿Cómo sé si mi estrategia de chunking está funcionando bien?
Lance 15-20 preguntas representativas de lo que preguntarían sus usuarios reales y revise los pasajes citados en cada respuesta. Si faltan datos, si aparecen fragmentos irrelevantes o si la respuesta mezcla información de secciones distintas sin relación, es señal de que el tamaño de chunk, el solapamiento o el punto de corte necesitan ajuste.
¿Debo trocear igual un PDF escaneado que un documento en Markdown?
No. Un documento en Markdown o HTML tiene encabezados explícitos, así que el chunking consciente de la estructura es casi siempre la mejor opción. Un PDF escaneado necesita primero un buen reconocimiento de texto (OCR) antes de poder aplicar cualquier estrategia de chunking fiable, ya que sin texto limpio ninguna división tendrá sentido.
Reciba la newsletter de Kopik
Nuevas bases de conocimiento, guías sobre RAG y novedades del producto. Un correo cada una o dos semanas, baja con un clic.
Al suscribirse, acepta recibir nuestra newsletter. Nunca compartimos su dirección.