EasyOCR vs docTR en Recibos
Campeón de Velocidad vs Extractor de Campos (2026)

Última revisión: 2026-08-18 · Nivel de ejecución: oficial · Comparación directa de primera parte · 2 motores × 2 conjuntos de datos de recibos

Declaración de alcance: todos los números de esta página se aplican solo a recibos — recibos en inglés SROIE 2019 y recibos en indonesio CORD v2. Un nivel de hardware (RTX 4090 a $0.76/hr, precio con marca de tiempo agosto 2026), un postprocesador LLM (deepseek-v4-flash a temperatura 0), versiones de modelo fijas (EasyOCR 1.7.2, docTR v1.0.1). No extrapole estos resultados a otros tipos de documentos, GPUs o LLMs — el benchmark mide solo OCR de recibos y extracción de campos de recibos. Todas las cifras provienen de results/summary_metrics.csv y results/field_method_comparison.csv del benchmark, reflejadas en el repositorio público de GitHub y citadas fila por fila.

En recibos limpios en inglés, la arquitectura moderna gana decisivamente en calidad de texto bruto: el CER de docTR en SROIE 0.1971 frente a 0.2833 de EasyOCR (30% más bajo), WER 0.3199 frente a 0.6158 (48% más bajo). Sin embargo, al pasar el texto de ambos motores por los mismos patrones regex fijos, la clasificación se invierte: EasyOCR extrae campos a una tasa 1.93× mayor (0.1477 frente a 0.0766 F1 de campo) — la inversión "precisión de texto ≠ precisión de campo" del benchmark, ahora entre dos motores tradicionales. Al añadir un postprocesador LLM, la inversión se revuelve decisivamente de nuevo: docTR 0.6171 (el mejor de los 8 motores) frente a EasyOCR 0.3717 (el peor de los 8) — una brecha de 1.66× y uno de los mayores deltas de F1 de campo con LLM del benchmark. El rango operativo es todo docTR: 3.8× más rápido en p50 (108.7 frente a 413.6 ms), 3.6× mayor rendimiento (449.3 frente a 124.5 páginas/min), 2.3× más barato ($0.048 frente a $0.110 por 1.000 páginas) — el motor más rápido y barato del benchmark en ambos ejes a la vez.

El compromiso, en un par de números: docTR lee una página de recibo en 108.7 ms p50 por $0.048 por 1.000 páginas y, a través de un postprocesador LLM, extrae campos con un 0.6171 F1; EasyOCR la lee en 413.6 ms p50 por $0.110 por 1.000 páginas y su F1 de campo con LLM colapsa a 0.3717 — el peor de los ocho motores probados. Mismos recibos, misma división de prueba, mismo RTX 4090. Ningún motor "gana"; EasyOCR mantiene la ventaja en campos con regex y la propuesta de despliegue, mientras que docTR gana en todos los ejes de precisión, velocidad y costo medidos aquí.

Fuente: field_method_comparison.csv — llm_field_value_f1, las ocho filas de sroie_2019, 361 muestras cada una (llm_ok_count). Postprocesador LLM idéntico para todos los motores: deepseek-v4-flash a temperatura 0. Contexto de CER de summary_metrics.csv, columna cer, filas de sroie_2019.

Tabla: field_method_comparison.csv — llm_field_value_f1, todas las filas sroie_2019; columna CER de summary_metrics.csv, cer, filas sroie_2019. El 0.6171 de docTR es el F1 de campo LLM más alto del benchmark; el CER de EasyOCR (0.2833) ocupa el cuarto lugar de ocho — texto de nivel intermedio con la peor recuperación de campos posteriores al LLM (0.3717, por debajo del 0.4389 de Tesseract). La paradoja se documenta como observada y reproducible; su mecanismo no está aislado por este benchmark.

El Envolvente Operativo: docTR es el Campeón de Velocidad Y Costo del Benchmark

La precisión decide qué motor lee mejor; el envolvente operativo decide cuál termina. En la misma RTX 4090 a la misma tarifa registrada de $0.76/hr, docTR mantiene 449.3 páginas/min a 108.7 ms p50 por página por $0.048 por 1,000 páginas; EasyOCR mantiene 124.5 páginas/min a 413.6 ms p50 por $0.110 por 1,000 páginas — una brecha de latencia de 3.8×, una brecha de rendimiento de 3.6×, y una brecha de costo de 2.3×, todas a favor de docTR. En la ejecución completa de ocho motores, los 108.7 ms p50, 449.3 páginas/min, y $0.048 de costo de docTR son cada uno los mejores de cualquier motor medido — docTR es simultáneamente el motor más rápido y más barato del benchmark.

