RAGが正しい証拠を持っていても誤答するSAEGを回避する方法をAWS Bedrockで試してみた - 3つのベンチマークで分割呼び出しの効果を検証する -

はじめに

前回は "Why Retrieval-Augmented Generation Fails: A Graph Perspective"（Kai Guo et al., 2026）を読んで、RAGが正しい証拠を持っていても誤答するメカニズムをSAEGとQCEGで整理しました。SAEGは質問を深く処理する前に証拠の表層パターンに飛びつく失敗パターンで、論文はCircuit Tracingによってこの差を帰属グラフの構造として可視化していました。

ただし論文の手法はTransformerの内部構造に直接介入するもので、BedrockのAPIモデルには使えません。ならばAPIの呼び出し設計でSAEGを回避できないか、が今回の出発点です。論文が示したQ→Qルーティングの考え方をAWS BedrockのAPI呼び出し構造で近似し、呼び出しを2段階に分割するsplit callで実装しました。3つのベンチマークデータセットで効果を確かめています。SAEGやQCEGの詳細は前回を参照してみてください。

結果、2WikiMultiHopQAで50.0%→64.0%で+14.0pp、MuSiQueで40.0%→52.0%で+12.0ppの正答率改善が確認できました。HotpotQAは70.0%→70.0%で±0.0pp。呼び出し構造を変えるだけで論文と同じ方向の改善が再現できました。思ったよりシンプルな近似でもちゃんと数値が動きました。

---

実験の設計

通常RAGとsplit callを比較する

論文の手法はTransformerのAttention重みをforward hookで直接制御するもので、BedrockのAPIモデルには適用できません。今回の検証では、SAEGの根本にある問題、つまり証拠を見る前に質問が浅い状態で推論が進む現象を、呼び出し構造で近似しました。

比較した構成は2つです。通常RAG（以降ベースライン）は全文書を一度に渡して回答させる単一呼び出しで、split callは以下の2ステップに分けます。

• Call 1（証拠なし）：質問だけ渡して、正答に必要な条件を列挙させる

• Call 2（Call1の条件リスト＋全文書）：Call 1で列挙した条件を全て満たす答えを証拠から導かせる

Call 1で証拠を見せないことで質問の構造を先に言語化させます。Call 2で自分が整理した条件を参照させることで、Q制約（質問から導いた条件リスト）を回答生成まで持続させます。前回の記事で紹介したプロンプトで強制するアプローチに近いですが、呼び出し自体を分割することで構造として保証しています。

使ったデータセットと評価方法

モデルはMeta Llama 3.1 8B Instruct（us.meta.llama3-1-8b-instruct-v1:0）をBedrockで使用し、temperature=0に固定しました。各データセットはSEED=42で50問をサンプリングしました。

データセット	設定	文書数/問	ホップ数
HotpotQA	distractor設定（gold 2文書 + 無関係な8文書を混入）	10文書	2ホップ
2WikiMultiHopQA	validation split	10文書	2ホップ（bridge/comparison混在）
MuSiQue	train split / answerable=Trueのみ	20文書	2〜4ホップ

評価はLLMジャッジによる二値正誤判定を使いました。論文はGemini-2.5-Flash-Liteをジャッジモデルに使用していますが、今回はAPI制限の都合でClaude Sonnetを代用しました。ジャッジには質問/正解/予測の3つを渡し、セマンティックに同じ情報を伝えているかを判定させました。表現や言い回しの違いは許容し、事実の正誤のみで判断しています。

---

結果

データセット	ベースライン正答率	split call正答率	改善幅
HotpotQA	70.0% (35/50)	70.0% (35/50)	±0.0pp
2WikiMultiHopQA	50.0% (25/50)	64.0% (32/50)	+14.0pp
MuSiQue	40.0% (20/50)	52.0% (26/50)	+12.0pp

（pp はパーセントポイント）

難しいデータセットほど改善幅が大きい傾向がありました。HotpotQAが改善しなかった理由は後述します。

問題タイプ別の内訳を見る

50問それぞれをベースラインとsplit callで比較した内訳です（LLMジャッジの二値判定）。

	HotpotQA	2WikiMultiHopQA	MuSiQue
両方正解	32問	20問	16問
split callのみ正解（改善）	3問	12問	10問
ベースラインのみ正解（悪化）	3問	5問	4問
両方不正解（改善不可）	12問	13問	20問

