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.

En caso de duda, comienza entrenando un único modelo, pero mantén los documentos en diferentes lotes del Administrador de documentos (consulta el menú desplegable Filtro en la parte superior de la vista) para poder separarlos fácilmente más tarde si es necesario. De esta manera, no se pierde el trabajo de etiquetado. Cuando se trata de modelos ML, cuantos más datos, mejor. Por tanto, tener un solo modelo con muchos datos es un buen punto de partida.

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

Niveles de confianza

¿Qué son los niveles de confianza?

Cuando los modelos ML hacen predicciones, son básicamente conjeturas estadísticas. El modelo dice "probablemente este sea el importe total" de esta factura. Esto plantea la pregunta: ¿qué tan probable? Los niveles de confianza son un intento de responder a esa pregunta, en una escala de 0 a 1. Sin embargo, NO son estimaciones de probabilidad verdaderas. Son el grado de confianza que tiene el modelo en sus conjeturas y, por tanto, dependen de con qué se haya entrenado el modelo. Una mejor forma de pensar en ellos es como una medida de familiaridad: ¿qué tan familiarizado está el modelo con esta entrada del modelo? Si se parece a algo que el modelo ha visto en el entrenamiento, es posible que tenga una mayor confianza. De lo contrario, podría tener una confianza inferior.

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

La mejor manera de detectar malas predicciones, con diferencia, es a través de la aplicación de reglas empresariales. Por ejemplo, sabemos que en una factura, el importe neto más el importe de los impuestos debe ser igual al importe total. O que los números de parte de los componentes ordenados deben tener 9 dígitos. Cuando estas condiciones no se mantienen, sabemos que algo ha ido mal y podemos desencadenar el flujo de gestión de excepciones. Este es el enfoque preferido y altamente recomendado. Vale la pena invertir un esfuerzo considerable en la creación de este tipo de reglas, incluso utilizando expresiones regulares complejas o búsquedas en bases de datos para validar nombres de proveedores, números de pieza, etc. En algunos casos, es posible que incluso desee extraer algún otro documento que no sea de interés, sino solo para cruzar referencias y validar algunos valores con el documento original de interés.

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?

La mayoría de los componentes en el producto Document Understanding^TM proporcionan un nivel de confianza. Los componentes principales de un flujo de trabajo de Document Understanding^TM son Digitalización, Clasificación y Extracción.Cada uno de estos tiene una cierta confianza para cada predicción. La confianza de digitalización y extracción se exponen visualmente en la Estación de validación, por lo que puede filtrar las predicciones y centrarse solo en las de baja confianza, para ahorrar tiempo.

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 DocPath, 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 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. 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.

• Casilla de verificación con varios valores

  Esto es para manejar campos de opción múltiple u otros campos que pueden tener más de un valor, pero NO están representados como columna de tabla. Por ejemplo, una pregunta sobre un grupo Étnico en un formulario del gobierno puede contener varias casillas de verificación donde puede seleccionar todas las que correspondan.

• 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 relevante solo para los procesos de evaluación y afecta a la forma en que se calcula la puntuación de precisión. Un campo que utiliza la puntuación de Levenshtein es más permisivo: si un solo carácter de cada 10 es incorrecto, la puntuación es de 0,9. Sin embargo, si la puntuación es Coincidencia exacta , es más estricta: un solo carácter erróneo conlleva una puntuación de cero. Solo los campos de tipo Cadena tienen la opción de seleccionar la puntuación de Levenshtein de forma predeterminada.

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 limpia posible, para que no haya confusiones. Si un humano puede estar confuso, el modelo ML también lo estará.

