Velocidad vs. Precisión en OCR: La Disyuntiva que Ningún Proveedor Explica

Todos los proveedores de OCR dicen que su herramienta es "rápida" y "precisa", como si ambas cualidades existieran en el mismo eje y se obtuvieran automáticamente. La realidad es la opuesta: la velocidad y la precisión están en tensión directa en cualquier pipeline de OCR, desde una biblioteca open source gratuita en un portátil hasta una API en la nube respaldada por miles de GPUs. Una instancia de Tesseract configurada para máxima velocidad procesa una página en 0.16 segundos, pero lee mal 1 de cada 8 palabras. Un modelo de IA de visión que lee la misma página con precisión casi perfecta tarda entre 30 y 60 veces más. ¿Cuál es la adecuada para tu flujo de trabajo? La respuesta depende de qué procesas, qué construyes y cuánto te cuesta un solo dígito incorrecto. La mayoría de los proveedores omiten esa pregunta porque la respuesta honesta —"depende"— no cabe en una tabla comparativa.

Por qué la velocidad y la precisión son inversamente proporcionales

La relación inversa entre velocidad y precisión no es una limitación de una herramienta específica, sino una consecuencia del funcionamiento del OCR a nivel arquitectónico. Todo sistema OCR, ya sea un motor clásico de coincidencia de patrones o un modelo moderno de lenguaje y visión, sigue una secuencia de pasos: preprocesamiento de imagen, detección de texto, reconocimiento de caracteres y posprocesamiento. Cada paso consume recursos computacionales, y cuanto más minuciosamente se ejecute cada uno, más preciso será el resultado, pero también más tiempo llevará.

Profundidad del preprocesamiento. Un pipeline de OCR optimizado para velocidad minimiza o elimina el preprocesamiento: reduce la resolución de la imagen para disminuir la cantidad de píxeles, aplica un umbral de binarización simple y pasa el resultado directamente al reconocedor. Pruebas independientes muestran que omitir pasos como la corrección de inclinación, la eliminación de ruido y el realce de contraste puede reducir el tiempo de procesamiento entre un 40 y un 60 %, pero también reduce la precisión entre 10 y 20 puntos porcentuales en entradas imperfectas. La recomendación estándar en la literatura de OCR —mínimo 300 DPI, binarización adaptativa, corrección geométrica— es en sí misma un compromiso entre velocidad y precisión. A 300 DPI, un carácter de 10 puntos abarca aproximadamente 42 píxeles, lo que le da al reconocedor suficiente resolución para distinguir trazos finos. Por debajo de 150 DPI, la precisión cae drásticamente en todos los motores probados. Por encima de 300 DPI, las ganancias de precisión se estancan mientras que el tamaño del archivo y el tiempo de procesamiento siguen aumentando.

Complejidad del modelo. Aquí es donde la relación inversa se vuelve más evidente. El motor clásico de Tesseract utiliza extracción de características artesanal: compara formas de caracteres con una biblioteca de plantillas mediante clasificadores precalculados. Esto es rápido (0.1–0.3 segundos por página en una CPU moderna), pero frágil: la precisión en entradas desafiantes, como fotos de teléfonos móviles, cae a aproximadamente 70–80 %. El motor LSTM de Tesseract 4 añade una capa de red neuronal que lee caracteres en contexto secuencial, mejorando la precisión entre 5 y 15 puntos porcentuales en documentos ruidosos, aunque duplicando aproximadamente el tiempo de procesamiento. Los motores OCR modernos de aprendizaje profundo, como PaddleOCR y EasyOCR, reemplazan todo el pipeline con redes neuronales: detección de texto basada en CNN seguida de reconocimiento de secuencias basado en atención. Estos modelos logran una precisión sustancialmente mayor (especialmente en diseños complejos y escritura a mano), pero requieren de 3 a 30 veces más cómputo por página. Un análisis comparativo de marzo de 2026 realizado por Codesota midió lo siguiente en una sola factura: Tesseract 5.5 en 0.162 segundos con 87.5 % de precisión, EasyOCR en 0.656 segundos con 62.5 % de precisión y PaddleOCR en 4.85 segundos con 100 % de precisión. La correlación no es perfecta —PaddleOCR dominó en esta prueba específica—, pero el patrón en todos los tipos de documentos es claro: cuanto más profundo es el modelo, más lento y, por lo general, más preciso tiende a ser.

