Por qué el CER engaña al comparar VLMs de análisis de documentos
Cuantificado con datos de benchmark propios (2026)

El CER es un algoritmo de puntuación de coincidencia exacta, no un medidor de calidad

El 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 por la especificación de evaluación de OCR-D). Cuenta diferencias y no puede distinguir una lectura errónea 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 — el CER penaliza comportamientos que no son errores de lectura en absoluto.

Los motores OCR tradicionales (Tesseract, PaddleOCR, EasyOCR, docTR) emiten flujos de caracteres sin procesar que conservan las mayúsculas/minúsculas y el diseño de líneas originales, por lo que su convención de salida se acerca al texto de referencia y el 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 mayúscula/minúscula normalizada y cada línea fusionada es una penalización de distancia de edición, incluso cuando el valor del campo subyacente es correcto.

El análisis de protocolo del benchmark sobre las predicciones SROIE publicadas descompone el presupuesto bruto de CER de un VLM en aproximadamente ~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 a partir de las notas de análisis del benchmark, no una columna del 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 CER “malo” de un VLM en recibos en inglés limpios.

Dos filas del CSV hacen visible el mecanismo sin necesidad de descomposición. Unlimited-OCR obtiene CER 0.6552 pero WER 0.4779 en SROIE — sus caracteres parecen distorsionados mientras que sus palabras sobreviven, porque la normalización de mayúsculas/minúsculas reemplaza caracteres sin romper palabras (summary_metrics.csv, cer / wer, fila unlimited_ocr/sroie_2019). Y el VLM que menos normaliza, Surya2, obtiene CER 0.1915 — el mejor CER bruto de toda la ejecución de 8 motores, indistinguible de un motor tradicional sólido (summary_metrics.csv, cer, fila surya2/sroie_2019). La convención de salida del VLM, no su capacidad de lectura, es lo que la columna CER mide principalmente.

La prueba está en las inversiones: la CER y el F1 de campo no coinciden

La clasificación de CER del benchmark y su clasificación de extracción de campos difieren de forma significativa. Ordene los ocho motores por CER de SROIE y el ganador es Surya2 (0.1915); ordénelos por F1 de campo regex —la métrica que se aproxima a lo que consume un pipeline de producción— y el ganador es Unlimited-OCR (0.3376), el motor que la CER clasifica en último lugar. Una de las dos columnas no está midiendo lo que realmente consumen los sistemas posteriores.

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 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 la CER de cada motor con su F1 de campo regex en los mismos 361 recibos, con la clasificación 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í como magnitudes (unidades diferentes), pero sus clasificaciones difieren, que es el punto.

