優れたパフォーマンスのモデルをトレーニングする

The power of Machine Learning Models is that they are defined by training data rather than by explicit logic expressed in computer code. This means that extraordinary care is needed when preparing datasets because a model is only as good as the dataset that was used to train it. In that sense, what UiPath® Studio is to RPA workflows, a Document Type session (in Document UnderstandingDocument Understanding^TM Cloud) is to Machine Learning capabilities. Both require some experience to be used effectively.

データ抽出 ML モデルでできること

ML モデルは 1 種類のドキュメントからデータを抽出できますが、複数の異なる言語をカバーすることができます。各フィールド (合計金額、日付など) は、1 つの一貫性のある意味を持つ必要があります。人間にフィールドの正しい値がわからないのであれば、ML モデルでもわからないでしょう。

状況が曖昧なこともあります。たとえば、公共料金請求書は、単なる別の種類の請求書なのでしょうか。それとも、これらは 2 つの異なる ML モデルが必要な 2 つの異なる種類のドキュメントなのでしょうか。抽出する必要のあるフィールドが同じである場合 (同じ意味を持つ場合)、1 つのドキュメントの種類として扱うことができます。ただし、異なる理由 (異なる業務プロセス) で異なるフィールドを抽出する必要がある場合は、それらを 2 つの異なる種類のドキュメントとして扱い、2 つの異なるモデルをトレーニングする必要があります。

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

トレーニング データセットと評価データセット

Document Manager を使用して、次の 2 つの種類のデータセットを作成できます。

• トレーニング データセット
• 評価データセット

どちらの種類のデータセットも、優れたパフォーマンスの ML モデルを構築するのに不可欠であり、モデルを作成およびメンテナンスするための時間と労力が必要です。優れたパフォーマンスの ML モデルを得るには、運用環境のドキュメント トラフィックを代表する評価データセットが必要です。

各種類のデータセットは、異なる方法でラベル付けされます。

• トレーニング データセットの場合は、抽出する必要のあるさまざまな情報を表すページ上の単語の境界ボックスの値が使用されます。
• トレーニング セットをラベル付けするときには、ページ自体と単語のボックスに値を入力します。
• 評価データセットの場合は、サイドバー (通常のフィールドの場合) または上部バー (列フィールドの場合) に表示されるフィールドの値が使用されます。
• 評価セットをラベル付けするときは、サイドバーまたは上部バーにあるフィールド名の下にある値のみに注目します。といっても、手動で入力する必要はありません。ページのボックスを選択してラベル付けし、値が正しいことを確認することをお勧めします。

データ抽出コンポーネント

データ抽出では、以下のコンポーネントを使用します。

• 光学文字認識
• 単語と行の構築
• 文字を単語にグループ化し、単語を左から右方向のテキストの行にグループ化します。
• マシン ラーニング モデルによるページ上の各単語/ボックスの予測
• テキストの範囲のクリーンアップ、解析、書式設定
• たとえば、複数行にわたる単語を住所にグループ化したり、日付を標準の yyyy-mm-dd 形式に書式設定したりします。
• アルゴリズムを適用して、返される値を選択
• ドキュメントが 2 ページ以上で、一部のフィールドが複数のページに表示される場合

信頼度レベル

信頼度レベルとは

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.

信頼度レベルの有効な用途

ビジネス オートメーションには、例外 (オートメーションが正常に機能しない事例) を検出して処理する方法が必要です。従来のオートメーションでは、RPA ワークフローが中断すると、ワークフローが停止またはハングするか、例外がスローされるので、すぐに分かります。そのエラーをキャッチし、状況に応じて処理できます。これに対し、マシン ラーニング モデルは、質の低い予測を行っても例外をスローしません。では、ML モデルが間違いを犯していて、例外処理フローをトリガーする必要がある場合、どのように判断すればよいでしょうか。このためには、人間が手動で関与しなければならないことが多く、多くの場合 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.

ただし、このようなオプションがない状況で、質が低いと思われる予測を検出したい場合もあります。このような場合は、改めて信頼度レベルを利用できます。予測の信頼度レベルが低い場合 (たとえば、0.6 を下回っている場合)、予測が誤っているリスクは、信頼度が 0.95 である場合よりも高くなります。ただし、この相関関係はかなり弱く、低い信頼度で抽出された値であっても正しい場合が数多くあります。また、比較的まれですが、高い信頼度 (0.9 以上) で抽出されているにもかかわらず、値が正しくない可能性もあります。こうした理由から、可能な限りビジネス ルールを利用し、信頼度レベルは最後の手段としてのみ使用することを強くお勧めします。

