El RAG evolucionó de un tamaño de fragmento a varios, y no de clásico a agéntico.

Dentro del expediente

Circula un diagrama que ya has visto esta semana, puede que dos veces. Tres columnas, que son RAG clásico, RAG con grafo de conocimiento y RAG agéntico. Cada columna tiene más piezas que la anterior. La flecha de izquierda a derecha se lee sola como progreso.

El diagrama es un género más que un documento concreto, y circula en propuestas de proveedor y entre gente que sabe de lo que habla. Y en las tres columnas hay una caja de la que sale lo que el modelo va a leer, sea una base vectorial o un grafo de conocimiento. Nadie dibuja lo que hay dentro.

El reto de lo que no cambia entre columna y columna

Un sistema RAG hace dos cosas antes de que nadie escriba una pregunta. Trocea los documentos y decide de qué tamaño es cada fragmento, el chunk size. Eso ocurre igual si encima montas un grafo de entidades o un agente que razona sobre la respuesta. El troceado pasa antes, en el indexado, y ninguna de las tres columnas del diagrama lo menciona.

La elección se suele hacer una vez, al principio del proyecto. Algo así como 512 tokens, con un solape del 10 o del 20%, el ejemplo que ponía AI21 en su charla Fuente primaria ↗. Se fija sin conocer las preguntas que van a llegar después, y se queda igual para todas las que lleguen.

Lo que midieron

AI21 Labs publicó en enero de 2026 un experimento que responde justo a lo que el diagrama no pregunta Fuente primaria ↗. Tomaron tres corpus y los indexaron seis veces, cada una con un tamaño de fragmento distinto que iba de 50 a 2000 tokens. Los corpus eran QMSum, con transcripciones de reuniones, y NarrativeQA, con preguntas sobre relatos y novelas. El tercero es un conjunto propio de trivia sobre Seinfeld que publicaron ellos mismos.

Después construyeron un oráculo que, para cada pregunta, elegía a posteriori el tamaño de fragmento que mejor funcionaba. Las diferencias entre ese oráculo y el mejor tamaño fijo fueron habitualmente del 20 al 30% en recall@1, es decir, en acertar el documento correcto en la primera posición, y superaron el 40% en algunos conjuntos Fuente primaria ↗. Ningún tamaño fijo domina. En sus ejemplos, una pregunta puntual rinde mejor con un fragmento pequeño y una que necesita el cuadro completo, con uno grande. Decide la pregunta, no el corpus.

Con ese hallazgo delante, elegir bien un tamaño deja de ser la respuesta, porque no hay un tamaño bueno esperando a que lo encuentres, sino una pregunta que todavía no se ha hecho. Lo que probaron en su lugar fue indexar el mismo corpus varias veces con tamaños distintos, consultar todas las versiones en paralelo y fusionar los resultados con Reciprocal Rank Fusion, un método de votación entre listas ordenadas. Probado ya con FinanceBench junto a los tres anteriores, el resultado es que iguala o supera al mejor tamaño fijo en todos los casos que publican Fuente primaria ↗. En otra batería de pruebas, MTEB, lo comparan con un sistema ingenuo de un solo tamaño y publican mejoras de entre el 1% y el 37% en la mayoría de configuraciones. El 37% sale de un solo caso, TREC-COVID con el modelo E5-small; lo habitual allí son ganancias pequeñas. El coste es previsible y supone entre dos y cinco veces más almacenamiento, porque hay que guardar varias copias del mismo corpus.

El punto ciego que ningún diagrama dibuja

Esta no es la única forma de atacar el síntoma, y ahí está lo interesante para quien lee un diagrama de arquitectura como si fuera un mapa de madurez. Dieciséis meses antes, en septiembre de 2024, Anthropic había publicado un método distinto para el mismo problema. Consistía, en vez de multiplicar el índice, en anteponer a cada fragmento un contexto breve que lo sitúa en su documento, generado antes de indexarlo. Ojo al matiz, que un resumen genérico del documento les dio mejoras muy limitadas. Combinado con búsqueda léxica, su técnica redujo un 49% los casos en que el fragmento pertinente no aparecía entre los 20 primeros. Con reordenamiento posterior encima, un 67% Fuente primaria ↗.

