Training von leistungsstarken Modellen

Die Leistungsfähigkeit von Machine Learning-Modellen besteht darin, dass sie durch Trainingsdaten und nicht durch explizite Logik im Computercode definiert werden. Das bedeutet, dass bei der Vorbereitung von Datasets besondere Vorsicht geboten ist, da ein Modell nur so gut ist wie das Dataset, mit dem es trainiert wurde. Was UiPath Studio für RPA -Workflows bedeutet, ist eine Dokumenttypsitzung (in Document &Understanding Cloud) für Machine Learning -Funktionen. Beide erfordern für einen effektiven Einsatz etwas Erfahrung.

What can a data extraction ML model do?

Ein ML-Modell kann Daten aus einem einzelnen Dokumenttyp extrahieren, obwohl es mehrere verschiedene Sprachen umfassen kann. Es ist wichtig, dass jedes Feld (Gesamtbetrag, Datum usw.) immer dieselbe Bedeutung hat. Wenn ein Mensch beim richtigen Wert für ein Feld unsicher sein kann, dann wird es auch das ML-Modell unklar sein.

Manchmal ist nicht alles so eindeutig. Ist z. B. eine Betriebskostenabrechnung eine von vielen Rechnungsarten? Oder sind es zwei verschiedene Dokumenttypen, die zwei verschiedene ML-Modelle erfordern? Wenn die Felder, die Sie extrahieren müssen, identisch sind (d. h. sie haben die gleiche Bedeutung), können Sie sie als einzelnen Dokumenttyp behandeln. Wenn Sie jedoch aus unterschiedlichen Gründen (unterschiedliche Geschäftsprozesse) unterschiedliche Felder extrahieren müssen, sollten Sie sie als zwei verschiedene Dokumenttypen behandeln und daher zwei verschiedene Modelle trainieren.

Wenn Sie sich unsicher sind, beginnen Sie mit dem Training eines einzelnen Modells. Halten Sie die Dokumente jedoch in verschiedenen Document Manager- Batches getrennt (siehe Filter-Dropdownmenü oben in der Ansicht), sodass Sie sie bei Bedarf später einfach trennen können. Auf diese Weise geht der Beschriftungsaufwand nicht verloren. Bei ML-Modellen gilt: Je mehr Daten, desto besser. Ein einzelnes Modell mit umfangreichen Daten ist also ein guter Anfang.

Training and evaluation datasets

Der Document Manager kann verwendet werden, um zwei Arten von Datasets zu erstellen: Trainings-Datasets und Auswertungs-Datasets.

Auswertungs-Datasets sind für Datenspezialisten oder für eine detaillierte Fehlerbehebung relevant, um bestimmte Probleme zu reproduzieren. Für die überwiegende Mehrheit der Enterprise -Automatisierungsszenarien wird jedoch nur das Trainings-Dataset benötigt und empfohlen. Trainingspipelines geben jetzt Artefakte der vollständigen Bewertung zurück, einschließlich der folgenden:

• Gesamtgenauigkeit des Modells – Dies wird als Hauptpunktzahl verwendet, die sowohl in der Ansicht „Details des Document Understanding-Extraktors“ als auch im AI Center-Ordner „Artefakte“ angezeigt wird (auch zugänglich über Document Understanding).
• F1-Punktzahl auf Modell- und Feldebene – Diese wird aus historischen Gründen im AI Center-Ordner „Artefakte“ bereitgestellt (auch zugänglich über Document Understanding).
• Detaillierte Metriken pro Feld und pro Batch sowie direkter Leistungsvergleich in der Excel-Datei, die im AI Center-Artefaktordner verfügbar ist (auch über Document Understanding zugänglich).

Es ist möglich, das Modell im Rahmen des Trainings zu bewerten, da der Trainingssatz automatisch zu 80 % oder 20 % auf Trainings- und Validierungsdaten aufgeteilt wird und die Ergebnisse anhand der Validierungsdaten berechnet werden.

Mit zunehmendem Dataset ändern sich sowohl die Trainings- als auch die Validierungsaufteilung, was bedeutet, dass die Ergebnisse im Laufe der Zeit nicht direkt vergleichbar sind (was einen Datenspezialisten interessieren würde). Sie spiegeln jedoch die Leistung des Modells bei den neuesten Daten wider, sodass sie repräsentativer für die aktuelle Leistung des Modells bei aktuellen Production sind (wofür Geschäftsprozessinhaber interessiert sind).

Mit diesem Ansatz haben Sie die folgenden Vorteile:

• Sie laufen nicht Gefahr, sich Ergebnisse anzusehen, die an veralteten Daten gemessen wurden, die möglicherweise Jahre alt sind.
• Sie reduzieren den Aufwand für die Beschriftung.
• Alle Daten, die Sie beschriften, tragen zur tatsächlichen Verbesserung des Modells bei, was schneller zu einer besseren Leistung führt.

Data extraction components

Die Datenextraktion basiert auf den folgenden Komponenten:

• Optical Character Recognition (OCR)
• OCR-Nachverarbeitung
  • Erkennen von Wörtern und Zeilen
  • Gruppieren von Zeichen zu Wörtern und Wörter zu Textzeilen
