ABEJAでデータサイエンティストをしている藤原です。ABEJAアドベントカレンダー2025の17日目の記事です。

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

ロングコンテキストLLMに関する検証の一環で、以前にもロングコンテキストLLMの評価や分析に関するブログを公開しています。

今回もロングコンテキストLLMの評価に関する記事です。今回のブログでは、より実際の評価タスク設計に近い検証を行いました。具体的には、長いコンテキストの中に誤った情報を大量に含めた場合に、LLM は誤った情報を無視して正確な回答を生成できるのか？という観点で評価タスクの設計と検証を行いました。

1. ロングコンテキストLLMの評価
2. Context Poisoning
3. 評価タスクの設計
4. 評価方法
5. 評価結果
6. まとめ
参考文献
We are hiring!!

1. ロングコンテキストLLMの評価

ロングコンテキストLLM（Long Context Language Model; 以下LCLMと呼ぶ）の評価には、長大な入力を正確に処理する能力（Long context comprehension などと呼ばれる）の評価と、長大な出力を一貫して生成する能力（Long-form generation などと呼ばれる）の評価を行うものがあります[1]。前者は入力するプロンプト・コンテキストについてどこまで長くしても正確に情報処理できるか？を問い、後者は出力するテキストの長さについてどこまで安定して生成ができるか？を問うものです。モデル開発のテクニカルレポートなどでロングコンテキスト処理性能として記載されるのは、前者の長大な入力を正確に処理する能力を評価するベンチマークのスコアが多い印象です。

LCLM評価タスクとしては Needle-in-a-Haystack; NIAH がよく知られています。 Needle は針、Haystack は干し草の山という意味で、NIAHは大量の情報の中から必要な情報を探し出すタスクです。近年の LCLM ではロングコンテキスト処理能力が向上しており、簡単な NIAH タスクでは100点を取ってしまいモデル間の性能差が見れないため、より難易度の高い評価タスクの設計や多角的な評価が可能なベンチマークの構築が進められています。

1.1 合成的なタスクと実世界的なタスク

入力側の LCLM 評価では、どのようにして評価データを作成するか？が難しいポイントになっています。たとえば、10万文字の文書とそれに対するQAを作成した場合、入力プロンプトは文書全体と質問のテキストになるため、そのままでは 100万文字の入力での評価はできません。そのため、多くのロングコンテキスト評価タスクでは、複数の文書を並べて長い入力テキストを作成するなど、タスクを解くために不要なテキストをコンテキストに織り交ぜることで、評価したいコンテキスト長まで入力長を伸ばした合成長文サンプルを作成しています。たとえば、短いドキュメントとそれに対するQAを作成して「ドキュメント＋質問文」で入力プロンプトのベースを作成し、ドキュメントの部分に他の無関係なドキュメントを追加していくことで長い入力テキストを構築します。代表的なベンチマークとしては RULER[2] が挙げられ、モデル開発のテクニカルレポートでもよくスコアが記載されています。

一方で、より現実のタスクに近い実世界的な（real-world）タスクでの評価を目指したベンチマークも構築されています。 LongBench v2[3] などはモデル開発のテクニカルレポートでもしばしば使用されている代表的なベンチマークです。実世界的な評価タスクは一貫性のある・現実的な入力コンテキストを用いて評価することで、現実のタスクで使用した際の性能に近い性能を図ることを目的に作成されます。しかしながら、先ほどの合成タスクと反対に、入力長の制御と正解の保証が難しいという側面があります。

合成的なタスクが優れている点は、入力長を自在に制御できる点と、問題に対する模範解答が本当に正しいか評価しやすい点が挙げられます。入力長の制御については、合成的なタスクでは挿入する無関係な情報の量によって入力長を自在に変更することが可能ですが、実世界的なタスクでは必要なデータ本体が持っているテキストの長さで入力長がある程度決まってしまいます。模範解答の正しさについては、合成的なタスクではベースプロンプトのみ読めば解答を判断できるため、問題と解答のペアが適切か？人手で評価することが比較的容易です。実世界的なタスクでは、基本的には入力全体を読む必要があるため、人手で品質をチェックするにはかなりのコストがかかってしまいます。

