NM2.1 · 之后做了什么

发布页上的数字来自 v2。这一页讲**之后又做了什么**：三处改动各自凭什么、一个把端到端正确率 锁死在 50% 的写入缺陷怎么定位的、以及一个 75% 泄漏的失败怎么修到 0%——又怎么在接上运行时之后失败两次。 所有数字都来自磁盘上的报告文件，每张表都标了出处；**没有一条是估算或外推**。

净变化一览

出处 · V2_dpskw\NM2_VS_NM2_1.md（该文件自述：所有数字均从磁盘上的评分卡 / JSON 读取，不是手工抄录）

「未知拒答率」与「未知泄漏」是同一件事的两面：前者是问库里没有的属性时**正确说不知道**的比例， 后者是**照样编一个答案**的比例。v2 在这两轴上是 0% 和 75%，也就是几乎必然硬答。

一 · 路由器工件本身的检索与排序

出处 · router_scorecard_final.json（判定见 router_verdict_final.json）· 冻结 v6 评测集 21,920 条 / 10 类别

二 · 拒答与仲裁策略轴

出处 · router_scorecard_final.json（门槛 0.50）+ threshold_sweep_check.json（0.30–0.80 全门槛扫描）

门槛扫描是这里真正的证据。0.30 / 0.40 / 0.50 / 0.60 / 0.70 / 0.80 六个门槛逐一复核： NM2.1 **全门槛通过**；而原版在**每一个**门槛上未知拒答率都是 0.00%，且门槛越高误拒越差 （0.00% → 1.32%）。一个能在整条门槛轴上都成立的结论，和一个只在某个阈值上成立的点，可信度不是一回事。

三 · 端到端整体记忆能力（同一份运行时，只有模型包不同）

出处 · nm2_battery_comparison_final.json · A 110 用例 / B 16 / C 48 / D 重启持久化

运行间波动必须自己讲出来：B 段只有 16 个用例，1 个用例 = 6.25 pp。所以 B 的 68.75% 与另一次测得的 75.00% 属于同一水平的运行间波动，**不作为增益主张**。A / C / D 的结论在多次运行中一致。

四 · 零字面重叠改写的泛化

出处 · replay_check_zov.json（路由器级）与上表 B / C 段（端到端）· 数据集 300 条、24 个未见过的问法

五 · 代价：几乎没有

出处 · router_scorecard_final.json、router_latency_bench_prod.json（7 轮交错取中位数）

交错基准（7 轮，消除顺序效应）：单查询中位数 1.4203 ms → 1.4242 ms，差 +0.28%。 同一轮里原版自身离散度就有 4.85% —— 也就是说这个差值小于测量噪声。 零重叠那一轮里 batch=64 的读数低 9.2%，但该轮离散度是 17.4%，且同架构同参数同 FLOPs 下 batch=256 反而更快， 方向不一致，判为测量噪声而非回归；这条也写在这里，因为把噪声当结论是这个领域最常见的错误。

六 · 工程鲁棒性

七 · 三处改动，每处都有测量依据

改动 1 · 记录排序混合权重取 0.5

memory_record_router_blend 控制「打包的词面重排器」与「学习出的路由器」各占多少。 调这个之前先测了剂量曲线 —— 而且**此前的同进程测量因顺序污染已作废**，下面这版是独立进程测的。

改动 2 · 把加法先验参数化，然后测出「不该动」

假设是「加法先验压过了学习打分」。把它暴露成可调再测，结果**调小只会更差**：

这是一个有价值的负面结论：它否定了原来的假设。项目里这类结论和增益一样被保留下来， 因为它们决定了后面不再往哪个方向投入。

改动 3 · 覆盖门 —— 以及为了让它真正生效必须一起修的两处

覆盖门本身很简单：先判断「这个提问在问哪个属性」，再查库里有没有这个属性。但单独加门是不生效的， 有两处**必须同时修**，否则门会被静默绕过：

八 · 写入路径：为什么 20 条事实会互相销毁

出处 · V2_dpskw\WRITE_PATH_FIX.md（根因由栈追踪确证，非推断）

16 次 retract 的调用栈完全一致：

eval_end_to_end_memory.py:106  write_fact
 -> qwen_integration.py:3807   forward
 -> qwen_integration.py:2195   _write_text_memory      <-- retract 调用点
 -> memory_os_v2.py:2578       MemoryOSV2.retract_record
 -> memory_os_v2.py:1959       PagedMemoryBankV2.retract (status = retracted)

status_transition_summary == {"active->retracted": 16}，无 superseded、无 quarantined， 20 次 bank.write 全部返回 inserted —— 写入路径的唯一销毁机制就是 2195 行的 retract。 授权条件 confirmed_update 在 20 次写入中为真 5 次，且全部只走「学习重排器 learned_best >= 0.95」这一条：

随后 2187–2197 的循环退掉 8 条：3 条走 record.slot_index == slot，5 条走 score >= 0.95 and shared >= 2；2196 行的 break（仅当 score < 0.98 才停） 让写 #12 一次级联退掉 3 条、写 #15 退掉 2 条。被退掉的正是写 1/2/3/4/9/10/11/14 —— 16 条关键事实中的 8 条。

根因：retire 一条已存在记录的授权完全来自学习打分加一个固定 0.95 阈值， 没有任何「新文本与在位记录共享 (entity, attribute)」的结构性校验。

修复（两处，都是结构性的）

