Path: blob/main/transformers_doc/ja/pytorch/document_question_answering.ipynb
4542 views
Document Question Answering
文書による質問応答は、文書による視覚的な質問応答とも呼ばれ、以下を提供するタスクです。 ドキュメント画像に関する質問への回答。このタスクをサポートするモデルへの入力は通常、画像と画像の組み合わせです。 質問があり、出力は自然言語で表現された回答です。これらのモデルは、以下を含む複数のモダリティを利用します。 テキスト、単語の位置 (境界ボックス)、および画像自体。
このガイドでは、次の方法を説明します。
DocVQA データセット の LayoutLMv2 を微調整します。
微調整されたモデルを推論に使用します。
このタスクと互換性のあるすべてのアーキテクチャとチェックポイントを確認するには、タスクページ を確認することをお勧めします。
LayoutLMv2 は、最後の非表示のヘッダーの上に質問応答ヘッドを追加することで、ドキュメントの質問応答タスクを解決します。 トークンの状態を調べて、トークンの開始トークンと終了トークンの位置を予測します。 答え。言い換えれば、問題は抽出的質問応答として扱われます。つまり、コンテキストを考慮して、どの部分を抽出するかということです。 の情報が質問に答えます。コンテキストは OCR エンジンの出力から取得されます。ここでは Google の Tesseract です。
始める前に、必要なライブラリがすべてインストールされていることを確認してください。 LayoutLMv2 は detectron2、torchvision、tesseract に依存します。
すべての依存関係をインストールしたら、ランタイムを再起動します。
モデルをコミュニティと共有することをお勧めします。 Hugging Face アカウントにログインして、🤗 ハブにアップロードします。 プロンプトが表示されたら、トークンを入力してログインします。
いくつかのグローバル変数を定義しましょう。
Load the data
このガイドでは、🤗 Hub にある前処理された DocVQA の小さなサンプルを使用します。フルに使いたい場合は、 DocVQA データセットは、DocVQA ホームページ で登録してダウンロードできます。そうすれば、 このガイドを進めて、🤗 データセットにファイルをロードする方法 を確認してください。
ご覧のとおり、データセットはすでにトレーニング セットとテスト セットに分割されています。理解するためにランダムな例を見てみましょう 機能を備えた自分自身。
個々のフィールドが表す内容は次のとおりです。
id
: サンプルのIDimage
: ドキュメント画像を含む PIL.Image.Image オブジェクトquery
: 質問文字列 - いくつかの言語での自然言語による質問answers
: ヒューマン アノテーターによって提供された正解のリストwords
とbounding_boxes
: OCR の結果。ここでは使用しません。answer
: 別のモデルと一致する答え。ここでは使用しません。
英語の質問だけを残し、別のモデルによる予測が含まれていると思われるanswer
機能を削除しましょう。 また、アノテーターによって提供されたセットから最初の回答を取得します。あるいは、ランダムにサンプリングすることもできます。
このガイドで使用する LayoutLMv2 チェックポイントは、max_position_embeddings = 512
でトレーニングされていることに注意してください ( この情報は、チェックポイントの config.json
ファイル) で見つけてください。 例を省略することもできますが、答えが大きな文書の最後にあり、結局省略されてしまうという状況を避けるために、 ここでは、埋め込みが 512 を超える可能性があるいくつかの例を削除します。 データセット内のほとんどのドキュメントが長い場合は、スライディング ウィンドウ戦略を実装できます。詳細については、このノートブック を確認してください。 。
この時点で、このデータセットから OCR 機能も削除しましょう。これらは、異なるデータを微調整するための OCR の結果です。 モデル。これらは入力要件と一致しないため、使用したい場合はさらに処理が必要になります。 このガイドで使用するモデルの。代わりに、OCR と OCR の両方の元のデータに対して LayoutLMv2Processor
を使用できます。 トークン化。このようにして、モデルの予想される入力と一致する入力を取得します。画像を手動で加工したい場合は、 モデルがどのような入力形式を想定しているかを知るには、LayoutLMv2
モデルのドキュメント を確認してください。
最後に、画像サンプルを確認しないとデータ探索は完了しません。