信頼度の種類

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

信頼度スコアのスケーリング (またはキャリブレーション)

異なるモデルの信頼度レベルは、モデルの設計に応じて異なる方法でスケーリングされます。たとえば、一部のモデルはほぼ常に 0.9-1 の範囲の信頼度レベルを返し、0.8 を下回ることはきわめてまれです。また、信頼度レベルがスケールの高い方に集まっていることが多くても、0 から 1 の間にもっと均等に分散されているモデルもあります。結果的に、モデルが異なれば信頼度のしきい値も異なります。たとえば、OCR の信頼度のしきい値は、ML 抽出器や ML 分類器のしきい値と同じではありません。また、モデルのアーキテクチャに重大な更新があると (生成 AI ベースのモデル アーキテクチャである Helix のリリースで導入される更新など)、信頼度レベルの分布が変わるため、そのたびに信頼度のしきい値を再評価する必要があります。

優れたパフォーマンスの ML モデルを構築する

最適な自動化率 (ドキュメント フローの処理に必要な人月/年で計測した手動作業の削減率) を実現するには、以下の手順を慎重に実行する必要があります。

1. ドキュメントに最適な OCR エンジンを選択する

   これは、OCR 、単語と行の構築 (部分的に OCR に依存)、および下流のすべての機能に影響します。

2. トレーニング用に、バランスのとれた代表的なデータセットを選択する

3. 抽出するフィールドを定義する

4. トレーニング データセットをラベル付けする

5. 抽出器をトレーニングする

6. モデル出力を処理するためのビジネス ルールを定義および実装する

7. (任意) 抽出用の信頼度しきい値を選択する

8. 検証ステーションからのデータを使用してトレーニングする

9. オートメーションをデプロイする

1. OCR エンジンを選択する

OCR エンジンを選択するには、まず異なる Document Manager セッションを作成し、異なる OCR エンジンを設定してから、それぞれに同じファイルをインポートして違いを確認する必要があります。その際、抽出対象の領域に注目します。たとえば、請求書のロゴの一部として表示される会社名を抽出する場合は、どの OCR エンジンがロゴのテキストに対してうまく機能するかを確認する必要があります。

既定のオプションは、Document Understanding ライセンスに無料で含まれている UiPath Document OCR です。ただし、サポート対象外の言語が必要な場合、または非常に読み取りづらいドキュメントが含まれる場合は、より広範な言語に対応した Google Cloud (クラウドのみ) または Microsoft Read (クラウドまたはオンプレミス) を試すことができます。これらのエンジンは高コストとされていますが (実際は低コスト)、業務プロセスで重要ないくつかのデータ フィールドでより精度の高さが求められる場合は、利用可能な最適な OCR を使用することを強くお勧めします。ダウンストリームのすべてのものにかかわってくるため、後々時間の節約になります。

Please be aware that the Digitize Document activity has the ApplyOcrOnPDF setting set to Auto by default, determining if the document requires to apply the OCR algorithm depending on the input document. Avoid missing the extraction of important information (from logos, headers, footers, etc.) by setting the ApplyOcrOnPDF to Yes, making sure that all text is detected, though it might slow down your process.

2. フィールドを定義する

フィールドの定義は、業務プロセス自体を所有する内容領域専門家またはドメイン専門家と話し合いながら行うべきことです。請求書の場合は、買掛金プロセスの所有者です。この話し合いは重要であり、無駄な時間を省くために、ドキュメントをラベル付けする前に行って、20 件以上のランダムに選択したドキュメント サンプルを一緒に確認する必要があります。そのために 1 時間を確保する必要があります。また、データを準備する人が漠然とした状況や極端なケースに遭遇することを考慮して、多くの場合は数日後に繰り返す必要があります。

10 個のフィールド、最終的には 15 個のフィールドを抽出する必要があることを前提として話し合いが開始されることは、珍しいことではありません。

注意すべき主な設定を以下に示します。

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

公共料金請求書の金額

