Document Understanding

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

マシンラーニングモデルは、コンピューターコードで表される明示的なロジックではなく、トレーニングデータによって定義されます。このため、データセットを準備するときは、十分に注意を払う必要があります。モデルの良し悪しはトレーニングに使用されるデータセットによって決まるからです。その意味では、RPA ワークフローにとっての UiPath Studio が、マシンラーニング機能にとっての (クラウド版 Document Understanding の) ドキュメントの種類のセッションであり、どちらも効果的に使用するにはある程度の経験が必要です。

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

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

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

確信が持てない場合は、単一のモデルのトレーニングから始めます。ドキュメントを Document Manager の別々のバッチ (Document Manager ビューの上部中央にある [フィルター] ドロップダウンを参照) に保持し、必要に応じて後から簡単に区別できるようにしておきます。そうすれば、ラベル付けの作業内容が失われることはありません。ML モデルの場合、データが多いほど優れたパフォーマンスを得られます。そのため、十分なデータを持つ単一のモデルから始めるとよいでしょう。

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

Document Manager を使用して、トレーニングデータセットと評価データセットの 2 つの種類のデータセットを構築できます。

評価データセットは、データサイエンティストが使用するため、または詳細なトラブルシューティングを行って特定の問題を再現するために使用します。ただし、エンタープライズの自動化シナリオの大半では、トレーニングデータセットのみが必要であり、推奨されます。トレーニングパイプラインでは、以下のような完全なスコアリングの成果物が返されるようになりました。

モデルの全体的な精度 – これは、Document Understanding 抽出器の詳細と AI Center の成果物フォルダー (Document Understanding からもアクセス可能) の両方に表示されるメインスコアとして使用されます。
モデルの総合スコアとフィールドレベルの F1 スコア – これは、歴史的な理由により、AI Center の成果物フォルダー (Document Understanding からもアクセス可能) で提供されます。
フィールドごとおよびバッチごとの詳細なメトリックと、パフォーマンスを横並びで比較した結果が含まれる Excel ファイル。このファイルは AI Center の成果物フォルダー (Document Understanding からもアクセス可能) 内にあります。

トレーニングの一部としてモデルをスコアリングできます。トレーニングセットはトレーニングデータと検証データの間で 80%/20% にランダムに自動分割され、スコアは検証データに対して計算されるためです。

データセットが大きくなるにつれて、トレーニングデータと検証データ両方の分割が変化します。つまり、(データサイエンティストにとって興味がある) スコアの経時的な変化を直接比較してみることはできません。ただし、スコアには最新のデータに対するモデルのパフォーマンスが反映されるため、(業務プロセスオーナーにとって興味がある) 現在の運用データに対する現在のモデルのパフォーマンスがより正確に表されます。

この方法には以下のメリットがあります。

以前のデータ (数年前のものである可能性もある) で測定されたスコアを参照してしまう恐れがなくなる。
必要なラベル付けの量が減る。
ラベル付けするすべてのデータが実際にモデルの改善に貢献し、パフォーマンスの向上に役立つ。

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

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

光学文字認識
OCR の後処理
- 単語と行の構築
- 文字を単語にグループ化し、単語をテキストの行にグループ化します。
マシンラーニングモデルによるページ上の各単語/ボックスの予測
データの正規化
- たとえば、複数行にわたる単語を住所にグループ化したり、日付を標準の yyyy-mm-dd 形式に書式設定したりします。
値の選択
- 一部のフィールドが複数のページに表示される 2 ページ以上のドキュメントの場合に、アルゴリズムを適用して、特定の値の複数のインスタンスのうち実際にどのインスタンスを返すかを選択します。

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

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

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

これは、OCR 、単語と行の構築 (部分的に OCR に依存)、および下流のすべての機能に影響します。
トレーニング用に、バランスのとれた代表的なデータセットを選択する
抽出するフィールドを定義する
トレーニングデータセットをラベル付けする
抽出器をトレーニングする
モデル出力を処理するためのビジネスルールを定義および実装する
(任意) 抽出用の信頼度しきい値を選択する
検証ステーションからのデータを使用してトレーニングする
オートメーションをデプロイする

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

既定のオプションは、UiPath Document OCR (ヨーロッパラテン語ベースの言語の場合)、または UiPath Chinese-Japanese-Korean OCR です。キリル文字、デーヴァナーガリー文字、タイ語、ベトナム語、アラビア語、ヘブライ語、ペルシャ語などの他の言語を処理する必要がある場合は、Microsoft Azure Read OCR (クラウドのみ)、Google Cloud Vision OCR (クラウドのみ)、または Omnipage OCR (Studio のアクティビティパッケージ) を使用できます。さまざまな OCR エンジンを使用し、いくつかの異なる Document Manager セッションを作成して、お使いのドキュメントに最適なパフォーマンスを確認してください。プロジェクトで後から OCR エンジンを変更すると、コストがかかる場合があります。

