Divisor de Texto: la guía completa (2026)
Las unidades por las que puedes dividir, por qué los límites de oración son más difíciles de lo que parecen, qué recomienda la guía publicada sobre fragmentación para recuperación, en qué se diferencian los tokens de los caracteres y cómo mantener las partes en orden cuando viajan por separado.
- Por qué dividir texto aparece en todas partes
- Siete unidades para dividir, y cuándo conviene cada una
- Los límites de oración son más difíciles de lo que parecen
- Fragmentar para recuperación y embeddings
- Fragmentación de tamaño fijo, recursiva y semántica
- Superposición: qué hace y cuánta usar
- Dividir por tokens: por qué los caracteres no bastan
- Las ventanas de contexto no son el límite que crees
- Límites de plataforma: SMS, publicaciones y campos
- Etiquetas, orden y cómo volver a unir las partes
- Un flujo de trabajo repetible
- Herramientas relacionadas para el mismo trabajo
Dividir un texto es el requisito silencioso de la mitad de las cosas que hoy se hacen con el lenguaje. Un prompt tiene que caber en una ventana de contexto, un documento hay que fragmentarlo antes de convertirlo en embeddings y buscar en él, una publicación tiene que respetar el tope de una plataforma, un mensaje tiene que caber en un SMS, una transcripción la revisan tres personas a la vez. Todos esos casos son el mismo problema: cortar un texto largo en partes que quepan dentro de un límite, sin cortar donde duele. Esta guía recorre las unidades por las que puedes dividir, por qué los límites de oración son más difíciles de lo que parecen, qué recomienda de verdad la guía publicada sobre fragmentación para recuperación, en qué se diferencian los tokens de los caracteres y cómo mantener las partes en orden cuando viajan por separado.
El Divisor de Texto hace todo esto en tu navegador. La guía explica las decisiones detrás de cada una de sus opciones para que las elijas a propósito.
Por qué dividir texto aparece en todas partes
Los límites están en todos lados, y se miden en unidades distintas. Los modelos de lenguaje miden su contexto en tokens. Los modelos de embeddings tienen una entrada máxima, también en tokens. Los campos de texto, los SMS y las redes sociales cuentan caracteres. Editores, traductores y revisores piensan en palabras, oraciones y párrafos. Los registros y las hojas de cálculo piensan en líneas. Un divisor es útil justamente porque te deja cortar por la unidad que el destino cuenta, y no por la que resulta fácil de medir.
La segunda razón es la calidad, no solo el encaje. Un sistema de recuperación que responde preguntas a partir de tus documentos solo puede devolver los fragmentos que indexó; si un fragmento termina a mitad de oración, el dato de la frontera no está en ninguna de las dos mitades. La guía de Pinecone sobre estrategias de fragmentación lo dice sin vueltas: si un fragmento contiene oraciones que no sirven sin contexto, puede que nunca aparezca en una consulta. Dividir bien es decidir qué podrá encontrar una búsqueda futura.
Siete unidades para dividir, y cuándo conviene cada una
| Unidad | Qué significa el tamaño | Úsala cuando |
|---|---|---|
| Caracteres | Máximo de caracteres por parte | El destino cuenta caracteres: formularios, SMS, publicaciones, fichas |
| Palabras | Máximo de palabras por parte | Personas leerán o traducirán las partes; planifican su trabajo en palabras |
| Tokens | Máximo de tokens por parte en la codificación del propio modelo | Las partes van a un modelo de lenguaje o a un modelo de embeddings |
| Oraciones | Oraciones por parte | Quieres la unidad más pequeña que todavía se lee como una idea completa |
| Párrafos | Párrafos por parte | El autor ya agrupó las ideas; un párrafo por fragmento es una unidad habitual de recuperación |
| Líneas | Líneas por parte | El texto ya viene a un elemento por línea: registros, listas, filas CSV, código |
| Partes iguales | El número de partes que quieres | Repartes un trabajo entre personas o sesiones y solo importa la cantidad |
Dos de ellas merecen una nota. Dividir por párrafos respeta una estructura que una persona ya eligió, y por eso suele ser el mejor primer intento con documentos bien editados. Partes iguales es la excepción: parte del número de partes y deduce el tamaño, y aun así termina cada parte en un límite de oración o de palabra, para que ninguna empiece a mitad de una idea.
Los límites de oración son más difíciles de lo que parecen
Todo el mundo sabe que una oración termina en punto, signo de interrogación o de exclamación. El problema es que el punto también cierra abreviaturas («Dr.», «EE. UU.», «etc.») y vive dentro de los números («3.14»), y que detrás del signo final pueden venir comillas o paréntesis de cierre. El estándar Unicode de segmentación de texto, UAX #29, lo dice con todas las letras: el punto se usa de forma ambigua, a veces para terminar una oración, a veces en abreviaturas, a veces en números. Sus reglas de límite de oración por defecto resuelven los casos comunes y recomiendan ajustes propios de cada idioma para el resto.
Los navegadores ya traen esa maquinaria. La API Intl.Segmenter hace segmentación sensible al idioma en grafemas, palabras u oraciones, así que un divisor que corre en el navegador puede preguntarle a la plataforma dónde terminan las oraciones en lugar de adivinarlo con una expresión regular. El Divisor de Texto la usa cuando está disponible, con un respaldo por reglas para navegadores antiguos y una pasada extra que vuelve a unir los cortes falsos tras abreviaturas frecuentes, y empaqueta oraciones enteras en cada parte. Cuando una sola oración es más larga que la parte que pediste, no tiene más remedio que cortar por dentro, y te lo dice en lugar de hacerlo en silencio.
Fragmentar para recuperación y embeddings
La generación aumentada por recuperación, o RAG, indexa piezas de tus documentos como vectores y trae las más cercanas a un prompt cuando llega una pregunta. Esas piezas son los fragmentos, y la manera de construirlos decide qué puede responder el sistema. Dos restricciones enmarcan la decisión. Primera, los modelos de embeddings limitan su entrada: la guía de embeddings de OpenAI indica una entrada máxima de 8192 tokens para sus modelos text-embedding-3. Segunda, un fragmento debe cargar una idea con contexto suficiente para sostenerse solo, porque eso es lo que se compara con la consulta.
La documentación de Microsoft sobre fragmentar documentos grandes para búsqueda vectorial ofrece un punto de partida concreto: un tamaño fijo suficiente para párrafos con sentido, por ejemplo, 200 palabras o 600 caracteres, con cierta superposición, por ejemplo, del 10 al 15 % del contenido. También señala que fragmentar es la forma de mantenerse por debajo de la entrada máxima de tokens de los modelos de chat y de embeddings. Son valores para probar, no leyes: una tabla de especificaciones quiere fragmentos más pequeños que un informe narrativo, y las preguntas que exigen referencias cruzadas quieren fragmentos más grandes.
Fragmentación de tamaño fijo, recursiva y semántica
La literatura agrupa los métodos en unas pocas familias. La fragmentación de tamaño fijo, como la describe Pinecone, consiste en decidir un número de tokens por fragmento y trocear el documento en piezas de ese tamaño, con o sin superposición; es el método más común y el más barato de calcular. La división recursiva por caracteres, implementada en el RecursiveCharacterTextSplitter de LangChain, prueba una lista de separadores en orden, normalmente saltos de párrafo primero, luego saltos de línea, luego espacios, para que los fragmentos sigan la estructura del documento hasta donde el tamaño lo permita. La fragmentación semántica usa un modelo para decidir dónde cambia el tema, lo que cuesta más y no puede funcionar sin un modelo. La documentación de divisores de texto de LangChain es la referencia para las familias de software; el Divisor de Texto implementa las dos primeras ideas en el navegador (tamaño fijo en cualquier unidad, con límites que respetan oraciones y palabras) y, a propósito, no la tercera.
Superposición: qué hace y cuánta usar
La superposición repite el final de un fragmento al comienzo del siguiente. Su propósito es garantizar que una oración o un dato que cae en la frontera aparezca entero al menos en un fragmento, para que una búsqueda pueda encontrarlo. El costo es la redundancia: más fragmentos que almacenar, más tokens que convertir en embeddings y pasajes repetidos en los resultados. La cifra de Microsoft, del 10 al 15 %, es un rango de partida razonable para recuperación; para un texto que alguien leerá en orden, la superposición es simplemente ruido y debería ser cero.
Cómo se toma la superposición importa tanto como su tamaño. Un corte crudo de los últimos N caracteres casi siempre empieza a mitad de palabra. El Divisor de Texto arrastra unidades completas, palabras enteras hasta agotar el presupuesto de superposición, para que la cola repetida siempre se lea como texto y el dato de la frontera se conserve intacto.
Dividir por tokens: por qué los caracteres no bastan
Un modelo de lenguaje nunca ve tus caracteres. Ve tokens, las unidades que produce su tokenizador, y su relación con los caracteres es apenas una regla aproximada: en prosa inglesa un token son unos cuatro caracteres, pero el código, los números, otros idiomas y las palabras raras mueven esa proporción, a veces mucho. Nuestra propia comparación de tokenizadores midió cuánto varía el mismo texto entre codificaciones. Una parte medida en caracteres es, por tanto, una apuesta cuando el límite está en tokens, y una apuesta que falla hacia el lado equivocado termina truncada.
El Divisor de Texto cuenta con la codificación o200k, la que usan GPT-5, GPT-4.1 y GPT-4o, con el mismo tokenizador que el Contador de Tokens, de modo que una parte de 500 tokens son exactamente 500 tokens para esos modelos. Empaqueta oraciones o palabras enteras hasta el presupuesto y después mide cada parte terminada con exactitud. Claude y Gemini usan sus propios tokenizadores, que no existen como bibliotecas para el navegador; para ellos la cuenta es una estimación cercana, y lo correcto es dimensionar las partes un poco por debajo del límite.
Las ventanas de contexto no son el límite que crees
Las ventanas de contexto han crecido enormemente. La documentación de Google dice que muchos modelos Gemini traen ventanas de contexto de un millón de tokens o más; la de Anthropic describe ventanas de 200 000 tokens para Claude Sonnet 4.5 y otros modelos, y de hasta un millón según el modelo. Es tentador concluir que dividir ya no hace falta. No es así, por tres razones. El costo: cada token de la ventana se paga en cada llamada. La calidad: los sistemas de recuperación siguen devolviendo fragmentos, y un fragmento que es un documento entero es un mal resultado de búsqueda. La atención: un modelo al que le das un párrafo relevante suele responder mejor que uno al que le entregas cien páginas y le pides que lo encuentre. Las ventanas grandes cambian cuánto puedes permitirte incluir; no eliminan la necesidad de elegir.
Límites de plataforma: SMS, publicaciones y campos
Algunos límites son viejos y duros. Un SMS lleva un cuerpo de 140 bytes, que caben 160 caracteres del alfabeto GSM de 7 bits definido en la especificación 3GPP TS 23.038, o 70 caracteres cuando el mensaje incluye algo fuera de ese alfabeto y debe enviarse en UCS-2; una sola letra con tilde o un emoji puede, por tanto, reducir el espacio a la mitad y duplicar el número de mensajes. X admite publicaciones de hasta 280 caracteres y, según su documentación sobre conteo de caracteres, pondera algunos, como muchos caracteres CJK y los emojis, como dos. Las meta descripciones, los campos de las tiendas de aplicaciones, los titulares de anuncios y los formularios tienen cada uno su tope, y casi todos cuentan caracteres, no palabras. El modo de caracteres con palabras enteras es la herramienta adecuada para todos ellos; cuando la plataforma cuenta de forma inusual, comprueba la parte más larga con el Contador de Caracteres.
Etiquetas, orden y cómo volver a unir las partes
Las partes que viajan separadas necesitan tres cosas: una etiqueta que diga qué parte es esta y cuántas hay, un orden estable y una regla de unión que deshaga la división. Una etiqueta como [2/5] cuesta seis caracteres y evita casi toda la confusión; el divisor la añade como prefijo para que sea visible en cualquier destino. El orden se conserva al copiar todas las partes de una vez o al descargarlas como un solo archivo, donde van separadas por una línea en blanco. Para volver a unirlas, quita las etiquetas y junta las partes con ese mismo separador; si usaste superposición, también hay que eliminar las colas repetidas, una razón más para reservar la superposición a la recuperación y no a un texto que alguien va a reconstruir.
Un flujo de trabajo repetible
- Nombra el límite y su unidad. Tokens para un modelo, caracteres para un campo, párrafos para un documento que alguien editó. Fija el tamaño un poco por debajo del límite real.
- Pega el texto en el Divisor de Texto y elige el modo que corresponde. Mantén enteras las oraciones y las palabras, salvo que el destino cuente de verdad caracteres crudos.
- Decide la superposición. Del 10 al 15 % para fragmentos de recuperación; cero para todo lo que una persona leerá en orden.
- Mira la parte más larga. Si una parte es mucho mayor que el resto, la forzó una oración o un párrafo largo; baja el tamaño o activa la división a nivel de palabra.
- Deja las etiquetas activadas cuando las partes se envíen por separado, y copia todo o descarga para conservar el orden.
- Cuenta como cuenta el destino. Verifica una parte con el Contador de Tokens o el Contador de Caracteres cuando el límite sea estricto.
Herramientas relacionadas para el mismo trabajo
El divisor corta; otras herramientas miden y preparan. El Contador de Tokens calcula el costo de un texto en distintos modelos y lo compara con una ventana de contexto. El Contador de Oraciones y el Contador de Palabras muestran qué estás a punto de dividir. El Limpiador de Texto IA quita el Markdown y los caracteres ocultos de una respuesta de IA antes de fragmentarla, y Resumir Texto acorta una fuente cuando hacerla caber entera es la mejor opción.
Fuentes y lecturas recomendadas
- Microsoft Learn: fragmentar documentos grandes para soluciones de búsqueda vectorial (edición en español): tamaño fijo, superposición, límites de entrada de los embeddings
- OpenAI: guía de embeddings (en inglés): entrada máxima por modelo de embeddings
- Pinecone: estrategias de fragmentación para aplicaciones con modelos de lenguaje (en inglés)
- LangChain: divisores de texto, documentación conceptual (en inglés)
- Unicode Standard Annex #29: segmentación de texto Unicode, límites de oración (en inglés)
- MDN: Intl.Segmenter, segmentación de texto sensible al idioma en el navegador (en inglés)
- Google AI for Developers: contexto largo en la API de Gemini (edición en español)
- Anthropic: ventanas de contexto (en inglés)
- 3GPP TS 23.038: alfabetos e información específica por idioma, alfabeto GSM de 7 bits (en inglés)
- X Developer Platform: conteo de caracteres (en inglés)
Preguntas frecuentes
¿Cómo divido un texto en fragmentos?
Elige la unidad que cuenta el destino (caracteres, palabras, tokens, oraciones, párrafos o líneas), fija el máximo por parte y corta en límites de palabra u oración en lugar de en la cuenta exacta. El Divisor de Texto lo hace en el navegador y añade etiquetas [1/N], superposición, copia por parte y descarga en .txt.
¿Cómo elijo el tamaño de fragmento para RAG?
Parte de los valores publicados y prueba con tus propias preguntas. La guía de fragmentación de Microsoft da un tamaño fijo de, por ejemplo, 200 palabras o 600 caracteres con una superposición del 10 al 15 %; los modelos text-embedding-3 de OpenAI aceptan como máximo 8192 tokens por entrada. Las especificaciones y las tablas piden fragmentos más pequeños; la narrativa con referencias cruzadas, más grandes.
¿Qué diferencia hay entre dividir por caracteres y la división recursiva por caracteres?
Dividir por caracteres corta en una cuenta fija. La división recursiva, como el RecursiveCharacterTextSplitter de LangChain, prueba una lista de separadores en orden, normalmente saltos de párrafo, luego saltos de línea y luego espacios, para que los fragmentos sigan la estructura del documento hasta donde el tamaño lo permite.
¿Por qué dividir por tokens y no por caracteres?
Porque los modelos de lenguaje y los de embeddings miden la entrada en tokens, y la relación entre caracteres y tokens cambia con el idioma, el código y el vocabulario. Una parte medida en tokens con la codificación del propio modelo cabe por construcción; una medida en caracteres es una apuesta.
¿Qué es la superposición entre fragmentos y cuánta conviene?
La superposición repite el final de un fragmento al comienzo del siguiente para que un dato de la frontera sobreviva al menos en uno. La guía de Microsoft sugiere alrededor del 10 al 15 % del contenido para recuperación; para un texto que una persona leerá en orden, ninguna.
¿Sigue importando dividir con ventanas de contexto de un millón de tokens?
Sí. Google documenta modelos Gemini con ventanas de un millón de tokens o más y Anthropic documenta 200 000 y hasta un millón para Claude, pero cada token de la ventana se paga, la recuperación sigue devolviendo fragmentos, y un modelo al que le das un párrafo relevante suele responder mejor que uno al que le entregas cien páginas.
Seguir leyendo
Escrito por SAVI. Construimos las herramientas sobre las que escribimos. Prueba Divisor de Texto que aparece en este artículo.