Surya OCR

Surya OCR es un proyecto de procesamiento de documentos que extrae texto y estructura de página de imágenes y archivos PDF. Conviene evaluarlo cuando una aplicación necesita algo más que una cadena de texto, como el orden de lectura o las regiones de una tabla. La versión es una condición importante: esta guía trata la documentación actual de Surya 2, no las interfaces antiguas que todavía aparecen en algunos tutoriales. Una instalación correcta es solo el comienzo. La prueba de aceptación debe comprobar si el documento extraído conserva su significado.

Esta evaluación se basa en fuentes revisadas el 10 de septiembre de 2026. No ejecutamos un benchmark de OCR ni procesamos documentos de clientes. El flujo siguiente es una propuesta de prueba adaptable con condiciones explícitas de rechazo, no una puntuación de precisión inventada.

Revisión del código y la documentación consultada: a2363d33.

Defina qué debe sobrevivir a la extracción

Empiece por la operación que consumirá el resultado. Buscar en un archivo exige pruebas distintas a importar una factura en un sistema contable. Un índice de búsqueda puede tolerar un encabezado decorativo dañado si el usuario todavía encuentra la página correcta. Un importador de facturas no puede tratar un número de cuenta verosímil pero incorrecto como un problema menor de formato.

Considere un equipo hipotético que recibe PDF de proveedores. Algunos contienen texto digital limpio. Otros son escaneos con un sello, una dirección en dos columnas o una tabla que continúa en la página siguiente. El resultado deseado no es simplemente “OCR completado”. El equipo necesita un registro revisable en el que proveedor, artículos, cantidades y totales sigan asociados a sus ubicaciones de origen.

Escriba los requisitos antes de elegir la configuración. Identifique los campos que nunca deben aceptarse sin verificación, las estructuras que deben permanecer enlazadas y los casos que deben pasar a una cola humana. Así, un párrafo legible no ocultará una tabla inutilizable. Cada flujo candidato debe conservar la misma información y no limitarse a producir una vista previa atractiva.

La documentación del proyecto presenta Surya para documentos, no para texto en escenas naturales. Una fotografía de un escaparate o una señal en movimiento requiere otra evaluación. La compatibilidad con muchos idiomas no demuestra que sirva para cualquier imagen de cámara. Alcance y limitaciones de Surya.

Identifique la versión instalada antes de copiar ejemplos

El nombre de la familia de modelos y la versión del paquete de Python son identificadores distintos. En la fecha de revisión, la configuración declaraba la versión 0.22.1 y compatibilidad con Python desde la 3.10. Registre el paquete realmente instalado, checkpoint, backend y entorno. Un comando copiado sin esos datos no constituye una integración reproducible. Configuración del paquete.

Las notas actuales de migración sustituyen el antiguo foundation predictor por un inference manager y describen cambios en los campos de salida. Trate una actualización como un cambio del contrato de la aplicación. Antes de procesar una colección, examine un resultado real y confirme que su parser lee los campos devueltos por esa versión. Migración desde Surya v1.

El schema actual representa una página como bloques y un límite de imagen. Los bloques incluyen orden de lectura, contenido HTML e indicadores explícitos de omisión o error. Un bloque vacío no debe convertirse automáticamente en un valor vacío de base de datos. Conserve estado suficiente para distinguir una región omitida de forma intencionada, un fallo de reconocimiento y un área sin texto. Schema de reconocimiento.

En una integración existente, guarde un resultado antiguo representativo junto al nuevo y compare primero la estructura. Revise campos renombrados, anidamiento, orden de páginas y tratamiento posterior de valores ausentes. Una prueba de schema que pasa mientras elimina todas las tablas en silencio no es aceptable.

Separe el permiso del código del permiso de los pesos

El código del repositorio utiliza Apache 2.0. Los pesos del modelo tienen una licencia modificada OpenRAIL-M independiente. Describir el sistema completo simplemente como GPL o suponer que la licencia del código permite usar los pesos sin restricciones oculta la decisión real de una organización. Licencia del código, licencia de los pesos.

El Anexo A incluye restricciones relacionadas con ingresos brutos del año anterior superiores a cinco millones de dólares estadounidenses, financiación total mediante capital o deuda superior a esa cantidad y productos o servicios que compitan con los del licenciante. Las excepciones para uso personal o investigación en las disposiciones de ingresos y financiación no equivalen a la restricción de uso competitivo. No lo convierta en una afirmación general de que toda pequeña empresa cumple. Lea los términos completos para su organización y despliegue, y solicite aclaración cuando corresponda. Esta guía informa sobre la licencia, pero no concede autorización legal.

Los documentos también requieren una revisión independiente. El permiso para ejecutar un modelo no demuestra el derecho a cargar registros de proveedores, conservar identificadores indefinidamente o reutilizarlos para entrenar otro sistema. Registre quién controla la entrada, quién puede ver el resultado y qué entorno está autorizado para procesarlo.

Prepare una muestra pequeña que revele errores costosos

Para el caso de proveedores, elija una muestra limitada que represente los problemas reales. Incluya un PDF digital limpio, un escaneo con texto tenue, una página girada, un documento con varias columnas y una tabla con encabezados repetidos. Son categorías propuestas, no una afirmación de que Surya tendrá éxito o fallará en cada una.

