Entraînement de modèles hautement performants

La puissance des modèles d'apprentissage automatique réside dans le fait qu'ils sont définis par des données d'entraînement plutôt que par une logique explicite exprimée en code informatique. Cela signifie qu'une attention particulière est nécessaire lors de la préparation des ensembles de données, car un modèle n'est aussi bon que l'ensemble de données qui a été utilisé pour l'entraîner. En ce sens, ce qu’est UiPath® Studio aux workflows RPA , une session Type de document (Document UnderstandingDocument Understanding^TM Cloud) l’est aux capacités d’ apprentissage automatique. Les deux nécessitent une certaine expérience pour être utilisés efficacement.

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.

En cas de doute, commencez par entraîner un seul modèle, mais conservez les documents dans différents lots de Document Manager (voir la liste déroulante Filtrer (Filter) en haut de la vue) afin de pouvoir les séparer facilement ultérieurement si nécessaire. De cette façon, le travail de labellisation n'est pas perdu. En ce qui concerne les modèles ML, plus il y a de données, mieux c'est. Ainsi, avoir un modèle unique avec de nombreuses données est un bon point de départ.

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 ?

Lorsque les modèles ML font des prédictions, il s’agit de suppositions statistiques. Le modèle indique qu’ « il s’agit probablement du montant total » de la facture. On peut alors se demander : à quel degré de probabilité ? Les niveaux de confiance constituent une tentative de réponse à cette question, sur une échelle allant de 0 à 1. Cependant, il ne saurait s’agit d’une estimation exacte des probabilités. Ces niveaux reflètent en réalité la confiance du modèle en ses propres hypothèses, et dépendent donc des éléments ayant servi à entraîner le modèle. On peut se les représenter comme une mesure de la familiarisation du modèle : dans quelle mesure le modèle s’est-il familiarisé avec cette entrée de modèle ? Si le modèle identifie des éléments similaires à ceux qui lui ont été soumis dans le cadre de l’entraînement, le niveau de confiance sera plus élevé. Dans le cas contraire, le niveau de confiance sera plus faible.

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

La meilleure façon de détecter les prédictions erronées consiste, de loin, à appliquer des règles métier. On sait par exemple que, sur une facture, le montant net ajouté au montant des taxes doit être égal au montant total. Ou encore, que les numéros de référence des composants commandés doivent comporter 9 chiffres. Lorsque ces conditions ne sont pas remplies, on sait qu’une erreur s’est produite et que l’on peut déclencher le flux de gestion des exceptions. Cela constitue l’approche la plus privilégiée, ainsi que la plus recommandée. Il est capital de consacrer des efforts considérables à la création de ce type de règles, jusqu’à utiliser des expressions régulières complexes, voire des recherches dans les bases de données afin de valider les noms de fournisseurs, les numéros de référence, etc. Dans certains cas, il peut être utile d’extraire un document différent du document concerné, mais uniquement afin de comparer et valider certaines valeurs par rapport au document original qui vous intéresse.

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 ?

La plupart des composants du produit Document Understanding^TM renvoient un niveau de confiance. Les principaux composants d’un workflow Document Understanding^TM sont la numérisation, la classification et l’extraction. Chacun d’entre eux se caractérise par un certain niveau de confiance pour chaque prédiction. Les niveaux de confiance pour la Numérisation et l’extraction sont tous deux affichés dans la Station de validation : pour gagner du temps, vous pouvez ainsi filtrer les prédictions et vous concentrer uniquement sur celles présentant un faible niveau de confiance.

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

