2021/02/08 2021/02/08

ドキュメントの構造データ抽出（AI最新論文読解 No.11）

アクセス: 121

コメント: 0

<a href="https://research.google/pubs/pub49122/">Representation Learning for Information Extraction from Form-like Documents</a>(ACL2020, Google Research)を読解する。 
領収書、請求書、保険見積もりなどのドキュメントは、様々なビジネスワークフローで非常に一般的で重要です。現在、これらのドキュメントの処理は主に手動による作業で行われていて、既存の自動化されたシステムは、とても脆弱でエラーが発生しやすいものです。請求書を例に上げると、何千もの異なる形でレイアウトされています。異なる会社からの請求書、または同じ会社内の異なる部門でさえ、フォーマットがわずかに異なるケースがあります。しかし、請求書番号、請求日、支払期日、支払期日、アイテムリストなど、請求書に含まれるフィールドについては一般的に共通の認識があります。この全てのデータを自動的に抽出できるシステムが可能になると、手作業によるエラーを回避することができ、多くのビジネスワークフローの効率を劇的に向上させる可能性があります。 
本論文では、テンプレートドキュメントから構造化データを自動的に抽出するアプローチが紹介されています。プレーンテキストドキュメントからの抽出する既存の手法とは対照的に、ターゲットフィールドタイプのナレッジを使用して候補となるフィールドを識別するアプローチです。次に、これらは近接する単語を使用して各候補のデンスな表現を学習するニューラルネットワークを使用してスコアリングされます。 2つのコーパス（請求書と領収書）での実験では、目に見えないレイアウトにうまく一般化できることが示されています。 なぜ難しいのか 
 この情報抽出の問題は、自然言語処理（NLP）とコンピュータービジョンの世界にまたがるために発生します。従来のNLPタスクとは異なり、このようなドキュメントには、通常の文や段落に見られるような「自然言語」は含まれていませんが、代わりにフォームに似ています。多くの場合、データは表で表されますが、さらに多くのドキュメントには複数のページがあり、多くの場合、セクションの数が異なり、情報を整理するためのさまざまなレイアウトとフォーマットのヒントがあります。ページ上のテキストの2次元レイアウトを理解することは、そのようなドキュメントを理解するための鍵です。一方、これを純粋に画像セグメンテーションの問題として扱うと、テキストのセマンティクスを利用することが困難になります。 ソリューション概要 
