Entrenamiento de modelos de alto rendimiento

El poder de los modelos de aprendizaje automático es que se definen mediante datos de entrenamiento en lugar de por lógica explícita expresada en código informático. Esto significa que se debe tener mucho cuidado al preparar conjuntos de datos porque un modelo es tan bueno como el conjunto de datos que se usó para entrenarlo. En ese sentido, lo que UiPath Studio es para los flujos de trabajo RPA , una sesión de Tipo de documento (en Document & Understanding Cloud) son para las capacidades de aprendizaje automático . Ambos requieren algo de experiencia para utilizarse de manera efectiva.

¿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 se puede utilizar para crear dos tipos de conjuntos de datos: conjuntos de datos de entrenamiento y conjuntos de datos de evaluación.

Los conjuntos de datos de evaluación son relevantes para los científicos de datos o para solucionar problemas detallados. Sin embargo, para la gran mayoría de los escenarios de automatización Enterprise , solo se necesita y se recomienda el conjunto de datos de entrenamiento. Los procesos de entrenamiento ahora devuelven artefactos con puntuación completa, incluidos los siguientes:

• Precisión general del modelo: se usa como puntuación principal que se muestra tanto en la vista de Detalles del extractor de Document Understanding como en la carpeta de artefactos de AI Center (también accesible desde Document Understanding).
• Puntuación general del modelo y a nivel de campo F1: se proporciona, por motivos históricos, en la carpeta de artefactos del AI Center (a la que también se puede acceder desde Document Understanding).
• Métricas detalladas por campo y por lote, así como una comparación del rendimiento en el archivo de Excel disponible en la carpeta de artefactos del AI Center (también accesible desde Document Understanding).

Es posible puntuar el modelo como parte del entrenamiento porque el conjunto de entrenamiento se divide automáticamente de forma aleatoria en un 80% / 20% entre los datos de entrenamiento y validación, y las puntuaciones se calculan sobre los datos de validación.

A medida que aumenta el conjunto de datos, tanto la división de entrenamiento como la de validación evolucionan, lo que significa que las puntuaciones no son directamente comparables con el tiempo (que es lo que le interesaría a los científicos de datos). Sin embargo, reflejan el rendimiento del modelo en los datos más recientes, por lo que son más representativos del rendimiento actual del modelo en los datos de Production actuales (que es en lo que están interesados los propietarios de procesos empresariales).

Con este enfoque, tiene los siguientes beneficios:

• No corre el riesgo de ver puntuaciones medidas en datos obsoletos, potencialmente con años de antigüedad.
• Reducirá la cantidad de etiquetado que tiene que hacer.
• Todos los datos que se etiquetan contribuyen a mejorar el modelo, lo que lleva a un mejor rendimiento más rápido.

Componentes de extracción de datos

La extracción de datos se basa en los siguientes componentes:

• Reconocimiento óptico de caracteres
• Posprocesamiento de OCR
  • Creación de palabras y líneas
  • Agrupar caracteres en palabras y las palabras en líneas de texto
• Predicción del modelo de aprendizaje automático para cada palabra/casilla de la página
• Normalización de datos
  • Por ejemplo, agrupar palabras en varias líneas en una dirección, aplicar el formato estándar aaaa-mm-dd a una fecha
• Selección de valor
  • Aplicar un algoritmo para seleccionar cuál de las múltiples instancias de un valor determinado se devuelve realmente, para los casos en los que el documento tiene dos o más páginas y algunos campos aparecen en más de una página.

Niveles de confianza

What are confidence levels?

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

What are confidence levels useful for?

Business automations need ways to detect and handle exceptions - i.e. instances where an automation goes wrong. In traditional automations this is pretty obvious because when an RPA workflow breaks, it will just stop, hang, or throw an error. That error can be caught and handled accordingly. However, Machine Learning models do not throw errors when they make bad predictions. So how do we determine when an ML model has made a mistake and the exception handling flow needs to be triggered? This often involves human manual involvement, perhaps using Action Center.

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

