- 概要
- Document Understanding Process
- クイック スタート チュートリアル
- フレームワーク コンポーネント
- ML パッケージ
- 概要
- Document Understanding - ML パッケージ
- DocumentClassifier (ドキュメント分類) - ML パッケージ
- OCR 機能を持つ ML パッケージ
- 1040 (米国の個人所得税申告書) - ML パッケージ
- 1040 Schedule C (米国の個人所得税申告書のスケジュール C) - ML パッケージ
- 1040 Schedule D (米国の個人所得税申告書のスケジュール D) - ML パッケージ
- 1040 Schedule E (米国の個人所得税申告書のスケジュール E) - ML パッケージ
- 4506T (米国の納税申告証明依頼書) - ML パッケージ
- 990 (米国の所得税非課税団体申告書) - ML パッケージ (プレビュー)
- ACORD125 (企業向け保険契約申込書) - ML パッケージ
- ACORD126 (企業総合賠償責任保険) - ML パッケージ
- ACORD131 (アンブレラ/エクセス保険) - ML パッケージ
- ACORD140 (商業保険申込書の財物補償条項) - ML パッケージ
- ACORD25 (賠償責任保険証明書) - ML パッケージ
- Bank Statements (銀行預金残高証明書) - ML パッケージ
- BillsOfLading (船荷証券) - ML パッケージ
- Certificate of Incorporation (会社存在証明書) - ML パッケージ
- Certificate of Origin (原産地証明書) - ML パッケージ
- Checks (小切手) - ML パッケージ
- Children's Product Certificate (子供向け製品証明書) - ML パッケージ
- CMS 1500 (米国の医療保険請求フォーム) - ML パッケージ
- EU Declaration of Conformity (EU 適合宣言書) - ML パッケージ
- Financial Statements (財務諸表) - ML パッケージ
- FM1003 (米国の統一住宅ローン申請書) - ML パッケージ
- I9 (米国の就労資格証明書) - ML パッケージ
- ID Cards (ID カード) - ML パッケージ
- Invoices (請求書) - ML パッケージ
- InvoicesAustralia (請求書 - オーストラリア) - ML パッケージ
- InvoicesChina (請求書 - 中国) - ML パッケージ
- InvoicesIndia (請求書 - インド) - ML パッケージ
- InvoicesJapan (請求書 - 日本) - ML パッケージ
- Invoices Shipping (船積送り状) - ML パッケージ
- Packing Lists (梱包明細書) - ML パッケージ
- Passports (パスポート) - ML パッケージ
- Payslips (給与明細) - ML パッケージ
- Purchase Orders (発注書) - ML パッケージ
- Receipts (領収書) - ML パッケージ
- RemittanceAdvices (送金通知書) - ML パッケージ
- UB-04 (健康保険請求フォーム) - ML パッケージ
- Utility Bills (公共料金の請求書) - ML パッケージ
- Vehicle Titles (自動車の権利書) - ML パッケージ
- W2 (米国の源泉徴収票) - ML パッケージ
- W9 (米国の納税申告書) - ML パッケージ
- その他のすぐに使える ML パッケージ
- パブリック エンドポイント
- ハードウェア要件
- パイプライン
- Document Manager
- OCR サービス
- ディープ ラーニング
- 優れたパフォーマンスのモデルをトレーニングする
- 優れたパフォーマンスのモデルをデプロイする
- Automation Suite にデプロイされた Document Understanding
- AI Center スタンドアロンにデプロイされた Document Understanding
- ライセンス
- アクティビティ
- UiPath.Abbyy.Activities
- UiPath.AbbyyEmbedded.Activities
- UiPath.DocumentProcessing.Contracts
- UiPath.DocumentUnderstanding.ML.Activities
- UiPath.DocumentUnderstanding.OCR.LocalServer.Activities
- UiPath.IntelligentOCR.Activities
- UiPath.OCR.Activities
- UiPath.OCR.Contracts
- UiPath.OmniPage.Activities
- UiPath.PDF.Activities
優れたパフォーマンスのモデルをデプロイする
機械学習 (ML) モデルの精度が時間の経過と共に向上するにつれて、リソース要件も変化します。最適なパフォーマンスを得るには、AI Center を介して ML モデルをデプロイする際に、処理が必要なトラフィックに対してスキルを適切なサイズに設定することが重要です。ほとんどの場合、インフラストラクチャのサイズは、単位時間 (分または時間) あたりのページ数に対して設定されます。1 件のドキュメントは 1 ページの場合も、複数ページの場合もあります。
AI Center を介してインフラストラクチャをデプロイする場合、最適なパフォーマンスを得るために留意すべき重要な側面がいくつかあります。
使用できる GPU インフラストラクチャの種類は 1 つだけです。これは、GPU を有効にするためのチェックボックスで強調表示されます。各スキルは、GPU を持つ単一の仮想マシン (VM) またはノードで実行されます。この場合、スキルはそのノードで使用可能なすべての CPU とメモリ リソースを使用できるため、CPU とメモリは関係ありません。スループットに加えて、GPU は非常に高速です。このため、レイテンシが重要な場合は GPU の使用をお勧めします。
CPU とメモリは分割できます。つまり、同じノード上で複数の ML スキルを実行できます。隣接するスキルからの妨害を避けるため、各 ML スキルの上限は、選択した層に応じて使用可能なメモリ量と CPU です。CPU を高くすると (ページの) 処理速度が速くなり、メモリを増やすと処理可能なドキュメントの数が増えます。
レプリカの数によって、ML モデルからの要求を処理するために使用されるコンテナーの数が決まります。この値が大きいほど、並列処理できるドキュメントの量が増えますが、その特定の層の制限が適用されます。レプリカの数はインフラストラクチャの種類 (レプリカあたりの CPU の数、または GPU を使用している場合) に直接関連付けられます。つまり、レプリカとインフラストラクチャのサイズの両方がスループット (ページ/分) に直接影響します。
インフラストラクチャのサイズが正しくない場合、モデルに非常に高い負荷がかかるおそれがあります。場合によっては、要求のバックログが発生し、処理時間が長くなり、さらにはドキュメントの処理時に失敗が発生する可能性があります。
メモリ不足が最も多く発生するのは下位の CPU 層 (0.5 CPU または 1 CPU) です。非常に大きなペイロード (1 つまたは複数の大きなドキュメント) を処理する必要がある場合は、メモリ不足例外が発生する可能性があります。これは、ページとテキスト密度 (ページあたりのテキストの量) で測るドキュメントのサイズに関連しています。要件は個々のユース ケースで固有のため、正確な数値を提示することはできません。詳細については、「インフラストラクチャの適切なサイズ設定」セクションのガイドラインをご覧ください。メモリ不足の状況が発生した場合は、一般推奨事項として次の層に進むことをお勧めします。
このセクションでは、異なるスキル サイズごとにモデルがどのように実行されるかについての一般的なガイドラインを示します。
層 | ドキュメントあたりの最大ページ数 | 予想されるスループット (ページ/時間) | AI ユニット/時間 |
---|---|---|---|
0.5 CPU/2 GB メモリ | 25 | 300-600 | 1 |
1 CPU/4 GB メモリ | 50 | 400-800 | 2 |
2 CPU/8 GB メモリ | 100 | 600-1000 | 4 |
4 CPU/16 GB メモリ | 100 | 800-1200 | 8 |
6 CPU/24 GB メモリ | 100 | 900-1300 | 12 |
GPU | 200-250 | 1350-1600 | 20 |
層 | ドキュメントあたりの最大ページ数 | 予想されるスループット (ページ/時間) | AI ユニット/時間 |
---|---|---|---|
0.5 CPU/2 GB メモリ | 25 | 40-100 | 1 |
1 CPU/4 GB メモリ | 50 | 70-140 | 2 |
2 CPU/8 GB メモリ | 75 | 120-220 | 4 |
4 CPU/16 GB メモリ | 100 | 200-300 | 8 |
6 CPU/24 GB メモリ | 100 | 250-400 | 12 |
GPU | 200-250 | 1400-2200 | 20 |
層 | ドキュメントあたりの最大ページ数 | 予想されるスループット (ページ/時間) | AI ユニット/時間 |
---|---|---|---|
0.5 CPU/2 GB メモリ | 25 | 60-200 | 1 |
1 CPU/4 GB メモリ | 50 | 120-240 | 2 |
2 CPU/8 GB メモリ | 75 | 200-280 | 4 |
4 CPU/16 GB メモリ | 100 | 250-400 | 8 |
6 CPU/24 GB メモリ | 100 | 350-500 | 12 |
GPU | 200-250 | 1000-2000 | 20 |
予想されるスループットは各レプリカにつき「ページ/時間」単位で表され、予想される最小スループットと最大スループットはドキュメント自体に応じて表されます。ML スキルのサイズは、日、週、月の平均スループットではなく、予想される最大スループット (スパイク) に合わせて設定する必要があります。
例 1
- 最大 5 ページを含むドキュメント。
- 最大スパイクは 1 時間あたり 300 ページ。
スループットは低い方であり、ドキュメント サイズも小さいため、この例では GPU は必要ありません。0.5 CPU 層または 1 CPU 層のレプリカが 2 つから 4 つあれば十分です。
例 2
- 最大 80 ページを含むドキュメント。
- 最大スパイクは 1 時間あたり 900 ページ。
この例では、4 CPU 層の 3 つのレプリカ、または 1 つの GPU 層で十分です。
例 3
- 最大 50 ページを含むドキュメント。
- 最大スパイクは 1 時間あたり 3000 ページ。
- 3 つの GPU レプリカを使用する。
- 4 CPU 層または 6 CPU 層のレプリカを 12 ~ 15 個使用する。
どちらのオプションでも、ML スキルのレプリカが 3 つ以上あるため高可用性が実現します。
モデルのバージョンと層に応じた、1 つの抽出レプリカの予想されるスループットについては、「一般的なガイドライン」セクションの表で確認できます。
- 理想的には、レプリカが 1 つの要求に応答を送信してから、次の要求のデータを受信するまでのアイドル時間が最小限である必要があります。
- レプリカが過負荷にならないようにします。要求は 1 つずつ (順次) 処理されます。つまり常に、処理中のアクティブな要求が 1 つと、保留中の要求のキューが 1 つ存在します。このキューが長くなりすぎると、レプリカは新しい受信要求を拒否し、ステータス コード「
429 (too many requests) HTTP
」が表示されます。
1 つのレプリカのインフラストラクチャのサイズを調整する場合に留意すべき重要なポイントは、ワークロードのバランスを取ることです。ワークロードが軽すぎてレプリカがアイドル状態のままになったり、重すぎてタスクを拒否し始めたりしないようにする必要があります。
- レプリカに関連する最もビジーな期間を特定します。たとえば、1 分間のピーク時間や 12 時間に及ぶ期間ではなく、アクティビティが最もビジーな 1 時間を特定する必要があります。この期間を特定したら、その期間中の需要 (ページまたは要求の数) を推定します。
- この推定値をレプリカあたりのスループットで割ります。詳しくは、「1 つのレプリカのインフラストラクチャのサイズを設定する」セクションをご覧ください。
- 安全策として若干の余剰容量を追加します。
最もビジーな期間を使用すると、需要が大幅に減ったときにプロビジョニング過剰になる可能性があることに注意してください。これに対処するには、需要に応じてデプロイのサイズを手動で増減できます。これが役立つのは、たとえば、10 個のレプリカが必要な非常にビジーな 1 時間の期間の後に、アクティビティが少なく 2 個のレプリカだけで済む期間が 23 時間続くような場合です。この結果、システムはかなりの時間、プロビジョニング過剰になります。
ページ数とそのページの密度が重要な要因になります。ページ数は要求数よりも関連度が高いものの、実際問題としては、要求の方がカウントするのが容易です。
デプロイがプロビジョニング不足かどうかを判断する場合、CPU 使用率は適切ではありません。各レプリカは、保留中の要求のキューに関係なく、要求の処理中に CPU/GPU を最大限に使用するためです。
重要な要因はエンドツーエンドの時間であり、これは待機時間と実際の処理時間の合計です。
たとえば、スループットが約 900 ページ/時、すなわち約 4 秒/ページの層を選択し、5 ページのドキュメントを送信すると、通常はドキュメントあたり約 30 秒かかるとします。
この場合、待機時間は約 10 秒であると見積もることができます。つまり、待機時間が存在しています (これは、レプリカが既存の要求の処理でビジーであったため、要求がすぐには取得されなかったことを意味します)。また、この待機時間が約 10 秒であったことも示しています。
実際のエンドツーエンドの時間 (測定された時間) と予想されるエンドツーエンドの時間 (層の機能として推定された時間) の差が 0 より大きい場合は、レプリカが絶え間なく動作していることを意味します。また、需要の増加に応じて待機時間が長くなる場合は、デプロイに持続的な負荷がかかっていることは明らかです。さらに、ステータス コード 429 (要求が多すぎる) があれば、プロビジョニング不足の証拠となります。
- 最もビジーな期間を特定します。この例では、1 時間 (3,600 秒) と仮定します。
- レプリカの現在の数を取得します。ここでは 10 個と仮定します。ここから 36,000 「レプリカ秒」 (「人時」と同様の概念) が得られます。
- 要求の総所要時間 (エンドツーエンドの時間の合計) を求めます。これを 10,000 秒と仮定します。