El costo se calcula como tiempo de ejecución de reloj de pared × la tarifa de RunPod RTX 4090 ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución), incluyendo la inicialización del modelo — el precio que realmente pagarías por el tiempo de GPU. El rendimiento son páginas por minuto de reloj de pared incluyendo esa misma inicialización. La latencia p50/p95 son tiempos de inferencia por página en estado estable medidos en caliente-para-puntuar (excluyendo la carga del modelo); la cola de EasyOCR es proporcionalmente peor — 960.4 ms p95 contra los 281.4 ms de docTR, una brecha de 3.4×. EasyOCR sigue siendo genuinamente más barato que la mayoría de los otros motores medidos (su $0.110 es la segunda cifra más baja por 1,000 páginas en el benchmark, solo detrás de docTR) — es de costo medio y velocidad media, no caro ni lento.

Fuente: summary_metrics.csv — columnas latency_p50_ms / latency_p95_ms, filas sroie_2019. docTR p50 108.72 / p95 281.38; EasyOCR p50 413.64 / p95 960.37. Latencia en estado estable (modo de medición warm_then_scored, excluye carga del modelo).

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. docTR 0.0479, EasyOCR 0.1098. Costo = tiempo de ejecución de reloj de pared × $0.76/hr incluyendo init del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto 2026). Los $0.048 de docTR son el costo más bajo por 1,000 páginas de cualquier motor en el benchmark; los $0.110 de EasyOCR son el segundo más bajo (summary_metrics.csv, cost_per_1000_pages, todas las filas sroie_2019).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019. Ambos motores con GPU (RTX 4090, precio de $0.76/hr con marca de tiempo en los manifiestos); el costo incluye la inicialización del modelo, no el rendimiento puro en estado estable. Valores exactos: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. Mejores resultados del benchmark: docTR tiene la latencia p50 más baja, las páginas/min más altas y el costo más bajo de los ocho motores (summary_metrics.csv, filas sroie_2019).

CORD (Recibos Indonesios): Ambos Colapsan en Texto, la Brecha del LLM se Amplía

Ningún motor fue entrenado predominantemente en recibos indonesios, por lo que CORD v2 (100 muestras, campos anidados menu/sub_total/total) funciona como una prueba de estrés entre idiomas — y ambos colapsan en CER bruto: 0.9101 (docTR) y 0.9185 (EasyOCR), un empate por desajuste de idioma donde ambos motores son efectivamente incapaces de leer el texto. Según el protocolo de referencia, los números de CORD se mantienen aislados de la comparación con SROIE — no se fusionan en ninguna clasificación — porque el texto de referencia de CORD incrusta estructura de anotación, lo que infla el CER bruto para cada motor además del genuino desajuste de idioma.

Las métricas de campo muestran que el patrón de SROIE se extiende — y se amplía. A través del postprocesador LLM, el F1 de campo de docTR se mantiene en 0.5500 frente a 0.3378 de EasyOCR en CORD — una brecha de 1,63×, el mismo orden que el 1,66× de SROIE, incluso cuando ambos reconocedores de texto fallan a nivel de carácter. A través de patrones regex, docTR recupera ningún campo (0.0000 field F1 — un cero literal en el CSV, no un valor faltante) porque los patrones de formato en inglés no coincidieron con nada en el texto indonesio, mientras que EasyOCR obtiene 0,0067. La ventaja de costo de docTR también se reduce y se invierte en CORD ($0,094 frente a $0,086 de EasyOCR por 1.000 páginas) — pero su ventaja de rendimiento en tiempo real crece a 500,4 frente a 211,8 páginas/min (2,4×). CORD se cita aquí por su contexto de robustez lingüística; se omite deliberadamente de agruparse con los números de SROIE en una sola tabla de clasificación.

Tabla: summary_metrics.csv (cer / pages_per_minute / cost_per_1000_pages) y field_method_comparison.csv (field F1), filas de cord_v2. No fusiones los números de CORD en ningún ranking de SROIE: El CER de CORD combina una discrepancia lingüística genuina con una inflación de la estructura de anotación en el ground truth. Los patrones regex fueron escritos para formatos en inglés, por lo que el field F1 de regex colapsa a ~0–1% en ambos motores; el 0.0000 de docTR es un cero literal registrado en el CSV, no un valor faltante. La brecha de field-F1 del LLM (0.5500 vs 0.3378) extiende el patrón de SROIE a través de idiomas; el orden de costos se invierte (EasyOCR $0.086 vs docTR $0.094) mientras la brecha de rendimiento se amplía (2.4×).