Tabla: summary_metrics.csv — columnas cer / wer / field_f1_regex, filas sroie_2019. Rangos calculados dentro de las 8 filas de esta tabla (1 = mejor según 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 con CPU (compute_type=cpu).

Lea los dos pares de inversión explícitamente. Unlimited-OCR: peor CER (0.6552), mejor F1 de campo (0.3376) — el motor que la métrica de OCR en bruto clasifica en último lugar es el que la lente de campo clasifica en primer lugar. docTR: 2.º mejor CER (0.1971), peor F1 de campo (0.0766) — texto perfecto, fallo de campo. PaddleOCR-VL también invierte en el margen (rango CER 6, rango de campo 2), mientras que las dos filas alineadas (PaddleOCR 3.º/3.º, Tesseract 5.º/5.º) son ambos motores tradicionales cuya convención de salida de texto en bruto es exactamente lo que CER fue diseñado para puntuar. Clasifique los motores solo por CER y obtendrá un ganador diferente que clasificando por lo que consume la producción — la inversión es la demostración, no una anomalía.

La Métrica de Campo es la Lente Confiable Entre Familias

Ejecute el texto en bruto de cada motor a través del mismo postprocesador de extracción de campos LLM (deepseek-v4-flash, temperatura 0) y los seis motores con texto OCR utilizable convergen a 0.57–0.62 de F1 de campo — la frontera entre familias VLM vs. tradicional que la clasificación CER hace parecer enorme (0.19 a 0.66) casi desaparece. Dos motores quedan por debajo de la banda: EasyOCR con 0.3717 y Tesseract con 0.4389. La métrica de campo separa los motores por lo que realmente importa — la recuperación de campos aguas abajo — y lo hace de manera consistente a través de la frontera entre familias.

Este es el mismo conjunto de motores que la tabla CER anterior, re-puntuado solo en la dimensión de campo: la inversión CER entre Unlimited-OCR y docTR desaparece, porque la recuperación de valores de campo es lo que consume el pipeline. El mecanismo es que el postprocesador absorbe las diferencias de convención de salida que CER penalizó — lee el texto con normalización de mayúsculas/minúsculas y fusión etiqueta/valor y extrae los valores. El F1 de campo 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 desde summary_metrics.csv solo como 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: la estructura del texto de referencia

El texto de referencia publicado por CORD (gt_text) incorpora estructura de anotación — etiquetas de campo, entradas de menú y coordenadas — en lugar de texto visible puro. El CER calcula la distancia de edición con respecto a esa cadena aumentada estructuralmente, por lo que el CER de CORD de cada motor se infla sistemáticamente antes de que siquiera se considere un error de lectura. El resultado: los ocho motores se agrupan en CER de CORD 0.90–1.08 — un rango inútilmente comprimido que dice casi nada sobre la calidad del texto.

El artefacto extremo es el CER de CORD de PaddleOCR-VL de 1.0805, el peor de los 8 motores — no es una lectura de su calidad de texto, sino la inflación estructural actuando con más fuerza contra 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 el lente de campo, el mismo motor registra el mejor F1 de campo regex de CORD del benchmark (0.3412). El CER de CORD es estructuralmente inutilizable; las métricas de campo son el único lente justo de CORD, y se mantienen estrictamente separadas de cualquier clasificación de SROIE en este benchmark (idioma diferente — indonesio — y estructura de texto de referencia diferente).

Fuente: summary_metrics.csv — columnas cer y field_f1_regex, filas cord_v2 (100 muestras por motor). El CER de CORD no es comparable entre familias ni siquiera entre motores — el texto de referencia incorpora estructura de anotación, por lo que el CER mide la distancia a una cadena aumentada estructuralmente, no al texto visible.

Tabla: summary_metrics.csv — columnas cer / field_f1_regex, filas cord_v2. CORD no se fusiona en ningún ranking de SROIE (regla del protocolo): la estructura del texto de referencia infla el CER de todos los motores, y los patrones regex se escribieron para formatos en inglés. Las métricas de campo son el único lente justo para CORD. Ordenado por F1 de campo, no por CER — el punto es que la columna CER no aporta ninguna señal de ordenamiento.

El lente de campo invierte por completo la tabla de CORD. 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 CORD de docTR es literalmente 0.0000 — no extrajo nada — mientras que su CER de CORD (0.9101) se sitúa en medio del grupo y no dice nada al respecto. En CORD, publicar el CER sin las cifras de campo no solo es poco informativo; clasifica activamente los motores en el orden equivocado.

Cuándo CER es realmente la métrica adecuada

CER sigue midiendo algo real — la reproducción exacta de caracteres — y es la métrica adecuada siempre que el consumidor final necesite texto verbatim, no campos. La conclusión de esta página es “CER induce a error en la comparación entre familias de salidas tipo VLM”, no “CER siempre está mal”.

• Dentro de la familia de OCR en bruto, CER conserva su valor. Los motores tradicionales emiten texto en bruto con mayúsculas/minúsculas y diseño preservados, por lo que CER mide la calidad real de lectura: la columna de CER de motores tradicionales en este benchmark (0.1971–0.3347 en SROIE) sigue su rendimiento de campo mucho más de cerca que en el caso de los VLM (correlación de rango con F1 de campo por regex: PaddleOCR y Tesseract están exactamente alineados en 3.º/3.º y 5.º/5.º).
• Casos de uso de texto verbatim. Los consumidores finales que requieren 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 comprobaciones de aprobado/reprobado 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 el enfoque incorrecto.
• Regla práctica para publicaciones. Cuando publique un valor de CER, indique tanto la convención de salida del motor (¿normaliza mayúsculas/minúsculas? ¿fusiona etiquetas? ¿reordena líneas?) como la construcción del texto de referencia (texto visible puro, o aumentado con anotaciones como el gt_text de CORD). Si alguno de los dos se desconoce, el valor no es portable entre motores o conjuntos de datos.
• La regla de frontera de este benchmark. CER es justo dentro de la familia de OCR en bruto e injusto a través de la frontera OCR tradicional / VLM de análisis de documentos; el F1 a nivel de campo (regex o postprocesado por LLM) es justo en ambos lados. Use CER para la calidad de texto en bruto dentro de la misma familia, y F1 de campo para la comparación entre familias — y siempre reporte la advertencia de descomposición para las filas de VLM.

Preguntas Frecuentes

¿Por qué la CER es engañosa al comparar motores OCR y VLM?

Porque la CER es una puntuación de distancia de edición de caracteres exacta, y los VLM de análisis de documentos deliberadamente no reproducen los caracteres exactamente — normalizan mayúsculas/minúsculas, fusionan líneas etiqueta/valor y reordenan texto. Cada una de esas normalizaciones se puntúa como un error incluso cuando el valor del campo es correcto. En este benchmark, Unlimited-OCR obtiene la peor CER de SROIE (0.6552) mientras tiene el mejor F1 de campo regex (0.3376) en los mismos 361 recibos (summary_metrics.csv, cer / field_f1_regex, fila unlimited_ocr/sroie_2019) — la clasificación CER y la clasificación de campos eligen ganadores diferentes.

¿Sigue siendo la CER una métrica OCR útil en absoluto?

Sí — dentro de la familia de OCR en bruto y para consumidores de texto verbatim. Los motores tradicionales (Tesseract, PaddleOCR, EasyOCR, docTR) generan flujos de caracteres en bruto que la CER mide de manera justa: en este benchmark su CER de SROIE abarca 0.1971–0.3347 y sigue el rendimiento de campo (PaddleOCR 3.º/3.º, Tesseract 5.º/5.º bajo CER y F1 de campo). La 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?

Mayormente por convención de salida, no por capacidad de lectura. El análisis de protocolo del benchmark atribuye aproximadamente ~18% del presupuesto de CER de SROIE de un VLM 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 del benchmark, no una columna CSV) — mientras que los valores de campo en sí son correctos. La CER 0.6552 de Unlimited-OCR frente a WER 0.4779 muestra la firma: los caracteres se normalizan, las palabras sobreviven (summary_metrics.csv, cer / wer, fila unlimited_ocr/sroie_2019).

