Deje de enviar cada página a un modelo de visión: lecciones de investigadores de Citigroup, EY y NVIDIA

Cuando los equipos de ingeniería construyen pipelines de documentos para la Generación Aumentada por Recuperación (RAG), la conversación se convierte casi de inmediato en un duelo entre modelos. ¿Debería llamar a Gemini 3.1 Pro? ¿Enrutar páginas a Mistral OCR v3? ¿Utilizar un modelo compacto como Granite-Docling?

Un artículo de Abbas Raza Ali (Citigroup), Muhammad Ajmal Siddiqui (Ernst & Young) y Moona Zahid (NVIDIA), titulado Smart Content Ingestion for Generative AI Workloads, aporta una fría dosis de realidad de producción a este debate. Publicado como preprint el 5 de octubre de 2026, se encuentra en revisión para MLSys 2027.

Al presentar mediciones sobre un corpus interno de 180 documentos que abarcan 10.507 páginas, los autores destacan dos cifras que deberían orientar el diseño de su arquitectura de ingesta:

1. Alrededor del 77 % del tiempo real de extracción (wall-clock time) se destinó al preprocesamiento compartido en la configuración más rápida. La mejora de imágenes y el análisis sintáctico de la maquetación (layout parsing) consumieron aproximadamente 2.062 segundos, en comparación con los 611 segundos de inferencia de Mistral OCR. En la configuración más lenta, la inferencia de Granite-Docling tomó cerca de 1.350 segundos, dejando el preprocesamiento en torno al 60 % del tiempo total de extracción.
2. Alrededor del 92 % de las páginas tomaron la ruta de extracción nativa. De 10.507 páginas, 853 superaron el umbral de área de imagen del sistema para el OCR a nivel de página. Las 9.654 páginas restantes siguieron la vía nativa con un coste de modelo prácticamente nulo, aunque las figuras extraídas aún podían activar el subtitulado por visión (vision captioning).

Si canaliza cada documento íntegramente hacia una API de visión, esta arquitectura sugiere una alternativa: extraer primero el contenido directamente accesible y reservar el OCR a nivel de página para las páginas predominantemente visuales. La ingesta de documentos no es solo un ejercicio de ingeniería de prompts. El artículo la aborda como un pipeline de sistemas de cuatro etapas en el que los errores de procesamiento upstream pueden privar a la recuperación downstream de la información que necesita.

La capa de percepción de los sistemas agénticos

En el aprendizaje automático tradicional, la preparación de datos era acotada y dependiente del esquema. Las tareas, las representaciones de datos, las etiquetas y las arquitecturas de modelos estaban estrechamente acopladas.

La IA generativa cambió esa relación. Los modelos fundacionales admiten múltiples tareas downstream mediante instrucciones y contexto en lenguaje natural. A medida que la parte del modelo se volvió más general, la parte de los datos planteó su propio desafío: el conocimiento empresarial reside en archivos PDF, presentaciones de diapositivas, hojas de cálculo, documentos escaneados, formularios, tablas y diagramas.

Estos archivos condensan información textual, visual, geométrica y estructural en un único artefacto. Si un parser de ingesta aplana un documento de dos columnas en líneas intercaladas o pierde las relaciones dentro de una tabla financiera, los componentes downstream reciben una representación dañada. Un recuperador vectorial no puede recuperar de forma fiable información ausente en su índice. Un modelo de reclasificación (re-ranker) no puede restaurar las alineaciones de columnas que la extracción descartó.

Los autores sitúan la extracción medida de contenido como la capa de percepción de los sistemas agénticos empresariales. Su argumento es que el razonamiento downstream depende de representar correctamente la fuente en esta frontera.

El artículo presenta una arquitectura de producción dividida en cuatro fases secuenciales:

