ABEJAでデータサイエンティストをしている藤原です。

弊社は、経済産業省とＮＥＤＯが実施する、国内の生成AIの開発力強化を目的としたプロジェクト「GENIAC（Generative AI Accelerator Challenge）」の1期、2期に続き、3期にも採択され、そこで大規模言語モデルの開発を行っています。3期ではエージェントとして用いるための基盤モデルを開発しており、特にロングコンテキスト処理性能と Planning / Tool Use などの agentic な能力の向上に重点を置いて開発を進めております。

これまでにも、開発の過程で行ったロングコンテキストLLM評価に関するいくつかの検証をブログで公開しています。

今回は、実際にGENIAC3期の基盤モデル開発で使用したロングコンテキスト処理性能の評価タスク・ベンチマークについて説明するとともに、それらの評価を実行できるベンチマークのリポジトリと、新しく作成した評価データセットを公開します。ここでは各種ベンチマーク・タスクのポイントと選定理由、また公開するリポジトリの中身について解説します。

はじめに
本開発で使用したロングコンテキスト評価のベンチマーク・タスクの一覧
各種ベンチマーク選定過程
実装したベンチマークのリポジトリ
まとめ
参考文献
We are hiring!!

はじめに

ロングコンテキストLLMの評価とは？については、以前のブログに詳しく書いています。本開発で使用した評価タスク・ベンチマークは長大な入力を正確に処理する能力を評価するものです。（本ブログでは「長大な入力を正確に処理する能力の評価」を指して「ロングコンテキスト評価」という言葉を使用します。）

本開発で使用したロングコンテキスト評価のベンチマーク・タスクの一覧

ベンチマーク	タスク	評価データセット	対応言語
RULER	Needle-in-a-Haystack (NIAH), QA	合成データセット	英語、日本語
LongBench v2	全タスク	zai-org/LongBench-v2	英語
-	MRCR	openai/mrcr	英語、日本語

各種ベンチマーク選定過程

前提として日本語のロングコンテキスト評価ベンチマーク・データセットがなかったため、日本語のロングコンテキストLLM評価をどのように行うか？というところから考え始めました。初期は「ロングコンテキスト＆日本語に特化した学習の効果が測れる」評価タスク・データセットの設計を検討していましたが、その設計や評価データセットの作成が難しいなどの課題があり、最終的にはそれぞれを分けて評価する方法を取りました。具体的には、日本語で学習した効果は既存の日本語汎用性能を評価するベンチマーク（日本語MT Bench など）で評価し、ロングコンテキスト性能は既存の英語ロングコンテキストベンチマーク・評価タスクとその日本語版で評価する方針としました。

後ほど登場しますが、ロングコンテキスト評価の一部のタスクは本開発の中で日本語版を作成しました。しかしながら、「ロングコンテキスト＆日本語に特化した学習のおかげで性能が変化した」ということを確かめるタスク・ベンチマークを新たに構築するには至らなかったということです。その他、いくつかのロングコンテキスト評価タスク・データセットを試験的に作成しましたが、ベンチマーク自体の良し悪しを検証するところまでリソースが割けなかったため、基本的にこのブログで紹介するロングコンテキスト評価が本開発で使用したものの全てです。

最初にロングコンテキスト評価のベンチマークを探し始めたころは、まずはテクニカルレポートなどで Long Context の性能としてよく記載されているベンチマークを中心に調査をしました。その中で、2025年の6月ごろまでの文献で複数のLLM開発のレポートで用いられていたのが

RULER [1]
HELMET [5]
LongBench / LongBench v2 [2]
MRCR [3] / OpenAI-MRCR[4]

などのベンチマーク・評価データセットでした。その上で、特に評価したいロングコンテキスト性能は

大量の文書やエージェントの長期の行動ログなどの大量のトークンからなる入力（ロングコンテキスト）を与えられたときに、コンテキストが短い場合に比べて性能が低下しないか？
ロングコンテキストかつ難易度の高い問題について、正確に回答することができるか？
長文入力時も日本語出力が安定して行えるか？

の3点に絞りました。各種ベンチマークの概要や選定理由の詳細は後述しますが、おおまかな理由としては、

1 の観点 -> RULER（理由: 入力長を自由に設計できるため）
2 の観点 -> LongBench v2 と OpenAI-MRCR（理由: 当時の優れたオープンウェイトのモデルでも高いスコアが達成できていなかったため）
3 の観点 -> OpenAI-MRCR の日本語版を作成（理由: ある程度の長さの日本語テキストの生成が要求されるタスクなため）