• Vorhersage des Machine Learning-Modells für jedes Wort/Feld auf der Seite
• Datennormalisierung
  • Zum Beispiel Gruppieren von Wörtern auf mehreren Zeilen in eine Adresse, Formatieren eines Datums in das Standardformat yyyy-mm-dd
• Wertauswahl
  • Anwenden eines Algorithmus zur Auswahl, welche von mehreren Instanzen eines bestimmten Werts tatsächlich zurückgegeben wird, für den Fall, dass das Dokument zwei oder mehr Seiten hat und einige Felder auf mehr als einer Seite angezeigt werden.

Konfidenzniveaus

What are confidence levels?

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

What are confidence levels useful for?

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

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

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

What types of confidence levels are there?

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

Confidence score scaling (or calibration)

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

Build a high performing ML model

Um das beste Ergebnis in Bezug auf die Automatisierungsrate zu erzielen (prozentuale Verringerung der manuellen Arbeitszeit in Monaten pro Jahr, die für die Verarbeitung Ihres Dokumentflusses erforderlich sind), müssen Sie die folgenden Schritte sorgfältig ausführen:

1. Die geeignetste OCR-Engine für Ihre Dokumente wählen

   Dies beeinflusst sowohl die OCR als auch die Erstellung von Wörtern und Zeilen (was teilweise von der OCR abhängt) und natürlich alles darauf folgende.

2. Die zu extrahierenden Felder definieren
3. Ein ausgewogenes und repräsentatives Dataset für das Training wählen
4. Das Trainings-Dataset beschriften
5. Den Extraktor trainieren
6. Definieren und Implementieren der Geschäftsregeln für die Ausgabe von Verarbeitungsmodellen
7. Konfidenz-Schwellenwert(e) für die Extraktion auswählen (optional)
8. Training mit Daten aus der Validation Station
9. Die Automatisierung bereitstellen

1. Ein OCR-Modul wählen

Ihre Standardoption sollte UiPath Document OCR für europäische lateinische Sprachen oder UiPath Chinese-Japanese-Korean OCR sein. Wenn Sie andere Sprachen verarbeiten müssen, einschließlich kyrillischer Schrift, Devanagiri-Schriftart, Thai, Vietnamesisch, Arabisch, Hebräisch oder Persisch, sollten Sie Microsoft Azure Read OCR (nur Cloud), Google Cloud Vision OCR (nur Cloud) oder Omnipage OCR (Aktivität) in Studio). Es lohnt sich, ein paar verschiedene Document Manager-Sitzungen mit verschiedenen OCR-Engines zu erstellen, um zu überprüfen, welche bei Ihren Dokumenten am besten funktioniert. Ein späteres Ändern des OCR-Moduls im Projekt kann kostspielig sein.

Beachten Sie, dass bei der Aktivität Digitize Document die Einstellung OCRAufPDFAnwenden standardmäßig auf Automatisch festgelegt ist. Das bedeutet, dass Digitize bei der Bearbeitung von .pdf-Dokumenten standardmäßig versucht, so viel Text wie möglich aus dem .pdf-Dokument selbst und nur OCR-Bilder wie Logos zu erfassen und die Ergebnisse zu kombinieren.

Die PDF-Datei sind Dokumente manchmal beschädigt oder ungewöhnlich formatiert, was zu Fehlern im extrahierten Text führt. Legen Sie in diesem Fall ApplyOCRonPDFs auf Yesfest.

Ein weiterer Vorteil der Anwendung von OCR auf allen PDF- Dateien Dokumente, die UiPath Document OCR verwenden, besteht darin, dass UiPath Document OCR Kontrollkästchen erkennt, die kritische Elemente von Dokumenten wie Formularen sind. Beachten Sie jedoch, dass die Anwendung von OCR auf alles die Digitalisierung etwas verlangsamt.

2. Define fields

Wie Felder definiert werden, muss mit dem/der Zuständigen für das jeweilige Thema besprochen werden. Bei Rechnungen etwa ist der Zuständige für Konten mit Fähigkeiten. Das zu besprechen ist äußerst wichtig. Es muss vor der Beschriftung von Dokumenten erfolgen, um Zeitverschwendung zu vermeiden und erfordert zusammen mindestens 20 zufällig ausgewählte Dokumentenbeispiele. Dafür muss ein Ein-Stunden-Slot reserviert werden, der oft nach ein paar Tagen wiederholt werden muss, wenn die Person, die die Daten vorbereitet, mehrdeutige Situationen oder Randfälle erlebt.

Nicht selten wird am Anfang angenommen, dass 10 Felder extrahiert werden müssen, am Ende sind es aber 15. Einige Beispiele werden in den Unterabschnitten unten beschrieben.

Einige wichtige Konfigurationen, die Sie kennen müssen:

• Inhaltstyp

  Dies ist die wichtigste Einstellung, da sie die Nachverarbeitung der Werte bestimmt, insbesondere für Datumsangaben (erkennt, ob das Format im US- oder nicht-US-Format ist, und formatiert sie dann im Format yyyy-mm-dd) und für Zahlen (erkennt das Dezimaltrennzeichen – Komma oder Punkt). Identifikationsnummern löschen alle Inhalte vor einem Doppelpunkt oder Rautensymbol. Strings führen keine Bereinigung durch und können verwendet werden, wenn Sie Ihre eigene Analyse im RPA-Workflow durchführen möchten.