• Fase 1: Extracción de contenido multimodal, que combina el enrutamiento selectivo de OCR con la extracción nativa heurística.
• Fase 2: Curación y evaluación de la extracción, mediante un muestreo multietiqueta priorizado por escasez (scarcity-first) para auditar los parsers frente a un ground truth.
• Fase 3: Chunking jerárquico (padre-hijo) consciente de la estructura, desacoplando las unidades de recuperación de los contextos de lectura.
• Fase 4: Evaluación de recuperación de solo lectura, generando preguntas sintéticas fundamentadas para evaluar la recuperabilidad.

Tres principios de ingeniería rigen el diseño: la estructura antes que la semántica, nunca mutar lo que se mide y presupuestar las etiquetas.

Enrutamiento selectivo: Deje que PyMuPDF soporte el tráfico pesado

La clave de eficiencia fundamental en la Fase 1 es sencilla: extraer el contenido directamente accesible sin OCR y utilizar una heurística de área de imagen para enrutar las páginas predominantemente visuales a modelos de visión.

Para cada página de PDF entrante $p$, el sistema calcula una tasa de cobertura de área de imagen:

$$r(p) = \frac{A_{\text{img}}(p)}{A(p)}$$

Si el área total de imágenes incrustadas $A_{\text{img}}(p)$ supera el 80 % ($\tau_{\text{cov}} = 0.8$) del área total de la página $A(p)$, la página se enruta a OCR. De lo contrario, permanece en la ruta de extracción nativa impulsada por PyMuPDF.

En el conjunto de datos Orion de los autores, compuesto por 180 documentos, 853 de las 10.507 páginas (8,1 %) tomaron la ruta de OCR. El 91,9 % restante siguió la extracción nativa. Esta es una distribución de enrutamiento observada en Orion, no una estimación para documentos empresariales en general.

De forma independiente, el motor de curación aplica una prueba de dos señales al etiquetar páginas escaneadas:

$$s(p) = 1_{|T(p)| < \kappa ;\wedge; r(p) > \tau_{\text{cov}}}$$

Con $\kappa = 40$, una página debe tener menos de 40 caracteres extraíbles además de una alta cobertura de imagen para recibir la etiqueta de escaneada. Esto evita que una página con una fotografía grande y una capa de texto sustancial sea etiquetada erróneamente como escaneada durante la curación. No modifica la regla basada únicamente en el área que utiliza el enrutador de extracción.

Para las páginas con predominio de imágenes, el artículo describe una secuencia opcional de mejora: eliminación de bordes, estimación de ruido mediante la varianza laplaciana para seleccionar entre filtros gaussianos, bilaterales o de medias no locales (non-local means), ecualización adaptativa de histograma con limitación de contraste (CLAHE), máscara de desenfoque (unsharp masking) y escalado cúbico. Las páginas rasterizadas pasan luego a un back-end de OCR. La infraestructura de inferencia incluye gestión de reintentos y retroceso exponencial (back-off) para respuestas 429/5xx y renovación de tokens OAuth2 ante errores 401.

Reconstrucción determinista de la maquetación sin aprendizaje profundo

Para las páginas de texto nativo, la etapa de reconstrucción estructural evita el uso de modelos entrenados. En su lugar, se apoya en heurísticas deterministas:

