2026-07-26　·　防御軸　·　未再検証

実モデルでの信頼スイッチ実験：+8.3%、しかし統計的には何も起きていません

60 の対応のあるタスクで、信頼層のオン・オフによって合格率は 51.67% から 60.00% に上がりました——しかし 95% 区間は 0 をまたぎ、McNemar p=0.332、検出力は 0.163 しかありません。同じデータには、もっと意味のある結果がもう一つあります。

実モデル実験McNemar検出力

これは本研究で初めて実モデルで行った対応のある防御実験であり、私たちが初めて手にした「実モデルでの null 結果」でもあります。

#設計


モデル	qwen3.6-35b-a3b @ 100.119.113.56:8765
問題バンク	EvalPlus MBPP+ v0.2.0（378 問、sha256 で固定）
タスク	60 の対応のあるタスク
名簿	デモ用の名簿に、破壊者を人為的に 2 人植え込む
対応キー	`task_id` = `sha256(prompt + tests)`、アーム間で安定
品質判定	アームの外での `compile_check(t.check)(answer)`

アーム	合格	有効	合格率	所要時間	ledger イベント	合格あたりの呼び出し
off	31	60	0.5167	6,837.5 s	ROUTE 60、ATTEMPT 60、DELIVERED 60	1.94
on	36	60	0.6000	6,168.0 s	+REVIEW 180、AUDIT 60	1.67

良さそうに聞こえますが、統計的には何も起きていません

区間は 0 をまたぎ、p = 0.332。 しかも検出力は 0.163 しかなく、80% の検出力を得るには n = 337 が必要です。

この偽の結果は単独で語る価値があります

しかし off アームは設計上監査しないので、その audit.passed は常に空です。結果：

修正後は off 7/12 vs on 5/10——差はありません。

この件は典型的な落とし穴として examples/realmodel_suite.py のコメントに残してあります。一般則：「ある機能をオンにしたもの」と「オフのもの」を比べるなら、品質の判定基準は、決してその機能自身が生成したフィールドであってはなりません。

私たちは破壊者に割り振られた仕事量も測りました。これは「悪い仕事をしても仕事をもらい続ける」ことの直接の指標です。

	破壊者に割り振られた割合
off	20 / 60（33.3%）
on	11 / 60（18.3%）


破壊者は人為的に植え込んだもの	自分で悪事を覚えたわけではありません。攻撃者の能力は過小評価されています。
破壊者 2 人 / 住人 8 人	規模が非常に小さく、生態系としての相互作用はほとんど存在しません。
単一モデル	qwen3.6-35b-a3b。モデル横断ではありません。
監査率 0.2、評価者の正確さ 0.7	どちらの定数も設定値で、測ったものではありません。
n = 60	検出力 0.163。n = 337 が必要です。