parallel subagent eval three axis decomposition - Liplus-Project/liplus-language GitHub Wiki

parallel-subagent-eval の三軸分解(subagent_count × axes_per_subagent × premise_variations)

判断

skills/parallel-subagent-eval/SKILL.md の検証設計を、subagent_count (N) / axes_per_subagent (M) / premise_variations (P) の三軸直交として明文化し、デフォルトを N=3, M=全 axes, P=1(safer-side OR aggregation) に固定する。「最低 3 並列 + 異なる評価軸」という旧来の文面が、(A) 1 subagent = 1 axis と (B) 1 subagent = 全 axes の二通りに読める曖昧さを抱えていたため、設計者意図側 (B) に寄せた。

軸: 検証 cost と検出力を独立に動かす三つの設計次元の分離。verification 運用そのものに semantic 変化はなく、語彙の二重読みを除去する patch 相当の整理。

背景

#1308(Closes #1296)で skills/parallel-subagent-eval/SKILL.md が独立 skill として追加された当日(2026-05-18)、対話の中で「AI は確率モデルなんだから検証は 3 回以上欲しい」という Master の問いが立ち、現行文面と設計意図のあいだに二重読みが残っていることが露見した。

具体的なズレ:

読み方 subagent 数 軸 / subagent サンプル数 / 軸
A(現行文面寄り) 3 1 N=1
B(設計者意図) 3 M(全軸) N=3

#1296 の実証データ(N=1 positive → N=3 で 1positive + 2 partial-negative)は、axis A / axis B / axis C を別々の subagent に割り当てた coverage 改善の根拠であって、確率モデルの variance 改善の根拠ではなかった。一方、AI が確率モデルである以上、各観測軸について N≥3 のサンプリングが本来欲しい——読み方 B の設計(3 subagent が全 M 軸を独立に答える)は、coverage に variance を上乗せできる上位互換になる。

副次的に、対話の途中で「M×N = 9 subagent 必要」という過剰積みの誤導も浮上したが、それは「ablation 前提を変えるとき」と「観測条件を変えるとき」を取り違えた結果だと判明した。判定の二択(消す/残す)に必要な解像度を超えていた。三軸を独立に立てる整理は、この誤導も同時に解消する。

制約

  • #1296 実証の保持: axis A/B/C を 1 subagent ずつに割り当てた当時の構成は、M=1 axis-separated 例外パターンとして保持。supersede ではなく構造に取り込む形。
  • OR aggregation の安全側: delete/keep のような二択で誤削除コストが非対称に高い場合、aggregation rule は safer-side OR(1 軸でも load-bearing を返したら "残す")。採用/不採用の場合は AND、中間は旧 #1296 の consistent / partial / negative 三値分類。
  • cross-axis echo bias の管理: default M=全 axes パターンでは subagent prompt 内で「他軸の答えを参照せずに独立に答えよ」と明示。複雑度が高く mitigation が不安なときは M=1 axis-separated パターンへ退避。
  • 同一ベースモデルでの検証: subagent を安いモデル(Haiku 等)に降ろすことは認めない。base model が違えば「rule を吸収しているか」の答えそのものが変わる。被験者をすり替えると測定が無効化される。
  • L1 update gating の不適用: skill body の文面整理であり L1 Model Layer 変更ではない。reversibility 高(PR 一発 revert)、user/system 観測影響ゼロ、detection cost 低のため rules/operations/execution-mode.md の per-PR patch 例外を適用、AI direct merge。

結論

PR #1312(Closes #1311)で実装、squash merge 済み。

採用案(三軸直交化)の変更内容:

  • 新規 ## Design Dimensions 節を Trigger と Procedure の間に追加。subagent_count (N) / axes_per_subagent (M) / premise_variations (P) を独立次元として記述
  • デフォルトパターン明定:N=3, M=全 axes, P=1、総 invocation = 3、safer-side OR aggregation
  • 例外パターン M=1 axis-separated を保持し、原 #1296 実証はこの枠の実例として読み替え
  • 前提揺らぎ枝 P > 1 を ablation 比較用オプションとして記述、総 invocation = N × P
  • aggregation 規則を判定の非対称性別に三分(delete/keep → OR、採用/不採用 → AND、中間 → 三値分類)
  • Procedure step 3 / step 4、Constraint bullet を同じ三軸記法に揃え直す