• Calibración del tamaño de fuente: El extractor calcula el tamaño de fuente modal $f^$ en todo el documento, tratándolo como texto de cuerpo estándar. Los tamaños de fuente distintos que satisfacen $f \ge 1.12 f^$ se convierten en candidatos a encabezados. Estos tamaños se ordenan de forma descendente en niveles jerárquicos, hasta una profundidad configurada, para generar encabezados en Markdown.
• Supresión de encabezados y pies de página: El sistema inspecciona los bloques de texto dentro de los márgenes de la página, normaliza los dígitos para que "Page 4" y "Page 9" compartan una clave y descarta el contenido marginal coincidente que se repite en más del 50 % de las páginas.
• Detección de tablas en dos niveles: Las tablas con líneas se capturan mediante lines_strict en PyMuPDF. Cuando la estrategia de tablas se establece en auto, un detector de alineación de palabras también busca tablas sin bordes agrupando palabras en filas y organizando columnas mediante una tolerancia de alineación en el eje x. Un mecanismo de protección descarta la prosa dispuesta en columnas paralelas que se asemeje a una tabla.
• Conciliación con granularidad de línea: En lugar de descartar un bloque de texto completo que se superpone con una tabla detectada, este pipeline evalúa cada línea individualmente. Una línea solo se suprime si más del 50 % de su área se encuentra dentro del rectángulo de la tabla, preservando las oraciones cercanas que simplemente comparten un bloque de texto con un fragmento de la tabla.
• Desduplicación de imágenes rasterizadas: Las imágenes rasterizadas incrustadas de tamaño superior a $32 \times 32$ píxeles se desduplican mediante hashes MD5 y se representan mediante marcadores de posición de figuras como ## Figure-{page}.{n}. Los marcadores restantes activan el subtitulado por visión, con Gemma-3 y Llama-4-Scout entre los modelos mostrados en la arquitectura.

La salida de la Fase 1 es Markdown etiquetado que conserva marcadores explícitos de ### Page: N, tablas y figuras. La reconstrucción estructural nativa y el subtitulado por visión son partes diferenciadas de dicho proceso.

La trampa de la escasez: auditar la extracción cuando el 90 % de los datos es texto

Antes de canalizar el Markdown extraído hacia un modelo de embeddings, es necesario saber si el extractor funcionó realmente. Esto nos lleva a la Fase 2: curación de datos y evaluación de la extracción.

La evaluación de la extracción de documentos en repositorios empresariales se enfrenta a un persistente problema de muestreo. Si la mayoría de las páginas son texto plano, una muestra aleatoria puede dejar a las páginas escaneadas, diagramas e infografías con muy pocos ejemplos para estimar la calidad de la extracción. Las modalidades poco frecuentes requieren una representación deliberada en el conjunto de evaluación.

Los autores formalizan esto como un problema de cobertura con múltiples etiquetas por página. Su taxonomía incluye las categorías Scanned, Text, Table, Diagram, Graph/Infographic y Photo/Signature.

Dadas las cuotas objetivo $t_m = \lceil \phi_m N \rceil$ para cada modalidad dentro de un presupuesto total de $N$ páginas, el Algoritmo 1 aplica una heurística voraz (greedy) orientada primero a la escasez:

1. Ordenar las modalidades en orden ascendente según su cuota objetivo. Este orden sigue las cuotas configuradas, no necesariamente su frecuencia observada en el corpus.
2. Para la modalidad activa, clasificar las páginas candidatas según una puntuación de utilidad: la cantidad de otras cuotas aún no cubiertas que la página también satisface.
3. Seleccionar páginas mientras esa modalidad tenga una cuota no cubierta y queden candidatos, actualizando los déficits en todas las etiquetas coincidentes.
4. Completar con páginas no seleccionadas o recortar las selecciones de baja utilidad para alcanzar el presupuesto de páginas y, a continuación, reportar la cobertura objetivo frente a la alcanzada.

El método es una heurística, no una garantía de que se pueda cumplir cada cuota. Las páginas seleccionadas pueden exportarse como archivos PDF independientes de una sola página o como documentos fuente completos cuando el contexto es relevante. Un libro de cálculo de seis hojas registra la configuración, las selecciones, las estadísticas y la distribución alcanzada. Posteriormente, se lleva a cabo la digitalización del ground truth y la validación humana sobre la muestra.

Puntuación de la fidelidad de texto y tablas

El entorno de evaluación normaliza el texto mediante Unicode NFKC, conversión a minúsculas (case-folding), unificación de puntuación y ligaduras, eliminación de Markdown y HTML y colapso de espacios en blanco. Calcula la Tasa de Error de Caracteres (CER) y la Tasa de Error de Palabras (WER) mediante la distancia de Levenshtein, junto con precisión, exhaustividad (recall), F1, F1 sobre bolsa de palabras (bag-of-words F1), BLEU-4 suavizado y una razón de longitud $(|\hat{c}| / |c|)$.

