Entrenamiento de modelos de alto rendimiento

The power of Machine Learning Models is that they are defined by training data rather than by explicit logic expressed in computer code. This means that extraordinary care is needed when preparing datasets because a model is only as good as the dataset that was used to train it. In that sense, what UiPath® Studio is to RPA workflows, a Document Type session (in Document UnderstandingDocument Understanding^TM Cloud) is to Machine Learning capabilities. Both require some experience to be used effectively.

¿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 (Cantidad total, Fecha, etc.) tenga un significado único y coherente. Si un humano puede estar confuso sobre el valor correcto de un campo, 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), deberás tratarlos como dos tipos de documentos diferentes y, por tanto, entrenar dos modelos distintos.

When in doubt, start by training a single model, but keep the documents in different Document Manager batches (check the Filter drop-down at the top of the view) so you can easily separate them later if needed. In this way, the labeling work is not lost. When it comes to ML Models, the more data, the better. So, having a single model with ample data is a good place to start.

Conjuntos de datos de entrenamiento y evaluación

El Administrador de documentos puede utilizarse para crear dos tipos de conjuntos de datos:

• conjuntos de datos de entrenamiento
• conjuntos de datos de evaluación

Ambos tipos de conjuntos de datos son esenciales para crear un modelo ML de alto rendimiento y requieren tiempo y esfuerzo para su creación y mantenimiento. Para obtener un modelo ML de alto rendimiento se requiere un conjunto de datos de evaluación que sea representativo del tráfico de documentos de producción.

Cada tipo de conjunto de datos está etiquetado de manera distinta:

• Training datasets rely 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 en la propia página y en los cuadros de palabras.
• Evaluation datasets rely on the values of the fields, that appear in the sidebar (for Regular fields) or the top bar (for Column fields).
• Cuando etiquetes un conjunto de evaluación, concéntrate en los valores bajo los nombres de los campos en la barra lateral o superior. Eso no significa que tengas que escribirlos manualmente. Se recomienda etiquetar seleccionando las casillas de la página, y comprobar la exactitud de los valores.

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
• Si el documento tiene dos o más páginas y algunos campos aparecen en más de una página

Niveles de confianza

¿Qué son los niveles de confianza?

When ML models make predictions, they are basically statistical guesses. The model is saying "this is probably the Total amount" of this Invoice. This begs the question: how probably? Confidence levels are an attempt to answer that question, on a scale from 0 to 1. However, they are NOT true probability estimates. They are just how confident the model is about its guesses, and therefore they depend on what the model has been trained on. A better way to think of them is as a measure of familiarity: how familiar is the model with this model input? If it resembles something the model has seen in training, then it might have a higher confidence. Otherwise it might have a lower confidence.

¿Para qué sirven los niveles de confianza?

Las automatizaciones empresariales necesitan formas de detectar y gestionar excepciones, es decir, los casos en los que una automatización sale mal. En las automatizaciones tradicionales, esto es bastante obvio porque cuando se interrumpe un flujo de trabajo de RPA, simplemente se detiene, se bloquea o genera un error. Ese error se puede detectar y gestionar en consecuencia. Sin embargo, los modelos de aprendizaje automático no arrojan errores cuando hacen malas predicciones. Entonces, ¿cómo determinamos cuándo un modelo ML ha cometido un error y debe activarse el flujo de gestión de excepciones? Esto a menudo implica la participación manual de personas, tal vez mediante el Action Center.

The best way to catch bad predictions, by far, is through enforcing business rules. For example, we know that on an invoice, the net amount plus the tax amount must equal the total amount. Or that the part numbers for the components ordered must have 9 digits. When these conditions do not hold, we know something has gone wrong, and we can trigger the exception handling flow. The is the preferred and strongly recommended approach. It is worth investing significant effort in building these kinds of rules, even using complex Regular Expressions, or even lookups in databases to validate Vendor names, or part numbers, etc. In some cases you may even want to extract some other document that is not of interest but only to cross reference and validate some values to the original document of interest.