However, in some cases, none of these options exist and you still want to detect potentially bad predictions. In these cases you can fall back on the confidence level. When confidence level for a prediction is low, say, below 0.6, the risk that the prediction is incorrect is higher than if the confidence is 0.95. However, this correlation is fairly weak. There are many instances where a value is extracted with low confidence but it is correct. It is also possible, though relatively rare, that a value is extracted with high confidence (over 0.9) but it is incorrect. For these reasons we strongly encourage users to rely on business rules as much as possible and only use confidence levels as a last resort.

What types of confidence levels are there?

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

Confidence score scaling (or calibration)

The confidence levels of different models will be scaled differently, depending on the model design. For example some models return confidence levels in the range 0.9-1 almost always, and only very rarely below 0.8. Other models have confidence levels spread much more evenly between 0 and 1, even if usually they are clustered at the higher end of the scale. As a result, the confidence thresholds on different models will be different. For example a confidence threshold on the OCR will not be the same as the threshold on the ML Extractor or the ML Classifier. Also, whenever there is a major architecture update on a model, like the one coming up with the release of the DocPath Generative AI-based model architecture, the confidence level distribution will change, and confidence thresholds will need to be re-assessed.

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. Definir los campos que se extraerán
3. Selecciona un conjunto de datos bien equilibrado y representativo para el entrenamiento
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

La opción predeterminada debe ser UiPath Document OCR para los idiomas latinos europeos o UiPath chino-japonés-coreano. En caso de que necesite procesar otros idiomas, incluido elCloud , Cloud Cloud devanagir pack en Studio). Vale la pena crear algunas sesiones diferentes del Administrador de documentos con diferentes motores de OCR para comprobar cuál funciona mejor en sus documentos. Cambiar el motor de OCR más adelante en el proyecto puede resultar costoso.

Ten en cuenta que la actividad Digitalizar documento tiene el ajuste AplicarOCRenPDF configurado en Automático de forma predeterminada, lo que implica que cuando se trabaja con archivos .pdf de forma predeterminada, Digitize intenta extraer la mayor cantidad de texto posible del .pdf y solo imágenes de OCR como logotipos, y combinar los resultados.

Sin embargo, el archivo .pdf a veces los documentos están corruptos o tienen un formato inusual, lo que provoca errores en el texto extraído. En este caso, establece AplicarOCRonPDF en Sí.

Otro beneficio de aplicar OCR en todos los archivos PDF documentos que utilizan UiPath Document OCR es que UiPath Document OCR reconoce las casillas de verificación que son elementos cruciales de documentos como formularios. Tenga en cuenta, sin embargo, que aplicar OCR en todo tipo de aplicaciones ralentizará un poco la digitalización.

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.

3. Crear un conjunto de datos de entrenamiento

La tecnología de aprendizaje automático tiene el beneficio principal de poder manejar problemas complejos con una gran diversidad. Al estimar el tamaño de un conjunto de datos de entrenamiento, se observa primero el número de campos y sus tipos, y el número de idiomas. Un solo modelo puede manejar varios idiomas siempre que no sean chino / japonés / coreano. Los escenarios posteriores generalmente requieren conjuntos de datos de entrenamiento y modelos independientes.

Hay 3 tipos de campos:

1. Campos regulares (fecha, suma total)

   Para los campos regulares, necesita al menos entre 20 y 50 muestras de documentos por campo. Por tanto, si necesita extraer 10 campos regulares, necesitará al menos entre 200 y 500 muestras. Si necesita extraer 20 campos regulares, necesitará al menos 400-1000 muestras. La cantidad de muestras que necesita aumenta con el número de campos. Más campos significa que necesita más muestras, entre 20 y 50 veces más.

2. Campos de columna (precio unitario del elemento, cantidad del elemento)

   Para los campos de columna, necesita al menos de 50 a 200 muestras de documentos por campo de columna, por lo que, para campos de 5 columnas, con diseños limpios y sencillos puede obtener buenos resultados con 300 muestras de documentos, pero para diseños muy complejos y diversos, puede necesitar más 1000. Para abarcar varios idiomas, necesita al menos 200- 300 muestras por idioma, suponiendo que cubran todos los diferentes campos. Por tanto, para 10 campos de encabezado y 4 campos de columna con 2 idiomas, 600 muestras pueden ser suficientes (400 para las columnas y encabezados más 200 para el idioma adicional), pero algunos casos pueden requerir 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 cada clase.

