Entraînement de modèles hautement performants

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.

Que peut faire un modèle ML d'extraction de données ?

Un modèle ML peut extraire des données d'un seul type de document, bien qu'il puisse couvrir plusieurs langues différentes. Il est essentiel que chaque champ (Montant total, Date, etc.) ait une signification unique et cohérente. Si un humain peut ne pas comprendre la valeur correcte d’un champ, un modèle ML le fera également.

Des situations ambiguës peuvent apparaître. Par exemple, une facture de services publics n'est-elle qu'un autre type de facture ? Ou s'agit-il de deux types de documents différents qui nécessitent deux modèles de ML différents ? Si les champs que vous devez extraire sont les mêmes (c'est-à-dire qu'ils ont la même signification), vous pouvez les traiter comme un seul type de document. Cependant, si vous devez extraire différents champs pour différentes raisons (différents processus métier), cela peut indiquer que vous devez les traiter comme deux types de documents différents et, par conséquent, recourir à entraîner deux modèles différents.

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

Ensemble de données d'entraînement et d'évaluation

Document Manager peut être utilisé pour créer deux types d'ensembles de données : des ensembles de données d'entraînement et des ensembles de données d'évaluation.

Les ensembles de données d'évaluation sont pertinents pour les scientifiques des données ou pour effectuer un dépannage détaillé afin de reproduire certains problèmes. Cependant, pour la grande majorité des scénarios d'automatisation Enterprise , seul l'ensemble de données d'entraînement est nécessaire et recommandé. Les pipelines d'entraînement renvoient désormais des artefacts de notation complets, y compris les suivants :

• Précision globale du modèle – utilisée comme score principal affiché dans la vue Détails de l'extracteur de Document Understanding et dans le dossier des artefacts de l'AI Center (également accessible à partir de Document Understanding).
• Score F1 global du modèle et au niveau du champ – fourni pour des raisons historiques dans le dossier des artefacts de l’AI Center (également accessible à partir de Document Understanding).
• Mesures détaillées par champ et par lot, ainsi que comparaison des performances dans le fichier Excel disponible dans le dossier des artefacts de l'AI Center (également accessible à partir de Document Understanding).

La notation du modèle dans le cadre de l'entraînement est possible car l'ensemble d'entraînement est automatiquement divisé de manière aléatoire à 80/20 % entre les données d'entraînement et de validation, et les scores sont calculés sur les données de validation.

À mesure que l'ensemble de données augmente, les fractionnements d'entraînement et de validation évoluent, ce qui signifie que les scores ne sont pas directement comparables dans le temps (ce qui intéresserait un scientifique des données). Cependant, ils reflètent les performances du modèle sur les données les plus récentes, ils sont donc plus représentatifs des performances actuelles du modèle sur les données de Production actuelles (ce qui intéresse les propriétaires de processus métier).

Cette approche vous offre les avantages suivants :

• Vous ne risquez pas de consulter des scores mesurés sur des données obsolètes, potentiellement anciennes.
• Vous réduisez la quantité de labellisation que vous devez effectuer.
• Toutes les données que vous labellisez contribuent à améliorer réellement le modèle, ce qui conduit à de meilleures performances plus rapidement.

Composants d'extraction de données

L'extraction de données repose sur les composants suivants :

• OCR (reconnaissance optique de caractères)
• Post-traitement OCR
  • Création de mots et de lignes
  • Regroupement des caractères en mots et des mots en lignes de texte
• Prédiction du modèle d'apprentissage automatique pour chaque mot/boîte de la page
• Normalisation des données
  • Par exemple, regroupe des mots sur plusieurs lignes dans une adresse, formate une date au format standard jj/mm/aaaa
• Sélection de valeur
  • Application d'un algorithme pour sélectionner laquelle de plusieurs instances d'une certaine valeur est réellement renvoyée, pour les cas où le document comporte deux pages ou plus, et certains champs apparaissent sur plus d'une page.

Niveaux de confiance