Cadena de posprocesamiento. Los pipelines optimizados para precisión añaden pasos de validación después del reconocimiento: corrección ortográfica basada en diccionarios, comprobaciones de coherencia entre campos (¿el total de la factura coincide con la suma de las líneas de detalle?), validación de formato (¿la fecha se analiza correctamente?) y umbralización de puntuaciones de confianza con enrutamiento de revisión humana. Cada paso añade latencia. Un OCR básico que genera texto sin procesar en 0.2 segundos puede requerir de 2 a 3 segundos adicionales de posprocesamiento para alcanzar una precisión de nivel de producción. La latencia total del sistema —no solo el paso de reconocimiento— es lo que determina el rendimiento en el mundo real.

El panorama de velocidad: cómo se ven realmente los números

La velocidad bruta de procesamiento varía en dos órdenes de magnitud según el motor OCR, el hardware y la complejidad del documento. La tabla siguiente destila puntos de referencia publicados de múltiples fuentes independientes en rangos que reflejan condiciones reales de producción, no ejecuciones seleccionadas del mejor caso.

Motor / API	Velocidad (por página, CPU)	Velocidad (GPU)	Precisión (impreso limpio)	Precisión (desafiante)
Tesseract 5.5 (modo legacy)	0,1–0,3 s	N/A (solo CPU)	90–96%	50–70%
Tesseract 5.5 (modo LSTM)	0,3–0,8 s	N/A (solo CPU)	93–97%	60–80%
EasyOCR	0,6–2,5 s	0,2–0,8 s	90–95%	55–75%
Google Cloud Vision OCR	1–3 s (API)	—	96–99%	75–85%
AWS Textract	2–4 s (API)	—	95–98%	78–85%
Azure Document Intelligence	3–5 s (API)	—	96–99%	80–88%
PaddleOCR	3–6 s	~0,5 s (120 páginas/min)	95–99%	75–88%
Modelo de Lenguaje y Visión (VLM)	5–15 s	2–6 s	96–99%	85–95%

Fuentes: Codesota (marzo 2026), AIMultiple DeltOCR Bench (enero 2026), benchmark GigaGPU PaddleOCR, documentación oficial de AWS/Azure/Google. "Desafiante" incluye escaneos de baja resolución, fotos de teléfono móvil y documentos con diseños mixtos. La categoría VLM representa herramientas como ImageToTable.ai y Qwen-VL.

La conclusión clave de estos números: la relación entre velocidad y precisión no es una curva suave. Tiene puntos de inflexión. Tesseract te da velocidad pero alcanza un techo de precisión duro en documentos imperfectos. Las APIs en la nube ofrecen un techo más alto con latencia moderada. Los VLM elevan el techo al máximo pero requieren más tiempo por página. Elegir entre ellos significa saber en qué punto de inflexión te colocan tus documentos y tu tolerancia a errores.

Conclusión práctica: Tesseract procesa una factura en el tiempo que un humano tarda en parpadear. Pero si esa factura es una foto de teléfono de un recibo arrugado de un contratista, la extracción de 0,16 segundos puede tener una tasa de error del 20–30% — y corregir esos errores en tu sistema contable lleva minutos por documento. La extracción rápida crea trabajo lento aguas abajo.

Cuando la Velocidad Importa Más

No todo flujo de trabajo documental requiere precisión a nivel de campo. Varios escenarios reales priorizan correctamente el rendimiento sobre la exactitud de caracteres, y los proveedores que solo promocionan "99% de precisión" perjudican a sus usuarios al no reconocer estos casos.

Escaneo en punto de venta en tiempo real. Un sistema de caja minorista que escanea un recibo para consultar un precio o validar una devolución necesita una respuesta en menos de un segundo. Si el OCR lee mal un carácter en el nombre de un producto, pero el sistema de inventario encuentra el SKU correcto mediante coincidencia difusa, la transacción se completa sin interrupción. La velocidad es la restricción clave; el sistema procesa cientos de transacciones por hora y 3 segundos adicionales por escaneo crearían una cola en la caja. Para estos casos, el modo heredado de Tesseract o una API ligera en la nube con tiempos de espera agresivos son la opción correcta, incluso si implica aceptar una tasa de error del 2–5%.