• Mehrzeiliges Kontrollkästchen

  Dies ist zum Analysieren von Zeichenfolgen wie Adressen, die sich auf mehrere Zeilen erstrecken können.

• Kontrollkästchen mit mehreren Werten

  Dies ist für die Handhabung von Multiple-Choice-Feldern oder anderen Feldern gedacht, die mehr als einen Wert haben können, aber NICHT als Tabellenspalte dargestellt werden. Beispielsweise kann eine Frage zur Volksgruppe auf einem Formular einer Regierung mehrere Kontrollkästchen enthalten, in denen Sie alle Zutreffenden auswählen können.

• Ausgeblendete Felder

  Felder, die als ausgeblendet markiert sind, können beschriftet werden, werden aber beim Exportieren von Daten zurückgehalten, sodass das Modell nicht darauf trainiert werden kann. Dies ist praktisch, wenn die Beschriftung eines Felds ausgeführt wird, wenn es zu selten ist oder wenn es eine geringe Priorität hat.

• Punktzahl

  Dies ist nur für Auswertungspipelines relevant und wirkt sich auf die Berechnung der Genauigkeitspunktzahl aus. Ein Feld, das die Levenshtein -Bewertung verwendet, lässt mehr zu: Wenn ein einzelnes Zeichen von 10 falsch ist, beträgt die Punktzahl 0,9. Eine Exact Match -Bewertung ist strenger: Ein einzelnes falsches Zeichen führt zu einer Punktzahl von Null. Nur Felder vom Typ String verfügen standardmäßig über die Option, Levenshtein-Bewertung auszuwählen.

Beträge auf Betriebskostenabrechnungen

Ein Gesamtbetrag mag aussagekräftig genug erscheinen, aber Betriebskostenabrechnungen enthalten viele Beträge. Manchmal benötigen Sie den zu zahlenden Gesamtbetrag. In anderen Situationen benötigen Sie nur den aktuellen Rechnungsbetrag – ohne die Beträge, die aus früheren Rechnungsperioden übertragen wurden. Im letzteren Fall müssen Sie anders beschriften, auch wenn die aktuelle Rechnung und der Gesamtbetrag identisch sein können. Die Konzepte unterscheiden sich und die Beträge sind oft unterschiedlich.

Hinweis: Jedes Feld stellt eine andere Betragsart dar und muss so genau wie möglich definiert werden, damit keine Verwirrung entsteht. Wenn ein Mensch verwirrt sein könnte, wird das ML-Modell auch verwirrt sein.

Darüber hinaus kann der aktuelle Rechnungsbetrag manchmal aus mehreren verschiedenen Beträgen, Gebühren und Steuern bestehen und erscheint nirgendwo auf der Rechnung einzeln. Eine mögliche Lösung hierfür ist die Erstellung von zwei Feldern: einem Feld mit früheren Kosten und einem Feld für die Gesamtsumme . Diese beiden erscheinen immer als unterschiedliche explizite Werte auf der Betriebskostenabrechnung. Dann kann der aktuelle Rechnungsbetrag als Differenz zwischen den beiden ermittelt werden. Sie können sogar alle drei Felder (previous-costs, totalund current-costs) einschließen, um Konsistenzprüfungen durchführen zu können, wenn der aktuelle Rechnungsbetrag explizit im Dokument erscheint. Sie können also in einigen Fällen von einem auf drei Felder wechseln.

Bestellnummern auf Rechnungen

Auftragsnummern können als einzelne Werte für eine Rechnung angezeigt werden, oder sie erscheinen möglicherweise als Teil der Tabelle der Positionen auf einer Rechnung, bei denen jede Position eine andere Auftragsnummer hat. In diesem Fall könnte es sinnvoll sein, zwei verschiedene Felder zu haben: po-no (Auftragsnummer) und item-po-no (Position Auftragsnummer). Wenn jedes Feld visuell und visuell konsistent bleibt, wird das Modell wahrscheinlich viel besser funktionieren. Sie müssen jedoch sicherstellen, dass beide in Ihren Trainings- und Auswertungs-Datasets gut dargestellt sind.

Lieferantenname und Zahlungsadresse auf Rechnungen

Der Name des Unternehmens erscheint normalerweise oben auf einer Rechnung oder einer Betriebskostenabrechnung, aber manchmal ist er möglicherweise nicht lesbar, da es nur ein Logo gibt und der Name des Unternehmens nicht explizit ausgeschrieben ist. Der Text könnte auch durch einen Stempel, Handschrift oder Falten verdeckt sein. In diesen Fällen könnte der Name, der unten rechts im Abschnitt „ Zahlung anfordern an“ des Lohnzettels auf den Betriebskostenabrechnungen steht, beschriftet werden. Dieser Name ist oft derselbe, aber nicht immer, da es sich um ein anderes Konzept handelt. Zahlungen können an eine Muttergesellschaft, eine Beteiligungsgesellschaft oder ein anderes verbundenes Unternehmen mit visuellen Unterschieden auf dem Dokument erfolgen. Dies kann zu einer schlechten Modellleistung führen. In diesem Fall sollten Sie zwei Felder erstellen: vendor-name und payment-addr-name. Dann können Sie beide in einer Anbieterdatenbank nachschlagen und den passenden verwenden oder payment-addr-name verwenden , wenn der Anbietername fehlt.