逆に、実世界的なタスクが優れているのは、情報の一貫性のある、より現実的な入力コンテキストで評価できる点です。合成タスクでは無関係な文書などをコンテキストに含めることで入力長を制御しますが、そのような無関係な文書は本来現実のタスクでは入力されるべきものではありません。そのため、実際の開発では合成タスクによる多角的な評価を行いつつ、最終的な用途に合わせて実世界的なタスクでの評価を実施することが重要になります。

1.2 評価する LCLM 能力の違い

冒頭で、LCLMの評価といっても長文入力の処理能力を評価するか？長文生成の能力を評価するか？で異なるという話をしましたが、長文入力の処理能力の中にも複数の要素が存在しています。ここでは大きく分けて以下の3種類の要素があるとします[1]。

長いコンテキストの中から必要な情報を見つけられる検索能力（Retrieval）
長いコンテキストの情報全体を参照して情報を集める集約能力（Aggregation）
長いコンテキストの情報をもとに論理的な推論を行って最終的な回答を生成する能力（Reasoning）

Retrieval タスクは

検索対象と類似するテキストがどれほど本文中に含まれているか
検索クエリが本文中でどのように表記されるか
検索対象が何個あるか

といった観点で難易度が変化すると考えられます。 NVIDIA が構築した RULER[2] ベンチマークの NIAH タスクは、「ID 〇〇に紐づく番号は ××× です。」というような文（Needle）を大量の無関係な文（Haystack）の中に埋めて、IDに対応する番号が何であったか問う形式になっています。この時、 Haystack も全て「ID 〇〇に紐づく番号は ××× です。」形式にすることで、探すべき文を見つけづらくすることが可能です。 Multi Round Coreference Resolution; MRCR[4] は Google Deep Mind が提案した LCLM 評価タスクで、 Gemini のテクニカルレポートで LCLM 性能を示す指標として記載されています。 Gemini の開発で用いられている評価データは公開されていませんが、OpenAI から MRCR タスクの評価データ[5] が公開されています。 MRCR は以下の画像のように、マルチターンの会話をコンテキストとして与え、その中では Needle として同じユーザプロンプトが何度か登場し、最終的な問い合わせで「N番目の〇〇に関するプロンプト」について問うようなタスクになっています。N番目という指定によって文字列の一致だけでは位置を特定できないようにしています。MRCR も Needle を増やすことで、難易度を上げることが可能です。他にも、文中の一部分を抜粋して言い換えたものを作成し、言い換えた文章の続きを本文から探して回答するといったタスクも存在します[6]。3つ目の検索対象の個数については、例えば RULER の NIAH なら検索させる ID を複数個にすることで調整することが可能です。

Aggregation タスクは

集約時に参照すべき情報が何個あるか
情報どうしをどのように結びつけるか

といった観点で難易度が変化すると考えられます。わかりやすい評価手法は長文を要約するというタスクですが、要約文の評価は機械的な一致度などではその良し悪し十分に図ることが難しいです。RULER の Variable Tracking（変数追跡）タスクは、 X = 1111, Y = X のような変数定義の式をコンテキストの中に埋め込み、その変数の値を問う形式になっています。X = 1111, Y = X, Z = Y のようにして変数を辿る回数（num_hops）を増やしてコンテキスト中に散りばめることで、その変数に格納されている数字を当てるのが難しくなります。

