- 概要
- モデルを構築する
- モデルを使用する
- ML パッケージ
- 1040 (米国の個人所得税申告書) - ML パッケージ
- 1040 Schedule C (米国の個人所得税申告書のスケジュール C) - ML パッケージ
- 1040 Schedule D (米国の個人所得税申告書のスケジュール D) - ML パッケージ
- 1040 Schedule E (米国の個人所得税申告書のスケジュール E) - ML パッケージ
- 1040x (米国の個人所得税修正申告書) - ML パッケージ
- 3949a - ML パッケージ
- 4506T (米国の納税申告証明依頼書) - ML パッケージ
- 709 (米国の贈与税申告書) - ML パッケージ
- 941x (米国の雇用主による四半期連邦税修正申告書) - ML パッケージ
- 9465 (米国の分割納付申請書) - 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 パッケージ
- Invoices Hebrew (請求書 - ヘブライ語) - ML パッケージ
- InvoicesIndia (請求書 - インド) - ML パッケージ
- InvoicesJapan (請求書 - 日本) - ML パッケージ
- Invoices Shipping (船積送り状) - ML パッケージ
- Packing Lists (梱包明細書) - ML パッケージ
- Payslips (給与明細) - ML パッケージ
- Passports (パスポート) - ML パッケージ
- Purchase Orders (発注書) - ML パッケージ
- Receipts (領収書) - ML パッケージ
- RemittanceAdvices (送金通知書) - ML パッケージ
- UB-04 (健康保険請求フォーム) - ML パッケージ
- Utility Bills (公共料金の請求書) - ML パッケージ
- Vehicle Titles (自動車の権利書) - ML パッケージ
- W2 (米国の源泉徴収票) - ML パッケージ
- W9 (米国の納税申告書) - ML パッケージ
- パブリック エンドポイント
- サポートされている言語
- データおよびセキュリティ
- ライセンスと請求ロジック
- 使い方
チェックボックスと署名
チェックボックスと署名は、契約上の合意から登録フォームまで、さまざまな種類のドキュメントで重要な役割を果たす 2 つの要素です。モデルを最大限に活用するには、チェックボックスと署名に正しくアノテーションを行う方法を理解することが重要です。
- 相互に排他的なチェックボックス
- 相互に排他的ではないチェックボックス (複数のオプションを選択可能)
考慮すべき重要な点は、特定の複数選択フィールドで提供されている選択肢の数です。オプションが 1 個だけで、チェックボックスがオンかオフのいずれかしかない場合もありますが、多くの場合は、健康診断書のように、オプションが 10 個から 20 個、あるいはそれ以上あり、グリッドや表の形式で構成されていることがほとんどです。
このような多様な複数選択フィールドにアノテーションを行うという観点では、主に 4 つの方法を使用できます。
例を見ながら、オプションにアノテーションを行う方法を理解していきましょう。
このアプローチのメリットは、フィールドが 1 つあれば良く、必要なデータが少ないところです。また、チェックボックスの検出の成否に依存することもありません。たとえば、チェックボックスが誤って X という文字として検出されても、モデルはその X の意味が、その横にあるオプションがオンになっていることだと学習して認識できます。
潜在的なデメリットとしては、両方のオプションがだいたい等しく表されていることを確認する必要があります。常にそうなっているとは限りません。たとえば、データセット内のドキュメントの 90% で 2018 にチェックマークが付いている場合、モデルのパフォーマンスが影響を受け、このアプローチは失敗する可能性があります。オプションが多いほど問題は悪化します。一部のオプションはほとんどの場合、まれであるためです。このような場合には、まれなオプションにチェックマークを付けた偽のドキュメントを作成して、バランスを取る必要があるかもしれません。
前の例で、異なるフィールドを 2 つ作成しました。1 つは 2018 というラベルが付いたフィールドで、その年に対応するチェックボックスに一貫してアノテーションを行いました。もう 1 つは 2019 というラベルの付いたフィールドで、2019 年に対応するチェックボックスに、オン/オフに関係なくアノテーションを行いました。この方法のメリットは、バランスがそれほど重要ではないところです。どちらかの選択肢が 90% の確率で選択されるとしても、チェックボックスの位置は固定されているので、モデルは今までどおり学習してオプションを識別できます。
デメリットは、フィールドが 1 つではなく 2 つになることです。処理するオプションが 2 つであれば大した問題ではないかもしれませんが、処理するオプションが 10 個から 20 個になり、その結果、1 つではなく 10 個から 20 個のフィールドを作成すると、アノテーション プロセスが大幅に複雑になる可能性があります。さらに、モデルのトレーニング プロセスも困難になり、必要なトレーニング データも増えます。
もう 1 つのデメリットは、チェックボックスが間違って検出される場合があることです。この場合、返される文字 X、V、K のすべてを管理するために、より複雑なロジックをワークフローに追加しなければならない可能性があります。場合によっては、OCR でチェックボックスがその横にある単語と結合されてしまい、X2018 のようになることもあります。この状況に対処するには、さらに複雑な RPA ロジックが必要です。
複数値フィールドを使用すると、アノテーションが容易になります。また、複数値フィールドは、オンになっているオプションのバランスが取れていなかったり、選択されるオプションが広範であったりしても影響を受けません。ただし、複数値フィールドであっても、チェックボックスの検出精度や、チェックボックスが隣接するオプションと結合されるリスクの影響を受けることに変わりはありません。OCR エラーを防ぐのは非常に困難です。