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

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

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

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

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

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

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

Data Manager を使用して、トレーニング データセットと評価データセットという 2 つの種類のデータセットを作成できます。どちらも、優れたパフォーマンスの ML モデルを構築するのに不可欠であり、両方のモデルを作成およびメンテナンスするための時間と労力を確保する必要があります。運用ドキュメント トラフィックを表す評価データセットなしで、優れたパフォーマンスの ML モデルを実現することはできません。

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

• トレーニング データセットの場合は、抽出する必要のあるさまざまな情報を表すページ上の単語の境界ボックスの値のみが使用されます。

  トレーニング セットをラベル付けするときは、ページ自体と単語ボックスにのみ注目します。

• 評価データセットの場合は、サイドバー (通常のフィールドの場合) または上部バー (列フィールドの場合) に表示されるフィールドの値のみが使用されます。

  評価セットをラベル付けするときは、サイドバーまたは上部バーにあるフィールド名の下にある値のみに注目します。といっても、値を手動で入力する必要はありません。手動入力は入力ミスにつながるため、ページ上のボックスをクリックしてラベル付けすることが推奨されます。ただし、値が正しいことを必ず確認してください。

適切な評価を行う方法の詳細については、以下をご覧ください。

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

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

• 光学文字認識

• 単語と行の構築

  文字を単語にグループ化し、単語を左から右方向のテキストの行にグループ化します。

• マシン ラーニング モデルによるページ上の各単語/ボックスの予測

• テキストの範囲のクリーンアップ、解析、書式設定

  たとえば、複数行にわたる単語を住所にグループ化したり、日付を標準の yyyy-mm-dd 形式に書式設定したりします。

• アルゴリズムを適用して、返される値を選択

  ドキュメントが 2 ページ以上で、一部のフィールドが複数のページに表示される場合

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

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

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

注: これは、OCR および単語と行の構築 (部分的に OCR に依存) の両方に影響します。むろん、ダウンストリームにも影響します。

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

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

[ドキュメントをデジタル化] アクティビティで [OCR を強制適用] 設定が既定で [False] に設定されていることに注意してください。これは、.pdf ドキュメントを操作するときに、既定では OCR エンジンはまったく使用されず、ネイティブ .pdf ドキュメントの場合は、テキストが .pdf ドキュメント自体から直接抽出されることを意味します。ただし、多くのネイティブ .pdf ドキュメントにはロゴやヘッダー/フッターが含まれていますが、それらは抽出されません。ロゴやヘッダー/フッターには、会社名、所在地、VAT コードや支払い情報など、業務プロセスとの関連性が高い、会社に関する詳細情報が含まれることがあります。プロセスがこのような状況にある場合は、プロセスの速度が低下する可能性がありますが、[OCR を強制適用] を [True] に設定して、すべてのテキストが検出されるようにします。

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

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

フィールドには次の 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 件以上のサンプルが必要です。

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

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

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

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

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

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

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

請求書からデータを抽出する際に、すぐに使える請求書モデルでは認識されない標準フィールドが 2 つ、列フィールドが 1 つ含まれている、というような状況がよく発生します。このような場合に必要なのは、新しい標準フィールドあたり 50 個のサンプルと新しい列フィールドあたり 100 個のサンプルが含まれるトレーニング セットです。そのため、200 ページから始めるとよいでしょう。大抵の場合は、既定のモデルを使用することで、すべてのフィールドをゼロからトレーニングするよりもはるかに小規模なデータセットで済ませることができます。

この 200 ページは、すぐに使えるモデルで認識されない新しいフィールドとすぐに使えるモデルで認識される元々のフィールドを含めて、完全にラベル付けする必要があります。

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

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

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

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

代表的なデータセット

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

3. 評価データセットを作成する

トレーニング セットの場合はページとページ数が最も重要ですが、評価セットの場合はドキュメントとドキュメント数のみが重要です。v2021.10 のリリース以降、スコアはドキュメントごとに計算されるからです。

評価データセットのサイズは小さくても構いません。50 個から 100 個のドキュメント (多様性の低いシナリオでは 30 個から 50 個) で開始して、後から数百個に増やすことができます。ただし、評価データセットは運用環境のデータ フローを表すものであることが重要です。そのため、RPA ワークフローで処理されるドキュメントからランダムに選択することが推奨されます。一部のベンダーが大きな比率を占めていてもかまいません。たとえば、1 つのベンダーの請求書が請求書トラフィックの 20% を占める場合、そのベンダーの請求書が評価セットの 20% を占めていても構いません。これは、評価メトリックをビジネス メトリックに近似させるためです (ドキュメントの手動処理にかかる人月費用の削減)。