Reasoning タスクは複数の要素が絡み合っていることが多いため分解するのが難しいですが、抽象的には「最終回答が得られるまでの過程の複雑さ」という観点で難易度が変化すると考えられます。ある文章を段落ごとに分けシャッフルし、元の順番に並び替えさせるといったタスクの場合、段落の数や段落同士の関係性で難易度が変化します。Reasoning 単体を見ることは難しいため、 Aggregation と併せて性能を評価するタスクも多く、情報の集約時や集約後に論理的な推論が必要なタスクも提案されています。 LongBioBench [7] は複数人の伝記・略歴で長文コンテキストを作成し、年齢順に並べる、特定の年齢差の人物ペアを見つけるといったタスクを設計しています。 OOLONG [8] は、より現実的なケースとしてロールプレイングゲームの対話ログからロールの種類をカウントするなどのタスクを設計しています。

これらの LongBioBench や OOLONG は比較的 Aggregation の要素が強いタスクな印象ですが、数学やコードなどのテキストを用いて、より論理的な推論を重視したタスクも提案されています。GSM-Infinite [9] は小学校レベルの算術問題（GSM-8K）を用いて、計算過程を複雑にしたり、回答するための計算過程には不要な情報を追加することで、ロングコンテキストの Reasoning 評価タスクを設計しています。コードやその編集履歴を用いた評価タスクとしては、 LoCoDiff [10] や LongCodeEdit [11] などが提案されています。LoCoDiff はコードの編集履歴を辿って最終的なコードがどうなるかを生成するタスクです。LongCodeEdit はテストが存在するコードを使って、バグを特定して修正するタスクになっています。（この評価タスクの設計に関するブログが面白かったのでおすすめです。）

また、多角的なLCLM評価を行うベンチマークも構築が進められており、HELMET [12] や LongBench v2 が主に用いられている印象です。

ここまでで LCLM 評価に関して最近の動向を簡単にお話ししましたが、ここからは今回の検証の本題である Context Poisoning について説明します。

2. Context Poisoning

今回は LCLM における Context Poisoning への耐性を検証します。 Context Poisoning とは、LLMに与えるコンテキスト（チャットモデルの会話履歴やエージェントの行動履歴など）がたくさんの誤った・不適切な情報で汚染されてしまう現象です。まずは、Context Poisoning によってどのような問題が発生するのか、具体的な事例を紹介します。

事例1 エージェントにおけるダメな行動の繰り返し

Gemini 2.5 のテクニカルレポート[13] では、エージェントとしてロングコンテキストLLMを用いた際に、過去の行動ログによって以下のような問題が発生したことが報告されています。重要なポイントなので原文の引用と翻訳を併記します。

Original
While Gemini 2.5 Pro supports 1M+ token context, making effective use of it for agents presents a new research frontier. In this agentic setup, it was observed that as the context grew significantly beyond 100k tokens, the agent showed a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans. This phenomenon, albeit anecdotal, highlights an important distinction between long-context for retrieval and long-context for multi-step, generative reasoning.

日本語訳
Gemini 2.5 Pro は 100万トークン以上のコンテキストをサポートしているものの、エージェント用途でそれを効果的に活用することは新たな研究フロンティアとなっている。このようなエージェント的な設定では、コンテキストが 10 万トークンを大きく超える規模になると、エージェントは膨大な履歴の中から同じ行動を繰り返す傾向が見られ、新しい計画を合成して生み出す力が弱まることが観察された（あくまで逸話的だが）。この現象は、「長いコンテキストを用いた情報検索」と「長いコンテキストを用いた多段階の生成的推論」との間に重要な違いがあることを示唆している。

Original
An especially egregious form of this issue can take place with “context poisoning” – where many parts of the context (goals, summary) are “poisoned” with misinformation about the game state, which can often take a very long time to undo. As a result, the model can become fixated on achieving impossible or irrelevant goals. This failure mode is also highly related to the looping issue mentioned above. These delusions, though obviously nonsensical to a human (“Let me try to go through the entrance to a house and back out again. Then, hopefully the guard who is blocking the entrance might move.”), by virtue of poisoning the context in many places, can lead the model to ignore common sense and repeat the same incorrect statement. Context poisoning can also lead to strategies like the “black-out” strategy (cause all Pokémon in the party to faint, “blacking out” and teleporting to the nearest Pokémon Center and losing half your money, instead of attempting to leave).