Clasificación y enrutamiento de documentos. Muchos procesos de documentos necesitan clasificar un documento entrante (¿es una factura, una orden de compra o un albarán?) antes de enrutarlo al procesador adecuado. El paso de clasificación requiere extraer solo el texto suficiente para identificar el tipo de documento —normalmente el encabezado, título o algunos campos clave—, no cada carácter de la página. Un pase OCR rápido que identifique correctamente el 95% de los tipos de documento en 0.2 segundos por página es más valioso que uno lento que identifique el 98% en 5 segundos, porque el 3% mal clasificado puede detectarse en la revisión humana. Google Cloud Vision OCR, con su latencia de 1–3 segundos y amplio soporte de idiomas, es una opción común para esta capa de enrutamiento.

Archivo de alto volumen con texto buscable. Cuando el objetivo es hacer buscables millones de páginas en un sistema de gestión documental —en lugar de extraer campos de datos específicos—, el umbral de precisión es menor. Un PDF buscable generado por Tesseract con un 90% de precisión de caracteres aún permite a los usuarios encontrar la mayoría de los documentos mediante búsqueda por palabras clave, porque un documento que contiene "Factura #12345" se encontrará incluso si Tesseract lee "Factura #1234S" en algunas páginas. La diferencia de costo entre un proceso OCR rápido (miles de páginas por hora en un solo servidor) y uno lento (cientos de páginas por hora) determina si el proyecto de archivo es viable.

OCR móvil en dispositivos con batería limitada. Ejecutar un modelo OCR de aprendizaje profundo en un teléfono inteligente o escáner portátil requiere equilibrar la precisión con el consumo de batería y el calor. EasyOCR en un smartphone moderno toma aproximadamente 0.2–0.8 segundos por imagen con aceleración GPU, pero a costa de un consumo energético significativo. Para trabajadores de campo que escanean cientos de etiquetas por turno, un modelo más ligero que sacrifique un 5% de precisión para duplicar la duración de la batería es la opción operativa correcta.

Cuando la Precisión es Clave

Cada escenario anterior comparte una característica: el costo de un solo error es bajo o fácil de absorber. Invierta esa suposición y la compensación se revierte por completo.

Documentos fiscales y financieros. Un solo dígito mal leído en una declaración de IVA, un campo salarial de un W-2 o el total de una factura genera un problema en cascada. El total de factura de $1,500 que el OCR lee como $15,000 provoca un error de pago que requiere conciliación, seguimiento con el proveedor y, potencialmente, una declaración de impuestos corregida. Un análisis de Gennai de 2025 calculó que un sistema que procesa 500 facturas con un 94% de precisión (30 facturas con errores) generó 5 horas de trabajo de corrección por lote, mientras que un sistema que procesa 400 facturas con un 99% de precisión (4 con errores) generó solo 40 minutos de limpieza, a pesar de la tasa más lenta por página. El sistema más lento fue más productivo en términos de producción útil por hora. Para documentos fiscales específicamente, el IRS y la mayoría de las autoridades tributarias esperan un 100% de precisión en las cifras reportadas, no "casi exacto". Un solo error de campo en una declaración de impuestos anual puede desencadenar una auditoría, multas y cargos por intereses que eclipsan cualquier ahorro en costos de procesamiento.

Contratos legales y documentos de cumplimiento. La extracción de datos de contratos para monitoreo de cumplimiento, abstracción de arrendamientos o presentaciones regulatorias es el ámbito donde la precisión no es negociable. Una fecha de renovación de contrato desfasada por un mes, una cláusula de indemnización mal clasificada o un límite de responsabilidad leído como $500,000 en lugar de $5,000,000 crea una exposición legal que ninguna velocidad de procesamiento justifica. Para estos documentos, el enfoque correcto es la extracción optimizada para precisión con puntuación de confianza y revisión humana obligatoria de cualquier campo de baja confianza. Los modelos de lenguaje-visión — que leen el documento completo en contexto y pueden interpretar la estructura de cláusulas y relaciones semánticas — son cada vez más el estándar aquí, incluso a 10–15 segundos por página, porque el costo de un solo error de extracción puede exceder el presupuesto anual completo de la herramienta de extracción.