Sin embargo, en algunos casos, ninguna de estas opciones existe y aún se desea detectar predicciones potencialmente malas. En estos casos, puede volver al nivel de confianza. Cuando el nivel de confianza para una predicción es bajo, por ejemplo, inferior a 0,6, el riesgo de que la predicción sea incorrecta es mayor que si la confianza es 0,95. Sin embargo, esta correlación es bastante débil. Hay muchas instancias en las que se extrae un valor con poca confianza, pero es correcto. También es posible, aunque relativamente raro, que se extraiga un valor con alta confianza (más de 0,9), pero es incorrecto. Por estas razones, recomendamos encarecidamente a los usuarios que confíen en las reglas empresariales tanto como sea posible y solo utilicen los niveles de confianza como último recurso.

¿Qué tipos de niveles de confianza hay?

Most components in the Document Understanding^TM product return a confidence level. The main components of a Document Understanding^TM workflow are Digitization, Classification and Extraction. Each of these has a certain confidence for each prediction. The Digitization and the Extraction confidence are both visually exposed in the Validation Station, so you can filter predictions and focus only on low confidence ones, to save time.

Escala de la puntuación de confianza (o calibración)

Los niveles de confianza de los diferentes modelos se escalarán de forma diferente, dependiendo del diseño del modelo. Por ejemplo, algunos modelos devuelven niveles de confianza en el rango 0,9-1 casi siempre, y solo muy rara vez por debajo de 0,8. Otros modelos tienen niveles de confianza distribuidos de forma mucho más uniforme entre 0 y 1, incluso si generalmente están agrupados en el extremo superior de la escala. Como resultado, los umbrales de confianza en diferentes modelos serán diferentes. Por ejemplo, un umbral de confianza en el OCR no será el mismo que el umbral en el extractor ML o el clasificador ML. Además, cada vez que se produzca una actualización importante de la arquitectura de un modelo, como la que viene con el lanzamiento de la arquitectura del modelo basado en IA generativa de Helix, la distribución del nivel de confianza cambiará y los umbrales de confianza deberán volver a evaluarse.

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:

1. Elegir el mejor motor OCR para los documentos

   Esto influye tanto en el OCR como en la creación de Word y Línea (que depende parcialmente del OCR), y por supuesto.

2. Selecciona un conjunto de datos bien equilibrado y representativo para el entrenamiento

3. Definir los campos que se extraerán

4. Etiquetar el conjunto de datos de entrenamiento

5. Entrenar al extractor

6. Definir e implementar las reglas empresariales para procesar la salida del modelo

7. (Opcional) Elegir el umbral de confianza para la extracción

8. Entrenamiento con datos de la estación de validación

9. Implementar automatización

1. Elegir un motor OCR

Para elegir un motor de OCR, debes crear diferentes sesiones del Gestor de documentos, configurar diferentes motores de OCR e intentar importar los mismos archivos en cada uno de ellos para examinar las diferencias. Concéntrate en las áreas que deseas extraer. Por ejemplo, si necesitas extraer nombres de empresas que aparecen como parte de los logotipos en las facturas, es posible que quieras comprobar qué motor de OCR funciona mejor en el texto de los logotipos.

La opción predeterminada debería ser UiPath Document OCR, ya que se incluye en las licencias de Document Understanding sin coste alguno. Sin embargo, en los casos en los que se requieren algunos idiomas no admitidos, o algunos documentos muy difíciles de leer, es posible que desees probar Google Cloud (solo en la nube) o Microsoft Read (en la nube o local), que disponen de una mejor cobertura de idiomas. Estos motores tienen un coste, si bien es bajo. Sin embargo, si la precisión es mayor en algunos campos de datos críticos para el proceso empresarial, se recomienda encarecidamente utilizar el mejor OCR disponible, lo cual supondrá un ahorro de tiempo más adelante, ya que todo lo demás depende de él.