Qu’est-ce qu’un niveau de confiance ?

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.

À quoi servent les niveaux de confiance ?

Les automatisations métier ont besoin de moyens pour détecter et gérer les exceptions, c’est-à-dire les instances où une automatisation échoue. Dans les automatisations traditionnelles, cela est assez évident : en effet, lorsqu’un workflow RPA s’interrompt, il s’arrête, se bloque ou génère une erreur. Cette erreur peut être détectée et traitée en conséquence. Or, les modèles d’apprentissage automatique ne génèrent pas d’erreurs lorsqu’ils font des prédictions erronées. Dès lors, comment déterminer le moment où un modèle ML a fait une erreur et où le flux de gestion des exceptions doit être déclenché ? Cela implique souvent une intervention manuelle humaine, potentiellement via 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.

Dans certains cas, cependant, aucune de ces options n’existe alors que vous souhaitez malgré tout détecter des prédictions potentiellement erronées. Dans ces cas, vous pouvez utiliser les niveaux de confiance comme solution de substitution. Lorsque le niveau de confiance d’une prédiction est faible, par exemple s’il est inférieur à 0,6, le risque que la prédiction soit incorrecte est plus élevé que si la confiance est de 0,95. Cette corrélation est cependant relativement faible. Il existe de nombreux cas où une valeur est extraite avec un niveau de confiance faible mais se révèle en fait correcte. Il est également possible, bien que relativement rare, qu’une valeur soit extraite avec un niveau de confiance élevé (supérieur à 0,9), mais qu’elle soit incorrecte. Pour toutes ces raisons, nous encourageons fortement les utilisateurs à se fier autant que possible aux règles métier et à n’utiliser les niveaux de confiance qu’en dernier recours.

Quels sont les types de niveaux de confiance existants ?

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

Mise à l’échelle (ou calibrage) du score de confiance

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 Helix Extractor Generative AI-based model architecture, the confidence level distribution will change, and confidence thresholds will need to be re-assessed.

Créer un modèle de ML hautement performant

Pour obtenir le meilleur résultat en termes de taux d'automatisation (pourcentage de réduction du travail manuel mesuré en mois-personnes par an requis pour traiter votre flux de documents), vous devez suivre attentivement ces étapes :

1. Choisir le meilleur moteur OCR pour vos documents

   Cela influence à la fois l'OCR et la création de mots et de lignes (qui dépend en partie de l'OCR), et bien sûr tout ce qui se trouve en aval.

2. Sélectionner un ensemble de données bien équilibré et représentatif pour l'entraînement

3. Définir les champs à extraire

4. Labelliser l'ensemble de données d'entraînement

5. Entraîner l'extracteur

6. Définir et mettre en œuvre les règles métier pour le traitement de la sortie du modèle

7. (Facultatif) Choisir le(s) seuil(s) de confiance pour l'extraction

8. Entraînement à l'aide des données de la Station de validation

9. Déployer votre automatisation

1. Choisir un moteur OCR

Your default option should be UiPath Document OCR for European Latin-based languages, or UiPath Chinese-Japanese-Korean OCR. In case you need to process other languages, including Cyrillic, Devanagiri script, Thai, Vietnamese, Arabic, Hebrew or Persian, you may prefer Microsoft Azure Read OCR (Cloud only), Google Cloud Vision OCR (Cloud only) or Omnipage OCR (Activity pack in Studio). It is worth creating a few different Document Manager sessions with different OCR engines to check which performs best on your documents. Changing OCR engine later in the project can be costly.

Please be aware that the Digitize Document activity has the ApplyOcrOnPDF setting set to Auto by default, which means when operating on .pdf documents by default, Digitize tries to scrape as much text as possible from the .pdf itself, and only OCR images like logos, and combine the results.

However, .pdf documents are sometimes corrupt or unusually formatted leading to errors in the extracted text. In this case, set ApplyOCRonPDFs to Yes.