Quién Gana Cuándo: La Cuadrícula de Resumen

“Mejor” depende de la carga de trabajo, y esta comparación directa divide los ejes claramente: la precisión del texto bruto, los campos downstream del LLM, la velocidad, el rendimiento y el costo favorecen a docTR; la extracción de campos con regex fija y la historia de despliegue favorecen a EasyOCR — con la advertencia de que el resultado downstream del LLM de EasyOCR es su mayor riesgo, no su punto de venta.

Preguntas Frecuentes

¿Es docTR más preciso que EasyOCR en recibos?

Sí, en todos los ejes de precisión de texto bruto y extracción de campos en este benchmark. En SROIE 2019: CER 0.1971 vs 0.2833 (30% más bajo), WER 0.3199 vs 0.6158 (48% más bajo), F1 de campo postprocesado por LLM 0.6171 vs 0.3717 (1.66×, mejor de 8 vs peor de 8) — pero no en F1 de campo por regex, donde EasyOCR gana 0.1477 vs 0.0766 (summary_metrics.csv y field_method_comparison.csv, filas sroie_2019). Ningún motor es el campeón general de CER del benchmark — Surya2 (0.1915) ostenta ese título por un pelo sobre docTR.

¿Por qué docTR tiene mejor precisión de texto pero peor extracción de campos por regex que EasyOCR?

Porque las dos métricas evalúan salidas diferentes contra un instrumento de medición fijo. docTR devuelve texto de línea bruto limpio — preciso por CER, pero preservando mayúsculas y separadores originales — y los patrones regex fijos, escritos una vez por conjunto de datos para valores formateados, fallan mayormente contra él: F1 de campo por regex en SROIE 0.0766 (field_method_comparison.csv, regex_field_value_f1, fila doctr/sroie_2019). La salida de EasyOCR coincide con los patrones en 0.1477. Alimentar ambos a un LLM en su lugar invierte la brecha a 1.66× a favor de docTR — el conjunto de patrones regex, no el OCR, era el cuello de botella.

¿Por qué EasyOCR tiene la peor extracción de campos por LLM a pesar de una precisión de caracteres aceptable?

Esta es la paradoja documentada del benchmark, actualmente sin un mecanismo probado. El CER de EasyOCR en SROIE (0.2833) ocupa el cuarto lugar de ocho motores, sin embargo su F1 de campo postprocesado por LLM (0.3717) ocupa el último lugar — por debajo incluso de Tesseract (0.4389), que tiene un CER peor. La hipótesis principal es una convención de formato de salida en cómo EasyOCR dispone o une las líneas de texto que degrada la extracción posterior por LLM; se etiqueta como un patrón observado y reproducible con el mecanismo no verificado (field_method_comparison.csv, llm_field_value_f1, filas sroie_2019). La misma paradoja está documentada contra un oponente diferente en PaddleOCR vs EasyOCR.

¿Cuánto más rápido y barato es docTR que EasyOCR?

3.8× menor latencia p50 (108.7 vs 413.6 ms), 3.4× menor p95 (281.4 vs 960.4 ms), 3.6× mayor rendimiento (449.3 vs 124.5 páginas/min), y 2.3× menor costo por 1,000 páginas ($0.048 vs $0.110) en el mismo RTX 4090 a $0.76/hr (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019). docTR es el motor más rápido y barato del benchmark en los tres relojes; EasyOCR es de costo medio (el segundo más barato) y velocidad media (el segundo en rendimiento).

¿Por qué ambos motores obtienen tan malos resultados en recibos CORD?

Dos causas acumulativas que el protocolo del benchmark mantiene separadas del ranking SROIE: una verdadera incompatibilidad de idioma (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) e inflación de la estructura de anotación dentro del texto de referencia de CORD — el CER llega a 0.9101 (docTR) y 0.9185 (EasyOCR) (summary_metrics.csv, cer, filas cord_v2). Lo que aún los separa es la recuperación posterior con LLM: docTR 0.5500 vs EasyOCR 0.3378 F1 de campo — el patrón SROIE persiste y se amplía, incluso cuando ambos reconocedores fallan a nivel de carácter.

¿Qué motor debe elegir un pipeline de recibos, EasyOCR o docTR?

