🧾DeepFacture🧾: Cuando el deep learning controla visualmente las facturas

Compartir por correo electrónico

Antes de la digitalización total, las facturas eran revisadas visualmente por los agentes. Hoy en día las facturas están totalmente desmaterializadas, por lo que nadie comprueba su disposición, legibilidad y coherencia con sus metadatos. En Francia, el control de un flujo de datos de facturas (ORMC: Order of Multi Creditor Receipt) puede llevar hasta un día completo. El flujo de datos ORMC es enviado por más de 10 de nuestros productos como Sedit GF, eGFEvolution, BL.enfance, E.FACTU (STD) Standard, E.FACTU (PTL) Point de livraison, E.FACTU (EAU) Eau et assainissement, MILORD EAU, MILORD FACFAM (Facturation aux familles), MILORD FACT97 (facturation diverses), MILORD HEB98 (Facturation EHPAD).

DeepFacture es una herramienta que resuelve el problema mencionado gracias a sus numerosos puntos fuertes :

  • Formación rápida: sólo una veintena de documentos anotados permiten a la IA aprender y funcionar.
  • Potente: 1 segundo es suficiente para analizar un documento. 4 minutos para un flujo de 260 facturas.
  • Agrupado: DeepFacture es API (REST / Open API 3.0), está preparado para la nube, es fácil de integrar y es accesible para todos.
  • Extensible: puede extenderse a todos los documentos estándar: Billetes, boletines, documentos de identidad, pasaportes, cheques, documentos de matriculación de vehículos, cartas, formularios, etc.
  • Buscar en: el fruto de nuestra investigación en análisis de imágenes y Deep Learning a lo largo de los años.
  • Código abierto: basado exclusivamente en bibliotecas de código abierto del mundo académico.

Cómo funciona

Los productos de Berger-Levrault para las autoridades locales generan flujos de facturas que se envían a la DGFIP en formato XML. La normativa impone un cierto número de reglas relativas a la forma y al contenido de estos flujos, así como a la carta gráfica de las facturas. La siguiente figura ilustra un ejemplo de estas normas. Los cuadros de direcciones del remitente y del destinatario deben situarse en lugares específicos. Los valores de estos campos también deben ser similares a los mencionados en las etiquetas XML del flujo.

Carta gráfica de la DGFIP

Un flujo que no cumple es sistemáticamente rechazado por el DGFIP. En efecto, el incumplimiento puede tener consecuencias nefastas para miles de personas: la no recepción del correo debido a una dirección no legible o mal colocada, la no consideración de un pago, los duplicados en el DGFIP base de datos, etc. Para garantizar que los flujos generados cumplan la normativa, es importante incluir en el proceso una fase de control que explore todas las facturas y compruebe que se cumplen todas las normas. Esta fase de control la realiza actualmente el personal humano. Es un trabajo repetitivo, tedioso y que requiere mucho tiempo. En efecto, para un flujo determinado hay que realizar decenas de controles sobre cientos de facturas. El control de un flujo puede durar varias horas.

El objetivo del proyecto DeepFacture es desarrollar una API que automatice la verificación de los flujos destinados al DGFIP. La siguiente figura muestra la interacción de la API con el mundo exterior, así como su arquitectura interna. La API recibe un feed XML como entrada, analiza el contenido de cada factura, comprueba el cumplimiento de cada regla y devuelve un informe JSON como salida, en el que se especifica si el feed es conforme y, en caso contrario, los motivos.

Una visión funcional y arquitectónica de la API de DeepFacture

Localización de objetos y extracción de datos de un PDF

La API de DeepFacture debe ser capaz de localizar los diferentes elementos de la factura (campos de dirección, logotipo...) y extraer el valor de cada elemento. En el estado del arte, hay dos enfoques para hacer esto [1] :
Coincidencia de patronesEl enfoque intuitivo consiste en identificar patrones en los documentos y utilizarlos para extraer información. Por ejemplo, el importe total de una factura suele ser un número decimal a la derecha de la palabra "Total". En la literatura existen varias técnicas para la comparación de patrones [2]-[5]. Los patrones pueden implementarse con una expresión regular o generarse con una anotación manual más una heurística.

  • Ventaja: La comparación de plantillas funciona bien cuando los documentos son homogéneos y están estructurados.
  • DesventajaLa creación y el mantenimiento de las plantillas requieren tiempo y experiencia. Además, no se extiende a otras plantillas de documentos.