Esa razón señala una posible sobreproducción o pérdida de contenido. Por sí sola, no determina si el texto adicional es una duplicación o una alucinación.

Para las tablas, el evaluador añade una comparación estructural utilizando la Similitud basada en Distancia de Edición de Árboles (TEDS). Las tablas con barras verticales (pipe tables) y en HTML se analizan en cuadrículas rectangulares y se modelan como árboles (table -> row -> cell). La similitud reportada adopta la forma:

$$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

Esto mide la organización de la tabla y, en el modo sensible al contenido que se describe, las diferencias entre las cadenas de texto de las celdas.

Finalmente, los back-ends se clasifican mediante una puntuación compuesta ($Q_m \in [0, 100]$):

$$Q_m = 100 \cdot \frac{\sum_j w_j \mu_{j,m}}{\sum_j w_j} \cdot \text{cov}_m$$

Las métricas están orientadas hacia la precisión y se combinan mediante pesos configurables. La variable $\text{cov}_m$ representa la fracción de archivos esperados para los cuales el modelo generó una salida. Los archivos faltantes reducen la puntuación proporcionalmente, penalizando de forma explícita a un motor que omite documentos difíciles.

El resultado es una puntuación de evaluación configurable, no un porcentaje absoluto de contenido extraído correctamente.

Chunking padre-hijo: fichas pequeñas dentro de carpetas grandes

La Fase 3 aborda el chunking. El artículo describe dos modos de fallo contrapuestos:

• Los fragmentos grandes (large chunks) pueden diluir la contribución de un pasaje relevante a un embedding. Bajo la aproximación de mean-pooling descrita en el artículo, una oración relevante aporta menos a medida que aumenta el número de oraciones.
• Los fragmentos pequeños (small chunks) pueden fragmentar una respuesta en partes que, de forma individual, resultan deficientes para la recuperación.

La arquitectura aborda este compromiso (trade-off) desacoplando la unidad de recuperación de la unidad de contexto.

Las unidades recuperadas son los hijos (children): fichas de índice focalizadas con un objetivo de 320 tokens y un límite para prosa normal de 512 tokens. Las unidades de contexto son los padres (parents): carpetas estructurales con un máximo configurado de 3.500 tokens. Estos no son límites incondicionales: las oraciones individuales excesivamente largas y las tablas o figuras atómicas se conservan íntegras, y una tabla o figura de gran tamaño también puede exceder el límite del padre.

Los hijos se procesan mediante embeddings con GTE, se normalizan con norma L2 y se indexan en FAISS utilizando un índice exacto de producto interno (IndexFlatIP). Los padres se almacenan en un mapa clave-valor de parent_id al texto del padre.

En el momento de la consulta, la búsqueda vectorial recupera las fichas hijas. Expandir un hijo hacia su padre almacenado requiere una única búsqueda $O(1)$. Dicha complejidad describe la búsqueda de contexto, no la búsqueda vectorial ni la consulta completa.

Document Markdown
       │
       ▼
[Parent Section Folder: configured maximum 3,500 tokens]
       │                                      (Key-Value Store)
       │
       ├──► Child Card 1: target ~320 tokens (FAISS Index)
       │      Optional prefix: "Doc > Section > Subsection (p.4)"
       │
       ├──► Child Card 2: target ~320 tokens (FAISS Index)
       │      Optional prefix: "Doc > Section > Subsection (p.4)"
       │
       └──► Child Card 3: whole atomic table (FAISS Index)

Las cuatro reglas de empaquetado

El empaquetado de oraciones dentro de pack_sentences() sigue cuatro reglas:

