今週のTOPIC

[論文] Learning Loss for Active Learning

• CVPR2019

• 不確実性サンプリングの文脈で、予測結果に対する損失の大きいデータをサンプリングするため、ラベル無しデータに対する損失の大きさを予測したい

• NNに損失予測モジュールを付与し、本来予測したいラベルに加えて損失の大きさを同時に学習する手法を提案
• 予測スコアではなく中間表現を使っているので、分類モデルだけでなく物体検出などの複雑なタスクにも適用可能

• 手法
• 隠れ層の出力を変換（GAP → FC → ReLU → concat → FC）し、損失の予測値を出力
• 損失予測の損失関数は、MSEで直接損失値を当てにいくのではなく、損失の大小の順序関係を当てにいく設計になっている



• i, j に対する予測された損失が実際の損失の大小関係と異なる場合に、損失予測の損失値が発生
• サイズBのミニバッチを2データずつのペアに分けて、それぞれ比較して計算
• 最終的な損失は、model側の予測損失と、損失予測モジュールの予測損失との重み付け和となる
• active learningのステップが進むに従って、損失予測損失に関する重みは小さくする

• 実験結果

• 左から順に、画像分類、物体検出、人間の姿勢推定

• 最終到達精度は提案手法が最も高い

• 画像分類では、初期フェーズでも提案手法が高い

• 課題: 物体検出、姿勢推定の複雑なタスクでは、損失予測精度が比較的低くなるらしい

[記事] LLMエージェントのデザインパターン、Agentic Design Patternsを理解する

Devin や swe-agent、GitHub Copilot Workspace など、エージェント型の実際に動くプロダクトが徐々に出てきていますが、そのデザインパターンの一つについてまとめた記事。

Agenticワークフローとはイテレーティブに問題解決を図っていくフローのことを指し、

Reflection, Tool Use, Planning, Multi-Agent Collaboration のデザインパターンを駆使しながらフローを構築するといったことが想定されています。

デザインパターンの中でも、ReflectionとTool Useは比較的信頼性の高いデザインパターンとされ、PlanningとMulti-agent collaborationはエージェントの能力を大きく拡張する可能性を持つものの、まだ発展途上の段階にあると考えられています。

確かに Tool Use は結構前から比較的多く論文が出ていたり OpenAI ChatGPT でも plugin が早期に導入されたことからも比較的前例がある。

 

実際にデザインパターンを組み合わせながらフローを構築した実例も紹介されている

LayoutLLM: Layout Instruction Tuning with Large Language Models for Document Understanding(CVPR’24)

概要

• 文書理解のための、大規模言語モデル(LLM)/マルチモーダル大規模言語モデル(MLLM)ベースの手法であるLayoutLLMを提案

• LayoutLLMの核となる要素は2つ
• Layout instruction tuning
• Layout chain-of-thought(LayoutCoT)

• Layout instruction tuningは、instruction tuningを通じて、レイアウト情報を考慮した事前学習(Layout-aware pre-training)とファインチューニング(Layout-aware SFT)を行う手法であり、既存のLLM/MLLMベースの手法に比べ、レイアウト情報を明示的に扱えるようになった

• LayoutCoTでは、LayoutLLMの回答プロセスを段階的に行うことで、回答に信頼性と解釈可能性が加わり、対話的に修正を行うことで、より正確な回答を生成できるようになった

• ゼロショットでの文書理解に関する標準的なベンチーマーク実験の結果、オープンソースの7B LLM/MLLMを使った既存の手法を大幅に上回った

Introduction

LLM/MLLMを使ったDocument AI

• Document Question Answering(docVQA)やDocument ParsingなどのDocument AIと呼ばれるタスクが学術界や産業界などで注目を集めている
Document AIについてはこちらのブログにて紹介されてます！

• Document AIの各タスクは、大規模データセットでの事前学習によって優れた性能を達成しているが、特定の下流タスクに向けにファインチューニングする必要がある