日本語訳
とりわけ深刻な問題として挙げられるのが「コンテキスト汚染（context poisoning）」である。これは、コンテキストの多くの部分（例：目標や要約）が、ゲーム状態に関する誤った情報で “汚染” されてしまう現象であり、その誤情報を修正するには非常に長い時間がかかることが多い。その結果、モデルは達成不可能または無関係な目標に固執してしまう。この失敗モードは、前述した「ループ」問題とも強く関連している。こうした妄想的な振る舞いは、人間にとっては明らかにナンセンスである。（例：「家の入口に入ってすぐ出れば、入口を塞いでいるガードが動くかもしれないから試してみよう。」）しかし、コンテキストの多くが誤情報で汚染されていると、モデルは常識を無視し、同じ誤った主張を繰り返すことがある。コンテキスト汚染は、例えば「ブラックアウト戦略」のような行動も引き起こしうる。（パーティのポケモンを全滅させて “ブラックアウト” を起こし、最寄りのポケモンセンターに強制送還され、さらに所持金を半分失う──本来なら脱出を試みるべき場面でも、あえてそうしてしまう。）

まとめると、エージェント自身が過去にとった失敗行動の履歴が大量に蓄積され、それをコンテキストとして与えた結果、過去の失敗行動に引っ張られて同じ失敗を繰り返したり、多様な新しい行動の計画ができなくなったということです。これは LLM の重要な能力の一つである In-context learning の能力に関係していると考えられ、コンテキストからパターンを学習して適応する能力が高いほど発生しやすい可能性があります。

事例2 Many-shot Jailbreaking

多数の誤った質問応答ペアを与えることで Jailbreaking を引き起こす、というのも類似する事例と言えるかと思います。Jailbreak とは、セキュリティの穴を突いて本来ユーザの権限ではできない操作を実行することなどを指します。そして、LLM における Jailbreak は、不適切な利用ができないようにLLMの備えられているガードレール（安全のための機能）の穴を突いて、本来禁止されているはずの出力を生成させる手法・攻撃のことを指します。たとえば、悪意のある発言を生成しないように調整させているモデルに、そのような発言の生成を誘発させるようなプロンプトを与えることで、悪意のある発言を生成させるようなものです。

Many-shot Jailbreaking[14] は長いコンテクストウィンドウが処理可能なモデルに対して、大量のフェイク会話を過去のログとして与えた後に危険／有害な質問をすることで、本来拒否されるべき質問に回答させる Jailbreaking 手法です。例えば、「ユーザが爆弾や薬物の作り方を質問し、アシスタント（LLM）が作り方を回答した」という架空の会話のログを作成し、これを何ターン分も作成して過去の会話ログとして入力します。

Many-shot jailbreaking が発生する原因も in-context learning というプロセスと関係していると考えられます。[15] の実験では、 shot 数（フェイク会話のターン数）を増やすと、それに伴って有害な応答を生成する可能性が高くなることが示されています。さらに、この傾向は通常の in-context learning タスクのスコアの推移と同様であり、与えたサンプル数が増えるほど in-context learning タスクのスコアが徐々に高くなることも示されています。

LCLM 評価の章で紹介したように、長いコンテキストの中から必要な情報を探すことや、従来の QA や In-context learning （以下 ICL と呼ぶ）などをロングコンテキスト条件下で評価するタスクは徐々に増えています。一方で、 Context Poisoning や Many-shot Jailbreaking などへの頑健性をロングコンテキスト条件下で評価するタスクは、[16] などの先行研究はあるもののまだまだ少ない印象です。

そこで今回は簡単なゲームルールとそのルールに従わない質問応答ペアを与えて、間違った過去のログを無視して本来のルールをどれだけ守れるか？検証してみました。