Además, el importe actual de la factura a veces puede estar compuesto por algunos importes, tarifas e impuestos diferentes y puede no aparecer individualizado en ninguna parte de la factura. Una posible solución a esto es crear dos campos: un campo de cargos previos y un campo de totales . Estos dos siempre aparecen como valores explícitos distintos en la factura de servicios públicos. Entonces, el importe de la factura actual se puede obtener como la diferencia entre los dos. Es posible que incluso desee incluir los 3 campos (cargos-anteriores, totalesy cargos actuales) para poder hacer algunas comprobaciones de coherencia en los casos en los que el importe de la factura actual aparezca explícitamente en el documento. Por lo tanto, en algunos casos se puede pasar de uno a tres campos.

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 una factura de servicios públicos, pero a veces puede no ser legible porque solo hay un logotipo y el nombre de la empresa no está escrito explícitamente. También podría haber algún sello, escritura a mano o arrugas en el texto. En estos casos, las personas pueden etiquetar el nombre que aparece en la parte inferior derecha, en la sección Remitir el pago a del recibo de pago en las facturas de servicios públicos. El nombre suele ser el mismo, pero no siempre, ya que es un concepto diferente. Los pagos pueden hacerse a alguna otra empresa matriz o matriz, u otra entidad afiliada, y es visualmente diferente en el documento. Esto puede provocar un rendimiento deficiente del modelo. En este caso, debe crear dos campos, nombre-del-proveedor y nombre- de-pago. Luego puede buscar ambos en una base de datos de proveedores y usar la que coincida, o usar el nombre de la dirección de pago cuando falta 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 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. 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.
2. 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.
3. 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.

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.

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.

5. Entrenar el extractor

Para crear un extractor, vaya a la vista Extractores en Document Understanding y haga clic en el botón Crear extractor en la parte superior derecha. A continuación, puede seleccionar el tipo de documento, el modelo ML y la versión que desea utilizar. Puedes supervisar el progreso en la pestaña Extractores o en la vista de Detalles del extractor, que contiene un enlace al proceso del AI Center, donde puedes ver los registros detallados en tiempo real.

Al evaluar un modelo de aprendizaje automático, la herramienta más potente es evaluación_<package name>.xlsx generado en la carpeta artifacts / eval_metrics en la vista de detalles del proceso de AI Center. En la primera hoja puedes ver un informe de puntuaciones de precisión detallado, que incluye puntuaciones generales, y también por campo y por lote.

En este archivo de Excel puede ver qué predicciones están fallando y en qué archivos, y puede ver inmediatamente si se trata de un error de OCR, una extracción de ML o un error de análisis, y si puede solucionarse mediante una 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 campo en el Administrador 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.

En general, la evaluación_<package_name>.xlsx El archivo de Excel es un recurso clave en el que debe concentrarse para obtener los mejores resultados de su automatización de IA.

Importante: el entrenamiento de la GPU es muy recomendable para conjuntos de datos grandes y de producción. El entrenamiento de la CPU es mucho más lento y debe utilizarse con moderación, para pequeños conjuntos de datos con fines de demostración o de prueba. Para más información, consulta la página Canales de entrenamiento.

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,
• mediante la aplicación de búsquedas en sistemas de registro de la organización del cliente
• 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: En el caso de los números, se redondea a ocho decimales.

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: al definir reglas de negocio, ten en cuenta que los valores Comienza por, Termina por y Contiene distinguen entre mayúsculas y minúsculas.

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.

La herramienta principal para establecer este umbral es la hoja de cálculo de Excel que genera el proceso de entrenamiento en la carpeta Salidas> artefactos> eval_metrics .

Esta evaluación_<package name>.xlsx El archivo contiene una columna para cada campo y una columna para el nivel de confianza de cada predicción. Al ordenar la tabla según las columnas de confianza, puede ver dónde comienzan a aparecer los errores para un campo determinado y establecer un umbral por encima de ese nivel para garantizar que solo se envíen directamente los documentos extraídos correctamente.

8. Sintoniza con los 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 deben utilizarse únicamente tras haber verificado y optimizado los demás Componentes de extracción de datos para garantizar una buena precisión, y la única área de mejora que queda 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.

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

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 Production . No es recomendable que el conjunto de datos se satura con los datos de la estación de validación, ya que esto puede degradar la calidad del modelo debido al problema de densidad de información mencionado anteriormente.

La recomendación es añadir un máximo de 2 a 3 veces el número de páginas de datos del Administrador de documentos y, más allá de eso, elegir únicamente aquellos proveedores o muestras en los que vea fallos importantes. Si hay cambios importantes conocidos en los datos de Production , como un nuevo idioma o la incorporación de una nueva región geográfica al proceso empresarial (que se expande de EE. UU. A Europa o el sur de Asia), se deben agregar datos representativos para esos idiomas y regiones al Administrador de documentos para el etiquetado manual. Los datos de la Estación de validación no son apropiados para una expansión de ámbito tan importante.

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.

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. Después de eso, debes examinar muy cuidadosamente el evaluation_<package name>.xlsx para asegurarte de que el modelo realmente haya mejorado y, a continuación, debes implementar el nuevo modelo en producción.

9. Implementar su automatización

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