• 一方で、ChatGPTなどのLLMやGPT-4VなどのMLLMは、ファインチューニングせずとも、様々なタスクでゼロショット性能を示しており、Document AIも例外ではない
• LLMの場合、外部のOCRなどでテキストを検出して、フラットなプレーンテキストとして質問と共に直接プロンプトとして与えて回答を生成
• レイアウト情報を与えたいときは、bboxの座標をテキストとして使ったりもできる
• MLLMの場合、Visual Encoder(ViTやCLIP)と統合し、文書画像とテキストのペアを使って事前学習したり、VQAデータセットでファインチューニングすることでそこそこの性能

• とはいえ文書のレイアウト情報をうまく活用できていないため、十分な結果が得られないことが多い
• LLMにフラットなプレーンテキストを与える方法はレイアウト情報を失ってしまう
• MLLMは、画像としてグローバルなレイアウト情報を与えているが、ローカルなレイアウト情報がうまく伝わらず、細かい部分の推論に失敗しがち
• 明示的にレイアウト情報を事前学習やファインチューニングに取り込みたいし、推論したい

LayoutLLMの提案

• LayoutLLMの核となる要素は2つ
• Layout instruction tuning
• Layout chain-of-thought(LayoutCoT)

• Layout instruction tuningは事前学習とファインチューニングによる2ステージの文書理解のためのinstruction tuning
• 事前学習は、Layout-aware pre-training
• ファインチューニングは、Layout-aware supervised fine-tuning(SFT)

• LayoutCoTは、LayoutLLMに一気に最終的な回答を推論させるのではなく、推論の過程を段階的に示させる手法

本論文の貢献

1. Layout Instruction Tuningにおいて、異なる粒度のレイアウト情報を考慮した事前学習タスクを用いることで、グローバルなレイアウト情報とローカルなレイアウト情報の両方を効果的に獲得することができた

2. LayoutCoTによって、まず質問に関連する文書中の領域に注目し、その領域の特徴を活用しながら、段階的な思考プロセスで正確な回答を生成できるようになり、それによる解釈可能性の広がりから、推論結果を信頼性の向上や、対話的な修正が可能になった

3. ゼロショットの文書理解タスクにおける実験結果から、LayoutLLMが既存のLLM/MLLMベースの手法を大きく上回ることを示した

LayoutLLMのアーキテクチャ

• LayoutLLMでは、document pre-trained model()というエンコーダに、文書画像()とそれに対応するテキスト()とレイアウト()を入力し、マルチモーダルな埋め込みを取得(, )
• とは、大量の画像とテキストとレイアウトを用いて事前学習したモデルのことで、ここではLayoutLMv3を使用

• によって得られたとは、それぞれ異なるMultilayer perceptron(, )でとに射影される(LLaVA由来の非常にシンプルな設計)

• とは質問の埋め込み(instruction embeddings)のと共に、LLMに入力され、回答の埋め込みが生成される

Layout Instruction Tuning

Layout-aware pre-training

• 文書レベル、領域レベル、セグメントレベルの異なる粒度のレイアウト情報を考慮した3つの事前学習戦略で、それぞれが複数のタスクで構成される(計7個🤗)

• 基本的には、タスクごとに文書画像に対する特定の質問フォーマットがあり、それに対して回答を生成するようなinstruction(Q&A)形式で事前学習を行う

• 文書レベル
• Document Dense Description(DDD)とText and Layout Reconstruction(TLR)の2つのタスクで事前学習
• DDDは、文書画像全体に対するcaptioningを生成
• 文書用にチューニングされたLLaVARというMLLMの平均10倍の長さのキャプションで学習
• GPT-3.5 Turboでキャプション生成
• TLRは、文書のテキストとレイアウトの再構成
• の各埋め込みを”<{box}, {text}>”という形式で再構築し、その結果と入力文書の実際のテキストとレイアウトのペアを比較し、lossを計算して学習
• 文書全体のグローバルなレイアウト情報を獲得

• 領域レベル
• Document Layout Analysis(DLA)とTable Understanding(TU)の2つのタスクで事前学習
• DLAは、レイアウトの種類に基づいてレイアウトの領域とその領域の種類を回答
• 論文だったら、図の場所とか指定したbbox内の図の種類など
• TUは、テーブル領域における行と列の情報を回答
• テーブルの行数や列名など
• グローバルとローカルの間くらいのレイアウト情報を獲得

