Document Understanding
2021.10
false
Guide de l'utilisateur de Document Understanding
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 5 juin 2024

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, Data Manager 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 se tromper sur 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 Data Manager (voir la liste déroulante Filtrer (Filter) dans la partie supérieure du milieu de la vue Data Manager) 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

Data Manager peut être utilisé pour créer deux types d'ensembles de données : des ensembles de données d'apprentissage et des ensembles de données d'évaluation. Les deux sont essentiels pour créer un modèle de ML performant et vous devez prévoir du temps et des efforts pour créer et maintenir les deux. Vous ne pouvez pas obtenir un modèle ML performant sans un ensemble de données d'évaluation représentatif du trafic de documents de production.

Chaque type de jeu de données est labellisé d'une manière différente :

  • Les ensembles de données d'entraînement reposent uniquement sur les cadres de délimitation des mots de la page représentant les différentes informations que vous devez extraire.

    Lorsque vous labellisez un ensemble d'entraînement, concentrez-vous uniquement sur la page elle-même et les zones de mots.

  • Les ensembles de données d'évaluation reposent uniquement sur les valeurs des champs qui apparaissent dans la barre latérale (pour les champs normaux) ou dans la barre supérieure (pour les champs de colonne).

    Lors de la labellisation d'un ensemble d'évaluation, concentrez-vous sur les valeurs sous les noms de champ dans la barre latérale ou la barre supérieure. Cela ne signifie pas que vous devez les saisir manuellement ; en effet, cette méthode est sujette à des erreurs typographiques, il est donc toujours recommandé de les labelliser en cliquant sur les cases de la page, mais assurez-vous de vérifier que les valeurs sont correctes.

Vous trouverez ci-dessous plus de détails sur la manière de mener des évaluations appropriées.

Composants d'extraction de données

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

  • OCR (reconnaissance optique de caractères)
  • Création de mots et de lignes

    Regroupement des caractères en mots et des mots en lignes de texte de gauche à droite

  • Prédiction du modèle d'apprentissage automatique pour chaque mot/boîte de la page
  • Nettoyage, analyse et formatage des plages de texte

    Par exemple, regroupe des mots sur plusieurs lignes dans une adresse, formate une date au format standard jj/mm/aaaa

  • Application d'un algorithme pour sélectionner la valeur renvoyée

    Pour les cas où le document comporte 2 pages ou plus et où certains champs apparaissent sur plus d'une page

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 un moteur OCR

Remarque : Cela influence à la fois l’OCR et la création de mots et de lignes (qui dépend en partie de l’OCR), et évidemment tout ce qui se trouve en aval.

Pour choisir un moteur OCR, vous devez créer différentes sessions Data Manager, configurer différents moteurs OCR et essayer d'importer les mêmes fichiers dans chacun d'eux pour examiner les différences. Vous devez vous concentrer sur les zones que vous avez l'intention d'extraire. Par exemple, si vous devez extraire des noms d'entreprise qui apparaissent dans les logos des factures, vous souhaiterez peut-être voir quel moteur OCR est le plus performant pour le texte des logos.

Votre option par défaut est UiPath Document OCR car elle est incluse gratuitement avec les licences Document Understanding. Cependant, dans les cas où certaines langues non prises en charge sont requises, ou que certains documents très difficiles à lire sont impliqués, vous pouvez essayer Google Cloud (Cloud uniquement) ou Microsoft Read (Cloud ou On Premises), qui ont une meilleure couverture linguistique. Ces moteurs ont un coût, certes faible, mais si la précision est plus élevée sur certains champs de données critiques pour votre processus métier, il est fortement recommandé d'utiliser le meilleur OCR disponible - cela vaudra bien votre temps plus tard puisque tous les processus en aval en dépendent.