Antes de ver la salida del modelo, una persona debe transcribir los campos críticos y marcar la secuencia esperada. De otro modo, el texto generado se convierte en su propia referencia. Mantenga la página original junto a la transcripción y marque como ambiguo cualquier carácter que realmente lo sea.

Asigne un identificador estable a cada página. Guarde el hash de entrada, dimensiones, configuración y ruta de salida. No incluya documentos privados en informes públicos de errores ni capturas compartidas. Cuando sea posible, reproduzca un problema del parser con un sustituto no sensible que conserve el layout y márquelo como fixture de diagnóstico.

Ejecute primero la muestra mínima. Siga el resultado desde la entrada, a través de su parser, hasta la aplicación de destino. No evalúe solo la vista previa de Surya. Enviar todo el archivo a un parser no validado aumenta el trabajo de corrección sin aportar mejores pruebas sobre la primera suposición rota.

Use una hoja de aceptación en lugar de un único número

La siguiente hoja es una propuesta editorial para el ejemplo de documentos de proveedores. Defina las tolerancias reales con las personas responsables del sistema de destino. No contiene resultados medidos de Surya.

Separe errores críticos de diferencias cosméticas. Un salto de línea puede ser inofensivo para búsqueda e inaceptable para un formulario de layout fijo. Esa distinción pertenece a la política de aceptación, no a una decisión improvisada después de ver el resultado. Registre el motivo de cada clasificación para que la siguiente persona pueda aplicar la misma regla.

Incluya el trabajo de revisión en el resultado. Si la salida reduce escritura pero exige buscar páginas repetidamente, el flujo puede seguir siendo más lento. Mida el tiempo hasta obtener un registro corregido y aceptado, incluidos los fallos. De este modo, la muestra sirve para tomar una decisión operativa y no solo para demostrar el modelo.

Mida el inicio y el procesamiento por separado

La documentación actual describe vLLM para GPU NVIDIA y llama.cpp para CPU o Apple Silicon. La instalación debe considerar un proceso de inferencia además del paquete de Python. Registre el backend de forma explícita. “Funcionó localmente” no describe con precisión suficiente el hardware ni el software. Documentación de backend.

El archivo de configuración expone por separado la caché de modelos, el endpoint y el ciclo de vida del servidor. Un comando local puede usar un endpoint remoto y el primer uso puede descargar modelos. Confirme el comportamiento real de red y el recorrido de los documentos antes de llamar al despliegue offline o apto para material confidencial. Configuración de inferencia.

Registre por separado el arranque en frío, el procesamiento con el servidor preparado, la conversión de salida y la corrección humana. Compare ejecuciones sobre la misma muestra e informe también los fallos. Una ejecución rápida con el servidor preparado no indica cómo se comportará una tarea programada que inicia un entorno nuevo para cada documento.

Cambie resolución o concurrencia de una en una y vuelva a comprobar el texto pequeño y la tabla más exigente. Observe el proceso completo para detectar presión de memoria o una salida truncada. Mantenga la configuración anterior hasta que la sustituta supere la misma hoja de aceptación. Una ejecución más rápida que pierde el separador decimal del proveedor no es una optimización útil.

Localice la etapa rota antes de repetir

Observe juntos la página de origen, el resultado bruto y el registro importado. Si el texto ya es incorrecto en el resultado bruto, cambiar el mapeo de base de datos no arreglará el reconocimiento. Si el resultado bruto es correcto y las filas se mezclan después de importar, repetir el modelo no resolverá el parser.

No repare una fuente ambigua inventando en silencio el texto más probable. Conserve una marca de incertidumbre o envíe la página a revisión. Esto es especialmente importante cuando una salida fluida anima a confiar en un valor que apenas era legible en el original.

Elija el siguiente flujo a partir de las pruebas

Si el PDF original ya contiene texto y estructura utilizables, compare la extracción directa antes de añadir OCR. Para una colección pequeña con escritura difícil o tablas muy irregulares, una transcripción supervisada puede ser más controlable que una integración extensa. Son alternativas de proceso, no afirmaciones de que un competidor concreto sea superior.

Un servicio gestionado de documentos es una decisión operativa diferente de alojar Surya. Evalúe de forma independiente sus términos actuales, controles de retención, contrato de salida y carga total de revisión. Usar un modelo relacionado no hace que el servicio sea idéntico al repositorio ni transfiere sus pruebas locales.

El resultado útil es un límite documentado: qué clases de documento pueden entrar en el pipeline, qué campos requieren verificación y qué fallos detienen la importación automática. Conserve ejemplos rechazados como conjunto de regresión de acuerdo con las normas de retención y repítalo cuando cambien paquete, checkpoint, backend o parser.

Esta evaluación no establece precisión universal por idioma, cumplimiento de privacidad en producción ni garantía de procesamiento desatendido de facturas. Ofrece una forma de probar el trabajo concreto. Puede explorar otras categorías en el directorio de modelos y aplicar la misma disciplina de fuentes y aceptación.