Son dos respuestas distintas al mismo síntoma, publicadas con dieciséis meses de diferencia. Ninguna de las dos aparece como caja en el diagrama de tres columnas. La caja de recuperación no cambia de aspecto entre columnas. Por dentro puede haber un único tamaño fijo o varios índices fusionados. El diagrama no distingue entre las dos cosas, y es justo ahí donde vive el número que cambia.

Tampoco se explica sola la caja de autoevaluación de la columna agéntica. Un agente que revisa su propia recuperación antes de responder no da una segunda opinión, porque es el mismo criterio que decidió qué buscar, comprobando si le convence lo que encontró. En el expediente 09 conté que un segundo agente puede darte la razón por nada. Aquí el problema es más pequeño, un solo agente mirándose al espejo, pero abre la misma pregunta. ¿Qué objeción externa podía cambiar la respuesta, y llegó a tenerla?

Lo que queda abierto

Los propios autores dejan sin cerrar cuántos tamaños hacen falta y cuáles. En la charla donde lo presentaron admiten que la elección de tamaños fue bastante arbitraria y que todavía no saben calcular cuántas copias necesitas Fuente primaria ↗. También reconocen que Reciprocal Rank Fusion ganó a las alternativas que probaron, no que sea el mejor método posible que existe.

Y queda abierta la pregunta que a un despacho le importa antes que ninguna otra. Cuando un proveedor enseña un diagrama de tres columnas y pide presupuesto para pasar de la primera a la tercera, ¿qué recall gana con ese salto, medido en tu corpus y con tus preguntas? No en el suyo. Ninguna de estas fuentes compara columnas entre sí. Esa medida le toca a quien vende el salto.

Declaración de interés. Uso sistemas de recuperación en herramientas propias de mi despacho, así que esta pregunta también va conmigo.

Tu proveedor dibujó tres arquitecturas con una flecha de progreso entre ellas. Ninguna dice qué tamaño de fragmento usa, ni cuánto recall pierdes por no preguntarlo.

Lo que me preguntan cuando cierro el portátil.

¿Qué es el chunk size en un sistema RAG?

Es el tamaño en el que se divide un documento antes de guardarlo en una base de datos vectorial, medido en tokens. Se decide en la fase de indexado, antes de que exista ninguna pregunta, y normalmente se fija una vez para todo el sistema.

¿Por qué no hay un chunk size correcto?

Porque depende de la pregunta, no del documento. AI21 Labs indexó los mismos corpus con seis tamaños distintos y ningún tamaño fijo ganó en todos los casos. En sus ejemplos, las preguntas puntuales rinden mejor con fragmentos pequeños y las que necesitan contexto amplio, con fragmentos grandes.

¿Qué es Reciprocal Rank Fusion?

Es un método para combinar varias listas de resultados ordenados en una sola, dando más peso a lo que aparece bien situado en más de una lista. AI21 lo usa para fusionar las búsquedas hechas contra el mismo corpus indexado a distintos tamaños de fragmento, sin tener que comparar fragmentos de tamaños distintos entre sí.

El expediente detrás del artículo.

Chunk size is query-dependent: a simple multi-scale approach to RAG retrieval ↗Niv Granot, AI21 Labs · blog técnico, 29 de enero · 2026
Publicación de investigación aplicadaStop Chunking Like It's 2022 ↗Yuval Belfer, AI21 Labs · AI Engineer World's Fair, track Search & Retrieval, 30 de junio · 2026
Charla de conferenciaIntroducing Contextual Retrieval ↗Anthropic · Engineering, 19 de septiembre · 2024
Publicación técnica

Fuentes consultadas hasta el 1 de octubre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.

Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.