Another benefit of applying OCR on all .pdf documents using UiPath Document OCR is that UiPath Document OCR recognizes checkboxes which are critical elements of documents like forms. Be aware however that applying OCR on everything will slow down the Digitization a bit.

2. Définir des champ (Define Fields)

La définition des champs doit faire l'objet d'une conversation devant avoir lieu avec l'expert en la matière ou l'expert du domaine chargé du processus métier lui-même. Pour les factures, il s'agirait du chargé du processus des comptes fournisseurs. Cette conversation est essentielle, elle doit avoir lieu avant que les documents ne soient labellisés pour éviter toute perte de temps, et elle nécessite de regarder ensemble au moins 20 échantillons de documents choisis au hasard. Un créneau d'une heure doit être réservé pour cela, et il doit souvent être répété après quelques jours, car la personne qui prépare les données se heurtera à des situations ambiguës ou à des cas limites.

Il n'est pas rare que la conversation commence par l'hypothèse que vous devez extraire, disons, 10 champs, et plus tard vous vous retrouviez avec 15.

Certaines configurations clés que vous devez connaître :

• Content type This is the most important setting as it determines the postprocessing of the values, especially for dates (detects if the format is US-style or non-US style, and then formats them as yyyy-mm-dd) and for numbers (detects the decimal separator – comma or period). ID numbers clean up anything coming before a colon or hash symbol. String content type performs no cleanup and can be used when you want to do your own parsing in the RPA workflow.
• Multi-line checkbox This is for parsing strings like addresses that may appear on more than 1 line of text.
• Multi-valued checkbox This is for handling multiple choice fields or other fields which may have more than one value, but are NOT represented as a table column. For example, an Ethnic group question on a government form may contain multiple checkboxes where you can select all that apply.
• Hidden fields Fields marked as Hidden can be labelled but they are held out when data is exported, so the model cannot be trained on them. This is handy when labeling a field is a work in progress, when it is too rare, or when it is low priority.
• Scoring This is relevant only for Evaluation pipelines, and it affects how the accuracy score is calculated. A field that uses Levenshtein scoring is more permissive: if a single character out of 10 is wrong, the score is 0.9. However, if scoring is Exact Match it is more strict: a single wrong character leads to a score of zero. Only String type fields have the option to select Levenshtein scoring by default.

Montants des factures de services publics

Un montant total peut sembler assez simple, mais les factures de services publics contiennent de nombreux montants. Parfois, vous avez besoin du montant total à payer. D’autres fois, vous n’avez besoin que du montant actuel de la facture, sans les montants reportés des périodes de facturation précédentes. Dans ce dernier cas, vous devez procéder à la labellisation différemment même si la facture actuelle et le montant total peuvent être les mêmes. Les concepts sont différents et les montants sont souvent différents.

Remarque :

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

Moreover, the current bill amount can sometimes be composed of a few different amounts, fees, and taxes and may not appear individualized anywhere on the bill. A possible solution to this is to create two fields: a previous-charges field, and a total field. These two always appear as distinct explicit values on the utility bill. Then the current bill amount can be obtained as the difference between the two. You might even want to include all 3 fields (previous-charges, total, and current-charges) in order to be able to do some consistency checks in cases where the current bill amount appears explicitly on the document. So you could go from one to three fields in some cases.

Numéros de bons de commande sur les factures

Les numéros de bon de commande peuvent apparaître sous forme de valeurs uniques pour une facture, ou ils peuvent apparaître dans le tableau des éléments de ligne sur une facture, où chaque élément de ligne a un numéro de bon de commande différent. Dans ce cas, il peut être judicieux d'avoir deux champs différents : po-no et item-po-no. En assurant la cohérence de chaque champ au niveau graphique et au niveau de sa conception, le modèle assurera un bien meilleur travail. Cependant, vous devez vous assurer que les deux sont bien représentés dans vos ensembles de données d'entraînement et d'évaluation.

Nom du fournisseur et intitulé de l'adresse de paiement sur les factures