Please be aware that the Digitize Document activity has the ApplyOcrOnPDF setting set to Auto by default, determining if the document requires to apply the OCR algorithm depending on the input document. Avoid missing the extraction of important information (from logos, headers, footers, etc.) by setting the ApplyOcrOnPDF to Yes, making sure that all text is detected, though it might slow down your process.

2. 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.

Algunas configuraciones clave que debes tener en cuenta:

• Content type 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.
• Multi-line checkbox This is for parsing strings like addresses that may appear on more than 1 line of text.
• Multi-valued checkbox This is for handling multiple choice fields or other fields which may have more than one value, but are NOT represented as a table column. For example, an Ethnic group question on a government form may contain multiple checkboxes where you can select all that apply.
• Hidden fields Fields marked as Hidden can be labelled but they are held out when data is exported, so the model cannot be trained on them. This is handy when labeling a field is a work in progress, when it is too rare, or when it is low priority.
• Scoring 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 is 0.9. However, if scoring is Exact Match it is more strict: a single wrong character leads to a score of zero. Only String type fields have the option to select Levenshtein scoring by default.

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 es necesario el importe total que hay que pagar. Otras veces solo se necesita el importe de la factura actual, sin los importes arrastrados de periodos 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.

Nota:

Each field represents a different concept, and they need to be defined as cleanly as possible, so there is no confusion. If a human might be confused, the ML model will also be confused.

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. There could also be some stamp, or handwriting, or wrinkle over the text. In these cases, people might label the name that 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 made 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 should create two fields, vendor-name and payment-addr-name. Then you can look both up in a vendor database and use the one that matches, or 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 consta de más de una línea de texto, entonces necesitará agrupar todos los valores en esa fila de la tabla usando la tecla de acceso rápido “/”. Al hacerlo, aparecerá un cuadro verde que cubre toda la fila de la tabla. A continuación se muestra un ejemplo de una tabla en la que las dos filas superiores constan de varias líneas de texto y deben agruparse usando la tecla de acceso rápido “/”, mientras que la tercera fila es una sola línea de texto y no necesita agruparse.

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.

Identificar dónde termina una fila y comienza otra mientras se lee de arriba a abajo a menudo puede ser un gran desafío para los modelos de extracción ML, especialmente en documentos como formularios en los que no hay líneas horizontales visuales que separen las filas. Dentro de nuestros paquetes ML hay un modelo especial que está entrenado para dividir las tablas en filas correctamente. Este modelo se entrena usando estos grupos que etiqueta con las teclas "/" o "Intro" y que se indican con cuadros transparentes de color verde.

2. Selecciona un conjunto de datos bien equilibrado y representativo para el entrenamiento

La tecnología de aprendizaje automático tiene como principal ventaja la posibilidad de tratar problemas complejos con gran diversidad. A la hora de estimar el tamaño de un conjunto de datos de entrenamiento, se observa en primer lugar el número de campos y sus tipos, y el número de idiomas. Un solo modelo puede procesar varios idiomas siempre que no sean chino, japonés o coreano. Los escenarios chino, japonés o coreano suelen requerir conjuntos de datos de entrenamiento y modelos independientes.

Hay 3 tipos de campos:

1. Regular fields (date, total amount)
   • Para los campos regulares, se necesita un mínimo de entre 20 y 50 muestras de documentos por campo. Por lo tanto, si necesitas extraer 10 campos regulares, necesitarás al menos entre 200 y 500 muestras de documentos. Si necesitas extraer 20 campos regulares, necesitarás al menos de 400 a 1000 muestras de documentos. La cantidad de muestras de documentos necesarias aumentará con el número de campos. Cuantos más campos haya, más muestras de documentos necesitarás, entre 20 y 50 veces más.