• Regla 1 (Presupuesto de tokens): Apuntar a aproximadamente 320 tokens utilizando el tokenizador de GPT-2, con un límite superior de 512 tokens para el empaquetado de prosa ordinaria.
• Regla 2 (Preservación de oraciones): Nunca cortar a mitad de una oración. Dividir por la puntuación conservando comillas y corchetes finales. Si una oración excede el límite superior, emitirla como un chunk aislado en lugar de truncarla.
• Regla 3 (Sin migajas / No crumbs): Si un grupo empaquetado queda por debajo del umbral mínimo de tokens, fusionarlo con las oraciones sin solapamiento del chunk anterior cuando el tamaño combinado respete el límite superior.
• Regla 4 (Tablas y figuras atómicas): Cuando el empaquetador encuentra una tabla o figura, descarga la prosa pendiente y emite la unidad estructural completa como un solo hijo, incluso cuando dicha unidad supere el presupuesto de tokens habitual.

Cuando un chunk se cierra porque la siguiente oración superaría el límite superior, el sistema traslada hasta 48 tokens de oraciones completas finales hacia el siguiente chunk.

Para añadir contexto posicional sin necesidad de una reescritura mediante LLM, unos rastros de navegación opcionales (breadcrumbs) anteponen al texto de embedding de cada hijo su dirección estructural: Document > Title > Section > Subsection (p.N). El texto original sin prefijos se conserva por separado para su visualización.

Auditoría de la recuperación: 25.050 preguntas con un evaluador de solo lectura

La Fase 4 cierra el ciclo con RetrievalEvaluator. Siguiendo el principio de nunca mutar lo que se mide, el entorno abre el índice mediante faiss.IO_FLAG_READ_ONLY. Reutiliza exactamente la huella digital (fingerprint) de embedding de GTE y la gramática de etiquetas de página empleadas durante la indexación.

El evaluador genera preguntas sintéticas fundamentadas mediante Mistral-Medium para páginas que contienen al menos un número mínimo configurado de tokens. Su prompt solicita preguntas factuales específicas y preguntas amplias que sinteticen el contenido de toda la página, exige JSON puro y prohíbe el conocimiento externo. Estas instrucciones restringen la generación; no demuestran de forma independiente que cada pregunta generada sea válida.

Cada pregunta se transforma en embedding con GTE y se busca dentro de su documento de origen utilizando IDSelectorBatch de FAISS, con un mecanismo de respaldo (fallback) de filtrado exhaustivo cuando el soporte de selectores no está disponible. Los hijos recuperados se desduplican por parent_id, conservando el hijo con mayor puntuación por cada padre. La búsqueda recupera candidatos en exceso (over-fetching) para permitir la devolución de distintos padres.

Se registra un acierto (hit) si el hijo candidato supera un umbral de similitud coseno $s(q, c) \ge \theta$ y su página de origen se encuentra a una distancia máxima de una página ($\delta = 1$) respecto al origen de la pregunta:

$$\text{hit}(q, c) = 1_{s(q, c) \ge \theta ;\wedge; |\pi(c) - \pi(q)| \le \delta}$$

En el corpus Orion, el evaluador generó y evaluó 25.050 preguntas en 180 documentos:

• hit@1: 68.58%
• hit@3: 82.30%
• hit@5: 87.66%
• hit@10: 92.77%
• Mean Reciprocal Rank (MRR): 0.7745
• Median Rank: 1.0 (Mean Rank: 1.81)
• Preguntas no encontradas en ninguno de los rangos evaluados: 1.810 (7.2%)
• Latencia media por consulta (Mean Per-Query Latency): 0.81 segundos, reportada como dominada por llamadas remotas de embeddings

Más de dos tercios de las preguntas cumplieron el criterio de acierto del evaluador en el primer padre devuelto. Al considerar diez padres distintos, esa proporción alcanzó el 92.77%.

Estos son resultados basados en una aproximación (proxy) de recuperación. El criterio evalúa la similitud y la proximidad de páginas, no una sección de destino exacta etiquetada independientemente ni la corrección de una respuesta generada. Dado que la búsqueda se restringe al documento de origen, las cifras tampoco miden la localización del documento correcto en todo el corpus.

El benchmark de extracción: back-ends más grandes frente a modelos compactos