HELMET を用いなかった理由としては、現実的なタスクとして LongBench v2 を採用したこと、後述しますが RULER の中からタスクを絞るときに HELMET と相関の高いものを選んだこと、などが主な理由になります。

以下では、個々のベンチマークの概要と選定理由をお話しします。

1. RULER

どのようなベンチマーク・タスクか？

RULER[1] はモデルが扱える真のコンテキスト長を計測することを目的に設計されているベンチマークです。評価データは自然な長文ではなく、測りたいコンテキスト長まで何らかのテキストを繋ぎ合わせて合成されます。コンテキスト長だけでなく、問題の難易度も変えることができます。

RULER には4つの評価カテゴリーがあります。本開発ではこのうち Retrieval（NIAH）と Question Answering を使用しました。

Retrieval（検索） 長いテキスト（Haystack）中から特定の情報（Needle）を見つけ出す能力を見るタスクで、従来の needle-in-a-haystack (NIAH) テストを拡張したもの。
Multi-hop Tracing（多ホップ追跡） 変数やエンティティの連鎖をたどって答えを導くタスク。文中で複数ステップ分の関係を追跡する必要があり、単純検索以上の文脈理解を評価。
Aggregation（集約） 文脈全体の情報をまとめて要約・集計する能力を見るタスク。例えば頻出語の抽出など、広いコンテキストから意味あるパターンを集める力を評価。
Question Answering（質問応答） 長文コンテキストを含む状況での QA 能力を評価するタスク。既存のQAデータセットに大量のノイズ情報を追加するなどして、モデルが長いコンテキストから適切な答えを導けるかを評価。

Retrieval はいわゆる NIAH テストなどに相当し、長いノイズテキストの中に key, value のペア（「X に紐づく値は100である。」など）を埋め込み、key に紐づく値を回答させる（「問題: X に紐づく値は何か？」など）タスクになっています。問題の難易度はコンテキストに埋め込む key, value の数、問題で解答を要求する query (=key) の数で制御されます。

Multi-hop Tracing は変数に値を代入する式（x1 = 100, x2 = x1, x3= x2, ...）をコンテキストの中に埋め込み、値（100）が割り当てられている変数を全て答えさせるというタスクです。難易度は代入を繰り返す回数（ホップ数）と、そのチェーン全体の本数で制御されます。

Aggregation には共通語抽出（Common Words Extraction; CWE）と頻出語抽出（Frequent Words Extraction; FWE）という2つのサブタスクがあります。どちらもコンテキストに単語をいくつか埋め込んで、その中から出現頻度の高い単語をN個抽出させるようなタスクです。難易度は単語間での出現頻度の差に影響するパラメータによって制御されます。

QA は既存の QA タスクをロングコンテキスト評価に拡張したもので、「参照すべきドキュメント・質問・解答」という3つ組の質問応答の評価サンプルがあるときに、複数のサンプルの「参照すべきドキュメント」を並べたものをコンテキストとして入力し、そのうち一つのドキュメントと紐づいた「質問」に対して回答を生成させるタスクです。明示的に難易度を制御するパラメータはありませんが、既存の QA 評価データセットを用いるため、難易度はその QA データセット自体の難易度に依存しています。

合成評価データについて

RULER では、入力の長さ・問題の複雑度などのパラメータを変えて評価サンプルを合成する設計になっています。入力の長さはLLMに入力するコンテキストの長さであり、1000 トークンを目標の入力長に設定して、それに近づく＆収まるようにノイズテキストなどをプロンプト本体に混ぜていくことで入力長を制御した評価サンプルを合成します。トークン数はトークナイザによって変化するため、基本的には評価したいモデルごとに評価データを合成するような設計になっています。問題の複雑度は解答すべき情報の量や、コンテキスト内での情報の見つけやすさなどで制御されています。

評価サンプルを合成するメリットは

モデルのコンテキスト長ギリギリのトークン長まで評価が可能
評価サンプルの正確さを保証しやすい

の2点が大きいと思います。

通常の固定QAデータセットでは、トークナイザ次第でコンテキスト長が変化します。そのため、モデル間で「同じ入力トークン長」での評価が難しくなります。一方で、合成方式の場合は（ほとんど）同じトークン長で評価・比較することができるようになります。一般的なロングコンテキストLLMのユースケースを考えると、「優れたトークナイザによってコンテキストのトークン長が短くなり評価で有利になる」というのはそのモデルの優れた点と言えるので、トークン長を揃えられることはそれほどメリットになりません。一方で、異なるアーキテクチャ間でモデルのコンテキスト長ギリギリでの性能を比較したい場合などに、トークナイザによる条件の不一致をトークン長という観点では解消できるため、LLM開発の文脈では有用性があります。

