En el mundo de la captura documental los documentos se han dividido tradicionalmente en tres tipos; estructurados, semi estructurados y no estructurados.

Hace más de 20 años, los primeros programas de captura se centraban en capturar información de documentos estructurados, en los cuales se sabía en qué posición estaba cada uno de los datos. En aquella época, en la que el uso de páginas web no estaba todavía extendido, era habitual utilizar este tipo de formularios para comunicarse con las empresas y se consiguió automatizar miles de procesos de captura de este tipo (pedidos, encuestas, partes de trabajo, exámenes, etc.)

Después se empezó a automatizar la captura de documentos semi estructurados, en los cuales los datos varían de posición, pero se pueden crear reglas para encontrarlos. El proyecto típico era la captura de facturas de proveedores, en los que se conseguía capturar alrededor de un 70% de los datos automáticamente. Posteriormente se introdujo la técnica de aprendizaje automático de plantillas de proveedores, que ahora se anuncia como “Machine Learning”. Esta técnica hace que el software aprenda cómo es la factura de cada proveedor después de que el usuario haya indicado dónde están los datos. Una vez aprendidos los principales proveedores y combinando aprendizaje con el uso de reglas, se conseguía capturar más del 90% de los datos de las facturas. En los últimos 10 años hemos implementado cientos de proyectos de este tipo y hoy día seguimos ayudando a compañías que todavía no han automatizado su proceso de cuentas a pagar.

Y no ha sido hasta hace unos pocos años que se ha empezado a trabajar en la captura de documentos no estructurados, en los que no existen reglas a aplicar y en los que tampoco se puede utilizar técnicas de aprendizaje de plantillas porque no se suelen repetir documentos del mismo tipo (plantillas). Es el caso de la captura de datos de hipotecas, escrituras,  actas notariales o correos electrónicos que lleguen a una cuenta.

Para extraer información de estos documentos se han de utilizar técnicas de inteligencia artificial y, más específicamente, de Procesamiento de Lenguaje Natural (NLP en inglés). Existen muchos servicios y programas que usan NLP (MicroSoft, Google, etc.) pero la mayoría están focalizados en la extracción de etiquetas o atributos (por ejemplo, obtener todos los nombres que aparecen en un documento) y en análisis de sentimiento (el texto indica algo positivo o negativo). Además, sus bases de conocimiento están creadas con lenguaje natural (el lenguaje que hablamos normalmente), que no suele ser el lenguaje que se utiliza en documentos de negocio. Por ello es importante utilizar una herramienta que sea capaz de usar técnicas NLP para encontrar datos específicos de un documento (por ejemplo, si existen varios nombres en un documento, debe indicar quién es el Notario y quién el Compareciente). Las herramientas más generalistas no suelen servir para este propósito.

Para entender cómo funciona este tipo de soluciones, a continuación muestro un ejemplo de cómo se realiza la captura de datos de Escrituras. El proceso se divide en 3 partes:

• Aprendizaje, es la fase clave, en la cual se debe seleccionar una muestra de documentos significativa (o suficientemente grande) y enseñar al sistema dónde están los datos que buscamos. El motor de inteligencia artificial analiza los textos (técnica NLP), tanto los que contienen los datos a buscar como los que les rodean (contexto) para encontrar patrones y asignarles un peso.

El entrenamiento se realiza antes de entrar en producción, aunque siempre se puede ajustar posteriormente con nuevas muestras. Como resultado, el software creará una base de conocimiento conteniendo todo el análisis de patrones.

En este vídeo muestro cómo se realiza la fase de aprendizaje usando unas muestras de Escrituras como ejemplo:

• Reconocimiento. Ya en la fase de producción, lo primero que se realiza es el reconocimiento de los documentos. En este momento se aplica la base de conocimiento a cada documento para encontrar los patrones que puedan coincidir en cada uno de los datos. Además del dato en sí mismo, el software devuelve un porcentaje de confianza.

La fase de reconocimiento se suele ejecutar de manera autónoma y como un servicio invisible a los usuarios. Sin embargo, en este vídeo muestro cómo se realizaría manualmente y lo rápido que es:

