Entrenamiento de modelos de alto rendimiento

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 puede utilizarse para crear dos tipos de conjuntos de datos: conjuntos de datos de entrenamiento y conjuntos de datos de evaluación. Ambos son esenciales para construir un modelo ML de alto rendimiento, y necesitas administrar el tiempo y el esfuerzo para crear y mantener ambos. No se puede lograr un modelo ML de alto rendimiento sin 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:

• Los conjuntos de datos de entrenamiento se basan solo en los recuadros delimitadores de las palabras en la página que representa las diferentes piezas de información que necesitas extraer.

  • Al etiquetar Conjuntos de entrenamiento, céntrate solo en la propia página y en los recuadros de palabras.

• Los conjuntos de datos de evaluación se basan solo en los valores de los campos, que aparecen en la barra lateral (para Campos regulares) o en la barra superior (para los campos de Columna).

  • 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:

1. 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.
2. Selecciona un conjunto de datos bien equilibrado y representativo para el entrenamiento
3. Seleccionar un conjunto de datos representativo para la evaluación
4. Definir los campos que se extraerán
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 en AI Center
9. Definir e implementar las reglas empresariales para procesar la salida del modelo
10. (Opcional) Elegir el umbral de confianza para la extracción
11. Entrenamiento con datos de la estación de validación
12. Bucle de ajuste fino automático (Preview)
13. 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.

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 conllevan un coste, aunque bajo. Pero si la precisión es mayor en algunos campos de datos esenciales para tu proceso empresarial, se recomienda encarecidamente utilizar el mejor OCR disponible, ya que podría valerte la pena más adelante, pues todo lo que sigue dependerá de ello.

Ten en cuenta que la actividad Digitalizar documento tiene el ajuste ForzarAplicaciónOCR configurado en Falso de forma predeterminada, lo que implica que cuando se trabaja con archivos .pdf no se utiliza el motor OCR, sino que el texto se extrae directamente del propiodocumento .pdf. en el caso de documentos .pdfnativos. No obstante, muchos documentos .pdf nativos pueden contener logotipos o incluso encabezados o pies de página que no se captan. Estos pueden contener información identificativa de la empresa, como su nombre, dirección, código del IVA o datos de pago, muy relevantes en los procesos empresariales. Si tu proceso se encuentra en esta situación, configura ForzarAplicaciónOCR en Verdadero para asegurarte de que se detecta todo el texto, si bien esto podría ralentizar el proceso.

2. Crear un conjunto de datos de 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:

• 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 elemento, cantidad del elemento)
• 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 (divisa)
• 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.

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 de un cuidado especial para evitar modelos frágiles que sean sensibles a pequeños cambios en el texto del OCR. Una manera de evitarlo es asegurarse de que haya cierta variabilidad deliberada en los documentos de entrenamiento, imprimiéndolos y luego escaneándolos o fotografiándolos con aplicaciones de escáner para teléfonos móviles. Las ligeras distorsiones o los cambios de resolución confieren mayor solidez al modelo.

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.

Los números anteriores son pautas generales, no requisitos estrictos. En general, se puede empezar con un conjunto de datos más pequeño y seguir añadiendo datos hasta conseguir una buena precisión. Esto es particularmente útil para sincronizar el trabajo de RPA con la construcción del modelo. Además, se puede utilizar una primera versión del modelo para etiquetar previamente los datos adicionales (consulta la vista Configuración y el botón Predecir en el Administrador de documentos). Esto puede acelerar el etiquetado de los datos de entrenamiento adicionales.

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

Los datos deben seleccionarse de manera que cubran la diversidad de los documentos que pueden encontrarse en el flujo de trabajo de producción. Por ejemplo, si se reciben facturas en inglés, pero algunas de ellas proceden de EE. UU., India y Australia, es probable que tengan un aspecto distinto, por lo que hay que asegurarse de tener muestras de documentos de los tres países. Esto es pertinente no solo para el propio entrenamiento del modelo, sino también para el etiquetado, pues a medida que etiquetas los documentos podrías descubrir que necesitas extraer campos nuevos y distintos de algunas de estas regiones, como el código GSTIN de la India, o el código ABN de Australia. Consulta más información en la sección Definir campos.

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.