• セグメントレベル
• Masked Vision Language Modeling(MVLM)とMask Position Instruction(MPI)とGeometric Layout Instruction(GLI)の3つのタスクで事前学習
• MVLMは、入力テキストをランダムにマスキングし、その部分のテキストを回答
• MPIは、入力テキストのbboxの座標を回答
• GLIは、ランダムにテキストを2つを選択し、それらのbbox間の方向や距離を回答
• テキスト単位のローカルなレイアウト情報を獲得

Layout-aware supervised fine-tuning(SFT)

• 既存の文書ベースのMLLMにおけるファインチューニングでは、特定の下流タスクの質問に対して、一気に最終的な回答まで推論させて学習するので、レイアウトを考慮するステップを飛ばしてしまい、推論のプロセスでレイアウトを明示的に考慮できていないという課題がある

• LLMの推論能力を高めるために、段階的に推論を行う手法であるChain-of-thought(CoT)に着想を得て、LayoutLLMではLayoutCoTを採用したLayout-aware supervised fine-tuning(SFT)を提案
• Chain-of-Thought(CoT)とは
• LLMに複雑な質問に回答させる際に、一気に最終的な回答を推論させるのではなく、推論の過程を段階的に示させる手法
• タスクを解くために必要な中間的な思考ステップを言語化させることで、LLMの思考プロセスを人間が理解しやすくなり、回答の信頼性や解釈可能性が高まる

• LayoutCoTでは、レイアウト情報をCoTの各中間ステップに明示的に組み込んでおり、レイアウトを根拠とした正確な回答を生成することを可能にした

• 具体的にはLayoutCoTは3つの段階的な思考の中間ステップを含む
1. Question Analysis: 文書画像と質問を照らし合わせ、レイアウトや質問のタイプを分析し、詳細に理解することで、その後のステップに方針を与える
ステップ2. Relevant Area Concentration: ステップ1でのレイアウトや質問の詳細情報から、それと関連する文書内の領域を探し、その領域の位置情報を生成する
ステップ3. Answer Formation: ステップ1でのレイアウトの情報とステップ2での注目領域の情報を使うことによって、探索範囲を大幅に狭めつつ、正しい回答を生成する

• 文書レベル、領域レベル、セグメントレベルの異なる粒度の3つのレイアウト情報を獲得することを目的とした事前学習が、この3つのステップに対応してるっぽい

• LayoutCoTを用いたLayout-aware SFTは、LayoutLLMの文書理解能力の向上だけでなく、解釈性を向上させ、推論の信頼性の向上や対話的な修正が可能である

LayoutCoT用アノテーションの構築

• LayoutCoTを使ったファインチューニングには、文書データ、レイアウト情報、Q&Aのテキストが必要だが、手動でアノテーションするのは困難

• そこで、公開データセットとGPT-3.5 Turboを用いて、LayoutCoTの段階的なレイアウトに関する中間プロセスを持つデータを自動的に生成する手法を提案

• 利用できる公開文書データセットには以下の3つのタイプがあり、これらのデータのテキストやレイアウトをGPTで理解できるフォーマットにし、アノテーションする
• HTML、画像、Machine Reading Comprehension(MRC)
• MRCとは、機械が人間のように自然言語で書かれたテキストを読み、理解し、そのテキストに関する質問に答えられるようにするNLPの研究分野

アノテーション手順

1. Document Representation: テキストとBBox
• HTMLは、文書を正確に表現できる形式言語なので、pdfに変換してからpdfパーサでテキストとbboxを取得
• 画像は、オリジナルのデータセットでアノテーションされてるテキストとbboxを使う

2. QA & Text CoT Generation: Q&AとTextCoT
• TextCoTとして、LayoutCoTと同じ段階的な思考の中間プロセスをアノテーション
• ステップ1(Question Analysis): 質問の分析
• ステップ3(Answer Formation): 領域からの回答の生成
• TextCoTの段階では、レイアウトの情報を含めることができないので、領域探索のためのステップ2(Relevant Area Concentration)は、後述の処理でアノテーション
• MRCには、文書を表現するテキストと、それに関するQ&Aのペアが含まれているので、それをそのまま使う。回答までの思考プロセスも含まれているので、それをTextCoTとして使う
• HTMLと画像の文書データに関しては、Q&AおよびTextCoTがないので、GPTに生成してもらう

