¿Por qué hay que trocear?
Porque un solo vector no puede representar un contrato de setenta páginas. El embedding condensa el texto en una fila de números de longitud fija: si el texto es corto, sale preciso; si es largo, lo importante se pierde en la media. Ese mecanismo lo explica a fondo el texto sobre embeddings y búsqueda vectorial desde la base.
La diferencia medida viene del estudio propio de un gran proveedor, sobre cuatro conjuntos de datos de clientes:
| Planteamiento | Recall@50 |
|---|---|
| Un vector para todo el documento | 28,2 |
| Troceado (512 tokens, 25 % de overlap) | 45,7 |
(Este es un subexperimento aparte de esa medición; las tablas de tamaño y de overlap que vienen más abajo salen de otro subexperimento, así que sus valores absolutos no son comparables con este.)
Este es el argumento más fuerte y más simple que hay: 17,5 puntos solo por trocear.
¿De qué tamaño debe ser un chunk?
La misma medición probó también los tamaños:
| Tamaño de chunk | Recall@50 |
|---|---|
| 512 tokens | 42,4 |
| 1.024 tokens | 37,5 |
| 4.096 tokens | 36,4 |
| 8.191 tokens | 34,9 |
Deterioro monótono. De 512 a 8.191 la caída es de 7,5 puntos. El motivo es sencillo: la frase relevante se diluye dentro del chunk. Si en un bloque de 8.000 tokens un solo párrafo responde a la pregunta, el vector del bloque habla sobre todo de los otros 7.800 tokens.
Pero aquí llega la reserva sin la cual esa cifra engaña. Un estudio de 2025 sobre varios conjuntos de datos encontró que no hay un óptimo universal:
| Tamaño de chunk | Cuándo es el mejor |
|---|---|
| 64–128 tokens | preguntas concretas y de dato («¿cuál es el plazo de preaviso?») |
| 512–1.024 tokens | donde hace falta más contexto («¿por qué se modificó el contrato?») |
Y el modelo de embedding también influye: en ese estudio un modelo salió ganando con chunks más grandes en documentos largos, mientras que el otro iba mejor con los más pequeños al buscar nombres e identificadores.
Así que la formulación responsable es: 512 tokens es un buen punto de partida, no una respuesta. La respuesta es la que midas con tus propias preguntas.
Chunk pequeño, mejor precision
Hay una segunda medición que mira lo mismo desde otro ángulo — y es importante, porque no mide lo mismo.
| Estrategia | Tamaño / overlap | Recall | Precision |
|---|---|---|---|
| Recursiva | 800 / 400 | 85,4 % | 1,5 % |
| Recursiva | 400 / 0 | 89,5 % | 3,6 % |
| Recursiva | 200 / 0 | 88,1 % | 7,0 % |
| Semántica por clústeres | 200 / 0 | 87,3 % | 8,0 % |
| Chunking con LLM | — | 91,9 % | 3,9 % |
El recall mide si has encontrado la respuesta. La precision, cuánto texto inútil te has traído al lado.
Entre el recall del ajuste 800/400 y el del 200/0 hay apenas tres puntos — pero la precision se diferencia en cuatro veces y media. Es decir: con chunks grandes encuentras la respuesta igual de a menudo, solo que pones cuatro veces más ruido delante del modelo. Y el ruido no es neutro: empeora la respuesta y lo pagas en tokens.
Dos reservas que hay que decir en voz alta. Una: la dispersión de esta medición es enorme, entre ±25 y ±37 puntos — o sea, unos pocos puntos de diferencia entre medias no dicen gran cosa por sí solos. La otra: la medición la hizo una empresa que vende una vector database, eso sí, con metodología abierta y código abierto.
Sobre el overlap, tres fuentes dicen tres cosas
Este es el punto en el que la mayoría de las guías suenan más seguras de lo que justifica la evidencia. Esto es lo que dicen:
- La medición de un gran proveedor: el overlap del 25 % aportó +3 puntos de recall frente al corte en seco.
- El estudio de chunking anterior: el overlap empeoró la precision — más tokens redundantes.
- Un preprint de 2026: el overlap encarece la indexación sin mejora medible de calidad.
El resumen honesto: el overlap aporta poco y seguro que cuesta algo. Si tus documentos son párrafos cortos e independientes, probablemente puedas prescindir de él. Si es texto continuo, donde una idea puede cruzar el límite, mantenlo — pero con un 10-25 % sobra.
El límite por donde cortas
De la misma medición, y esta es la mejora más barata de todas:
| Estrategia | Recall@50 |
|---|---|
| Corta en el límite de token | 40,9 |
| Respeta el límite de frase | 42,4 |
| 10 % de overlap | 43,1 |
| 25 % de overlap | 43,9 |
Respetar el límite de frase vale punto y medio, gratis. Una frase cortada por la mitad deja dos fragmentos sin sentido, y los dos reciben un vector malo.
La configuración de fábrica no sirve
Esta es la conclusión más práctica del artículo, porque la mayoría de los sistemas RAG funcionan con los ajustes de fábrica.
| Herramienta | Chunk / overlap de fábrica |
|---|---|
| Un framework muy extendido | 4.000 caracteres / 200 |
| Otro | 1.024 tokens / 20 |
| La función de asistente de un gran proveedor | 800 tokens / 400 |
De esta última, la medición independiente dice literalmente que da «recall por debajo de la media y la peor puntuación en todas las demás métricas».
Ninguno de los valores de fábrica se acerca a lo que sugieren las mediciones. Esta es la media hora de trabajo que más rinde en un proyecto RAG.
Tablas, listas, código, PDF
Aquí está el trabajo de verdad, y aquí es donde mejor se amortiza.
La mejor medición al respecto se hizo sobre 80 informes financieros difíciles — de 4 a 549 páginas, 147 de media, 11.787 páginas en total. La comparación fue entre el chunking de tamaño fijo y el chunking según la estructura del documento, donde el sistema reconoce títulos, párrafos, ítems de lista y tablas:
| Estrategia | Precisión a nivel de página |
|---|---|
| Fijo de 128 tokens | 72,3 % |
| Fijo de 256 tokens | 73,1 % |
| Fijo de 512 tokens | 68,1 % |
| Según estructura | 84,4 % |
Once o doce puntos más, incluso frente al mejor tamaño fijo — y la precisión de las respuestas también subió del 48,2 % al 51,8-53,2 %.
Y la cifra secundaria más importante: todo eso con casi la mitad de chunks — 62.529 frente a 112.155. O sea, casi la mitad de almacenamiento, casi la mitad de coste de embedding, menos ruido. Aquí es donde el trabajo invertido en el chunking se amortiza de forma medible.
Cuatro reglas concretas para los detalles, de documentación primaria:
1. TABLAS: REPITE LA CABECERA EN CADA CHUNK
Si cortas una tabla de 200 filas en cuatro
chunks y la cabecera solo está en el primero,
los chunks 2-4 son columnas sin significado.
Las buenas herramientas ya lo hacen de serie.
2. NO UNAS UNA TABLA CON OTRO TEXTO
Es una unidad aparte. Si no cabe, divídela
como tabla, no como texto.
3. LISTAS: DECIDE SI SON UNA SOLA UNIDAD
Las herramientas hacen lo CONTRARIO entre sí:
una mantiene la lista junta, la otra la parte.
Mira con cuál estás trabajando.
4. CÓDIGO: CORTA POR LÍNEAS, NO POR CARACTERES
Una línea de código es una unidad; el carácter
400 no. Hay divisores conscientes de sintaxis.
La primera regla es el fallo silencioso más frecuente. El embedding de un trozo de tabla sin cabecera codifica ruido, en la práctica, y la búsqueda no lo va a encontrar nunca.
Si el chunk pierde su contexto
Hay una técnica que resuelve justo ese problema: delante de cada chunk se coloca una frase corta, generada, sobre dónde se sitúa en el documento — antes de hacer el embedding. «Este fragmento procede del capítulo del informe anual de 2024 sobre los ingresos del tercer trimestre.»
El resultado de la medición del fabricante (tasa de fallo del retrieval, sobre los 20 mejores resultados):
| Ajuste | Tasa de fallo | Mejora |
|---|---|---|
| Base | 5,7 % | — |
| + frase de contexto delante del chunk | 3,7 % | −35 % |
| + búsqueda por palabras clave también | 2,9 % | −49 % |
| + re-ranking | 1,9 % | −67 % |
El coste, según los datos del propio fabricante: 1,02 dólares por millón de tokens de documento, una partida única, con caché.
(Medición de fabricante, con su propio modelo. El método, en cambio, es reproducible con cualquier modelo y su lógica se puede comprobar.)
Fíjate, eso sí, en que el paso individual mayor fue aquí la frase de contexto — del 5,7 al 3,7 — y en que el re-ranking se llevó un tercio de los fallos que quedaban. Eso lo desarrolla el artículo sobre hybrid search con sus mediciones.
La guía práctica
1. MIRA LA CONFIGURACIÓN DE FÁBRICA
Es el primer paso, y el que más aporta.
Si pone 800, 1024 o 4000, cámbialo.
2. EMPIEZA EN 512 TOKENS, EN LÍMITE DE FRASE
Buen punto de partida. No es la respuesta.
3. OVERLAP DEL 10-25 %, O NINGUNO
Mantenlo en texto continuo, quítalo en
párrafos independientes. Más no.
4. USA LA ESTRUCTURA, NO EL NÚMERO DE CARACTERES
Título, párrafo, ítem, tabla. En la medición:
+12 puntos, con CASI LA MITAD de chunks.
5. EN LAS TABLAS, REPITE LA CABECERA
En cada chunk. Esto no es opcional.
6. METE EL TÍTULO DEL DOCUMENTO EN CADA CHUNK
El contexto más barato que puedes dar.
7. MIDE DOS COSAS POR SEPARADO
Si lo encontró (recall) Y cuánto ruido trajo
al lado (precision). No es la misma pregunta.
8. PRUEBA CON TUS PROPIAS PREGUNTAS
No hay óptimo universal. Veinte preguntas
reales dicen más que cualquier blog.
El séptimo punto es el que más gente se salta. Si solo mides si lo encontró, los chunks grandes van a parecer buenos — mientras ponen cuatro veces más ruido delante del modelo.
Malentendidos habituales
- «Hay un tamaño de chunk óptimo.» No lo hay. Según la medición, 64–128 tokens en preguntas de dato y 512–1.024 en las que piden contexto — y el modelo de embedding también influye.
- «El chunk más grande da más contexto, así que es mejor.» El recall empeora de forma monótona con el tamaño: 42,4 en 512 y 34,9 en 8.191. La parte relevante se diluye.
- «Más overlap, resultado más seguro.» Tres mediciones dicen tres cosas. El resumen honesto: aporta poco y seguro que cuesta algo.
- «El chunking semántico siempre es mejor.» Con datos reales, el chunking de tamaño fijo suele ser igual de bueno o mejor — y mucho más barato.
- «Ya lo arreglará un modelo de embedding mejor.» Una medición de 2026 encontró que los modelos más grandes puntúan más alto, pero son igual de sensibles a un chunking malo.
- «El chunking es una tarea de una sola vez.» Cuando llega un tipo de documento nuevo (otra estructura de PDF, otro formato de tabla), hay que revisarlo todo otra vez.
Qué llevarte
El chunking es la parte más infravalorada de RAG: no se ve, no hay demo de él y aun así ahí se decide la calidad del sistema. La mitad de los fallos — que la respuesta no entre en los resultados, o que entre incompleta — se remontan al chunking.
Tres cifras que conviene recordar: +17,5 puntos solo por trocear; +12 puntos con casi la mitad de chunks si usas la estructura del documento; y cuatro veces y media de diferencia en precision entre chunks pequeños y grandes, con un recall prácticamente igual.
Y la ganancia más rápida que puedes conseguir hoy: mira cuál es el tamaño de chunk de fábrica en tu sistema. Si es 800 o más, con un solo ajuste mejorarás más que cambiando de modelo. Cómo saber que el sistema terminado responde bien lo recorre el post sobre la evaluación de un sistema RAG punto por punto, y para el lado del almacenamiento está la introducción a vector database sin jerga.