Les niveaux de confiance des différents modèles seront mis à l’échelle différemment en fonction de la configuration du modèle. Par exemple, certains modèles renvoient presque toujours des niveaux de confiance situés dans la plage allant de 0,9 à 1, et très rarement inférieurs à 0,8. D’autres modèles génèrent des niveaux de confiance répartis de façon beaucoup plus homogène entre 0 et 1, bien qu’ils soient généralement regroupés dans le niveau supérieur de cette échelle. Par conséquent, les seuils de confiance seront différents en fonction du modèle. Par exemple, le seuil de confiance de l’OCR ne sera pas le même que celui de l’extracteur ML ou du classifieur ML. Par ailleurs, à chaque fois qu’une mise à jour majeure de l’architecture sera réalisée sur un modèle, par exemple une mise à jour proposée avec la publication de l’architecture de modèle basée sur l’IA générative DocPath, la distribution du niveau de confiance changera et les seuils de confiance devront être réévalués.

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. Définir les champs à extraire
3. Sélectionner un ensemble de données bien équilibré et représentatif pour l'entraînement
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

Votre option par défaut doit être UiPath Document OCR pour les langues latines-europeennes, ou UiPath Chinese-Japanese-Korean OCR. Si vous devez traiter d'autres langues, y compris le cyrillique, l'écriture devanagiri, le thaï, le vietnamien, l'arabe, l'hébreux ou le persan, vous préférez peut-être Microsoft Azure Read OCR (Cloud uniquement), Google Cloud Vision OCR (Cloud uniquement) ou Omnipage OCR (Activity dans Studio). Cela vaut la peine de créer différentes sessions Document Manager avec différents moteurs OCR pour vérifier laquelle fonctionne le mieux sur vos documents. Changer de moteur OCR ultérieurement dans le projet peut s'avérer coûteux.

Veuillez noter que l'activité Numériser le document ( Digitize Document) a le paramètre AppliquerOcrAuxPDF défini sur Auto par défaut, ce qui signifie que lorsque vous utilisez des fichiers .pdf par défaut, Numériser (Digitize) essaie d'extraire le plus de texte possible du fichier .pdf lui-même et uniquement les images OCR telles que les logos, puis combinez les résultats.

Cependant, les fichiers .pdf les documents sont parfois corrompus ou formatés de manière inhabituelle, ce qui entraîne des erreurs dans le texte extrait. Dans ce cas, définissez AppliquerOCRonPDFs sur Oui(Yes).

Un autre avantage de l’application de l’OCR sur tous les fichiers .pdf documents utilisant UiPath Document OCR est qu'UiPath Document OCR reconnaît les cases à cocher qui sont des éléments essentiels de documents tels que les formulaires. Sachez cependant que l’application de l’OCR sur tout ralentira un peu la numérisation.

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. Quelques exemples sont décrits dans les sous-sections ci-dessous.

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

• Type de contenu

  Il s'agit du paramètre le plus important car il détermine le post-traitement des valeurs, en particulier pour les dates (détecte si le format est de style américain ou non américain, puis les formate en jj/mm/aaaa) et pour les nombres (détecte le séparateur décimal – virgule ou point). Les numéros d'identification effacent tout ce qui précède un signe deux-points ou un symbole dièse. Le type de contenu Chaîne n'effectue aucun nettoyage et peut être utilisé lorsque vous souhaitez effectuer votre propre analyse dans le flux de travail RPA.

• Case à cocher multiligne

  C'est pour analyser les chaînes comme les adresses qui peuvent apparaître sur plus d'une ligne de texte.

• Case à cocher à valeurs multiples

  Cela permet de gérer les champs à choix multiples ou d'autres champs qui peuvent avoir plus d'une valeur, mais qui ne sont PAS représentés sous la forme d'une colonne de table. Par exemple, une question sur un groupe ethnique sur un formulaire du gouvernement peut contenir plusieurs cases à cocher. Vous pouvez sélectionner toutes les cases qui s'appliquent.

• Champs cachés

  Les champs marqués comme masqués (Hidden) peuvent être labellisés, mais ils ne sont pas pris en compte lors de l'exportation des données, de sorte que le modèle ne sera pas entraîné sur eux. C'est pratique lorsque la labellisation d'un champ est en cours, lorsqu'il est trop rare ou lorsqu'il est de faible priorité.