合計金額だけを見ると極めて単純明快かもしれませんが、公共料金請求書にはさまざまな金額が含まれています。合計支払金額が必要な場合もあれば、前の請求期間から繰り越された金額は不要で、現在の請求額のみが必要な場合もあります。後者の場合、現在の請求額と合計金額が同じであっても、異なる方法でラベル付けする必要があります。この 2 つは概念が異なり、金額もたいていは異なります。

注:

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

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

請求書の発注書番号

請求書番号は請求書の 1 つの値として、または各明細項目の請求書番号が異なる、明細項目表の一部として請求書に示すことができます。そのような場合は、[po-no] と [item-po-no] という 2 つの異なるフィールドを持つようにするとよいでしょう。それぞれのフィールドの視覚的および概念的な一貫性を保つことで、モデルのパフォーマンスが向上しやすくなります。ただし、この両方のフィールドがトレーニング データセットと評価データセットで適切に表現されている必要があります。

請求書のベンダー名と支払先住所名

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

テーブルの行

テーブルの行とテキスト行という、留意すべき 2 つの異なる概念があります。テーブルの行には、その同じ行に属するすべての列フィールドのすべての値が含まれます。これらがすべて、ページをまたぐ同じテキスト行の一部であることもあります。別の行に存在することもあります。

テーブルが複数のテキスト行で構成される場合は、「/」ホットキーを使用して、そのテーブルの行のすべての値をグループ化する必要があります。グループ化すると、テーブルの行全体を含む緑のボックスが表示されます。以下に示すテーブルの例では、上の 2 つの行は複数行のテキストで構成され、「/」ホットキーを使用してグループ化する必要があり、3 番目の行は 1 行のテキストで、グループ化する必要がありません。

以下は、各行が 1 行のテキストで構成される表の例です。これらの行は Document Manager によって暗黙的にグループ化されるため、「/」ホットキーを使用してグループ化する必要はありません。

ML 抽出モデルでは、ドキュメントを上から下に読み進める際に、行の終わりと次の行の始まりを識別するのが難しい場合が多々あります。特に、視覚的な水平方向の線によって行が区切られていないフォームなどのドキュメントで問題になります。UiPath が提供する ML パッケージには、表を複数の行に正しく分割するようトレーニングされた特別なモデルがあります。このモデルは、ユーザーが「/」または「Enter」キーを使用してラベル付けした、緑の透明なボックスで表示されるグループを使用してトレーニングされています。

2. トレーニング用に、バランスのとれた代表的なデータセットを選択する

マシン ラーニング技術の主な利点は、多岐にわたる複雑な問題を処理できることです。トレーニング データセットのサイズを予測するときには、まずフィールドの数とその種類、そして言語の数を確認します。中国語/日本語/韓国語以外であれば、1 つのモデルで複数の言語を処理できます。中国語/日本語/韓国語の場合は一般に、別個のトレーニング データセットとモデルが必要になります。

フィールドには次の 3 つの種類があります。

1. Regular fields (date, total amount)
   • 標準フィールドの場合、1 つのフィールドにつき少なくとも 20 件から 50 件のドキュメント サンプルが必要です。したがって、10 個の標準フィールドを抽出する必要がある場合は、少なくとも 200 件から 500 件のドキュメント サンプルが必要になります。20 個の標準フィールドを抽出する必要がある場合は、少なくとも 400 件から 1,000 件のドキュメント サンプルが必要です。必要なドキュメント サンプルの数は、フィールドの数に応じて増加します。フィールドの数が増えると、必要なドキュメント サンプルの数も 20 倍から 50 倍程度増加します。
2. Column fields (item unit price, item quantity)
   • 列フィールドの場合、1 つの列フィールドにつき少なくとも 50 件から 200 件のドキュメント サンプルが必要です。5 個の列フィールドの場合は、シンプルで整ったレイアウトであれば、300 件のドキュメント サンプルで十分な結果が得られるでしょう。一方で、非常に複雑で多様性の高いレイアウトの場合、1,000 件を超えるドキュメント サンプルが必要になる場合があります。複数の言語に対応できるようにするには、さまざまな種類のフィールドをすべてカバーしているドキュメント サンプルが 1 つの言語につき少なくとも 200 件から 300 件必要です。したがって、2 種類の言語で 10 個のヘッダー フィールドと 4 個の列フィールドを処理する場合は 600 件のドキュメント サンプル (列とヘッダーに 400 件、2 つ目の言語に 200 件) で十分と考えられますが、場合によっては 1,200 件以上のドキュメント サンプルが必要になることがあります。