評価データを Data Manager にインポートする際は、[インポート] ダイアログ ウィンドウで [これを評価セットにする] ボックスをオンにする必要があります。これにより、トレーニング時にそのデータが除外されるようになります。また、Data Manager の [フィルター] ドロップダウンの評価セット オプションを使用して、評価を実行する際にデータを簡単にエクスポートできます。

重要: Automation Cloud での v21.9 (プレビュー版) のリリースおよびオンプレミス版の v21.10 (一般提供) のリリースより、Data Manager はドキュメントの各ページを個別のエンティティとして処理するのではなく、複数ページの単一のドキュメントとして処理するようになりました。この大幅な変更は、主に評価機能の向上を目的として行われました。プロセスの実行時、複数ページのドキュメントは個別のページとしてではなく、単一のドキュメントとして処理されます。評価はこのプロセスを反映している必要があります。v21.10 以降の ML パッケージでこの機能を活用するには、[エクスポート] ダイアログの [後方互換性のあるエクスポート] ボックスのチェックをオフにしておく必要があります。このボックスをオンにすると、データセットは以前のようにページ単位でエクスポートされ、評価スコアは実行時のパフォーマンスを反映しません。

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

フィールドの定義は、業務プロセス自体を所有する内容領域専門家またはドメイン専門家と話し合いながら行うべきことです。請求書の場合は、買掛金プロセスの所有者です。この話し合いは重要であり、無駄な時間を省くために、ドキュメントをラベル付けする前に行って、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 行のテキストで構成されるテーブルの例を示します。これらの行を「/」ホットキーを使用してグループ化する必要はありません。Data Manager によって暗黙的にグループ化されるためです。

項目を分割

[項目を分割] は [列] フィールドに対してのみ表示される設定で、明細項目がどこで終わって他の項目がどこで始まるのかをモデルが認識するのに役立ちます。人間がドキュメントを見るときに、どれだけの行があるかを把握するにはたいてい、右側に金額がいくつ示されているかを見ます。各金額は一般に、明細項目を示しています。つまり、明細金額が [項目を分割] を有効化すべき列であることになります。OCR が明細金額を読み取れなかった場合、またはモデルが明細金額を認識しなかった場合には、他の列もマークできます。数量と単価も通常、「項目を分割」としてマークされます。

5. フィールドを設定する

文字列を除き、最も重要な設定はコンテンツの種類です。

• Number
• 日付
• 電話番号
• ID 番号

これらは、後処理、特にクリーンアップ、解析、書式設定に影響します。最も複雑なのは日付の書式設定ですが、数値の書式設定でも小数点区切りや 3 桁の区切り文字を決めておく必要があります。解析に失敗した場合は、問題を UiPath のサポートに報告し、解析を実行しないコンテンツの種類 String を使用するようにします。その場合は、値を RPA ワークフローのロジックで解析する必要があります。

関係があるもう 1 つの設定は [複数行] チェックボックスで、主に String 型のフィールドと関係があります。他のいずれかのフィールドで予期しない結果が得られた場合、または結果が得られなかった場合には、まずそのフィールドを [String Multi-line] フィールドに変更して、未変更のモデル予測の出力を確認します。

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

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

フィールドが 1 つのページに複数回出現する場合、それらが同じ概念を表すかぎり (上記の「フィールドを定義」セクションを参照)、すべてのフィールドをラベル付けする必要があります。

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

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

7. 評価データセットをラベル付けする

評価データセット (テスト データセットとも呼ばれる) をラベル付けするときには、トレーニング データセットのラベル付けとは若干異なるものに的を絞る必要があります。トレーニング データセットの場合は、ドキュメント上のフィールドの境界ボックスのみが重要になりますが、評価データセットの場合は、フィールドの値のみが重要になります。右側または上部のサイドバーの値をクリックして編集することで、フィールドの値を編集できます。自動的に解析された値に戻すには、ロック アイコンをクリックします。

注: 利便性およびスピードを向上し、タイポを防ぐため、ラベル付けをするときにはドキュメントのボックスをクリックし、修正のみを手動で行うことをお勧めします。値全部を手動で入力すると、スピードが遅くなり、エラーも発生しやすくなります。

8. モデルをトレーニングおよび評価する

AI Center のトレーニング パイプラインではテスト データが無視されるため、トレーニング バッチとテスト バッチの両方を含むデータセット全体をエクスポートできます。ただし、評価データセットがトレーニング データで構成されるかテスト データで構成されるかに関係なく、評価パイプラインは評価データセット全体に対して評価を実行します。指定したドキュメントの種類は、Data Manager ウィンドウの上部中央にあるファイル名のすぐ下に表示されます。