Al importar los datos de evaluación en Document Manager, debes asegurarte de marcar la casilla "Convertir en un conjunto de evaluación" en la ventana de diálogo Importar. De este modo, se garantiza que los datos se mantengan al entrenar, y también se puedan exportar fácilmente para ejecutar Evaluaciones utilizando la opción de conjunto de evaluaciones en el menú desplegable Filtro del Administrador de documentos.

Importante: A partir de la versión preliminar 21.9 en Automation Cloud y de la versión GA local 21.10, el Document Manager ha pasado a gestionar documentos de varias páginas en lugar de cada página como entidad independiente como sucedía anteriormente. Se trata de un cambio importante, especialmente para las evaluaciones, que eran su principal motivación. Las evaluaciones deben ser representativas del proceso del runtime, y en el runtime se procesan los documentos de varias páginas como un todo, en lugar de como páginas independientes. Para beneficiarse de esta mejora en los paquetes ML con la versión 21.10 o posterior, basta con desactivar la casilla "Exportación compatible con versiones anteriores" en el diálogo de exportación. Si marcas esta casilla, el conjunto de datos se exportará a la antigua, página a página, y las puntuaciones de evaluación no serán tan representativas del rendimiento del runtime.

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
• Se trata de la configuración más importante, ya que determina el posprocesamiento de los valores, especialmente para las fechas (detecta si el formato es de estilo estadounidense o no estadounidense, y luego les da el formato aaaa-mm-dd) y para los números (detecta el separador de decimales: coma o punto). Los números de identificación eliminan todo lo que precede a dos puntos o a un símbolo de almohadilla. El tipo de contenido cadena no realiza ninguna corrección y puede utilizarse cuando se desee realizar su propio análisis en el flujo de trabajo RPA.
• 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
• Esto es pertinente únicamente para los Procesos de evaluación y afecta al modo en que se calcula la puntuación de precisión. Un campo que utiliza la puntuación Levenshtein es más permisivo: si uno de cada 10 caracteres es erróneo, la puntuación será de 0,9. Sin embargo, si el resultado es Coincidencia exacta será más estricto: un solo carácter equivocado dará lugar a una puntuación de cero. Todos los campos son, de forma predeterminada, de coincidencia exacta. Solo los campos de tipo cadena tienen la opción de seleccionar la puntuación Levenshtein.

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.

Nota: Cada campo representa un concepto diferente, y deben definirse de la manera más clara y nítida posible, para que no haya confusión. Si una persona es capaz de confundirlo, también lo hará el modelo ML.

Además, el importe de la factura actual a veces puede estar compuesto por varios importes, tasas e impuestos distintos y no aparecer individualizado en ninguna parte de la factura. Una posible solución a este problema es crear dos campos: un campo gastos anteriores y un campo total. Estos dos campos aparecen siempre como valores explícitos distintos en la factura de servicios públicos. Así, el importe de la factura actual puede obtenerse como la diferencia entre ambos. Puede que incluso quieras incluir los tres campos (gastos anteriores, total y gastos actuales) para poder hacer algunas comprobaciones de coherencia en los casos en que el importe de la factura actual aparezca explícitamente en el documento. Así que podrías pasar de uno a tres campos en algunos casos.

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

El nombre de la empresa suele aparecer en la parte superior de una factura o un recibo de servicios, aunque a veces puede no ser legible porque solo figura un logotipo y el nombre de la empresa no está escrito de manera explícita. O puede que haya algún otro sello, escritura a mano o arrugas sobre el texto. En estos casos, los usuarios pueden etiquetar el nombre que aparece en la parte inferior derecha, en el apartado "Remitir pago a" del recibo de pago de las facturas de servicios. Ese nombre suele ser el mismo, pero no siempre, ya que se trata de un concepto diferente. Los pagos pueden hacerse a alguna otra empresa matriz o a un holding, o a otra entidad afiliada, y será visualmente distinto en el documento. Esto puede ocasionar un mal funcionamiento del modelo. En este caso, te interesaría crear dos campos, nombre-del-proveedor y nombre-dirección-pago. A continuación, puedes buscar ambos en una base de datos de proveedores y utilizar el que corresponda, o utilizar nombre-dirección-pago cuando no haya nombre-del-proveedor.

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