• Évaluation

  Ceci n'est pertinent que pour les pipelines d'évaluation et affecte la façon dont le score de précision est calculé. Un champ qui utilise la notation de Levenshtein est plus permissif : si un seul caractère sur 10 est faux, le score est de 0,9. Cependant, si le score est une correspondance exacte ( Exact Match) , il est plus strict : un seul caractère erroné conduit à un score de zéro. Seuls les champs de type String ont la possibilité de sélectionner la notation de Levenshtein par défaut.

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 : chaque champ représente un concept différent, et ils doivent être définis aussi précisément que possible pour éviter toute confusion. Si un humain peut être confus, le modèle ML sera également confus.

De plus, le montant actuel de la facture peut parfois être composé de quelques montants, frais et taxes différents et peut ne pas apparaître de manière individuelle sur la facture. Une solution possible consiste à créer deux champs : un champ Charges antérieures et un champ Total . Ces deux éléments apparaissent toujours comme des valeurs explicites distinctes sur la facture de services publics. Ensuite, le montant actuel de la facture peut être obtenu comme la différence entre les deux. Vous pouvez même vouloir inclure les 3 champs (previous-charges, totalet current-charges) afin de pouvoir effectuer des contrôles de cohérence dans les cas où le montant de la facture actuelle apparaît explicitement sur le document. Vous pouvez donc passer d’un à trois champs dans certains cas.

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

Le nom de l'entreprise apparaît généralement en haut d'une facture ou d'une facture de services publics, mais il peut parfois ne pas être lisible car il n'y a qu'un logo et le nom de l'entreprise n'est pas explicitement écrit. Il peut également y avoir un tampon, une écriture manuscrite ou un pli sur le texte. Dans ces cas, les utilisateurs peuvent labelliser le nom qui apparaît en bas à droite, dans la section Verser le paiement à de la fiche de paie sur les factures de services publics. Ce nom est souvent le même, mais pas toujours, car il s'agit d'un concept différent. Les paiements peuvent être effectués à une autre société mère ou holding, ou à une autre entité affiliée, et cela est affiché différemment sur le document. Cela peut entraîner de mauvaises performances du modèle. Dans ce cas, vous devez créer deux champs, vendor-name et payment-addr-name. Ensuite, vous pouvez rechercher les deux dans une base de données de fournisseurs et utiliser celle qui correspond, ou utiliser payment-addr-name lorsque le nom du fournisseur est manquant.

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)

La technologie d'apprentissage automatique présente le principal avantage de pouvoir gérer des problèmes complexes avec une grande diversité. Lors de l'estimation de la taille d'un ensemble de données d'entraînement, on regarde d'abord le nombre de champs , leurs types et le nombre de langues. Un seul modèle peut gérer plusieurs langues tant qu'elles ne sont pas chinoises/japonaises/coréennes. Les scénarios les plus récents nécessitent généralement des ensembles de données d'entraînement et des modèles distincts.

Il existe 3 types de champs :

1. Champs réguliers (Regular fields) (date, montant total)

   Pour les champs réguliers, vous avez besoin d'au moins 20 à 50 échantillons par champ. Ainsi, si vous devez extraire 10 champs réguliers, vous avez besoin d'au moins 200 à 500 échantillons. Si vous devez extraire 20 champs réguliers, vous avez besoin d'au moins 400 à 1 000 échantillons. La quantité d'échantillons dont vous avez besoin augmente avec le nombre de champs. Plus de champs signifie que vous avez besoin de plus d'échantillons, environ 20 à 50 fois plus.

2. Champs de colonne (Column fields) (prix unitaire de l'article, quantité de l'article)

   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. Champs de classification (Classification fields) (devise)

   Les champs de classification nécessitent généralement au moins 10 à 20 échantillons de chaque classe.

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.

Attention : la technologie ML est conçue pour gérer des scénarios de grande diversité. Son utilisation pour entraîner des modèles sur des scénarios à faible diversité (1 à 10 mises en page) nécessite une attention particulière pour éviter les modèles fragiles qui sont sensibles aux légers changements dans le texte OCR. Une façon d'éviter cela est de s'assurer qu'il existe une certaine variabilité délibérée dans les documents d'entraînement en les imprimant, puis en les numérisant ou en les photographiant à l'aide d'applications de scanner de téléphone portable. Les légères distorsions ou les changements de résolution rendent le modèle plus robuste.

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.

