D-RAC: chunking de RAG 4 veces más barato planificando por IDs

D-RAC es la extensión a documentos de empresa de W-RAC, el framework de chunking del mismo equipo de Yellow.ai, y ataca el problema de coste donde vive: en los tokens de salida. En el chunking agéntico clásico, el LLM lee el documento y reescribe el texto en chunks semánticos; D-RAC convierte el documento a Markdown una sola vez con un modelo multimodal y, a partir de ahí, el LLM solo planifica: emite arrays de identificadores ([["h1","h2","p1","p2"], …]), nunca regenera texto fuente. Resultado declarado: −95,7% de tokens de salida en la etapa de chunking y un coste de esa etapa un 77,8-85,6% más bajo, con retrieval igual o mejor.

TL;DR

Verificado contra el paper (arXiv HTML v1, leído íntegro; 6/6 cifras clave cotejadas también con verificación automática): el corpus completo (236 documentos, 795 páginas de RAG-Multi-Corpus) se convierte y chunkiza en 72 minutos con cero errores, produciendo 1.748 chunks. La planificación de chunks del corpus entero: 541,8 s — un 14% del tiempo de conversión — porque el planner solo emite IDs, no texto.
Verificado (según los autores): frente al chunking agéntico, D-RAC reduce los tokens de salida de chunking de 270.454 a 11.714 (−95,7%, Tabla 9) y el coste de esa etapa de $2,815 a $0,624 con precios GPT-4.1 (−77,8%) y de $3,112 a $0,448 con Gemini 2.5 Pro (−85,6%) (Tabla 10). En retrieval, D-RAC iguala o supera al chunking agéntico en las 7 métricas sobre 762 queries (R@6 0,798 vs 0,795).
El matiz: los tokens de salida son la palanca. El chunking agéntico gasta un 77-87% de su coste en output porque regenera el documento; D-RAC paga una conversión multimodal única (su propio coste, con Gemma-3 27B) y re-chunkiza barato para siempre: cambiar de estrategia de chunking solo re-paga segundos de llamadas de IDs.
Lo que me parece la señal real: lo transfieres sin publicar tu contenido a un vendor: la separación entre “convertir una vez” y “planificar N veces” es el patrón que cambia la economía de cualquier ingesta RAG pesada, igual que una caché de assets separa el build del serve.

El problema: el chunking agéntico paga dos veces por lo mismo

Si ya tienes un RAG en producción, esto te suena. El chunking agéntico promete chunks semánticos de calidad, y los entrega — pero el mecanismo es caro: un LLM frontier lee el documento y regenera el texto como chunks coherentes. Escribir es 4-8 veces más caro que leer (los precios publicados de GPT-4.1 y Gemini 2.5 Pro ponen el output a 4× y 8× el input). El paper atribuye un 77-87% del coste del chunking agéntico a tokens de salida (claim de los autores). Y hay un segundo coste silencioso: el texto que el LLM reescribe es texto que puede alterar — el chunking agéntico tiene superficie de alucinación dentro de tu índice; D-RAC tiene “muy baja o nula” según los autores, porque sus 11.714 tokens de salida son solo IDs validados contra la tabla de elementos.

El chunking agéntico paga dos veces por lo mismo: una por el texto de salida que regenera y otra por re-pagar esa regeneración cada vez que cambias de estrategia de chunking. D-RAC paga la conversión una vez y re-planifica por IDs.

Cómo funciona: cuatro etapas y una sola pasada multimodal

El pipeline real son 4 etapas (el “3 fases” que circula en resúmenes es una lectura rápida del abstract):

Normalización a PDF y render. Cualquier formato (DOCX, PPTX, XLSX, HTML, escaneos) se convierte a PDF con tooling determinista — la apuesta del paper es que “todo formato renderiza fielmente a PDF” — y cada página se rasteriza a 200 DPI con un tope de 1.568 px por lado. Sin LLM: 1-7 s por documento.
Conversión multimodal (la única pasada de LLM sobre el contenido). Las páginas, en lotes de 5, van a un LLM multimodal — en los experimentos, Gemma-3 27B vía AWS Bedrock — con reglas estrictas de salida orientada a retrieval: cada fila de tabla se reescribe como una frase autosuficiente con las cabeceras como contexto (sintaxis de tabla Markdown prohibida), filas distintas jamás se fusionan en frases del tipo “16 o 20 años”, logos y gráficos decorativos se omiten (nada de describirlos y meter caption alucinados en el índice), la jerarquía de encabezados se reconstruye y cada página marca con un comentario .
Parseo determinista y sectioning. El Markdown se trocea en elementos con ID (h1, h2…, p1, p2…) y los documentos grandes se parten recursivamente por cabeceras con un presupuesto de 60 elementos por llamada al planner.
Planificación de chunks por IDs. El planner recibe IDs, previews truncados a 200-400 caracteres y la cadena de cabeceras padre, y devuelve arrays de IDs agrupando 3-8 bloques por tema. La cobertura se verifica por código: todo ID de contenido aparece exactamente una vez; los olvidados caen en un chunk de fallback con sus cabeceras de sección. Los chunks se reconstruyen localmente mapeando IDs al texto convertido verbatim, prefijados con la cadena de encabezados.

