Untitled

生成日: 2026-05-24 02:20

# Untitled
RAFFLES: Reasoning-based Attribution of Faults for LLM Systems
著者: Chenyang Zhu, Spencer Hong, Jingyu Wu, Kushal Chawla, Yuhui Tang, Youbing Yin, Nathan Wolfe, Erin Babinsky, Daben Liu
会議: Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers), 2026
URL: https://aclanthology.org/2026.eacl-long.359/

どんな論文か

LLM を単体で使うだけなら、答えが合っているかを見る評価でもそれなりに回ります。ただ、ReAct や Toolformer、Reflexion のように、計画して、道具を呼び、何ステップも進むエージェントになると話が変わります。最終結果が失敗したとしても、どの時点のどの判断がまずかったのかを探すのはかなり面倒です。論文でも、手作業だと 1 件あたり数分から数十分かかるとしています。

この論文の RAFFLES は、そういう「どこで壊れたか」を後から探すための評価アーキテクチャです。中心に Judge を置いて、ログ全体から「このステップが決定的な fault ではないか」と候補を出します。その候補を、複数の Evaluator が別々の観点からチェックし、理由と信頼度を返します。Judge はそのフィードバックを履歴として受け取り、必要なら次の反復で候補を直します。

面白いのは、単に LLM-as-a-judge を強くしたというより、「評価する側もエージェントっぽくする」方向に振っているところです。ログ全体を見る Judge と、候補ステップを細かく検査する Evaluator を分けることで、長い軌跡の中の初期エラーを探しやすくしています。

何を調べたか

- 主な対象は Who&When ベンチマーク。GAIA と AssistantBench 由来のエージェントログと、故障ステップのペアからなるデータセット。
- Who&When では 2 つのサブセットを使用。Algorithmically-Generated は 126 ログ、191 種類のエージェント、平均 9 ステップ。Hand-Crafted は 58 ログ、5 種類のエージェント、平均 51 ステップ。
- 汎用性を見るため、数学の推論過程にステップ単位の誤り注釈がある ReasonEval でも評価。MR-MATH-Invalid のうち誤りステップを含む 83 軌跡と、MR-GSM8K の original / reversed 設定を使っている。
- 比較対象は、one-shot の LLM-as-a-judge、Step by Step と Binary Search のルーター、最大 3 回までステップを調べる Tool-Caller ベースライン。
- モデルは Llama 3.3 70B、gpt-oss-20b、Claude Sonnet 4。オープンモデルは vLLM で A100 80GB 上に載せ、Claude は最大 200K tokens の文脈長で評価。
- 主指標は Strict Step-Level Accuracy。つまり、故障した正確なステップ番号を当てた割合。補助指標として、正解ステップから ±s ステップ以内なら正解とする Tolerant Step-Level Accuracy も使っている。

主な結果

Who&When では、RAFFLES がほぼ全モデルで一番良い結果でした。K=2 の設定では、Claude Sonnet 4 で Algorithmically-Generated が 51.59%、Hand-Crafted が 22.41%。同じ Claude の one-shot Chat-LLM はそれぞれ 29.37% と 3.45%、Binary Search は 33.33% と 20.69% なので、短めのログではかなり差が出ています。Llama 3.3 70B でも、RAFFLES は 43.65% / 20.69% で、Tool-Caller の 33.33% / 13.56% を上回っています。

既存研究との比較でも強いです。Who&When の ground truth なし設定で、RAFFLES は K=5、Claude Sonnet 4 の組み合わせにより Algorithmically-Generated で 51.59%、Hand-Crafted で 27.59%。論文が挙げる既存の simulation-free 手法では CORRECT が 38.10% / 17.20%、Causal Framework が 36.20% / 18.20%。simulation-based の FAMAS は 23.81% / 41.38% なので、長い Hand-Crafted では FAMAS が強い一方、Algorithmically-Generated では RAFFLES が上です。