¿Cuál es la mejor métrica para comparar motores OCR y VLM de análisis de documentos?

F1 de campo — con postprocesado regex para un pipeline de OCR puro, y postprocesado LLM para ambas familias. En SROIE, el F1 de campo con LLM converge seis motores a 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 lente que clasifica la tabla CORD de manera sensata, 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 incorpora 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 y normalizada — por lo que su distancia de edición a esa cadena estructuralmente aumentada es la mayor (CER 1.0805, el peor de 8). En la lente de campo, el mismo texto extrae 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 en 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 es una sustitución frente a las mayúsculas del texto de referencia, aunque el valor sea idéntico. En el análisis de protocolo de este benchmark, las sustituciones por caso representan aproximadamente el ~18% del presupuesto de CER de un VLM en SROIE (estimación derivada del protocolo) — por eso un VLM puede leer un recibo perfectamente y aun así reportar un CER que parece de un modelo fallido.

¿Debo comparar los motores de OCR por CER o por F1 de campo?

Por F1 de campo para cualquier comparación que involucre tanto motores de OCR tradicionales como VLM, porque su pipeline consume campos, no flujos de caracteres, y porque el CER está sistemáticamente inflado para la salida VLM normalizada y el texto de referencia aumentado con estructura. Use CER solo dentro de la familia de OCR sin procesar o cuando el consumidor aguas abajo necesite texto verbatim (búsqueda, auditoría, coincidencia exacta). Las dos métricas discrepan marcadamente en este benchmark: el CER clasifica a docTR en 2.º lugar y a Unlimited-OCR en 8.º; el F1 de campo por regex clasifica a docTR en 8.º y a Unlimited-OCR en 1.º (summary_metrics.csv, filas sroie_2019).

¿De dónde provienen estos números de CER y F1 de campo?

Cada número de tabla es una fila del results/summary_metrics.csv o results/field_method_comparison.csv publicados del benchmark de primera parte, alojados en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución que registra las versiones de los modelos y las huellas del entorno. La descomposición del CER de ~76%/~18%/~10% es una estimación derivada del protocolo a partir de las notas de análisis del benchmark, explícitamente no una columna del CSV. Las definiciones de los conjuntos de datos provienen de los artículos de SROIE y CORD citados a continuación.

Metodología y fuentes

Protocolo

Esta página informa 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: prueba SROIE 2019 (361 recibos en inglés, campos planos company/date/address/total, CC-BY-4.0) y prueba CORD v2 (100 recibos en indonesio, campos anidados menu/sub_total/total, CC-BY-4.0); las divisiones de entrenamiento nunca se evaluaron. Ocho motores se ejecutaron listos para usar, sin ajuste fino, bajo el protocolo congelado reports/receipt_v1_official_protocol.md (calentado y luego puntuado, solo nivel oficial). Las 16 ejecuciones puntuadas se completaron 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 con GPU se realizan en una única NVIDIA RTX 4090 (24 GB); Tesseract se ejecutó solo con CPU (compute_type=cpu) y se etiqueta como tal en cada tabla.
• Motores y versiones (según manifiestos de 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).