Veuillez noter que l'activité Numériser le document (Digitize Document) a le paramètre ForceApplyOCR défini sur False par défaut, ce qui signifie que lorsque vous utilisez des documents .pdf par défaut, le moteur OCR n'est pas du tout utilisé, le texte est extrait directement du document .pdf lui-même dans le cas des documents .pdf natifs. Cependant, de nombreux documents .pdf natifs peuvent contenir des logos ou même des en-têtes ou des pieds de page qui ne sont pas récupérés. Ceux-ci peuvent contenir les informations d'identification de l'entreprise, telles que son nom, son adresse, son code TVA ou ses informations de paiement, qui sont très pertinentes dans les processus commerciaux. Si votre processus présente cette situation, définissez ForceApplyOCR sur True pour vous assurer que tout le texte est détecté, bien que cela puisse ralentir votre processus.

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

La technologie d'apprentissage automatique a pour principal avantage de pouvoir gérer une grande diversité de problèmes complexes. Lors de l'estimation de la taille d'un ensemble de données d'apprentissage, 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 CJK nécessiteront généralement des ensembles de données d'entraînement et des modèles distincts.

Il existe 3 types de champs :

  • Champs normaux (date, montant total) Pour les champs normaux, vous avez besoin d'au moins 20 à 50 échantillons par champ. Ainsi, si vous devez extraire 10 champs réguliers, vous aurez besoin d'au moins 200 à 500 échantillons. Si vous devez extraire 20 champs réguliers, vous aurez 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.
  • 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, mais pour des mises en page très complexes et diverses, cela peut en nécessiter plus de 1 000. 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 dans certains cas, cela peut nécessiter 1 200 ou plus.
  • Champs de classification (devise) : les champs de classification nécessitent généralement au moins 10 à 20 échantillons de chaque classe.

Les directives ci-dessus supposent que vous vous retrouviez dans un scénario présentant une grande diversité, comme des factures ou des bons de commande avec des dizaines, des centaines ou des milliers de mises en page différentes. Cependant, si vous résolvez un scénario de faible diversité comme un formulaire fiscal ou des factures avec très peu de mises en page différentes (moins de 5 à 10), la taille de l'ensemble de données est davantage déterminée par le nombre de mises en page. Dans ce cas, vous devez commencer avec 20 à 30 pages pour chaque mise en page et en ajouter si nécessaire - surtout si les pages sont très denses et présentent un grand nombre de champs à extraire. Par exemple, la création d'un modèle permettant d'extraire 10 champs depuis 2 mises en page peut nécessiter 60 pages, mais si vous devez extraire 50 ou 100 champs depuis 2 mises en page, vous pouvez commencer avec 100 ou 200 pages et en ajouter si nécessaire pour obtenir le niveau de précision souhaité. Dans ce cas, la distinction champs réguliers/champs colonnes est moins importante.

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 Data 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, mais vous disposez également de 2 champs réguliers supplémentaires et d'un champ de colonne supplémentaire que le modèle de factures prêt à l'emploi ne reconnaît pas. Dans ce cas, vous avez besoin d'un ensemble d'apprentissage avec 50 échantillons par nouveau champ régulier et 200 échantillons par nouveau champ de colonne. Un ensemble de 200 pages est donc un bon point de départ. Il s'agit généralement d'un ensemble de données beaucoup plus petit que si vous aviez entraîné tous les champs à partir de zéro.

Ces 200 pages doivent être entièrement labellisées, 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 prêt à l'emploi le modèle reconnaît.

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 pages (par exemple, frais de traitement, remises). Dans ces cas, vous devez prendre une décision d'ordre professionnel. 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 sa 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. Au-delà d'un certain point, un nombre plus important de données n'est pas avantageux, et cela peut même affecter la précision sur d'autres fournisseurs car le modèle s'ajuste à l'excès en faveur d'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. Voir plus dans la section Définir les champs.

3. Créer un ensemble de données d'évaluation (Create an Evaluation dataset)

Alors que pour les ensembles d'entraînement, les pages et le nombre de pages sont les plus importants, dans le cas des ensembles d'évaluation, nous nous référons uniquement aux documents et au nombre de documents. Les scores des versions v2021.10 et ultérieures sont calculés par document.