El detalle que hace que el paso 4 sea barato: el planner no necesita el texto completo, solo señales de tema. Los previews truncados son la razón de que su input (265k tokens) sea incluso menor que el del baseline agéntico (326k).

Los números, con la letra pequeña

Sobre el subset PDF de RAG-Multi-Corpus (236 documentos, 795 páginas, 5 dominios ficticios: automoción, académico, cloud, enterprise-tech y banca). Primera letra pequeña: RAG-Multi-Corpus es un benchmark introducido por el propio equipo junto a W-RAC; no es una evaluación de terceros. Los costes de la Tabla 10 son una simulación con precios de lista de GPT-4.1 ($2,00/$8,00 por millón de tokens input/output) y Gemini 2.5 Pro ($1,25/$10,00), consultados por los autores a fecha del paper; los tokens se miden exactamente de los artefactos y el texto se convierte a tokens a 4 caracteres/token. La conversión del corpus se hizo con Gemma-3 27B — el coste de esa etapa no entra en la comparación de la tabla, que mira solo la etapa de chunking.

Métrica (etapa de chunking, corpus completo)	Chunking agéntico	D-RAC	Reducción
Tokens de salida	270.454	11.714	−95,7%
Tokens de entrada	325.855	264.954	−19% aprox.
Coste con precios GPT-4.1	$2,815	$0,624	−77,8%
Coste con precios Gemini 2.5 Pro	$3,112	$0,448	−85,6%
Tiempo de planificación/chunking	2.167,5 s (medido en W-RAC, mismo corpus)	541,8 s	−75%

Fuente: tablas 9 y 10 del paper (v1, 21-sep-2026). El desglose por modelo: agéntico $0,652 input + $2,164 output (GPT-4.1) y $0,407 + $2,705 (Gemini); D-RAC $0,530 + $0,094 y $0,331 + $0,117. Mira dónde está el dinero: en el output.

En escala, el test de estrés es un prospecto financiero de 503 páginas: 5.060 elementos planificados en 68,7 s con la conversión lineal — las páginas son independientes y no hay degradación superlineal.

Sobre la extrapolación de 1M de páginas (~$3.540 → ~$785 por re-index con GPT-4.1): es un cálculo de los autores, no una medición. La dirección es razonable — el ahorro se repite en cada re-index porque el re-chunking por IDs nunca re-paga la conversión — pero el número exacto depende de precios vigentes y de la mezcla de documentos.

Qué NO cambia y quién se lleva el gasto

Tres cosas que el titular no cuenta:

La conversión multimodal se paga aparte. El −77,8%/−85,6% es solo de la etapa de chunking. La pasada con Gemma-3 27B tiene su propio coste (el corpus completo: 72 minutos de conversión + planificación). La apuesta del paper es que se paga una vez por documento y el re-chunking es solo planificación; si re-indexas a menudo, ganas; si ingestas un documento y nunca lo tocas, el ahorro relativo baja.
El baseline lo define el vendor. El “agentic chunking” contra el que se compara es la referencia que distribuye el propio benchmark, y las métricas de retrieval son del equipo, sobre su benchmark. La dirección de los números es plausible (regenerar texto es objetivamente caro), pero ni el baseline ni el juez son independientes.
Sin implementación pública de D-RAC. Revisado el GitHub del primer autor a 27-sep-2026: están abiertos el benchmark (udayallu/RAG-Multi-Corpus) y un repo de W-RAC, pero no hay código del pipeline D-RAC. Las cifras no son reproducibles de forma independiente hoy. Es un preprint (v1, sin peer review) de un equipo de investigación de Yellow.ai, un vendor de RAG/agentes — interés comercial declarable en que el chunking “agéntico caro” sea el malo de la película.

La calidad en retrieval: igualar sí, “superar” con asterisco

Sobre 762 queries con ground truth de 4 organizaciones (la quinta no tiene queries anotadas), mismo embedder para todo (Titan Text Embeddings V2) y criterio de relevancia idéntico para los tres sistemas:

Sistema	R@6	R@3	P@3	MRR	NDCG@6
Fixed-size 1.000 chars (extracción PyMuPDF)	0,717	0,666	0,316	0,602	0,764
Chunking agéntico	0,795	0,726	0,316	0,682	0,793
D-RAC	0,798	0,743	0,321	0,690	0,801