3. Classification fields (currency)
   • 分類フィールドの場合、一般に各クラス 10 件から 20 件以上のドキュメント サンプルが必要です。

このガイドラインでは、数十種類から数千種類のレイアウトがある請求書や発注書のような、レイアウトが多岐にわたるドキュメントを処理することを想定しています。レイアウトの種類が極めて少ない (5 種類から 10 種類未満) 納税申告書や請求書のような多様性の低いシナリオの場合は、データセットのサイズはレイアウトの数によって決定されます。このような場合は、1 種類のレイアウトにつき 20 ページから 30 ページから始めて、必要に応じて (特にページ内のテキストの密度が非常に高く、抽出するフィールド数が多い場合は) ページを追加します。たとえば、2 種類のレイアウトから 10 個のフィールドを抽出するモデルを作成する場合は 60 ページが必要ですが、2 種類のレイアウトから 50 個または 100 個のフィールドを抽出する必要がある場合は、まず 100 ページまたは 200 ページから開始して、必要な精度が得られるまでページを追加します。この場合、標準フィールドと列フィールドの違いは重要ではありません。

重要:

マシン ラーニング テクノロジは多岐にわたるシナリオに対応するために設計されています。多様性の低いシナリオ (1 から 10 種類のレイアウト) でモデルをトレーニングする場合は、OCR で読み取ったテキストのわずかな変化に敏感に反応する不安定なモデルにならないように特別な注意が必要です。このようなモデルを回避するには、ドキュメントを一度印刷した後に携帯電話のスキャナー アプリでスキャンまたは撮影します。このように意図的に多少の変化をつけたドキュメントをトレーニングに使用するようにします。わずかな歪みまたは解像度の変化により、モデルがより堅牢になります。

これらの推定値では、ほとんどのページに対象のフィールドがすべてまたはほぼすべて含まれていることを想定しています。たとえば、複数ページのドキュメントでほぼすべてのフィールドが 1 ページに存在する場合、考慮すべきページの数は、ほぼすべてのフィールドが含まれているその 1 ページとなります。

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

ディープ ラーニング モデルの汎化能力

トレーニング セット内にすべてのレイアウトが含まれているようにする必要はありません。実際、運用環境のドキュメント フローに含まれるレイアウトの大半は、ドキュメント サンプルがトレーニング セットには含まれていないか、含まれていても 1 つか 2 つだけの場合があります。これは良いことです。というのも、ここでユーザーが望んでいるのは AI によるドキュメントの理解力を活用して、トレーニング時に使用されていないドキュメントでも正しい予測が実行されるようにすることだからです。レイアウトのサンプルがトレーニング セットにまったく含まれていない、または 1 つか 2 つしか含まれていなくても、モデルは他のレイアウトからの学習結果に基づいて正しく予測できるため、レイアウトごとにドキュメント サンプルを多数用意する必要はありません。

すぐに使えるモデルをトレーニングする

Document Understanding の ML モデルをトレーニングする場合、主に以下の 3 種類のシナリオがあります。

• AI Center の DocumentUnderstanding ML パッケージを使用して、新しいドキュメントの種類でゼロからトレーニングする
• 精度を最適化するため、事前トレーニング済みのすぐに使えるモデルを再トレーニングする
• 精度を最適化して新しいフィールドを追加するため、事前トレーニング済みのすぐに使えるモデルを再トレーニングする

1 つ目のシナリオで行うデータセットのサイズの予測については、このセクション「トレーニング データセットを作成する」の冒頭で説明しています。

2 つ目のシナリオの場合、データセットのサイズは、事前トレーニングされたモデルが対象のドキュメントをどの程度正確に処理できるかによって決まります。非常に正確に処理できる場合は、50 ページから 100 ページなど、ごく少量のデータしか必要ないかもしれません。複数の重要なフィールドが正確に処理されない場合はページ数を増やさなければならない可能性がありますが、それでもゼロからトレーニングする場合と比べると 4 分の 1 の量で開始できます。

3 つ目のシナリオの場合、2 つ目のシナリオのデータセットのサイズで開始して、追加する新しいフィールドの数に応じてデータセットを増やします。ゼロからトレーニングする場合と同じガイダンス (新しい標準フィールドあたり最低 20 ページから 50 ページ、列フィールドあたり最低 50 ページから 200 ページ) を使用します。

