- 概要
- 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
チェックボックスと署名
チェックボックスを使用する複数選択フィールドには、いくつか種類があります。
- 相互に排他的なチェックボックス
- 相互に排他的ではないチェックボックス (複数のオプションを選択可能)
もう 1 つの重要な点は、特定の複数選択フィールドで利用可能な選択肢の数です。オプションが 1 個だけで、チェックボックスがオンかオフのいずれかしかない場合や、健康診断書のように、オプションが 10 個から 20 個以上もあり、グリッドや表として配置されていることもあります。
このような種類の複数選択フィールドをラベル付けする方法は、主に 4 つあります。
例を見ながら、オプションにラベル付けする方法を理解していきましょう。フォームに Project または Policy のオプションが含まれるとします。この場合、フィールドは 1 つだけであり、選択した単語にのみラベル付けします。つまり、Project という単語の横にあるチェックボックスにチェックマークが付いている場合は Project という単語にラベル付けし、Policy という単語の横にあるチェックボックスにチェックマークが付いている場合は Policy という単語にラベル付けします。どちらにもチェックマークが付いていなければ、どちらにもラベル付けしません。両方にチェックマークが付くことはあり得ないので、そのようなドキュメントがあった場合はトレーニング セットから削除されます。
このアプローチのメリットは、フィールドが 1 つあれば良く、必要なデータが少ないところです。チェックボックスの検出の成否に依存しないというメリットもあります。チェックボックスが X という文字として検出されても、モデルはその X の意味が、その横にあるオプションがオンになっていることだと学習して認識できます。
デメリットとしては、両方のオプションがだいたい等しく表されていることを確認する必要があります。常にそうなっているとは限りません。場合によっては、トレーニング セットのドキュメントの 90% で Project にチェックマークが付いていることがあります。この場合、モデルのパフォーマンスは十分とは言えず、このアプローチは失敗します。オプションが多いほど問題は悪化します。一部のオプションはほとんどの場合、まれであるためです。このような場合には、まれなオプションにチェックマークを付けた偽のドキュメントを作成して、バランスを取る必要があるかもしれません。
上の例では、Project という名前のフィールドがあり、常に Project のチェックボックスにラベル付けします。また、Policy という名前のフィールドもあり、常に Policy チェックボックスにラベル付けします。チェックマークの有無は関係ありません。この方法のメリットは、バランスがそれほど重要ではないところです。どちらかのオプションに 90% の確率でチェックマークが付くとしても、チェックボックスは常に同じ場所にあるので、モデルは今までどおりオプションを認識します。
デメリットは、フィールドが 1 つではなく 2 つになることです。オプションが 2 つであれば大した問題ではないかもしれません。しかし、オプションが 10 個から 20 個あると、フィールドも 1 つではなく 10 個から 20 個になり、ラベル付けはずっと困難になります。モデルのトレーニングも困難になり、必要なトレーニング データも増えます。
もう 1 つのデメリットは、チェックボックスが正しく検出されない場合があることです。この場合、返される文字 X、V、K のすべてに対応するために、より複雑なロジックをワークフローに追加しなければならない可能性があります。場合によっては、OCR でチェックボックスがその横にある単語と結合されてしまい、XProject のようになることもあります。この状況に対処するには、さらに複雑な RPA ロジックが必要です。
複数値フィールドは、Document UnderstandingTM の 2022.10 リリースに含まれます。この方法を使用すると、ラベル付けが容易になります。バランスの悪い選択肢にチェックマークが付いていても影響を受けません。また、オプションが多数あっても影響を受けません。しかし、チェックボックスの検出精度に依存することに変わりはなく、チェックボックスがその横にあるオプションと結合されるリスクがあります。OCR エラーを防ぐのは非常に困難です。
この方法でも、ラベル付けが容易になり、チェックボックス検出エラーの影響も受けにくくなりますが、最初のオプションと同じように、バランスの悪いオプションの影響を受けやすくなる可能性があります。
UiPath の経験では、これらのすべてのオプションは、特定の状況では適切な場合があります。当初は 1 つ目のオプションが良いと考えていましたが、UiPath® Document OCR のチェックボックス検出精度が向上するのに伴い、オプション 2 と 3 に引かれるようになりました。オプション 2 と 3 には別の大きなメリットもあります。フォーム AI および AI Center ベースの ML パッケージと相互運用性があるところです。したがって、フォーム AI から始めて、精度が予想より低ければ、変更を一切加えることなく、データセットを Document Manager セッションに移動して ML モデルを直接トレーニングできます。ML パッケージが強力になり、必要なトレーニング データが減ったことで、このオプションへの関心が特に高まっています。
LTS Enterprise バージョンの 2022.4 リリースより UiPath Document OCR を使用して署名を検出できるようになったため、マシン ラーニング モデルが署名を直接検出できます。
ドキュメント内で他のフィールドをラベル付けするのと同じように署名をラベル付けします。UiPath Document OCR によって署名が検出されると、マシン ラーニング モデルはこのフィールドを署名として認識するよう学習します。