3. 評価タスクの設計

今回は数字のパズルを system prompt として与え、コンテキストとして正しい・誤った会話履歴（user prompt, assistant response の系列）を挿入し、最後に回答すべき問題を user prompt として与えて、それに正確に回答できるか？を検証します。数字のパズルはメイクテンパズルにしました。

3.1 今回のメイクテンパズルのルール

メイクテンパズルは4つの数字と四則演算 +, −, ×, ÷、括弧 ( , )を用いて、計算結果が 10 になる式を見つけるパズルです。ルールを簡単に整理すると以下のようになります。

使用できる演算記号は加算（+）、減算（-）、乗算（×）、除算（÷）、括弧（( , )）の5種類
与えられた4つの数字をすべて1回ずつ使うこと
数字の順序は問わない
複数の数字を並べて2桁、3桁の数字として使うのは禁止
途中の計算過程で分数が出ても良い
- たとえば、(3 + (1 ÷ 3)) x 3 = (3 + 1/3) x 3 = 10/3 x 3 = 10 みたいなのもOK

という感じです。例えば、 2, 3, 5, 7 の4つが与えられたとします。ダメな例を紹介すると

ダメな例	ダメな理由
`(2 x 3) + 7 - 5 = 8`	計算結果が `10` にならない
`7 + 5 - 2 = 10`	使っていない数字（`3`）がある
`2 + 2 x 3 - 5 + 7 = 10`	`2` は1つしか与えられていないのに2回使用している
`9 x 5 ÷ 3 - 7 + 2 = 10`	与えられていない数字（`9`）を使っている
`35 ÷ 7 x 2 = 10`	2桁の数字（`35`）にするは禁止
`2 ^ 3 + 7 - 5 = 10`	許可されていない演算記号（べき乗記号 `^`）を使用している

などはルール違反です。正解例としては

(2 + 3) x (7 - 5) = 10
(7 - 3) x 5 ÷ 2 = 10
(7 - 3 - 2) x 5 = 10
(7 + 3) ÷ 2 + 5 = 10
5 ÷ (7 ÷ 2 - 3) = 10

などがありえます。LLMに与えるパズルのルール説明として、 system prompt を以下のように設定しました。

あなたには4つの数字が与えられます。その4つの数字と四則演算および括弧だけを使って、計算結果がちょうど 10 になる式を作ってください。

# ルール
- 使用できる演算記号は次の5種類のみです。
    - `+`（加算）
    - `−`（減算）
    - `×`（乗算）
    - `÷`（除算）
    - `(` `)`（括弧）
- 数字の使い方
    - 与えられた4つの数字をすべて1回ずつ使用してください。
    - 数字は任意の順番で並べ替えて構いません。
    - 複数の数字をつなげて2 桁以上の整数を作ることは禁止です。
        - 例： `1, 2, 3, 4` → `12` や `34` として使うのは不可。
    - 同じ数字を複数回使う、あるいは未使用の数字を残すことは禁止です。
- 計算ルール
    - 計算は整数演算と一般的な分数計算の範囲で行ってください。
    - 計算途中に分数が出ても構いません。
        - 例：`(3 + (1 ÷ 3)) × 3 = 10`
    - 除算で 0 で割ることは禁止です。
    - 最終的な結果は厳密に 10 である必要があります。
    - 近似値や四捨五入で 10 にするのは不可。

# 出力形式
- 左辺に与えられた4つの数字と追加した記号、右辺に 10 を持つ完成版の数式を出力してください。
  - 例：`(3 + (1 ÷ 3)) × 3 = 10`

3.2 比較条件

比較する条件は以下の4条件です。