Para un pipeline cuyo objetivo es campos extraídos a gran volumen con costo medido, docTR domina en este corpus: mejor texto bruto (30% menor CER), los mejores campos posteriores con LLM de cualquier motor (0.6171 vs 0.3717), y una ventaja de costo 2.3×, rendimiento 3.6×, latencia 3.8× — los cuatro ejes a la vez (summary_metrics.csv / field_method_comparison.csv, filas sroie_2019). EasyOCR sigue siendo una opción legítima para OCR por lotes barato, fácil de instalar y multi-escritura en documentos limpios donde la extracción por regex o el texto bruto a volumen moderado es la tarea y la calidad de campos posteriores con LLM importa menos — pero presupuesta su debilidad medida en LLM posterior antes de comprometerte. Estos resultados son válidos para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; vuelve a ejecutar en tu corpus objetivo antes de decisiones de producción (ver Limitaciones).

¿De dónde provienen los números de esta página?

Cada cifra es una fila de los CSV publicados del benchmark de primera parte — results/summary_metrics.csv (CER/WER, F1 de campo por regex, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex vs. postprocesamiento por LLM, llm_model = deepseek-v4-flash) — alojados en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución para huellas de entorno. Las definiciones de los conjuntos de datos provienen de los artículos de SROIE 2019 y CORD citados a continuación.

Metodología y Fuentes

Protocolo

Esta página reporta un corte directo de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros, ni una página de comparación de proveedores. Solo se usaron divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/fecha/total) y CORD v2 test (100 recibos en indonesio, campos anidados menú/sub_total/total); las divisiones de entrenamiento nunca se evaluaron. Ambos motores vieron las mismas imágenes, la misma verdad de referencia y el mismo protocolo de medición (warm_then_scored: un pase de calentamiento fijo precede al pase puntuado, por lo que las cifras de latencia son en estado estable). Ambas ejecuciones completaron con error_rate 0.0 en ambos conjuntos de datos (columna error_rate de summary_metrics.csv). La ejecución subyacente contiene ocho motores en total; esta página compara solo los dos motores nombrados, citando a los otros motores únicamente como contexto de clasificación. Los resultados completos de los 8 motores se publican por separado en Traditional OCR vs Document Parsing VLMs.

Entorno de Ejecución

• Hardware: ambos motores se ejecutaron en la misma NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó con la tarifa bajo demanda de RunPod de $0.76/hr, con la marca de tiempo del precio en el manifest redactado de cada ejecución (agosto de 2026).
• Motores: fuera de la caja, sin ajuste fino. Versiones bloqueadas: EasyOCR 1.7.2 (reconocedor clásico CNN + RNN + CTC, extractor de características ResNet, GPU) y docTR v1.0.1 (OCR neuronal moderno de dos etapas — detección tipo transformer DETR + reconocimiento, GPU) — según la tabla de modelos del repositorio público (README.md) y los manifests de ejecución. La fila de SROIE de EasyOCR se re-verificó en una re-ejecución con torch 2.8 el 2026-08-17 (ejecuciones repetidas r1/r2/r3 idénticas a nivel de byte); los CSV publicados contienen esos valores corregidos.
• Postprocesador LLM: deepseek-v4-flash vía API a temperatura 0 para salida determinística (la columna llm_model en field_method_comparison.csv); fue el único modelo utilizado para todas las filas de campos LLM en ambos motores.
• Base de costo: tiempo de ejecución real × $0.76/hr, incluyendo la inicialización del modelo — el procesamiento por lotes reduce el costo por página.
• Postprocesamiento de campos: las métricas de campos por regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* de field_method_comparison.csv) — campos extraídos del texto OCR por un conjunto de patrones fijo escrito una vez por conjunto de datos. Miden OCR + extracción posterior, no la salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto OCR + extracción por LLM. Las dos canalizaciones nunca se combinan.

Definiciones de Métricas