Tabellenzeilen

Es gibt zwei verschiedene Konzepte zu beachten: Tabellenzeilen und Textzeilen. Eine Tabellenzeile enthält alle Werte aller Spaltenfelder, die in dieser Zeile zusammen gehören. Manchmal sind sie alle Teil derselben Textzeile auf einer Dokumentenseite. Manchmal erstrecken sie sich über mehrere Zeilen.

Wenn eine Tabellenzeile aus mehr als einer Textzeile besteht, müssen Sie alle Werte in dieser Tabellenzeile mit dem Hotkey „/“ gruppieren. Dabei wird ein grünes Feld für die gesamte Tabellenzeile angezeigt. Hier ist ein Beispiel für eine Tabelle, in der die ersten beiden Zeilen aus mehreren Textzeilen bestehen und mit dem Hotkey „/“ gruppiert werden müssen, während die dritte Zeile eine einzelne Textzeile ist und nicht gruppiert werden muss.

Hier ein Beispiel für eine Tabelle, in der jede Tabellenzeile aus einer einzelnen Textzeile besteht. Sie müssen diese nicht mit dem Hotkey „/“ gruppieren, da dies implizit durch den Document Manager geschieht.

Zu erkennen, wo eine Zeile endet und eine andere beginnt, wenn man von oben nach unten liest, kann für ML-Extraktionsmodelle oft eine große Herausforderung sein, insbesondere bei Dokumenten wie Formularen, bei denen es keine visuellen horizontalen Linien gibt, die die Zeilen trennen. In unseren ML-Paketen gibt es ein spezielles Modell, das darauf trainiert ist, Tabellen korrekt in Zeilen aufzuteilen. Dieses Modell wird mithilfe dieser Gruppen trainiert, die Sie mit den Tasten „/“ oder „Enter“ beschriften und die durch die grünen transparenten Kästchen gekennzeichnet sind.

3. Create a training dataset

Machine Learning-Technologie ist vor allem zur Lösung komplexer Probleme mit großen Unterschieden hilfreich. Bei der Schätzung der Größe eines Trainings-Datasets wird zuerst die Anzahl der Felder und deren Typen sowie die Anzahl der Sprachenbetrachtet . Ein einzelnes Modell kann mehrere Sprachen verarbeiten, solange sie nicht Chinesisch/Japanisch/Koreanisch sind. Die späteren Szenarien erfordern im Allgemeinen separate Trainings-Datasets und separate Modelle.

Es gibt 3 Arten von Feldern:

1. Reguläre Felder (Datum, Gesamtbetrag)

   Für reguläre Felder benötigen Sie mindestens 20–50 Dokumentenbeispiele pro Feld. Wenn Sie also 10 reguläre Felder extrahieren müssen, benötigen Sie mindestens 200–500 Beispiele. Wenn Sie 20 reguläre Felder extrahieren müssen, benötigen Sie mindestens 400–1000 Beispiele. Die Anzahl der benötigten Beispiele erhöht sich mit der Anzahl der Felder. Weitere Felder bedeutet, dass Sie mehr Beispiele benötigen, etwa 20–50-mal mehr.

2. Spaltenfelder (Stückpreis, Stückzahl)

   Für Spaltenfelder benötigen Sie mindestens 50–200 Dokumentenbeispiele pro Spaltenfeld, sodass Sie für 5 Spaltenfelder mit sauberen und einfachen Layouts mit 300 Dokumentenbeispielen gute Ergebnisse erzielen können 1000. Um mehrere Sprachen abzudecken, benötigen Sie mindestens 200–300 Beispiele pro Sprache, vorausgesetzt, sie decken all die verschiedenen Felder ab. Für 10 Headerfelder und 4 Spaltenfelder mit 2 Sprachen können 600 Beispiele ausreichen (400 für die Spalten und Header plus 200 für die zusätzliche Sprache), aber in einigen Fällen können 1200 oder mehr erforderlich sein.

3. Klassifizierungsfelder (Währung)

   Klassifizierungsfelder erfordern in der Regel mindestens 10–20 Beispiele aus jeder Klasse.

Der empfohlene Bereich für die Dataset-Größe basiert auf den Informationen, die auf der Registerkarte „Rechner“ bereitgestellt werden. Bei einfacheren Szenarien mit wenigen regulären Feldern und klaren Dokumentlayouts können gute Ergebnisse mit Datasets in einem niedrigen orangefarbenen Bereich erzielt werden. Bei komplexen Szenarien, insbesondere bei komplexen Tabellen mit vielen Spalten, können gute Ergebnisse Datasets in einem hohen orange- oder sogar grünen Bereich erfordern.

Wichtig: Machine Learning wurde für Szenarien mit großen Unterschieden entwickelt. Um Modelle für Szenarien mit geringen Unterschieden (1–10 Layouts) zu trainieren, ist eine besondere Vorsicht erforderlich, um empfindliche Modelle zu vermeiden, die auf geringfügige Änderungen des OCR-Textes reagieren. Vermeiden Sie dies, indem Sie absichtlich für Unterschiede bei den Trainingsdokumenten sorgen, indem Sie diese ausdrucken und dann über Scanner-Apps mit dem Smartphone scannen oder fotografieren. Leichte Verzerrungen oder unterschiedliche Auflösungen machen das Modell robuster.

