チェックボックスと署名

チェックボックス

チェックボックスを使用する複数選択フィールドには、いくつか種類があります。

相互に排他的なチェックボックス
相互に排他的ではないチェックボックス (複数のオプションを選択可能)

もう 1 つの重要な点は、特定の複数選択フィールドで利用可能な選択肢の数です。オプションが 1 個だけで、チェックボックスがオンかオフのいずれかしかない場合や、健康診断書のように、オプションが 10 個から 20 個以上もあり、グリッドや表として配置されていることもあります。

このような種類の複数選択フィールドをラベル付けする方法は、主に 2 つあります。

オプションにラベル付けする

例を見ながら、オプションにラベル付けする方法を理解していきましょう。フォームに 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 Understanding^TM の 2022.10 リリースに含まれます。この方法を使用すると、ラベル付けが容易になります。バランスの悪い選択肢にチェックマークが付いていても影響を受けません。また、オプションが多数あっても影響を受けません。しかし、チェックボックスの検出精度に依存することに変わりはなく、チェックボックスがその横にあるオプションと結合されるリスクがあります。OCR エラーを防ぐのは非常に困難です。