また2点目については、例えば10万文字ある文書に対するQAを評価サンプルとして作ろうとすると、その回答の正しさを保証するために10万文字ある文書を読む必要があり、アノテーションのコスト・負担が高くなります。一方で、例えば RULER の QA タスクでは、メインのQAサンプルとそれに回答時にリファレンスとなるドキュメントを核として、無関係なリファレンスドキュメントを差し込む量によってコンテキスト長を制御しています。そのため、本体のQA+リファレンスの長さは数千トークン程度に収まるため、質問に対する回答の品質をある程度保証しやすくなります。（無関係なリファレンスとして追加したものが実は関連していて、回答が変化する or より詳しい回答が可能になり正誤判定が難しくなる、といった可能性はあります。）

デメリットはトークナイザごとに別の評価データを合成すると、モデル間の性能を比較するときに評価データが異なることになるため、少し扱いづらいところがあります。そのため、開発期間中は Qwen3 のトークナイザで合成した評価データで他のモデルの評価も行っていました。

選定理由

基本的には入力長の設計が行えるところが主な理由です。その中で NIAH, QA タスクを選定した理由を説明します。

大前提として、タスクを絞るのは全てのカテゴリー・サブタスクを評価するには時間がかかるためです。ロングコンテキスト評価はその入力長のために推論時間がかなり長くなります。LLM開発期間は大規模なGPUサーバを利用していますが、基本的にはLLMの学習や学習関連の検証にリソースを配分しているため、評価でGPUが長時間埋まってしまうのは避けたいというのがあります。そのため、必要なタスクに絞って評価をすることにしました。

NIAH の評価サンプルは複雑な英語の理解を問うような設計になっていないため、日本語で追加学習したモデルでも英語のまま性能評価に使える可能性があると考えました。その上で、NIAH はさらにサブセットまで限定しているのですが、その際に参考にしたのが HELMET の論文です。論文の中では HELMET の各種タスクと RULER の各種タスクのスコアの相関を調査しており、RULERのタスクの中でも NIAH の Multi-Key (NIAH-MK variant 1~3) のタスクは比較的高い相関を示しています。また、NIAH の Single-Key の variant 2 のサブセットはオリジナルの NIAH と近い設定になっています。このような理由から NIAH の Single-Key variant 2 と NIAH-MK variant 1~3 をピックアップしました。（公開するリポジトリでは Multi-Query, Multi-Value も実行することが可能です。）

QA も同様に HELMET の論文で現実的なタスクとの相関が高いことが示されています。また、QA カテゴリーは既存のQAデータセットを用いて合成する形式なので、日本語のQAデータセットを用いて同じアルゴリズムで合成を行えば日本語での評価が行える設計になっています。そのため、QAカテゴリーについては既存の日本語QAデータセットを用いた日本語版の評価もサポートしました。

2. LongBench v2

どのようなベンチマーク・タスクか？

LongBench v2[2] は、従来の NIAH や抽出型 QA のような検索・局所一致で解けてしまう課題ではなく、長文全体を読んだ上での深い理解・統合・推論を要求するよう設計された、現実寄りのロングコンテキスト・マルチタスクベンチマークです。LongBench v2 は、評価データを合成ではなく現実的なテキストで構成しており、専門家による人手のレビューと複数のLLMによるレビューを併用した多段階のレビュープロセスによって、品質の評価や難易度のアノテーションなどを行っています。

LongBench v2 の特徴は主に以下の4点です。

Length：8,000〜2,000,000 単語と、幅広い入力長での評価が可能（ただし大半は 128,000 単語以下を重視）
Difficulty：人間の専門家でも短時間では解けない難易度の問題も用意（検索ツールを用いても時間がかかる問題が含まれている）
Coverage：現実的シナリオを広くカバー（6カテゴリー・20サブタスク）
Reliability：全問4択からの択一形式で、再現性の高い評価が可能（llm-as-a-judge に依存しない評価が可能）

LongBench v2 には 6 つの評価カテゴリーがあります。

