小さいモデルにナレッジグラフを渡すと、答えに中間物が混ざって精度が落ちることがあります。Qwen 3.5 の 4B で、段数が2以上のクラフトレシピ71問を解かせたら、グラフなしで 12.7% だった完全一致が、直下の材料を1歩渡したときに 1.4% まで落ちました。recall は 0.26 → 0.33 と上がっているので、正しい材料は受け取れています。落ちているのは precision (0.19 → 0.16) です。
「知識を渡したのだから精度が上がるはず」と、設計の見積もりで前提にしたくなる挙動のうちで、これが一番外しやすい一つです。
Minecraft (Java Edition) のクラフトレシピ 429件を正解データにしました。公開されていて機械可読、人手のアノテーションを挟まないという点で、この分野では珍しい素材です。
「何ホップから辿れなくなるか」は測られてこなかった
ナレッジグラフが要る理由は、たいてい「LLM は関係を辿れない」と説明されます。ただ、Plancraft・Orak・Crafter といった先行の計測は、どれもタスクの成否で測っていて、ホップ数を軸にしていません。「何ホップから辿れなくなるか」を直接見た例が見当たらないので、自分で測りました。
Minecraft を選んだ理由は、正解が公開されていて機械可読だからです。多くの評価は「public な正解データが無いので人手でアノテーションする」のが通例で、そこが弱点になります。クラフトレシピは、ゲーム自身が正解を配っています。
正解データと段数の定義
build_graph.py が PrismarineJS/minecraft-data (pc 26.1、MIT。レシピデータ自体は Minecraft Wiki 由来の CC BY-SA 3.0) から機械的に生成します。
アイテム 1,506
クラフト可能 887
エッジ 2,261
分岐ありで除外 439
葉がクラフト可能で除外 57
正解データ 372 段数分布 {1: 161, 2: 158, 3: 42, 4: 9, 5: 2}
段数 (level) は次のように決めました。
level(x) = 0 x を作るレシピが無い (原材料)
level(x) = 1 + max(level(材料)) レシピがある
2種類の曖昧さは、除外しています。これをやらないと LLM の正しい別解を誤りと採点してしまいます。
| 曖昧さ | 例 | 扱い |
|---|---|---|
| 循環 | 鉄インゴット ⇄ 鉄ブロック / ナゲット | 探索中のスタックに載る材料を要求するレシピを外す。全部外れたら原材料扱い (鉄インゴットは実際には製錬で得るのでこれが正しい) |
| 分岐 | 「どの木材でも可」「どの色の羊毛でも可」 | 材料集合が2通り以上あるアイテムは正解データから除外 (439件) |
2条件 - bare と graph
課題は1問で、答えは短くて済みます。
In Minecraft (Java Edition), list ALL base materials required to craft one X.
これに2つの条件で答えさせました。
| 条件 | 渡すもの |
|---|---|
bare |
何も渡さない。モデルの記憶だけ |
graph |
直下の材料だけ をコンテキストに入れる (グラフから1ホップ引いた状態)。原材料までの答えは渡さない。辿るのはモデルの仕事 |
graph が bare を上回れば、それがナレッジグラフを足す価値そのものになります。
モデルは qwen3.5 の 0.8b / 2b / 4b / 9b / 35b-a3b の5サイズ。ローカルの RTX 4070 12GB で Ollama から読みました。
L2以上71問の集計
標本は101問 (L1 30 / L2 30 / L3 30 / L4 9 / L5 2)、5サイズ × 2条件 = 1,010回、パース失敗0件、温度0各1回。段数1は graph が答えそのものを渡しているので、知識ではなく指示追従の下限しか測れません (0.8b は答えを渡されても3回に1回しか写せない)。以降は L1 を外して集計します。
L2以上 (n=71) の平均が次です。
bare rec/prec graph rec/prec 完全一致 bare→graph
0.8b 0.11 / 0.02 0.05 / 0.04 0.0% → 0.0%
2b 0.10 / 0.04 0.09 / 0.05 0.0% → 0.0%
4b 0.26 / 0.19 0.33 / 0.16 12.7% → 1.4% ← 悪化
9b 0.41 / 0.39 0.56 / 0.53 35.2% → 49.3%
35b-a3b 0.24 / 0.23 0.36 / 0.35 18.3% → 31.0%
4B だけが、グラフを足すと完全一致を下げています。
中間物をそのまま答えに混ぜている
なぜ下がるのか。応答を見ると素直な理由が出てきます。
Spruce Stairs 正解 [spruce_log] 直下として渡したもの [spruce_planks]
4b bare → ["spruce_wood"] (誤り)
4b graph → ["spruce_log", "spruce_planks"] (正しい材料 + 渡された中間物)
Respawn Anchor 正解 [crying_obsidian, glowstone_dust] 渡したもの [crying_obsidian, glowstone]
4b graph → ["crying_obsidian","glow_dust","glowstone","glowstone_dust","obsidian"]
プロンプトには「中間物は挙げるな」と書いてあります。4B はこれを読んでも、直前に見せられた語を落とせません。recall は上がっても (正解を含めてはくれる)、precision が落ちます (余計なものを混ぜる)。この現象は arXiv 2603.11513 で「7B未満では正しい文脈でも成績を落とす」と報告されている境界と一致します。現象名は contextual entrainment です。
グラフを足せば精度が上がる、とは限りません。使えるだけの容量が要ります。
大きいほうが強いとは限らない
同じ系列の 35b-a3b は、9b に負けています (bare 18.3% vs 35.2%、graph 31.0% vs 49.3%)。この 35b は総パラメータで、a3b は MoE のため1回の推論で動くのは約3Bぶんです。
ただし「MoE だから」で説明するのは、私自身が一度やって撤回した側の説明です。上の測定は全部 think=false で、qwen3.5 のこの系列は思考前提の設計だからです。
35b だけ思考を有効にして測り直すと、符号が反転します (L2以上 n=71)。
思考なし bare 18.3% graph 31.0% +12.7
思考あり bare 28.2% graph 19.7% -8.5
思考は記憶からの想起に効きます。 一方で、渡された文脈への引きずられを強めます。落ちた問題の形は 4B と同じです。
Birch Boat 正解 [birch_log] 渡した直下 [birch_planks]
→ ["birch_log", "birch_planks"] 正解 + 渡されたものを混ぜる
Spruce Door 正解 [spruce_log] 渡した直下 [spruce_planks]
→ ["spruce_planks"] 渡されたもので止まる
9b の思考ありは、まだ測れていません。構造化出力を指定すると空配列になり、外すと出力上限を思考に使い切って答えに到達しませんでした。なので「35b は 9b より弱い」は think=false 限定の主張です。
段数で崩れるのは L3 から
9b の graph 条件が一番はっきり段数の効果を見せます。
L1 90% → L2 70% → L3 37% → L4 22%
L1 と L2 の差は、問題の難易度が揃っていないので単純には比較できません (L1 には Mace ← breeze_rod + heavy_core のような難問が入ります)。L2 から L4 への低下は、同じ形式の問題での低下なので、これが段数の効果です。
失敗の型も 35b と 9b で違います。35b は「途中で止まった」(直下の材料をそのまま答えた) が 37% で、9b の 12% より格段に多い。35b は展開せずに止まり、9b は展開して間違えます。
読み取れること
ここまでをまとめます。
- 4B にグラフを1歩渡すと、完全一致が 12.7% → 1.4% に落ちる。 recall は 0.26 → 0.33 と上がっている。原因は precision (0.19 → 0.16)
- 現象名は contextual entrainment。 arXiv 2603.11513 の7B未満の境界と一致
- 9B 以上でグラフの効果が正の方向に出る。 35.2% → 49.3% (9b) / 18.3% → 31.0% (35b think=false)
- 35B の思考ありは符号が逆転する。 思考は記憶からの想起には効くが、渡された文脈への引きずられを強める
- 崩れるのは L3 から。 9b graph で L2 70% → L3 37% → L4 22%
設計の見積もりに使えるかたち
ここから、ナレッジグラフを LLM に足すときの設計に使える結論が3つ出ます。
- 4B 以下の小型モデルに「直下の材料だけ」を渡す足し方は、効くとは限らない。recall 寄りの用途 (ざっくり関連を拾う) なら使えるが、completeness が要る用途 (材料集合をそのまま出す) では使わない
- 使うなら 9B 以上。「中間物を答えに混ぜるな」の指示を、文脈の縮尺に負けない容量のモデルで読ませる
- 「思考ありなら勝つ」は、grafh ではなく bare 側で効く。知っているものを引き出すには思考が効き、知らないものを渡されて辿らせると思考が負荷になる
Qwen 系で「サイズを下げたい」話が出るとき、グラフを足して小型を補う、という議論になりがちです。ここでは逆方向で効く構成が存在します。本の中で別のモデル系列を扱うときも、bare/graph 比較は最初に測るやつに入れておく価値があります。
まとめ
- Qwen 3.5 の 4B に KG の直下材料を1歩渡すと、L2以上71問で完全一致が 12.7% → 1.4% に落ちます
- 落ちているのは precision。recall は 0.26 → 0.33 と上がる (正しい材料は受け取れている)
- 9B 以上で効果が出ます。9b は 35.2% → 49.3%、35b-a3b (think=false) は 18.3% → 31.0%
- 崩れるのは L3 から。9b graph で L2 70% → L3 37% → L4 22%
測定条件
本記事は iris-lab exp033「クラフトの段数 × LLM の展開精度」(2026-09-05 実施) の結果を公開情報の形に再構成したものです。後続の実験は nhop-bench (MIT) に移していて、こちらで同じ正解データと実行手順が再現できます。
- 正解データ: PrismarineJS/minecraft-data pc 26.1 (MIT、レシピデータは Minecraft Wiki 由来の CC BY-SA 3.0) から機械生成の372件
- 標本: 101問 (L1 30 / L2 30 / L3 30 / L4 9 / L5 2) × 5サイズ × 2条件 = 1,010回、パース失敗0、温度0各1回
- モデル: Ollama 経由
qwen3.5:0.8b/2b/4b/9b/35b-a3b(RTX 4070 12GB) - 文献: arXiv 2603.11513 (7B未満での同現象) / 2604.13275 (contextual entrainment の命名)
- 新規実測はしていません。数字は exp033 の
results.jsonと nhop-bench に残っています
限界:
- 材料の「種類」の集合だけで採点しています。個数は見ていません
- 分岐のあるレシピ439件と、葉がクラフト可能な57件を除いているので、対象は木材・石材系に偏ります
- L4 は 9問、L5 は 2問しかありません。深い側の数字は参考値です
-
graph条件は1ホップのみです。全部渡せば当然 100% に近づくので、「グラフを全部渡す」ではなく「グラフを1歩だけ渡す」で測りました - 温度0で各1回。ばらつきは測っていません
-
think=trueは 35b-a3b でしか測れていません
破棄した1回目 (results-v1-flawed.json) の記録は残してあります。プロンプトは「クラフトできないものまで展開せよ」と書いていたのに、正解データの葉には精錬で得る中間物 (stone / glass / brick) が入っていて、正しく深く展開した答えを誤りと採点していました。止まる場所を例つきで書き直し、葉がクラフト可能な問題を除外して回し直したのが、本記事の数字です。
関連する既published記事:
- GraphRAG自作はJEMHopQA 120問でベクトル検索73.3%に負けた: 日本語マルチホップ QA ベンチでの vector vs 自作 graph の比較
- GraphRAGが優秀なのは精度だけ:構築コストを1万件で実測した: 構築側のコスト計測
- GraphRAGは本当にVector RAGより優秀なのか: 自ドキュメント1万件での比較
続きはこちら
静的解析ベースのコードKGにも、似た「渡したものが答えに混ざる」とは別種の、「渡されるべきものが欠けている」問題があります。こちらで実データの数字を見ています。
KG を実務の決済経路に入れる前に、「ゼロと未知が同じ表示になる」部分を見ておくと、本番で踏みにくくなります。
RAG・MCP・ローカルLLM を実際に動かして測った記事を書いています。続きが気になる方は Qiita でフォロー してもらえると、次の記事が届きます。
LLM × KG のユースケース設計を仕組みから書き下したのが、拙著の第7章 (ユースケース) + 第4章 (KGを7ステップで組む) です。