Tabla 6 del paper. NDCG@3: 0,677 / 0,716 / 0,726. P@6: 0,203 / 0,197 / 0,199.

Tres lecturas honestas:

El mensaje real es “empata con el caro y aplasta al barato”. Las diferencias con el chunking agéntico son de centésimas (+0,003 en R@6): diría “iguala”, no “supera”. La mejora clara es contra el chunking por tamaño fijo sobre extracción cruda (R@6 0,717 → 0,798, +11,3% relativo), que es lo que tiene montada la mayoría.
Las mejoras grandes están donde el paper predice: queries temporales (R@6 0,85 vs 0,73 del fixed), comparativas (0,79 vs 0,72) y analíticas (0,61 vs 0,56) — las sensibles a los bordes de chunk y a las tablas. En las booleanas, el agéntico conserva ventaja (0,86 vs 0,82 de D-RAC): las preguntas sí/no castigan los chunks que mezclan varios hechos.
La normalización de tablas es la joya silenciosa. Convertir cada fila en una frase autosuficiente (y prohibir fusionar filas en “16 o 20 años”) ataca el modo de fallo clásico del RAG sobre PDFs: la celda sin su cabecera de fila/columna no significa nada para el embedder. Esta regla la puedes aplicar en tu pipeline de conversión pase lo que pase con D-RAC.

Cuándo gana y cuándo te da igual

Gana con claridad si: re-indexas a menudo o iteras la estrategia de chunking (cambiar tamaño objetivo, agrupación por entidades, políticas por tenant = re-planificar IDs, no reconversionar); tu corpus es pesado en tablas y manuales (pólizas, catálogos, tarifas); el corpus es grande y el coste de chunking te aparece en la factura mensual; o necesitas trazabilidad — chunks reconstruidos verbatim, plan de chunks inspeccionable, cero reescritura silenciosa.

Te da igual si: tu corpus es estable y pequeño (el ahorro no compensa montar el pipeline de 4 etapas); ya ingestas HTML/Markdown nativo (ahí W-RAC es el mismo concepto sin la etapa de conversión); o tus documentos son limpios y lineales, donde el chunking fijo barato sigue siendo suficiente.

No es un checkpoint de calidad gratis: si tu conversión multimodal alucina una fila o fusiona dos opciones de un plan de precios, el resto del pipeline es determinista hasta el final — y determinista propagando el error. La auditoría es más fácil (miras el Markdown convertido, artefacto persistido), pero la calidad se decide en la pasada 2.

Cómo medirlo en tu pipeline esta semana

Cuenta tus tokens de salida de chunking. Si tu chunker agéntico regenera texto, multiplica tokens de salida por tu precio de output: eso es lo que D-RAC dice comprimir un 95,7%. Con precios de output a $8-10/M, se hacen los números solos a partir de unos pocos miles de páginas.
Separa el coste de conversión del coste de chunking en tu contabilidad. El ratio del paper: la planificación total fue un 14% del tiempo de conversión. Si tu “chunking” cuesta más que tu conversión, estás pagando regeneración.
Mide retrieval antes y después con tu propio set de queries. El protocolo del paper es copiable: mismo embedder, mismo top-K, mismo criterio de relevancia para todos los sistemas, y un juez simple (porcentaje de palabras del hecho soporte presentes en el chunk). Sin eso, cualquier cifra de R@6 es decoración.
Adopta las reglas de conversión aunque no adoptes D-RAC: una frase autosuficiente por fila de tabla, prohibido fusionar filas, jerarquía explícita, imágenes decorativas fuera. Son gratis y atacan el peor modo de fallo del RAG sobre PDFs.

Enlaces y pieza relacionada

Paper: D-RAC (arXiv 2609.24220) — HTML v1 completo · discusión en HF Papers (67 upvotes a 27-sep-2026)
Benchmark: udayallu/RAG-Multi-Corpus · repo W-RAC · implementación de D-RAC: no pública a 27-sep-2026

Si el chunking es tu etapa cara, igual tu problema de fondo es el chunking de base: en RAG: qué funciona de verdad (patrones reales) tienes las cinco palancas con código, y la cara opuesta del coste — cuando el output de tu agente se dispara — está en AgentDiet: reducir el gasto en tokens de agentes de coding. Para decidir qué modelo mueve cada etapa (conversión multimodal incluida), routing multi-modelo: cómo elegir el LLM correcto por tarea y, si tu RAG come documentos corporativos, qué pasa cuando el contenido del índice es atacable: memoria de agentes e IA: envenenamiento de RAG y memorias en conflicto.