Preprocess the data
文書の質問に答えるタスクはマルチモーダル タスクであるため、各モダリティからの入力が確実に行われるようにする必要があります。 モデルの期待に従って前処理されます。まず、LayoutLMv2Processor
をロードします。これは、画像データを処理できる画像プロセッサとテキスト データをエンコードできるトークナイザーを内部で組み合わせています。
Preprocessing document images
まず、プロセッサからの image_processor
を利用して、モデルのドキュメント画像を準備しましょう。 デフォルトでは、画像プロセッサは画像のサイズを 224x224 に変更し、カラー チャネルの順序が正しいことを確認します。 tesseract を使用して OCR を適用し、単語と正規化された境界ボックスを取得します。このチュートリアルでは、これらのデフォルトはすべて、まさに必要なものです。 デフォルトの画像処理を画像のバッチに適用し、OCR の結果を返す関数を作成します。
この前処理をデータセット全体に高速に適用するには、map
を使用します。
Preprocessing text data
画像に OCR を適用したら、データセットのテキスト部分をエンコードしてモデル用に準備する必要があります。 これには、前のステップで取得した単語とボックスをトークンレベルの input_ids
、attention_mask
、 token_type_ids
とbbox
。テキストを前処理するには、プロセッサからのTokenizer
が必要になります。
前述の前処理に加えて、モデルのラベルを追加する必要もあります。 xxxForQuestionAnswering
モデルの場合 🤗 Transformers では、ラベルは start_positions
と end_positions
で構成され、どのトークンがその位置にあるかを示します。 開始点と、どのトークンが回答の最後にあるか。
それから始めましょう。より大きなリスト (単語リスト) 内のサブリスト (単語に分割された回答) を検索できるヘルパー関数を定義します。
この関数は、words_list
と answer_list
という 2 つのリストを入力として受け取ります。次に、words_list
を反復処理してチェックします。 words_list
(words_list[i]) 内の現在の単語が、answer_list (answer_list[0]) の最初の単語と等しいかどうか、および 現在の単語から始まり、answer_list
と同じ長さの words_list
のサブリストは、to answer_list
と等しくなります。 この条件が true の場合、一致が見つかったことを意味し、関数は一致とその開始インデックス (idx) を記録します。 とその終了インデックス (idx + len(answer_list) - 1)。複数の一致が見つかった場合、関数は最初のもののみを返します。 一致するものが見つからない場合、関数は (None
、0、および 0) を返します。
この関数が答えの位置を見つける方法を説明するために、例で使用してみましょう。
ただし、サンプルがエンコードされると、次のようになります。
エンコードされた入力内で答えの位置を見つける必要があります。
token_type_ids
は、どのトークンが質問の一部であり、どのトークンが文書の単語の一部であるかを示します。tokenizer.cls_token_id
は、入力の先頭で特別なトークンを見つけるのに役立ちます。word_ids
は、元のwords
で見つかった回答を、完全にエンコードされた入力内の同じ回答と照合して判断するのに役立ちます。 エンコードされた入力内の応答の開始/終了位置。
これを念頭に置いて、データセット内のサンプルのバッチをエンコードする関数を作成しましょう。
この前処理関数が完成したので、データセット全体をエンコードできます。
エンコードされたデータセットの特徴がどのようなものかを確認してみましょう。
Evaluation
Train
おめでとう!このガイドの最も難しい部分を無事にナビゲートできたので、独自のモデルをトレーニングする準備が整いました。 トレーニングには次の手順が含まれます。
前処理と同じチェックポイントを使用して、AutoModelForDocumentQuestionAnswering でモデルを読み込みます。
TrainingArguments でトレーニング ハイパーパラメータを定義します。
サンプルをバッチ処理する関数を定義します。ここでは
DefaultDataCollator
が適切に機能します。モデル、データセット、データ照合器とともにトレーニング引数を Trainer に渡します。
train() を呼び出してモデルを微調整します。
TrainingArguments で、output_dir
を使用してモデルの保存場所を指定し、必要に応じてハイパーパラメーターを構成します。 モデルをコミュニティと共有したい場合は、push_to_hub
をTrue
に設定します (モデルをアップロードするには、Hugging Face にサインインする必要があります)。 この場合、output_dir
はモデルのチェックポイントがプッシュされるリポジトリの名前にもなります。
サンプルをまとめてバッチ処理するための単純なデータ照合器を定義します。
最後に、すべてをまとめて、train() を呼び出します。
最終モデルを 🤗 Hub に追加するには、モデル カードを作成し、push_to_hub
を呼び出します。
Inference
LayoutLMv2 モデルを微調整し、🤗 ハブにアップロードしたので、それを推論に使用できます。もっとも単純な 推論用に微調整されたモデルを試す方法は、それを Pipeline で使用することです。
例を挙げてみましょう:
次に、パイプラインをインスタンス化します。 モデルを使用して質問への回答を文書化し、画像と質問の組み合わせをモデルに渡します。
必要に応じて、パイプラインの結果を手動で複製することもできます。
画像と質問を取得し、モデルのプロセッサを使用してモデル用に準備します。
モデルを通じて結果または前処理を転送します。
モデルは
start_logits
とend_logits
を返します。これらは、どのトークンが応答の先頭にあるのかを示し、 どのトークンが回答の最後にありますか。どちらも形状 (batch_size、sequence_length) を持ちます。start_logits
とend_logits
の両方の最後の次元で argmax を取得し、予測されるstart_idx
とend_idx
を取得します。トークナイザーを使用して回答をデコードします。