Definiciones de métricas

• Character Error Rate (CER): distancia de edición de Levenshtein entre el texto reconocido y el texto de referencia — inserciones/eliminaciones/sustituciones mínimas divididas por la longitud del texto de referencia (especificación de evaluación de OCR-D). Cuanto menor, mejor. Mide únicamente 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 sola sustitución de mayúsculas/minúsculas, por lo que la divergencia CER/WER revela una normalización que cambia caracteres sin romper palabras.
• F1 de valor de campo: media armónica de precisión y exhaustividad sobre los valores de campo extraídos; un campo coincide solo si es exactamente igual al texto de referencia. Las columnas de regex y LLM son dos postprocesadores sobre el mismo texto OCR, nunca mezclados.
• Convención de salida: cómo un motor formatea su texto (mayúsculas/minúsculas, separadores, orden de líneas). Los motores tradicionales la conservan; los VLM de análisis de documentos la normalizan — el eje que mide esta página.
• Estructura del texto de referencia: si el texto de referencia es texto visible puro (SROIE) o se aumenta con estructura de anotación (CORD gt_text), lo que infla el CER de todos los motores.

Lista de fuentes

1. 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 de esta página proviene de una fila aquí, citada a nivel de archivo/modelo/conjunto de datos/métrica.
2. field_method_comparison.csv (GitHub raw). Extracción de campos con regex frente a LLM lado a lado (llm_field_value_f1, llm_model=deepseek-v4-flash). Fuente de la tabla de F1 de campo LLM.
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja 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.
4. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada con versiones de modelo, huellas de entorno y hashes de artefactos.
5. receipt_v1_official_protocol.md. El contrato de ejecución congelado: divisiones de prueba fijas, nivel oficial, medición de calentamiento y luego puntuación, reglas de separación CORD frente a SROIE. Fuente de las reglas a nivel de protocolo citadas en esta página.
6. Notas de análisis del protocolo de evaluación (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 de CORD y la descomposición CER de SROIE (~76 % idéntico / ~18 % mayúsculas/minúsculas / ~10 % fusión de líneas). Citado aquí con la etiqueta explícita “estimación derivada del protocolo — no es una columna CSV”; la división es direccional, no precisa.
7. Proyecto OCR-D — Especificación de garantía de calidad. Definición formal de CER (inserciones + eliminaciones + sustituciones) / caracteres totales y el análogo de WER. Ancla definicional formal.
8. Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction” (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas, licencia (CC-BY-4.0).
9. Park et al., “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing” (2020). Definición del conjunto de datos CORD, esquema de campos anidados, licencia (CC-BY-4.0).

Limitaciones

• Las cifras de descomposición son estimaciones derivadas del protocolo, no mediciones: la descomposición 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 los VLM) es sólida; los porcentajes exactos deben tratarse como estimaciones direccionales, 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 único postprocesador LLM: todas las cifras de F1 de campo con LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente desplaza los valores absolutos de F1 y posiblemente la banda de convergencia; el orden entre familias dentro de la banda es la señal estable.
• El CER sigue siendo válido para casos de texto verbatim: la conclusión se limita a la comparación entre familias de salidas tipo VLM. Para la comparación entre familias de OCR sin procesar y para consumidores posteriores que requieren caracteres exactos (búsqueda, auditoría), el CER sigue siendo una métrica legítima — esta página no es un argumento en contra del CER en esos contextos.
• CORD no se fusiona en las clasificaciones de SROIE: idioma diferente, estructura de texto de referencia diferente. CORD se compara solo con métricas de campo, según el protocolo del benchmark.
• Versión y fijación de hardware: los números corresponden a las versiones de modelos de agosto de 2026 y a un nivel de GPU (RTX 4090) indicado arriba. Las versiones más recientes desplazan el CER y el F1 de campo; las diferencias de un solo dígito porcentual deben tratarse como ruido.
• Tamaño de muestra: 361 + 100 muestras; los intervalos de confianza bootstrap se informan en la salida de evaluación del benchmark, pero no se reproducen fila por fila en esta página.

Referencias relacionadas: Precisión a nivel de campo vs. a nivel de carácter (definición) · OCR tradicional vs. VLM de análisis de documentos · Extracción de campos con regex vs. con LLM · PaddleOCR vs. EasyOCR en recibos · Surya2 vs. Unlimited-OCR vs. PaddleOCR-VL · Benchmark de latencia de OCR · Costo de OCR por 1,000 páginas

Lectura relacionada: por qué la precisión de la IA en OCR diverge del OCR tradicional · extracción con IA desde imágenes frente a pipelines de OCR tradicionales