Les ensembles de données d'évaluation peuvent être plus petits. Il peut s'agir de 50 à 100 documents (ou même de 30 à 50 dans des scénarios à faible diversité), et ils peuvent augmenter avec le temps pour atteindre quelques centaines de documents. Il est important qu'ils soient représentatifs du flux de données de production. Ainsi, une bonne approche consiste à sélectionner au hasard parmi les documents traités dans le workflow RPA. Même si certains fournisseurs seront surreprésentés, ce n'est pas grave. Par exemple, si un seul fournisseur représente 20 % de votre flux de factures, il est normal que ce fournisseur représente également 20 % de votre ensemble d'évaluation, de façon à ce que celui-ci se rapproche du mieux possibles de vos mesures commerciales, c'est-à-dire la réduction du nombre de mois et de personnes consacrés au traitement manuel des documents.

Lors de l'importation de données d'évaluation dans Data Manager, vous devez vous assurer de cocher la case « En faire un ensemble d'évaluation (Make this an evaluation set) » dans la fenêtre de dialogue d'importation. De cette façon, vous garantissez que les données sont conservées lors de l'entraînement, et vous pouvez également les exporter facilement pour exécuter des évaluations à l'aide de l'option Ensembles d'évaluation (evaluation-set) de la liste déroulante Filtre (Filter) de Data Manager.

Attention : À partir de la version Aperçu public 21.9 dans Automation Cloud et de la version locale 21.10 GA, Document Manager est passé à la gestion des documents multi-pages au lieu de chaque page comme entité distincte comme c'était le cas auparavant. Il s'agit d'un changement majeur, notamment pour les Évaluations, qui en étaient la principale motivation. Les évaluations doivent être représentatives du processus de runtime et, lors de l'exécution, les documents de plusieurs pages sont traités comme un tout plutôt que comme des pages séparées. Pour bénéficier de cette amélioration dans les paquets ML avec la version 21.10 ou ultérieure, il vous suffit de laisser la case « Exportation rétrocompatible » décochée dans la boîte de dialogue Exporter. Si vous cochez cette case, le jeu de données sera exporté selon l'ancienne méthode page par page, et les notes d'évaluation ne seront pas aussi représentatives des performances d'exécution.

4. Définir des champs

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.

  • 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 sera de 0,9. Cependant, si le score est une correspondance exacte (Exact Match), il est plus strict : un seul caractère erroné conduira à un score de zéro. Tous les champs sont par défaut définis sur Correspondance exacte (Exact Match). Seuls les champs de type String ont la possibilité de sélectionner la notation de Levenshtein.

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 de la facture actuelle - 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 clairement et précisément que possible afin d'éviter toute confusion. Si un humain peut les confondre, le modèle ML le fera également.

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. 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 (Charges antérieures, Total et Charges courantes) afin de pouvoir effectuer des vérifications 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 indiqué de façon explicite. Il peut également y avoir un autre tampon, une écriture manuscrite ou un pli au niveau du texte. Dans ces cas, les gens 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 des performances médiocres du modèle. Dans ce cas, vous pouvez créer 2 champs supplémentaires, 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 uniquement le 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 plusieurs lignes 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, englobant toute la ligne du tableau. Voici un exemple de tableau où les 2 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 Data Manager.



Fractionner les éléments

Fractionner les éléments (Split items) est un paramètre qui apparaît uniquement pour les champs Colonne (Column), qui aide le modèle à savoir quand un élément de ligne se termine et qu'un autre commence. En tant qu'humain qui regarde un document, pour connaître le nombre de lignes, vous regardez probablement combien il y a de montants sur le côté droit. Chaque montant fait habituellement référence à une ligne de montant. Ceci indique que line-amount est une colonne dans laquelle vous devez activer Fractionner les éléments (Split items). D'autres colonnes peuvent également être marquées, au cas où l'OCR manquerait le line-amount ou que le modèle ne le reconnaîtrait pas : la quantité (quantity) et le prix unitaire (unit-price) sont généralement également marqués comme « articles fractionnés ».

5. Configurer les champs

La configuration la plus importante est le type de contenu, à l'exception de la String :

  • Numérique
  • Date
  • Téléphone
  • Numéro d'identification