Facturación médica y datos de pacientes. La extracción de documentos de salud se encuentra en la intersección de los requisitos de precisión y las restricciones regulatorias. Un código CPT mal leído en un formulario de reclamación CMS-1500 puede resultar en la denegación de la reclamación, pago retrasado o, en el peor de los casos, un procedimiento incorrecto facturado al registro del paciente. El cumplimiento de HIPAA exige tanto precisión como auditabilidad. El estándar en la extracción de documentos médicos es una precisión a nivel de campo superior al 98% con trazabilidad completa de cada valor extraído hasta su posición en el documento fuente. La velocidad es secundaria; una reclamación presentada incorrectamente es más costosa que una reclamación presentada tarde.

Transacciones internacionales y multidivisa. Los documentos que mezclan monedas, convenciones decimales y formatos numéricos son particularmente implacables con el OCR optimizado para velocidad. Una factura europea que muestra "€ 1.234,56" (1.234,56 EUR) procesada por un sistema entrenado en convenciones decimales estadounidenses puede leer mal el importe como €1,23 — un error de 1.000x. La caída de precisión en documentos multilingües y multiformato está bien documentada, y corregir estos errores específicos de formato requiere un modelo entrenado en formatos internacionales o reglas de validación de posprocesamiento que añaden latencia. En este ámbito, la precisión debe ganar porque el costo de un error de formato no es proporcional a la tasa de error de caracteres: un punto decimal mal colocado puede quebrar una transacción.

Regla práctica: Si un humano tarda más de 30 segundos en verificar un solo campo de tu salida, y procesas más de 200 documentos por semana, optimiza para precisión — el tiempo de revisión ahorrado por menos errores compensará con creces la velocidad de extracción más lenta. Si verificar el mismo campo toma menos de 5 segundos y los errores son obvios de inmediato, optimiza para velocidad.

Un Marco de Decisión Práctico

En lugar de preguntar "cuál es la mejor herramienta OCR", hazte estas tres preguntas sobre tu flujo de trabajo en orden:

¿Cuál es el costo de un solo error de extracción en tu flujo de trabajo?

Si un campo mal leído cuesta más de $50 en correcciones, retrasos posteriores o riesgo de cumplimiento, comienza con un pipeline optimizado para precisión y acepta un rendimiento más lento. Si los errores se detectan rápido y cuestan poco arreglarlos, un pipeline priorizando velocidad es adecuado.

¿Cuál es la distribución de calidad de tus documentos de entrada?

Si el 90% de tus documentos son PDFs limpios e impresos con fuentes estándar — Tesseract en modo LSTM a 0.3 segundos por página probablemente sea suficiente, y solo necesitas manejar el 10% restante de casos atípicos con un sistema de respaldo más lento y preciso. Si la mayoría son fotos de teléfono de recibos térmicos arrugados, comienza con un modelo que maneje bien el deterioro — lo que significa aceptar una velocidad más lenta por página.

¿Necesitas extracción de campos estructurados o solo texto sin formato?

Extraer campos específicos (total de factura, número de OC, ID fiscal) de formatos arbitrarios requiere comprensión semántica — una tarea donde las ventajas de velocidad del OCR tradicional desaparecen porque el posprocesamiento necesario para identificar y validar campos añade latencia independientemente de la velocidad de reconocimiento. Aquí es donde las herramientas de extracción sin plantilla basadas en VLM como ImageToTable.ai cambian la ecuación: eliminan la configuración y el mantenimiento de plantillas que ralentizan los pipelines tradicionales, haciendo que su procesamiento de 5 a 10 segundos por página sea más rápido en tiempo total de flujo de trabajo.

Aplica este marco como filtro: si la Pregunta 1 apunta a precisión y la Pregunta 2 confirma que tienes calidad de entrada heterogénea, salta las herramientas de velocidad primero y ve directamente a una plataforma diseñada para precisión en documentos diversos. Si la Pregunta 1 apunta a velocidad y la Pregunta 2 confirma una entrada limpia y uniforme, un pipeline ligero basado en Tesseract o una API rápida en la nube es la decisión correcta. El error que cometen la mayoría de los equipos es no evaluar estas preguntas en orden — comparan herramientas primero por velocidad, luego descubren que sus requisitos de precisión los obligan a reconstruir el pipeline.

Cómo los modelos de lenguaje visual cambian las reglas del juego

