Por qué el CER Engaña en los VLMs de Análisis de Documentos Cuantificado con Datos de Benchmark Propios (2026)
Última revisión: 2026-08-18 · Nivel de ejecución: oficial · Benchmark propio · 8 motores × 2 conjuntos de datos de recibos
Qué cubre esta página: Una cuantificación propia y reproducible de cómo y en qué medida la Tasa de Error de Caracteres (CER) engaña al comparar motores OCR tradicionales con modelos de lenguaje visuales para análisis de documentos (VLMs) — el mecanismo de dos capas (normalización de la salida del VLM, luego inflación de la estructura del texto de referencia), las inversiones de ranking CER-vs-F1 de campo medidas, y las métricas que se mantienen justas a través de la frontera familiar. Cifra trazable a una fila CSV publicada en el repositorio público de benchmark OCR (ImageToTableai/benchmark-ocr); las cifras de descomposición del CER ~76%/~18%/~10% son estimaciones del análisis del protocolo de benchmark, no columnas CSV, y se etiquetan como tales donde aparecen. Qué NO cubre esta página: La diferencia definicional entre precisión a nivel de carácter y a nivel de campo — eso está en la página de definición complementaria Precisión a Nivel de Campo vs. a Nivel de Carácter; esta página es la capa de datos que cuantifica la brecha. No se miden facturas, formularios ni documentos largos — solo recibos (SROIE 2019 inglés, CORD v2 indonesio), un nivel de GPU (RTX 4090), versiones de modelo de agosto de 2026.
Declaración de alcance: Mecanismo ilustrado en recibos (SROIE 2019 inglés, 361 muestras de prueba; CORD v2 indonesio, 100 muestras de prueba) usando los datos de benchmark propios. La descomposición del CER ~76%/~18%/~10% es una estimación derivada de la nota del protocolo, no una columna CSV. CORD nunca se fusiona en el ranking de SROIE — diferente idioma, diferente estructura de texto de referencia.
La Tasa de Error de Caracteres es un algoritmo de coincidencia de caracteres exactos, no un medidor de calidad: cobra un error por cada carácter que difiere del texto de referencia. En este benchmark, esa convención de puntuación por sí sola — antes de cualquier error genuino de lectura — mueve motores entre la parte superior e inferior del ranking: Unlimited-OCR obtiene la peor CER (0.6552) y la 2ª mejor CER (0.1971) y la Los tres números que más necesitan los redactores: ~18% del presupuesto de CER de un VLM en SROIE son solo sustituciones de mayúsculas/minúsculas (estimación derivada del protocolo) — pasar TAN CHAY YEE a tan chay yee se puntúa como errores aunque el valor del campo sea correcto; 0.3412 es la mejor del benchmark; y la inversión
~18%
Porción del presupuesto de CER de SROIE de un VLM atribuida a sustituciones de mayúsculas/minúsculas en el análisis de descomposición de errores del benchmark — los caracteres son correctos, solo se normalizan las mayúsculas/minúsculas (estimación derivada del protocolo de las notas de análisis del benchmark, no una columna CSV)
1.0805
CER de CORD de PaddleOCR-VL — el peor de los 8 motores en una métrica que incorpora la estructura de anotación en el texto de referencia; el F1 de campo regex de CORD del mismo motor (0.3412) es el mejor del benchmark (summary_metrics.csv, cer / field_f1_regex, fila paddleocr_vl_vllm/cord_v2)
0.6552 ↔ 0.3376
CER de Unlimited-OCR (el peor de 8) versus su F1 de campo regex (el mejor de 8) en los mismos recibos SROIE — la inversión de ranking más pronunciada del benchmark (summary_metrics.csv, cer / field_f1_regex, fila unlimited_ocr/sroie_2019)
CER es un algoritmo de puntuación por coincidencia exacta, no un medidor de calidad
CER es la distancia de edición de Levenshtein entre el texto reconocido y el texto de referencia — el número mínimo de inserciones, eliminaciones y sustituciones de caracteres necesarias para convertir uno en el otro, dividido por la longitud del texto de referencia (la definición formal está publicada en la especificación de evaluación OCR-D). Cuenta diferencias y no puede distinguir una mala lectura de un reformateo legítimo. Cuando la convención de salida de un motor difiere del texto de referencia — mayúsculas/minúsculas, separadores, orden de líneas — CER penaliza comportamientos que no son en absoluto una mala lectura.
Los motores OCR tradicionales (Tesseract, PaddleOCR, EasyOCR, docTR) emiten flujos de caracteres crudos que preservan el formato original y el diseño de líneas, por lo que su convención de salida se acerca al texto de referencia y CER mide algo cercano a un error de lectura genuino. Los VLM de análisis de documentos (Surya2, Unlimited-OCR, PaddleOCR-VL) emiten texto interpretado: aplican normalización de mayúsculas/minúsculas (TAN CHAY YEE se convierte en tan chay yee), fusión etiqueta/valor (INVOICE NO\n: PEGIV se convierte en Invoice No : PEGIV) y reordenamiento de líneas — las convenciones de salida de un lector, no de un escáner. Cada caso normalizado y línea fusionada es una penalización por distancia de edición, incluso cuando el valor del campo subyacente es correcto.
El análisis de protocolo del benchmark de las predicciones SROIE publicadas descompone el presupuesto de CER crudo de un VLM aproximadamente en ~76% de caracteres idénticos al texto de referencia, ~18% de sustituciones de mayúsculas/minúsculas y ~10% de fusiones de líneas / separadores omitidos — con los valores de campo reales (empresa, total, fecha, dirección) correctos. Esta descomposición es una estimación derivada del protocolo de las notas de análisis del benchmark, no una columna CSV; trate la división como orientativa, no precisa. La dirección es lo que importa: la normalización de mayúsculas/minúsculas por sí sola puede explicar una gran parte del "mal" CER de un VLM en recibos de inglés limpios.
Dos filas CSV hacen visible el mecanismo sin ninguna descomposición. Unlimited-OCR puntúa CER 0.6552 pero WER 0.4779 en SROIE — sus caracteres parecen distorsionados mientras sus palabras sobreviven, porque la normalización de mayúsculas/minúsculas reemplaza caracteres sin romper palabras (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019 row). Y el VLM que menos normaliza, Surya2, puntúa CER 0.1915 — el mejor CER crudo en toda la ejecución de 8 motores, indistinguible de un motor tradicional fuerte (summary_metrics.csv, cer, surya2/sroie_2019 row). Lo que la columna CER mide principalmente es la convención de salida del VLM, no su capacidad de lectura.
La Prueba Está en las Inversiones: CER y F1 de Campo Discrepan
El ranking de CER del benchmark y su ranking de extracción de campos discrepan materialmente. Si se clasifican los ocho motores por CER de SROIE, el ganador es Surya2 (0.1915); si se clasifican por F1 de campo con regex — la métrica que se aproxima a lo que consume un pipeline de producción — el ganador es Unlimited-OCR (0.3376), el motor que el CER clasifica en el último lugar. Una de las dos columnas no está midiendo lo que los sistemas descendentes realmente consumen.
F1 de campo es la media armónica de precisión y exhaustividad sobre los valores de campo extraídos (empresa, fecha, dirección, total en SROIE): un campo es una unidad binaria — coincide o falla. La columna de regex aplica el mismo conjunto de patrones fijos al texto de cada motor, por lo que la única variable es la salida del motor. La tabla siguiente empareja el CER de cada motor con su F1 de campo con regex en los mismos 361 recibos, con el rango de cada motor bajo ambas métricas.
Fuente: summary_metrics.csv — columnas cer y field_f1_regex, filas sroie_2019 (361 muestras por motor, error_rate 0.0 para los 8). Las dos series no son comparables entre sí en magnitud (unidades diferentes), pero sus rankings discrepan, que es el punto.
Tabla: summary_metrics.csv — columnas cer / wer / field_f1_regex, filas sroie_2019. Los rankings se calcularon dentro de las 8 filas de esta tabla (1 = mejor bajo esa métrica: CER más bajo, F1 de campo más alto). Estas son métricas postprocessed_sroie_receipt_regex_*: patrones fijos aplicados al texto OCR de cada motor, no salida estructurada nativa. Tesseract se ejecutó solo en CPU (compute_type=cpu).
Lee explícitamente los dos pares de inversión. Unlimited-OCR: peor CER (0.6552), mejor F1 de campo (0.3376) — el motor que la métrica de OCR bruto clasifica último es el motor que la lente de campo clasifica primero. docTR: 2do mejor CER (0.1971), peor F1 de campo (0.0766) — perfecto en texto, falla en campos. PaddleOCR-VL también se invierte en el margen (CER rango 6, campo rango 2), mientras que las dos filas alineadas (PaddleOCR 3ro/3ro, Tesseract 5to/5to) son ambos motores tradicionales cuya convención de salida de texto bruto es exactamente lo que el CER fue diseñado para puntuar. Clasificar motores solo por CER da un ganador diferente que clasificar por lo que el consumo de producción necesita — la inversión es la demostración, no una anomalía.
La Métrica de Campo es la Lente Confiable entre Familias
Ejecuta el texto bruto de cada motor a través del mismo postprocesador de extracción de campos por LLM (deepseek-v4-flash, temperatura 0) y los seis motores con texto OCR utilizable convergen a 0.57–0.62 F1 de campo — la frontera familiar VLM-vs-tradicional que la clasificación por CER hace parecer enorme (0.19 a 0.66) casi desaparece. Dos motores caen por debajo del rango: EasyOCR en 0.3717 y Tesseract en 0.4389. La métrica de campo separa motores por lo que realmente importa — la recuperación de campos posteriores — y lo hace de manera consistente a través de la frontera familiar.
Este es el mismo conjunto de motores que la tabla de CER anterior, re-puntuado solo en la dimensión de campo: la inversión de CER entre Unlimited-OCR y docTR ha desaparecido, porque la recuperación de valores de campo es lo que el pipeline consume. El mecanismo es que el postprocesador absorbe las diferencias de convención de salida que el CER castigó — lee el texto normalizado de mayúsculas/minúsculas y con fusión etiqueta/valor y extrae los valores. El F1 de campo por LLM aquí es la columna llm_field_value_f1 de la comparación de métodos del benchmark, con el modelo LLM registrado por fila.
Tabla: field_method_comparison.csv — columna llm_field_value_f1, filas sroie_2019, llm_model=deepseek-v4-flash. La columna CER se repite de summary_metrics.csv solo para referencia cruzada. La “banda de convergencia” es el rango observado de 0.5685–0.6171 de los seis motores con texto utilizable; las dos filas por debajo de la banda se indican como observaciones, no como una clasificación de los motores.
CORD Añade una Segunda Capa de Inflación: Estructura del Texto de Referencia
El texto de referencia publicado por CORD (gt_text) incrusta estructura de anotación — etiquetas de campos, entradas de menú y coordenadas — en lugar de texto visible puro. El CER calcula la distancia de edición contra esa cadena estructuralmente aumentada, por lo que el CER de CORD de cada motor está sistemáticamente inflado antes de considerar incluso un error de lectura. El resultado: los ocho motores se agrupan en CORD CER 0.90–1.08 — un rango comprimido inútilmente que dice casi nada sobre la calidad del texto.
El artefacto extremo es el CORD CER de PaddleOCR-VL de 1.0805, el peor de los 8 motores — no una lectura de su calidad de texto sino la inflación estructural que más afecta a la salida más limpia y corta, que tiene la mayor distancia de edición relativa al texto de referencia de CORD cargado de estructura. En la lente de campos, el mismo motor obtiene el
Fuente: summary_metrics.csv — columnas cer y field_f1_regex, filas cord_v2 (100 muestras por motor). El CORD CER no es comparable entre familias ni siquiera entre motores — el texto de referencia incrusta estructura de anotación, por lo que el CER mide la distancia a una cadena estructuralmente aumentada, no al texto visible.
Tabla: summary_metrics.csv — columnas cer / field_f1_regex, filas cord_v2. CORD no se fusiona en ninguna clasificación de SROIE (regla de protocolo): la estructura del texto de referencia infla el CER para cada motor, y los patrones regex se escribieron para formatos en inglés. Las métricas de campo son la única lente justa para CORD. Ordenado por F1 de campo, no por CER — el punto es que la columna CER no aporta señal de ordenación.
La lente de campo invierte la tabla de CORD por completo. El motor con el peor CER de CORD del benchmark (PaddleOCR-VL, 1.0805) tiene el mejor F1 de campo de CORD (0.3412); el F1 de campo de docTR es literalmente 0.0000 — nada extraído — mientras que su CER de CORD (0.9101) se sitúa en el centro del grupo y no dice nada al respecto. En CORD, publicar el CER sin las métricas de campo no solo no es informativo; clasifica activamente los motores en el orden incorrecto.
Cuándo es CER la métrica correcta
CER sigue midiendo algo real — la reproducción exacta de caracteres — y es la métrica correcta siempre que el consumidor downstream necesite texto literal, no campos. La conclusión de esta página es “CER induce a error en la comparación entre familias de salidas de estilo VLM,” no “CER siempre es incorrecto.”
Dentro de la familia de OCR puro, CER conserva su valor. Los motores tradicionales emiten texto crudo con formato y mayúsculas preservados, por lo que CER mide la calidad de lectura genuina: la columna CER del motor tradicional en este benchmark (0.1971–0.3347 en SROIE) rastrea su rendimiento en campos mucho más de cerca que para los VLMs (correlación de rango con F1 de campo por regex: PaddleOCR y Tesseract están exactamente alineados en 3er/3er y 5to/5to).
Casos de uso de texto literal. Los consumidores downstream de coincidencia exacta — búsqueda de texto completo que debe encontrar una cadena literal, registros de auditoría que reproducen los caracteres de un documento, o verificaciones de paso/fallo contra una secuencia de caracteres requerida — consumen caracteres, no campos. Para ellos, la reproducción exacta de caracteres (CER) es la medida fiel y el F1 de campo es la lente equivocada.
Regla práctica de publicación. Cuando publique un número de CER, indique tanto la convención de salida del motor (¿normaliza mayúsculas? ¿fusiona etiquetas? ¿reordena líneas?) como la construcción del texto de referencia (texto visible puro, o anotación aumentada como el gt_text de CORD). Si cualquiera de los dos es desconocido, el número no es portable entre motores o conjuntos de datos.
La regla de límite de este benchmark. CER es justo dentro de la familia de OCR puro e injusto a través del límite entre OCR tradicional / VLM de análisis de documentos; el F1 a nivel de campo (postprocesado por regex o LLM) es justo en ambos. Use CER para calidad de texto crudo dentro de la misma familia, F1 de campo para comparación entre familias — y siempre informe la advertencia de descomposición para las filas de VLM.
Preguntas Frecuentes
¿Por qué es engañoso el CER al comparar motores OCR y VLM?
Porque el CER es una puntuación de distancia de edición exacta por caracteres, y los VLM de análisis de documentos deliberadamente no reproducen los caracteres exactamente — normalizan mayúsculas/minúsculas, fusionan líneas de etiqueta/valor y reordenan el texto. Cada una de esas normalizaciones se puntúa como un error incluso cuando el valor del campo es correcto. En esta comparativa, Unlimited-OCR obtiene el peor CER en SROIE (0.6552) mientras tiene el mejor F1 de campo con regex (0.3376) en los mismos 361 recibos (summary_metrics.csv, cer / field_f1_regex, unlimited_ocr/sroie_2019 row) — la clasificación por CER y la clasificación por campo eligen ganadores diferentes.
¿Es el CER todavía una métrica OCR útil?
Sí — dentro de la familia de OCR puro y para consumidores de texto literal. Los motores tradicionales (Tesseract, PaddleOCR, EasyOCR, docTR) producen flujos de caracteres sin procesar que el CER mide de manera justa: en esta comparativa, su CER en SROIE varía de 0.1971 a 0.3347 y sigue el rendimiento por campo (PaddleOCR 3º/3º, Tesseract 5º/5º en CER y F1 de campo). El CER es la métrica incorrecta cuando el motor normaliza su salida (estilo VLM) o cuando el texto de referencia incorpora estructura en lugar de texto visible (CORD).
¿Por qué los modelos OCR VLM tienen altas tasas de error de caracteres?
Principalmente por convención de salida, no por capacidad de lectura. El análisis del protocolo de la comparativa atribuye aproximadamente ~18% del presupuesto de CER de un VLM en SROIE a sustituciones de mayúsculas/minúsculas y ~10% a fusiones de líneas/separadores omitidos (estimación derivada del protocolo de las notas de análisis de la comparativa, no una columna del CSV) — mientras los valores de campo en sí son correctos. El CER de Unlimited-OCR de 0.6552 frente a un WER de 0.4779 muestra la firma: los caracteres se normalizan, las palabras sobreviven (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019 row).
¿Cuál es la mejor métrica para comparar motores OCR y VLMs de análisis de documentos?
F1 de campo — con postprocesamiento regex para un pipeline OCR puro, o con postprocesamiento LLM para ambas familias. En SROIE, el F1 de campo con LLM converge a seis motores en 0.57–0.62 independientemente de la familia (field_method_comparison.csv, llm_field_value_f1, filas sroie_2019), y el F1 de campo con regex es la única métrica que clasifica razonablemente la tabla CORD, donde el 0.3412 de PaddleOCR-VL es el mejor del benchmark (summary_metrics.csv, field_f1_regex, filas cord_v2). Siempre indique el postprocesador y la convención de salida junto con el número.
¿Por qué el CER de PaddleOCR-VL es tan alto en CORD pero su F1 de campo es el mejor?
Porque el texto de referencia de CORD incrusta estructura de anotación (etiquetas de campo, coordenadas, entradas de menú) en lugar de texto visible puro, y la salida de PaddleOCR-VL es la más limpia — la más corta, más normalizada — por lo que su distancia de edición a esa cadena con estructura aumentada es la mayor (CER 1.0805, el peor de 8). En la métrica de campo, el mismo texto extrae los campos de recibos indonesios con un F1 de campo de 0.3412, el mejor del benchmark (summary_metrics.csv, cer / field_f1_regex, fila paddleocr_vl_vllm/cord_v2). El CER de CORD es estructuralmente inutilizable para todos los motores; las métricas de campo son la única comparación justa de CORD.
¿Qué es la normalización de mayúsculas/minúsculas y por qué infla el CER?
La normalización de mayúsculas/minúsculas consiste en convertir todo el texto a un solo caso — TAN CHAY YEE se convierte en tan chay yee. El CER compara caracteres exactamente, por lo que cada letra normalizada se cuenta como una sustitución contra las mayúsculas del texto de referencia, aunque el valor sea idéntico. En el análisis de protocolo de este benchmark, las sustituciones de caso representan aproximadamente ~18% del presupuesto de CER de un VLM en SROIE (estimación derivada del protocolo) — por lo que un VLM puede leer un recibo perfectamente y aun así reportar un CER que parece el de un modelo que falla.
¿Debo comparar motores OCR por CER o por F1 a nivel de campo?
Por F1 a nivel de campo para cualquier comparación que involucre motores OCR tradicionales y VLM — porque su canalización consume campos, no flujos de caracteres, y porque el CER se infla sistemáticamente para la salida normalizada de VLM y el texto de referencia con estructura aumentada. Use CER solo dentro de la familia de OCR puro o cuando el consumidor downstream necesite texto literal (búsqueda, auditoría, coincidencia exacta). Las dos métricas discrepan notablemente en este benchmark: el CER clasifica a docTR 2º y Unlimited-OCR 8º; el F1 de campos por regex clasifica a docTR 8º y Unlimited-OCR 1º (summary_metrics.csv, filas de sroie_2019).
¿De dónde vienen estos números de CER y F1 de campo?
Esta página reporta la dimensión de equidad de métricas de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros. Solo divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/fecha/total, CC-BY-4.0) y CORD v2 test (100 recibos indonesios, campos anidados menú/sub_total/total, CC-BY-4.0); las divisiones de entrenamiento nunca se evaluaron. Ocho motores ejecutados sin configuración, sin ajuste fino, bajo el protocolo congelado reports/receipt_v1_official_protocol.md (calentado y puntuado, solo nivel oficial). Las 16 ejecuciones puntuadas completadas con error_rate 0.0 (columna error_rate de summary_metrics.csv). Los datos se recopilaron en agosto de 2026.
Entorno de Ejecución
Hardware: todas las ejecuciones en GPU se realizaron en una única NVIDIA RTX 4090 (24 GB); Tesseract se ejecutó solo en CPU (compute_type=cpu) y se indica así en cada tabla.
Motores y versiones (según los manifiestos de cada ejecución): Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR servido con vLLM, PaddleOCR-VL 1.6.
Postprocesadores de campo: F1 de campo con regex = patrones fijos sroie_receipt_regex/cord_receipt_regex aplicados al texto OCR de cada motor (postprocesado, no extracción nativa); F1 de campo con LLM = deepseek-v4-flash (temperatura 0) leyendo el mismo texto (columna llm_model de field_method_comparison.csv).
Definición de Métricas
Character Error Rate (CER): distancia de edición de Levenshtein entre el texto reconocido y el texto de referencia — mínimo de inserciones/eliminaciones/sustituciones dividido por la longitud del texto de referencia (especificación de evaluación OCR-D). Menor es mejor. Mide solo la reproducción exacta de caracteres.
Word Error Rate (WER): la misma lógica de distancia de edición a nivel de palabra — una palabra sobrevive a una sustitución de caso única, por lo que la divergencia CER/WER revela normalización que cambia caracteres sin romper palabras.
F1 de campo-valor: media armónica de precisión y recuperación sobre los valores de campo extraídos; un campo coincide solo si es igual exactamente al texto de referencia. Las columnas regex y LLM son dos postprocesadores sobre el mismo texto OCR, nunca se mezclan.
Convención de salida: cómo un motor formatea su texto (mayúsculas/minúsculas, separadores, orden de líneas). Los motores tradicionales lo preservan; los VLM de análisis de documentos lo normalizan — el eje que mide esta página.
Estructura del texto de referencia: si el texto de referencia es texto visible puro (SROIE) o está aumentado con estructura de anotación (CORD gt_text), lo que infla el CER para todos los motores.
Lista de Fuentes
summary_metrics.csv (GitHub raw). 16 filas = 8 motores × 2 conjuntos de datos de recibos. Las columnas incluyen cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate. Cada cifra de CER/WER y F1 de campo regex en esta página se remonta a una fila aquí, citada a nivel de archivo/modelo/dataset/métrica.
field_method_comparison.csv (GitHub raw). Comparación lado a lado de extracción de campos regex vs LLM (llm_field_value_f1, llm_model=deepseek-v4-flash). Fuente para la tabla de F1 de campo LLM.
Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga los CSV de resultados, manifiestos de ejecución redactados, el protocolo congelado (reports/receipt_v1_official_protocol.md) y listas de muestras fijas para reproducción.
results/manifests/ (GitHub). Un manifest.json redactado por cada ejecución publicada con versiones de modelo, huellas de entorno y hashes de artefactos.
receipt_v1_official_protocol.md. El contrato de ejecución congelado: divisiones de prueba fijas, nivel oficial, medición de calentamiento-para-puntuación, reglas de separación CORD-vs-SROIE. Fuente para las reglas a nivel de protocolo citadas en esta página.
Notas de análisis del protocolo de benchmark (documentación interna de ejecución, WRITING_BRIEF §8.2/§8.3). El mecanismo de normalización VLM (normalización de mayúsculas/minúsculas, fusión etiqueta/valor, reordenamiento de líneas), el mecanismo de estructura de texto de referencia CORD y la descomposición del CER de SROIE (~76% idéntico / ~18% mayúsculas / ~10% fusión de líneas). Citado aquí con la etiqueta explícita “estimación derivada del protocolo — no es una columna de CSV”; la división es direccional, no precisa.
Las cifras de descomposición son estimaciones derivadas del protocolo, no mediciones: la descomposición del CER de SROIE de ~76%/~18%/~10% proviene de las notas de análisis del protocolo del benchmark (WRITING_BRIEF §8.2), no de una columna CSV. La dirección (la normalización, no la mala lectura, domina el CER de VLM) es robusta; los porcentajes exactos deben tratarse como estimaciones orientativas, no como mediciones puntuales.
Solo recibos: recibos de SROIE (inglés) y CORD (indonesio). El comportamiento en facturas, formularios, tablas o documentos largos no está medido; el mecanismo se generaliza, los números no.
Un solo postprocesador LLM: todas las cifras de F1 de campo de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambia los valores absolutos de F1 y posiblemente la banda de convergencia; el ordenamiento entre familias dentro de la banda es la señal estable.
El CER sigue siendo válido para casos de texto literal: la conclusión está limitada a la comparación entre familias de salidas de estilo VLM. Para la comparación dentro de la misma familia de OCR puro y para consumidores de caracteres exactos (búsqueda, auditoría), el CER sigue siendo una métrica legítima; esta página no es un argumento contra el CER en esos contextos.
CORD no se fusionó en los rankings de SROIE: diferente idioma, diferente estructura de texto de referencia. CORD se compara solo en métricas de campo, según el protocolo del benchmark.
Fijación de versión y hardware: los números son válidos para las versiones del modelo de agosto de 2026 y un nivel de GPU (RTX 4090) listado arriba. Versiones más nuevas cambian el CER y el F1 de campo; las diferencias de un solo dígito porcentual deben tratarse como ruido.
Tamaño de la muestra: 361 + 100 muestras; los intervalos de confianza por bootstrap se reportan en la salida de evaluación del benchmark pero no se reproducen fila por fila en esta página.