The company name usually appears at the top of an invoice or a utility bill, but sometimes it might not be readable because there is just a logo, and the company name is not explicitly written out. There could also be some stamp, or handwriting, or wrinkle over the text. In these cases, people might label the name that appears at the bottom right, in the Remit payment to section of the payslip on utility bills. That name is often the same, but not always, since it is a different concept. Payments can be made to some other parent or holding company, or other affiliate entity, and it is visually different on the document. This might lead to poor model performance. In this case, you should create two fields, vendor-name and payment-addr-name. Then you can look both up in a vendor database and use the one that matches, or use payment-addr-name when the vendor-name is missing.

Rangées de tableaux

Il y a deux concepts distincts à garder à l'esprit : les lignes de tableau et les lignes de texte. Une ligne de tableau comprend toutes les valeurs de tous les champs de colonnes qui appartiennent ensemble dans cette ligne. Parfois, ils peuvent tous faire partie de la même ligne de texte qui traverse la page. D'autres fois, ils peuvent être sur des lignes différentes.

Si une ligne de tableau se compose de plus d'une ligne de texte, vous devez regrouper toutes les valeurs de cette ligne de tableau à l'aide du raccourci clavier "/". Lorsque vous faites cela, une boîte verte apparaîtra et couvrira toute la ligne du tableau. Voici un exemple de tableau où les deux premières lignes sont constituées de plusieurs lignes de texte et doivent être regroupées à l'aide du raccourci clavier "/", tandis que la troisième ligne est une seule ligne de texte et n'a pas besoin d'être regroupée.

Voici un exemple de tableau où chaque ligne du tableau est constituée d'une seule ligne de texte. Vous n'avez pas besoin de les regrouper à l'aide du raccourci clavier "/" car cela est fait implicitement par Document Manager.

Identifier où se termine et où commence une ligne, de haut en bas, peut souvent être un défi majeur pour les modèles d'extraction ML, en particulier sur des documents tels que des formulaires où aucune ligne horizontale visuelle ne sépare les lignes. À l'intérieur de nos paquets ML, il existe un modèle spécial qui est entraîné pour diviser correctement les tables en lignes. Ce modèle est entraîné à l'aide de ces groupes que vous labellisez à l'aide des touches "/" ou "Entrée" et qui sont indiqués par les cases transparentes vertes.

3. Créer un ensemble de données d'entraînement (Create a Training Dataset)

Machine Learning technology has the main benefit of being able to handle complex problems with high diversity. When estimating the size of a training dataset, one looks first at the number of fields and their types, and the number of languages. A single model can handle multiple languages as long as they are not Chinese/Japanese/Korean. The later scenarios generally require separate Training datasets and separate models.

Il existe 3 types de champs :

1. Regular fields (date, total amount) For Regular fields, you need at least 20-50 document samples per field. So, if you need to extract 10 regular fields, you need at least 200-500 samples. If you need to extract 20 regular fields, you need at least 400-1000 samples. The amount of samples you need increases with the number of fields. More fields means you need more samples, about 20-50X more.

2. Column fields (item unit price, item quantity)

   Pour les champs de colonne, vous avez besoin d'au moins 50 à 200 échantillons par champ de colonne. Par conséquent, pour les champs à 5 colonnes, avec des mises en page claires et simples, vous pouvez obtenir de bons résultats avec 300 échantillons de documents, mais pour des mises en page très complexes et diverses, cela peut nécessiter plus de 1000. Pour couvrir plusieurs langues, vous avez besoin d'au moins 200 à 300 échantillons par langue, en supposant qu'ils couvrent tous les domaines. Ainsi, pour 10 champs d'en-tête et 4 champs de colonne avec 2 langues, 600 échantillons peuvent suffire (400 pour les colonnes et les en-têtes plus 200 pour la langue supplémentaire), mais certains cas peuvent en nécessiter 1200 ou plus.

3. Classification fields (currency) Classification fields generally require at least 10-20 samples from each class.