El equilibrio velocidad-precisión descrito hasta ahora se aplica a las arquitecturas OCR tradicionales — motores que dividen la lectura de documentos en pasos secuenciales e independientes (detección → reconocimiento → postprocesamiento). Los modelos de lenguaje visual (VLM) abordan el problema de manera diferente: leen el documento como una escena visual única, comprendiendo el diseño, el texto y las relaciones entre campos en un solo paso integrado. La consecuencia práctica es que los VLM no enfrentan la misma curva de equilibrio velocidad-precisión que el OCR tradicional.

Donde la precisión de Tesseract se desploma en entradas difíciles (50–70% en escritura a mano, por ejemplo), la precisión de un VLM se degrada gradualmente — de 96% en texto impreso limpio a 85–90% en escritura a mano moderada hasta aproximadamente 75–80% en el peor caso. No hay un precipicio. Donde EasyOCR requiere aceleración por GPU para alcanzar velocidades aceptables en documentos complejos, un VLM ejecutándose en CPU aún puede producir resultados utilizables — más lento, pero sin la fuerte caída de precisión que exhibe el OCR tradicional cuando se omite el preprocesamiento.

Esto cambia el marco de decisión. Con una herramienta basada en VLM como ImageToTable.ai, el equilibrio velocidad-precisión ya no es una elección binaria entre "rápido e incorrecto" o "lento y correcto". En cambio, el mismo modelo sirve para ambos escenarios: puedes procesar una sola factura en 5–10 segundos con una precisión a nivel de campo superior al 95%, o procesar 50 facturas por lote y revisar solo los resultados de baja confianza. La consistencia del modelo en diferentes calidades de documento — la ausencia de precipicios de precisión — es lo que hace esto posible. No estás eligiendo entre dos motores diferentes para triaje rápido y extracción de alta precisión; estás eligiendo un motor y ajustando el umbral de revisión.

Para los equipos que evalúan soluciones OCR en 2026, el cambio importante es este: el equilibrio velocidad-precisión sigue siendo real, pero la curva se ha aplanado. Las herramientas basadas en modelos de lenguaje visual ofrecen un piso de precisión más alto en cada punto de velocidad que las arquitecturas OCR tradicionales pueden igualar. La pregunta ya no es "¿cuánta precisión estoy dispuesto a intercambiar por velocidad?" sino "¿cuánta latencia puede tolerar mi flujo de trabajo para lograr la precisión que necesito?" — y la respuesta, para la mayoría de los flujos de trabajo documentales, es más de lo que crees.

Preguntas Frecuentes

P: ¿Puedo usar Tesseract para extracción de documentos en producción o es muy impreciso?

Depende de tus documentos y tu tolerancia al error. En PDFs limpios e impresos con fuentes estándar a 300 DPI, Tesseract 5.5 en modo LSTM ofrece una precisión de caracteres del 93–97%, suficiente para muchos flujos internos donde un error tipográfico ocasional no es catastrófico. En fotos de recibos tomadas con móvil, copias carbón escaneadas o documentos con escritura a mano, la precisión baja al 50–80%, probablemente demasiado baja para uso en producción sin una revisión manual significativa. Para una comparación detallada de herramientas de código abierto, consulta nuestra guía de herramientas OCR de código abierto.

P: ¿Cuál es más rápido — AWS Textract o Google Cloud Vision OCR?

Ambos procesan una página en 2–4 segundos en modo síncrono, con Google ligeramente más rápido en documentos simples (1–3 segundos) y Textract comparable (2–4 segundos). En modo asíncrono/lote, ambos servicios procesan cientos de páginas por hora. La diferencia principal no es la velocidad, sino el perfil de precisión: Google Vision destaca en documentos multilingües e imágenes ruidosas, mientras que Textract tiene mejor extracción de formularios y tablas. Para una comparación directa de APIs OCR en la nube, consulta nuestra guía Mejor API OCR 2026.

P: ¿Cuánto más lento es el modo "preciso" frente al modo "rápido" en la misma herramienta OCR?

El modo LSTM de Tesseract es aproximadamente 2–5 veces más lento que el modo heredado en el mismo documento — 0.3–0.8 segundos por página frente a 0.1–0.3 segundos. El modo "preciso" de ABBYY FineReader es aproximadamente 2–2.5 veces más lento que el modo "rápido". La ganancia de precisión suele ser de 5–10 puntos porcentuales en documentos difíciles. Algunos modos "súper precisos" ejecutan múltiples motores en paralelo y toman el mejor resultado, multiplicando el tiempo de procesamiento por el número de motores. El análisis de rendimientos decrecientes de CVISION aplica aquí: cada reducción a la mitad de la tasa de error requiere aproximadamente el doble de tiempo de procesamiento.