カテゴリー	評価サンプル数	概要
Single-Document QA	175	学術・文学・法律・金融・行政などの単一文書を前提に、背景理解や時系列・推理（探偵小説など）を問うQAタスク
Multi-Document QA	125	複数資料（ニュース記事群など）を跨いで推論するQAタスク
Long In-context Learning	81	長い文脈（例：ユーザガイド等）からの In-context Learning 能力を測るタスク
Code Repository Understanding	50	大きなコードベース全体を跨いだ理解を問うタスク
Long-dialogue History Understanding	39	長い対話履歴全体の整合についての理解を問うタスク
Long Structured Data Understanding	33	長大な表や構造化データの理解を問うタスク

いずれのカテゴリー・タスクにおいても、評価サンプルは A, B, C, D の4つの選択肢からの択一問題形式になっており、出力の形式をシンプルにすることで LLM-as-a-judge に依存しない機械的な評価を可能にしています。

選定理由

主な理由は

社会実装をテーマとしているため、現実的なタスクに近い評価を行いたい
4択問題からの択一形式なので評価が機械的に行いやすい
難易度の高い問題が用意されており、人手での品質評価も十分に行われている

などです。サンプル数は500件程度と多くはなかったので、全サンプルを評価に使用しました。

3. MRCR (Multi-Round Coreference Resolution)

どのようなベンチマーク・タスクか？

MRCR[3] は Google DeepMind が開発した評価タスクで、Gemini シリーズのモデル情報の中でロングコンテキスト性能として記載されている指標です。 gemini 2.5 のレポートではより難易度の高い評価データセットとして MRCR v2 を作成し評価に用いていると書かれており、最新のモデルでは MRCR v2 でのスコアがモデル情報に記載されています。

MRCR はユーザとアシスタントのマルチターンの会話履歴と会話履歴に対する質問から構成される評価タスクになっており、これまでの会話履歴の中から該当するやり取りを探して必要な思考・操作を行って回答を出力する必要があります。

Gemini の開発で用いられている実際の MRCR 評価データは公開されていませんが、OpenAI から類似する形式の評価データセット[4]が公開されている（これを OpenAI-MRCR と呼ぶことにします）ため、本開発でも OpenAI-MRCR を使用しました。

OpenAI-MRCR では、「"バク" についての "詩" を書いて」のように、「<ジャンル> についての <文書の種類> を書いて」形式のユーザプロンプトに対してLLMからの回答があり、そのようなユーザ・アシスタントの1ターンの会話を繋ぎ合わせて擬似的なマルチターンの会話を構成しています。そして、最後のユーザプロンプトとして、「 N 回目の『X についての Y を書いて』という質問についてのアシスタントの回答を抜き出して、その頭に△△△（ランダム文字列）をつけたものを出力して」といった質問が与えられます。

同じ「X についての Y を書いて」という質問を持つ1ターンの会話が履歴の中に複数挿入されており、その中からN回目のその質問に対するアシスタントの回答を抽出させます。挿入する同じ質問の数が難易度に影響する要素であり、OpenAI-MRCR では難易度の異なるサブセットとして 2needles, 4needles, 8needles の3種類が用意されています。

選定理由

MRCR を選定したのは

タスクの難易度が高い（レポートなどでのモデルのスコアが低いことが多い）
長文入力時の日本語生成の安定性を見ることが可能
日本語データの作成が比較的容易

などの理由からです。日本語データの作成が容易というのは、評価サンプルの構成上、日本語版のデータを作る場合に、コンテキスト全体をまとめて翻訳する必要がないためです。 LongBench v2 の評価データは（複数文書からなるケースもありますが）コンテキスト全体で一つの文書になっているケースがあり、長大なドキュメントを前後の文脈を保って翻訳するのが難しくなっています。一方で、MRCRのデータは会話がターンごとに区切れる、同じ質問が複数存在する、質問に対する回答が翻訳が不要、といった特徴があります。

同じ質問が複数存在する、については、MRCRは同じ質問を何度か含む会話履歴の中で、「N番目の〇〇という問い合わせについて△△してください」といった問題を出す設計になっているためです。質問が重複しているため、評価サンプルを分解して個別に翻訳して再構築すれば、翻訳の回数を減らすことができ、品質の担保がしやすくなります。さらにいうと、OpenAI-MRCR の評価データのユーザの問い合わせ文はすべて「write a A about B.」という形式になっているので、A, B だけ翻訳すれば事足ります。

次に、質問に対する回答が翻訳が不要、については、上記の A には詩・エッセイ・歌詞などの正解が一つに定まらないものが指定されるため、元の回答を翻訳せずとも、質問が翻訳できればその質問文に対して新しくLLMで日本語の回答を数種類生成すればよい形になっています。そのような方法で作成した日本語版の OpenAI-MRCR の評価データセットを今回公開しています。

