Después de transformar el lenguaje en vectores mediante embeddings y de almacenarlos en una base vectorial, surge un problema menos visible pero decisivo en cualquier arquitectura RAG: cómo fragmentar la información.

A este proceso se lo conoce como chunking, y aunque suele tratarse como un detalle de implementación, en la práctica es uno de los factores que más impacta en la calidad de las respuestas de un sistema de Generación Aumentada por Recuperación. Un buen modelo, una buena base vectorial y un mal chunking producen, inevitablemente, malos resultados.

1. ¿Qué es el chunking?

El chunking es el proceso mediante el cual un documento se divide en fragmentos más pequeños —chunks— antes de generar sus embeddings y almacenarlos en una base vectorial.

La razón es simple:

los modelos de lenguaje y los sistemas de búsqueda no trabajan eficientemente con documentos extensos como una sola unidad. En lugar de eso, operan mejor cuando la información está segmentada en piezas manejables que puedan ser recuperadas selectivamente según la consulta del usuario.

2. El límite invisible: la ventana de contexto

Los Modelos de Lenguaje Grandes (LLM) tienen una limitación estructural conocida como ventana de contexto: una cantidad máxima de tokens que pueden procesar en una sola interacción.

Aunque esta ventana ha crecido con el tiempo, sigue siendo finita. Esto obliga a los sistemas RAG a seleccionar solo una fracción del conocimiento disponible para cada pregunta. El chunking es, por tanto, el mecanismo que determina qué información puede competir por entrar en ese contexto limitado.

Si los fragmentos son demasiado grandes, se desperdicia espacio con información irrelevante. Si son demasiado pequeños, se pierde coherencia semántica.

3. Chunking no es cortar texto arbitrariamente

Uno de los errores más comunes es asumir que el chunking consiste simplemente en partir un texto cada N caracteres o N tokens. Aunque esta aproximación puede funcionar en casos simples, ignora un aspecto fundamental: el significado no siempre respeta longitudes fijas.

Un párrafo puede contener una idea completa, mientras que otro puede depender fuertemente del contexto anterior. Partir un documento sin considerar su estructura semántica suele producir fragmentos que, aunque matemáticamente válidos, son conceptualmente pobres.

4. El equilibrio entre tamaño y significado

El objetivo del chunking no es maximizar la cantidad de fragmentos, sino maximizar la utilidad semántica de cada uno.

Un buen chunk debería:

• Contener una idea relativamente autocontenida.
• Tener suficiente contexto para ser comprendido de forma independiente.
• No incluir información irrelevante para la mayoría de consultas.

Este equilibrio es delicado y depende del tipo de documento, del dominio del conocimiento y del tipo de preguntas que se esperan del sistema.

5. Overlap: repetir para no olvidar

Para mitigar la pérdida de contexto entre fragmentos, es común introducir overlap, es decir, una superposición parcial de contenido entre chunks consecutivos.

El overlap permite que ideas que cruzan límites artificiales no se fragmenten por completo. Sin embargo, un exceso de overlap introduce redundancia, aumenta el volumen de datos almacenados y puede provocar que el sistema recupere múltiples fragmentos casi idénticos.

Como en muchos aspectos del RAG, aquí no hay valores universales, solo compromisos informados.

6. Chunking y embeddings: una relación directa

Es importante recordar que cada chunk genera su propio embedding. Esto significa que el modelo no “ve” el documento completo, sino únicamente los fragmentos individuales que resulten más similares a la consulta.

Si un concepto clave está dividido entre varios chunks, ninguno de ellos puede resultar suficientemente cercano al embedding de la pregunta, y la información correcta simplemente no será recuperada.

Este es uno de los motivos por los cuales un sistema RAG puede “alucinar” incluso cuando la respuesta correcta existe en la base de conocimiento.

7. Chunking no es universal

No existe una estrategia de chunking válida para todos los casos. Documentación técnica, contratos legales, artículos académicos o conversaciones requieren enfoques distintos.

Pensar el chunking como una decisión puramente técnica es un error; es, en realidad, una decisión arquitectónica y de dominio.

Conclusión

En un sistema RAG, el chunking es el punto donde el lenguaje humano se traduce en unidades de conocimiento recuperables. No es un paso menor ni un simple preprocesamiento, sino una de las decisiones más influyentes en la calidad final del sistema.

Partir bien un documento es, en muchos casos, más importante que elegir el modelo más grande o la base vectorial más rápida. Porque en RAG, lo que no se recupera, no existe.