[ドキュメントをデジタル化] アクティビティでは、[PDF に OCR を適用] が既定で [自動] に設定されていることに注意してください。つまり、.pdf ドキュメントを操作している場合、既定ではデジタル化の際に .pdf 自体とロゴなどの OCR 画像のみからできるだけ多くのテキストをスクレイピングして、結果を結合しようとします。

ただし、.pdf ドキュメントが破損していたり、通常とは異なる形式だったりすると、抽出テキストにエラーが発生することがあります。その場合は、[PDF に OCR を適用] を [はい] に設定します。

UiPath Document OCR を使用してすべての .pdf ドキュメントに OCR を適用するもう 1 つのメリットは、UiPath Document OCR が、フォームなどのドキュメントの重要な要素であるチェックボックスを認識することです。ただし、すべてに OCR を適用すると、デジタル化の速度が多少低下します。

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

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

10 個のフィールド、最終的には 15 個のフィールドを抽出する必要があることを前提として話し合いが開始されることは、珍しいことではありません。以下のサブセクションで、いくつか例を示します。

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

コンテンツの種類
これは、値の後処理を決定する最も重要な設定です。特に日付 (形式が米国スタイルかそれ以外のスタイルかを検出して、yyyy-mm-dd に書式設定します) および数値 (小数点区切り (コンマまたはピリオド) を検出します) にとって重要です。[ID 番号] は、コロンまたはハッシュ記号の前にあるものをすべてクリーンアップします。コンテンツの種類が [文字列] の場合はクリーンアップを実行せず、RPA ワークフローで独自の解析を行う場合に使用できます。
[複数行] チェックボックス
複数行のテキストとして表示される可能性のある、住所などの文字列を解析します。
複数値チェックボックス
これは、複数選択フィールド、または複数の値を持つ場合があるが表の列としては表示されないフィールドを処理するための設定です。たとえば、政府機関のフォームの民族グループに関する質問に、当てはまるすべての項目を選択できる複数のチェックボックスが設けられていることがあります。
非表示のフィールド
[非表示] とマークされたフィールドをラベル付けすることはできますが、これらのフィールドはデータのエクスポートには含まれないため、モデルのトレーニングはこれらのフィールドについては行えません。この設定は、フィールドのラベル付けが進行中の場合、フィールドが非常にまれにしか発生しない場合、またはフィールドの優先度が低い場合に便利です。
スコアリング
これは、評価パイプラインにのみ関係があり、精度スコアの計算方法に影響します。レーベンシュタイン スコアリングを使用するフィールドは許容性が高く、10 文字中 1 文字が間違っている場合のスコアは 0.9 になります。ただし、スコアリングが完全一致の場合はより厳格になり、1 文字間違っているとスコアはゼロになります。種類が文字列のフィールドにのみ、既定でレーベンシュタインスコアリングを選択するオプションがあります。

公共料金請求書の金額

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

注: 各フィールドは異なる概念を表していて、混乱が生じないように、できるかぎり明確かつ簡潔に定義されている必要があります。人間が混乱するのであれば、ML モデルも混乱します。

さらに、現在の請求額が複数の異なる金額、手数料、税金で構成され、それらが請求書に個別には示されていないことがあります。この問題を解決するには、[previous-charges] と [total] という 2 つのフィールドを作成します。これら 2 つは常に、公共料金請求書に別々の値として明確に示されます。これにより、この 2 つの差異として現在の請求額を取得できます。現在の請求額がドキュメントに明示的に示される場合、整合性チェックを行えるようにするために、3 つのフィールド ([previous-charges]、[total]、[current-charges]) をすべて含めることもできます。そのため、場合によっては 1 つから 3 つのフィールドを含めることができます。

請求書の発注書番号

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

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

会社名は通常、請求書または公共料金請求書の上部に示されますが、ロゴしかなく、会社名が明記されていないため、わかりにくいことがあります。テキスト上にスタンプや手書き文字やしわがあることもあります。そのような場合、給与明細や公共料金請求書の「支払先」セクションの右下にある名前がラベル付けされる可能性があります。この名前はたいていは同じですが、概念が異なるため、常に同じとは限りません。ドキュメント上ではまったく関係のない会社のように見える、他の親会社や持株会社あるいは関連会社に支払いが行われることがあり、その結果、モデルのパフォーマンスが低下する可能性があります。そのような場合は、[vendor-name] と [payment-addr-name] という 2 つのフィールドを作成する必要があります。これにより、ベンダーのデータベースでその 2 つのフィールドを検索して、一致した方を使用するか、[vendor-name] がない場合は [payment-addr-name] を使用できます。