Dividir elementos es un ajuste que aparece únicamente para los campos de columna, y permite al modelo saber cuándo termina un elemento de línea y comienza otro. Cuando persona que observa un documento, para saber cuántas filas hay, lo más probable es que te fijes en cuántos importes hay en la parte derecha. Cada importe se refiere a un elemento de línea en general. Esto es una indicación de que el importe de las líneas es una columna en la que deberías habilitar Dividir elementos. También se pueden marcar otras columnas, en caso de que el OCR omita el importe de las líneas, o que el modelo no lo reconozca: la cantidad y el precio unitario suelen marcarse también como 'Dividir elementos'.

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

Estos afectan al posprocesamiento, especialmente a la limpieza, al análisis sintáctico y al formato. El más complejo es el formato de fecha, pero también el formato de número requiere determinar el separador de decimales y el de miles. En algunos casos, si el análisis falla, puedes informar del problema al soporte de UiPath y recurrir al tipo de contenido String, que no realiza ningún análisis. En ese caso, deberías necesitar analizar el valor en tu lógica del flujo de trabajo RPA.

Otra configuración relevante es la casilla de verificación Multilínea, que es relevante principalmente para los campos de tipo String. Siempre que algún otro campo obtenga resultados no previstos o ningún resultado, lo primero que hay que intentar es cambiarlo a campo de tipo Cadena multilínea, para ver el resultado intacto de la predicción del modelo.

6. Etiquetar el conjunto de datos de entrenamiento

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

Siempre que un campo aparezca varias veces en una página, en la medida en que representen el mismo concepto (véase más arriba la sección Definir campos), todos ellos 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 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.

Al etiquetar, presta atención a los campos que puedan tener varios significados/conceptos que se solapen, en caso de que necesites dividir un campo en dos campos independientes, o campos que no podrías no necesitar expresamente, pero que, si están etiquetados, podrían ayudarte a realizar cierta validación o lógica de comprobación de la autocoherencia en el flujo de trabajo RPA. Ejemplos típicos son cantidad, precio unitario e importe de línea en los elementos de línea de facturas. El importe de la línea es el producto de la cantidad y el precio unitario, aunque resulta muy útil para comprobar la coherencia sin necesidad de niveles de confianza.

7. Etiquetar el conjunto de datos de evaluación

Al etiquetar los conjuntos de datos de evaluación (también denominados conjuntos de datos de prueba) hay que centrarse en algo que difiere ligeramente del etiquetado de los conjuntos de datos de entrenamiento. Mientras que para los conjuntos de datos de entrenamiento solo importan los cuadros delimitadores de los campos en el documento, en el caso de los conjuntos de datos de evaluación solo importan los valores de los campos. Puedes editarlos haciendo clic en el valor que aparece en la barra lateral derecha o superior y editándolo. Para regresar al valor analizado automáticamente, haz clic en el icono de bloqueo.

Nota: Por comodidad, rapidez y para evitar errores tipográficos, recomendamos hacer clic en las casillas del documento a la hora de etiquetar, y solo efectuar las correcciones manualmente. Introducir manualmente los valores completos es más lento y propenso a errores.

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.

Cuando se evalúa un modelo ML, la herramienta más potente es el archivo evaluation.xlsx generado en la carpeta artifacts/eval_metrics. En este archivo de Excel se puede ver qué predicciones están fallando y en qué archivos, así como ver inmediatamente si se trata de un error de OCR, de una extracción ML o de un error de análisis, y si se puede solucionar con una simple lógica en el flujo de trabajo RPA o requiere un motor OCR distinto, más datos de entrenamiento o mejorar el etiquetado de las configuraciones de los campos en 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.
• Deben estar presentes los campos Número de factura, Fecha, Suma total (y otros quizás).
• 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 a la suma de la línea
• 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.

