中文分词算法_怎样记录变更与复盘：从交付结果倒推验收资料
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /553ab7fec874.html
📄
中文分词算法_怎样记录变更与复盘：从交付结果倒推验收资料
记录中文分词算法的变更与复盘，核心是让每一次改动都能对应到可验证的交付结果：改前留下基线样本与版本号，改中记录词典、模型、参数和代码的差异，改后按同一批测试句对比切分结果，并把不一致的原因归类到词典、规则、模型或数据四类中的某一类。没有基线和对比样本的“感觉变好了”不能作为验收依据。
先确定交付结果，再倒推要留什么资料
分词算法的交付结果通常表现为三类可观察输出：对固定测试集的切分序列、对业务语料的准确率或人工抽检通过率、以及下游任务（检索、标注、意图识别）的指标变化。先写下这次变更期望改善哪一类结果，再决定记录范围。
- 若目标是修正特定领域词被切碎，交付物应是“问题句清单+改后切分结果+未回归的对照句”。
- 若目标是整体指标提升，交付物应是“同一测试集上的前后对比表+差异样本抽样”。
- 若只是升级依赖或重构代码，交付物应是“输出完全一致的校验结果”，而不是指标变化。
适用条件：测试集必须固定且可追溯，否则前后对比没有意义。判断结果时，如果差异样本集中在某一类词（如人名、机构名、新词），说明问题定位到该类资源；如果差异随机分散，优先怀疑版本或环境不一致。
变更记录要写到可复现的程度
一份能支撑复盘的分词变更记录，至少包含以下字段，缺一项就可能在复盘时无法定位原因。
- 版本标识：代码提交号、模型文件哈希、词典文件哈希，三者分开记，不要只写“更新了词典”。
- 变更类型：词典增删、规则调整、模型替换、参数修改、依赖升级，类型不同，验证方式不同。
- 影响范围：只影响自定义词典生效的分词器，还是影响所有调用方；是否有下游系统依赖旧切分结果。
- 基线数据：变更前的测试集输出文件，保留原始文件而非截图。
- 责任人：谁提交、谁验证、谁批准上线，三者可以是同一人，但要写明。
- 回滚方式：旧版本文件位置和恢复步骤，写清楚才能在没有结论时先止损。
例子（假设）：某项目把“深度学习框架”从词典中删除，改由模型自行切分。记录中应写明删除的词条、删除原因、测试集中包含该词的句子编号，以及改后是否切成了“深度/学习/框架”。如果只写“优化词典”，复盘时无法判断这次改动是否达到预期。
复盘按“现象—证据—原因—结论”四步走
复盘不是重述变更内容，而是回答“这次改动是否解决了原问题、有没有引入新问题”。可以按下面的顺序组织。
- 现象：列出改前改后的具体差异句，不要只给汇总数字。
- 证据：指向测试集文件、输出文件和对比脚本，保证他人能重跑。
- 原因：区分“可能原因”和“已经定位的原因”。例如差异可能来自词典未生效、分词器加载了缓存、测试集本身被修改，只有逐项排除后才能写成已定位。
- 结论：明确保留、回滚还是继续观察，并给出下一次验证的条件。
一项现象往往有多个解释。比如某句切分结果与预期不符，可能是词典未加载、可能是模型优先级高于词典、也可能是该句在预处理阶段被改写过。没有逐项验证前，不要断言唯一原因。
用固定检查项代替主观判断
每次变更后按同一张检查表过一遍，能减少复盘时的争议。检查项可以包括：
- 测试集句子数量与变更前是否一致，文件哈希是否变化。
- 词典文件是否被正确加载，加载日志中词条数量是否与预期相符。
- 同一输入重复运行多次，输出是否稳定。
- 下游任务使用的分词结果是否同步更新，是否存在缓存旧结果。
- 回滚后输出是否与变更前完全一致。
判断标准要提前定。例如规定“测试集中问题句修复率达标且对照句回归不超过约定条数”才算通过；如果只写“效果可以接受”，复盘时无法验收。技术细节上，若用脚本对比输出，可把差异行写入单独文件，例如用 diff baseline.txt current.txt 生成差异清单，再逐条归类。
把责任和验收写进流程
记录与复盘能否落地，取决于是否有人对每个环节负责。提交人负责提供变更说明和基线文件，验证人负责按检查表跑对比并签字确认，批准人负责判断是否上线或回滚。验收不通过时，默认动作是回滚而不是继续叠加改动，避免多个变量混在一起导致无法归因。
如果团队规模小，可以合并角色，但三类信息不能省：改了什么、和什么比、结论是什么。把这三项固定成模板，每次变更填一次，复盘时直接取用，比事后回忆可靠得多。
下一步：挑最近一次分词相关改动，按上面的字段补一份变更记录，并用同一测试集重跑一次对比，看现有资料是否足以支撑归因。