La plage recommandée pour la taille de l'ensemble de données est basée sur les informations fournies dans l'onglet Calculatrice (Calculator). Pour des scénarios plus simples avec peu de champs réguliers et des mises en page de documents claires, de bons résultats peuvent être obtenus avec des ensembles de données dans la plage orange inférieure. Pour les scénarios complexes, impliquant en particulier des tables complexes comportant de nombreuses colonnes, de bons résultats peuvent nécessiter des ensembles de données dans une plage orange supérieure ou plage verte régulière.

Important :

ML technology is designed to handle high diversity scenarios. Using it to train models on low diversity scenarios (1-10 layouts) requires special care to avoid brittle models that are sensitive to slight changes in the OCR text. Avoid this by having some deliberate variability in the training documents, by printing and then scanning or photographing them using mobile phone scanner apps. The slight distortions or changing resolutions make the model more robust.

De plus, ces estimations supposent que la plupart des pages contiennent la totalité ou la plupart des champs. Dans les cas où vous avez des documents avec plusieurs pages mais où la plupart des champs sont sur une seule page, le nombre de pages pertinent est le nombre d'exemples de cette page où la plupart des champs apparaissent.

The numbers above are general guidelines, not strict requirements. In general, you can start with a smaller dataset, and then keep adding data until you get good accuracy. This is especially useful to parallelize the RPA work with the model building. Also, a first version of the model can be used to prelabel additional data (see Settings view and Predict button in Document Manager) which can accelerate labeling additional Training data.

Les modèles de Deep Learning peuvent généraliser

Vous n'avez pas besoin que chaque mise en page soit représentée dans un ensemble d'apprentissage. En fait, il est possible que la plupart des mises en page de notre flux de documents de production n'aient aucun échantillon dans votre ensemble d'apprentissage, ou peut-être 1 ou 2 échantillons. C'est souhaitable, car vous souhaitez tirer parti de la puissance de l'IA pour comprendre les documents et être en mesure de réaliser des prédictions correctes pour des documents sur lesquels elle n'a pas été entraînée pendant la formation. Il n'est pas obligatoire de devoir disposer d'un grand nombre d'échantillons par mise en page, car la plupart des mises en page peuvent soit ne pas être présentes du tout, soit n'être présentes qu'une ou deux fois, et le modèle serait toujours capable de réaliser des prédictions correctes en se basant sur l'apprentissage d'autres mises en page.

Entraînement depuis un modèle prêt à l'emploi

Une situation courante consiste à extraire des données des factures, pour laquelle nous avons un modèle prêt à l'emploi pré-entraîné, mais qui comprend 2 champs réguliers supplémentaires et 1 champ de colonne supplémentaire que le modèle de factures pré-entraîné ne reconnaît pas. Dans ce cas, vous aurez généralement besoin d'un ensemble de données beaucoup plus petit que si vous aviez entraîné tous les champs à partir de zéro. L'estimation de la taille de l'ensemble de données est fournie lorsque vous créez un type de document dans Document Understanding Cloud, et elle est ensuite accessible dans la vue Dataset Diagnostics. Cependant, gardez à l'esprit que tous les documents que vous utilisez pour entraîner un modèle doivent être entièrement labellisés, y compris les nouveaux champs, que le modèle prêt à l'emploi ne reconnaît pas, ainsi que l'original des champs, que le modèle de sortie le modèle prêt à l'emploi ne reconnaît pas.

Occurrences de champ inégales

Certains champs peuvent apparaître sur chaque document (par exemple, date, numéro de facture) tandis que certains champs peuvent apparaître uniquement sur 10 % des documents (par exemple, frais de traitement, remises). Dans ces cas, vous devez prendre une décision commerciale. Si ces champs rares ne sont pas essentiels à votre automatisation, vous pouvez vous en tirer avec un petit nombre d'échantillons (10-15) de ce champ particulier, c'est-à-dire des pages qui contiennent une valeur pour ce champ. Cependant, si ces champs sont critiques, vous devez vous assurer d'inclure dans votre ensemble d'entraînement au moins 30 à 50 échantillons de ce champ pour vous assurer de couvrir toute la diversité.