ML モデルを評価するときに最も強力なツールが、artifacts/eval_metrics フォルダーに生成される evaluation.xlsx ファイルです。この Excel ファイルでは、どの予測がどのファイルで失敗しているかがわかります。また、それが OCR エラーなのか、それともマシン ラーニングの抽出または解析のエラーなのか、RPA ワークフロー内の単純なロジックによって修正可能なのか、それとも異なる OCR エンジン、さらなるトレーニング データ、あるいは Data Manager でのラベル付けまたはフィールド構成の改善が必要なのかもわかります。

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

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

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

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

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

• ビジネス ルールの適用
• 最小の信頼度レベルのしきい値を設定

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

ビジネス ルールの例:

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

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

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

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

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

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

このスプレッドシートには、各フィールドに対応する列と各予測の信頼度レベルに対応する列が含まれています。min_confidence という名前の列を追加すると、業務プロセスにおける重要な、ビジネス ルールがまだ適用されていないすべてのフィールドに、すべての信頼度のうちで最低のレベルが設定されます。たとえば、明細項目の信頼度に対してしきい値を設定するのではなく、ベンダー名、合計金額、日付、期限日、請求書番号、その他の必須フィールドにしきい値を設定することもできます。min_confidence 列に基づいて表を並べ替えることによって、エラーの発生場所を確認できます。また、そのレベルを超えるしきい値を設定することで、正しく抽出されたドキュメントだけを直接送信できます。

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

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

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

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

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

検証ステーションのデータは運用ワークフローで使用されるため、データの量がはるかに増える可能性があります。したがって、モデルのトレーニングに時間とインフラストラクチャを要することを考えると、どのくらいの量のデータが役に立つ可能性があるのかを示したガイドラインが必要になります。また、前述の情報密度の問題によってモデルの品質が低下する可能性があるため、評価ステーションのデータでデータセットが埋め尽くされないようにした方がよいでしょう。

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

ここで、サンプル シナリオについて説明しましょう。これまでに、優れた OCR エンジンを選択し、Data Manager で 500 ページにラベル付けをして、結果的にパフォーマンスを向上させることができました。また、運用中の RPA ワークフローでモデルもデプロイしました。現在は、検証ステーションがデータの生成を開始しています。検証ステーションから最大 1000 から 1500 ページをランダムに選択し、最初の 500 ページとともに Data Manager にインポートして、ML モデルを再トレーニングする必要があります。その後、評価パイプラインを実行してモデルが実際に改善されたことを確認してから、新しいモデルを運用環境にデプロイする必要があります。

12. 自動微調整ループ (プレビュー)

自動微調整ループはプレビュー機能であり、前述の手順に従って作成した高性能モデルのメンテナンスに役立ちます。自動微調整でさらに優れたバージョンのモデルが確実に生成されるようにするには、優れた評価データセットを用意することに加えて、スケジュールが自動的に再設定されるフル パイプラインを使用して、トレーニングと評価を同時に実行することが重要です。そうすることで、最新のトレーニングで以前よりも正確なモデルが生成されたかどうかを確認できます。また、その後、業務プロセス内でロボットによって呼び出される ML スキルに新しいモデルをすぐにデプロイできます。

注: トレーニング データセットは変化し続けます。これは、より多くのデータが取り込まれ、Data Manager が「スケジュールされたエクスポート」画面で設定されたスケジュールに従って定期的にデータセットをエクスポートするからです。評価は、パイプラインで指定した評価データセットと同じデータセットを使用して実行されます。評価データセットが自動的に変更されることはなく、常に手動でキュレーション、ラベル付け、エクスポートする必要があります。異なるトレーニング実行間で精度スコアを比較できるように、評価セットの変更は最小限に留める必要があります。

AI Center では、ML パッケージの新しいバージョンが再トレーニングされるときに ML スキルを自動更新する機能が利用できます。ただし、この自動更新ではフル パイプラインのスコアは考慮されません。したがって、この機能を Document Understanding の自動再トレーニング パイプラインとともに使用することはお勧めしません。

前述の「評価データセットを作成する」セクションで説明したように、v21.10 以降の ML パッケージの評価パイプラインの実装では、ドキュメント単位でスコアが計算されるため、RPA ワークフローを実行した時の結果を正確に反映します。これは、Data Manager でデータセットがドキュメントごとにラベル付けされたことを前提としています。複数ページのドキュメントがドキュメント単位でラベル付けされているかどうかは、通常の PDF リーダーのようにページ間を自然にスクロールできるかどうかで確認できます。あるページから次のページに移動するのに [次へ] をクリックする必要がある場合は、各ページが個別のドキュメントとして処理されています。

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

企業向け RPA アーキテクチャにベスト プラクティスを適用するために、Studio の開始画面の [テンプレート] セクションの [Document Understanding Process] を必ず使用してください。