The 2nd Automated Verification of Textual Claims (AVeriTeC) Shared Task: Open-weights, Reproducible and Efficient Systems

生成日:

The 2nd Automated Verification of Textual Claims (AVeriTeC) Shared Task: Open-weights, Reproducible and Efficient Systems

Abstract(日本語訳)

第 1 回 Automated Verification of Textual Claims(AVERITEC)shared task では、参加チームが各主張について Web から証拠を検索し、その真偽を予測するシステムを開発した。実世界の主張に対する自動ファクトチェックには進展があった一方で、提案されたシステムの大半は closed-weights の大規模言語モデルに依存しており、そのため実行コストが高く、再現性も低かった。この問題を改善するため、本年の AVERITEC shared task では、システムが 23GB RAM の単一 GPU で実行可能な open-weights モデルだけを用いること、また事前に構築された knowledge store から検索した証拠を添えて、1 分以内に判定を返すことを求めた。shared task には 7 件の提出があり、そのうち 6 件は、指定したハードウェア上で 1 主張あたり 1 分未満で動作しつつ、test set において baseline の正解率を上回った。優勝したのは CTU AIC チームで、AVeriTeC score は 33.17% であった。本論文では shared task を詳述し、主要な知見を示す。

論文の面白いところ

この論文の特徴は、ファクトチェックの性能競争を、実際に運用できる条件へ近づけている点にある。第 1 回では商用 API や closed-weights LLM を使うシステムが目立ち、成績は高くても、費用、再現性、プライバシー、遅延の面で研究評価と現場利用の距離が残った。第 2 回では、推論時に外部 API を呼ばず、AWS g5.2xlarge 相当の A10G 23GB GPU で動くことを条件にした。これは単なる制約ではなく、報道機関やファクトチェック組織が実際に導入できるかを問う設計である。さらに、検索対象を商用検索エンジンへの逐次アクセスではなく、事前に集めた knowledge store に限定したため、参加者間の比較がしやすい。評価も表層的な token overlap から、原子的な事実の一致と被覆をみる Ev2R に移っている。完全ではないが、人手評価との相関は前回より明らかに改善した。結果として、論文は「強いモデルを使えばよい」という話ではなく、検索、証拠構成、判定、実行時間を同時に扱う shared task の記録になっている。

問題設定

タスクは、与えられた主張とメタデータ、たとえば発言日や発言者に対し、証拠を検索し、最終的なラベルを返すことである。ラベルは Supported、Refuted、Not Enough Evidence、Conflicting Evidence/Cherry-picking の 4 種である。AVERITEC の証拠は、単なる文書 ID ではなく、主張を検証するための question-answer pair として整理される。たとえば、ある温室効果ガス排出量の主張に対して、2007 年の排出量、2017 年の排出量、その後の増減といった複数の問いを立てる形になる。この形式により、multi-hop reasoning を必要とする検証を扱いやすくしている。2025 年の test set は 1,000 件で、2024 年 1 月から 12 月までの新しい主張を含む。training set や過去の test set より時間的に離れており、モデルが事前学習で見た可能性や分布差の問題を意識した作りである。knowledge store は各主張あたり平均 1,019 URL を含み、そのうち平均 593 件に有効な抽出テキストがあるため、検索そのものが大きな課題になっている。

提案手法

本論文は単一の新モデルを提案するものではなく、shared task の設計、baseline、評価方法、提出システムの比較を報告する。baseline は前回上位の HerO に近い三段階 pipeline を用いる。まず LLM による仮想文書生成、BM25、cross-attention reranker を組み合わせて証拠を検索し、次に証拠に基づく検証用の質問を生成し、最後に LLM が説明と判定ラベルを生成する。ただし今回は効率を重視し、Llama-3.1-70B ではなく Llama-3.1-8B を用い、BM25 や reranking の候補数にも上限を置く。評価では、検索証拠の妥当性を Ev2R で測る。Ev2R は検索された証拠と参照証拠を原子的な事実に分解し、参照証拠がどれだけ検索証拠に覆われているかを recall として計算する。AVeriTeC score は、Ev2R recall が閾値 0.5 を超える場合にのみ真偽判定の正解を得点化する。これにより、正しいラベルだけを出しても、根拠となる証拠を十分に返していなければ得点にならない。

結果

提出された 8 システムのうち、7 システムが最終的に再現可能な形で実行された。1 件は構文エラー、インストール手順の欠落、hardcoded path などにより VM 上で動かなかった。7 システムはいずれも 1 主張あたり平均 1 分以内という条件を満たし、6 システムが baseline の AVERITEC score 0.2023 を上回った。最上位は CTU AIC で、平均 53.67 秒、Q+A の Ev2R recall 0.4774、AVeriTeC score 0.3317 を記録した。CTU AIC は量子化を用いず、Qwen3-14B と dense index を使い、制限内で動く最大級の文脈処理を選んだ点が目立つ。一方、EFC は平均 7.01 秒と非常に速く、semantic filtering によって一部の判定で LLM 呼び出しを減らした。全体として、dense retrieval と BM25 を組み合わせる方法、事前計算した embedding index、vLLM や llama.cpp 系の推論基盤、AWQ や GPTQ などの量子化がよく使われた。課題別には、数値主張の得点が他の型より低く、Not Enough Evidence と Conflicting Evidence/Cherry-picking では全システムが 0.1 を超えなかった。人手評価では、検索証拠の relevance は高めだったが、semantic coverage には不足が残り、Ev2R との相関も中程度にとどまった。

具体例

たとえば「英国の新しい Highway Code は、自動車が自転車を追い越す際に 5 フィートの間隔を空けるべきだとしている」という主張が入力されたとする。システムは、発言日以前に公開された文書だけを knowledge store から探し、まず「5 フィートはメートルでいくらか」「Highway Code の新規則は追い越し距離をどう定めているか」「速度によって必要な距離は変わるか」といった検証用の問いを立てる。次に、関連する政府文書や解説記事から、1.5 メートル、30mph 以下、より速い場合はさらに距離を取る、といった証拠を集める。期待される出力は、主張が十分に支持されるか、あるいは単位や条件の省略により一部だけ正しいかを、証拠付きで示す判定である。間違えやすい点は、単に「5 フィート」という語を含む文書を拾うだけでは検証にならないことである。5 フィートと 1.5 メートルの換算、速度条件、規則の適用範囲を合わせて確認しなければならない。また、見つからない問いに対して「No answer could be found」と返すだけでは、Ev2R の coverage が低くなり、正しいラベルを出しても得点につながりにくい。この例は、ファクトチェックが分類問題だけではなく、証拠をどの粒度でそろえるかという検索と説明の問題でもあることを示している。