• Validación. Tras el reconocimiento se realiza la Validación de aquellos documentos en los que hay alguna incidencia o algún campo no ha podido ser encontrado.

Es importante recordar que todo este tipo de soluciones de captura tiene como objetivo final la reducción del tiempo total del proceso. El objetivo nunca debe ser alcanzar un cierto porcentaje de reconocimiento. En otras entradas del blog ya he analizado más en detalle este tema, porque todavía hay gente que se centra solamente en los porcentajes de captura.

En este vídeo muestro los resultados del reconocimiento anterior aplicado a Escrituras. En una solución en producción el software solamente se parará en aquellos datos que tengan una incidencia a resolver por el usuario pero en este caso he ido parando en cada uno de los datos para que se pueda ver el resultado de la extracción:

Cada vez surgen más proyectos para capturar documentos no estructurados y pienso que será la tendencia en los próximos años. Espero seguir publicando más proyectos de éxito mostrando otros tipos de documento no estructurados.

¿Alguna vez habéis oído la expresión «llevar un escáner en el bolsillo»? Lo dispositivos móviles (teléfonos y tabletas) tienen muchísimas funciones útiles para el usuario y, entre ellas, hoy quiero destacar la posibilidad de capturar documentos.

Y cuando hablo de capturar un documento me refiero a obtener una imagen fiel del mismo y no me refiero a sacar una foto cualquiera. La imagen de un documento no debería tener ningún tipo de fondo, debería estar rotada correctamente y ser perfectamente legible. ¡Cuántas veces me he encontrado un repositorio documental lleno de fotos de DNIs girados, de mala calidad y en las que se ven manteles de fondo, mesas, dedos, etc! Esto no es un repositorio documental sino un repositorio de imágenes a las que no se le puede sacar mucho partido. Por ejemplo, no se les puede hacer OCR para extraer datos, no se puede comprobar si el documento es auténtico y no se pueden extraer elementos como la foto y la firma.

Quizás en nuestra vida personal no es algo que nos importe demasiado, pero en el mundo empresarial la gestión de la información es fundamental para el negocio. Y cuanto mayor calidad tenga un documento y más sencillo le sea a un cliente enviar documento, mejor y más rápidamente se podrá dar servicio a dicho cliente. Esto crea una clara ventaja competitiva y por ello vemos ejemplos de compañías que permiten a sus clientes enviar documentación con sus dispositivos móviles o habilitan a sus propios empleados (en sucursales, oficinas remotas o los que van por la calle) con aplicaciones móviles que facilitan el envío de documentos sin necesitar ningún otro aparato.

Para dar una idea de lo que se puede realizar con un teléfono móvil, he creado el siguiente vídeo, en el que muestro distintos escenarios en los que se captura un documento obteniendo una calidad tan buena que incluso se puede hacer OCR y extraer datos del mismo.

¿Tú también usas el escáner que llevas en el bolsillo?

Todavía sigo viendo proyectos en los que se mide el éxito de un sistema de captura de datos en base al porcentaje de acierto del OCR. Incluso en algunas pruebas de concepto el cliente todavía tiende a comparar las distintas soluciones en función de los porcentajes de extracción obtenidos.

Supongo que en parte ha sido culpa nuestra, de los proveedores de tecnología, que en el pasado nos centrábamos mucho en este parámetro y siempre intentábamos mejorarlo lo máximo posible en las implementaciones. Este año Kofax sacó una publicación en torno a este tema: The truth about ocr accuracy, que quiero difundir entre todos los que estén interesados en capturar datos de documentos.

La cuestión básica es que el porcentaje de captura (o de OCR) no es un parámetro significativo para el negocio. Por ejemplo, ¿qué decisión puede tomar un directivo si le contamos que una solución tiene un porcentaje de captura del 80% y otra solución tiene un porcentaje del 70%? Pues posiblemente ninguna! ¿Cómo podría entender la repercusión de cualquiera de ellas en su negocio? o cómo calcularía un posible retorno de la inversión? No podría! Y lo  más probable es que solicite más información para entender las implicaciones que tiene el proyecto en su negocio.