Ensembles de données équilibrés

Dans le cas des factures, si un ensemble de données contient des factures de 100 fournisseurs mais que la moitié de l'ensemble de données se compose uniquement de factures d'un seul fournisseur, alors il s'agit d'un ensemble de données très déséquilibré. Un ensemble de données parfaitement équilibré est celui où chaque fournisseur apparaît un nombre égal de fois. Les ensembles de données n'ont pas besoin d'être parfaitement équilibrés, mais vous devez éviter que plus de 20 % de l'ensemble de vos données proviennent d'un seul fournisseur. À un moment donné, un nombre plus important de données n'est pas avantageux, et cela peut même dégrader la précision sur d'autres fournisseurs, car le modèle s'ajuste à l'excès pour un seul fournisseur.

Ensembles de données représentatifs

Les données doivent être choisies pour couvrir la diversité des documents susceptibles d'être consultés dans le workflow de production. Par exemple, si vous recevez des factures en anglais mais que certaines d'entre elles proviennent des États-Unis, de l'Inde et de l'Australie, elles auront probablement un aspect différent, et vous devez donc vous assurer d'avoir des échantillons des trois. Ceci est pertinent non seulement pour l'entraînement du modèle lui-même, mais également à des fins de labellisation, car lorsque vous labellisez les documents, vous découvrirez peut-être que vous devez extraire de nouveaux champs différents de certaines de ces régions, comme le code GSTIN pour l'Inde ou le code ABN pour l'Australie.

Répartition Entraînement/Validation

Tout ensemble de données d'entraînement est automatiquement divisé en coulisses en un ensemble d'entraînement (sélectionné au hasard à 80 %) et un ensemble de validation (sélectionné au hasard à 20 %). Lors de l'entraînement de modèles d'apprentissage profond, l'ensemble d'entraînement est utilisé pour la rétropropagation, la partie qui modifie réellement les pondérations des nœuds dans le réseau, tandis que l'ensemble de validation n'est utilisé que pour savoir quand arrêter l'entraînement. En d'autres termes, il est utilisé pour éviter le surentraînement sur l'ensemble d'entraînement.

C’est ainsi que nous pouvons obtenir des scores d’évaluation complets à la fin de n’importe quelle exécution d’entraînement : nous renvoyons les scores sur l’ensemble de validation (Validation set). Cet ensemble n'est techniquement pas utilisé pour entraîner le réseau, mais uniquement pour éviter le surajustement. Cependant, comme il est sélectionné au hasard à 20 % de l'ensemble de données, il a tendance à être distribué de la même manière dans l'ensemble d'entraînement. Cette cohérence est une bonne chose, car cela signifie que les scores que vous obtenez reflètent la capacité du modèle à apprendre à partir des données, ce qui nous intéresse généralement. Si un modèle n'est pas capable d'apprendre, cela signifie que les données sont incohérentes ou que le modèle a une limitation. Ce sont des choses critiques que nous devons savoir immédiatement lors de l'entraînement d'un modèle.

L’inconvénient de cette approche est que les scores ne peuvent pas nécessairement être comparés exactement de pommes à pommes à mesure que l’ensemble de données augmente, et également que les scores ne reflètent pas la capacité du modèle à généraliser – seulement sa capacité à apprendre. Cependant, les comparaisons et la mesure de la capacité à généraliser sont des problèmes techniques liés à la science des données qui n'ont qu'un impact indirect sur les performances de l'entreprise ou le retour sur investissement pour la plupart des automatisations.

4. Labelliser le jeu de données d’entraînement

When labeling Training data, you need to focus on the bounding boxes of the words in the document pane of Document Manager. The parsed values in the right or top sidebars are not important as they are not used for training.

Chaque fois qu'un champ apparaît plusieurs fois sur une page, chacun d'eux doit être labellisé à condition de représenter le même concept.