Zero-shot
- そもそも正解できる問題の難易度になっているかを確認
Gold N-shots
- 1 で正しい答えを出せていた評価サンプルの think の過程と最終回答を使用し、全て正しい回答ができている会話履歴を作成
- 挿入する user, assistant の会話（1ターン＝1個の問題の出題と回答）のターン数を増減
Poison N-shots
- 2 と同じ方法で会話履歴を作成するが、加算と減算、乗算と除算の記号を反転
Poison N-shots with Correct
- 3 と同じ方法で会話履歴を作成し、会話履歴中の assistant response の次の user prompt に「その回答は不正解です。」という prefix をつけて次の問題を出題
- これまでの会話履歴の思考・回答が誤っていたことを伝える

4. 評価方法

この評価タスクで狙うのは以下のような評価の実現です。

コンテキストが長くなる（＝N が増える）ほど
- クリーンなコンテキスト（Gold N-shots）では、スコアが変わらない（LCLM性能の安定性）
- Poison なコンテキスト（Poison N-shots）では、（耐性がないモデルは）スコアが徐々に低下する（Context Poisoning への耐性）
不正解のパターンとしては、差し込んだ Poison なコンテキスト中での間違い方が増える
- 今回の場合は加算・減算が反転、乗算・除算が反転した Poison なコンテキストを挿入することで、数式はルールに則って生成されるが計算結果が 10 にならない、という間違いパターンを誘導する

4.1 評価データ作成

以下のような方法で、評価データを作成しました。評価データの作成では Qwen/Qwen3-Next-80B-A3B-Thinking と openai/gpt-oss-120b を使用しました。使用するパズルの問題（数字のペア）は同じですが、以下の手順でモデルごとに別々の評価サンプルを作成しました。

Zero-shot
- 30問の問題を作成
  - 手作業で正解が存在する数字の組みを選定
  - 1~20問目は簡単な問題、21~30問目は難しい問題
- LLM で問題への回答を生成（think 付き）
  - ここが使用するモデルによって変化
Gold N-shots
- 30問から1問を回答対象として取り出す
- 残りの29問の中から N (N = 1, 2, …, 29) 個の問題を取り出し、各問題と 1 で作成した対応する解答例をもとに会話履歴を作成
- 挿入時に問題の順番はシャッフルしない（N >21 では難しい問題が挿入される）
  - N が大きくなると、コンテキストの長さと問題の難易度の両面で難易度が変化してしまうため、本来なら問題の難易度はある程度統一したいところですが、今回はそこまでできませんでした
Poison N-shots
- 2 と同様
- ただし、会話履歴中の assistant response (thinkの中も対象)のすべての加算と減算、乗算と除算をそれぞれ反転
Poison N-shots with Correct
- 3 と同様
- ただし、会話履歴中の assistant response 直後の user prompt の先頭に「その回答は不正解です。」という訂正文を挿入

4.2 評価指標

できるだけ定量評価したかったので、以下の方法で出力テキストをパースしてスコアを算出しました。