2. Column fields (item unit price, item quantity)
   • En el caso de los campos de columna, se necesitan al menos entre 50 y 200 muestras de documentos por campo de columna, por lo que, para 5 campos de columna, con diseños simples y precisos, se pueden obtener buenos resultados con 300 muestras de documentos. Con diseños muy complejos y diversos, podrían necesitarse más de 1000 muestras de documentos. Para cubrir varios idiomas, se necesitan al menos entre 200 y 300 muestras de documentos por idioma, suponiendo que se cubran todos los distintos campos. Así, para 10 campos de cabecera y 4 campos de columna con 2 idiomas, 600 muestras de documentos podrían ser suficientes (400 para las columnas y cabeceras, más 200 para el idioma adicional), aunque en algunos casos podrían ser necesarias 1200 o más.
3. Classification fields (currency)
   • Los campos de clasificación suelen requerir al menos entre 10 y 20 muestras de documentos de cada clase.

Las directrices generales 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 baja diversidad como un formulario de impuestos o facturas con muy pocos diseños (menos de 5-10), entonces el tamaño del conjunto de datos está determinado más por el número de diseños. En este caso, debes comenzar con 20 a 30 páginas por diseño y añadir más si es necesario, especialmente si las páginas son muy densas con un gran número de campos que extraer. Por ejemplo, crear un modelo para extraer 10 campos de 2 diseños puede requerir 60 páginas, pero si necesitas extraer 50 o 100 campos de 2 diseños, puedes comenzar 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.

Importante:

La tecnología ML está diseñada para gestionar escenarios de gran diversidad. Su uso para entrenar modelos en escenarios de baja diversidad (de 1 a 10 diseños) requiere un cuidado especial para evitar modelos frágiles que sean sensibles a pequeños cambios en el texto del OCR. Evita esto teniendo alguna variabilidad intencionada en los documentos de entrenamiento, imprimiéndolos y luego escaneándolos o fotografiándolos mediante aplicaciones de escáner para teléfonos móviles. Las ligeras distorsiones o los cambios de resolución confieren mayor solidez al modelo.

Estas estimaciones asumen que la mayoría de las páginas contienen todos o la mayoría de los campos. Si se trata de documentos con varias páginas y la mayoría de los campos están en una sola, el número de páginas relevante es el número de ejemplos de esa página en los que aparecen la mayoría de los campos.

