-
-
Notifications
You must be signed in to change notification settings - Fork 0
liplus evaluation criterion
Li+(統治 / 判断 / 対話というメトリック無しドメイン)の評価基準をどう設計するか。完全自動化できるか。
現状の有力案 = 対話そのものが評価(失敗は人間が対話内で指摘)。評価基準を人間の中に置く=農夫の報酬=ゲーム不能。評価者を自動化すると人間評価者が閉じていた gameability の穴が開く(農夫を自動化=犬が "good boy" を偽造=DGM 型 objective hacking)→ 完全自動化は牧羊犬の壁。真の形 = 漸近線「人間が握る天井の下で、自動化の床をどこまで上げるか」。
- depends on: master-verification-at-runtime-not-spec — 人間 anchor は還元不能、static gold 不在ゆえライブ人間に縮退
- relates to: dialogue-evaluator-scoring-redesign — 部分自動化の実装側 = この基準の床を上げる試み
- relates to: liplus-judgment-learning-telos — 人間=天井という現状の正直な限界に対し、judgment-learning がそのギャップを閉じにいく instrument
- relates to: liplus-selfevolution-lineage — AutoResearch ループをメトリック無しドメインへ拡張
0/1 ではない。Li+ は既に部分自動化済: self-eval 10軸 / parallel-subagent-eval / Lay-Lin 相互評価 = コンプライアンス/一貫性の "床"。人間に残るのは方向性/趣味/判断の正しさの "天井"(自動化すると報酬が手に戻るため残る)。床を上げる正攻法 = 偽造不能な現実の結果に接地(foundational-invariant: correctness=観測挙動)、ただし客観還元可能な部分のみ。
部分自動化の試作 = dialogue-evaluator サブエージェント(#1261、reference-only / placeholder)。採用ゲート = サブエージェント評価が Master 自身の評価に十分収束したら採用。= 自己定義メトリックでなく「人間評価への距離」で測る → DGM 穴を設計レベルで回避。
- 統合点は category error: 異質軸の合計/平均は axis-separation 違反。評価単位は軸そのもの=独立 verdict、軸(行)で読む。axis の run 間変動それ自体が診断(安定軸=実観察 anchor / 変動軸=実体が薄く framing・価値観が支配)。
- N 無関係: dialogue-evaluator の甘さは systematic な same-substrate bias(全インスタンス同 priors で揃って甘い)。N≥3+OR が消すのは variance であって shared bias でない。対角線の外(別モデル / 外部 ground truth / 人間のみ)でしか直らない。
-
採点 = 0/100 両端のみ定義、1〜99 は評価者の価値観(較正はしご撤去)。
promotion-judgment.md「criteria 化しない/Judge=AI/reproducibility tradeoff 受容」と同型。鉄則: 観察が成果物・数字は副 / 価値観の違う評価者間で raw 数値を比較しない / calibration は数字でなく Master 評価への収束で行う。 - 外部裏づけ SAGE(2026-05, arXiv 2605.12061): 外部 gold アンカーで writer の reader 騙しを抑えるが、回避できるのは QA が客観正解を静的ラベル可能だから。Li+ の判断/統治/対話は静的 gold 原理的不在 → 外部アンカーはライブ人間に縮退。「人間を天井に」は "人間が優れる" でなく "static gold が取れぬドメインゆえの帰結"。
「天井」に座る人間は 能動的反応面 — passive evaluator でなく違和感→検証 pull(例: 英語成果物に違和感→「日本語にして」と照合可能形へ引き込む)。ゼロ engineering literacy でも felt な質に高解像度(「ボタンの反応遅くない?」=原因を知らず遅延検知)。残る死角の正しい軸 = エンジニア可視性でなく felt-vs-silent: 人間=体感に出る物ほぼ全部 / 装置軸(CI・実機・運用)=構造的に signal を出さない残りのみ。
ただし silent 残りは"客観的欠陥"ではない — correctness = as-required、要求の外に correctness は無い(foundational-invariant)。装置軸は独立 arbiter でなく 要求者が設定する精度 bar を執行する instrument。security はこの還元の外(surfacing が adversarial に誘発され「表に出なければ無害」が崩れる)= 別軸。
- 「評価を自動化しよう」と考えた瞬間、対象が床(コンプライアンス)か天井(方向/趣味)かを判別。天井の自動化は gameability の穴を開け直す。
- 単一自動メトリックを採否ゲートに据えない(AutoResearch/DGM 側への滑り)。
- 死角を literacy 軸で切らない(軸は felt-vs-silent)。
- #1261(dialogue-evaluator landing)/ #1456 #1457(採点再設計)/ SAGE arXiv 2605.12061
この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。
数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。
- 要求(何を満たすか)と仕様(どう振る舞うか)を一体として記述する
- 実装前に作成または更新する
- issue群から採用された要件を集約する
これらのページは 安定性と一貫性を重視して管理されます。
アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。
- 設計思想・背景
- 設定リファレンス・インストール手順
これらのページは 必要に応じて更新・拡張されます。
リポジトリ内の rules/**/*.md(L1–L4 の常時ロード分、subdir 含む)、skills/**/SKILL.md(トリガー起動分)、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+update.md は、
AIやランタイムが直接読む実行用プログラム / 定義ファイルです。
-
docs/は人間向けの仕様書・要求仕様・手順書 -
rules/,skills/および adapter / update は実行時に読み込まれる本体
両者は対応しているが、役割は同じではない。
Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept
要求仕様書 (1-6)
参考文書 (A-K)
- A. Concept
- B. Configuration
- C. Update
- D. Installation
- DiDD(対話駆動開発)
- E. Li+ language
- F. Behavior-First
- G. Sheepdog Engineering
- H. Roles and Evaluation
- K. Source File Format
判断構造
- Decision Structure
- layer reorg rationale
- github app user-to-server token expiration
- sheepdog engineering concept
- prerelease tag recovery procedure
- release flip drift patterns
- Li+ long-term vision (feedback only)
- Master role as client-architect
- current architecture as concession
- Li+ license Apache-2.0 rationale
- Character_Instance evolution history
- prompt as emotion vector controller
- agentic-search five-phase refactor
- Character_Instance output-styles migration
- Li+ lightening L1 gate override
- subagent state-machine label mechanism
- LSP integration out of scope
- Character_Instance opt-in and surface scope
- parallel-subagent-eval three-axis decomposition
- parallel-subagent-eval cost acceptance
- parallel-subagent-eval model floor
- release version rule always-on relocation
- bootstrap walkthrough skip and gh install relocation
- wiki sync sidebar integrity check
- decision structure rename rationale
- decision structure industry positioning
- subtractive structural beauty framing
- Li+ authorship is collaborative
- Li+ design intent vs current limit
- Li+ history is empirical
- Master verification at runtime not spec
- rules cache fetch address table
- dialogue-evaluator scoring redesign
- Li+ always-on footprint is load-bearing
- DiDD umbrella naming
- milestone subsystem removal
- L1 brake 2 root-criteria evaluator
- Hook-driven gate trigger
- dynamic-workflows non-adoption
- ACE context-engineering non-adoption
- memory GraphRAG SQLite exploration
- Li+ context-rot tension
- Li+ structure as retrieval surface
- Li+ evaluation criterion
- Li+ self-evolution lineage
- Li+ judgment-learning telos
- Sheepdog Engineering publish intent