Aprendizaje automáticoEste enfoque se basa en un modelo entrenado a partir de un corpus de documentos anotados. Algunos trabajos consideran la tarea como una clasificación de palabras. Para cada palabra del documento, se decide si hay que extraerla o no. Si hay que extraer varios valores (total, fecha, etc.) la tarea se convierte en una clasificación multiclase. Para resolver el problema, estos trabajos han optado por la ingeniería de rasgos más un modelo de aprendizaje automático clásico como las SVM [6], o las incrustaciones de palabras más las redes neuronales [7]-[11]. También hay trabajos que proponen un enfoque integral. En este caso, el modelo considera el documento como un todo y no indica la ubicación de la información a extraer, sino que devuelve directamente el valor de la información buscada [1].
Los documentos también pueden verse como imágenes (en el caso de las digitalizaciones, por ejemplo). En este caso, resulta interesante explotar los métodos de localización de objetos en imágenes: YOLO [12], Single Shot MultiBox Detector [13], Fast R-CNN [14], Faster R-CNN [15], Feature Pyramid Networks [16]... Una vez detectado el objeto, se utiliza un OCR para extraer el texto que contiene.

  • VentajaEl enfoque está bien generalizado para muchas plantillas de documentos.
  • Desventaja: la necesidad de contar con un corpus amplio en el que haya que etiquetar cada palabra. La anotación manual es un proceso costoso y, por tanto, no es factible en muchos casos.
Clasificación de las obras existentes

Para el proyecto DeepFacture, tenemos varios formatos de factura con posibles elementos mal colocados. Además, DGFIP Las reglas pueden evaluarse en cualquier momento. Establecer todas las reglas posibles es tedioso y poco razonable para un enfoque de "cotejo de plantillas". Queremos adoptar una solución que tenga en cuenta los documentos escaneados y que se generalice a otros formatos de documentos, con el fin de explotar el pipeline para otros proyectos futuros. El enfoque adoptado es, por tanto, la extracción de información con "machine learning". Más concretamente, utilizamos técnicas de aprendizaje profundo para localizar objetos en las imágenes.

Proceso DeepFacture

La respuesta a esta pregunta se ilustra en la siguiente figura. Utilizamos un R-CNN más rápido (implementado en la biblioteca Python Detectron2) para localizar los objetos en la factura. Este modelo devuelve las coordenadas y la clase de cada objeto. A continuación, utilizamos una función de reconocimiento óptico de caracteres (implementada en la biblioteca Tesseract ) para extraer la información textual del objeto. Por último, utilizamos las funciones de control que hemos implementado para comprobar si la factura es buena o no. Estas funciones se basan en la lista de objetos (con sus coordenadas, clase y texto), los metadatos del flujo XML y el DGFIP normas para analizar la conformidad de la factura.

Proceso de verificación de facturas

El aprendizaje supervisado necesita datos anotados

El enfoque que hemos adoptado requiere datos anotados para impulsar el modelo de localización de objetos. Actualmente estamos desarrollando una interfaz web para la anotación de imágenes. Ya tenemos una versión que permite cargar una factura, luego anotar visualmente los objetos y, finalmente, escribir el resultado en un archivo. El contenido de este archivo se utiliza para entrenar el modelo Faster R-CNN. La siguiente figura en una vista previa en esta interfaz.

Anotación de la factura

Para evaluar la calidad del modelo nos basamos en la "precisión media" [17]. El código OpenSource para la evaluación está disponible en Internet. A continuación, la preparación del Test-set: construimos un conjunto de facturas anotadas lo más general posible en términos de Plantilla y tipos de errores, tomamos de 80% a 85% del total de facturas anotadas para entrenar el modelo, el resto de las facturas para probarlo.

Nuestro objetivo: ¡Anotar lo menos posible!

El aprendizaje profundo suele requerir muchos datos anotados para converger de forma fiable. En nuestro caso, conseguimos construir un modelo que sólo requiere entre 20 y 30 facturas anotadas para converger con excelentes resultados. Hay varias formas de lograr ese objetivo:

  1. Generar un corpus artificialUna base de direcciones preestablecida, un texto generado aleatoriamente o procedente de la web u otra fuente, números generados aleatoriamente, una ubicación generada aleatoriamente.
  2. Utilizar el "aumento de datos": toma facturas correctas y bien estructuradas, y luego mueve, redimensiona y modifica los objetos de forma aleatoria.
  3. Utilizar un modelo preentrenadoUn primer pase de entrenamiento con un corpus genérico grande. Un segundo pase de entrenamiento con el pequeño corpus específico de facturas.

Para nuestras primeras pruebas, utilizamos un Faster-RCNN modelo (con el Detectron2 biblioteca). Hicimos un pase de entrenamiento con algunas docenas de facturas que anotamos. Los resultados obtenidos fueron satisfactorios. En el siguiente ejemplo, utilizamos la plantilla entrenada para localizar la dirección del destinatario, la dirección del remitente y el logotipo.

