ドキュメントからの情報抽出
画像ソース: Nanonetsブログ
概要
このレポートでは、構造化ドキュメントまたは非構造化ドキュメントから情報を抽出する方法について説明します。具体的には、Googleによるフォームのようなドキュメントから情報を抽出するための表現学習 について説明します。この論文は ACL 2020に提出されています。
名刺をスキャンして、連絡先番号、EメールID、住所などのすべての連絡先の詳細を直接追加できると考えてみましょう。おもしろいですね。この小さな機能は多くの時間を節約します。
ドキュメントから情報を抽出することは、人間にとって面倒な作業であり、もちろん、費用もかかります。
情報を抽出する方法に関するいくつかの深層学習アプローチについて説明させていただきます
GitHubのコードを確認する→
注意:コードの実装が期待どおりに機能していません。しかし、これはこの論文を実装するための良い出発点になります。
さまざまなアプローチ
-
テンプラティックベースの情報抽出
-
フォームのようなドキュメントから情報を抽出するための表現学習
画像ソース : ACLデモスライド
従来のアプローチでは、テンプレートベースの方法を使用し、OCRされたテキストをテンプレートと照合して情報を抽出します。ただし、請求書には大きなばらつきがあるため、このアプローチを大規模に適用することはできません。
図1
出典 : 論文
さまざまなベンダーからの請求書は、さまざまなレイアウトを使用して情報を提示します。一時的なアプローチの使用は、スケーラブルではなく、エラーが発生しやすくなります。
このブログ投稿では、フォームのようなドキュメントから情報を抽出するための表現学習の概要について説明します。他のテクニックの詳細については、Nanonetsによるこのブログ投稿 にアクセスしてください。
データセットの詳細
著者はこの論文で、2つの異なるデータセットを使用しました。
- 請求書:請求書には2つのコーパスがあります。最初のコーパスには14,237の請求書が含まれ、2番目のコーパスには595の請求書が含まれています。請求書は共通のテンプレートを共有しません。各請求書テンプレートは他のテンプレートとは異なります。
請求書コーパスはプライベートデータセットです。
- .領収書:このデータセットは、スキャンされた領収書のOCRおよび情報抽出(SROIE)に関するICDAR 2019ロバストリーディングチャレンジの一部として公開されたスキャンされた領収書の公開されたコーパスです。
このデータセットには、住所、会社名、合計金額、日付の4つのフィールドのグラウンドトゥルースとともに626枚の画像が含まれています。合計金額と日付フィールドのみをターゲットとして使用します。このデータセットには、座標と対応するテキストが関連付けられたOCRされたCSVファイルも含まれています。
サンプル画像
GroundTruthのサンプル
{
"company": "BOOK TA .K (TAMAN DAYA) SDN BHD",
"date": "25/12/2018",
"address": "NO.53 55,57 & 59, JALAN SAGU 18, TAMAN DAYA, 81100 JOHOR BAHRU, JOHOR.",
"total": "9.00"
}
観察
モデルの部分に入る前に、いくつかの観察について説明しましょう。
- 多くの場合、各フィールドはよく理解されているタイプに対応しています。たとえば、合計金額の候補としては、数値のインスタンスが考えられます。「Weights and Biases」のようなテキストは、合計金額フィールドでは明らかに正しくありません。
画像ソース : ACLデモスライド
タイプごとに検索スペースを制限すると、問題の複雑さが大幅に軽減されます。したがって、いくつかのライブラリを使用して、各フィールドの候補を生成します。たとえば、日付フィールドの潜在的な候補ジェネレータは、日付パーサーライブラリになります。また、Google NLPなどのクラウドサービスを使用して、候補者をより効果的に生成することもできます。
- 各フィールドインスタンスは、キーフレーズに関連付けられています。たとえば、fig1では、日付インスタンスは常に日付または日付のキーフレーズで囲まれていると推測できます。また、キーフレーズが常に同じ行にあるわけではありません。効果的な解決策は、テキスト情報とともに空間情報を含めることです。
画像ソース : ACLデモスライド
空間情報を含める方法は?
空間情報は、各単語の周囲の隣人を考慮して含まれています。この論文の隣人の著者を選択するために、近隣ゾーンを定義しました。
近隣ゾーン:候補ごとに、近隣ゾーンはページの左側まで広がり、候補の上のページの高さの10%になります。
バウンディングボックスがネイバーフッドゾーンと50%以上オーバーラップしているテキストトークンは、ネイバーと見なされます。
- フィールドの主要なフレーズは、主に限られた語彙から抽出されます。請求書の日付インスタンスの約93%は、「日付」や「日付」(論文から)などのキーフレーズに関連付けられています。これは、この問題が適度な量のトレーニングデータで解決できることを示唆しています。
画像ソース : ACLデモスライド
上記のすべての観察は、さまざまなドキュメントの多くのフィールドに適用できます。
この問題では、データの前処理がモデル部分よりも重要で重要です。上記の観察結果を使用して、データ処理パイプラインを見てみましょう。
画像ソース : ACLデモスライド
-
OCR:画像からテキストを抽出するには、OCRを適用する必要があります。EasyOCR、PyTesseractなどのオープンソースツール、またはGoogle OCRなどのクラウドサービスを使用できます。私たちの場合、ICDARはすでにOCRされたテキストを提供しています。
-
候補ジェネレーター(エンティティのタグ付け):上記の観察で説明したように、複数の候補ジェネレーターを使用して候補を生成します。システム全体のリコールは候補発電機のリコールを超えることはできないため、それらのリコールが高くなることが重要です。
- スコアリングおよび割り当てモジュール:このモジュールは、ニューラルモジュールを使用して、各候補者の0〜1のスコアを個別に計算し、その真の抽出である可能性が高いスコアリングされた候補者を各フィールドに割り当てます。
このスコアリングと割り当ての分離により、他の候補者やフィールドとは関係なく、近隣のみに基づいて各候補者の表現を学習できます。また、必要に応じて、任意に複雑なビジネスルールを割り当て者にエンコードすることもできます。たとえば、請求書の期日が(時系列で)請求書の日付より前になることはありません。(論文による)
簡潔にするために、著者は割り当てモジュールの詳細を省略し、他のフィールドとは無関係に各フィールドの最高スコアの候補を選択する単純な割り当てを使用して結果を報告します
神経スコアリングモデル
モデルが複数のドキュメントテンプレートにわたって一般化されることを���認するために、モデルは候補とそれが属するフィールドの個別の埋め込みを学習しようとし、候補とフィールドの埋め込みの類似性がスコアを決定します。
著者が行ったもう1つの重要な設計選択は、候補テキストをモデルに組み込まないことです。これは、偶発的な過剰適合を回避することです。たとえば、データセットに2020年より前のすべての請求書が含まれている場合、モデルは請求書の日付が2020年より前に発生する必要があることを学習できる可能性があります。
近隣埋め込み:近隣テキストトークンは、単語埋め込みテーブルを使用して埋め込まれます。各隣接相対位置は、ドロップアウトのある2つのReLUアクティブ化レイヤーで構成される非線形位置埋め込みを介して埋め込まれます。この非線形埋め込みにより、モデルは、候補と同じ線を共有する隣接線と上の線上の隣接線の間など、位置のきめ細かい差異を解決することを学習できます。(論文による)
近隣埋め込み:近隣テキストトークンは、単語埋め込みテーブルを使用して埋め込まれます。各隣接相対位置は、ドロップアウトのある2つのReLUアクティブ化レイヤーで構成される非線形位置埋め込みを介して埋め込まれます。この非線形埋め込みにより、モデルは、候補と同じ線を共有する隣接線と上の線上の隣接線の間など、位置のきめ細かい差異を解決することを学習できます。(論文による)
近隣エンコーディング:すべての近隣埋め込みは互いに独立しています。隣人同士の関係を捉えるために、自己注意メカニズムが使用されます。これにより、予測に関係のないネイバーの重みを減らし、ネイバーのコンテキスト化された表現を生成できます。
候補に対する近傍の相対位置に関する情報は、埋め込み自体にすでに取り込まれているため、近傍エンコーディングが、近傍が特徴に含まれる(任意の)順序に対して不変であることを確認するために、プーリングメカニズムが採用されています。
候補エンコーディング:候補エンコーディングは、近傍エンコーディングを候補位置埋め込みと連結することによって取得されます。
フィールド埋め込み:フィールドIDは、フィールド埋め込みレイヤーを使用して埋め込まれ、フィールドIDの表現を生成します。
候補者スコア:候補者エンコーディングには、候補者の位置に関するすべての情報と近隣の詳細が含まれていることが期待されます。候補者が属する分野とは無関係です。
ここで、候補エンコーディングとフィールド埋め込みの間のCosineSimilarityを計算します。類似性の値は-1から1の範囲にあるため、値を0から1の間で再スケーリングし、スコアが最も高い候補を選択します。
結果
このモデルの利点を実証するために、この論文の作成者は2つのベースラインを提案し、結果を比較しました。
bag-of-words(BoW)ベースラインには、候補の隣接するトークンのみが組み込まれ、それらの位置は組み込まれません。MLPベースラインは、候補の隣接層の相対位置など、提案されたモデルと同じ入力機能を使用し、3つの隠れ層を使用して候補をエンコードします。
これらのベースラインは両方とも同じアプローチに従い、候補とフィールドを別々にエンコードします。
このモデルが2つのベースラインを上回っていることは明らかです。隣接位置のMLPベースラインを使用すると、BoWベースラインよりもパフォーマンスが向上します。
機能の重要性に対する相対的な順序:
neighbor text > candidate position > neighbor position
また、自己注意層を削除すると、スコアラーROCAUCが1ポイント低下し、エンドツーエンドの最大F1が1.7ポイント低下することも確認されています。
モデル表現
この論文のエキサイティングな部分は、モデルの内部表現を調査し、t-SNE(次元削減手法)を使用して視覚化したことです。
表現がどのように見えるかに興奮していますか?さあ、見てみましょう。
注意点:
-
図4(b)から、正の点がうまくクラスター化されているのに対し、負の点はまばらな空間分布を示していることがはっきりとわかります。
-
フィールドの埋め込みは、クラスターの中心ではなく、ポイントから遠く離れたクラスターの端にあることに注意することが重要です。このパターンは、損失関数が本質的に、フィールド埋め込みとその正の間の余弦距離を最小化しようとし、その負からの距離、最も重要なのは他のフィールドの正からの距離を最大化しようとしているという事実によって予測されます。
-
図4(c)から、請求日の例は請求日クラスターから遠く離れています。購入日を請求日としてラベル付けしたのはアノテーターの責任であることは明らかです。
-
図4(d)のサンプルの候補エンコーディングは、請求日と期日の間にあります。これは、この候補者が期日と請求書の日付の両方に囲まれているという事実によって説明されます。
-
図4(e)のサンプルの候補エンコーディングは、請求日クラスターから遠く離れています。注意深く調べたところ、これはスキャンノイズによるOCRエラーが原因であることがわかりました。
モデル表現を視覚化することは、一般的にどのモデルにも大いに役立つと思います。
結語
このブログ投稿を楽しんでいただけたでしょうか。ドキュメントからの情報抽出は、困難で困難な作業です。候補ジェネレータの精度を上げることはまだ研究中であり、多くのドメインの専門知識が必要です。コメントまたはTwitterのハンドルを通じてフィードバックをお気軽にお知らせください。