Document Understanding

2022.10

偽

Document Understanding ガイド

最終更新日 2024年4月19日

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

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

データ抽出 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 モデルを構築する

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

ドキュメントに最適な OCR エンジンを選択する
- これは、OCR、単語と行の構築 (部分的に OCR に依存)、およびその後に続くすべてに影響します。
トレーニング用に、バランスのとれた代表的なデータセットを選択する
評価用に代表的なデータセットを選択する
抽出するフィールドを定義する
フィールドを設定する
トレーニングデータセットをラベル付けする
評価データセットをラベル付けする
AI Center でモデルをトレーニングおよび評価する
モデル出力を処理するためのビジネスルールを定義および実装する
(任意) 抽出用の信頼度しきい値を選択する
検証ステーションからのデータを使用してトレーニングする
自動微調整ループ (プレビュー)
オートメーションをデプロイする

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

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

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

[ドキュメントをデジタル化] アクティビティでは、[PDF に OCR を適用] が既定で [自動] に設定されていることに注意してください。この設定の場合、入力ドキュメントに応じてドキュメントに OCR アルゴリズムを適用する必要があるかどうかが判断されます。重要な情報 (ロゴ、ヘッダー、フッターなど) の抽出漏れを避けるには、[PDF に OCR を適用] を [はい] に設定します。ただし、プロセスの速度が低下する可能性があります。

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 コードなど)。詳細については、「フィールドを定義」セクションをご覧ください。

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

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

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

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

重要: Automation Cloud での v21.9 (プレビュー版) のリリースおよびオンプレミス版の v21.10 (一般提供) のリリースより、Document 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 行のテキストで構成される表の例です。これらの行は Document Manager によって暗黙的にグループ化されるため、「/」ホットキーを使用してグループ化する必要はありません。

項目を分割

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

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

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

Number
日付
電話番号
ID 番号

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

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

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

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

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

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

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

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

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

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

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

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

ML モデルを評価するときに最も強力なツールが、artifacts/eval_metrics フォルダーに生成される evaluation.xlsx ファイルです。この Excel ファイルでは、どの予測がどのファイルで失敗しているかがわかります。また、それが OCR エラーなのか、それともマシンラーニングの抽出または解析エラーなのか、RPA ワークフロー内の単純なロジックによって修正可能なのか、それとも異なる OCR エンジン、追加のトレーニングデータ、あるいは Document 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 つ目に重要なのは、検証ステーションのデータの方が、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 に追加して手動でラベル付けする必要があります。検証ステーションのデータは、そのような主要なスコープの拡張には適していません。

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

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

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

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

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

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