Calculadora RAG: chunk size y overlap óptimo🌎
Actualizado junio de 2026Ver cálculo paso a paso
El chunking es la pieza más subestimada de un sistema RAG. Si los chunks son muy chicos (200 tokens), perdés contexto y el embedding no captura la idea completa. Si son muy grandes (2.000 tokens), el modelo embedding diluye conceptos y el retrieval devuelve resultados poco precisos. El overlap entre chunks (solapar 10-20% del final de un chunk con el inicio del siguiente) evita cortar oraciones por la mitad. La regla práctica 2026: chunk_size = 500-800 tokens + overlap = 10-20% para la mayoría de casos. Esta calculadora toma tokens del documento, chunk size y % overlap, devuelve cantidad de chunks, tokens totales embedeados y eficiencia (qué fracción es contenido único vs duplicado por overlap). Útil para presupuestar embeddings, tunear retrieval o entender por qué tu RAG no está respondiendo bien.
Cuándo usar esta calculadora
- Decidir el chunk size correcto para tu corpus de PDFs / wiki / docs.
- Calcular cuánto va a costar embeddear N documentos.
- Estimar cuántos vectores tendrás en tu vector DB después del chunking.
- Comparar eficiencia entre overlap 10% vs 20% vs 30%.
- Validar que el chunk no excede el límite del modelo embedding.
Ejemplo: PDF 20.000 tokens, chunk 512, overlap 15%
- Overlap: 512 × 0,15 = 76,8 ≈ 77 tokens.
- Stride (avance neto): 512 − 77 = 435 tokens.
- Cantidad de chunks: ceil(20.000 / 435) = 46 chunks.
- Tokens totales embedeados: 46 × 512 = 23.552 tokens (vs 20k del doc original).
- Eficiencia: 20.000 / 23.552 = 84,9% (15% es overlap).
Cómo funciona
4 min de lecturaFórmula del chunking RAG
overlap_tokens = chunk_size × overlap_pct
stride = chunk_size − overlap_tokens
cantidad_chunks = ceil(tokens_documento / stride)
tokens_embedeados = cantidad_chunks × chunk_size
eficiencia = tokens_documento / tokens_embedeadosEl overlap sirve para que ideas que cruzan la frontera entre chunks no se pierdan. Sin overlap, una oración puede quedar partida exactamente en la unión y ningún chunk la representa bien.
Tabla de chunk sizes recomendados
| Tipo de contenido | Chunk recomendado | Overlap |
|---|---|---|
| FAQ corto / snippets | 200-400 tokens | 10% |
| Documentación técnica | 500-800 tokens | 15% |
| Artículos / blog posts | 600-1.000 tokens | 15-20% |
| PDFs estructurados / contratos | 800-1.500 tokens | 20% |
| Código fuente | semantic split (función) | — |
| Conversaciones / chats | por turn | 0% (boundary natural) |
Tabla de modelos embedding y límites (2026)
| Modelo | Dim | Token máx | Costo aprox. |
|---|---|---|---|
| OpenAI text-embedding-3-small | 1.536 | 8.192 | USD 0,02 / 1M tokens |
| OpenAI text-embedding-3-large | 3.072 | 8.192 | USD 0,13 / 1M tokens |
| Cohere embed-multilingual-v3 | 1.024 | 512 | USD 0,10 / 1M tokens |
| Cohere embed-v3 (English) | 1.024 | 512 | USD 0,10 / 1M tokens |
| BGE-M3 (open-source) | 1.024 | 8.192 | self-host |
| e5-large-v2 (open-source) | 1.024 | 512 | self-host |
| Voyage-3 | 1.024 | 32.000 | USD 0,06 / 1M tokens |
Verificá pricing oficial vigente antes de usar en producción.
Tabla de valores comunes: chunks vs overlap
| Tokens doc | Chunk | Overlap | Chunks generados | Tokens embedeados | Eficiencia |
|---|---|---|---|---|---|
| 5.000 | 256 | 10% | 22 | 5.632 | 88,8% |
| 10.000 | 512 | 15% | 24 | 12.288 | 81,4% |
| 20.000 | 512 | 15% | 46 | 23.552 | 84,9% |
| 20.000 | 800 | 20% | 32 | 25.600 | 78,1% |
| 50.000 | 1.000 | 10% | 56 | 56.000 | 89,3% |
| 100.000 | 800 | 15% | 148 | 118.400 | 84,5% |
Estrategias de chunking
1. Fixed-size (default, simple)
Divide cada N tokens. Rápido y predecible. Funciona bien con overlap.
2. Recursive character splitter (LangChain default)
Intenta dividir por: párrafos → oraciones → palabras. Mantiene boundaries semánticos.
3. Semantic chunking (mejor calidad, más caro)
Usa un LLM o embedding similarity para decidir dónde cortar. Detecta cambios de tema dentro del documento. Costo extra: ~10-30% en latencia + tokens.
4. Document-aware (PDFs, HTML)
Respeta secciones, tablas, headers. Crucial en contratos legales y papers científicos.
5. Late chunking (técnica 2024-2026)
Embedeás el documento completo con context-rich models (Voyage, Jina-v3) y chunkeás los embeddings, no el texto. Mejora coherencia pero requiere modelos especiales.
Errores comunes de chunking RAG
1. Overlap=0%: corta ideas a la mitad. Mínimo recomendado: 10%.
2. Chunk demasiado chico (<200 tok): cada vector pierde contexto. El retrieval devuelve fragmentos sin sentido.
3. Chunk demasiado grande (>2.000 tok): el embedding promedia tantos conceptos que pierde precisión. Recall@10 cae 20-40%.
4. No filtrar metadata: si todos los chunks van a una bolsa común, el retrieval se desordena. Agregá source, tenant, date.
5. Olvidar tablas y código: chunkear con character splitter rompe tablas Markdown y bloques de código. Tratá esos casos por separado.
Cómo elegir k en retrieval
Después de chunkear, en query traes los top-k chunks más similares. Heurística:
Costo de embeddear un corpus
tokens_embedeados = chunks × chunk_size
costo_embedding = tokens_embedeados × precio_por_tokenEjemplo: 10.000 documentos × 5.000 tokens cada uno = 50M tokens. Con overlap 15% suben a ~58M. Con OpenAI 3-small (USD 0,02/M): ~USD 1,16. Con 3-large (USD 0,13/M): ~USD 7,54.
> Aviso legal: Calculadora educativa. No constituye recomendación técnica final: el chunk óptimo depende de tu corpus específico — testeá con eval set propio antes de productivizar.
Revisión editorial
Revisado por el equipo editorial de Hacé Cuentas. Cifras y prácticas cotejadas contra docs oficiales de OpenAI, Cohere, LangChain y LlamaIndex a junio 2026.
Preguntas frecuentes
¿Cuál es el chunk size óptimo para RAG?
500-800 tokens funciona bien para el 80% de los casos en 2026 con embeddings OpenAI / Cohere / BGE. Para FAQ cortos, bajá a 200-400. Para documentos técnicos densos (papers, contratos), subí a 1.000-1.500. Siempre testeá con un eval set propio para tu corpus específico.
¿Cuánto overlap usar en RAG?
10-20% es el rango recomendado. Menos del 10% arriesga partir ideas importantes en la frontera de chunks. Más del 30% duplica costo y storage sin mejora notable de retrieval. El default 15% de LangChain es razonable para la mayoría de casos.
¿Cómo se calcula el número de chunks?
La fórmula es: stride = chunk_size × (1 − overlap_pct) y luego chunks = ceil(tokens_documento / stride). Con un doc de 20.000 tokens, chunk 512 y overlap 15%: stride = 512 × 0,85 = 435 tokens → 46 chunks.
¿Por qué mi RAG devuelve resultados malos?
Los 5 sospechosos más comunes: (1) chunks demasiado grandes que diluyen el embedding, (2) overlap=0% que corta ideas, (3) modelo embedding débil (probá voyage-3 o text-embedding-3-large), (4) k bajo en retrieval, (5) falta de re-ranking post-retrieval (Cohere Rerank o un cross-encoder mejoran 10-30%).
¿Qué pasa si el chunk excede el límite del modelo embedding?
El modelo trunca los tokens excedentes, a veces silenciosamente. Cohere embed-v3 tiene límite de 512 tokens: si tu chunk es 800, perdés el contenido final. La calculadora valida que chunk_size ≤ tokens_max del modelo seleccionado.
¿Cuántos vectores genera 1 GB de PDFs?
Estimación: 1 GB de PDFs ≈ 80-150M tokens (varía según densidad de texto). Con chunk 500 + overlap 15% → aproximadamente 190.000-350.000 vectores. Pesarían 1-3 GB en una vector DB con embeddings de 1.536 dimensiones en float32.
¿Cuánto cuesta embeddear 1.000 documentos?
Asumiendo 5.000 tokens/doc + chunk 500 + overlap 15%: ~5,8M tokens totales. Con OpenAI text-embedding-3-small (USD 0,02/M): ~USD 0,12. Con 3-large (USD 0,13/M): ~USD 0,75. Con Voyage-3 (USD 0,06/M): ~USD 0,35. Lo más barato es self-host BGE-M3 a costo solo de GPU.
¿Conviene chunks fijos o por estructura del documento?
Por estructura siempre que sea posible. Si tenés Markdown o HTML, dividí por headers (h2, h3). En PDFs estructurados, respetá secciones. Fixed-size sirve como fallback cuando no hay estructura clara (texto plano, transcripts, emails).
¿Qué es semantic chunking y cuándo usarlo?
Es una estrategia que detecta cambios de tema dentro del documento usando similitud entre embeddings de oraciones consecutivas. Cuando hay un salto semántico, corta. Mejora calidad de retrieval un 5-15% vs fixed-size, pero suma costo (cada doc requiere embedding extra). Usalo en producción cuando la calidad justifique el costo adicional.
Fuentes y referencias
También te puede interesar
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 03 de junio de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.