基盤LLMと分離したCapability Layerを、プロンプト・Memory・RAG・Agent構成とどう区別して評価すべきか

基盤LLMとは別に、再利用可能な問題解決能力・意思決定能力を保持するCapability Layerのプロトタイプ「Monster Plugin」を実装しています。

現在の実証機であるhuman-runtimeでは、人間の問題解決・判断能力の一部を永続的なAbility資産として外部化しています。

想定している性質は次のとおりです。

• 基盤モデルを再学習せずにAbilityを追加・更新できる
• 同じAbilityを異なる問題や領域へ再利用できる
• 基盤モデルを変更してもAbility資産を引き継げる可能性がある
• 将来的には現実の結果からAbilityを獲得・更新するループを作る

Monster Pluginあり／なしで100問の回答ペアを生成した探索的比較はこちらです。

現在の比較は条件が完全には統一されていないため、統制されたベンチマークや因果関係の証明として提示するものではありません。

確認したいのは個々の回答の文章品質だけではなく、異なる問題をまたいで次のような一貫した意思決定構造が観測できるかです。

• 表面的な依頼ではなく、本来の目的を保持する
• 目的・制約・症状・手段を分離する
• 一つの経路が失敗しても、目的を放棄せず経路を更新する
• 人間・AI・ツール・アルゴリズム・システムをSolver候補として比較する
• 必要に応じて、個別対応より再利用可能な仕組みを選ぶ

仮にこのような一貫性が見えたとしても、それだけでは長いSystem Prompt、検索された指示、Memory、RAG、Agent workflow、文体模倣などとの差を証明できません。

そこで、次の点について意見をいただきたいです。

1. Capability Layerの存在を検証するために必要なアブレーションは何か
2. 同一トークン量のSystem Promptとの比較は十分か
3. 未知領域への転用性をどう測るべきか
4. 基盤モデル交換後に何を不変量として評価すべきか
5. 複数モデルでの再現性をどの程度示せばmodel-independentと言えるか
6. 人手評価とLLM Judgeをどう組み合わせるべきか

内部のdecision logic、Abilityの具体的表現、routing、更新方式、schema、prompt、ソースコードは現時点では公開していません。

一方で、評価方法と観測可能な出力については厳しめの反例や批判を歓迎します。