Sería demasiado simple pensar que la primera solución es mejor solamente con este dato. ¿Qué ocurriría si esta primera solución tiene menos funciones para facilitar la gestión de las excepciones (los datos que no han podido ser capturados)? Supongamos que con la primera solución se tarda el doble de tiempo en solventar cada excepción. Con esta hipótesis podría ser más rápido arreglar el 30% de excepciones de la segunda solución que el 20% de excepciones de la primera. Es decir, la segunda solución sería más efectiva de cara al negocio, ofreciendo mayores beneficios al cliente. De hecho, cuanto mayor sea el volumen de documentos a procesar mayor será el beneficio en comparación con la primera solución. En la publicación mencionada anteriormente se describen técnicas que facilitan la gestión de excepciones.

Otro factor que puede alterar nuestra percepción es el umbral de reconocimiento (probabilidad límite para aceptar un dato como correcto). Es un número (entre 1 y 100) que se define manualmente. Normalmente sólo se aceptan datos con un umbral de reconocimiento alto (por ejemplo, mayor del 80%). Si la primera solución ha bajado mucho este umbral (pongamos que al 25%) es posible que acierte alguna vez y eso aumenta su porcentaje de acierto pero ya no te puedes fiar de los datos que devuelve porque muchos serán incorrectos. Por ello toda la información se deberá confirmar manualmente (hay que validarlo todo porque no se sabe cuándo acertará).

Si la segunda solución ha puesto un umbral más alto, garantiza una mejor calidad de la información extraída pero al rechazar más datos se penalizará su porcentaje de acierto. La paradoja es que ambos podrían estar devolviendo exactamente los mismos datos pero la segunda solución parecería peor. En ambos casos el usuario deberá gestionar el dato manualmente (o por validación o por rechazo), por lo que vuelve a ser más relevante el tiempo que necesita el empleado en gestionar las excepciones.

En resumen, el porcentaje de OCR es un dato indicativo pero no suficiente. Lo que realmente interesa conocer es el tiempo total que se tarda en procesar un documento de media, desde el principio hasta el final. Este tiempo dependerá tanto del porcentaje de OCR como de la rapidez en gestionar las excepciones. Con esta información sí se pueden tomar decisiones. Por ejemplo, si una solución me permite procesar documentos en 70% menos tiempo que hoy en día manualmente, muy posiblemente me interese implementarla. Si la solución A me permite procesar 1000 documentos al día y la solución B procesa 800 documentos al día, ya puedo calcular cual me va a ofrecer un mejor retorno de la inversión.

Si aun así alguien está solamente interesado en el porcentaje de OCR mi recomendación sería que eligiera simplemente un motor de OCR (los hay incluso gratuitos) y no una solución completa de captura.

Finalmente quisiera resaltar que en la implementación moderna de este tipo de soluciones, donde se tratan documentos cada vez más complejos, el porcentaje de OCR es cada vez menos relevante. Tradicionalmente, trabajando con documentos más estructurados, se han utilizado sistemas basados en reglas para capturar información. Íbamos añadiendo más y más reglas para ir mejorando dicho porcentaje, pero cada vez se hacía más complicado porque cada nueva regla afectaba a las anteriores, por lo que la mejora acaba estancándose en algún momento. Hoy en día los proyectos capturan documentos más complejos como hipotecas, escrituras, actas, etc. y se basan mayoritariamente en técnicas de Machine Learning. Es decir, se deja que el sistema vaya aprendiendo solo a medida que procesa documentación. No se implementan reglas. El problema de esta técnica de inteligencia artificial es que necesita muchas muestras para aprender bien. Como no se suelen tener tantos ejemplos, los proyectos comienzan con porcentajes más bajos de reconocimiento y todo el foco de la implementación se pone en el diseño de formularios eficaces para la corrección e introducción de datos. El retorno de la inversión no es tan rápido pero el coste de procesar manualmente estos documentos complejos es muy alto y con el paso del tiempo (y documentos) la solución va aprendiendo sin parar y el ahorro acaba siendo significativo.