• CER (Character Error Rate): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto OCR y la verdad de terreno, dividida por los caracteres de la verdad de terreno. Menor es mejor.
• WER (Word Error Rate): el mismo cálculo de distancia de edición a nivel de palabra.
• F1 de valor de campo (regex): media armónica de precisión/recall sobre los valores de campo extraídos usando patrones regex fijos en el texto OCR (pipeline de OCR tradicional + KIE basado en reglas). Columna: regex_field_value_f1. Una puntuación de 0 significa que no se recuperaron valores de campo.
• F1 de valor de campo (LLM): la misma métrica en la salida del postprocesador LLM (texto OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Los dos pipelines son diferentes y nunca se combinan.
• Campos de documento exactos: fracción de documentos donde todos los campos objetivo coincidieron exactamente — un criterio mucho más estricto que el F1 por campo.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (calentado y luego medido, excluye la carga del modelo) y rendimiento en tiempo real incluyendo la inicialización del modelo. Miden relojes diferentes.
• Costo por 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hr, incluyendo la inicialización del modelo.

Lista de Fuentes

1. summary_metrics.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos. Columnas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Cada número de CER/WER, latencia, costo y rendimiento en esta página se remonta a las filas de easyocr y doctr aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de valor de campo regex/llm, document-fields-exact, llm_median_latency_ms, recuentos de tokens. Cada número de F1 de valor de campo regex/LLM se remonta a las filas de easyocr y doctr aquí (y a las ocho filas de sroie_2019 en la tabla de paradojas).
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por cada ejecución publicada (16 ejecuciones) con versiones del modelo, GPU/driver, versiones de torch/CUDA/Python, metadatos de costos con marca de tiempo de precio y hashes de artefactos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitaciones

• Alcance del documento — solo recibos: SROIE + CORD. Nada aquí mide la amplitud de 80+ idiomas de EasyOCR en texto que no sea de recibos, el comportamiento de docTR en tablas/formularios/documentos largos, ni ningún otro tipo de documento. No use esta página para concluir que cualquiera de los dos motores “gana en todo.”
• Tamaño de la muestra: 361 recibos en inglés + 100 en indonesio. El F1 de campo y el CER son sensibles al corpus; diferencias de un solo dígito de unas centésimas deben tratarse como ruido, no como verdad de ingeniería — aunque las brechas documentadas aquí (30% CER, 48% WER, 1.66× LLM F1) están muy por encima de ese rango.
• Un solo nivel de GPU y un solo precio: todos los números provienen de una RTX 4090 a $0.76/hr, con precio registrado en agosto de 2026 en los manifiestos de ejecución. Otras GPUs, servicio multi-GPU, programación por lotes o cambios de precio alterarán la latencia, el rendimiento y el costo — recalcule los costos a las tarifas actuales antes de presupuestar.
• Un solo postprocesador LLM: todas las filas de LLM usan deepseek-v4-flash con temperatura 0. Un LLM diferente cambiará el F1 de campo absoluto; la magnitud de la paradoja de EasyOCR puede variar con el LLM, aunque el patrón observado se mantuvo para este único postprocesador en ambos conjuntos de datos. La latencia del LLM (~2.0–2.1 s mediana en SROIE, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no forma parte de la latencia de ninguno de los dos motores.
• Mecanismo de la paradoja de EasyOCR no verificado: el benchmark documenta que el texto de CER intermedio de EasyOCR produce la peor recuperación de campos aguas abajo del LLM (0.3717 SROIE / 0.3378 CORD) — un resultado observado y reproducible bajo la hipótesis de las convenciones de diseño del texto de salida, con el mecanismo causal explícitamente no aislado. Trátelo como un resultado medido para planificar en torno a él, no como una propiedad comprobada de la biblioteca.
• Ajuste de regex: el conjunto de patrones se escribió una vez por conjunto de datos. Una biblioteca de patrones ajustada por formato podría puntuar más alto en sus propios diseños — a costa del mantenimiento que el LLM elimina. La desventaja de regex de docTR (0.0766 vs 0.1477) es una propiedad de este instrumento fijo, no una afirmación sobre lo que un analizador ajustado podría recuperar.
• El CER de CORD no es una lectura de calidad por modelo: la verdad de referencia de CORD incrusta la estructura de anotación y ninguno de los dos motores fue entrenado predominantemente en indonesio; el CER de CORD (~0.91) refleja la discordancia lingüística + la inflación de la verdad de referencia. Las filas de CORD se citan con contexto y nunca se fusionan en ninguna clasificación de SROIE (regla de protocolo).
• Solo dos motores: esta comparación directa excluye deliberadamente los otros seis motores de la ejecución subyacente, los servicios OCR en la nube/API y las APIs de VLM alojadas; sus modelos de latencia y precios difieren fundamentalmente de los motores locales medidos aquí.
• Fijación de versiones: los resultados son válidos para EasyOCR 1.7.2 y docTR v1.0.1 (agosto de 2026). Versiones más recientes de cualquiera de los dos motores pueden alterar cada número en esta página.

Referencias relacionadas: PaddleOCR vs EasyOCR Receipt Benchmark · docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · OCR Cost per 1,000 Pages

Lectura relacionada: Precisión de la IA OCR vs. OCR Tradicional · Extracción de Datos de Imágenes con IA vs. OCR Tradicional · Precios de Extracción de Documentos con IA (2026)