Los autores presentan puntuaciones de extracción para cuatro back-ends de producción. Sus mediciones provienen de los evaluadores propios del sistema sobre corpus internos; no constituyen una tabla de clasificación (leaderboard) pública e independiente.

Model	Composite Score ($Q_m$)	Character Error Rate (CER)	Word Error Rate (WER)	Table Similarity (TEDS)	Inference Time on Orion	Total Wall-Clock Time on Orion
Gemini 3.1 Pro	97.37	0.13%	0.13%	0.9952	No reportado por separado	No reportado por separado
Mistral OCR v3	95.98	1.39%	1.55%	0.9737	~611 s	2,672.67 s
Granite-Docling (258M)	92.92	2.60%	2.90%	0.9599	~1,350 s	3,411.86 s
SmolDocling (256M)	90.70	4.43%	4.82%	0.9274	No reportado por separado	No reportado por separado

Nota: Los totales de tiempo real de extracción (wall-clock) incluyen aproximadamente 2.062 segundos de preprocesamiento compartido, descrito como mejora de imagen y análisis sintáctico de la maquetación (layout parsing). El artículo sitúa a los otros dos back-ends entre los extremos temporales reportados sin detallar sus tiempos individuales.

Gemini 3.1 Pro lideró la clasificación de precisión reportada, registrando un CER del 0.13% y una puntuación TEDS de 0.9952.

Mistral OCR v3 finalizó en segundo lugar con una puntuación compuesta de 95.98. Su CER del 1.39% fue aproximadamente un orden de magnitud superior al de Gemini, al tiempo que ofreció el tiempo de extracción más rápido reportado. El componente de inferencia de su modelo tomó unos 611 segundos, en comparación con los cerca de 1.350 segundos de Granite-Docling.

Los modelos compactos, Granite-Docling y SmolDocling, quedaron por detrás de Gemini en aproximadamente 4.5 y 6.7 puntos compuestos. Sus CER reportados fueron del 2.60% y 4.43%, respectivamente; sus puntuaciones TEDS fueron de 0.9599 y 0.9274. Estos son resultados agregados del benchmark, no mediciones separadas sobre texto de cuerpo simple ni niveles específicos de dificultad de tablas.

El artículo también cita trabajos previos de detección de tablas mediante CNN y extracción de celdas con Encoder-Dual-Decoder que reportaban un 85% de precisión de palabras en tablas de imágenes. Esto aporta contexto histórico, pero los resultados suministrados no establecen una comparación con un conjunto de datos equiparable a partir de la cual calcular una mejora controlada con respecto a ese sistema anterior.

Por qué es importante: los verdaderos compromisos (trade-offs) para pipelines de documentos en producción

Si usted es un líder de ingeniería o un gestor de producto construyendo la ingesta de documentos para búsqueda empresarial o flujos de trabajo agénticos, este artículo ofrece varias lecciones operativas:

1. La llamada de OCR más económica es la que nunca se realiza

El enrutamiento selectivo mantuvo al 91.9% de las páginas de Orion fuera de la ruta de OCR a nivel de página. Ese es un resultado concreto que vale la pena contrastar con sus propios documentos.

No se trata de una reducción medida del 91.9% en el coste total. La extracción nativa sigue conllevando costes de procesamiento, y el subtitulado de figuras todavía puede invocar modelos de visión. El artículo no proporciona precios por página ni una comparación de facturación de antes y después. La lección fundamentada es más acotada: el texto directamente accesible no tiene por qué someterse automáticamente a OCR a nivel de página.

2. El preprocesamiento compartido merece un lugar en su presupuesto de latencia

La Figura 4 visibiliza los tiempos de extracción: aproximadamente 2.062 segundos se destinaron a la mejora compartida de imágenes y al análisis sintáctico de la maquetación, frente a los 611 segundos de inferencia de Mistral OCR.

Eso sitúa el preprocesamiento en cerca del 77% del tiempo real de extracción en la configuración más rápida y alrededor del 60% en la más lenta. Los autores lo identifican como el próximo objetivo de optimización.

