PII项目交接：先冻结基线，再继续优化

6月22日的核心工作，不是继续调参，而是把PII检测项目从“已经有高分结果”整理成“后续可以安全继续优化的工程状态”。这类任务很容易被单次线上分数牵着走，但如果基线、冻结产物、评估口径和验证集边界没有先固定，后续每一次提升都可能变成不可复现的偶然结果。

问题与目标

PII检测是字符级span任务。模型输出不仅要找到敏感信息的位置，还要满足统一的start、end和label语义。最终评估也不是只看单一分数，而是同时关注PCR、weighted coverage、critical coverage和fp_char_rate。

这意味着，一个模型线上分数更高，并不自动等于它适合作为继续实验的基线。如果它缺少复现说明、验证集隔离、提交审计或冻结记录，后续优化就会失去比较基础。

今天的目标是先把项目状态梳理清楚：

• 当前protected best是谁。
• 历史强基线还保留什么价值。
• 哪些目录只读保存，不能继续改动。
• 哪些复现入口可以作为后续实验起点。
• old、fresh和final验证集合分别承担什么角色。

这些事情看起来不像模型优化，但它们决定了后面的优化是否可信。

基线冻结

交接时最重要的原则是：已经成为protected best的结果必须冻结，不再被后续实验覆盖。继续训练、后处理或ensemble时，只能从明确的复现副本或新实验目录开始。

这样处理有两个好处。第一，线上结果和对应产物可以长期追溯；第二，后续任何候选模型都能和固定基线做公平比较，而不是在不断变化的工作目录里比较“看起来类似”的结果。

项目中保留了多个阶段的强基线，包括早期强模型、后续扩展训练版本，以及新的protected best。公开博客不展开内部目录细节，也不列出提交包hash、样本编号或预测明细，只记录阶段性结论和评估口径。对PII项目来说，实验记录本身也属于风险面，不能为了说明效果而复制敏感数据细节。

验证集边界

今天另一个重点，是把不同验证集合的用途分开。

old验证集适合做历史对比。它能帮助判断新候选相对旧模型是否有可比提升，但不能长期作为唯一选择依据。

fresh lockbox用于检查泛化。它需要尽量避开前面训练和调参已经接触过的样本，避免模型只是在旧验证集合上“看起来变好”。

final lockbox更接近最终仲裁工具，不适合频繁使用。如果把最终验证集合也拿来反复调参，短期指标可能提高，但模型对真实线上分布的可靠性会下降。

因此后续每一次实验都应该说清楚：这次用了哪一类验证集合、它适合回答什么问题、它不能证明什么。验证边界不清楚时，分数越多，反而越容易制造误判。

决策原因

今天没有急着修改模型，是因为PII项目的风险不只来自模型漏检，也来自工程记录、调试材料和提交流程中无意暴露信息。先冻结基线、整理复现入口和明确验证边界，是后续安全优化的前提。

后续实验应遵守三条原则：

1. 不修改已经冻结的结果目录。
2. 不混用训练、验证和最终仲裁集合。
3. 不在公开记录中保留真实样本、字段值、样本编号或可反推数据内容。

只有这些规则先站稳，后面的训练、后处理和ensemble才有可信的比较基础。

下一步计划

交接完成后，后续优化可以从两条线推进。

第一条是模型线：围绕现有强基线继续训练，尝试降低误报、补强关键覆盖或做更稳的样本级组合。

第二条是工程线：保留每次实验的摘要、验证指标、上传决策和风险边界，但公开记录只写方案层面的经验，不写数据层面的细节。

对PII项目来说，好的实验复盘不应该是聊天流水账，也不应该是产物清单。它应该回答三个问题：为什么做这次实验、怎么判断它是否有效、它给下一步留下了什么边界。