3. LayoutCoT Generation: LayoutCoT
• LayoutCoTのステップ1とステップ3は、TextCoTのステップ1, ステップ3をそのまま使う
• LayoutCoTのステップ2としては、ステップ1とステップ3に関連するbboxの座標を全て使う

4. Document Image Generation: 文書画像
• HTMLとMRCテキストを画像に変換

実験

データセット収集

• 前提として、LayoutLLMのレイアウトを考慮した事前学習データは、一般に公開されている文書データセットから作成しており、下流ベンチマークのデータを使っていない

• 領域レベルの事前学習を除いて、文書レベル、セグメントレベルのタスクの多くはself-supervisedであるため、元のデータセットの画像、pdfやそれに対応するOCRやpdfをパースしたテキストとレイアウト情報のみ使用
• PubLayNet、DocLayNet、Docbank、RVL-CDIP、DocILEからランダムサンプリング

• 全体で570万のinstruction(Q&A)があり、文書レベル、領域レベル、セグメントレベルのタスクの比率は1:4:4

• HTMLデータは、GPTで自由生成

• 文書画像データは、PubLayNet、DocLayNet、Docbank、RVL-CDIP、DocILEからランダムサンプリング

• MRCデータは、FeTaQAからランダムサンプリング

• GPT-3.5 Turboで、それぞれのデータからLayoutCoTを生成

• 全体で30万のinstructionがあり、HTML、文書画像、MRCの比率は、5:4.5:0.5

学習

• 画像とレイアウトのエンコーダ(DocPTM)として、LayoutLMv3-large

• LLM backboneは、Vicuna-7B-v1.5の重みで初期化

• DocPTMとLLM以外のパラメータはランダムに初期化し、事前学習ではLLM以外のパラメータを更新

• ファインチューニングでは、DocPTMをフリーズさせて、それ以外のLLMを含むパラメータを更新

評価

• 実応用を考えるとゼロショット能力が大事

• 標準的なベンチマークのDocVQAとVisual information Extraction(VIE)で実験
• DocVQAは、DocVQAとVisualMRC
• VIEは、FUNSD、CORD、SROIE
 

定量的評価

• LayoutLLMが全てのベンチマークで、既存のLLMs/MLLMsベースの手法を大幅に上回った

• そもそもLLMs/MLLMsを比較すると、LLMにフラットなプレーンテキストのみ与えた場合が一番良かったりしている
• 文書画像から正確なテキスト情報を得られていないから
• フラットなテキストに加え、レイアウトをテキストとして与えても良くなったり、悪くなったりするので、安定はしていない
 

定性的評価

• LayoutLLMは、LayoutCoTによって、段階的に関連する領域に注目して、回答を生成できるようになっている
• 上の図を見ると、文書中に答えがないときはちゃんとないって言えている
• 関連する領域をちゃんと見ることができているからこそ
 

対話による結果の修正

• LayoutLLMは段階的に推論するので、途中のプロセスで間違えていたら修正することができる

• 上の図の(a)では、”vender”というキーワードが2箇所あるために、結果が間違ってしまっているが、間違えた理由としては質問中の”left bottom”というキーワードを見逃していることがわかる
• 普通に間違えることもあるが、なぜ間違えているかわかりやすい

• (b)のようにそれを修正するように指示をすると、ちゃんと読み取れるようになっている

まとめ

• ChatGPTとかに読み取りを依頼すると間違えることもあったが、文書のレイアウトを理解し、細かいところまで詳細に読み取ることができるようになっていてよき

• モデルの解釈可能性の議論のところは、DonutとかUDOPみたいなend-to-endモデルにも同じ課題があり、実際に業務上で使うとなると少し使いにくい部分はあるかなと思っていたが、それも改善が進んでいてよき

• アノテーションにはGPT-3.5 Turboをかなり使っていて、試してみる価値あるかもしれない