实验分享：构建成本的三份读数——零 LLM 写入细节保真 100%、域门控零成本清泄露、记账可信

[modusensus]

#339 的两场体检之后，实验线转向成本-质量轴：同一个问题换了个问法——「不调模型，到底损失什么？」。这轮三份读数拼在一起：一份旧账（#239 的记账发现）、一份新考卷（E10 EdgeMem）、一份天花板实测（E9 域门控）。全部 Kaggle 免费 T4 + 本地模型，零 API 额度，数据在 persistbench-sycophancy（v6）。

先还旧账：任何「降本」结论的前提是记账可信

#239 成本级联（#251）立项时先干了件事：验证尺子。7 天窗口 235 条后台 LLM 审计行、183 条 success——但 input/output/total tokens 非零行数是 0。根因在读取层级：宿主 dsh-llm 的流式协议把用量嵌在 chunk.usage 里，插件两处记账从 chunk 顶层取字段 → 恒 undefined → 全落 0（修复 #242 / PR #248）。方法论结论进了后续所有成本类实验的前置检查表：「成本下降」与「根本没记账」不可区分——任何降本宣称之前先跑一遍这个检查。

E10｜EdgeMem 考卷：零 LLM 写入细节保真 100%

EdgeMem（arXiv 2609.05553）的指控：摘要式记忆在不知道未来查询需要什么时，提前丢掉含答案的细节；它用「原始证据原样入库 + 零 LLM 构建/检索」拿到质量-成本双优。我们把这句话变成三臂 QA：30 合成会话 × 4 条桥接事实（带唯一 marker 值，只被后续 QA 问到）= 120 个「未来才问」的细节问题，三臂同题，maxItems=5 注入：

臂	构建调用	库内存活	QA full
Z0 原样写入	0	100%	100%
Z1 蒸馏（真代码路径）	30	85.8%	75.8%
Z2 蒸馏+叙述条	60	85.8%	85.8%

• 预注册判据触发：Z0−Z1 = +21.7pp（13:0:17，Z0 从未更差）。蒸馏在库层丢 17/120 条桥接事实，端到端差 21.7pp——最便宜的臂细节保真最高，质量-成本双优逐字复现。
• 损耗链解剖：Z1 存活 85.8% → 注入命中 75.8% → QA 75.8%：蒸馏丢弃（−14pp）与注入错过（−10pp）串联；注入命中后几乎必答对——丢细节的责任在写入侧压缩，不在答案环节。
• 叙述条是冗余备份，不是保障：Z2 比 Z1 好 7.9pp（0:6:24）——机制是叙述复述了部分 marker 值，给被丢细节第二次注入机会；但仍比 Z0 差 13.8pp。我们自己的担忧「叙述条丢细节」在端到端口径不成立，原子证据层才是最终保障。
• 诚实限制：Z0 是理想化映射（逐条事实入库而非原始轮次；桥接事实按可条目化设计，利好 Z0）；QA 只测细节保真，蒸馏的归纳增益（去重/泛化/压缩）在别的口径上，本考卷无权宣称蒸馏无价值。

E9｜域门控：零成本把跨域泄露清零

PersistBench 上 zh embedder 打英文文本余弦虚高、纯阈值无可用工作点之后，测了「域条件化取用」的天花板：余弦阈值 ∧ oracle 域匹配（数据自带池级标签）。n=200 跨域 + 100 有益，topK=10：

余弦阈值	纯余弦泄露	+ oracle 域门控
0.5	100%	0%
0.7	97.5%	0%
0.75	76.5%	0%

oracle 域匹配把泄露清零且零代价（有益利用率不掉）；纯余弦要 0.8 档才把泄露压到 28%，此时有益只剩 11%。oracle 不是方案（真实检测器有误差），但 ceiling 这么高，值得为真实机制立项。

合并读数：「不调模型」有三个层次，都便宜得超出预期

1. 写入侧（E10）：对「未来会问的具体值」，原样写入零调用且细节保真 100%，蒸馏反而丢 14%；
2. 检索侧（E9）：域门控（零成本信号）在 oracle 口径严格支配阈值调参；
3. 调度侧（[Feature] 巩固/总结的高峰感知调度：成本感知级联 + 有界检查点 + 错峰队列 #239）：蒸馏链路本就有 5 道零 LLM 早退（无路由/无新事件/无可蒸馏文本/最小间隔/同会话 inFlight），补上可观测性后「能不调就不调」的第一步已经在了。

当然要反过来读：这三份读数不构成「蒸馏无价值」——蒸馏的归纳/泛化收益在 QA 之外的口径，E5 也只裁决了「heat 不该进注入排序」。它们构成的是另一句话：在细节保真与泄露这两个可测口径上，构建期 LLM 调用目前没有展示出不可替代性——每一处用模型的地方，都欠一张「关掉会怎样」的对照表。

数据与复现

数据、harness、分析脚本与已执行的报告 notebook 在 persistbench-sycophancy（v6）；完整口径与局限见仓库 RESULTS.md 的 E9/E10 节。E10 的执行坑（cell 拷贝清单漏文件秒崩、ollama 500 中途崩）已记录，harness 加了 5xx 重试退避。下一步想把「关掉会怎样」的对照表做成产品机制（autoSummarize 与原样写入并存、域门控真实检测器），欢迎拍砖。

[modusensus]

跟帖：原样写入与蒸馏并存的产品化决策（E10 读数的后续，按队列计划书走了一遍设计取舍）

E10 的结论要变成产品机制，卡在一个事实上：Z0 依赖一个 dsh-mneme 没有的东西——事实层来源。store 里只有蒸馏产物，原始轮次在宿主会话历史里，插件不持有。三个可选机制过了一遍：

选项	机制	判定
A 宿主事件镜像	宿主把会话事件喂给插件作原样层（新 surface）	最贴近 E10 的 Z0，但跨仓库协作 + 宿主版本门槛，成本最大
B 蒸馏同时逐条落事实	蒸馏 prompt 要求「逐条拷贝事实」	E8 arm B 已证 prompt 保真指令净负（JSON 崩溃率 10%→17.5% 吃掉语义收益），此路不通
C 叙述条冗余备份	现状即有	零成本，已拿回 7.9pp，但只挽回部分

决策：短期不动写入侧。 触发条件：真实负载出现可归因的「蒸馏丢细节」案例（召回失败但原始轮次里有答案）时，立项选项 A 的跨仓库设计讨论。先行动作是把 E10 式 QA 抽查做成观测面，让「丢了多少」可被看见——这是选项 A 的前置。

完整取舍与队列里另外四份计划书（heat 注入侧产品化 PR #362 已开、E11 域门控真实检测器、E12 注入前判定、MemGauge 引入）见 mneme-research 的 notes/queue-plans-2026-10.md。