これらの問題に対するこの研究論文のアプローチによって、開発者は、ターゲットスキーマ（抽出するフィールドのリストとそれに対応するタイプ）とラベルが付けられたドキュメントの小さなコレクションの2つの入力を使用して、特定のドメイン（請求書など）の抽出システムをトレーニングおよび展開できますトレーニングセットとして使用するためのグラウンドトゥルースを使用します。サポートされているフィールドタイプには、日付、整数、英数字コード、通貨金額、電話番号、URLなどの基本が含まれます。また、住所、会社名など、Googleナレッジグラフで一般的に検出されるエンティティタイプも利用します。 
　入力ドキュメントは、最初に光学式文字認識（OCR）サービスを介して実行され、テキストとレイアウト情報が抽出されます。これにより、PDFなどのネイティブデジタルドキュメントやドキュメント画像（スキャンされたドキュメントなど）を処理できます。次に、特定のフィールドのインスタンスに対応する可能性のあるOCR出力内のテキストのスパンを識別する候補ジェネレーターを実行します。候補ジェネレーターは、各フィールドタイプ（日付、番号、電話番号など）に関連付けられた既存のライブラリを利用するため、候補ジェネレーターごとに新しいコードを記述する必要がありません。次に、これらの候補のそれぞれが、訓練されたニューラルネットワーク（下図のscorer）を使用してスコアリングされ、それが実際にそのフィールドに対して抽出される可能性のある値である可能性を推定します。最後に、Aassigner モジュールはスコアリングされた候補をターゲットフィールドに照合します。デフォルトでは、Assingerはフィールドの最高スコアの候補を選択するだけですが、請求日フィールドが支払い日フィールドよりも時系列的に前にある条件を加えるするなど、追加のドメイン固有の制約を組み込むことができます。 <img height="274" src="/p/yfejpnjk9tx77v9igaf4-d2f3c575.png" style="width:640px;height:274px;" width="640" alt="yfejpnjk9tx77v9igaf4-d2f3c575.png" /> Scorer 
Scorerは、バイナリ分類器としてトレーニングされたニューラルモデルです。スキーマからターゲットフィールドを抽出候補とともに入力として受け取り、0〜1の予測スコアを生成します。候補のターゲットラベルは、候補がそのドキュメントとフィールドのグラウンドトゥルースと一致するかどうかによって決定されます。モデルは、フィールドと候補がベクトル空間に近いほど、候補がそのフィールドとドキュメントの真の抽出値である可能性が高いベクトル空間で、各フィールドと各候補を表す方法を学習します。 Candidate 
候補となる値は、識別されたバウンディングボックスの重心に対する、ページ上のトークンの相対位置とともに、その近傍のトークンによって表されます。例としてinvoice_dateフィールドを使用すると、「InvoiceDate」や「InvDate」などの近隣のフレーズは、これが候補である可能性が高いことをスコアラーに示し、「DeliveryDate」などのフレーズはこれが可能性が低いことを示します。 <img height="173" src="/p/zsroy8bhvawrpita8rtu-68779450.png" style="width:150px;height:81px;" width="320" alt="zsroy8bhvawrpita8rtu-68779450.png" /> A small snippet of an invoice. The green box shows a candidate for the invoice_date field, and the red box is a token in the neighborhood along with the arrow representing the relative position. Each of the other tokens (‘number’, ‘date’, ‘page’, ‘of’, etc along with the other occurrences of ‘invoice’) are part of the neighborhood for the invoice candidate. モデルアーキテクチャ 
下図は、構造データ抽出のためのネットワークの一般的な構造を示しています。 候補エンコーディング（i）を構築するために近傍の各トークンは単語埋め込みテーブル（a）を使用して埋め込まれます。各近傍の相対位置（b）は、きめ細かい非線形性をキャプチャする2つの完全に接続されたReLUレイヤーを使用して埋め込まれます。各近傍のテキストと位置の埋め込みは連結されて、近傍エンコーディングを形成します（d）。Self Attentionメカニズムは、各近傍のネイバーフッドコンテキストを組み込むために使用され（e）、max-poolingを使用して近傍エンコーディング（f）に結合されます。。ページ上の候補の絶対位置（g）は、隣接ノードの位置埋め込みと同様の方法で埋め込まれ、候補エンコーディング（i）の近傍エンコーディングと連結されます。最終スコアリングレイヤーは、フィールド埋め込み（k）と候補エンコーディング（i）の間のコサイン類似度から計算し、0から1の間に再スケーリングします。 <img height="517" src="/p/pp3hvyi28bktri7r6vuv-0e25a554.png" style="width:640px;height:517px;" width="640" alt="pp3hvyi28bktri7r6vuv-0e25a554.png" /> 結果 トレーニングと検証には、さまざまなレイアウトの請求書の内部データセットを使用しました。見えないレイアウトに一般化するモデルの能力をテストするために、トレーニングと検証のセットから切り離されたレイアウトの請求書のテストセットを使用しました。いくつかの重要なフィールドでこのシステムからの抽出した値のF1スコアは以下のようになりました。

<table align="center"><tbody><tr><td>フィールド</td>
			<td align="center">F1スコア</td>
		</tr><tr><td>料金</td>
			<td align="center">0.801</td>
		</tr><tr><td>配送日</td>
			<td align="center">0.667</td>
		</tr><tr><td>期日</td>
			<td align="center">0.861</td>
		</tr><tr><td>請求書の日付</td>
			<td align="center">0.940</td>
		</tr><tr><td>invoice_id</td>
			<td align="center">0.949</td>
		</tr><tr><td>注文書</td>
			<td align="center">0.896</td>
		</tr><tr><td>合計金額</td>
			<td align="center">0.858</td>
		</tr><tr><td>total_tax_amount</td>
			<td align="center">0.839</td>
		</tr></tbody></table> 上の表からわかるように、モデルはほとんどのフィールドでうまく機能します。ただし、delivery_dateなどのフィールドには改善の余地があります。追加の調査により、このフィールドがトレーニングデータの例の非常に小さなサブセットに起因することが明らかになり、追加のトレーニングデータを収集することで精度を改善できると考えています。

ドキュメントの構造データ抽出（AI最新論文読解 No.11）

人気記事ランキング

YOLOv5 登場！このプロ…

噂のNotionですっきり、A…

PyTorchの躍進を紐解く３…

深層学習はシステム1から…

XGBoost（GBDT）とランダ…

いいね！ランキング

XGBoost（GBDT）とランダムフォレストから…

ディープラーニングを学び始めた方へ　東…

深層学習はシステム1からシステム2へ

なぜZoomは40分で切れるのか？

DETR : transformerが組み込まれた物体検…

ユーザーランキング

タグランキング

深層学習

ディープラーニング

AI

deeplearning

Transformer