Ejemplo de ubicación de elementos en una factura

Conclusión

En este artículo, hemos presentado DeepFacture, un proyecto para satisfacer las necesidades de nuestros minuciosos equipos en lo que respecta a la automatización del control de las facturas enviadas al DGFIP. El enfoque adoptado para extraer la información es el uso de técnicas de redes neuronales para la detección de objetos en imágenes. Actualmente estamos interesados en desarrollar una interfaz web genérica que permita no sólo anotar las imágenes, sino también parametrizar, ejecutar el entrenamiento y reentrenar el modelo. La experiencia ha demostrado que la línea de producción propuesta puede extenderse a otros casos de estudio. En el futuro, nos interesarán otros usos. Por ejemplo, la extracción de información de tarjetas de identificación de hospitales, etc.

Referencias

1] R. B. Palm, F. Laws y O. Winther, "Attend, copy, parse end-to-end information extraction from documents", en Conferencia internacional de 2019 sobre análisis y reconocimiento de documentos (ICDAR), 2019, pp. 329-336.
2] E. Medvet, A. Bartoli y G. Davanzo, "A probabilistic approach to printed document understanding" (Un enfoque probabilístico para la comprensión de documentos impresos). Int. J. Doc. Anal. Reconocimiento., vol. 14, no. 4, pp. 335-347, 2011.
3] D. Esser, D. Schuster, K. Muthmann, M. Berger y A. Schill, "Automatic indexing of scanned documents: a layout-based approach", en Reconocimiento y recuperación de documentos XIX, 2012, vol. 8297, p. 82970H.
[4] D. Schuster y otros."Intellix-End-User Trained Information Extraction for Document Archiving", en 2013 12ª Conferencia Internacional de Análisis y Reconocimiento de Documentos, 2013, pp. 101-105.
5] M. Rusinol, T. Benkhelfallah y V. Poulain dAndecy, "Field extraction from administrative documents by incremental structural templates", en 2013 12ª Conferencia Internacional de Análisis y Reconocimiento de Documentos, 2013, pp. 1100-1104.
6] Y. Li, K. Bontcheva y H. Cunningham, "SVM based learning system for information extraction", en Taller internacional sobre métodos deterministas y estadísticos en el aprendizaje automático, 2004, pp. 319-339.
7] T. Mikolov, I. Sutskever, K. Chen, G. Corrado, y J. Dean, "Distributed representations of words and phrases and their compositionality," arXiv Prepr. arXiv1310.4546, 2013.
8] J. Pennington, R. Socher y C. D. Manning, "Glove: Global vectors for word representation", en Actas de la conferencia 2014 sobre métodos empíricos en el procesamiento del lenguaje natural (EMNLP), 2014, pp. 1532-1543.
9] X. Ma y E. Hovy, "End-to-end sequence labeling via bi-directional lstm-cnns-crf," arXiv Prepr. arXiv1603.01354, 2016.
10] G. Lample, M. Ballesteros, S. Subramanian, K. Kawakami y C. Dyer, "Neural architectures for named entity recognition" (Arquitecturas neuronales para el reconocimiento de entidades con nombre). arXiv Prepr. arXiv1603.01360, 2016.
11] C. N. dos Santos y V. Guimaraes, "Boosting named entity recognition with neural character embeddings," arXiv Prepr. arXiv1505.05008, 2015.
12] J. Redmon y A. Farhadi, "YOLO9000: mejor, más rápido, más fuerte", en Actas de la conferencia del IEEE sobre visión por ordenador y reconocimiento de patrones, 2017, pp. 7263-7271.
13] W. Liu y otros., "Ssd: Single shot multibox detector", en Conferencia europea sobre visión por ordenador, 2016, pp. 21-37.
14] R. Girshick, "Fast r-cnn", en Actas de la conferencia internacional del IEEE sobre visión por ordenador, 2015, pp. 1440-1448.
15] S. Ren, K. He, R. Girshick, y J. Sun, "Faster r-cnn: Towards real-time object detection with region proposal networks," arXiv Prepr. arXiv1506.01497, 2015.
16] T.-Y. Lin, P. Dollár, R. Girshick, K. He, B. Hariharan y S. Belongie, "Feature pyramid networks for object detection", en Actas de la conferencia del IEEE sobre visión por ordenador y reconocimiento de patrones, 2017, pp. 2117-2125.
17] R. Padilla, S. L. Netto y E. A. B. da Silva, "A survey on performance metrics for object-detection algorithms", en Conferencia Internacional sobre Sistemas, Señales y Procesamiento de Imágenes 2020 (IWSSIP), 2020, pp. 237-242.

Más ...

Ir arriba