No chunkar datos estructurados (JSON, CSV) con un chunker de texto. Los límites caen a mitad de registro y los embeddings pierden sentido. Divide por registros primero, o usa un enfoque RAG específico. No chunkar código con un chunker de prosa. Para retrieval de código importan los límites de función, no el número de caracteres. Existen chunkers basados en tree-sitter. Whitespace y BOM. Texto pegado puede traer whitespace oculto que desvía la estimación de tokens. Trimmea y normaliza antes si importa. Privacidad. Todo corre en el navegador. Los documentos pegados aquí no salen de la página; úsala para material confidencial o con PII igual que un script local.

Chunker de Texto para RAG

Divide texto en chunks de tamaño en tokens para RAG / preparación de embeddings. Varias estrategias: recursive char, sentence-aware, semantic boundaries. Overlap configurable. Todo en el navegador.

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

¿Para qué sirve?

RAG (Retrieval-Augmented Generation) y la búsqueda por embeddings dependen ambas de dividir un corpus en chunks: piezas pequeñas que se embedean individualmente y se guardan en una vector DB. La división ocurre antes de cualquier maquinaria de IA, pero la calidad de tu retrieval depende silenciosamente de ella más de lo que la gente cree. Chunks demasiado pequeños pierden contexto; demasiado grandes diluyen relevancia; chunks cortados a mitad de frase retrievan mal porque el embedding cae en un punto semántico raro. Esta herramienta es un playground rápido en el navegador para experimentar con tamaño, overlap y estrategia antes de fijar una pipeline.

Las cuatro estrategias

recursive-char (predeterminado). Intenta dividir por párrafos primero, luego saltos de línea, luego fronteras de frase (. ), luego espacios. Cada pieza se empaqueta greedy hasta el budget de tamaño. Solo recurre a corte por caracteres cuando nada más cabe. Es el default en LangChain, LlamaIndex y la mayoría de stacks RAG en producción; punto de partida sensato para casi cualquier corpus de prosa.
sentence. Divide en fronteras de frase y nunca dentro de una frase — aunque sea más corta que el budget, queda entera. Mejor que recursive-char cuando los chunks se citarán como evidencia (QA, citas) porque ningún chunk termina a mitad de pensamiento. Los tamaños varían más, porque las frases varían.
paragraph. Trata cada párrafo como unidad. Dos párrafos cortos adyacentes pueden empaquetarse juntos, pero uno largo nunca se divide. Útil para documentación, artículos de KB y formato largo bien estructurado donde cada párrafo es un pensamiento coherente.
semantic. Añade detección de headings sobre paragraph: líneas con #, ## etc., o líneas cortas en mayúsculas, se tratan como inicio de nueva sección. Bueno para documentación técnica donde las secciones importan más que el espaciado visual.

Overlap — por qué y cuánto

Por qué. Si un span relevante cae exactamente entre dos chunks, ambos retrievan mal porque cada uno tiene solo la mitad. Overlap copia los últimos N tokens del chunk anterior al inicio del siguiente para que ambos capturen el span.
Cuánto. 10–20% del tamaño del chunk como regla. Para chunks de 500 tokens, 50–100 de overlap. Aquí el default es 50, va bien en la práctica.
Trade-off. Más overlap = más embeddings totales (más storage, más coste, build más lento, más candidatos de retrieval). No pases del 30% sin razón concreta; gastas dinero sin mejorar mucho.

Estimación de tokens

Es heurística. chars / 3.8 para texto tipo inglés y 1 token por carácter CJK. ±5–10% para prosa, peor con código o texto estructurado.
¿Por qué no el tokenizer real? tiktoken son ~1 MB de WASM — demasiado pesado solo para sizing. Si tu modelo downstream tiene un límite duro (p.ej. cohere/embed-v3 a 512), construye con margen o corre el tokenizer real en tu pipeline.
Para sizing va bien. El conteo exacto por chunk importa poco para calidad RAG — el modelo de embedding trunca de todos modos. Lo que importa es la consistencia: la misma heurística para chunking y para presupuestar prompts downstream.

Errores comunes

No chunkar datos estructurados (JSON, CSV) con un chunker de texto. Los límites caen a mitad de registro y los embeddings pierden sentido. Divide por registros primero, o usa un enfoque RAG específico.
No chunkar código con un chunker de prosa. Para retrieval de código importan los límites de función, no el número de caracteres. Existen chunkers basados en tree-sitter.
Whitespace y BOM. Texto pegado puede traer whitespace oculto que desvía la estimación de tokens. Trimmea y normaliza antes si importa.
Privacidad. Todo corre en el navegador. Los documentos pegados aquí no salen de la página; úsala para material confidencial o con PII igual que un script local.