El rango recomendado para el tamaño del conjunto de datos se basa en la información proporcionada en la pestaña Calculadora. Para escenarios más sencillos con pocos campos regulares y diseños de documentos claros, se pueden obtener buenos resultados con los conjuntos de datos en el rango naranja bajo. Para situaciones más complejas, especialmente cuando se trata de tablas complejas con muchas columnas, los buenos resultados pueden requerir conjuntos de datos en rango naranja alto o incluso verde.

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.

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 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, 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 extraer datos de las facturas, para lo cual tenemos un modelo predefinido, pero también hay 2 campos regulares más y 1 campo de columna más que el modelo de facturas previamente entrenado no reconoce. En este caso, normalmente necesitará un conjunto de datos mucho más pequeño que si hubiera entrenado todos los campos desde cero. La estimación del tamaño del conjunto de datos se proporciona cuando se crea un tipo de documento en Document Understanding Cloud y, a continuación, se puede acceder a él en la vista Diagnóstico del conjunto de datos. Sin embargo, tenga en cuenta que cualquier documento que utilice para entrenar un modelo debe etiquetarse completamente, incluidos los campos nuevos, que el modelo listo para usar no reconoce, y también el original de los campos, que el reconoce.

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 los documentos (por ejemplo, gastos de gestión, descuento). En estos casos, necesitará tomar una decisión empresarial. Si esos campos raros no son cruciales para su automatización, puede salirse con la suya con un pequeño número de muestras (10-15) de ese campo en particular, es decir, páginas que contienen un valor para ese campo. Sin embargo, si esos campos son cruciales, deberá asegurarse de incluir en su conjunto de formación al menos 30-50 muestras de ese campo para asegurarse de abarcar 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 consta solo de facturas de un solo proveedor, entonces se trata de un conjunto de datos muy desequilibrado. Un conjunto de datos perfectamente equilibrado es donde cada proveedor aparece un número igual de veces. No es necesario que los conjuntos de datos estén perfectamente equilibrados, pero debes evitar que más del 20% de todo tu conjunto de datos proceda de un solo proveedor. En algún momento, un mayor número de datos no ayuda, e incluso podría degradar la precisión en otros proveedores porque el modelo optimiza (sobreajusta) demasiado 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.

División entrenamiento / validación

Cualquier conjunto de datos de entrenamiento se divide automáticamente en segundo plano en un Conjunto de entrenamiento (80% seleccionado aleatoriamente) y un Conjunto de Validación (20% seleccionado aleatoriamente). Durante el entrenamiento de modelos de aprendizaje profundo, el conjunto de entrenamiento se usa para la propagación hacia atrás, la parte que modifica las ponderaciones de los nodos de la red, mientras que el conjunto de validación solo se usa para saber cuándo detener el entrenamiento. En otras palabras, se utiliza para evitar un sobreajuste en el conjunto de entrenamiento.

Así es como podemos obtener las puntuaciones de evaluación completas al final de cualquier ejecución de entrenamiento: devolvemos las puntuaciones en el conjunto de validación. Este conjunto no se utiliza técnicamente para entrenar la red, solo para prevenir el sobreajuste. Sin embargo, dado que se selecciona aleatoriamente el 20% de todo el conjunto de datos, tiende a distribuirse de manera similar al conjunto de entrenamiento. Esta coherencia es buena porque significa que las puntuaciones que obtiene reflejan la capacidad del modelo para aprender de los datos, que es lo que normalmente nos importa. Si un modelo no puede aprender, significa que los datos son inconsistentes o el modelo tiene una limitación, y esos son puntos cruciales que debemos saber de inmediato al entrenar un modelo.

La desventaja de este enfoque es que las puntuaciones no pueden necesariamente compararse de manera exacta a medida que el conjunto de datos crece, y también que las puntuaciones no reflejan la capacidad del modelo para generalizar, solo su capacidad de aprender. Sin embargo, las comparaciones básicas y la capacidad de medición para generalizar son preocupaciones técnicas de la ciencia de datos que solo tienen un impacto indirecto en el rendimiento empresarial o el retorno de la inversión para la mayoría de las automatizaciones.

4. Label the training dataset

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. Train the 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. Define and implement business rules

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. Deploy your automation

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