Files

T

FastheiandClaude Opus 4.8 b5cc68c977 feat(benchmark): 落地自证采集器（阶段0+1）— S_gain≡G_E 接通 S_swarm + leaderboard

阶段0（定口径，docs/benchmark/emergence-evaluation.md §6 v2.1-impl）：
- S_gain ≡ G_E（差值，不强制归一 [0,100]，与标准「见涌现增益」字面一致）。
- 聚合 S_gain 取对最强基线（Q_base 最大）的 G_E（最保守，避免挑弱基线虚高）。
- Q ≡ Q_quality；swarm_valid 仍要求对全部基线 G_E>0 且 G_E,c>0。

阶段1（采集器）：
- 新增 benchmark/collectors/selfcert_collector.py：把套件 5 份 BenchmarkRunRecord
  （swarm+4基线）+ 可选活体 SwarmMetrics 合流，经 baselines.compare 算 G_E/G_E,c，
  补全 run_collector 无法自算的 s_gain/g_e/g_e_cost/s_swarm，可能时产出 Benchmark_Agent。
- benchmark/leaderboard：实现排行榜聚合+渲染（标准 §11 字段）。
- run-benchmark-suite.py 接入自证 + leaderboard 输出。

诚实纪律（组织规则 #9）：缺真实输入一律 NaN+coverage False，不伪造。
- O（可观测性）标准无公式 → 恒 NaN；Gov 计数器未实现 → 无活体治理则 NaN。
- 故完整 Benchmark_Agent 数字仍待 O 公式 + Gov 计数器（阶段2），采集器明列缺口。

验证：新增 test-benchmark-selfcert.py（17 项）+ 现有 benchmark 测试（metrics/
collector/comparison/runners）+ offline suite + 契约冒烟（runtime/merge/freeze）全 PASS。

影响范围：仅 agent_swarm benchmark 模块 + docs；不改 Manager↔Swarm 契约/计费/审计/密钥/发布链路。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-12 17:38:19 +08:00

4.6 KiB

Raw Permalink Blame History

Emergence Evaluation（涌现增益评估）

状态：规划中（公式已对齐，基线运行器/评估器未落地）。

依据：Agent 蜂群指标量化与标准 v2.0 §6.1, §9。配套：baseline-comparison.md、cost-normalized-gain.md、swarm-benchmark-protocol.md。

1. 原始增益

G_E = Q_swarm − Q_base

Q_base 取自四类基线之一（标准 §6.1，附参考系数，由低到高）：

基准	类型	参考系数
Baseline A	Single Agent	×0.75
Baseline B	Chain Agent	×0.85
Baseline C	Sub-Agent	×0.90
Baseline D	Strong Agent	×0.95

⚠️ 参考系数为暂定值（待量化）：×0.75/0.85/0.90/0.95 是人为设定的强度先验，标准未给计算方法；当前不参与公式（G_E 用原始 Q_base），仅作元数据。后续应实测量化（见 baseline-comparison.md §1.1）。代码常量见 benchmark/metrics.py:BASE_COEFFICIENTS。

2. 成立条件（蜂群是否真正优于基线）

蜂群成立要求对全部基线为正增益：

Q_swarm > Q_single  ∧  Q_swarm > Q_strong  ∧  Q_swarm > Q_chain  ∧  Q_swarm > Q_sub

否则蜂群不成立（仅是「多 Agent 工作流」而非有涌现的蜂群）。

仅有原始增益不足以验收：还须经成本归一化（见 cost-normalized-gain.md），证明增益非「堆 Agent / Token」虚高。

3. Q（质量）口径

Q 采用统一质量度量。建议复用标准 §5.3：

Q = Q_quality = 0.4·TestPassRate + 0.3·CodeReviewScore + 0.3·UserAcceptance

并在每组统一采集 Completion / Quality / Cost / Time / Robustness（标准 §10），按场景（Coding / Refactoring / Architecture / DevOps / Bug Fix）分别计算 G_E。

⚠️ Q 的精确口径（是否等于 Q_quality，或综合 Completion/Robustness）v2.0 未唯一指定 → 待对齐。

4. 评测流程（草案）

固定任务集（按场景）。
在 A/B/C/D 与 Swarm 上同一任务集运行，统一采集指标（见 swarm-metrics-schema §0）。
计算每场景 Q_*，得 G_E = Q_swarm − Q_base。
进入成本归一化（G_E,c）。
多次运行取均值并报告方差/显著性。

5. 实现状态

组件	位置（规划）	状态
基线运行器 A–D	`benchmark/baselines/`	🔴 未实现
基线 benchmark 套件 / 数据集	`benchmark/baselines/` + `test-data/`	🔴 未实现
基线对比	baseline-comparison	🔴 未实现
涌现评估器（G_E）	`benchmark/`	🔴 未实现
归一化增益评估器（G_E,c）	cost-normalized-gain	🔴 未实现

在以上落地前，不得宣称已验证蜂群涌现能力（重大能力缺口）。

6. 实现口径（v2.1-impl，2026-06-12 落地自证采集器时锁定）

标准 §5.1 写 S_gain 「见第 6 节涌现增益」，但未给从 G_E（差值）到 S_swarm 分量的换算。落地采集器（benchmark/collectors/selfcert_collector.py）按以下口径执行，不引入标准外的归一化/魔法系数：

S_gain ≡ G_E：直接取涌现增益值。S_swarm 的若干分量（V_speed/E_cost/S_cost）本就可超过 100，故 S_gain 不强制归一到 [0,100]，与标准字面「见涌现增益」一致。
聚合基线 = 最强基线：当对 4 类基线分别得 G_E_i 时，进入 S_swarm 的单一 S_gain 取对最强基线（Q_base 最大者）的 G_E，即 min_i G_E_i——最保守口径，避免挑弱基线虚高。逐基线 G_E_i / G_E,c_i 仍全量保留在 leaderboard。
Q ≡ Q_quality（标准 §5.3，掩码归一见 swarm-metrics-schema §4）：与 §3 一致。
成立硬条件不变：swarm_valid 要求对全部基线 G_E>0 且 G_E,c>0（见 §2 与 baselines.evaluate）。

⚠️ 该口径为实现级裁定，已与 owner 对齐（「标准见 docs/benchmark/，S_gain 见涌现增益」）。若后续标准 v2.x 给出不同换算，以标准为准并同步本节。

7. 待对齐

四类基线的标准实现（尤其 Strong Agent / Chain Agent / Sub-Agent 的定义边界）与统一数据集。
运行次数、方差/显著性门槛。
Benchmark_Agent 仍缺两分量：O（可观测性，标准无公式）、Gov（计数器未实现，见 governance-score.md）——采集器对二者诚实置 NaN + coverage=False，故完整 Benchmark_Agent 数字待这两项落地。

4.6 KiB Raw Permalink Blame History Unescape Escape