Esta hoja de cálculo contiene una columna para cada campo y una columna para el nivel de confianza de cada predicción. Puedes añadir una columna denominada confianza_mínima, que toma el mínimo de todas las confidencias a todos los campos relevantes para tu proceso empresarial que no estén ya cubiertos por las reglas empresariales. Por ejemplo, puede que no desees poner un umbral en las confidencias de los elementos de línea, sino en el nombre del proveedor, el importe total, la fecha, la fecha de vencimiento, el número de factura y otros campos esenciales. Al ordenar la tabla en función de la columna confianza_mínima, podrías ver dónde empiezan a surgir los errores y establecer un umbral por encima de ese nivel para garantizar que solo se pasan los documentos correctamente extraídos.

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

Los datos de la Estación de validación pueden ayudar a mejorar las predicciones del modelo aunque, a menudo, resulta que la mayoría de los errores no se deben al propio modelo sino al OCR, a errores de etiquetado, a incoherencias o a incidencias de posprocesamiento (por ejemplo, el formato de fechas o números). Así pues, el primer aspecto clave es que los datos de la Estación de validación deberían utilizarse únicamente tras haber verificado y optimizado los demás Componentes de extracción de datos, para garantizar una buena precisión. La única área de mejora pendiente es la propia predicción del modelo.

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.

Importante:

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.

La recomendación es añadir un máximo de 2 o 3 veces el número de páginas de los datos de Document Manager y, por encima de eso, solo seleccionar aquellos proveedores o muestras en los que se observen fallos importantes. Si se conocen cambios importantes en los datos de producción, como un nuevo idioma, o una nueva región geográfica que se incorpora al proceso empresarial (que se expande de Estados Unidos a Europa o Asia Meridional), deben añadirse datos representativos de esos idiomas y regiones al Administrador de documentos para su etiquetado manual. Los datos de la estación de validación no son apropiados para una ampliación tan importante.

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)

El bucle de ajuste fino automático es una capacidad de Vista previa que resulta útil para mantener un modelo de alto rendimiento que ya se ha creado mediante los pasos anteriormente descritos. Para asegurarse de que el ajuste fino automático genere mejores versiones del modelo, es fundamental disponer de un buen conjunto de datos de evaluación y utilizar un proceso completo automáticamente reprogramado que ejecute el entrenamiento y la evaluación a la vez. De este modo, puedes ver si el entrenamiento más reciente ha generado un modelo más preciso que el anterior, y si es así, puedes implementar el nuevo modelo en la habilidad ML invocada por los robots en tu proceso empresarial.

Nota: El conjunto de datos de entrenamiento va cambiando a medida que llegan más datos y el Document Manager los exporta de forma periódica según lo programado en el cuadro de diálogo Exportación programada. La evaluación se ejecuta en el mismo conjunto de datos de evaluación especificado en el proceso. Los conjuntos de datos de evaluación nunca cambian de forma automática, sino que siempre hay que revisarlos, etiquetarlos y exportarlos manualmente. Es conveniente cambiar el conjunto de evaluación en contadas ocasiones para poder comparar las puntuaciones de precisión entre diferentes ejecuciones de entrenamiento.

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.

Como se ha mencionado anteriormente en la sección Crear un conjunto de datos de evaluación, las implementaciones de procesos de evaluación para paquetes ML de la versión 21.10 o posterior calculan las puntuaciones por documento, lo que refleja con precisión los resultados que se ven en un flujo de trabajo RPA. Esto supone que tu conjunto de datos se ha etiquetado por documento en el Administrador de documentos. Para saber si un documento de varias páginas está etiquetado por documento, puedes desplazarse de forma natural por las páginas como en un lector de PDF normal. Si tienes que hacer clic en Siguiente para pasar de una página a la siguiente, entonces cada página se considera un documento independiente.

13. Implementar la automatización

Asegúrate de utilizar el Proceso de Document Understanding de la sección Plantillas en la pantalla de inicio de Studio para aplicar las mejores prácticas en la arquitectura Enterprise RPA.