P: ¿La aceleración por GPU elimina la compensación velocidad-precisión?

Reduce la brecha significativamente, pero no la elimina. PaddleOCR en una GPU RTX 3090 procesa ~120 páginas por minuto — aproximadamente 5 veces más rápido que su velocidad en CPU y casi 5 veces el rendimiento de Tesseract solo en CPU — manteniendo la misma precisión. La aceleración por GPU permite ejecutar modelos OCR de aprendizaje profundo a velocidades comparables a motores ligeros, ofreciendo efectivamente velocidad y precisión. Sin embargo, el costo de la GPU, su disponibilidad en entornos cloud y el consumo de energía en dispositivos periféricos siguen siendo limitaciones. No todos los flujos de trabajo tienen una GPU disponible.

P: ¿Debo optimizar la velocidad o la precisión al procesar facturas de múltiples proveedores con diferentes formatos?

Precisión. El principal desafío del procesamiento de facturas de múltiples proveedores no es la velocidad de lectura, sino la variación de formatos. Una herramienta OCR basada en plantillas que procesa cada factura en 0,5 segundos pero requiere una plantilla separada por cada diseño de proveedor dedicará mucho más tiempo total al mantenimiento de plantillas que al procesamiento real. Una herramienta sin plantillas, basada en VLM, que procesa cada factura en 5–10 segundos pero maneja cualquier formato sin configuración previa, será más rápida en el tiempo total del flujo de trabajo, especialmente a medida que crece el número de proveedores. Nuestra guía sobre qué significa realmente la precisión del OCR explica por qué la precisión a nivel de campo importa más que la velocidad a nivel de caracteres en flujos de trabajo con múltiples formatos.

P: ¿Cuándo debo usar un enfoque híbrido — OCR rápido para clasificación y OCR preciso para extracción?

Un pipeline híbrido tiene sentido cuando tienes una distribución bimodal de calidad documental: un gran volumen de documentos limpios y estandarizados (donde basta un pase rápido) mezclado con un volumen menor de documentos complejos o degradados (donde se requiere un procesamiento optimizado para la precisión). La clasificación de documentos mediante Tesseract o un OCR ligero en la nube categoriza cada documento entrante como "limpio" o "difícil", enviando los limpios a un pipeline de extracción rápida y los difíciles a una revisión VLM o humana. Este es un patrón común en departamentos de cuentas por pagar empresariales que procesan tanto facturas electrónicas de grandes proveedores como facturas en papel de pequeños proveedores. La trampa: la lógica de enrutamiento debe ser muy precisa, o los documentos difíciles se cuelan en el pipeline rápido y generan errores.

Toma la Decisión Deliberadamente

El equilibrio entre velocidad y precisión en OCR no es un problema que resolver, sino un parámetro de diseño que debe definirse deliberadamente. Para cada flujo de procesamiento de documentos, existe un punto de equilibrio correcto. El error es dejar que la configuración predeterminada del proveedor o un único número de referencia tomen la decisión por ti.

La mayoría de los equipos priorizan la velocidad durante la evaluación porque es fácil de medir (un número, una ejecución, un cronómetro) y la precisión no lo es (varía según el tipo de documento, la calidad, el campo y la definición de error). El proceso de evaluación honesto mide la precisión en los documentos reales que procesas, incluidos los desordenados, y mide el tiempo total del flujo de trabajo, no solo la latencia del OCR. Ese total incluye el tiempo dedicado a corregir errores, que es donde el OCR "rápido" pierde su ventaja.

Los modelos de lenguaje y visión han aplanado la curva de precisión, haciendo que una alta precisión sea accesible a velocidades tolerables para la mayoría de los flujos de trabajo de documentos empresariales. Si la precisión es tu limitación (y para la mayoría de los casos de extracción de documentos debería serlo), una herramienta basada en VLM que procese una página en 5 a 10 segundos y ofrezca una precisión a nivel de campo superior al 95% es una mejor opción que una herramienta que procese la misma página en 0.2 segundos y te obligue a verificar cada 5.º valor.

Prueba el equilibrio con tus documentos reales. Observa cómo son 5 segundos por página cuando los errores que solían llevar minutos encontrar simplemente ya no están.