Les chiffres ci-dessus sont des directives générales et non des exigences strictes. En général, vous pouvez commencer avec un ensemble de données plus petit, puis continuer à ajouter des données jusqu'à ce que vous obteniez une bonne précision. Ceci est particulièrement utile pour paralléliser le travail RPA avec la construction de modèles. En outre, une première version du modèle peut être utilisée pour pré-labelliser des données supplémentaires (voir la vue Paramètres (Settings) et le bouton Prédire (Predict) dans Document Manager), ce qui peut accélérer la labellisation des données d'entraînement supplémentaires.

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

Lors de la labellisation des données d'entraînement, vous devez vous concentrer sur les Cadres englobants (bounding boxes) des mots dans le volet du document de Document Manager. Les valeurs analysées dans les barres latérales droite ou supérieure ne sont pas importantes car elles ne sont pas utilisées pour l'entraînement.

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.

Pendant que vous labellisez, restez vigilant sur les champs qui peuvent avoir des significations/concepts multiples ou qui se superposent, au cas où vous auriez besoin de diviser un champ en deux champs distincts, ou des champs dont vous n'avez potentiellement pas besoin explicitement, mais qui, une fois labellisés, pourraient vous aider à effectuer une certaine validation ou une logique de contrôle d'auto-cohérence dans le workflow RPA. Des exemples typiques sont la quantité, le prix unitaire et le montant de la ligne des éléments de ligne de la facture. Le montant de la ligne est le produit de la quantité et du prix unitaire, mais cela est très utile pour vérifier la cohérence sans avoir besoin de niveaux de confiance.

5. Entraîner l’extracteur

Pour créer un extracteur, accédez à la vue Extracteurs (Extractors) dans Document Understanding et cliquez sur le bouton Créer un extracteur (Create Extractor) en haut à droite. Vous pouvez ensuite sélectionner le Type de document ( Document Type), le modèle ML et la version que vous souhaitez utiliser. Vous pouvez surveiller la progression dans l'onglet Extracteurs (Extractors) ou dans la vue Détails (Details) de l'Extracteur, qui contient un lien vers le pipeline AI Center, où vous pouvez voir les journaux détaillés en temps réel.

Lors de l'évaluation d'un modèle ML, l'outil le plus puissant est le fichier evaluation_<package name>.xlsx généré dans le dossier artefacts/eval_metrics dans la vue des détails du pipeline AI Center. Sur la première feuille, vous pouvez voir un rapport détaillé sur les scores de précision, y compris les scores globaux, ainsi que par champ et par lot.

Dans ce fichier Excel, vous pouvez voir quelles prédictions échouent et sur quels fichiers, et vous pouvez voir immédiatement s'il s'agit d'une erreur OCR ou d'une erreur d'extraction ou d'analyse ML, et s'il peut être corrigé par une simple logique dans le workflow RPA, ou elle nécessite un moteur OCR différent, davantage de données d'entraînement ou l'amélioration de la labellisation ou des configurations de champ 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.

Dans l'ensemble, le fichier evaluation_<package_name>.xlsx Le fichier Excel est une ressource clé sur laquelle vous devez vous concentrer pour obtenir les meilleurs résultats de votre automatisation de l’IA.