テキストを正規化
- Unicode正規化など
- think 部分は取り除いた上で、最終回答として数式のみ生成されるケースと、余分な前置き付きで生成されるケースがあった
- そこで、長い回答は後ろ40文字を取り出し、その中で先頭から見ていって初めて数字 0~9 または左括弧 ( が登場した位置以降を有効な最終回答として取り出した
ルールを守っているかチェック
1. 数式の左辺に与えられた数字のリストの中で使われていないものがある → Unused
2. 数式の左辺に5個以上の数字が登場している → OverDigits
数式が正しいかチェック
- 記号の表記揺れもみつけた範囲で正規化した上で、 Python の ast で解析して数式を評価
- 左辺の計算結果が 10 にならない or 数式として解析できない場合 → InvalidEquation
2,3 をクリアしたものを正解としてカウント
- → CorrectAnswer

上記の方法で、 Unused, OverDigits, InvalidEquation, CorrectAnswer の数をカウントし、それぞれプロットする。

5. 評価結果

Qwen3-Next-80B-A3B-Thinking

まずは Qwen3-Next での検証結果から見ていきます。

以下に正解したサンプル（ CorrectAnswer）の割合、不正解だったサンプル（InvalidEquation, OverDigits, Unused）の割合を記載します。各グラフの赤線が Zero-shot での正解率（shot数に依存しないため一定）、青色が Gold N-shots、橙色が Poison N-shots、緑色が Poison N-shots with Correct のスコアです。

正解率から見ていくと、まず Zero-shot でも難しい問題を2問だけ間違えたので 100% にはなっていません。残りの3条件を比較すると、Gold N-shots が他の2条件に比べて正解率の低下が少なそうです。Poison N-shots と Poison N-shots with Correct はあまり差はないものの、若干 with Correct の方が正解率が下がっているように見えます。

不正解のケースも少し分析してみます。こちらも Gold N-shots, Poison N-shots, Poison N-shots with Correct の間での差はあまりありませんでした。間違い方として多かったのは、数字を5個や6個に増やして無理やり回答を提出してくるというパターンでした。今回狙っていた「ルールを守った回答をした上で数式が不正（解析できない or 計算結果が 10 にならない）」という間違い方はそれほど多く発生しませんでした。

gpt-oss-120b

次は gpt-oss-120b での検証結果を見ていきます。

まずは正解率からですが、Zero-shot に関しては1問だけ間違えていたので、Qwen3-Next と同様 100% とはなっていません。残りの3条件を比較すると、 Qwen3-Next の時よりも N が大きい時の Gold と Poison のスコアの差が大きいという結果になりました。Poison 条件において with Correct か否かでは、あまり差はありませんでした。

不正解のパターンを見ていきます。こちらも Qwen3-Next と傾向が違います。gpt-oss では InvalidEquation での不正解率が比較的高くなりました。特に、 Gold 条件では N が大きくなっても InvalidEquation はほとんど発生していませんが、Poison 条件では N が大きくなるほど InvalidEquation で不正解になっているケースが増えています。数式の検証のコードが誤っている可能性もあるので、実際に出力テキストを確認したところ、確かに正常な四則演算の数式は最終回答として提出できているものの、その数式の計算結果が 10 になっていない、という誤りが多く発生していることを確認しました。

6. まとめ

今回は LCLM 評価の新しいタスクの検討として、Context Poisoning への耐性を評価できないか？検証してみました。結果として、Qwen3-Next では、誤ったコンテキストに引っ張られて問題が解けなくなるという傾向はそれほど見受けられませんでした。一方で、gpt-oss-120b では誤ったコンテキストに引っ張られたのか、有害なコンテキストの量を増やすほど問題が解けなくなるという結果が得られました。今回作成した評価タスク・評価データセット自体にもまだまだ課題があるため、この結果がモデルの Context Poisoning への耐性を十分評価できているとは言えませんが、今後の評価タスク設計に参考になる結果が得られました。

評価タスク・評価データの設計の改善点ですが、

問題の難易度がコントロールできていない
Zero-shot 条件で間違った回答をしたサンプルも Gold 条件でコンテキストに入るケースがあるため、有害なコンテキストになっている可能性がある
Poisoning の注入方法にバリエーションがない

など多々あるかと思います。また、新しいツールをドキュメントや数例で上手く使える ICL 能力の高さと、過去の失敗した行動履歴をいかに無視して新しい方針を立てる能力が両立できているか？を評価するのが理想なので、両方を評価してバランスを見れるベンチマークを整備していく必要があります。

もちろん、すべてをLLM本体で解決する必要があるわけではないので、例えば失敗している行動履歴ほど要約してコンテキスト中の割合を減らすといったコンテキストエンジニアリングの技術も重要になってきます。とはいえ、いくつかの失敗例から新しい方針を立てる、という場面を完全に避けられるわけではないと思うので、LLM本体の能力と周辺技術の活用の両方からアプローチしていく必要があると思っています。

本成果は、経済産業省とＮＥＤＯが実施するGENIACでのモデル開発によって得られたものです。