これらのケースでは、すぐに使えるモデルで認識されない新しいフィールドと認識される元のフィールドを含め、すべてのドキュメントを完全にラベル付けする必要があります。

フィールドの不規則な出現

どのドキュメントにも出現するフィールドもあれば (日付、請求書番号など)、10% 程度のページにしか出現しないフィールドもあります (取扱手数料、割引など)。これらのケースでは、ビジネス上の意思決定を下す必要があります。実行するオートメーションにおいてこれらのめったに出現しないフィールドが重要でない場合は、その特定のフィールドのドキュメント サンプル (そのフィールドの値を含むページ) を少量 (10 件から 15 件) に抑えることができます。それらのフィールドが重要な場合は、フィールドの多様性に対応できるように、トレーニング セットにそのフィールドのドキュメント サンプルを少なくとも 30 件から 50 件含める必要があります。

バランスのとれたデータセット

請求書の場合、データセットにベンダー 100 社分の請求書が含まれていても、そのうちの半数が単一のベンダーの請求書である場合、そのデータセットは非常にバランスが悪いデータセットであると言えます。完璧なバランスのデータセットには、各ベンダーの請求書が均等に含まれます。データセットのバランスを完璧にする必要はありませんが、単一のベンダーの請求書の占める割合がデータセット全体の 20% を超えないようにする必要があります。この割合を超えるとデータを増やしても役に立ちません。さらに、モデルが 1 つのベンダーに対して過度に最適化 (過剰適合) されるため、他のベンダーの請求書の処理精度に影響を与えることもあります。

代表的なデータセット

Data should be chosen to cover the diversity of the documents likely to be seen in the production workflow. For example, if you get invoices in English but some of them come from the US, India and Australia, they probably look different, so you need to make sure you have document samples from all three. This is relevant not only for the model training itself, but also for labeling purposes. When you label the documents you might discover that you need to extract new, different fields from some of these regions, like GSTIN code from India, or ABN code from Australia. Check the Define fields section for more information.

4. トレーニング データセットをラベル付けする

トレーニング データをラベル付けする際は、Document Manager のドキュメント ペインにある単語の境界ボックスに注目する必要があります。右側または上部のサイドバーにある解析値はトレーニングには使用されないため、重要ではありません。

フィールドが 1 つのページに複数回出現する場合、それらが同じ概念を表すかぎり、すべてのフィールドをラベル付けする必要があります。

OCR が単語を認識できなかったり、いくつかの文字を正しく認識できなかったりした場合は、境界ボックスがあれば境界ボックスをラベル付けし、なければそのまま続行します。なお、Document Manager に単語を追加することはありません。たとえ追加したとしても、実行時にはその単語が存在しないため、モデルの役には立ちません。

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

5. 抽出器をトレーニングする

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

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

この Excel ファイルでは、どの予測がどのファイルで失敗しているかを確認できます。また、それが OCR エラーなのか、それともマシン ラーニングの抽出または解析エラーなのか、RPA ワークフロー内の単純なロジックによって修正可能なのか、それとも異なる OCR エンジン、追加のトレーニング データ、あるいは Document Manager でのラベル付けまたはフィールド設定の改善が必要なのかもわかります。

この Excel ファイルは、よくある間違いを見つけて Action Center の検証ステーションで手動によるレビューを行えるようにするために、RPA ワークフローに適用する必要のある、最も関連性の高いビジネス ルールを特定する場合にも非常に役立ちます。ビジネス ルールは、最も信頼性の高いエラー検出方法です。

ビジネス ルールで発見できないエラーについては、信頼度レベルを使用することもできます。Excel ファイルには、各予測の信頼度レベルも記述されているので、並べ替えやフィルター処理のような Excel 機能を使用して、ビジネス シナリオにとっての適切な信頼度のしきい値を判断できます。

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

重要:

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

6. ビジネス ルールを定義および実装する

このステップでは、モデルのエラーおよびそれらのエラーの検出方法について説明します。主なエラー検出方法は 2 つあります。

• ビジネス ルールの適用
• through applying lookups in Systems of Record in the customer organization
• 最小の信頼度レベルのしきい値を設定

