DocIE@XLLM25: In-Context Learning for Information Extraction using Fully Synthetic Demonstrations
- 文書単位の情報抽出（Information Extraction; IE）で、手作業の注釈を使わずに、合成デモだけで in-context learning を行う試みである。
- Wikipedia の要約から約 5 千件の合成注釈データを作り、検索で近い例を 1 件選んで、長文からエンティティと関係を抽出する。
- 結果は控えめで、とくに関係抽出は低い。論文の価値は、うまくいった話よりも、現在の大規模言語モデルがどこでつまずくかを丁寧に示した点にある。
論文の面白いところ
この論文は、合成データを作れば文書レベルの情報抽出が簡単に解ける、という調子では書かれていない。むしろ、合成デモ、検索、推論向け言語モデルを組み合わせても、長文から関係三つ組を安定して取り出すのは難しい、という報告になっている。著者らは DocIE shared task のゼロショット設定を保つため、訓練用の手作業注釈を使わず、Wikipedia Vital Articles の要約から別の注釈データベースを作った。そこから入力文書に似た例を検索し、DeepSeek-R1-Distill-Qwen2.5-32B に 1 件の見本として与える。設計は素直で、実装の見通しもよい。一方で、出力 JSON が壊れる、関係の主語と目的語が入れ替わる、存在しないエンティティを関係に使う、といった細かな失敗が目立つ。ここが実務に近い。モデルが正しい答えを知らないというより、長い文書を相手に、形式、照応、型、関係方向を同時にそろえることが難しいのである。論文はその難しさを、失敗率と評価値の両方から記録している。
問題設定
対象は Document-level Information Extraction（DocIE）shared task である。入力は長い非構造文書と、抽出すべきエンティティ型および関係型のスキーマである。システムは文書中のエンティティを見つけ、その型を付け、さらにエンティティ間の関係を三つ組として出す。訓練時に与えられるデータは、テスト時のスキーマやドメインとは異なるため、そのまま教師ありで覚える設定ではない。著者らはこの条件をより厳しく扱い、共有タスクの訓練データを推論パイプラインに使わない。代わりに、手作業でない合成注釈を作り、それを in-context learning の見本にする。ここで難しいのは、エンティティ抽出だけではない。同じ実体の別表現をまとめる照応解決、型の一貫性、関係の向き、JSON として機械処理できる出力を、同時に満たす必要がある。短い文ならまだしも、文書単位になると小さな破綻が後段の評価を崩してしまう。
提案手法
手法は、合成注釈データベースの構築と、検索にもとづく in-context 推論に分かれる。合成データの原文には、Wikipedia Vital Articles Level 4 の約 1 万件の要約を使う。各要約に対して DeepSeek-R1-Distill-Qwen2.5-32B をゼロショットで呼び出し、エンティティ型、関係型、本文中のメンション、エンティティ一覧、関係三つ組を JSON として生成させる。メンションは HTML/XML 風のタグで本文中に埋め込み、エンティティ ID によって照応を表す。関係三つ組には自然言語の説明文も付けさせ、後処理で向きや意味の検査に使う。検証では、メンションが実際に本文に現れるか、三つ組の主語と目的語が既存エンティティ ID を参照しているかを確認する。さらに、関係の説明文に対して、正向き、逆向き、対称、どれでもない、という選択式の確認を行う。推論時には、入力文書に近い合成デモを all-MiniLM-L6-v2 で検索し、1 件だけプロンプトに入れる。長文では形式が崩れやすいため、最初の呼び出しで冒頭段落を注釈し、次の呼び出しで全文と冒頭注釈を渡して完成させる。
結果
合成データ作成では、初期注釈後に 5,114 文書が残り、後処理後の最終データは 5,010 文書になった。含まれるエンティティは約 59,000 件、エンティティ型は 3,466 種、関係三つ組は約 30,000 件、関係型は 7,103 種である。DocIE テストセットでは、エンティティ識別の F1 が 32.86%、エンティティ分類の F1 が 16.19% だった。関係抽出はさらに難しく、general 設定で F1 3.29%、strict 設定で F1 3.01% にとどまった。共有タスクでの順位は 4 位である。出力が妥当な形式として解析できた文書は 63.91% で、形式エラーは無視できない規模だった。Re-DocRED でも傾向は似ており、全体では関係抽出の F1 が general で 2.98%、strict で 1.85% だった。有効な出力だけに限るとエンティティ分類 F1 は 54.44% まで上がるが、関係抽出は general で 6.87%、strict で 4.26% である。著者らの結論は慎重で、合成デモは資源として有用だが、文書レベルのゼロショット情報抽出はなお難しい、というものになっている。
具体例
- 「エンティティ」は、本文中で名の付く対象である。例では The University of Vienna、Vienna、Austria、Duke Rudolph IV などがそれに当たる。
- 「エンティティ型」は、その対象の種類である。The University of Vienna なら Educational institution、Vienna なら Location といった形で付く。
- 「メンション」は、本文に実際に出てくる表現である。同じ大学を The University of Vienna と Universität Wien の両方で表す場合、同じ ID にまとめる。
- 「照応解決」は、別の表現が同じ実体を指すことをそろえる処理である。論文ではエンティティ ID によってそれを表している。
- 「関係三つ組」は、主語、関係、目的語の組である。例として (The University of Vienna, located_in, Vienna) が挙げられる。
- 「関係の向き」は重要である。founded_by では、大学が主語で創設者が目的語になるので、逆にすると意味が変わる。
- 「自然言語の説明」は、三つ組を検査するための手がかりである。"The University of Vienna was founded by Duke Rudolph IV." のような文を後で照合する。
- 「合成デモ」は、人手で作った見本ではなく、言語モデルが Wikipedia 要約から作った注釈例である。
- 「検索にもとづく in-context learning」は、入力文書に似た合成デモを 1 件だけ選び、回答形式の見本としてプロンプトに入れる方法である。
- 「parseable output」は、後段のプログラムが JSON として読める出力を指す。内容が良くても、括弧や引用符が壊れると評価に載らない。
- この論文の実例は、合成データが役に立つ可能性と、形式を守らせるだけでも難しいという現実を同時に示している。