abeja/OpenAI-MRCR-Translation-JPN · Datasets at Hugging Face

実装したベンチマークのリポジトリ

ここからは各種ベンチマークの評価を実行するために実装したベンチマークのリポジトリについて説明します。リポジトリの概要と、サポートしている評価タスクおよび指標、ロングコンテキスト処理の評価という観点から実装時に考慮したポイントについて説明します。

リポジトリの概要

公開するベンチマーク実装のリポジトリはこちらです。

GitHub - abeja-inc/longcontext-evaluation: ロングコンテキストLLMの評価 · GitHub

本リポジトリでは、RULER / LongBench v2 / OpenAI-MRCR を同一のインターフェースで実行し、結果を共通の形式で集計・比較できます。実装の全体設計などはリポジトリに記載しています。実行方法もリポジトリの README.md に記載している通り、

環境の準備（コンテナ起動など）
データセットの準備（ダウンロード、合成）
評価の実行

の順に進めていただくことで、評価を行うことが可能です。サポートしている評価対象のモデルですが、vLLM Offline Inference または OpenAI API 形式での呼び出しができるモデルであれば基本的には評価が可能です。*1

サポートしている評価タスク

基本的には選定したベンチマーク・評価タスクに絞ってサポートしています。

RULER（NIAH, QA のみ）
LongBench v2（全カテゴリー）
OpenAI-MRCR

RULER QA と OpenAI-MRCR のみ日本語での評価が可能です。RULER QA の日本語サブセットでは JSQuAD と JEMHopQA をサポートしています。各種ベンチマークにおけるスコア算出方法・正誤判定の方法はすべてオリジナルの実装と同じアルゴリズムを採用しています。

実装時に考慮したポイント

言語間での差分は基本的にデータセット側で吸収されるため、あまり実装上考慮しなければならない点などはありませんでした。実装時に考慮する必要があったのは主に

入力長がモデルのコンテキスト上限を超える時にどのように処理するか？
Reasoning Model と非Reasoning Model での出力の違いをどのように扱うか？

の2点です。1点目については長すぎる入力の一部を切り取るパターンと、フィルタリングして評価対象外にするパターンが考えられます。

RULER はそもそもコンテキスト長に収まるように評価データを合成するので基本的には考慮しなくて良いのですが、同じ評価データで複数のモデルを比較したい時には必要になります。また、LongBench v2 はオリジナルの実装で入力がコンテキスト上限を超えるときは入力の中央付近を切り取る設計になっています。MRCR については公式の実装などはありませんが、RULER や LongBench v2 と違ってマルチターンの会話履歴なので、切り取るとしたら会話のターン単位で行うのが望ましいと考えられます。また、フィルタリングの機能もサポートしています。入力の切り取りはベンチマーク・タスクによって手法が異なるためベンチマーク固有の実装側で対応し、フィルタリングはベンチマークに依存しないため、推論モジュール側の機能として実装しています。

2点目の Reasoning Model と非Reasoning Model での違いというのは、一つは Reasoning をパースする必要があること、もう一つは（開発の過程ではモデルが正常に動かないことが往々にあるため）コンテキスト上限の中で生成が終了せずにパースできない場合にどのように対応するか？です。前者については、 vLLM の場合は Online Serving の場合は Reasoning Parser が実装されているので、serve 時に単純に引数から設定すれば良いのですが、Offline Inference ではサポートされていませんでした。そのため推論モジュール側の機能として Reasoning Parser を追加し、Offline Inference の場合は独自実装した Reasoning Parser を呼び出す形で対応しています。

後者のコンテキスト上限で生成が終了しない場合については、

Reasoning を行うモデルの場合は、Reasoning のテキストがない / パースできなかった場合は不正解とする
Reasoning も含めて全ての生成テキストを評価対象とするが、出力長の長さに応じたペナルティを課す

といった対応が考えられます。前者については、個別の評価指標に依存しない共通機能として実装しています。後者については、LongBench v2 や OpenAI-MRCR のように回答時のフォーマットが指定されている場合は、その正規表現に一致する回答しか受け付けないため、あまりスコアの算出には悪影響がありませんでした。一方で、RULER では生成テキストの中に正解の文字列が含まれているかどうか？で正誤判定を行うため、正解候補を全て列挙した回答と正解のみの回答は等しく "正解" 扱いになる設計でした。そのため、RULER にのみ出力長に対してペナルティを課す評価指標をオリジナルで実装しています。