テーブルの行

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

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

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

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

3. トレーニングデータセットを作成する

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

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

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

データセットのサイズの推奨範囲は、計算機能のタブで入力した情報に基づいています。標準フィールドがほとんどなく、ドキュメントのレイアウトが明確である単純なシナリオでは、オレンジ色の範囲の下限に近い数のデータセットで適切な結果が得られる可能性があります。複雑なシナリオ、特に列が多い複雑な表の場合は、適切な結果を得るのに、オレンジ色または緑色の範囲の数のデータセットが必要になる可能性があります。

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

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

上記の数値は厳密な要件ではなく、一般的なガイドラインです。基本的には、小さいデータセットから開始して、適切な精度が得られるまでデータを追加し続けます。これは、RPA 作業をモデルの構築と並行する場合に特に便利です。また、モデルの最初のバージョンを使用して追加のデータに事前ラベル付けすることができるため (Document Manager の [設定] ビューと [予測] ボタンを参照)、追加のトレーニングデータに素早くラベル付けできます。

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

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

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

一般的な状況として、次のような請求書のデータ抽出のシナリオが考えられます。UiPath が提供する、事前トレーニングされたすぐに使える Invoices (請求書) モデルで認識されるフィールドに加えて、認識されない 2 つの標準フィールドと 1 つの列フィールドがある場合です。このような状況では、通常、すべてのフィールドをゼロからトレーニングした場合と比べると、必要なデータセットのサイズは大幅に小さくなります。必要なデータセットのサイズの推定値は、Document Understanding Cloud でドキュメントの種類を作成するときに、データセット診断ビューで確認できます。ただし、モデルのトレーニングに使用するドキュメントがどのようなものであっても、すぐに使えるモデルで認識されない新しいフィールドと、すぐに使えるモデルで認識される元からあるフィールドのどちらも、完全にラベル付けする必要があることに注意してください。

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

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

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

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

代表的なデータセット

データは、運用環境のワークフローで生じる可能性のあるドキュメントの多様性に対応できるよう選択する必要があります。たとえば、英語の請求書を入手する場合、その一部が米国、インド、オーストラリアからのものであるときには、見た目が異なってくることがあるため、3 つすべてのサンプルを含めるようにする必要があります。これは、モデルのトレーニング自体だけでなく、ラベル付けにも関係することです。ドキュメントをラベル付けするときに、これらの一部の地域から新規の異なるフィールドを抽出しなければならなくなることがあるからです (インドの GSTIN コードやオーストラリアの ABN コードなど)。

トレーニング/検証の分割

トレーニングデータセットは、背後でトレーニングセット (ランダムに選択された 80%) と検証セット (ランダムに選択された 20%) に自動的に分割されます。ディープラーニングモデルのトレーニング時に、トレーニングセットはバックプロパゲーション、すなわち実際にネットワーク内のノードの重みを変更する部分で使用されますが、検証セットはトレーニングを停止するタイミングを知るためにのみ使用されます。つまり、トレーニングセットの過学習を防ぐために使用されます。

トレーニングの実行終了時に完全な評価スコアを取得する方法として、検証セットのスコアが返されます。検証セットは技術的にはネットワークのトレーニングには使用されず、過学習を防ぐためにのみ使用されます。ただし、このセットはデータセット全体からランダムに選択された 20% であるため、トレーニングセットに同様に分布される傾向があります。こうした一貫性があるのは良いことです。取得したスコアが、モデルがデータから学習する能力を反映していることになるからです。通常、私たちが気にするのはこの点です。モデルが学習不可能な場合は、データに整合性がない、またはモデルに制限があることを意味するため、モデルのトレーニング時にはそれらをすぐに把握することが重要です。

この方法のデメリットは、データセットのサイズが大きくなるにつれ、スコアを必ずしも同一条件で正確に比較できなくなることです。また、スコアにはモデルの汎化能力が反映されず、学習能力のみが反映されます。ただし、同一条件での比較や汎化能力の測定はデータサイエンスの領域における技術的な懸念事項であり、ほとんどのオートメーションにおいて、業績や ROI への影響は間接的にしかありません。

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

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

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

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