Ceux-ci ont un impact sur le post-traitement, en particulier le nettoyage, l'analyse et le formatage. Le plus complexe est le formatage de la Date, mais le formatage des Nombres nécessite également de déterminer le séparateur de décimales et le séparateur de milliers. Dans certains cas, si l'analyse échoue, votre option consiste à signaler le problème au support UiPath et à vous rabattre sur le type de contenu String, qui n'effectue aucune analyse. Dans ce cas, vous devrez analyser la valeur dans votre logique de workflow RPA.

Une autre configuration pertinente est la case à cocher Multi-ligne (Multi-line) qui concerne principalement les champs de type String. Chaque fois qu'un autre champ produit des résultats inattendus ou aucun résultat, la première chose à essayer est de le changer en champ multi-ligne de String (String Multi-line) pour voir la sortie inchangée de la prédiction du modèle.

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

Lors de la labellisation des données d'entraînement, vous devez vous concentrer sur les Cadres englobants des mots dans le volet du document du Data 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, tant qu'ils représentent le même concept (voir la section Définir les champs ci-dessus), tous doivent être labellisés.

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

7. Labelliser l'ensemble de données d'évaluation

Lors de la labellisation des ensembles de données d'évaluation (également appelés ensembles de données de test), vous devez vous concentrer sur quelque chose de légèrement différent de la labellisation des ensembles de données d'entraînement. Alors que pour les ensembles de données d'entraînement, seuls les cadres de délimitation des champs du document comptent, pour les ensembles de données d'évaluation, seules les valeurs des champs comptent. Vous pouvez les modifier en cliquant sur la valeur dans la barre latérale droite ou supérieure et en la modifiant. Pour revenir à la valeur analysée automatiquement, cliquez sur l'icône de verrouillage.

Remarque : pour plus de commodité, de rapidité et pour éviter les fautes de frappe, nous vous recommandons de cliquer sur les cases du document lors de la labellisation et de ne procéder aux corrections que manuellement. La saisie manuelle des valeurs complètes est plus lente et plus sujette aux erreurs.

8. Former et évaluer le modèle

L'exportation de l'ensemble de données complet, y compris les lots d'entraînement et de test, est autorisée car les pipelines d'entraînement dans AI Center ignorent les données de test. Cependant, les pipelines d'évaluation exécuteront l'évaluation sur l'ensemble de données d'évaluation, qu'il soit composé de données d'apprentissage ou de test. Le type d'un document donné est affiché juste sous le nom du fichier, en haut au centre de la fenêtre du Data Manager.

Lors de l'évaluation d'un modèle ML, l'outil le plus puissant est le fichier evaluation.xlsx généré dans le dossier artefacts/eval_metrics. 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 si cela peut être corrigé par une simple logique dans le workflow RPA, ou cela 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 Data Manager.

Ce fichier Excel est également très utile pour identifier les règles métier les plus pertinentes que vous devez appliquer dans le workflow RPA afin de détecter les erreurs courantes lors du routage vers la station de validation dans Action 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 Excel evaluation.xlsx est une ressource clé sur laquelle vous devez vous concentrer afin d'obtenir les meilleurs résultats de votre automatisation de l'IA.

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

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.

