document-understanding

2023.4

false

重要 :

このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。

Document Understanding ガイド

デリバリー:

Automation Cloud Automation Cloud Public Sector Automation Suite Standalone

Last updated 2024年11月11日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

信頼度レベル

信頼度レベルとは

ML モデルが行う予測は、基本的に統計的な推測です。つまり、モデルが示すのは、この請求書では「これがおそらく合計金額である」ということです。ここから次のような疑問が浮かびます。「どの程度おそらくなのか」という疑問です。その疑問に 0 から 1 の尺度で答えようとするのが、信頼度レベルです。ただし、信頼度レベルは真の確率推定値ではありません。信頼度レベルは、モデルがその推測にどの程度確信を持っているかを示すものであるため、モデルが何でトレーニングされたかによって異なります。もっと分かりやすく考えると、信頼度レベルは理解度の尺度です。すなわち、モデルがこのモデルの入力をどの程度理解しているかを示すのが信頼度レベルです。入力が、モデルがトレーニング中に認識したことがあるものに似ている場合、信頼度は高くなると考えられます。そうではない場合、信頼度は下がる可能性があります。

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

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

質の低い予測を補足するはるかに優れた最善の方法は、ビジネスルールを適用することです。たとえば、請求書の場合、正味金額と税額が合計金額に等しくなければなりません。また、注文するコンポーネントの部品番号は必ず 9 桁である必要があります。こうした条件に当てはまらなければ、問題が発生していることが分かり、例外処理フローをトリガーできます。このアプローチを優先的に使用することを強く推奨します。複雑な正規表現を使用したり、データベースを検索してベンダー名や部品番号などを検証したりすることになっても、多大な労力をかけてこのようなルールを構築することには価値があります。場合によっては、対象外の他のドキュメントを抽出し、一部の値を、対象となっている元のドキュメントと相互参照して検証することもできます。

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

信頼度の種類

Document Understanding^TM 製品のほとんどのコンポーネントは信頼度レベルを返します。Document Understanding^TM ワークフローの主要な要素は、デジタル化、分類、抽出です。この要素ごとに、各予測に対して特定の信頼度があります。デジタル化と抽出の信頼度はどちらも検証ステーションに視覚的に表示されるため、予測をフィルター処理し、信頼度の低い予測にのみ的を絞ることで時間を節約できます。

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

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

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

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

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

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

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

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

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

[ドキュメントをデジタル化] アクティビティでは、[PDF に OCR を適用] が既定で [自動] に設定されていることに注意してください。この設定の場合、入力ドキュメントに応じてドキュメントに OCR アルゴリズムを適用する必要があるかどうかが判断されます。重要な情報 (ロゴ、ヘッダー、フッターなど) の抽出漏れを避けるには、[PDF に 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」キーを使用してラベル付けした、緑の透明なボックスで表示されるグループを使用してトレーニングされています。

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

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

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

通常のフィールド (日付、合計金額)
- 標準フィールドの場合、1 つのフィールドにつき少なくとも 20 件から 50 件のドキュメントサンプルが必要です。したがって、10 個の標準フィールドを抽出する必要がある場合は、少なくとも 200 件から 500 件のドキュメントサンプルが必要になります。20 個の標準フィールドを抽出する必要がある場合は、少なくとも 400 件から 1,000 件のドキュメントサンプルが必要です。必要なドキュメントサンプルの数は、フィールドの数に応じて増加します。フィールドの数が増えると、必要なドキュメントサンプルの数も 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 ページとなります。

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

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

トレーニングセット内にすべてのレイアウトが含まれているようにする必要はありません。実際、運用環境のドキュメントフローに含まれるレイアウトの大半は、ドキュメントサンプルがトレーニングセットには含まれていないか、含まれていても 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 つのベンダーに対して過度に最適化 (過剰適合) されるため、他のベンダーの請求書の処理精度に影響を与えることもあります。

代表的なデータセット

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

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 を注意深く確認してから、この新しいモデルを運用環境にデプロイする必要があります。