The numbers described 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 to parallelize the RPA work with the model building. Also, a first version of the model can be used to prelabel additional data (check 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, la mayoría de los diseños de nuestro flujo de documentos de producción no tienen ninguna muestra en tu conjunto de entrenamiento, o una o dos muestras de documentos. Esto es conveniente, ya que se desea aprovechar el poder de la IA para entender los documentos y ser capaz de hacer predicciones correctas sobre los documentos que no ha observado durante el entrenamiento. No es obligatorio contar con muchas muestras de documentos por diseño, ya que la mayoría de los diseños podrían no estar presentes o estarlo solo una o dos 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

Hay tres tipos principales de escenarios a la hora de entrenar un modelo ML para Document Understanding:

• entrenar un nuevo tipo de documento desde cero utilizando el paquete ML de Document Understanding en AI Center;
• reentrenar sobre un modelo previamente entrenado del tipo listo para usar con el fin de optimizar la precisión;
• reentrenar sobre un modelo previamente entrenado listo para usar con el fin de optimizar la precisión y añadir algunos campos nuevos.

Las estimaciones del tamaño del conjunto de datos para el primer tipo de escenario se describen en la primera parte de esta sección bajo el título "Crear un conjunto de entrenamiento".

Para el segundo tipo de escenario, el tamaño del conjunto de datos depende de lo bien que funcionen los modelos previamente entrenados en los documentos. Si funcionan muy bien, es posible que se necesiten muy pocos datos, entre 50 y 100 páginas. Si fallan en algunos campos importantes, es posible que se necesiten más, aunque un buen punto de partida seguiría siendo cuatro veces menor que si se entrenara desde cero.

Y, por último, para el tercer tipo de escenario, comienza por el tamaño del conjunto de datos del segundo escenario y, luego, aumenta el conjunto de datos en función del número de campos nuevos que tengas, utilizando la misma orientación que para el entrenamiento desde cero: al menos entre 20 y 50 páginas por campo regular nuevo, o al menos entre 50 y 200 páginas por campo de columna.

En todos estos casos, es necesario etiquetar por completo todos los documentos, incluidos los campos nuevos, que el modelo listo para usar no reconoce, y también el origen de los campos, que sí se reconocen.

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 de documentos (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 asegurarte de incluir en su conjunto de entrenamiento al menos entre 30 y 50 muestras de documentos 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, será 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 probably look different, so you need to make sure you have document samples from all three. This is relevant not only for the model training itself, but also for labeling purposes. When 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. Check the Define fields section for more information.

4. Etiquetar el conjunto de datos de entrenamiento

Al etiquetar los datos de entrenamiento, hay que centrarse en los cuadros delimitadores de las palabras en el panel de documentos del Administrador de documentos. Los valores analizados en las barras laterales derecha o superior no son importantes, ya que no se utilizan para el entrenamiento.

Cada vez que un campo aparece varias veces en una página, siempre que represente el mismo concepto, todos deben estar etiquetados.

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 el Administrador de documentos, ya que, aunque lo hicieras, la palabra seguiría faltando durante la ejecución, por lo que añadirla no sirve de nada al 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 do not explicitly need, but which, if labelled, 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.

5. Entrenar el extractor

To create an extractor, go to the Extractors view in Document Understanding and select the Create Extractor button at the top right. You can then select the Document Type, the ML Model and Version you would like to use. You can monitor the progress on the Extractors tab, or in the Details view of the Extractor, which contains a link to the AI Center pipeline, where you can check the detailed logs in real time.

When evaluating an ML model, the most powerful tool is the evaluation_.xlsx file generated in the artifacts/eval_metrics folder in AI Center pipeline details view. On the first sheet you can check a detailed Accuracy scores report, including overall scores, and also per field and per batch.

En este archivo de Excel puedes comprobar qué predicciones están fallando y en qué archivos, y puedes observar inmediatamente si se trata de un error de OCR o de extracción o análisis de ML, y si se puede corregir mediante lógica simple en el flujo de trabajo de RPA, o requiere un motor de OCR diferente, más datos de entrenamiento o mejorar el etiquetado o las configuraciones de los campos en el Gestor de documentos.

Este archivo de Excel también es muy útil para identificar las reglas empresariales más relevantes que debe aplicar al flujo de trabajo de RPA con el fin de detectar errores comunes y enviarlos a la Estación de validación en el Centro de Actions 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.

Overall, the evaluation_<package_name>.xlsx Excel file is a key resource you need to focus on to get the best results from your AI automation.

Importante:

GPU training is highly recommended for large and production datasets. CPU training is much slower and should be used sparingly, for small datasets for demo or testing purposes. For more information, check the Training pipelines page.

6. Definir e implementar reglas empresariales

En este paso, debes preocuparte por los errores del modelo y por cómo detectarlos. Existen dos maneras principales de detectar errores:

• mediante la aplicación de reglas empresariales,
• through applying lookups in Systems of Record in the customer organization
• mediante la aplicación de un umbral mínimo de confianza.

La forma más efectiva y fiable de detectar errores es definir reglas empresariales y búsquedas. Los niveles de confianza nunca pueden ser 100% perfectos, siempre habrá un porcentaje pequeño pero distinto de cero de predicciones correctas con baja confianza o predicciones erróneas con gran confianza. Además, y quizás lo más importante, un campo que falta no tiene confianza, por lo que un umbral de confianza nunca puede detectar errores por los que un campo no se extrae en absoluto. En consecuencia, los umbrales de nivel de confianza solo deben usarse como alternativa, una red de seguridad, pero nunca como la principal forma de detectar errores críticos para el negocio.

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.
• Los campos Número de factura, Fecha, Importe total (y otros) deben estar presentes.
• 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.
• Para cada elemento de línea, la cantidad multiplicada por el precio unitario debe ser igual al importe de línea.
• La suma de los importes de las líneas debe ser igual al importe neto o al importe total.
• etc.

Nota:

In case of numbers, a rounding to eight decimals is performed.

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 reglas empresariales deben aplicarse como parte del flujo de trabajo RPA, y el fallo de la regla empresarial se transmite al validador humano para centrar su atención y acelerar el proceso.

Nota:

When defining Business Rules, please keep in mind that the Starts with, Ends with, and Contains values are case sensitive.

7. (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.

The main tool to set this threshold is the Excel spreadsheet which is output by the Training pipeline in the Outputs > artifacts > eval_metrics folder.

This evaluation_.xlsx file contains a column for each field, and a column for the confidence level of each prediction. By sorting the table based on the confidence columns you may check where the errors start appearing for any given field and set a threshold above that level to ensure that only correctly extracted documents are sent straight through.

8. Sintoniza con los 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 Administrador de documentos. 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 queda sin etiquetar. En el Administrador de documentos, todos los valores están etiquetados.

Finalmente, ten en cuenta que los datos de la Estación de Validación deben agregarse al conjunto de datos original etiquetado manualmente, para que siempre tengas un único conjunto de datos de entrenamiento que aumenta de tamaño con el tiempo. Siempre debes entrenar en el paquete ML con la versión menor 0 (cero), que es la versión lanzada por UiPath lista para su uso.

Importante:

It is often wrongly assumed that the way to use Validation Station data is to iteratively train the previous model version, so the current batch is used to train package X.1 to obtain X.2. Then the next batch trains on X.2 to obtain X.3 and so on. This is the wrong way to use the product. Each Validation Station batch needs to be imported into the same Document Manager session as the original manually labeled data making a larger dataset, which must be used to train always on the X.0 ML Package version.

Precauciones sobre el uso de los datos de la estación de validación

Los datos de la estación de validación pueden ser potencialmente de un volumen mucho mayor, ya que se utilizan en el flujo de trabajo de producción. No quieres que el conjunto de datos se sobrecargue con los datos de la estación de validación porque esto puede degradar la calidad del modelo debido a la incidencia de la densidad de información mencionada anteriormente.

La recomendación es añadir un máximo de 2 a 3 veces el número de páginas de datos de Document Manager y, más allá de eso, solo seleccionar cuidadosamente aquellos proveedores o muestras donde observes fallos importantes. Si hay cambios importantes conocidos en los datos de producción, como un nuevo idioma o una nueva región geográfica que se incorpora al proceso empresarial (expandiéndose de los EE. UU. a Europa o el sur de Asia), entonces los datos representativos para esos idiomas y regiones deben añadirse a Document Manager para el etiquetado manual. Los datos de la estación de validación no son apropiados para una expansión tan importante del ámbito.

Otro problema potencial con los datos de la estación de validación es el equilibrio. En Production , es común que la mayoría del tráfico provenga de un pequeño subconjunto de proveedores / clientes / regiones del mundo. Si se permite en el conjunto de entrenamiento tal como está, esto puede dar lugar a un modelo muy sesgado que tiene un buen rendimiento en un pequeño subconjunto de los datos, pero un rendimiento deficiente en la mayoría del resto de los datos. Por tanto, es importante tener especial cuidado al añadir datos de la estación de validación a un conjunto de entrenamiento.

Here is a sample scenario. You have chosen a good OCR engine, labeled 500 pages in Document Manager, resulting in good performance, and you have deployed the model in a production RPA workflow. Validation Station is starting to generate data. You should randomly select up to a maximum of 1000-1500 pages from Validation Station and import them into the Document Manager together with the first 500 pages and train your ML model again. After that, you should look very carefully at the evaluation_.xlsx to make sure the model actually improved, and then you should deploy the new model to production.

9. Implementar su automatización

Make sure to use the Document Understanding™ Process: Studio Template from the Templates section in the Studio start screen in order to apply best practices in Enterprise RPA architecture.