项目复盘

1. 做成了什么，没做成什么

做成了

• 一条从任务定义、造数据、训练、评测到网页应用的完整流程，每一步都实际运行过，每个数字都能追溯到脚本和原始输出。
• 一个能用的模型：FeedLens-MiniMind v0.1.0，在 MiniMind 官方权重上全参数微调得到。输出格式合规率 100%，CPU 上单条请求约 130 毫秒，不需要 GPU。
• 一个可以真实输入、真实推理的网页应用，以及没有权重时如实标注的演示模式。

没做成

• 模型没有超过关键词规则。 在三标签全对率上，微调后的模型与一份约 90 行的规则在所有测试集上都分不出高下（同分布 66.8% 对 71.9%，分布外 58.1% 对 58.1%）。模型明确更好的只有情感判断，以及同分布数据上的摘要。
• 预先写下的五条验收标准，达成两条（格式合规、延迟），三条没有达成（同分布准确率、超过规则基线、摘要质量）。
• 第二轮数据迭代没有带来独立测试集上的改进。 照着失败案例扩充语法后，开发集从 54.0% 升到 90.5%，独立测试集从 58.1% 到 53.0%。
• 没有真实数据，没有做用户研究。

所以这个项目目前能说明的是：我能把一个小模型微调项目从头到尾做完，并且有办法知道它到底行不行。它不能说明这个模型在真实场景里有用。

我认为最有价值的三个发现

1. 基线和独立测试集比模型本身更重要。 如果没有写那 90 行规则，我会把“微调后 67%，训练前 0%”当成一个不错的结果。如果没有那份手写的分布外集和按核心表达分组的划分，我看到的会是一个高得多、也假得多的数字。
2. 验证损失不能用来选检查点。 两次训练里，验证损失最低的检查点都不是生成准确率最高的，其中一次选中的甚至是不到一轮的权重。
3. 模型和规则犯的错不一样。 两者判断一致时准确率在 86%–99%，覆盖一半左右的样本。相比“用模型替代规则”，“把模型当作规则的第二意见”可能是这个小模型更现实的用法——这还需要真实数据验证。

2. 关键决策回顾

3. 过程中犯的错和发现方式

这些都是实际发生过的，按发现顺序记录。

4. 实际执行过的验证

下面每一项都真的运行过，括号里是依据。

数据

• 数据流水线完整运行，产出 5 份数据文件和构建报告（data/reports/data_report.md）
• 分组不泄漏、保留领域不进训练集：流水线里的硬断言通过；测试 test_lexicon_and_group_split 通过
• 训练集与各评测集的字符相似度实测，没有一条超过 0.6（v1）
• 改动生成器以支持 v2 之后，重新构建 v1，全部文件的 SHA256 与改动前一致

训练

• 上游兼容性：官方权重 strict=True 加载成功，参数量 63.91M，校验和与发布页一致
• 冒烟训练：损失下降、参数更新、权重保存（runs/smoke/）
• 四次正式训练（ft-full-v1、ft-lora-v1、scratch-v1、ft-full-v2）均跑完，params_updated 为真（runs/*/summary.json）
• 保存的权重重新加载后验证损失与保存时一致，并能推理：测试 test_train_updates_params_and_reload_matches 通过
• 中断后续训与一次跑完的权重逐位相同（CPU、小模型）：测试 test_resume_is_bit_identical 通过
• LoRA 只改适配器、不动主干，适配器可单独保存和加载：测试 test_lora_adapter_roundtrip 通过

评测

• 九个系统在同一批样本上评测，逐条预测、指标、失败案例保存在 eval/results/
• 系统之间的差距用按核心表达聚类的配对自助法检验（eval/analysis/paired_comparison.md）
• 发现指标存在二次舍入后，根据已保存的逐条预测重算了全部汇总指标（--rescore），重算时断言逐条得分与原记录一致
• 指标实现用手算的例子核对：tests/test_metrics.py 5 项通过

应用

• 没有权重时：服务正常启动，页面显示演示模式横幅和“演示数据”戳记，任意输入被拒绝并说明原因（浏览器中实际操作验证）
• 有权重时：输入 → 后端 → 模型 → 结果卡的完整链路，返回真实模型输出和耗时（浏览器中实际操作验证）
• 批量分诊 10 条、排序、汇总正常
• 输入校验：空、过短、超长、批量超限都返回 422 和中文说明（scripts/smoke_api.sh 全部通过）
• 模型输出格式不合规时的展示、后端连不上时的提示（在浏览器里模拟接口返回验证）
• 窄屏 375 像素下没有横向溢出，导航可横向滚动

5. 没有做的事

没有执行，只有方案或命令

做了但有明显不足

• 分布外测试集只有 117 条，且与语法出自同一作者。
• 标注是单人完成的，没有一致性检验。
• 摘要只用 ROUGE-L 评，没有人工评分。
• 应用没有自动化的端到端测试，界面验证是手工做的。
• 没有处理并发请求，推理是串行的。

6. 如果继续做，下一步的顺序

完整的计划和每一项的依据见 评测报告 第 11 节。顺序是：

1. 先拿真实数据。 哪怕只有 100 条。在此之前，任何进一步的调参或补数据都是在对着合成数据优化。
2. 修评测和选模的方法：按生成准确率选检查点；每个配置跑多个种子。这两项不需要新数据，立刻能做。
3. 换一种造数据的方式：用大模型改写来扩充说法；测试集由别人或别的模型来写。
4. 重新设计摘要：改为抽取，或者只在有把握时输出。
5. 验证“模型与规则一致则采信”的组合策略。

不打算做的：继续按失败案例手工扩充语法。第二轮已经说明这条路走不通。

7. 需要补充的资源

本页由 docs/10-retrospective.md 生成。