Zudem gehen diese Schätzungen davon aus, dass die meisten Seiten alle oder die meisten Felder enthalten. In Fällen, in denen Sie Dokumente mit mehreren Seiten haben, die meisten Felder aber auf einer einzigen Seite sind, dann entspricht die Anzahl von Seiten der Anzahl der Beispiele dieser einen Seite, auf der die meisten Felder erscheinen.

Die obigen Zahlen sind allgemeine Werte zur Orientierung, keine strikten Anforderungen. Im Allgemeinen können Sie mit einem kleineren Dataset beginnen und dann weiter Daten hinzufügen, bis Sie eine gute Genauigkeit erhalten. Dies ist besonders nützlich, um die RPA mit der Modellerstellung zu parallelisieren. Außerdem kann eine erste Version des Modells verwendet werden, um zusätzliche Daten vorzubeschriften (siehe Ansicht Einstellungen und Schaltfläche Vorhersage im Document Manager), was die Beschriftung zusätzlicher Trainingsdaten beschleunigen kann.

Deep-Learning-Modelle können verallgemeinern

Nicht jedes einzelne Layout muss in einem Trainingssatz dargestellt werden. Tatsächlich ist es möglich, dass die meisten Layouts in unserem Produktions-Dokumentenfluss keine Beispiele in Ihrem Trainingssatz haben oder vielleicht nur 1 oder 2. Das ist wünschenswert, da die Leistungsfähigkeit der KI genutzt werden soll, um die Dokumente zu verstehen und in der Lage zu sein, korrekte Vorhersagen für Dokumente zu treffen, die sie während des Trainings nicht gesehen hat. Eine große Anzahl von Beispielen pro Layout ist nicht obligatorisch, da die meisten Layouts entweder überhaupt nicht oder nur 1- oder 2-mal vorhanden sind und das Modell basierend auf dem Lernen von anderen Layouts weiterhin korrekt vorhersagen kann.

Training über ein sofort einsetzbares Modell

Eine häufige Situation ist das Extrahieren von Daten aus Rechnungen, für die wir ein vortrainiertes vorgefertigtes Modell haben, aber zusätzlich 2 weitere reguläre Felder und 1 weiteres Spaltenfeld zur Verfügung stehen, das das vortrainierte Modell „Rechnungen“ nicht erkennt. In diesem Fall benötigen Sie in der Regel ein viel kleineres Dataset, als wenn Sie alle Felder von Grund auf trainiert hätten. Die Schätzung der Dataset-Größe wird bereitgestellt, wenn Sie einen Dokumenttyp in der Document Understanding Cloud erstellen, und sie ist dann über die Ansicht „Dataset-Diagnose“ zugänglich. Beachten Sie jedoch, dass alle Dokumente, die Sie zum Trainieren eines Modells verwenden, vollständig beschriftet werden müssen, einschließlich der neuen Felder, die das out-of-the-box Modell nicht erkennt, und auch der Originale der Felder, die das out-of-the-box Modell nicht erkennt, des Box-Modells erkennt.

Ungleiche Feldvorkommen

Einige Felder können in jedem Dokument vorkommen (z. B. Datum, Rechnungsnummer), während einige Felder möglicherweise nur in 10 % der Dokumente angezeigt werden (z. B. Bearbeitungskosten, Rabatt). In diesen Fällen müssen Sie eine geschäftliche Entscheidung treffen. Wenn diese seltenen Felder für Ihre Automatisierung nicht wichtig sind, kann eine kleine Anzahl von Beispielen (10–15) dieses bestimmten Felds reichen, d. h. Seiten, die einen Wert für dieses Feld enthalten. Wenn diese Felder jedoch kritisch sind, müssen Sie sicherstellen, dass Sie in Ihren Trainingssatz mindestens 30–50 Beispiele dieses Felds aufnehmen, um sicherzustellen, dass die gesamte Vielfalt abgedeckt wird.

Ausgewogene Datasets

Wenn ein Dataset Rechnungen von 100 Anbietern enthält, aber die Hälfte des Datasets nur aus Rechnungen von einem einzigen Anbieter besteht, dann ist dies ein sehr unausgewogenes Dataset. In einem perfekt ausgewogenen Dataset erscheint jeder Anbieter gleich oft. Datasets müssen nicht perfekt austariert sein, aber Sie sollten vermeiden, mehr als 20 % Ihres gesamten Datasets von einem einzelnen Anbieter zu stammen. Irgendwann helfen mehr Daten nicht und kann sogar die Genauigkeit bei anderen Anbietern beeinträchtigen, weil das Modell zu sehr für einen Anbieter optimiert wird (overfit).

Repräsentative Datasets

Daten sollten so ausgewählt werden, dass sie die Vielfalt der Dokumente abdecken, die im Produktionsworkflow wahrscheinlich vorhanden ist. Wenn Sie beispielsweise Rechnungen auf Englisch erhalten, aber einige von ihnen aus den USA, Indien und Australien stammen, sehen sie wahrscheinlich anders aus, also müssen Sie sicherstellen, dass Sie Beispiele von allen dreien haben. Dies ist nicht nur für das Modelltraining selbst relevant, sondern auch für Beschriftungszwecke, da Sie beim Beschriften der Dokumente möglicherweise feststellen, dass Sie neue, verschiedene Felder bei einigen dieser Regionen extrahieren müssen, z. B. GSTIN-Code bei Indien oder ABN-Code bei Australien.