HotpotQAはbridge型とcomparison型（各々次の項目で説明）が混在するデータセットで、split callの効果は問題タイプによって真逆に出ました。bridge型ではConditions先出しが多段推論を助け正答率が上がる一方、AとBのどちらが〇〇かを問うcomparison型では比較の向きを逆転させてしまうケースが出ました。2つの効果が打ち消し合い、トータルでは±0.0ppになりました。

2WikiMultiHopQAとMuSiQueでは改善が悪化を大きく上回りました。

entity-bridging型の質問で改善が確認できた

3つのデータセット全体を通じて、split callで正答率が上がったのは中間エンティティを経由して答えを特定するentity-bridging型でした。AはBを持つ、BのCはDである、Dは何か、というように答えに至るまで複数の情報を橋渡しする構造の問題です。

MuSiQueでの例：

Q: "Xの出生地がある州の郡はどこか？"
正解: Marshall County
ベースライン: Mississippi（州レベルで止まる）
split call: Marshall County, Mississippi（正解）

ベースラインはX→出生地→州のホップで止まり、州名を返してしまっています。split callではCall 1で出生地→州→郡を特定するという条件を先に整理するため、Call 2で郡まで追いかけることができました。

2WikiMultiHopQAでの例：

Q: "あるフィルムの監督の父親は誰か？"
正解: Leopoldo Torres Ríos
ベースライン: Leopoldo Torre Nilsson（監督本人の名前）
split call: Leopoldo Torres Ríos（正解）

ベースラインは監督というキーワードに引きずられて監督名を返してしまっています。split callではCall 1で監督→その父親という2段の条件を先に立てることで、二番目のホップを正しく踏んでいます。

comparison型の質問では逆効果になった

HotpotQAと2WikiMultiHopQAの中にはAとBのどちらが〇〇かという比較を問うcomparison型が混在しています。このタイプではベースラインが正解してsplit callが誤答になるケースとなりました。

Q: "Elmer W. ContiとSeth Joshuaでは、どちらが早生まれか？"
正解: Seth Joshua
ベースライン: Seth Joshua was born earlier.（正解）
split call: Elmer W. Conti was born earlier.（不正解）

Call 1で2人の生年を特定して比較するという条件を正しく立てていますが、Call 2で実際に比較するとき8Bモデルが比較の向きを逆転させてしまいました。ベースラインが文書から2人の生年をそのまま拾って直接比較できるところを、split callが余分な推論ステップを踏んで裏目に出た結果と思われます（余計に考えさせると8Bサイズのモデルには荷が重かったのかな）。

---

考察

改善幅はなぜデータセットによって違うのか

HotpotQA ±0.0pp、2WikiMultiHopQA +14.0pp、MuSiQue +12.0ppという差を生んでいる要因を整理します。

文書数が多く、ホップ数が多いほどSAEGが起きやすい傾向があります。HotpotQAは10文書・2ホップですが、MuSiQueは20文書・2〜4ホップで、ノイズの多い環境ほど証拠の表層に引っ張られる力が強くなります。split callのCall 1で何を探すかを先に決めることで、文書が増えるほど効果が大きくなると思われます。

また、HotpotQAは改善された数とcomparison型の質問で不正解になってしまった数がちょうど同じであったため、数値上は改善していないとなってしまいました。

両方不正解の数がMuSiQueで20問あり、8Bモデルの能力上限に当たっているケースはsplit callでも解けないと考えています。改善の余地は2WikiMultiHopQAのほうが広く、split callのみ正解が12問ありました。

---

まとめ

論文が示したSAEGの分析をAWS Bedrock環境で近似的に検証しました。split callによる呼び出し分割は、entity-bridging型の複雑な質問に対して明確な改善効果があり、2WikiMultiHopQAで50.0%→64.0%で+14.0pp、MuSiQueで40.0%→52.0%で+12.0ppの正答率改善が確認できました。HotpotQAは70.0%→70.0%で±0.0pp、bridge型での改善とcomparison型での悪化が相殺されました。

今回の実験ではなぜこの設計にするかをSAEGのメカニズムから説明できるのが、経験則でプロンプトを調整する手法と差別化出来る点だと感じています。ちゃんと理由に基づいた改善であるので、話がしやすいのかなと。

おわり！

参考

• Why Retrieval-Augmented Generation Fails: A Graph Perspective（Kai Guo et al., arxiv 2605.14192, 2026）

• HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering（Yang et al., 2018）

• 2WikiMultiHopQA: A Dataset for Evaluating Cross-Document Reasoning（Ho et al., 2020）

• MuSiQue: Multihop Questions via Single-hop Question Composition（Trivedi et al., 2022）