Lorsque l'OCR manque un mot ou se trompe sur quelques caractères, labellisez simplement le cadre de délimitation s'il y en a un, et sinon, ignorez-le et continuez. Il n'y a aucune possibilité d'ajouter un mot dans le Document Manager, car même si vous le faisiez, le mot serait toujours manquant au moment de l'exécution ; l'ajouter n'aiderait donc pas du tout le modèle.

As you label, remain vigilant about fields that may have multiple or overlapping meanings/concepts, in case you might need to split a field into two separate fields, or fields that you do not explicitly need, but which, if labelled, might help you to do certain validation or self-consistency check logic in the RPA workflow. Typical examples are quantity,unit-price, and line-amount on invoice line items. Line-amount is the product of quantity and unit-price, but this is very useful to check for consistency without the need for confidence levels.

5. Entraîner l’extracteur

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

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

Dans ce fichier Excel, vous pouvez examiner quelles prédictions échouent et sur quels fichiers, et vous pouvez observer immédiatement s'il s'agit d'une erreur d'OCR, d'une erreur d'extraction ou d'analyse d'apprentissage automatique, et si elle peut être corrigée à l'aide d'une logique simple dans le workflow RPA ou si elle nécessite un moteur OCR différent, plus de données d'entraînement ou une amélioration de l'étiquetage ou des configurations de champs dans Document Manager.

Ce fichier Excel est également très utile pour identifier les règles métier les plus pertinentes que vous devez appliquer au workflow RPA afin de détecter les erreurs courantes lors du routage vers la station de validation dans Actions Center pour une révision manuelle. Les règles métier sont de loin le moyen le plus fiable pour détecter les erreurs.

Pour les erreurs qui ne peuvent pas être détectées par les règles métier, vous pouvez également utiliser des niveaux de confiance. Le fichier Excel contient également des niveaux de confiance pour chaque prédiction afin que vous puissiez utiliser des fonctionnalités Excel telles que le tri et le filtrage pour déterminer quel est un bon seuil de confiance pour votre scénario métier.

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

Important :

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

6. Définir et mettre en œuvre des règles métier

Dans cette étape, vous devez vous préoccuper des erreurs de modèle et de la façon de les détecter. Il existe 2 méthodes principales pour détecter les erreurs :

• en appliquant les règles de l'entreprise
• through applying lookups in Systems of Record in the customer organization
• en imposant un seuil de niveau de confiance minimum

Le moyen le plus efficace et le plus fiable de détecter les erreurs consiste à définir des règles métier et des recherches. Les niveaux de confiance ne peuvent jamais être parfaits à 100 %, il y aura toujours un pourcentage faible mais non nul de prédictions correctes avec une faible confiance ou de mauvaises prédictions avec une confiance élevée. De plus, et c'est peut-être le plus important, un champ manquant n'a pas de confiance, donc un seuil de confiance ne peut jamais détecter les erreurs où un champ n'est pas extrait du tout. Par conséquent, les seuils de niveau de confiance ne doivent être utilisés que comme une solution de repli, un filet de sécurité, mais jamais comme le principal moyen de détecter les erreurs critiques pour l'entreprise.

Exemples de règles métier :

• Le montant net plus le montant des taxes doit être égal au montant total
• Le montant total doit être supérieur ou égal au montant net
• Invoice number, Date, Total amount (and other fields) must be present
• Le numéro de bon de commande (si présent) doit exister dans la base de données de bons de commande
• La date de la facture doit être située dans le passé et ne peut pas dater de plus de X mois
• La date d'échéance doit être située dans le futur et ne doit pas compter plus de Y jours/mois
• For each line item, the quantity multiplied by unit price must equal the line amount
• La somme des montants des lignes doit être égale au montant net ou au montant total
• Etc.
  Remarque :

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