Aufteilung von Training/Validierung

Jedes Trainings-Dataset wird hinter den Kulissen automatisch in einen Trainingssatz (zufällig ausgewählte 80 %) und einen Validierungssatz (zufällig ausgewählte 20 %) aufgeteilt. Während des Trainings von Deep Learning-Modellen wird der Trainingssatz für die Backpropagation verwendet, dem Teil, der tatsächlich die Gewichtungen der Knoten im Netzwerk ändert, während der Validierungssatz nur verwendet wird, um zu wissen, wann das Training beendet werden soll. Er wird also verwendet, um eine Überanpassung des Trainingssatzes zu verhindern.

So erhalten wir die vollständige Auswertungspunktzahl am Ende einer Trainingsausführung: Wir geben die Punktzahlen für den Validierungssatz zurück. Dieser Satz wird technisch gesehen nicht zum Training des Netzwerks verwendet, sondern nur zur Vermeidung einer Überanpassung. Da es jedoch zufällig 20 % aus dem gesamten Dataset ausgewählt wird, ist es in der Regel ähnlich auf den Trainingssatz verteilt. Diese Konsistenz ist gut, denn sie bedeutet, dass die erhaltenen Ergebnisse die Fähigkeit des Modells widerspiegeln, aus den Daten zu lernen, was uns normalerweise wichtig ist. Wenn ein Modell nicht in der Lage ist, zu lernen, sind die Daten inkonsistent oder das Modell hat eine Einschränkung. Das sind kritische Dinge, die wir sofort beim Training eines Modells wissen müssen.

Der Nachteil dieses Ansatzes ist, dass die Punktzahlen nicht unbedingt mit genau gleichen Punkten verglichen werden können, wenn das Dataset wächst, und dass die Punktzahlen nicht die Fähigkeit des Modells zur Verallgemeinerung widerspiegeln, sondern nur seine Lernfähigkeit. Apple-to-Apfel-Vergleiche und die Messung der Fähigkeit zur Verallgemeinerung sind jedoch technische, Data-Science-Probleme, die bei den meisten Automatisierungen nur indirekte Auswirkungen auf die Geschäftsleistung oder den ROI haben.

4. Label the training dataset

Beim Beschriften von Trainingsdaten müssen Sie sich auf die Begrenzungsfelder der Wörter im Dokumentbereich vom Document Manager konzentrieren. Die geparsten Werte in den Seitenleisten rechts oder oben sind nicht wichtig, da sie nicht für das Training verwendet werden.

Wenn ein Feld mehrfach auf einer Seite auftaucht, sollten alle Felder, sofern sie dasselbe Konzept repräsentieren, beschriftet werden.

Wenn die OCR ein Wort verpasst oder ein paar Zeichen falsch interpretiert, beschriften Sie einfach das Begrenzungsfeld, wenn es eines gibt. Wenn nicht, überspringen Sie es einfach und fahren Sie fort. Es besteht nicht die Möglichkeit, ein Wort im Document Manager hinzuzufügen, da das Wort auch nach dem Ergänzen zur Laufzeit noch fehlen und das Modell nicht unterstützen würde.

Wenn Sie Felder beschriften, die mehrere oder sich überschneidende Bedeutungen/Konzepte haben können, müssen Sie ein Feld möglicherweise in zwei separate Felder aufteilen. Achten Sie auch auf Felder, die Sie nicht explizit benötigen, die jedoch bei der Beschriftung möglicherweise helfen, bestimmte Validierungen oder Selbstkonsistenzprüfungen im RPA-Workflow durchzuführen. Typische Beispiele sind Menge, Stückpreis und Zeilenbetrag für Rechnungspositionen. Der Zeilenbetrag ist das Produkt der Menge und des Stückpreises – er ist sehr nützlich, um auf Konsistenz zu überprüfen, ohne dass Konfidenzniveaus erforderlich sind.

5. Train the extractor

Um einen Extraktor zu erstellen, wechseln Sie in Document Understanding zur Ansicht „ Extraktoren “ und klicken Sie rechts oben auf die Schaltfläche Extraktor erstellen . Sie können dann den Dokumenttyp, das ML-Modell und die Version auswählen, die Sie verwenden möchten. Sie können den Fortschritt auf der Registerkarte „Extraktoren“ oder in der Ansicht „ Details “ des Extraktors überwachen, die einen Link zur AI Center-Pipeline enthält, in der Sie die detaillierten Protokolle in Echtzeit sehen können.

Bei der Auswertung eines ML-Modells ist das leistungsstärkste Tool evaluation_<package name>.xlsx Datei, die im Ordner artifacts/eval_metrics in der AI Center-Pipeline-Detailansicht generiert wird. Auf dem ersten Blatt können Sie einen detaillierten Bericht zu den Genauigkeitsbewertungen sehen, einschließlich der Gesamtpunktzahlen sowie pro Feld und pro Batch.

