Seguro que te ha pasado en el trabajo: haces capturas de conversaciones y páginas web para consultarlas más tarde, pero cuando de verdad las necesitas descubres que el texto dentro de esas imágenes no se puede buscar. O un contrato importante, firmado y sellado, tiene que escanearse como PDF para conservar el documento original, pero cuando quieres localizar algo o citar un fragmento, no puedes buscar dentro de él, no puedes copiar el texto y terminas pasando páginas y tecleándolo a mano.
Ese es el problema que el OCR integrado de Gety busca resolver.
Para ver qué tan bien lo hace, probamos el OCR integrado de Gety frente a las opciones locales que los usuarios tienen más probabilidades de usar: PaddleOCR (PP-OCRv6), el competidor open source más fuerte; Tesseract, la referencia clásica; y el OCR integrado en macOS y Windows. La prueba utiliza imágenes de documentos de dos conjuntos de datos públicos: MDPBench y OmniDocBench.
Los servicios de OCR en la nube y los modelos en la nube como Gemini no están incluidos aquí. Requieren subir archivos, hacer llamadas de API, tener conexión a internet y, a menudo, pagar por uso. Por eso pertenecen a una categoría distinta del OCR que se ejecuta localmente en tu propia máquina.
Los resultados muestran dos ventajas claras del OCR integrado de Gety:
- Entre los motores OCR locales que se ejecutan en el dispositivo, Gety ocupa el primer lugar en precisión multilingüe, con el mejor resultado global en 17 idiomas.
- Utiliza alrededor de una quinta parte de la memoria de modelos comparables que se ejecutan en el dispositivo, lo que hace viable mantener OCR en segundo plano e indexar en tiempo real.
1. Multilingüe: donde Gety saca más ventaja
Muchos motores OCR manejan bastante bien idiomas de escritura latina como el inglés y el francés. Los problemas empiezan cuando cambia el sistema de escritura. Al pasar al coreano, el ruso, el tailandés o el hindi, muchas puntuaciones caen de más de 0.9 a 0.2 o incluso 0.1, un nivel demasiado bajo para ser útil. Así se comportan los distintos motores en los 17 idiomas, usando las imágenes de documentos de MDPBench:
| Idioma / Métrica | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| General (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| Alfabetos latinos (prom.) | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| Inglés | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| Alemán | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| Francés | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| Español | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| Italiano | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| Portugués | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| Neerlandés | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| Indonesio | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| Vietnamita | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| Alfabetos no latinos (prom.) | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| Chino (simplificado) | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| Chino (tradicional) | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| Japonés | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| Coreano | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| Ruso | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| Tailandés | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| Hindi | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| Árabe | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
La fila que hay que mirar es el promedio de alfabetos no latinos. Mientras muchos motores locales caen al rango de 0.1 a 0.4, Gety se mantiene en 0.832. En la práctica, eso significa que los documentos con texto en chino, japonés, coreano o ruso tienen muchas menos probabilidades de volverse invisibles para la búsqueda solo porque cambió el sistema de escritura.
Los documentos fotografiados son un problema más difícil. Cuando la entrada es una foto de un documento, no un archivo digital limpio, y aparece borrosa, torcida o con reflejos, todos los modelos tienen dificultades:
| Modelo | Nativo digital (F1) | Fotografiado (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
Todavía no hay ningún modelo fuerte en este caso. Las puntuaciones caen del rango de 0.9 a la franja de 0.2 a 0.4 en todos los casos. Apple Vision lidera este escenario con 0.421, mientras que Gety queda ligeramente por delante de los modelos open source. Para la búsqueda cotidiana, sin embargo, importa más la columna de la izquierda: la mayoría de los archivos que la gente espera buscar son capturas y escaneos limpios, no fotos torcidas de documentos.
2. Diseños complejos: en el mismo primer nivel que el mejor modelo open source
El idioma es un eje. El diseño es el otro. Las páginas a varias columnas, las tablas, los encabezados, los pies de página y las estructuras mixtas son donde los modelos más débiles empiezan a omitir líneas o a desordenarlas. OmniDocBench está diseñado para poner a prueba justamente eso:
| Modelo | Precisión de diseño (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
El 0.963 de Gety queda solo medio punto porcentual por detrás de PP-OCRv6 small (0.968), una diferencia que los usuarios difícilmente notarán en la práctica. Ambos están en el primer nivel y quedan claramente por delante de las opciones OCR integradas en el sistema.
3. La misma precisión, una fracción del consumo
Leer bien es una cosa. Leer bien con un coste lo bastante bajo como para dejarlo funcionando todo el día es otra. En la misma máquina, con las mismas entradas, en CPU:
| Modelo | Precisión multilingüe (F1) | Tiempo medio por página | Memoria máxima por página |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
Gety necesita unos 908 MB por página. Las versiones tiny y small de PP-OCRv6 necesitan 4.7 GB y 6.3 GB, entre cinco y siete veces más. Esa es la diferencia entre un modelo que puede permanecer residente y otro más adecuado para trabajos bajo demanda. Como Gety es ligero, puede seguir ejecutándose en segundo plano, detectar archivos nuevos en cuanto llegan e indexarlos sin que muevas un dedo.
(Apple Vision y Windows OCR se ejecutan dentro de sus propias plataformas, así que una comparación de memoria o velocidad no sería equiparable. Solo aparecen en las tablas de precisión.)
4. En qué y contra qué probamos
Los conjuntos de datos
Usamos imágenes de documentos de dos conjuntos de datos públicos, cada uno pensado para responder una pregunta distinta:
| Conjunto de datos | La pregunta que responde |
|---|---|
| MDPBench | ¿Se mantiene la precisión en 17 idiomas, tanto en páginas limpias como fotografiadas? |
| OmniDocBench | ¿Sigue siendo preciso cuando el diseño se complica? |
Los dos conjuntos de datos miden cosas distintas, así que reportamos los resultados por separado en lugar de mezclarlos en una sola puntuación. Para dejar claro lo que es esto: usamos estos conjuntos de datos como fuente de imágenes de documentos. El método de evaluación, las métricas y el conjunto de modelos son nuestros, y difieren de las evaluaciones oficiales publicadas por los autores de los conjuntos de datos.
Cómo puntuamos
Puntuamos la salida del OCR con un F1 a nivel de carácter, independiente del diseño. Mide únicamente si el texto se reconoció correctamente, no el diseño, los saltos de línea, la estructura de párrafos ni dónde se ubica el texto en la página.
Lo mantenemos independiente del diseño porque, para los usos que importan (búsqueda, copia, indexación), lo que cuenta es si cada carácter se leyó correctamente, no si se reconstruyó el diseño. Un texto totalmente correcto pero en un orden distinto o con saltos de línea diferentes no debería penalizarse. Esta es una prueba de OCR, no una prueba de diseño.
Para cada página, comparamos la salida del OCR con el texto etiquetado a mano y calculamos:
Antes de puntuar, tanto la referencia como la salida del OCR pasan por la misma normalización: normalización Unicode, eliminación de caracteres invisibles, unificación de los espacios en blanco y eliminación de elementos de página como encabezados, pies de página y números de página.
La coincidencia de caracteres usa un conteo por multiconjunto: un carácter que aparece varias veces se cuenta cada vez. Esto evita que las diferencias en el orden de lectura, los saltos de línea y la división de párrafos afecten la puntuación, de modo que la métrica se mantiene centrada en si el OCR leyó correctamente los caracteres de la página.
Las cifras finales son el F1 por página, con macropromedio entre idiomas y grupos de datos; el informe completo también ofrece un intervalo de confianza bootstrap del 95%.
Contra qué comparamos
Para el conjunto de comparación, intentamos cubrir las opciones principales que los usuarios probablemente encuentren en flujos de trabajo reales:
- PaddleOCR (PP-OCRv6), la opción OCR open source más fuerte en la actualidad. Viene en versiones tiny, small y medium; nosotros ejecutamos las dos versiones para el dispositivo, tiny y small. Medium es un modelo de 34.5M de parámetros pensado para GPU de servidor, y meterlo en una prueba de CPU en el dispositivo sería comparar cosas equivocadas.
- Tesseract, un motor open source de larga trayectoria, muy instalado y conocido como referencia.
- Apple Vision y Windows OCR, el OCR que ya tienes si no instalas nada en absoluto.
5. La precisión es la base. La usabilidad es el objetivo.
Los números muestran que Gety lee con precisión. Pero la precisión no es la meta final; es la base de una experiencia OCR útil.
El flujo de trabajo habitual de una herramienta OCR se parece a esto:
Encontrar la imagen -> Abrirla o arrastrarla a una herramienta OCR -> Iniciar el reconocimiento manualmente -> Esperar el resultado -> Obtener texto utilizableLa mayoría de las veces, esa cadena ni siquiera empieza. Las capturas y los escaneos se convierten en puntos ciegos en cuanto llegan a tu computadora, y siguen siendo invisibles para la búsqueda hasta que recuerdas procesarlos.
Ese vacío es el problema que Gety se propuso cerrar. El OCR se ejecuta en segundo plano, así que en cuanto llega un archivo de imagen, Gety puede reconocerlo e indexarlo automáticamente. Nada que convertir, nada que pulsar. Cuando lo necesitas, escribes en el buscador global y el texto dentro de la imagen está ahí.
La precisión decide la calidad del reconocimiento. El consumo de recursos decide si ese reconocimiento puede estar siempre activo. No nos propusimos lanzar un motor de OCR más; nos propusimos hacer que «las palabras de esta imagen no se pueden buscar» sea un problema que deje de ocurrir en tu computadora.
Estos son nuestros propios resultados internos. Usamos las imágenes de documentos de los conjuntos de datos públicos MDPBench y OmniDocBench como material de prueba, pero el método de evaluación y las métricas son nuestros y difieren de las evaluaciones oficiales publicadas por los autores de los conjuntos de datos. Cada conjunto de datos conlleva su propia licencia y sus propios términos de uso, algunos solo para investigación; aquí informamos de hallazgos, no redistribuimos ninguna muestra.