¿Cuando necesito usar OCR en mi proceso de RPA?

Para los que venimos del mundo de la gestión documental y digitalización el término OCR (Optical Character Recognition) nos resulta bastante común. Para muchos otros les hace recordar cuando compraron su primer scanner (de esos que se conectaban por LPT o SCSI) y luego con algún software como OmniPage o Finereader generaban archivos editables en Word y se ahorraban tener que tipear  ese trabajo practico o articulo que habían conseguido para aprobar alguna materia, WOW era toda una experiencia! (para los que somos nerd obviamente).




Seguramente ya pasaron mas de 20 años de esas vivencias, años durante los cuales hemos visto una sorprendente evolución tecnológica. Muchos dispositivos y sistemas de aquella época quedaron obsoletos y ya no existen mas, pero muchos otros han sobrevivido y se han ido mejorando para alcanzar las altísimas demandas del mercado actual y ese es el caso de los OCR, una disciplina de la vieja escuela que ahora converge con potentes herramientas de automatización como RPA (Robotic Process Automation)

Ahora, en que situaciones me conviene usar OCR al diseñar mis procesos RPA? Se me ocurren 2 casos:

Procesos de grabación

Una de las características que hace a un RPA es su capacidad de "automatización de escritorio" (Desktop Automation) o sea el poder emular acciones que haría un usuario con teclado y mouse. Para esto se generan grabaciones de acciones por pantalla que el robot después repetirá. Estas acciones requieren de que el robot logre identificar correctamente los elementos de la interfaz gráfica, algo que en la mayoría de los casos logra de forma nativa con información univoca obtenida de la aplicación, el sistema operativo o del HTML en el caso de sistemas Web. Ese es el Plan A.

Cuando estas grabaciones no funcionan correctamente intentamos el Plan B, que involucra hacer ajustes en los selectores de elementos de la interfaz gráfica para que estos den con su destino, y en algunos casos nos valdremos de "anclajes" o sea seleccionar elementos circundantes de mayor confiabilidad para ubicar al robot en el lugar indicado.

Si con esto aun no podemos resolver nuestra secuencia de grabación es que entra en juego el OCR. Este forma parte del Plan C, o sea cuando los métodos de selección no permiten determinar de forma certera un elemento, algo que puede pasar al trabajar con sistemas desarrollados en entornos de programación anticuados o cuando nuestro robot necesita interactuar vía escritorio remoto. En estos casos el robot "sacará una foto" de la porción de la pantalla en cuestión y el OCR obtendrá el texto para luego poder identificar el elemento con el que queremos accionar.

Reconocimiento de documentos escaneados

También podemos usar OCR para obtener texto de documentos escaneados. Pero igual que en el caso anterior es importante que entendamos que este proceso no es 100% preciso por lo cual es conveniente usarlo solo en los casos necesarios. Por ejemplo, si necesitamos obtener información de un PDF y este es de origen digital contamos con actividades especificas para obtener el texto con total precisión sin necesidad de que un OCR analice la imagen. Sí obviamente necesitaríamos usarlo cuando trabajamos con documentos "digitalizados".

Aun así un OCR estándar no resuelve la problemática de localizar campos específicos que sean requeridos por nuestro proceso, por lo cual acá se nos abren algunas opciones adicionales:

  • Localizar datos mediante actividades de matcheo por expresiones regulares. Esto nos permite analizar los resultados generados por el OCR y quedarnos solo con los datos requeridos.
  • Usar un addon de tipo Intelligent OCR. Muchas herramientas como UiPath proponen addons como ABBYY Flexicapture con amplias capacidades de clasificación y extracción con licenciamiento adicional.
  • Conectar con servicios cloud. Hay un gran numero de servicios de localización de datos en imágenes como Google Cloud Vision o AWS Rekognition aunque en la mayoría de los casos si estamos tratando con imágenes de documentos lo mas probable es que necesitemos un servicio que provea los campos claves como Rossum o Cinnamon AI. En estos últimos casos deberemos tener presentes que los modelos de ML/AI utilizados estén entrenados con documentación local también y no solo ejemplos de otros países.  En esta misma categoría y con una mirada local nosotros creamos Digi24 (https://digi24.com.ar) un servicio en modalidad API de muy fácil uso y con amplias capacidades de customización en base a las necesidades del proceso.
Muchos otros también están encarando el desarrollo de modelos propios de ML/AI con Python u otros entornos de programación y frameworks idóneos para el caso, algo que sin duda es el camino a seguir, pero con mucho trecho por recorrer.

Comentarios

Entradas populares de este blog

Código de barra 2D en nuevo DNI argentino

Como está compuesto el código de barras AFIP en Facturas electrónicas

Nuevo formato de código de barras AFIP en Facturas electrónicas