实验分享：scope 与蒸馏的两份体检——strictScope 考卷 + 压缩悬崖保真

[modusensus]

#280 三问闭环之后，实验线又跑了两场，各对应一条产品线的「体检」：E7 strictScope 考卷（scope 隔离，0.8.x 线）和 E8 压缩悬崖保真（蒸馏链，#24 线）。一场是机制确认加一个意外收获，一场是警告贴。全部 Kaggle T4 × qwen3:8b、温度 0、会话内配对/机械溯源口径，数据与脚本在 persistbench-sycophancy（v5 tag 已含全部内容）。

E7｜strictScope 考卷：硬墙精确，软档在注入通道不存在

MUMBench（AIM, arXiv 2609.12320）带来的可检验问题：我们的 strictScope 可见性判定，等价于论文说的「索引级访问控制」吗？

造池：100 个合成多用户样本——用户 X 的任务请求 + X 自己的约束 + 用户 Y 的同话题私有记忆（带唯一 marker 值：Y 的过敏原是花生而 X 的是乳糖这类）+ 干扰项。Y 与 X 的条目同 importance 档——对泄露风险最有利的假设。三臂 n=80：

臂	scope 状态	Y 私有条目进注入	响应含 Y marker
S2	无标注（现行默认 scopeEnabled=false）	100%	47.5%
S1	explicit 标注 + 软档（foreign ×0.5）	100%	45.0%
S0	explicit 标注 + strictScope 硬墙	0%	11.2%（背景猜测率）

三个读数：

1. strictScope=true 行为等价索引级控制：注入级零暴露、fail-closed 精确——0.8.1 收窄到 explicit-only 的语义拿到了端到端数据版本。
2. 软档是装饰性的：S1 与 S2 的注入集逐样本相同（80/80）。代码事实（injectCandidates 里只有 strictScope===true 才过滤）得到了数据确认：A2 软加权只作用于显式检索通道，自动注入——默认管线的主泄露面——只有「关」和「硬墙」两档。S2/S1 下 Y 的私有条目 100% 进注入上下文，响应级可归属内容污染 +36.2pp（不可猜的型号名 marker 40% vs 背景 0%，溯源干净）。
3. 泄露 judge 自己就是第一个越权者（意外收获）：S0 硬墙下注入零 Y 内容，LLM judge 仍判 92.5% 泄露；仪器核查显示 judge 的 leaked 字段 97.8% 是 y_private 原文回显而非响应引文，连 utility 都反向（干净响应 3.11 < 泄露响应 3.80，合规被罚）。MUMBench 的核心数字「可见性分类 96% vs 严格操作 58.8%」在我们的 judge 身上逐字重演。结论：LLM 泄露判定必须配唯一 marker 机械溯源，「看得到私有清单的 judge」不可信。

E8｜压缩悬崖保真：静默失守有一个机器形态

Compaction Cliff（arXiv 2608.22752）的管线等价物审计：Claude Code 的 /compact 一轮后安全规则剩 53%、五轮剩 10%。我们的有损链是：蒸馏（LLM）→ dream 巩固（LLM）→ sleep 降级（120 字符规则截断）→ 再蒸馏。

40 个合成会话（5 场景 × 8 marker 变体——温度 0 下同文重复 ≈ 同一测量，变体化是独立性的前提），每会话 4 条带唯一 marker 的约束嵌在对话里。走真代码路径：STR.prompts.summary 原文、parseSummaryJson 真解析、saveWithDedupe 真写入（quality filter 开）、dream 决策真校验真应用、120 字符截断逐字复刻。

阶段	约束保真（faithful）
S1 蒸馏	83.1%
S2 dream 巩固	66.0%（−17.1pp）
R1 再蒸馏	46.2%
R2 再蒸馏	35.6%

四个读数：

1. 悬崖曲线：两轮再蒸馏后约束只剩三分之一，全程无任何报错——论文的形状在我们管线里成立，且比论文更快（我们的再蒸馏等价于「拿摘要当新输入压缩」）。
2. JSON 崩溃 = 机器形态的静默失守（本轮最重要的发现）：10-20% 的蒸馏窗口，模型其实输出了含约束的完整 JSON 数组，只因中段一处语法错误（如杂散引号）被真解析器整窗拒收。生产行为 = 游标不推进 + 温度 0 重试同文同错 = 该窗口记忆静默丢失，无任何用户可见信号。再蒸馏让崩溃率翻倍（10%→20%）。这是生产缺口，不是评测伪影。
3. 单级蒸馏其实及格：剔除崩溃后 S1 保真 92.4%（>90% 线）——悬崖主要不在蒸馏 prompt，而在 (a) 巩固 −17.1pp、(b) 摘要再当输入的循环、(c) JSON 崩溃。巩固的护栏也是漏的：ARCHIVE_GUARDED_TYPES 只挡 archive 不挡 merge——被丢的约束里 16/26 在 S1 被误归类型、10/26 归位了也被 merge 吃掉。
4. prompt 加「类型感知保真」指令净效应为负：类型归位 37.6%→83.7%（指令确实拧动了类型旋钮）、崩溃外保真 +3.7pp，但 JSON 崩溃 10%→17.5% 把收益吃光。论文的 Knowledge Triage 主张靠 prompt 实现不了——保真必须做在管线层。

产品建议

• scope 线：① strictScope 是唯一有效杠杆，保持 explicit-only + fail-closed 语义；② 软档（A2 ×0.5）要么扩到注入通道，要么文档如实标注「仅检索」。
• 蒸馏线：① summarize 解析失败要有修复路径（截取合法子集重试 / 结构化解码），静默卡死是最坏形态；② 巩固动作对 constraint/preference 应 merge-resistant（现在只有 archive 有护栏）；③ 先归位类型再巩固——误归类型是巩固损耗的大头，这部分可白捡。

数据与复现

全部数据、harness、分析脚本与已执行的报告 notebook 在 persistbench-sycophancy；完整口径与局限（单模型、温度 0、合成池、宿主路由未覆盖、Y 同 importance 档是有利的放大设计）见仓库 RESULTS.md 的 E7/E8 节。下一步想把这两条各落成一个产品化计划（软档处置；解析修复 + 巩固 merge-resistant），欢迎拍砖。