MDBench: A Synthetic Multi-Document Reasoning Benchmark Generated with Knowledge Guidance
- MDBench は、複数文書をまたぐ推論を評価するための、合成生成された question answering(QA)ベンチマークである。
- 表形式の構造化知識を種にして、GPT-4o により multi-hop、数値、時間、知識集約、曖昧な対応づけを含む問題へ変換し、それを自然文の文書集合へ展開する。
- 現行の強い LLM でも文書版ではおよそ 60% の exact match にとどまり、表では解ける情報が自然文の複数文書になると難しくなることを示している。
Abstract(日本語訳)
自然言語処理の評価は、強力な大規模言語モデル(LLM)の普及に大きく支えられて、著しい進展を遂げてきた。LLM の推論能力が急速に拡大するにつれて、新しい評価ベンチマークの優先度は高まっている。とりわけ、LLM がより長いコンテキスト入力を扱えるようになったことを考えると、複数文書(multi-document, MD)推論はきわめて重要な領域であるが、この設定でモデルの振る舞いを厳密に調べるベンチマークは少ない。さらに、複数文書設定では、長い入力にアノテーションを付ける費用が高いため、ベンチマーク作成は従来から難しかった。
本研究では、複数文書推論タスクにおける LLM 評価のための新しいデータセットである MDBench を導入する。MDBench は、新しい合成生成プロセスによって作成されており、難しい文書集合とそれに対応する question-answer(QA)例を、制御可能かつ効率的に生成できる点に特徴がある。本手法は、圧縮された構造化シード知識に対して、LLM 支援の編集を加えることで、複数文書に特有の推論上の難しさを誘発する。続いて、この構造化知識を自然文の表層形式へ変換し、文書集合と対応する QA 例を生成する。著者らは、主要な LLM とプロンプト手法の振る舞いを分析し、MDBench が、比較的短い文書集合であっても、すべての手法に大きな課題を与えることを示した。また、知識誘導型の生成手法により、(1)複数文書に特有の推論能力を対象にした分析を容易に行えること、(2)新しい課題や将来のモデル改善に合わせてすばやく適応できることも確認している。
論文の面白いところ
この論文の中心は、複数文書推論の評価を、単に既存文書から問題を切り出す作業としてではなく、構造化知識から制御して作る作業として定式化した点にある。通常の multi-hop QA では、Wikipedia などの公開文書を集め、人手で問いを作ることが多い。その場合、作成費用が高く、公開後には学習データへの混入も避けにくい。MDBench はこの制約を、表を種にして新しい文書集合を生成することで緩和する。
興味深いのは、最初から自然文を生成するのではなく、表の行を「のちに文書になる知識単位」と見なしている点である。表の段階で、別の日付の売上を足す、同じ対象を別表現で参照する、順序に依存する、といった条件を入れておけば、自然文化されたあとにも推論の筋道を追える。これは、RAG や長文 QA の評価でしばしば問題になる「答えがどこにあるかは分かるが、なぜそうなるかが曖昧」という状況をいくらか避ける設計である。
また、文書版と表版を比較している点も読みやすい。表では GPT-4o が 71.2% の exact match を示す一方、文書版では 60.0% に下がる。つまり、同じ知識であっても、自然文の冗長さ、文書境界、順序、参照の曖昧さが加わると、モデルの負担はかなり増える。この差は、長コンテキストを読めることと、複数文書を安定して推論できることが同じではないことを示している。
問題設定
対象は、複数の短い文書を入力として与え、その全体から質問に答える QA タスクである。単一文書の読解であれば、答えを含む段落を見つけ、局所的に照合すれば済む場合が多い。複数文書推論では、文書 A の値と文書 B の値を足す、文書 C の時点を基準に文書 D を解釈する、別名で書かれた同じ実体を対応づける、という操作が必要になる。
著者らが問題にするのは、この種の能力を測る既存ベンチマークが少なく、しかも作成に人手を要することである。さらに、広く公開されたベンチマークは、LLM の事前学習や後続学習に混入する危険がある。モデルが本当に文書を読んで推論したのか、既に見た知識を再生したのかが判別しにくくなる。
MDBench は、この問題を「評価例を新しく、制御可能に作る」問題として扱う。著者らは TabFact の Wikipedia 由来の表を出発点にし、5 から 17 行、3 から 9 列の扱いやすい表を選ぶ。各行は最終的に 1 つの文書に対応する。質問は 1 つの文書だけで答えられないように作られ、複数行、すなわち複数文書の依存関係を使って解く必要がある。
提案手法
MDBench の生成手順は四段階からなる。第一に、表形式のシード知識を集める。第二に、GPT-4o を用いて表を編集し、複数文書推論に必要な依存関係を加える。第三に、編集済みの表の各行を自然文の文書へ変換する。第四に、生成された例が内部的に一貫しているかを自動検証し、不安定な例を除く。
知識拡張では、著者らは五種類の推論を明示的に使う。multi-hop 推論、数値推論、時間推論、知識集約、soft reasoning である。soft reasoning は、完全に明示されていない対象対応や、文脈からのゆるい推定を含む。たとえば、あるチーム名が直接書かれず、チームカラーや前日の記述から結びつけられるような場合である。
品質管理もこの論文の重要な部分である。生成された表、編集計画、質問、答え、文書集合について、GPT-4o による検証プロンプトを通す。さらに、元の表と編集計画、生成表、生成文書集合という複数の oracle 設定で答えが一致するかを見る。どれかで生成された正解と合わない例は捨てる。この自動フィルタにより生成例の約 32% が残り、最終的には 300 件の人手検証済み例と 700 件の機械検証済み例からなる 1,000 件のベンチマークが作られている。
結果
文書版 MDBench では、最良の exact match はおよそ 60% にとどまる。GPT-4o は全体で 60.0% の exact match、zero-shot chain-of-thought では 62.1% を示した。GPT-o1 は exact match では 59.2% だが、部分点を含む accuracy では全体 82.2% と最も高い。Gemini-2.5-Flash は one-shot chain-of-thought で 60.2% の exact match に達している。
小さい、または古いモデルは全体に苦戦する。LLaMA-3-8B-Instruct は overall exact match が 41.0%、LLaMA-3-70B-Instruct は 48.9% である。GPT-3.5-Turbo も 42.1% にとどまる。chain-of-thought プロンプトは GPT-4o や GPT-o1、Gemini-2.5-Flash のような強いモデルでは役に立つことがあるが、弱いモデルを大きく押し上げるものではない。
表版との比較は、MDBench の性質をよく示している。GPT-4o は表版では 71.2% の exact match を達成するが、文書版では 60.0% に下がる。表の知識を自然文に展開すると、平均トークン長は約 256 から約 2,397 へ増える。情報の量だけでなく、表層形式そのものが推論を難しくしていると読める。
文書の順序と区切りも効いている。文書番号の区切りを除くと GPT-4o の zero-shot 性能は 59.7% から 55.5% に下がり、文書順をシャッフルすると 53.1% まで下がる。GPT-3.5 では文書順の影響がさらに大きい。これは、MDBench の問題が各文書を独立に読むだけでは解けず、文書間の順序や境界を手がかりにする必要があることを示す。
具体例
映画の各国興行収入を扱う例を考える。入力には、「Nightmares of Glory」という映画について、トルコ、ベルギー、ドイツ、オーストリア、オランダ、英国の売上を述べた複数の短い記事が並ぶ。ある記事は「10月25日のドイツの売上は 135,000 ドル」と明示し、別の記事は国名を直接書かずに「前日の同じ市場より 60,000 ドル多い 195,000 ドル」と述べる。質問は「国別の映画売上を順位づけよ」である。
このときモデルは、まず各文書がどの国、どの日付、どの売上を述べているかを取り出す必要がある。次に、国名のない 195,000 ドルの記事が、前日のドイツの記事に接続していることを見つける。さらに、ドイツの売上を 135,000 + 195,000 として合算し、他国の単独売上と比較する。期待される出力は、ドイツ、トルコ、オランダ、オーストリア、ベルギー、英国という順序である。
間違えやすい点は、最大の単独売上だけを見ることである。トルコの 146,200 ドルは単一記事では大きいが、ドイツは二つの記事を足す必要がある。もう一つの誤りは、国名のない記事を無視するか、別の国の売上として扱うことである。MDBench が測ろうとしているのは、まさにこのような、検索、対応づけ、計算、比較が混ざった読みである。