Important : l'entraînement sur GPU est fortement recommandé pour les ensembles de données volumineux et de production. L'entraînement sur CPU est beaucoup plus lent et doit être utilisé avec précaution, pour les petits ensembles de données à des fins de démonstration ou de test. Pour en savoir plus, consultez la page Pipelines d'entraînement.

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
• en appliquant des recherches dans les systèmes d’enregistrement de l’organisation cliente
• 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
• Le numéro de facture, la date, le montant total (et éventuellement d'autres champs) doivent être présents
• 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
• Pour chaque élément, la quantité multipliée par le prix unitaire doit être égale au montant de la ligne
• La somme des montants des lignes doit être égale au montant net ou au montant total
• Etc.

Remarque : dans le cas de nombres, un arrondi à huit décimales est effectué.

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 : lors de la définition des règles métier, gardez à l’esprit que les valeurs Commence par (Starts with), Se termine par (Ends with) et Contient (Contains) sont sensibles à la casse.

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.

L'outil principal pour définir ce seuil est la feuille de calcul Excel qui est générée par le pipeline d'entraînement dans le dossier Sorties ( Outputs) > artefacts > eval_metrics .

Ce fichier evaluation_<package name>.xlsx contient une colonne pour chaque champ et une colonne pour le niveau de confiance de chaque prédiction. En triant la table en fonction des colonnes de confiance, vous pouvez voir où les erreurs commencent à apparaître pour un champ donné et définir un seuil au-dessus de ce niveau pour garantir que seuls les documents correctement extraits sont envoyés directement.

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

Les données de la station de validation peuvent aider à améliorer les prédictions du modèle, pourtant, dans de nombreux cas, il s'avère que la plupart des erreurs ne sont pas dues au modèle lui-même mais à l'OCR, aux erreurs de labellisation ou aux incohérences, ou à des problèmes de post-traitement (par exemple, le formatage de la date ou du nombre). Ainsi, le premier aspect clé est que les données de la station de validation ne doivent être utilisées qu'après que les autres composants d'extraction de données ont été vérifiés et optimisés pour assurer une bonne précision, et le seul domaine d'amélioration restant est la prédiction du modèle elle-même.

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.

Attention : il est souvent supposé à tort que la façon d'utiliser les données de la station de validation consiste à entraîner de manière répétée la version précédente du modèle, de sorte que le lot actuel est utilisé pour former le package X.1 afin d'obtenir la version X.2. Ensuite, le batch suivant s'entraîne sur la version X.2 pour obtenir la version X.3 et ainsi de suite. C'est la mauvaise façon d'utiliser le produit. Chaque lot de la station de validation doit être importé dans la même session Document Manager que les données d'origine labellisées manuellement, créant ainsi un ensemble de données plus volumineux, qui doit être utilisé pour toujours s'entraîner sur la version X.0 du paquet ML.

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

Les données de la station de validation peuvent potentiellement être d'un volume beaucoup plus élevé car elles sont utilisées dans le workflow de Production . Vous ne voulez pas que l'ensemble de données soit submergé par les données de la station de validation, car cela peut dégrader la qualité du modèle en raison du problème de densité d'informations mentionné ci-dessus.

La recommandation est d'ajouter un maximum de 2 à 3 fois le nombre de pages de données de Document Manager et, au-delà, de ne sélectionner que les fournisseurs ou les échantillons pour lesquels vous constatez des défaillances majeures. S'il y a des changements majeurs connus dans les données de Production , comme 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), alors des données représentatives pour ces langues et régions doivent être ajoutées à Document Manager pour la labellisation manuelle. Les données de la station de validation ne sont pas appropriées pour une extension de portée aussi importante.

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.

Voici un exemple de scénario. Vous avez choisi un bon moteur OCR, labellisé 500 pages dans Document Manager (ce qui donne de bonnes performances) et déployé le modèle dans un workflow RPA de production. La station de validation commence à générer des données. Vous devez sélectionner au hasard jusqu'à un maximum de 1 000 à 1 500 pages à partir de la station de validation et les importer dans Document Manager avec les 500 premières pages et réentraîner votre modèle ML. Après cela, vous devez examiner très attentivement le fichier evaluation_<package name>.xlsx pour vous assurer que le modèle s'est réellement amélioré, puis déployer le nouveau modèle en production.

9. Déployer votre automatisation

Assurez-vous d'utiliser le modèle de processus Document Understanding de la section Modèles (Templates) de l'écran de démarrage de Studio afin d'appliquer les meilleures pratiques dans l'architecture RPA d'Enterprise.