In dieser Excel-Datei können Sie sehen, welche Vorhersagen fehlschlagen und auf welchen Dateien, und Sie können sofort sehen, ob es sich um einen OCR-Fehler oder einen ML-Extraktions- oder Analysefehler handelt und ob er durch einfache Logik im RPA-Workflow behoben werden kann, oder es erfordert eine andere OCR-Engine, mehr Trainingsdaten oder eine Verbesserung der Beschriftung oder der Feldkonfigurationen im Document Manager.

Diese Excel-Datei ist auch sehr nützlich, um die relevantesten Geschäftsregeln zu identifizieren, die Sie auf den RPA-Workflow anwenden müssen, um häufige Fehler zu erkennen, die zur manuellen Überprüfung an die Validation Station im Actions Center weiterzuleiten sind. Geschäftsregeln sind mit Abstand die zuverlässigste Möglichkeit, Fehler zu erkennen.

Für die Fehler, die für Geschäftsregeln nicht erkennbar sind, können Sie auch Konfidenzniveaus verwenden. Die Excel-Datei enthält auch Konfidenzniveaus für jede Vorhersage, sodass Sie Excel-Funktionen wie „Sortieren“ und „Filtern“ verwenden können, um zu bestimmen, was ein guter Konfidenzschwellenwert für Ihr Geschäftsszenario ist.

Insgesamt ist die evaluation_<package_name>.xlsx Eine Excel-Datei ist eine wichtige Ressource, auf die Sie sich konzentrieren müssen, um die besten Ergebnisse mit Ihrer KI-Automatisierung zu erzielen.

Wichtig: GPU-Training wird für große und Produktions-Datasets dringend empfohlen. CPU-Training ist viel langsamer und sollte sparsam für kleine Datasets zu Demo- oder Testzwecken eingesetzt werden. Weitere Informationen finden Sie auf der Seite Trainingspipelines.

6. Define and implement business rules

In diesem Schritt sollten Sie sich mit Modellfehlern und ihrer Erkennung beschäftigen. Es gibt zwei Hauptwege, um Fehler zu erkennen:

• durch Erzwingen von Geschäftsregeln
• durch Anwenden von Lookups in Systems of Record in der Kundenorganisation
• durch Erzwingen eines Mindestkonfidenzschwellenwerts

Die effektivste und zuverlässigste Möglichkeit, Fehler zu erkennen, ist die Definition von Geschäftsregeln und Lookups. Die Konfidenzniveaus können nie zu 100 % perfekt sein. Es wird immer einen kleinen, aber nicht Null betragenden Prozentsatz korrekter Vorhersagen mit geringer Konfidenz oder falscher Vorhersagen mit hoher Konfidenz geben. Darüber hinaus und vielleicht am wichtigsten ist, dass ein fehlendes Feld keine Konfidenz hat, sodass ein Konfidenzschwellenwert niemals Fehler erkennen kann, wenn ein Feld überhaupt nicht extrahiert wird. Folglich sollten Konfidenzschwellenwerte nur als Ausweichlösung, als Sicherheitsnetz, verwendet werden, aber niemals als Hauptmethode, um geschäftskritische Fehler zu erkennen.

Beispiele für Geschäftsregeln:

• Nettobetrag plus Steuerbetrag muss dem Gesamtbetrag entsprechen
• Der Gesamtbetrag muss größer oder gleich dem Nettobetrag sein
• Rechnungsnummer, Datum, Gesamtbetrag (und möglicherweise andere Felder) müssen vorhanden sein
• Auftragsnummer (falls vorhanden) muss in der entsprechenden Datenbank vorhanden sein
• Rechnungsdatum muss in der Vergangenheit liegen und darf höchstens X Monate alt sein
• Fälligkeitsdatum darf höchstens Y Tage/Monate in der Zukunft liegen
• Für jedes Zeilenelement muss die mit dem Stückpreis multiplizierte Menge dem Zeilenbetrag entsprechen
• Summe der Zeilenbeträge muss gleich dem Nettobetrag oder Gesamtbetrag sein
• usw.

Hinweis: Bei Zahlen wird eine Rundung auf acht Dezimalstellen durchgeführt.

Insbesondere sollten die Konfidenzniveaus von Spaltenfeldern fast nie als Mechanismus zur Fehlererkennung verwendet werden, da sie Dutzende Werte haben können (wie z. B. Zeilenelemente auf Rechnungen oder Auftragsblättern), was das Festlegen eines Mindestschwellenwerts über so viele Werte besonders unzuverlässig machen kann, da die Konfidenz eines Werts mehr als wahrscheinlich gering ausfällt. Dies würde dazu führen, dass die meisten/alle Dokumente unnötigerweise an die menschliche Validierung weitergeleitet werden.

Geschäftsregeln müssen als Teil des RPA Workflows erzwungen werden und die Geschäftsregelfehler werden an den menschlichen Validierer übergeben, um seine Aufmerksamkeit darauf zu lenken und den Prozess zu beschleunigen.

Hinweis: Beachten Sie beim Definieren von Geschäftsregeln, dass bei den Werten Beginnt mit, Endet mit und Enthält die Groß-/Kleinschreibung beachtet wird.

7. (Optional) Choose a confidence threshold

Nachdem die Geschäftsregeln definiert wurden, bleibt manchmal eine kleine Anzahl von Feldern übrig, für die keine Geschäftsregeln vorhanden sind oder für die die Geschäftsregeln wahrscheinlich nicht alle Fehler erkennen werden. Möglicherweise müssen Sie dazu einen Konfidenzschwellenwert als letztes Mittel verwenden.