ReasonEval でも改善が出ています。Claude Sonnet 4 の Chat-LLM baseline は MR-MATH-Invalid で 73.58%、MR-GSM8K-Original で 75.46%、MR-GSM8K-Reversed で 67.77%。RAFFLES K=2 はそれぞれ 84.91%、83.78%、75.28% でした。反復なしの K=0 でも MR-MATH-Invalid が 82.39%、MR-GSM8K-Original が 82.65% なので、反復だけでなく、Judge の理由を構造化して Evaluator に点検させる設計そのものが効いていそうです。

ポイント

この論文の良さは、「評価を一発判定にしない」ことです。長いエージェントログで最終結果だけを見ると、途中の小さなミスが後段で増幅されていても見落としがちです。RAFFLES は最初に怪しい地点を仮説として置き、その仮説の理由を別の Evaluator に疑わせる。人間のデバッグに少し近い動きです。

実務的には、エージェントの失敗分析を毎回人手でやるのがつらい場面に刺さりそうです。論文では、平均 9 ターンの軌跡に対して Claude Sonnet 4 を使った RAFFLES のコストを約 $0.1188、平均レイテンシを 15.55 秒と報告しています。リアルタイム監視というより、夜間バッチで失敗ログを洗う、評価セットの失敗理由を分類する、といった使い方が想像しやすいです。

注意点もあります。まず、エージェント故障帰属の大規模で多様な公開データセットがまだ少ないため、検証先は限られています。また、反復推論は fine-tuned な process reward model より遅くなりやすい。さらに、Evaluator が自信満々に間違えると、その誤りが残るケースもあり、論文では K=2 の実験で誤予測が最後まで残る例が Algorithmically-Generated で約 20.6%、Hand-Crafted で約 17.2% あったと報告しています。便利だけど、最後の根拠確認まで丸投げするのはまだ怖い、という温度感です。

一言でいうと、RAFFLES は「LLM エージェントの失敗ログを、別の LLM 評価エージェントにデバッグさせる」論文です。

Untitled

RAFFLES: Reasoning-based Attribution of Faults for LLM Systems 著者: Chenyang Zhu, Spencer Hong, Jingyu Wu, Kushal Chawla, Yuhui Tang, Youbing Yin, Nathan Wolfe, Erin Babinsky, Daben Liu 会議: Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers), 2026 URL: https://aclanthology.org/2026.eacl-long.359/

どんな論文か

LLM を単体で使うだけなら、答えが合っているかを見る評価でもそれなりに回ります。ただ、ReAct や Toolformer、Reflexion のように、計画して、道具を呼び、何ステップも進むエージェントになると話が変わります。最終結果が失敗したとしても、どの時点のどの判断がまずかったのかを探すのはかなり面倒です。論文でも、手作業だと 1 件あたり数分から数十分かかるとしています。

この論文の RAFFLES は、そういう「どこで壊れたか」を後から探すための評価アーキテクチャです。中心に Judge を置いて、ログ全体から「このステップが決定的な fault ではないか」と候補を出します。その候補を、複数の Evaluator が別々の観点からチェックし、理由と信頼度を返します。Judge はそのフィードバックを履歴として受け取り、必要なら次の反復で候補を直します。

面白いのは、単に LLM-as-a-judge を強くしたというより、「評価する側もエージェントっぽくする」方向に振っているところです。ログ全体を見る Judge と、候補ステップを細かく検査する Evaluator を分けることで、長い軌跡の中の初期エラーを探しやすくしています。

何を調べたか