语义不受损：真·同属性更新本来就已经由 PagedMemoryBankV2.write 通过 active_by_conflict 做版本化（旧版本保留为 superseded、version+1）， 修复只是移除了那条额外的、无监督的销毁路径。

四级验证

端到端效果（官方 harness，16 个零重叠用例）：

一个诚实的补充：这 16 个用例里 93.75% 的读取仍走旧版 16 槽路径而非 V2 库记录， 地址命中 0 / 16。写入路径的修复解除了 50% 的硬上限，但「V2 库记录真正参与读取」这一项仍未解决。

九 · 未知拒答：从 75% 泄漏到 100% 拒答

出处 · V2_dpskw\ABSTENTION_BREAKTHROUGH.md

这是整个项目最差的一个数字：问库里不存在的属性时，75% 的情况下模型照样编一个答案。 下面按「先排除一整类无效修法 → 再给出有效机制 → 最后如实记录接上运行时的两次失败」来写。

9.1 先排除掉一整类无效修法（有测量支撑）

最直觉的修法是「检索分数不够高就拒答」。用只在训练集拟合、评测集算 AUC 的口径， 测了四种打分器的分数几何（top1 / margin / top-k 均值 / 离散度 / 熵 / 近邻数，共 9 个特征）：

操作点同样不可用：混合打分器想标出 22% 的未知要误拒 28.40% 的可回答问题； cosine 想标出 46% 要误拒 30.00%。 结论：75% 的泄漏不可能靠分数阈值或分数上的分类头修好。 这不是调参空间不够，而是这个信号根本不存在 —— 24 条同句式候选对任何提问都「一样像」。

9.2 有效的机制：先判「问的是哪个属性」，再查库里有没有

换一个问题问就成立了：不是「有没有候选匹配得好」，而是「这个提问在问哪个属性，这个属性在库里吗」。

9.3 接上运行时：连续失败两次（如实记录）

第一轮：门把几乎全部可回答问题都拒掉了（100.00% → 6.25%），而它本该修好的 C 段泄漏只从 75.00% 降到 62.50%。 第二轮定位到真正的机制缺口 —— read() 返回空记录后不会停止，_build_text_prefix 会继续落到旧版 16 槽注入路径把无关记忆又塞回去。加了短路之后，C 段泄漏真的到了 0.00%、可回答正确率无损， 但 A 段崩到 0.00%。

A 段崩掉的原因已测定：段事实里 94.03% 是「这是普通对话噪声…不需要长期保存」， 只有 5.97%（63 / 1056）能解析出属性；更关键的是 A 段的属性空间完全不在属性头训练的 24 个属性之内， 头对 A 的提问只能输出那 24 个之一 → 必然不在库里 → 门把一切都拒掉。 也就是说：这个机制目前是「域内可用、跨域不可用」。

结论：已把 NM2.1 的 memory_coverage_gate 改回 false，恢复为已验证的可用状态。 属性头工件保留在 checkpoints/memory_attribute_head/，未随包启用。 正确的最终形态是开放词表的属性匹配（把提问与库里真实存在的属性名做匹配，词表随写入动态变化）， 而不是 24 类闭集分类头。

十 · 关键负面结论：路由器排序不影响端到端答案

出处 · V2_dpskw\ZERO_OVERLAP_FINDINGS.md §5

NM2.1 的路由器在零重叠集合上 Top-1 提升了 41.20 pp，但在 eval_router_critical_e2e.py（16 个零重叠用例）上，REPLAY-128 与 V2-128-v6 的结果 逐位相同（默认 Top-K：37.50% / 37.50%，答成别的属性 25.00% / 25.00%，平均选中记录 5.88 / 5.88）。

于是做了一个判决性实验：保留 need_memory / hop_controller / head_gate 全部原权重，只把排序通路（query_projection、key_projection、pair_scorer） 替换为同形状随机权重。结果在默认 Top-K 与 Top-K=1 下都完全不变。

结论分两层，不要混为一谈：① 路由器记分卡上 22 / 22 的统治性和 +41.20 pp 的零重叠提升， 都是路由器工件真实的增益；② 但在这套运行时里，记录级顺序由打包的 text_retriever 决定， 路由器分数被覆盖，且相当比例的读取根本不走 V2 库、目标记录还会被写入路径删除。 所以路由器增益不会传递到最终答案。

十一 · 仍未解决（不粉饰）

十二 · 复现

$env:PYTHONPATH='H:\Memory'; $env:PYTHONIOENCODING='utf-8'; cd H:\Memory\V2_dpskw

# 整体电池（A/B/C/D 四段）
pwsh -NoProfile -File .\run_nm2_battery.ps1 -Package qwen3_5_4b_natural_memory_v2_1 `
  -Label 'NM2.1 最终' -Tag 'nm2_1_final' -PerCategory 10 -OverlapCases 48 -Blends '0.5'

# 三代对照表
& 'C:\Users\Administrator\miniconda3\envs\LLM\python.exe' -m V2_dpskw.compare_nm2_batteries `
  --tag "原版NM2=nm2_orig" --tag "NM2.1=nm2_1" --tag "NM2.1最终=nm2_1_final"

# 门的适用性诊断（确认 applicable/bypassed，避免静默旁路）
& 'C:\Users\Administrator\miniconda3\envs\LLM\python.exe' -m V2_dpskw.diagnose_coverage_gate `
  --package qwen3_5_4b_natural_memory_v2_1

台账式的逐条原文在 真实评测台账； v2 的正式脏数据迁移测试在 测量结果。