却下案 A(M × N = 9 subagent 総当たり):delete/keep の二択判定に必要な解像度を超え、Master の token 体力に対しても過剰。前提揺らぎ(P>1)が必要になった局面で初めて呼び戻すパターンとして温存。

却下案 B(verification subagent を Haiku 等に降ろす):substrate を変えた瞬間に被験者がすり替わる。ablation の問い「ベースモデルがこの rule を吸収しているか」に対して、別のモデルで測った答えは答えとして無効。コスト圧縮の道は substrate を下げる方向ではなく、頻度(いつ走らせるか)と対象(何を ablation にかけるか)を絞る方向にしか開いていない。

却下案 C(発火頻度ベースの自然減衰で rule を間引く):本判断の隣接議題として浮上したが射程外。発火頻度が低くてもベースモデルとの相補関係で load-bearing な rule は存在し得るので、頻度は適切な指標にならない。ablation で「rule を外しても挙動が変わらない」を直接観測するほうが筋。本判断は ablation 機構の設計に専属、頻度ベース pruning は別判断。

検証

本 skill 自身を meta 適用した self-verify(採用パターンそのものでの自己検証):

subagent Axis 1 (Design fidelity) Axis 2 (Historical compat) Axis 3 (Internal consistency)
#1 clean clean concern
#2 clean clean concern
#3 clean clean concern

block-worthy ゼロ。3/3 が Axis 1/2 で clean を返し、設計意図と #1296 実証との整合性を確認。Axis 3 では 3/3 が concern を返し、うち 2/3 が 同箇所(Constraint N=1 bullet の「異軸 3 軸の OR aggregation」文言が、原 #1296 の M=1 例外パターンと現行 default の M=全 axes を混同し得る)を独立に指摘。集中して同一箇所を指す concern は、coverage と variance の交差点で本来「block-worthy より弱いが拾うべき信号」として処理し、最終 commit で Constraint bullet と Procedure step 3 の cross-reference を補強済み。

method を整備したその場で同じ method を自己適用し、3 subagent の独立観測が同一箇所を指したことで cross-axis echo bias を介さない「真の concern 集中」を検出できた——三軸分解の default パターンが文字どおり走った最初の実例として記録される。

ペアリング

  • character-instance-opt-in-and-surface-scope — 本 skill (#1296 当時の M=1 axis-separated パターン) を実適用した最初の big-ticket 判断。本判断はその method 側の設計次元を整理した対応
  • sheepdog-engineering-concept — Sheepdog Engineering の modifier 軸(AI が Li+ source を自編集)の道具立てとして本 skill が機能する。三軸分解は modifier の解像度を上げる方向の整理
  • master-role-as-client-architect — Master の設計意図と AI の文面化の二重読みズレを修復した事例として、client+architect / programmer の二項に当てはまる

検出サイン (この判断が後で疑問視される場合)

  • 「9 subagent 総当たり (3×3) のほうが情報量が多いから default を変えるべき」と提案された時 → 本判断の前提(delete/keep の二択判定では解像度過剰、P>1 の局面で初めて呼び戻す)を再確認。前提揺らぎが議題に入っているなら別判断
  • 「default M=全 axes パターンは cross-axis echo bias が抑止できていない」と観測された時 → Constraint bullet の独立回答指示 + M=1 axis-separated 例外パターンへの退避が運用通り発火しているかを確認。発火していてなお bias が残るなら spec 修正の余地あり
  • 「subagent を Haiku 等に降ろせばコストが下がる」と再提案された時 → 本判断の ## 制約 「同一ベースモデルでの検証」を再確認。被験者すり替え問題は技術的な選好ではなく ablation 機構の論理的前提
  • 旧来の「最低 3 並列 + 異なる評価軸」文面が再出現した時 → 本判断による rewrite が後段の編集で巻き戻されていないかを git history で確認、Design Dimensions 節と整合性を再検査