- Información general
- Proceso de Document Understanding
- Tutoriales de inicio rápido
- Componentes de marco
- Paquetes ML
- Procesos
- Gestor de datos
- Servicios de OCR
- Document Understanding implementado en Automation Suite
- Document Understanding implementado en AI Center independiente
- Aprendizaje profundo
- Crear un modelo ML de alto rendimiento
- Licencia
- Referencias
- Actividades.DeUipath
- UiPath.AbbyyEmbedded.Activities
- UiPath.DocumentUnderstanding.ML.Activities
- UiPath.DocumentUnderstanding.OCR.LocalServer.Activities
- UiPath.IntelligentOCR.Activities
- UiPath.OCR.Activities
- UiPath.OCR.Contracts
- UiPath.DocumentProcessing.Contracts
- UiPath.OmniPage.Activities
- UiPath.PDF.Activities
La ventaja de los modelos de aprendizaje automático es que se definen mediante datos de entrenamiento y no mediante una lógica explícita expresada en código informático. Esto significa que hay que tener especial cuidado a la hora de preparar los conjuntos de datos, ya que un modelo es igual de bueno que el conjunto de datos que se ha utilizado para entrenarlo. En este sentido, lo que UiPath Studio es para los flujos de trabajo RPA, lo es el Administrador de documentos para las capacidades de aprendizaje automático. Ambos requieren cierta experiencia para su uso eficaz.
¿Qué puede hacer un modelo ML de extracción de datos?
Un modelo ML puede extraer datos de un solo tipo de documento, aunque puede abarcar varios idiomas diferentes. Es esencial que cada campo (importe total, fecha, etc.) tenga un único significado coherente. Si un humano es capaz de confundirse con el valor correcto de un campo, entonces un Modelo ML también lo hará.
Pueden aparecer situaciones ambiguas. Por ejemplo, ¿es una factura de servicios públicos simplemente otro tipo de factura? ¿O se trata de dos tipos de documentos diferentes que requieren dos modelos ML distintos? Si los campos que necesita extraer son los mismos (es decir, tienen el mismo significado), entonces puedes tratarlos como un solo tipo de documento. Sin embargo, si necesitas extraer diferentes campos por distintos motivos (diferentes procesos empresariales), que podrían indicar que debas tratarlos como dos tipos de documentos diferentes y, por lo tanto, entrenar dos modelos distintos.
En caso de duda, empieza por entrenar un solo modelo, pero guarda los documentos en distintos lotes de Document Manager (consulta el menú desplegable Filtro en la parte superior central de la vista de Document Manager) para poder separarlos fácilmente más adelante, si fuera necesario. De esta manera, no se pierde el etiquetado. Cuando se trata de modelos ML, cuantos más datos, mejor. Por lo tanto, tener un modelo único con datos amplios es un buen punto de partida.
Conjuntos de datos de entrenamiento y evaluación
Document Manager can be used to build two types of datasets: training datasets and evaluation datasets. Both are essential for building a high-performing ML Model and you need to budget time and effort for creating and maintaining both. You cannot obtain a high-performing ML model without an evaluation dataset that is representative of the production document traffic.
Cada tipo de conjunto de datos está etiquetado de manera distinta:
- Training datasets rely only on the bounding boxes of the words on the page representing the different pieces of information you need to extract.
- Al etiquetar Conjuntos de entrenamiento, céntrate solo en la propia página y en los recuadros de palabras.
- Evaluation datasets rely only on the values of the fields, which appear in the sidebar (for Regular fields) or the top bar (for Column fields).
- Cuando etiquetes un Conjunto de evaluaciones, céntrate en los valores bajo los nombres de campo en la barra lateral o en la barra superior. Eso no significa que tengas que introducirlos manualmente, de hecho, es probable que se cometan errores tipográficos, por lo que se recomienda etiquetar haciendo clic en las casillas de la página, pero asegurándote de que los valores son correctos.
A continuación, encontrarás información más detallada sobre cómo realizar evaluaciones adecuadas.
Componentes de extracción de datos
La extracción de datos se basa en los siguientes componentes:
- Reconocimiento óptico de caracteres
- Creación de palabras y líneas
- Agrupar caracteres en palabras y palabras en líneas de texto de izquierda a derecha
- Predicción del modelo de aprendizaje automático para cada palabra/casilla de la página
- Limpieza, análisis y formato de los espacios de texto
- Por ejemplo, agrupar palabras en varias líneas en una dirección, aplicar el formato estándar aaaa-mm-dd a una fecha
- Aplicar un algoritmo para seleccionar qué valor se devuelve
- Para casos en los que el documento tenga dos o más páginas y algunos campos aparezcan en más de una página
Crear un modelo ML de alto rendimiento
Para lograr el mejor resultado en términos de tasa de automatización (porcentaje de reducción del trabajo manual medido en meses-persona por año necesarios para procesar tu flujo de documentos) deberías seguir cuidadosamente estos pasos:
- Elegir el mejor motor OCR para los documentos
- Esto influye tanto en el OCR como en la creación de palabras y líneas (que depende parcialmente del OCR) y, por supuesto, en todos los procesos posteriores.
- Selecciona un conjunto de datos bien equilibrado y representativo para el entrenamiento
- Seleccionar un conjunto de datos representativo para la evaluación
- Definir los campos que se extraerán
- Configurar los campos
- Etiquetar el conjunto de datos de entrenamiento
- Etiquetar el conjunto de datos de evaluación
- Entrenar y evaluar el modelo en AI Center
- Definir e implementar las reglas empresariales para procesar la salida del modelo
- (Opcional) Elegir el umbral de confianza para la extracción
- Entrenamiento con datos de la estación de validación
- Bucle de ajuste fino automático (Preview)
- Implementar automatización
1. Elegir un motor OCR
Para elegir un motor OCR, debes crear diferentes sesiones de Administrador de documentos, configurar diferentes motores de OCR e intentar importar los mismos archivos en cada uno de ellos para examinar las diferencias. Deberías centrarte en las áreas que pretendes extraer. Por ejemplo, si necesitas extraer los nombres de las empresas que aparecen como parte de los logotipos en las facturas, podrías querer ver qué motor OCR es más eficaz en el texto de los logotipos.
Your default option should be UiPath Document OCR since it is included with Document Understanding licenses at no charge. However, in cases where some unsupported languages are required, or some very hard-to-read documents are involved, you might want to try Google Cloud (Cloud only) or Microsoft Read (Cloud or On Premises), which have better language coverage. These engines come at a cost, indeed it is low, but if the accuracy is higher on some critical data fields for your business process, it is strongly recommended to use the best OCR available – it will be well worth your time later on since everything downstream depends on it.
Please be aware that the Digitize Document activity has the ForceApplyOCR setting set to False by default, which means when operating on .pdf documents by default the OCR engine is not used at all, the text is extracted directly from the .pdf document itself in the case of native .pdf documents. However, many native .pdf documents may contain logos or even headers or footers which are not picked up. These may contain the identifying information of the company, such as its name, address, VAT code or payment information, which is highly relevant in business processes. If your process has this situation, then set ForceApplyOCR to True to ensure that all text is detected, though it might slow down your process.
2. Crear un conjunto de datos de entrenamiento
Machine Learning technology has the main benefit of being able to handle complex problems with high diversity. When estimating the size of a training dataset, one looks first at the number of fields and their types and the number of languages. A single model can handle multiple languages as long as they are not Chinese/Japanese/Korean. CJK scenarios will generally require separate Training datasets and separate models.
Hay 3 tipos de campos:
- Campos regulares (fecha, suma total)
- Para los campos regulares, se necesita un mínimo de entre 20 y 50 muestras por campo. Por lo tanto, si necesitas extraer 10 campos regulares, necesitarías al menos de 200 a 500 muestras. Si necesitas extraer 20 campos regulares, necesitarías al menos de 400 a 1000 muestras. La cantidad de muestras que necesitas aumenta con el número de campos. Cuantos más campos haya, más muestras necesitarás, entre 20 y 50 veces más.
- Campos de columna (precio unitario del artículo, cantidad del artículo)
- En el caso de los campos de columna, necesitarás al menos entre 50 y 200 muestras por campo de columna, de modo que para campos de 5 columnas, con diseños limpios y sencillos podrías obtener buenos resultados con 300 muestras, pero para diseños altamente complejos y diversos, podría necesitar más de 1000. Para abarcar varios idiomas, entonces necesitas al menos entre 200 y 300 muestras por idioma, suponiendo que cubran todos los distintos campos. Por lo tanto, para 10 campos de encabezado y 4 de columna con dos idiomas, 600 muestras podrían ser suficientes (400 para las columnas y los encabezados más 200 para el idioma adicional), pero en algunos casos podría necesitar 1200 o más.
- Campos de clasificación (moneda)
- Los campos de clasificación suelen requerir al menos entre 10 y 20 muestras de cada clase.
Las directrices generales anteriores presuponen que se está resolviendo un escenario de gran diversidad, como facturas o pedidos de compra, con decenas, cientos o miles de diseños. Sin embargo, si estás resolviendo un escenario de escasa diversidad, como un formulario fiscal o facturas con muy pocos diseños (menos de 5-10), el tamaño del conjunto de datos viene determinado más por el número de diseños. En este caso, deberías empezar con entre 20 y 30 páginas por diseño y añadir más si es necesario, especialmente si las páginas son muy densas con muchos campos para extraer. Por ejemplo, la creación de un modelo para extraer 10 campos de 2 diseños podría requerir 60 páginas, pero si necesitas extraer 50 o 100 campos de 2 diseños, entonces podrías empezar con 100 o 200 páginas y añadir más según sea necesario para obtener la precisión deseada. En este caso, la distinción de campos regulares/campos de columna es menos importante.
ML technology is designed to handle high diversity scenarios. Using it to train models on low diversity scenarios (1-10 layouts) requires special care to avoid brittle models which are sensitive to slight changes in the OCR text. One way to avoid this is to make sure that there is some deliberate variability in the training documents by printing them and then scanning or photographing them using mobile phone scanner apps. The slight distortions or changing resolutions make the model more robust.
Además, estas estimaciones suponen que la mayoría de las páginas contienen todos o la mayoría de los campos. En los casos en los que tengas documentos con varias páginas, pero la mayoría de campos estén en una sola página, entonces el número de páginas pertinente será el número de ejemplos en esa única página donde aparecen la mayoría de los campos.
The numbers above are general guidelines, not strict requirements. In general, you can start with a smaller dataset, and then keep adding data until you get good accuracy. This is especially useful in order to parallelize the RPA work with the model building. Also, a first version of the model can be used to prelabel additional data (see Settings view and Predict button in Document Manager) which can accelerate labeling additional Training data.
Los modelos de aprendizaje profundo pueden generalizar
No es necesario que todos los diseños estén representadas en un conjunto de entrenamiento. De hecho, es posible que la mayoría de los diseños en nuestro flujo de documentos de producción no tengan ninguna muestra en tu conjunto de entrenamiento, o quizás solo una o dos. Esto es lo deseable, porque querrás aprovechar el poder de la IA para comprender los documentos y poder capaz de hacer predicciones correctas en documentos que no haya visto durante el entrenamiento. No es obligatorio disponer de un gran número de muestras por diseño, pues la mayoría de los diseños podrían no estar presentes en absoluto, o estar solo una o un par de veces, y el modelo seguiría siendo capaz de predecir correctamente, basándose en el aprendizaje de otros diseños.
Entrenamiento sobre un modelo listo para usar
Una situación habitual es la de extraer datos de facturas, pero también tienes 2 campos regulares y 1 campo de columna más que el modelo de facturas listas para usar no reconoce. En este caso, se necesita un conjunto de entrenamiento con 50 muestras por cada nuevo campo Regular y un mínimo de 100 muestras por cada nuevo campo de columna. Así pues, 200 páginas se considera un buen comienzo. Por lo general, se trata de un conjunto de datos mucho más pequeño que si se hubieran entrenado todos los campos desde cero.
Dichas 200 páginas deben etiquetarse en su totalidad, incluidos los campos nuevos, que el modelo listo para usar no reconoce, y también los campos originales, que el modelo listo para usar no es capaz de reconocer.
Desigualdad de ocurrencias en el campo
Algunos campos pueden aparecer en todos los documentos (por ejemplo, fecha, número de factura) mientras que otros pueden aparecer solo en el 10 % de las páginas (por ejemplo, gastos de gestión, descuento). En estos casos, hay que tomar una decisión empresarial. Si esos campos raros no son esenciales para la automatización, se puede optar por un pequeño número de muestras (entre 10 y 15) de ese campo en particular, es decir, páginas que contengan un valor para ese campo. Sin embargo, si esos campos son esenciales, debes asegurarse de incluir en tu conjunto de entrenamiento al menos entre 30 y 50 muestras de ese campo para asegurarte de cubrir toda la diversidad.
Conjuntos de datos equilibrados
En el caso de las facturas, si un conjunto de datos contiene facturas de 100 proveedores, pero la mitad del conjunto de datos está formado solo por facturas de un único proveedor, entonces se tratará de un conjunto de datos muy desequilibrado. Un conjunto de datos perfectamente equilibrado es aquel en el que cada proveedor aparece un número igual de veces. No es necesario que los conjuntos de datos estén perfectamente equilibrados, aunque debería evitarse que más del 20 % de todo el conjunto de datos proceda de un solo proveedor. En algún momento, un mayor número de datos no ayuda, e incluso puede afectar a la precisión en otros proveedores porque el modelo optimiza demasiado (sobreajusta) para un proveedor.
Conjuntos de datos representativos
Data should be chosen to cover the diversity of the documents likely to be seen in the production workflow. For example, if you get invoices in English but some of them come from the US, India and Australia, they will likely look different, so you need to make sure you have samples from all three. This is relevant not only for the model training itself, but also for labeling purposes because as you label the documents you might discover that you need to extract new, different fields from some of these regions, like GSTIN code from India, or ABN code from Australia. See more in the Define fields section.
3. Crear un conjunto de datos de evaluación
Mientras que, cuando nos referimos a los conjuntos de entrenamiento, las páginas y el número de páginas son lo más importante, en el caso de los conjuntos de evaluación nos referimos solo a documentos y al número de documentos. Las puntuaciones para las versiones v2021.10 y posteriores se calculan por documento.
Los conjuntos de datos de evaluación pueden ser más pequeños. Pueden ser de 50 a 100 documentos (o incluso solo de 30 a 50 en escenarios de escasa diversidad), y pueden aumentar con el tiempo hasta llegar a varios cientos de documentos. Es importante que sean representativos del flujo de datos de producción. Así que un buen método es seleccionar aleatoriamente entre los documentos procesados en el flujo de trabajo RPA. Aunque algunos proveedores estén excesivamente representados, no hay ningún problema. Por ejemplo, si un solo proveedor representa el 20 % de tu tráfico de facturas, es correcto que ese proveedor sea también el 20 % de tu conjunto de evaluación, de modo que las métricas de evaluación se aproximen a tu métrica empresarial, es decir, la reducción de meses-persona dedicados al procesamiento manual de documentos.
When importing Evaluation data into Document Manager you need to make sure you check the “Make this an evaluation set” box on the Import dialog window. In this way, you guarantee that the data is held out when training, and also you can easily export it for running Evaluations using the evaluation-set option in the Filter dropdown in Document Manager.
Starting with the 21.9 Preview release in Automation Cloud and the 21.10 GA On Premises release, Document Manager has switched to handling multi-page documents rather than each page as a separate entity as was the case previously. This is a major change, especially for Evaluations, which were its main motivation. Evaluations need to be representative of the runtime process, and at runtime multipage documents are processed as a whole, rather than as separate pages. To benefit from this enhancement in ML Packages with version 21.10 or later, you just need to leave the "Backward compatible export" box unchecked in the Export dialog. If you check this box, the dataset will be exported in the old page-by-page way, and evaluation scores will not be as representative of the runtime performance.
4. Definir campos
La definición de los campos es una conversación que debe tener lugar con el experto en la materia o el experto en el dominio que posee el proceso empresarial en sí. En el caso de facturas, sería el propietario del proceso de Cuentas por pagar. Esta conversación es fundamental, debe tener lugar antes de etiquetar los documentos para evitar la pérdida de tiempo, y requiere examinar juntos un mínimo de 20 muestras de documentos elegidos al azar. Hay que reservar un espacio de una hora para ello, y a menudo hay que repetirlo al cabo de un par de días, ya que la persona que prepara los datos se encuentra con situaciones ambiguas o casos límite.
No es raro que la conversación comience con la suposición de que hay que extraer, por ejemplo, 10 campos, y más tarde se acabe con 15. En las subsecciones siguientes se describen algunos ejemplos.
Algunas configuraciones clave que debes tener en cuenta:
- Tipo de contenido
- This is the most important setting as it determines the postprocessing of the values, especially for dates (detects if the format is US-style or non-US style, and then formats them as yyyy-mm-dd) and for numbers (detects the decimal separator – comma or period). ID numbers clean up anything coming before a colon or hash symbol. String content type performs no cleanup and can be used when you want to do your own parsing in the RPA workflow.
- Casilla de verificación Línea múltiple
- Esto sirve para analizar strings como direcciones que pueden aparecer en más de una línea de texto.
- Campos ocultos
- Los campos marcados como Ocultos pueden etiquetarse, pero se retienen al exportar los datos, por lo que el modelo no será entrenado con ellos. Esto resulta práctico cuando se está trabajando en el etiquetado de un campo, cuando es una auténtica rareza o si es de baja prioridad.
- Puntuación
- This is relevant only for Evaluation pipelines, and it affects how the accuracy score is calculated. A field that uses Levenshtein scoring is more permissive: if a single character out of 10 is wrong, the score will be 0.9. However, if scoring is Exact Match it is more strict: a single character wrong will lead to a score of zero. All fields are by default Exact Match. Only String type fields have the option to select Levenshtein scoring.
Cantidades en las facturas de servicios públicos
Un importe total puede parecer bastante sencillo, si bien las facturas de los servicios públicos contienen muchos importes. A veces necesitas que se pague el importe completo, otras solo el importe de la factura actual, sin las cantidades pendientes de los períodos de facturación anteriores. En este último caso, hay que etiquetar de forma distinta incluso si la factura actual y el importe total pueden ser los mismos. Los conceptos son diferentes y los importes suelen ser diferentes.
Each field represents a different concept, and they need to be defined as cleanly and crisply as possible so there is no confusion. If a human might confuse it, the ML model will also.
Moreover, the current bill amount can sometimes be composed of a few different amounts, fees, and taxes and may not appear individualized anywhere on the bill. A possible solution to this is to create two fields: a previous-charges field and a total field. These two always appear as distinct explicit values on the utility bill. Then the current bill amount can be obtained as the difference between the two. You might even want to include all 3 fields (previous-charges,total, and current-charges) in order to be able to do some consistency checks in cases where the current bill amount appears explicitly on the document. So you could go from one to three fields in some cases.
Números de pedido en facturas
Los números de pedido pueden aparecer como valores únicos para una factura, o bien aparecer como parte de la tabla de elementos de línea de una factura, donde cada elemento de línea tiene un número de pedido diferente. En este caso, podría ser conveniente tener dos campos diferentes: n.º de pedido y n.º de elemento de pedido. Al mantener cada campo visual y conceptualmente coherente, es probable que el modelo cumpla mucho mejor su función. Sin embargo, debes asegurarte de que ambos estén bien representados en tus conjuntos de datos de entrenamiento y de evaluación.
Nombre del proveedor y dirección de pago en las facturas
The company name usually appears at the top of an invoice or a utility bill, but sometimes it might not be readable because there is just a logo, and the company name is not explicitly written out. Or there may be some other stamp or handwriting or wrinkle over the text. In these cases, people might label the name which appears at the bottom right, in the 'Remit payment to' section of the payslip on utility bills. That name is often the same, but not always since it is a different concept. Payments can be done to some other parent or holding company or other affiliate entity, and it is visually different on the document. This might lead to poor model performance. In this case, you would want to create 2 fields, vendor-name and payment-addr-name. Then you can look both up in a vendor database and use the one that matches or only use payment-addr-name when the vendor-name is missing.
Filas de tablas
Hay que tener en cuenta dos conceptos distintos: las filas de la tabla y las líneas de texto. Una fila de la tabla incluye todos los valores de todos los campos de las columnas que pertenecen a esa fila. A veces pueden formar parte de la misma línea de texto que se extiende a lo largo de la página. Otras veces pueden estar en líneas diferentes.
Si una fila de la tabla está formada por más de una línea de texto, debes agrupar todos los valores de esa fila de la tabla utilizando la tecla de acceso directo "/". Cuando lo haces así, aparecerá un recuadro ver que cubrirá toda la fila de la tabla. Aquí tienes un ejemplo de una tabla en la que las dos primeras filas están formadas por varias líneas de texto que deben agruparse con la tecla de acceso directo "/", mientras que la tercera fila es una sola línea de texto y no necesita ser agrupada.
A continuación, se muestra un ejemplo de una tabla en la que cada fila de la tabla está formada por una sola línea de texto. No es necesario agruparlas con la tecla de acceso directo "/", ya que el Administrador de documentos lo hace de manera implícita.
Dividir los elementos
Split Items is a setting that appears only for Column fields, and it helps the model know when a line item ends and another begins. As a human looking at a document, to tell how many are rows there you probably look at how many amounts there are on the right side. Each amount refers to a line item in general. This is an indication that line-amount is a column where you should enable Split Items. Other columns can be also marked, in case the OCR misses the line-amount, or the model does not recognize it: quantity and unit-price are usually also marked as 'Split Items'.
5. Configurar los campos
El ajuste más importante es el Tipo de contenido, con la excepción de String:
- Número
- Fecha
- Teléfono
- Número de identificación
These impact post-processing, especially the cleanup, the parsing, and the formatting. The most complex is the Date formatting, but also Number formatting requires determining the decimal point separator and thousands decorator. In some cases, if parsing fails your option is to report the issue to UiPath support and to fall back on the String content type, which does no parsing. In that case, you would need to parse the value in your RPA workflow logic.
Another relevant configuration is the Multi-line checkbox which is relevant mainly for String type fields. Whenever some other field produces unexpected results or no results, the first thing to try is to change it to String Multi-line field, to see the unaltered output of the model prediction.
6. Etiquetar el conjunto de datos de entrenamiento
When labeling Training data you need to focus on the bounding boxes of the words in the document pane of Document Manager. The parsed values in the right or top sidebars are not important as they are not used for training.
Whenever a field appears multiple times on a page, as long as they represent the same concept (see the Define fields section above), all of them should be labeled.
Cuando el OCR se salta una palabra o se equivoca en algunos caracteres, basta con etiquetar el cuadro delimitador si lo hay, y si no, se omite y se continúa. No es posible añadir una palabra en Document Manager, porque, aunque lo hicieras, la palabra seguiría faltando durante la ejecución, por lo que añadirla no serviría de nada para el modelo.
As you label remain vigilant about fields that may have multiple or overlapping meanings/concepts, in case you might need to split a field into two separate fields, or fields that you potentially do not explicitly need, but which, if labeled, might help you to do certain validation or self-consistency check logic in the RPA workflow. Typical examples are quantity, unit-price, and line-amount on invoice line items. Line-amount is the product of quantity and unit-price, but this is very useful to check for consistency without the need for confidence levels.
7. Etiquetar el conjunto de datos de evaluación
When labeling Evaluation datasets (also called Test datasets) you need to focus on something slightly different from labeling Training datasets. Whereas for Training datasets only the bounding boxes of the fields on the document matter, for Evaluation datasets only the values of the fields matter. You may edit them by clicking on the value in the right or top sidebar and editing it. To return to the automatically parsed value click on the lock icon.
For convenience, speed, and to avoid typos we recommend clicking on the boxes on the document when labeling and only making corrections manually. Typing full values manually is slower and more error-prone.
8. Entrenar y evaluar el modelo
Se permite la exportación de todo el conjunto de datos, incluidos los lotes de entrenamiento y de prueba, ya que los procesos de entrenamiento de AI Center ignoran los datos de prueba. Sin embargo, los procesos de evaluación ejecutarán la evaluación en todo el conjunto de datos de evaluación, independientemente de si se compone de datos de entrenamiento o de prueba. El tipo de un determinado documento se muestra justo debajo del nombre del archivo, en la parte superior central de la ventana del Administrador de documentos.
When evaluating a ML model the most powerful tool is the evaluation.xlsx file generated in the artifacts/eval_metrics folder. In this Excel file you can see what predictions are failing and on which files, and you can see immediately if it is an OCR error or a ML Extraction or parsing error, and if it may be fixed by simple logic in the RPA workflow, or it requires a different OCR engine, more training data, or improving the labelling or the field configurations in Document Manager.
Este archivo de Excel también es muy útil para identificar las reglas empresariales más relevantes que hay que aplicar al flujo de trabajo de RPA para detectar errores comunes y enviarlos a la Estación de validación en Action Center para su revisión manual. Las reglas empresariales son, con diferencia, la forma más fiable de detectar errores.
Para aquellos errores que no puedan detectarse con reglas de negocio, también puedes utilizar niveles de confianza. El archivo Excel también contiene niveles de confianza para cada predicción, para que puedas utilizar funciones de Excel como clasificar y filtrar y así determinar cuál es un buen umbral de confianza para tu escenario empresarial.
En general, el archivo de Excel evaluation.xlsx es un recurso clave en el que debes centrarte para obtener los mejores resultados de tu automatización de IA.
9. Definir e implementar las reglas empresariales
En este paso, debes preocuparte por los errores del modelo y por cómo detectarlos. Hay dos formas principales de detectar errores:
- mediante la aplicación de reglas empresariales,
- mediante la aplicación de un umbral mínimo de confianza.
La manera más eficaz y fiable es definiendo reglas empresariales. Los niveles de confianza nunca pueden ser 100 % perfectos, siempre habrá un pequeño, pero no nulo porcentaje de predicciones correctas de confianza baja o predicciones erróneas de alta confianza. Además, y quizás lo más importante, un campo ausente carece de confianza, por lo que un umbral de confianza nunca podrá detectar errores cuando no se extrae ningún campo en absoluto. Por consiguiente, los umbrales de confianza solo deben utilizarse como un último recurso, un mecanismo de seguridad, pero nunca como la forma principal de detectar errores críticos para la empresa.
Ejemplos de reglas empresariales:
- El importe neto más el importe de impuesto debe ser igual al importe total.
- El importe total debe ser mayor o igual al importe neto.
- Invoice number, Date, Total amount (and potentially other fields) must be present
- El número de pedido (si está presente) debe existir en la base de datos de pedidos.
- La fecha de la factura debe ser anterior y no puede tener más de X meses de antigüedad.
- La fecha de vencimiento debe ser futura y no debe superar Y días/meses.
- For each line item the quantity multiplied by unit price must equal the line amount
- La suma de los importes de las líneas debe ser igual al importe neto o al importe total.
- etc.
En particular, los niveles de confianza de los campos de columna casi nunca deberían utilizarse como mecanismo de detección de errores, ya que los campos de columna (por ejemplo, los elementos de línea en facturas o pedidos) pueden tener docenas de valores. Por lo tanto, establecer un umbral mínimo para tantos valores puede ser especialmente poco fiable, porque es más que probable que un valor sea de poca confianza, lo que llevaría a que la mayoría o todos los documentos se enviaran a validación por parte de una persona, muchas veces de forma innecesaria.
Las normas empresariales deben aplicarse como parte del flujo de trabajo de RPA, y lo ideal sería que se pasara el fallo de la norma empresarial al validador humano, para dirigir su atención y agilizar el proceso.
10. (Opcional) Elegir un umbral de confianza
Una vez definidas las reglas empresariales, a veces puede quedar un pequeño número de campos para los que no existen reglas empresariales, o para los que es poco probable que las reglas empresariales detecten todos los errores. Para ello, es posible que tengas que utilizar un umbral de confianza como último recurso.
La principal herramienta para establecer este umbral es la función del proceso de evaluación de AI Center y, en concreto, la hoja de cálculo de Excel que genera el proceso de evaluación en la carpeta Outputs > artifacts > eval_metrics.
This spreadsheet contains a column for each field and a column for the confidence level of each prediction. You can add a column called min_confidence which takes the minimum of all the confidences over all fields which are important for your business process and are not already covered by business rules. For instance, you may not want to put a threshold on the line items confidences, but rather on vendor name, total amount, date, due date, invoice number, and other essential fields. By sorting the table based on the min_confidence column you may see where the errors start appearing and set a threshold above that level to ensure that only correctly extracted documents are sent straight through.
11. Entrenamiento con datos de la estación de validación
Validation Station data can help improve the model predictions, yet, in many cases, it turns out that most errors are not due to the model itself but to the OCR, labelling errors or inconsistencies, or to postprocessing issues (e.g., date or number formatting). So, the first key aspect is that Validation Station data should be used only after the other Data Extraction Components have been verified and optimized to ensure good accuracy, and the only remaining area of improvement is the model prediction itself.
El segundo aspecto clave es que los datos de la Estación de validación tienen una menor densidad de información que los datos etiquetados en el Document Manager. Fundamentalmente, al usuario de la estación de validación solo le interesa obtener el valor correcto una vez. Si una factura tiene 5 páginas, y el número de factura aparece en todas las páginas, el usuario de la Estación de validación lo valida solamente en la primera página. Así, el 80 % de los valores quedan sin etiquetar. En Document Manager, todos los valores están etiquetados.
Por último, ten en cuenta que los datos de la Estación de validación deben añadirse al conjunto de datos original manualmente etiquetado, de modo que siempre tengas un único conjunto de datos de entrenamiento que aumente de tamaño con el tiempo. Siempre tendrás que entrenar en el Paquete ML con la versión secundaria 0 (cero), que es la versión lista para usar lanzada por UiPath.
Añade siempre los datos de la estación de validación al mismo conjunto de datos y entrena con la versión menor 0 (cero) del paquete ML)
Con frecuencia, se asume de manera errónea que la forma de utilizar los datos de la Estación de validación es volver a entrenar de manera iterativa la versión anterior del modelo, por lo que el lote actual se utiliza para entrenar el paquete X.1 y así obtener X.2. A continuación, el siguiente lote se entrena en X.2 para obtener X.3 y así sucesivamente. Esta es la manera incorrecta de utilizar el producto. Cada lote de la Estación de validación debe importarse en la misma sesión del Administrador de documentos que los datos originales manualmente etiquetados, formando un mayor conjunto de datos, que debe utilizarse para entrenar siempre en la versión X.0 del paquete ML.
Los datos de la estación de validación pueden ser de un volumen mucho mayor, ya que se utilizan en el flujo de trabajo de producción. En consecuencia, se necesita una pauta para saber cuántos datos pueden ser útiles, dado que el entrenamiento del modelo requiere tiempo e infraestructura. Además, no se desea que el conjunto de datos se vea saturado de datos de la estación de validación, ya que esto puede degradar la calidad del modelo debido al problema de la densidad de información anteriormente mencionado.
The recommendation is to add a maximum of 2-3X the number of pages of Document Manager data and, beyond that, only cherry pick those vendors or samples where you see major failures. If there are known major changes to the production data, such as a new language, or a new geographic region being onboarded to the business process (expanding from US to Europe or South Asia), then representative data for those languages and regions should be added to Document Manager for manual labelling. Validation Station data is not appropriate for such major scope expansion.
A continuación, se muestra un escenario de muestra. Has seleccionado un buen motor OCR, has etiquetado 500 páginas en el Administrador de documentos, lo que ha dado como resultado un buen rendimiento, y has implementado el modelo en un flujo de trabajo RPA de producción. La Estación de validación está empezando a generar datos. Deberás seleccionar de forma aleatoria hasta un máximo de entre 1000 y 1500 páginas de la Estación de validación e importarlas al Administrador de documentos junto con las primeras 500 páginas y volver a entrenar tu modelo ML. Seguidamente, deberás ejecutar un proceso de evaluación para asegurarte de que el modelo ha mejorado realmente y, a continuación, deberás implementar el nuevo modelo en producción.
12. Bucle de ajuste fino automático (Preview)
The Auto-Fine-tuning Loop is a Preview capability that becomes useful for maintaining a high-preforming model which you have already created using the steps described above. To ensure that auto-fine-tuning produces better versions of the model it is critical that you have a good Evaluation dataset and that you use an automatically rescheduled Full Pipeline which runs both Training and Evaluation at the same time. In this way, you can see if the most recent Training produced a more accurate model than the previous one, and if so, you are ready to deploy the new model to the ML Skill invoked by the Robots in your business process.
The Training dataset keeps changing as more data comes in and Document Manager exports periodically as scheduled in the Scheduled Export dialog. The Evaluation runs on the same Evaluation dataset you specify in the pipeline. Evaluation datasets never change automatically, they always need to be curated, labeled and exported manually. You should change your Evaluation set rarely so that accuracy scores can be compared between different Training runs.
AI Center ofrece la posibilidad de actualizar automáticamente la habilidad ML cuando se reentrena una nueva versión de un paquete ML. Sin embargo, esta actualización automática no tiene en cuenta la puntuación del proceso completo y, por lo tanto, no es aconsejable utilizar esta función con los procesos de reentrenamiento automático de Document Understanding.
As mentioned above in the Create an Evaluation Dataset section, Evaluation Pipeline implementations for ML Packages release 21.10 or later calculate scores on a per-document basis - which reflects accurately the results you see in an RPA workflow. This assumes your dataset was labelled on a per-document basis in Document Manager. You can tell if a multi-page document is labeled on a per-document basis if you can scroll naturally through the pages like in a regular PDF reader. If you need to click next to pass from one page to the next, then each page is considered a separate document.
13. Implementar la automatización
Make sure to use the Document Understanding Process from the Templates section in the Studio start screen in order to apply best practices in Enterprise RPA architecture.
- ¿Qué puede hacer un modelo ML de extracción de datos?
- Conjuntos de datos de entrenamiento y evaluación
- Componentes de extracción de datos
- Crear un modelo ML de alto rendimiento
- 1. Elegir un motor OCR
- 2. Crear un conjunto de datos de entrenamiento
- 3. Crear un conjunto de datos de evaluación
- 4. Definir campos
- 5. Configurar los campos
- 6. Etiquetar el conjunto de datos de entrenamiento
- 7. Etiquetar el conjunto de datos de evaluación
- 8. Entrenar y evaluar el modelo
- 9. Definir e implementar las reglas empresariales
- 10. (Opcional) Elegir un umbral de confianza
- 11. Entrenamiento con datos de la estación de validación
- 12. Bucle de ajuste fino automático (Preview)
- 13. Implementar la automatización