最も効果的で信頼性の高いエラーの検出方法は、ビジネス ルールと検索情報を定義することです。信頼度レベルは 100% 完全ではありません。信頼性が低くても正確な予測もありますし、信頼性が高くても間違った予測もあります。その確率は決して高くはなくても、ゼロではありません。さらに、最も重要なことは、欠落しているフィールドには信頼性がないため、信頼度のしきい値ではエラーを発見できず、フィールドがまったく抽出されないことでしょう。したがって、信頼度レベルのしきい値は予備的な手段、安全策としてのみ使用する必要があります。ビジネスに致命的な影響を及ぼすエラーを検出するための主な方法としては使用できません。

ビジネス ルールの例:

• 正味金額と税額の合計が合計金額に等しいこと
• 合計金額が正味金額以上であること
• 請求書番号、日付、合計金額 (およびその他のフィールド) が存在すること
• 請求書番号 (存在する場合) が PO データベースに存在すること
• 請求日が過去の日付であり、X か月を超えていないこと
• 期限日が将来の日付であり、Y 日/か月を超えていないこと
• 各明細項目について、数量と単価の積が明細金額と等しいこと
• 明細金額の合計が正味金額または合計金額と等しいこと
• その他

注:

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

特に、列フィールドの信頼度レベルはエラー検出メカニズムとして使用すべきではありません。列フィールド (請求書または PO の明細項目など) には何十個もの値が含まれる可能性があり、中には信頼度が低い値もあると考えられます。そのため、最小しきい値を設定する値が多すぎると、ほとんどすべてのドキュメントが、本来は不要なはずの人間による検証ステップに送られてしまいます。

ビジネス ルールは、RPA ワークフローの一部として適用する必要があります。ビジネス ルールの失敗を人間が検証するようにして注意を喚起し、プロセスを迅速化します。

注:

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

7. (任意) 信頼度しきい値を選択する

ビジネス ルールを定義した後に、ビジネス ルールが存在しない、または定義されたビジネス ルールではすべてのエラーをキャッチできない可能性が高いフィールドがわずかに残ることがあります。これらのフィールドのために、最後の手段として信頼度しきい値を使用しなければならない可能性があります。

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

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

8. 検証ステーションからのデータを使用して微調整する

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.

2 つ目に重要なのは、検証ステーションのデータの方が、Document Manager でラベル付けされたデータよりも情報の密度が低いということです。基本的に、検証ステーションのユーザーは、正しい値を一度取得できさえすればよいと思っています。たとえば 5 ページの請求書があり、すべてのページに請求書番号が記載されている場合、検証ステーションのユーザーは 1 ページ目の番号のみを検証します。したがって、値の 8 割がラベル付けされないままになります。一方で、Document Manager ではすべての値がラベル付けされます。

最後に覚えておいてほしいのは、手動でラベル付けした元のデータセットに検証ステーションのデータを追加する必要があることです。これにより、時間の経過とともにサイズが増大する単一のトレーニング データセットを常に得られます。0 (ゼロ) マイナー バージョン (UiPath がリリースした、すぐに使えるバージョン) の ML パッケージでトレーニングを実施することが必要です。

重要:

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

検証ステーションのデータの使用に関する注意事項

検証ステーションのデータは運用環境のワークフローで使用されるため、データの量がはるかに増える可能性があります。前述の情報密度の問題によってモデルの品質が低下する可能性があるため、評価ステーションのデータでデータセットが埋め尽くされないようにした方がよいでしょう。

追加するページ数は Document Manager のデータの最大 2 倍から 3 倍に留めることをお勧めします。そのページ数を超えたら、大きな失敗が生じているベンダーまたはサンプルのみを選択します。運用環境のデータに、新しい言語や業務プロセスへの新しい地理的地域の追加 (米国から欧州または南アジアへの展開) などの既知の大きな変更がある場合は、それらの言語や地域の代表的なデータを Document Manager に追加して手動でラベル付けする必要があります。検証ステーションのデータは、そのような主要なスコープの拡張には適していません。

検証ステーションのデータに関するもう 1 つの潜在的な問題は、バランスです。運用環境では、トラフィックの大部分が少数のベンダー/顧客/世界リージョンから流れてくるのが一般的です。このようなデータをトレーニング セットにそのまま追加すると、強いバイアスがかかったモデルが生じる場合があります。その場合、一部のデータに対しては十分なパフォーマンスが得られるものの、残りのデータの大部分に対してはパフォーマンスが不十分になります。したがって、検証ステーションのデータをトレーニング セットに追加する際は特に注意することが大切です。

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

9. オートメーションをデプロイする

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