zizi 57b2593c41 fix(llm)+docs(eval): 双侧剥 think 防御 + M2.7-highspeed 升级门(不过门留任 M2.7)

- 剥 think 归一化(py/Java 语义对拍): 剥头部 <think> 块→整体试 JSON→字符串感知花括号
  配平提取(伪 JSON 顺延)→全失败原样透传维持原错误路径; Java 用 FAIL_ON_TRAILING_TOKENS
  专用 mapper 对拍 json.loads 严格语义; py 9 用例+全套 68 绿, Java 7 用例+模块 57 绿
- 升级门判定: highspeed 结构层 52/52(泄漏 27/52 剥除全救)但策划探针 P1 4/13>基线 2/13
  (2 条特有'裸 config 漏三键包裹'契约失败, schemaOk 11/13)+时延无增益→按'任何缺口=留任'
  铁律不过门; 待补=prompt 形状强化+M2.7 时延基线
- 防御对 M2.7 当日泄漏回归(batch-002 折损根因)同等生效, 部署后 batch-002b 补产可恢复

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-10 06:12:31 +00:00

5.7 KiB

Raw Blame History

MiniMax-M2.7-highspeed 主力升级门 · 评测小结

日期：2026-06-10 ｜评测工程师独立跑批 + CSV/raw 独立复算对账被测修法：解析侧剥 think 防御（orchestrator/llm_client.py::normalize_llm_json_content，本 harness 经 import 复用，未复制实现；本机单测 9/9 绿）总预算消耗：80/90（smoke 1 + 结构层 52 + 探针 27），零超闸

一、门判定（结论先行）

门条件	实测	判定
A. 结构层 ≥52/52 基线持平	52/52 = 100%（四模板各 13/13，零重试）	过
B. 策划探针 P0/P1 与既有两候选（各 2/13）同量级	P0 0/13 持平；P1 4/13（基线各 2/13 的 2 倍），其中 2 条为 highspeed 特有「裸 config 漏三键包裹」契约失败诱发；schemaOk 11/13 < 基线两候选各 13/13	不过（缺口）

最终裁决：不过门（按「任何缺口 = 留任」铁律）。 结构层硬线过、剥 think 修复完全有效；缺口在策划位输出契约纪律，非 think 病灶本身。

二、A 结构层明细（52 次，配方=struct_eval.py 逐字复用）

通过率：52/52 = 100%，与 M2.7 基线（spike-eval.csv 52/52）持平；clicker/dodge/runner/match 各 13/13。
think 泄漏：27/52（51.9%） content 以 <think> 开头（概率性病灶实锤，远高于 M3 路在 probe 腿的 6/13）；剥除后 27/27 全部救回（泄漏抢救成功率 100%，零条因泄漏失败）——若无该修复，结构层将跌至 25/52，比 M3 出局时的 22/52 略好但同样必死。
时延（最终采纳调用，n=52）：avg 9911ms / p50 9326ms / p95 15674ms（min 5170 / max 19360）。
- 对照 v4-pro（avg 7591 / p50 5671 / p95 17956）：avg 慢 30.6%、p50 慢 64%，仅 p95 尾部更优；
- 对照 M3（avg 10383 / p50 8921）：avg 快 4.5%、p50 反慢——「highspeed」卖点在短 prompt 结构层不成立；
- M2.7 本尊无逐次时延基线（既有缺口），无法证明相对主力不劣化。
调用消耗 52/56，零空 content、零 HTTP 错误；config 抽查 3 例真 JSON；自报与 CSV 独立复算零出入。

三、B 策划探针明细（13 创意 × 各一轮，统一 M2.7 + 对抗 v1.1.1 评审）

指标	m27hs	基线 m3	基线 v4p	读法
P0 检出	0/13	0/13	0/13	持平
P1 检出	4/13	2/13	2/13	2 倍，不同量级
schemaOk	11/13	13/13	13/13	新失败模式
think 泄漏	9/13	（6/13，M3）	0/13	全部被剥 think 救回
intent 均长	42.8	42.8	42.3	持平
生成均时延	15240ms	24584ms	22703ms	长 prompt 下反而最快

P1 归因（关键）：#07「海底捞珍珠」（kill 守卫 k-0cfbc296 同源锚点，两基线候选同位命中）与 #08「烧烤摊烤糊机制缺失」为真实内容质量 P1 —— 内容质量面 2/13 与基线同量级；#01/#02 的 P1 由「模型只输出裸 GameConfig、漏 {designIntent, expectedPlaySeconds, config} 三键包裹」直接诱发（config=null/designIntent=null），该契约失败模式两基线候选 0 发生。
think 文本里明明推理过 designIntent 却没包进输出（gen-01 raw 可证）——是输出纪律问题，非能力问题；但主力位以契约论。
#05 曾出现 reasoning 吃光 4096 额度（finish=length、reasoning_tokens=4096、</think> 后零负载）：属通道公平性问题（m3/v4p 的 reasoning 走 reasoning_content 字段、content 真空会享提额重试，highspeed 混进 content 绕过判定），已修 harness 判定（think-only 等同空 content）并重测——重测一发过 schema、评审 0 findings。重测全程入台账（calls.jsonl），其余 12 条 raw 复用未动。

四、剥 think 修复结论（独立于门判定）

修复有效且必要：本轮 36 处泄漏（结构层 27 + 探针 9）全部救回，剥除成功率 36/36 = 100%；评估矩阵前置的「解锁 M3 类模型」目标达成（M3 复测前置条件已满足）。
修复对纯净通道零扰动（归一化改写仅发生在泄漏条目，27/52 与泄漏数严格相等）。

五、若要转正的待补清单

三键包裹契约失败（2/13）：在策划 prompt 显式强化输出形状约束（或 run_batch schema 重出回炉实测回收率）后重测探针；
时延：补 M2.7 本尊同口径 52 次时延基线，才能判「不劣化」；highspeed 在结构层短 prompt 比 v4-pro 慢 30%，但长 prompt（策划位）比两候选快 33-38%——选型应按工位分别裁决；
reasoning 吃光额度为概率性（1/14 次生成调用），建议生产侧固化「think-only 等同空 content 提额重试」判定（本轮 harness 修法可平移 ExecutorLlmClient/llm_client）。

六、产物索引（均在本目录）

产物	说明
`struct_eval_m27hs.py`	结构层 harness（import struct_eval 基线配方 + import llm_client 剥 think）
`struct-m27hs.csv` / `struct-m27hs-run.log` / `raw-struct/`（52 文件）	结构层 52 行明细 / 运行日志 / 原始响应全量
`designer_probe_m27hs.py`	探针 harness（含 think-only 公平性修法，差异注释在文件头）
`designer-probe-m27hs-results.json` / `-calls.jsonl` / `-run.log` / `-rerun05.log` / `raw-designer-probe/`（26 文件）	探针结果 / 调用台账 / 首轮与 #05 重测日志 / 原始响应全量

caveats：① 探针样本仍仅 clicker 单模板 13 创意（与基线探针同限制）；② 两基线候选 P1 2/13 为同口径（对抗 v1.1.1 + M2.7 评审）可直比；③ #05 重测系通道公平性补测非质量重 roll，台账可审计；④ acceptable 列留空待创始人盲评（沿基线惯例）。

5.7 KiB Raw Blame History Unescape Escape