Las mediciones no determinan la utilización de la CPU, la ejecución en serie ni la aceleración que aportaría un cambio específico en el multiprocesamiento o en los filtros de imagen. No obstante, sí demuestran por qué elegir el back-end de OCR más rápido deja intacta una parte sustancial del tiempo de extracción.

3. La tasa de error de caracteres es solo una parte de la calidad de extracción

Una puntuación textual no ofrece un balance completo de la fidelidad de las tablas. El artículo evalúa ambos aspectos, combinando métricas a nivel de carácter y palabra con la estructura de la tabla y métricas relativas a las celdas.

Al comparar extractores, mantenga esa distinción. TEDS aporta evidencia estructural junto con el CER y el WER; la puntuación compuesta combina estas señales, pero no debería ocultarlas.

4. Separe sus fichas de recuperación de sus ventanas de contexto

La arquitectura padre-hijo del artículo ofrece una vía concreta para hacer coincidir pasajes reducidos devolviendo al mismo tiempo un contexto más amplio. Las etiquetas estructurales mantienen intactas tablas y figuras, y los breadcrumbs opcionales añaden la posición en el documento al texto objeto de embedding.

La ejecución sobre Orion demuestra que este diseño puede evaluarse a escala. No incluye una comparación de recuperación controlada que demuestre que el chunking padre-hijo supere alternativas de tamaño fijo, semánticas u otras sobre el mismo corpus.

Dónde encuentra sus límites el sistema

Los autores describen el sistema como listo para producción, pero la evidencia respalda varias delimitaciones sobre cómo interpretar sus resultados:

• Dependencia de preguntas sintéticas: Las mediciones de recuperación utilizan preguntas generadas por Mistral-Medium. El artículo señala explícitamente que esta aproximación (proxy) depende de la calidad del generador. No reporta validación frente a un conjunto de consultas de usuarios reales.
• Aciertos basados en páginas y acotados al documento: La búsqueda se realiza dentro del documento de origen de la pregunta, y el éxito depende de la similitud y la proximidad de páginas. Estos resultados no acreditan la selección de documentos en todo el corpus ni la corrección de las respuestas.
• Evaluación interna y comparaciones limitadas: Las puntuaciones reportadas son automediciones sobre corpus internos. El artículo no presenta una ablación del chunking ni una comparación controlada de recuperación frente a las estrategias alternativas que discute.
• Heurísticas de enrutamiento configurables: El umbral del 80% de área de imagen produce la distribución de enrutamiento reportada en Orion. El artículo no demuestra su precisión de enrutamiento en otras poblaciones de documentos, y la regla más estricta de etiquetado de páginas escaneadas pertenece a la curación más que al enrutamiento de extracción.
• La monitorización sigue siendo en parte una propuesta: El CER y el WER basados en referencias requieren ground truth. El artículo aborda señales sin referencia y estrategias de calibración, pero califica el fundamento de la monitorización como una hipótesis o línea futura en lugar de código de calibración implementado. Dichas señales no pueden reportar una tasa de error real por sí solas.

Conclusión principal

La ingesta de documentos merece mayor atención que un script de utilidad ensamblado una vez y olvidado. En el enfoque de los autores, constituye la capa de percepción de un sistema de IA generativa.

Al combinar el enrutamiento selectivo, la reconstrucción determinista de la maquetación, el chunking padre-hijo consciente de la estructura y evaluadores de solo lectura, el artículo presenta un método concreto para hacer que las decisiones de ingesta sean explícitas y medibles. Su mayor contribución radica en la conexión entre esos componentes y la evidencia que producen sobre sí mismos.

Antes de dedicar otra semana a ajustar prompts o probar modelos de reclasificación (re-ranking), examine con detenimiento su capa de ingesta. Si su parser pierde la información presente en la página, la recuperación downstream comenzará con un problema que tal vez no tenga forma de subsanar.