ラベル付けするときには、意味/概念が複数ある、または重複するフィールドに注意してください。1 つのフィールドを 2 つの異なるフィールド、または明らかに不要なフィールドに分割しなければならない場合に備えてラベル付けしておくと、RPA ワークフローでの検証や自己整合性チェックロジックに役立ちます。その代表的な例は、請求書の明細項目の数量、単価、明細金額です。明細金額は数量と単価を掛けたものですが、これは信頼レベルを必要とせずに整合性をチェックするために非常に便利です。

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

抽出器を作成するには、Document Understanding の [抽出器] ビューに移動し、右上にある [抽出器を作成] ボタンをクリックします。その後、使用するドキュメントの種類、ML モデル、およびバージョンを選択できます。進行状況は、[抽出器] タブ、または抽出器の [詳細] ビューで確認できます。[詳細] ビューには AI Center パイプラインへのリンクがあり、リンク先では詳細ログをリアルタイムで確認できます。

ML モデルを評価するときに最も強力なツールは、AI Center のパイプラインの [詳細] ビューにある artifacts/eval_metrics フォルダーに生成される evaluation_<package name>.xlsx ファイルです。1 枚目のシートでは、詳細な精度スコアレポートを確認できます。レポートには、全体的なスコアに加えてフィールドごとやバッチごとのスコアも含まれています。

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

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

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

全体的に見て、AI オートメーションから最良の成果を得るために重視すべき主要なリソースが、evaluation_<package_name>.xlsx という Excel ファイルです。

重要: GPU トレーニングは、サイズの大きいデータセットや運用環境のデータセットに強く推奨されます。CPU トレーニングは、GPU よりもかなり低速であり、デモやテストを目的としたサイズの小さいデータセットに控えめに使用してください。詳しくは、「トレーニングパイプライン」のページをご覧ください。

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

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

ビジネスルールの適用
顧客組織の Systems of Record にルックアップを適用する
最小の信頼度レベルのしきい値を設定

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

ビジネスルールの例:

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

注: 数値の場合、小数点以下 8 桁に四捨五入されます。

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

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

注: ビジネスルールを定義する場合、[次で始まる]、[次で終わる]、[次を含む] の値では大文字と小文字が区別されることに注意してください。

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

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

このしきい値を設定するための主要なツールが Excel スプレッドシートです。このスプレッドシートは、トレーニングパイプラインによって [出力] > [artifacts] > [eval_metrics] フォルダー内に出力されます。

この evaluation_<package name>.xlsx ファイルには、各フィールドに対応する列と各予測の信頼度レベルに対応する列が含まれています。信頼度列に基づいて表を並べ替えることによって、特定のフィールドのエラーの発生場所を確認できます。また、そのレベルを超えるしきい値を設定することで、正しく抽出されたドキュメントだけを直接送信できます。

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

検証ステーションのデータはモデル予測の改善に役立ちますが、多くの場合、ほとんどのエラーの原因はモデル自体によるものではなく、OCR、ラベル付けの誤りまたは不整合、あるいは後処理の問題 (日付や数値の書式設定など) によるものです。したがって、1 つ目に重要なのは、優れた精度を確保するために、他のデータ抽出コンポーネントを検証・最適化した後にのみ検証ステーションのデータを使用すべきだということです。そうすれば、改善が必要になるのはモデル予測自体のみとなります。

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

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

重要: 検証ステーションのデータの正しい使用方法は、前のモデルバージョンを繰り返しトレーニングすることだと誤解されていることがよくあります。X.2 を取得するために、現在のバッチを使用してパッケージ X.1 をトレーニングしているのです。そして次のバッチを使用して X.2 のトレーニングを行い、X.3 を取得します (以降同様)。これは、製品の使用方法として間違っています。検証ステーションの各バッチは、最初に手動でラベル付けしたデータと同じ Document Manager セッションにインポートして、さらに大きなデータセットを作成する必要があります。そして、そのデータセットを使用して、常に ML パッケージバージョン X.0 をトレーニングする必要があります。

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

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

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

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

例えば、次のようなシナリオを考えてみましょう。優れた OCR エンジンを選択し Document Manager で 500 個のドキュメントにラベル付けをした結果、モデルのパフォーマンスが向上したため、このモデルを運用中の RPA ワークフローにデプロイしたとします。すると、検証ステーションがデータを生成し始めます。検証ステーションから最大 1000 から 1500 ページをランダムに選択し、最初の 500 ページとともに Document Manager にインポートして、ML モデルを再度トレーニングする必要があります。トレーニングが完了したら、モデルが実際に向上したかどうかについて evaluation_<package name>.xlsx を注意深く確認してから、この新しいモデルを運用環境にデプロイする必要があります。