主な対象は Who&When ベンチマーク。GAIA と AssistantBench 由来のエージェントログと、故障ステップのペアからなるデータセット。
Who&When では 2 つのサブセットを使用。Algorithmically-Generated は 126 ログ、191 種類のエージェント、平均 9 ステップ。Hand-Crafted は 58 ログ、5 種類のエージェント、平均 51 ステップ。
汎用性を見るため、数学の推論過程にステップ単位の誤り注釈がある ReasonEval でも評価。MR-MATH-Invalid のうち誤りステップを含む 83 軌跡と、MR-GSM8K の original / reversed 設定を使っている。
比較対象は、one-shot の LLM-as-a-judge、Step by Step と Binary Search のルーター、最大 3 回までステップを調べる Tool-Caller ベースライン。
モデルは Llama 3.3 70B、gpt-oss-20b、Claude Sonnet 4。オープンモデルは vLLM で A100 80GB 上に載せ、Claude は最大 200K tokens の文脈長で評価。
主指標は Strict Step-Level Accuracy。つまり、故障した正確なステップ番号を当てた割合。補助指標として、正解ステップから ±s ステップ以内なら正解とする Tolerant Step-Level Accuracy も使っている。

主な結果

Who&When では、RAFFLES がほぼ全モデルで一番良い結果でした。K=2 の設定では、Claude Sonnet 4 で Algorithmically-Generated が 51.59%、Hand-Crafted が 22.41%。同じ Claude の one-shot Chat-LLM はそれぞれ 29.37% と 3.45%、Binary Search は 33.33% と 20.69% なので、短めのログではかなり差が出ています。Llama 3.3 70B でも、RAFFLES は 43.65% / 20.69% で、Tool-Caller の 33.33% / 13.56% を上回っています。

既存研究との比較でも強いです。Who&When の ground truth なし設定で、RAFFLES は K=5、Claude Sonnet 4 の組み合わせにより Algorithmically-Generated で 51.59%、Hand-Crafted で 27.59%。論文が挙げる既存の simulation-free 手法では CORRECT が 38.10% / 17.20%、Causal Framework が 36.20% / 18.20%。simulation-based の FAMAS は 23.81% / 41.38% なので、長い Hand-Crafted では FAMAS が強い一方、Algorithmically-Generated では RAFFLES が上です。

ReasonEval でも改善が出ています。Claude Sonnet 4 の Chat-LLM baseline は MR-MATH-Invalid で 73.58%、MR-GSM8K-Original で 75.46%、MR-GSM8K-Reversed で 67.77%。RAFFLES K=2 はそれぞれ 84.91%、83.78%、75.28% でした。反復なしの K=0 でも MR-MATH-Invalid が 82.39%、MR-GSM8K-Original が 82.65% なので、反復だけでなく、Judge の理由を構造化して Evaluator に点検させる設計そのものが効いていそうです。

ポイント

この論文の良さは、「評価を一発判定にしない」ことです。長いエージェントログで最終結果だけを見ると、途中の小さなミスが後段で増幅されていても見落としがちです。RAFFLES は最初に怪しい地点を仮説として置き、その仮説の理由を別の Evaluator に疑わせる。人間のデバッグに少し近い動きです。

実務的には、エージェントの失敗分析を毎回人手でやるのがつらい場面に刺さりそうです。論文では、平均 9 ターンの軌跡に対して Claude Sonnet 4 を使った RAFFLES のコストを約 $0.1188、平均レイテンシを 15.55 秒と報告しています。リアルタイム監視というより、夜間バッチで失敗ログを洗う、評価セットの失敗理由を分類する、といった使い方が想像しやすいです。

注意点もあります。まず、エージェント故障帰属の大規模で多様な公開データセットがまだ少ないため、検証先は限られています。また、反復推論は fine-tuned な process reward model より遅くなりやすい。さらに、Evaluator が自信満々に間違えると、その誤りが残るケースもあり、論文では K=2 の実験で誤予測が最後まで残る例が Algorithmically-Generated で約 20.6%、Hand-Crafted で約 17.2% あったと報告しています。便利だけど、最後の根拠確認まで丸投げするのはまだ怖い、という温度感です。

一言でいうと、RAFFLES は「LLM エージェントの失敗ログを、別の LLM 評価エージェントにデバッグさせる」論文です。