Lotook
Para dividir documentos en chunks de forma eficaz para RAG, separa primero los archivos según la estructura existente del documento, aplica un límite de longitud en tokens con solapamiento a nivel de oración a las secciones demasiado grandes y adjunta metadatos de origen a cada pasaje. La elección entre fragmentación por tokens, semántica y basada en la estructura depende de si tu corpus consta de prosa uniforme, temas cambiantes o tablas y títulos con formato.
¿Por qué la fragmentación para RAG determina la calidad de la recuperación?
Retrieval-Augmented Generation (RAG) divide los documentos de origen en pasajes más pequeños antes de generar sus embeddings y almacenarlos en un índice de búsqueda. En el momento de la consulta, el sistema recupera los chunks más relevantes y los entrega a un modelo de lenguaje junto con la pregunta del usuario. La fragmentación determina la unidad de recuperación porque un documento completo suele ser demasiado amplio para coincidir bien con una pregunta concreta y demasiado grande para caber junto con otros candidatos en la ventana de contexto del modelo.
Cuando Patrick Lewis y sus colegas presentaron el marco en su artículo de NeurIPS de 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks), su experimento dividió cada artículo de Wikipedia en chunks sin solapamiento de unas 100 palabras, produciendo unos 21 millones de pasajes. Esa división en bloques de 100 palabras fue una configuración experimental de 2020 para Wikipedia, no un valor predeterminado de producción para 2026. En noviembre de 2026, el RAG moderno en producción suele funcionar como una canalización de ingeniería modular (fragmentar, generar embeddings, indexar, recuperar y generar), en lugar de la configuración original de DPR y BART diferenciable de extremo a extremo.
¿Cuáles son los tres métodos principales de fragmentación para RAG?
Los métodos de fragmentación para RAG se dividen en tres familias: división por tokens, semántica y basada en la estructura. Cada familia determina dónde empieza y termina un pasaje mediante la longitud, el significado o el marcado del documento.
| Método de fragmentación | Señal de división | Mejor uso | Riesgo principal | Coste de indexación |
|---|---|---|---|---|
| Fragmentación por tokens (o longitud) | Ventana fija de tokens o caracteres con solapamiento deslizante | Prosa uniforme, texto sin formato o límite de longitud tras dividir por estructura | Corta por la mitad oraciones, filas de tablas, bloques de código o definiciones | Bajo |
| Fragmentación semántica | Descenso de la similitud entre embeddings de oraciones contiguas | Prosa sin formato donde los temas cambian a mitad del documento sin títulos | Indexación más lenta y costosa; tamaños de chunk desiguales | Alto |
| Fragmentación basada en la estructura | Títulos, párrafos, listas, tablas, bloques de código o páginas | Markdown, HTML, documentación de API, cláusulas legales y manuales estructurados | Estructura débil en PDFs escaneados; algunas secciones pueden seguir siendo enormes | Bajo a medio |
1. Fragmentación por tokens y caracteres
La fragmentación por tokens divide el texto en ventanas de longitud fija medida en tokens o caracteres, a menudo con un solapamiento deslizante. Medir en tokens se ajusta al funcionamiento de los modelos: los modelos de embeddings y los LLM tienen límites estrictos de tokens, las API se facturan por tokens y un mismo párrafo puede tokenizarse de forma diferente según la familia de modelos. El número de caracteres es solo una aproximación.
Los equipos suelen comenzar con un tamaño de ventana que quepa dentro del límite de su modelo de embeddings (los tutoriales suelen empezar con unos cientos de tokens) y lo ajustan después de revisar los fallos de recuperación. El principal riesgo de una ventana fija es que ignora la sintaxis y el diseño, corta una oración, fila de tabla, bloque de código o definición y omite la cláusula que responde a la pregunta.
2. Fragmentación semántica
La fragmentación semántica divide el texto cuando cambia el significado, por ejemplo cuando disminuye la similitud entre embeddings de oraciones contiguas o aparece un límite discursivo, en lugar de hacerlo a un número rígido de tokens. Mantener una idea completa en un chunk facilita la recuperación cuando los temas cambian a mitad de un documento sin títulos.
Sin embargo, la fragmentación semántica es más lenta y costosa de indexar porque la propia división puede requerir llamadas para generar embeddings. Un umbral de similitud con ruido también puede dividir el texto en exceso o de forma insuficiente, con tamaños desiguales, y la similitud entre oraciones no es automáticamente mejor para tablas, formularios o código.
3. Fragmentación basada en la estructura
La fragmentación basada en la estructura utiliza la estructura existente del documento para el primer corte: títulos de Markdown o HTML, párrafos, listas, secciones, páginas, bloques de código delimitados o límites de tablas. Como señala AWS Prescriptive Guidance sobre RAG, conservar la estructura del documento mantiene intacto el contexto relacionado de forma lógica. Un chunk que empieza en un título de política de reembolso y contiene toda la sección es más fácil de recuperar y citar que una ventana que comienza a mitad de una oración.
Como muchos PDFs y documentos escaneados carecen de títulos claros (y un solo título puede abarcar 20 páginas), las canalizaciones de producción suelen combinar métodos:
- Divide primero jerárquicamente por estructura: Separa el documento por sección o título y después por párrafo o bloque, manteniendo intactos los bloques de código, tablas y listas.
- Aplica después un límite de longitud en tokens: Si una sección sigue siendo demasiado grande, divídela con una ventana de tokens.
- Usa divisiones alternativas para texto no estructurado: En PDFs escaneados o secciones largas sin estructura, recurre a divisiones por página, ventanas de tokens o límites semánticos.
¿Cómo configurar el solapamiento de chunks y los metadatos de RAG?
El solapamiento de chunks y los metadatos de los pasajes evitan que se pierdan cláusulas en los límites y conectan los fragmentos recuperados con sus documentos de origen.
Configurar el solapamiento de chunks
El solapamiento repite el final de un chunk al principio del siguiente para que una oración o definición situada en un límite aparezca completa en al menos un pasaje recuperado. Es una precaución sencilla cuando las ventanas fijas o las divisiones alternativas cortan una idea por la mitad.
Ajusta el solapamiento para cubrir una o dos oraciones típicas de tu corpus, pero mantenlo lo bastante pequeño para no almacenar dos veces casi el mismo chunk. El solapamiento aumenta los tokens que conviertes en embeddings, almacenas y recuperas, lo que incrementa el tamaño del índice y añade resultados vecinos casi duplicados. Si la recuperación devuelve con frecuencia chunks casi duplicados, reduce el solapamiento o el tamaño de los chunks, o añade una fase de deduplicación después de la recuperación.
Adjuntar metadatos de RAG
Los metadatos de RAG son campos estructurados almacenados junto a cada chunk, entre ellos:
- ID o URL del documento de origen y título
- Ruta de sección o títulos y número de página
- Fecha de creación o actualización y tipo de documento (política, ticket, referencia de API)
- Etiquetas de acceso y permisos, idioma y un ID estable del chunk
Los equipos pueden excluir los metadatos del embedding cuando los ID sin procesar o las marcas de tiempo contaminen la similitud, o anteponer campos seleccionados (como un título de sección) al texto que se convierte en embedding cuando mejoren la recuperación. Los metadatos cubren tres necesidades de producción:
- Citas: Tu interfaz o modelo puede citar un archivo, título y número de página en lugar de un pasaje aislado.
- Filtros de permisos y versiones: Recupera solo la versión más reciente de una política, un producto concreto o documentos que el usuario tenga permiso para ver. Los permisos deben estar en los filtros del índice y no solo en el prompt, ya que colocar documentos privados en un índice RAG sin filtros los expone a cualquiera que pueda consultar el sistema.
- Depuración y actualizaciones: Cuando cambie un documento de origen, vuelve a dividirlo y generar sus embeddings, y retira los ID de chunks antiguos para que los datos desactualizados no causen errores factuales.
¿Cómo saber si tus chunks son demasiado grandes o pequeños?
Examinar los chunks recuperados para preguntas reales de usuarios revela si tus pasajes son demasiado grandes o están fragmentados.
Señales de que tus chunks son demasiado grandes
- Respuestas ocultas: La recuperación devuelve una sección larga que menciona el término de búsqueda pero oculta la respuesta real, de modo que el modelo debe buscarla o la pasa por alto.
- Prompts saturados: Solo caben unos pocos chunks en el prompt, por lo que una coincidencia mediocre desplaza a otras mejores.
- Mayor coste y latencia: Enviar muchos tokens irrelevantes aumenta el gasto y el tiempo de respuesta.
- Mayor distracción: El ruido adicional empeora el context rot: el modelo tiene el dato correcto en un prompt grande, pero se apoya en la memoria de entrenamiento o en una oración adyacente incorrecta.
Señales de que tus chunks son demasiado pequeños
- Fragmentos sin contexto: Un chunk recuperado no se entiende sin la oración anterior (por ejemplo, una oración que indica una excepción para planes empresariales sin nombrar la regla).
- Respuestas de varios pasos separadas: Una definición y su excepción, una función y sus parámetros, o una política y su fecha de entrada en vigor quedan en chunks distintos, y top-k solo devuelve una parte.
- Fragmentos casi idénticos: Recuperas muchos fragmentos repetitivos y sigues sin obtener una idea completa, mientras las citas se vuelven confusas porque cada oración es una fuente distinta.
Para ajustar los tamaños en la práctica, revisa preguntas reales y los chunks recuperados, y pregúntate si una persona que solo dispusiera de esos pasajes podría responder. Si la oración necesaria está en un chunk vecino no recuperado, ajusta el solapamiento, las reglas de estructura o el tamaño. Si está dentro del chunk recuperado rodeada de texto no relacionado, divide en partes más pequeñas o recupera menos chunks y más precisos.
¿Cómo afecta la fragmentación para RAG al context rot?
La fragmentación para RAG es una herramienta directa contra el context rot, la disminución de la calidad del razonamiento, el seguimiento de instrucciones y la capacidad de recordar de un modelo a medida que un prompt se alarga o se llena de información, incluso muy por debajo del límite de contexto anunciado.
RAG existe para que no tengas que volcar todo el corpus en el prompt. Sin embargo, recuperar chunks demasiado grandes, o aumentar top-k por precaución y llenar el prompt de muchos chunks vagamente similares, vuelve a crear un contexto largo y ruidoso. Más contexto no implica automáticamente mayor precisión. Mantener los chunks enfocados reduce la saturación del prompt, aunque una buena fragmentación por sí sola no puede corregir un mal modelo de embeddings ni eliminar las alucinaciones de IA cuando un modelo ignora el texto recuperado.
FAQ
¿Debo medir el tamaño de los chunks de RAG en tokens o caracteres?
Mide el tamaño de los chunks de RAG en tokens siempre que sea posible. Los modelos de embeddings y de lenguaje imponen límites de contexto en tokens y el uso de API se factura por token. El número de caracteres es solo una aproximación, porque un mismo párrafo puede dividirse en distintos números de tokens según el idioma, los bloques de código y la familia de modelos. Usar el tokenizador de tu modelo de embeddings evita truncamientos inesperados durante la indexación.
¿La fragmentación semántica siempre supera a la fragmentación por tokens?
La fragmentación semántica no supera automáticamente a la fragmentación por tokens o basada en la estructura. Dividir cuando disminuye la similitud entre oraciones ayuda a mantener juntas las ideas en prosa no estructurada, pero requiere trabajo adicional de embeddings durante la indexación, crea chunks de tamaño desigual y puede dividir demasiado o demasiado poco con un umbral ruidoso. Para documentos con formato, dividir por títulos, tablas y bloques de código es más rápido y sigue los límites previstos por el autor.
¿Cómo debo dividir tablas y bloques de código para RAG?
Las tablas, facturas, cláusulas legales y el código requieren reglas basadas en la estructura que mantengan intactos los bloques. Una división ingenua por caracteres o tokens a través de una tabla Markdown o del cuerpo de una función produce chunks inutilizables que separan los valores de los encabezados de columna o rompen la sintaxis. Mantén enteros los bloques de código, tablas y listas siempre que sea posible y aplica alternativas basadas en la estructura solo cuando un bloque supere los límites del modelo.
¿Deben incluirse los metadatos en el embedding del chunk?
Incluir metadatos dentro del texto convertido en embedding es una decisión de diseño que depende del campo. Anteponer un título de documento o una ruta de títulos de sección al texto del chunk suele ayudar a la recuperación cuando los párrafos dependen del título para aportar contexto. Los identificadores sin procesar, las marcas de tiempo y las etiquetas de acceso deben permanecer en campos de metadatos separados y filtrables para que no contaminen la similitud entre embeddings.
¿Qué ocurre cuando cambia un documento de origen?
Cuando cambia un documento de origen, tu canalización de ingestión debe volver a dividirlo y generar sus embeddings, y retirar del índice los ID de chunks antiguos. Dejar activos chunks desactualizados junto a los actualizados hace que el sistema de recuperación muestre políticas obsoletas o pasajes contradictorios, convirtiendo un descuido de mantenimiento del índice en un error factual en la respuesta final.