10. (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 fonctionnalité de pipeline d'évaluation dans AI Center, et plus précisément, la feuille de calcul Excel qui est générée par le pipeline d'évaluation dans le dossier Sorties (Outputs) > artefacts > eval_metrics.

Cette feuille de calcul contient une colonne pour chaque champ et une colonne pour le niveau de confiance de chaque prédiction. Vous pouvez ajouter une colonne appelée min_confidence qui prend le minimum de toutes les confiances sur tous les champs qui sont importants pour votre processus métier et qui ne sont pas déjà couverts par les règles métier. Par exemple, vous ne voudrez peut-être pas définir de seuil sur les éléments confidentiels des articles, mais plutôt sur le nom du fournisseur, le montant total, la date, la date d'échéance, le numéro de facture et d'autres champs essentiels. En triant le tableau en fonction de la colonne min_confidence, vous pouvez voir où les erreurs commencent à apparaître et définir un seuil au-dessus de ce niveau pour garantir que seuls les documents correctement extraits sont envoyés directement.

11. Entraînement à 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 Data 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 Data 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 devrez toujours vous entraîner sur le package 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 à ré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 Data 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.

Les données de la station de validation peuvent potentiellement être d'un volume beaucoup plus important car elles sont utilisées dans le workflow de production. Par conséquent, vous avez besoin d'une directive sur la quantité de données susceptibles d'être utiles, étant donné que l'entraînement du modèle nécessite du temps et une infrastructure. De plus, 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 Data 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 au Data Manager pour la labellisation manuelle. Les données de la station de validation ne sont pas appropriées pour une étendue de portée aussi importante.

Voici un exemple de scénario. Vous avez choisi un bon moteur OCR, labellisé 500 pages dans Data Manager, résultant en de bonnes performances et vous avez déployé le modèle dans un workflow RPA de production. Validation Station commence à générer des données. Vous devez sélectionner au hasard jusqu'à un maximum de 1000 à 1500 pages à partir de Validation Station et les importer dans le Data Manager avec les 500 premières pages et réentraîner votre modèle ML. Après cela, vous devez exécuter un pipeline d'évaluation pour vous assurer que le modèle s'est réellement amélioré, puis vous devez déployer le nouveau modèle en production.

12. La boucle de réglage automatique (aperçu) (The Auto-Fine-tuning Loop (Preview))

La boucle de réglage automatique est une fonctionnalité d'Aperçu qui devient utile pour maintenir un modèle hautement performant que vous avez déjà créé à l'aide des étapes décrites ci-dessus. Afin de garantir que le réglage automatique produit de meilleures versions du modèle, il est essentiel que vous disposiez d'un bon ensemble de données d'évaluation et que vous utilisiez un pipeline complet reprogrammé automatiquement qui exécute à la fois l'entraînement et l'évaluation. De cette façon, vous pouvez voir si l'entraînement le plus récent a produit un modèle plus précis que le précédent, et si c'est le cas, vous êtes prêt à déployer le nouveau modèle dans la compétence ML invoquée par les robots dans votre processus métier.

Remarque : l'ensemble de données d'entraînement ne cesse de changer à mesure que de nouvelles données arrivent, et Data Manager continue à exporter périodiquement dans la boîte de dialogue Exportation programmée (Scheduled Export). L'évaluation s'exécute sur le même ensemble de données d'évaluation que vous spécifiez dans le pipeline. Les ensembles de données d'évaluation ne changent jamais automatiquement, ils doivent toujours être organisés, labellisés et exportés manuellement. Vous devez modifier votre ensemble d'évaluation rarement afin que les scores de précision puissent être comparés entre les différentes exécutions d'entraînement.

AI Center offre la possibilité de mettre à jour automatiquement la compétence ML lorsqu'une nouvelle version d'un package ML est réentraînée. Cependant, cette mise à jour automatique ne prend pas en compte le score du Pipeline Complet, et il n'est donc pas recommandé d'utiliser cette fonctionnalité avec les pipelines de réapprentissage automatique de Document Understanding.

Comme mentionné ci-dessus dans la section Créer un ensemble de données d'évaluation (Create an Evaluation Dataset), les implémentations du pipeline d'évaluation pour les paquets ML version 21.10 ou ultérieure calculent les scores par document, ce qui reflète avec précision les résultats que vous voyez dans un workflow RPA. Cela suppose que votre ensemble de données a été labellisé par document dans Data Manager. Vous pouvez savoir si un document de plusieurs pages est étiqueté par document si vous pouvez faire défiler naturellement les pages comme dans un lecteur PDF ordinaire. Si vous devez cliquer sur suivant pour passer d'une page à l'autre, alors chaque page est considérée comme un document distinct.

13. Déployer votre automatisation

Assurez-vous d'utiliser le 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.

Cette page vous a-t-elle été utile ?

Obtenez l'aide dont vous avez besoin
Formation RPA - Cours d'automatisation
Forum de la communauté UiPath
Uipath Logo White
Confiance et sécurité
© 2005-2024 UiPath. Tous droits réservés.