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 una persona puede confundirse sobre el valor correcto de un campo, lo mismo ocurre con un modelo ML.

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.

En caso de duda, empieza por entrenar un solo modelo, aunque guarda los documentos en diferentes lotes del Administrador de documentos (consulta el menú desplegable Filtro en la parte superior central de la vista del Administrador de documentos). Si es necesario, puedes separar fácilmente los documentos más adelante, sin perder el etiquetado. Cuando se trata de modelos ML, cuantos más datos, mejor. Comienza por tener un único modelo con datos amplios.

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:

• Los Conjuntos de datos de entrenamiento se basan en los cuadros delimitadores de las palabras de la página que representan las diferentes partes de la información que necesitas extraer.
• Al etiquetar Conjuntos de entrenamiento, céntrate en la propia página y en los cuadros de palabras.
• Los Conjuntos de datos de evaluación se basan en los valores de los campos, que aparecen en la barra lateral (para los 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. Se recomienda etiquetar haciendo clic en las casillas de la página, y comprobar la exactitud de los valores.

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

Crear un modelo ML de alto rendimiento

Para obtener 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) sigue estos pasos:

1. Elegir el mejor motor OCR para los documentos

   • Esto influye en el OCR, en la creación de palabras y líneas (que dependen parcialmente del OCR), y en todo lo que sigue.
2. Seleccionar 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. Concéntrate en las áreas que deseas extraer. Por ejemplo, si necesitas extraer los nombres de las empresas que aparecen como parte de los logotipos en las facturas, puedes 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 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.

Ten en cuenta que la actividad Digitalizar documento tiene configurado ApplyOcrOnPDF en Auto de forma predeterminada, lo cual determina si el documento requiere la aplicación del algoritmo de OCR de acuerdo con el documento de entrada. Evita que se pierda la extracción de información importante (logotipos, encabezados, pies de página, etc.) configurando ApplyOcrOnPDF en Sí y asegurándote de que se detecte todo el texto, aunque 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 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.
• Campos de columna (precio unitario del elemento, cantidad del elemento)
• 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.
• Campos de clasificación (divisa)
• Los campos de clasificación suelen requerir al menos entre 10 y 20 muestras de documentos 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 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.

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 creació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, 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 anterior 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

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 Estados Unidos, India y Australia, probablemente tengan un aspecto distinto, por lo que hay que asegurarse de tener muestras de documentos de los tres países. Esto es importante no solo para el entrenamiento del modelo, sino también para el etiquetado. Al etiquetar los documentos, es posible descubrir que hay que extraer nuevos campos diferentes 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

Para los conjuntos de entrenamiento, lo más importante son las páginas y el número de páginas. Respecto a los conjuntos de evaluación, solo nos referimos 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. Incluso si algunos proveedores están excesivamente representados, no hay 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 el Administrador de documentos, es necesario marcar la casilla "Hacer de esto un conjunto de evaluación" en la ventana de diálogo Importar. Esto 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 evaluación en el menú desplegable Filtro en el 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 gestiona los documentos de varias páginas en lugar de cada página como entidad independiente. Se trata de un cambio importante, especialmente para las evaluaciones, que eran su principal motivación. Las evaluaciones deben ser representativas del proceso en tiempo de ejecución y los documentos de varias páginas se procesan 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 exporta de la manera anterior, página por página, y las puntuaciones de la evaluación no son tan representativas del rendimiento en tiempo de ejecución.

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 puede entrenarse con ellos. Esto es práctico cuando el etiquetado de un campo es un trabajo en curso, es demasiado raro o la prioridad es baja.
• 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 es de 0,9. Si la puntuación es Coincidencia exacta, es más estricta: un solo carácter erróneo conlleva 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 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: 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 lo confunde, el modelo ML también lo hace.

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. También puede haber algún sello, escritura a mano o arrugas encima del 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 servicios públicos. 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 filial, y es visualmente distinto en el documento. Esto puede ocasionar un mal funcionamiento del modelo. En este caso, debes crear dos campos: nombre del proveedor y nombre de la dirección de pago. A continuación, puedes buscar ambos en una base de datos de proveedores y utilizar el que corresponda, o utilizar el nombre de la dirección de pago cuando falte el 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 "/". Al hacerlo, aparece un cuadro verde que cubre toda la fila de la tabla. A continuación, se muestra el ejemplo de una tabla en la que las dos primeras filas están formadas por varias líneas de texto y deben agruparse con la tecla de acceso directo "/", 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.

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 una persona observa un documento, para saber cuántas filas hay, probablemente se fije en cuántos importes hay en la parte derecha. Cada importe se refiere a un elemento de línea en general. Esto indica que el importe de la línea es una columna en la que debes habilitar Dividir elementos. También se pueden marcar otras columnas, en caso de que el OCR omita el importe de la línea, o el modelo no lo reconozca: la cantidad y el precio unitario suelen marcarse también como 'Dividir elementos'.

5. Configurar los campos

La configuración más importante es el tipo de contenido, a excepción de cadena:

• 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 Cadena, que no realiza el análisis. En tal caso, deberás analizar el valor en tu lógica de 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 Cadena. 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, 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.

Todos los campos deben etiquetarse, incluso si un campo aparece varias veces en una página, siempre y cuando representen el mismo concepto (consulta la sección Definir campos más arriba).

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.

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 necesites 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 volver al valor analizado automáticamente, haz clic en el icono de candado.

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 ejecutan 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 extracción ML o 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 el Administrador de documentos.

Este archivo de Excel también es muy útil para identificar las reglas empresariales más relevantes que necesitas aplicar al flujo de trabajo 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 pueden ser detectados por las reglas empresariales, también puedes utilizar los niveles de confianza. El archivo Excel además contiene niveles de confianza para cada predicción, por lo que puedes utilizar las funciones de Excel como la clasificación y el filtrado para determinar cuál es el umbral de confianza óptimo para tu escenario empresarial.

En general, el archivo 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. Existen dos maneras 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 totalmente perfectos. Siempre hay un porcentaje pequeño, pero no nulo, de predicciones correctas de baja confianza o de predicciones erróneas de gran confianza. Además, y lo que es más importante, un campo ausente carece de confianza, por lo que un umbral de confianza nunca puede detectar los errores por los que un campo no se extrae 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.
• 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.

En particular, los niveles de confianza de los campos de columna rara vez 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 decenas de valores. Por tanto, establecer un umbral mínimo para tantos valores puede ser especialmente poco fiable, ya que es muy probable que un valor sea de poca confianza, lo cual conduciría a que la mayoría o todos los documentos se enviaran a validación por parte de una persona, muchas veces de manera 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.

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 confianza_mínima que tome el mínimo de todas las confianzas en todos los campos que sean importantes para tu proceso empresarial y que no estén ya cubiertos por 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, puedes ver dónde empiezan a surgir los errores y establecer un umbral por encima de ese nivel para garantizar que los documentos correctamente extraídos se envíen directamente.

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

Los datos de la estación de validación pueden 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 problemas 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 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.

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 hay que entrenar en el paquete ML con la versión menor 0 (cero), que es la versión liberada por UiPath Out of the Box.

Importante: Erróneamente, a menudo se supone que la manera de utilizar los datos de la Estación de validación es volver a entrenar iterativamente la versión anterior del modelo, de manera que se utilice el lote actual para entrenar el paquete X.1 y obtener el 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 como máximo 2 o 3 veces el número de páginas de los datos del Administrador de documentos y, por encima de eso, solo seleccionar aquellos proveedores o muestras de documentos 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.