En particulier, les niveaux de confiance des champs de colonne ne devraient presque jamais être utilisés comme mécanisme de détection d'erreurs, car les champs de colonne (par exemple, les éléments de ligne sur les factures ou les bons de commande) peuvent avoir des dizaines de valeurs, il est donc possible de définir un seuil minimum sur autant de valeurs. particulièrement peu fiable, car une valeur est plus que susceptible d'avoir une faible confiance, ce qui conduirait à ce que la plupart/tous les documents soient acheminés vers la validation humaine, plusieurs fois inutilement.

Les règles métier doivent être appliquées dans le cadre du workflow RPA, et il serait idéal que l'échec de la règle métier soit transmis au validateur humain afin de diriger son attention et d'accélérer le processus.

Remarque :

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

7. (Facultatif) Choisir un seuil de confiance

Une fois les règles métier définies, il peut parfois rester un petit nombre de champs pour lesquels aucune règle métier n'est en place ou pour lesquels il est peu probable que les règles métier détectent toutes les erreurs. Pour cela, vous devrez peut-être utiliser un seuil de confiance en dernier recours.

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

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

8. Peaufinage à l'aide des données de la station de validation

Validation Station data can help improve the model predictions, yet, in many cases, it turns out that most errors are NOT due to the model itself but to the OCR, labelling errors or inconsistencies, or to postprocessing issues (e.g., date or number formatting). So, the first key aspect is that Validation Station data should be used only after the other Data extraction components have been verified and optimized to ensure good accuracy, and the only remaining area of improvement is the model prediction itself.

Le deuxième aspect clé est que les données de la station de validation ont une densité d'informations inférieure à celle des données labellisées dans le Document Manager. Fondamentalement, l'utilisateur de Validation Station ne se soucie d'obtenir la bonne valeur qu'une seule fois. Si une facture comporte 5 pages et que le numéro de facture apparaît sur chaque page, l'utilisateur de la Station de Validation ne la valide que sur la première page. Ainsi, 80 % des valeurs restent sans libellé. Dans Document Manager, toutes les valeurs sont labellisées.

Enfin, gardez à l'esprit que les données de la station de validation doivent être ajoutées à l'ensemble de données d'origine libellé manuellement, afin que vous disposiez toujours d'un seul ensemble de données d'entraînement dont la taille augmente avec le temps. Vous devez toujours vous entraîner sur le paquet ML avec la version mineure 0 (zéro), qui est la version publiée par UiPath Out-of-the-box.

Important :

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

Précautions à prendre lors de l'utilisation des données de la station de validation

Le volume des données de Station de validation peut potentiellement être beaucoup plus élevé, car ces données sont utilisées dans le workflow de production. L'ensemble de données ne doit pas être submergé par les données de Station de validation, car cela pourrait dégrader la qualité du modèle en raison du problème de densité d'informations mentionné précédemment.

Nous vous recommandons d'ajouter au maximum 2 à 3 fois le nombre de pages de données Document Manager et, au-delà, de sélectionner uniquement les fournisseurs ou les échantillons dans lesquels vous observez des défaillances majeures. Si des modifications majeures connues sont apportées aux données de production, telles qu'une nouvelle langue ou une nouvelle région géographique intégrée au processus métier (expansion des États-Unis vers l'Europe ou l'Asie du Sud), les données représentatives de ces langues et régions doivent être ajoutées dans Document Manager pour un étiquetage manuel. Les données de Station de validation ne sont pas appropriées pour une telle extension d'étendue.

Un autre problème potentiel avec les données de la station de validation est l'équilibre. En Production , il est courant que la majorité du trafic provienne d’un petit sous-ensemble de fournisseurs/clients/régions du monde. Si vous êtes autorisé à entrer dans l'ensemble d'apprentissage tel quel, cela peut conduire à un modèle très biaisé qui fonctionne bien sur un petit sous-ensemble de données, mais mal sur la plupart du reste des données. Par conséquent, il est important de faire particulièrement attention lors de l'ajout de données de station de validation dans un ensemble d'apprentissage.

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

9. Déployer votre automatisation

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