Das Haupttool zum Festlegen dieses Schwellenwerts ist die Excel-Tabelle, die von der Trainingspipeline im Ordner Ausgaben > Artefakte > eval_metrics ausgegeben wird.

Diese evaluation_<package name>.xlsx enthält eine Spalte für jedes Feld und eine Spalte für das Konfidenzniveau jeder Vorhersage. Durch Sortieren der Tabelle basierend auf den Konfidenzspalten können Sie sehen, wo die Fehler für ein bestimmtes Feld angezeigt werden, und einen Schwellenwert über dieser Ebene festlegen, um sicherzustellen, dass nur korrekt extrahierte Dokumente direkt gesendet werden.

8. Fine-tune with data from Validation Station

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.

Der zweite Hauptaspekt ist, dass die Validation Station-Daten eine geringere Informationsdichte haben als die im Document Manager beschrifteten Daten. Grundsätzlich ist es dem Validation Station-Benutzer nur wichtig, einmal den richtigen Wert zu erhalten. Wenn eine Rechnung 5 Seiten hat und die Rechnungsnummer auf jeder Seite erscheint, überprüft der Benutzer der Validation Station sie nur auf der ersten Seite. 80 % der Werte bleiben also unbeschriftet. Im Document Manager werden alle Werte beschriftet.

Denken Sie schließlich daran, dass Validation Station-Daten dem ursprünglichen manuell beschrifteten Dataset hinzugefügt werden müssen, damit Sie immer über ein einzelnes Trainings-Dataset verfügen, das im Laufe der Zeit an Größe zunimmt. Sie müssen immer auf dem ML-Paket mit der Nebenversion 0 (null) trainieren, der Version, die von UiPath vorgefertigt veröffentlicht wurde.

Wichtig: Es wird oft fälschlicherweise angenommen, dass Daten aus der Validation Station dazu verwendet werden, die vorherige Modellversion iterativ zu trainieren, d. h. der aktuelle Batch wird verwendet, um Paket X.1 zu trainieren und dann X.2 zu erhalten. Dann wird der nächste Batch mit X.2 trainiert, um X.3 zu erhalten und so weiter. Dies ist die falsche Art, das Produkt zu verwenden. Jeder Batch der Validation Station muss in dieselbe Document Manager-Sitzung importiert werden wie die ursprünglichen manuell beschrifteten Daten, was ein größeres Dataset ergibt, mit dem dann immer auf der ML-Paketversion X.0 trainiert werden muss.

Vorsichtsmaßnahmen bei der Verwendung von Validation Station-Daten

Validation Station-Daten können potenziell ein viel höheres Volumen haben, da sie im Production verwendet werden. Das Dataset soll nicht mit Validation Station-Daten überlastet werden, da dies die Qualität des Modells aufgrund des oben genannten Problems der Informationsdichte beeinträchtigen kann.

Wir empfehlen, maximal 2–3-mal die Seitenanzahl der Document Manager-Daten hinzuzufügen und darüber hinaus nur die Anbieter oder Beispiele zu wählen, bei denen größere Fehler aufgetreten sind. Wenn größere Änderungen an den Production bekannt sind, z. B. eine neue Sprache oder eine neue geografische Region, die in den Geschäftsprozess integriert wird (von den USA nach Europa oder Südasien), dann sollten repräsentative Daten für diese Sprachen und Regionen hinzugefügt werden. an Document Manager zur manuellen Beschriftung. Validation Station-Daten sind für eine Scope-Erweiterung dieser Größe nicht geeignet.

Ein weiteres potenzielles Problem mit Validation Station-Daten ist die Ausgewogenheit. In der Production kommt der Großteil des Datenverkehrs häufig von einer kleinen Teilmenge von Anbietern/Kunden/Weltregionen. Wenn es so in den Trainingssatz übernommen wird, kann dies zu einem stark verzerrten Modell führen, das bei einer kleinen Teilmenge der Daten gut funktioniert, aber bei den meisten anderen Daten schlecht funktioniert. Daher ist es wichtig, beim Hinzufügen von Validation Station-Daten zu einem Trainingssatz besonders vorsichtig zu sein.

Hier ist ein Beispielszenario. Sie haben ein gutes OCR-Modul gewählt und 500 Seiten im Document Manager beschriftet, was zu einer guten Leistung führte. Dann haben Sie das Modell in einem RPA-Workflow für die Produktion bereitgestellt. Die Validation Station beginnt mit der Generierung von Daten. Sie sollten zufällig bis zu maximal 1000–1500 Seiten von der Validation Station auswählen und sie zusammen mit den ersten 500 Seiten zum Document importieren und Ihr ML-Modell trainieren. Danach sollten Sie sich die evaluation_<package name>.xlsx sehr sorgfältig ansehen, um sicherzustellen, dass das Modell tatsächlich verbessert wurde. Dann sollten Sie das neue Modell in der Produktion bereitstellen.

9. Deploy your automation

Stellen Sie sicher, dass Sie den Document Understanding-Prozess: Studio-Vorlage im Abschnitt Vorlagen auf dem Studio-Startbildschirm verwenden, um Best Practices in der Enterprise-RPA-Architektur anzuwenden.