数据闭环怎么接上
一个 AI 功能上线之后，它的质量就不再由发布那一次决定了——而是由"上线之后有没有东西在持续喂它"决定。没有闭环的系统，第 100 天和第 1 天一样笨。
而大多数团队的实际情况是：日志在采，看板在做，但中间少了一环——没人知道采集来的信号该变成什么。于是线上一堆点踩数据躺在表里，下一个版本还是靠拍脑袋改提示词。
1. 采集：先想清楚哪些信号有用
不是所有用户行为都值得记。按信息量排：
强信号（直接表明结果不好）：点踩、转人工、投诉、明确表示"你答错了"。这些数量少但确定性高，是最该优先接入的。
弱信号（间接推断）：立刻重问同一个问题、把问题改写后重问、生成中途点停止、答复停留时间极短就离开、复制了答复（这个其实偏正面）。这些量大但噪声高，适合用来找"哪些问题类型体验差"，不适合逐条当失败案例。
隐式信号（需要对比才能看）：拒答率、引用覆盖率、检索空结果率、单轮平均步骤数。这些不来自用户动作，来自系统自身指标，但往往最早暴露问题。
采集时有一条硬要求：每一条信号都要能关联回那次请求的 trace。只有点踩没有 trace，你只知道"这条不好"，不知道是检索没找到还是生成写错了——后面所有环节都做不了。埋点怎么设计见《给大模型链路装仪表》。
隐私侧也有两个约束：留存期要设，不能永久存；正文默认不落全量，需要时按采样保存并脱敏。用户数据被用来改进系统这件事本身，通常在隐私政策里是要写明的。
2. 归因：这一步决定了数据有没有用
闭环里最常被跳过的是归因，而它恰恰是唯一把"数据"变成"结论"的一步。
一次不好的答复，可能的环节只有几类，判据都是可从 trace 里读出来的：
召回漏 召回集合里根本没有正确答案所在的切片
切片切断 相关切片召回了，但答案跨在切片的边界上
排序错 正确答案在召回集合里，但排得太靠后被截断
生成错 上下文里有正确答案，模型没用或者用错了
理解错 用户意图和系统理解的不一样（问题本身有歧义）
拒答不当 该答的拒了，或者不该答的硬答了
前三类是检索问题，第四类是模型或提示词问题，第五类是产品设计问题，第六类是阈值问题。它们的修法完全不同。
归因可以自动化一部分：召回集合里有没有正确答案、正确答案排第几，这些能用代码判。剩下的（生成错还是理解错）需要人工或模型辅助，通常靠抽样。
有一条经验值得记住：归因错误比不归因更糟。把所有失败都记成"模型不行"，然后拼命调提示词，实际问题是切片切断——这时候调提示词不但没用，还会让团队得出"调提示词没用"的错误结论。
3. 转化：三种产出，别只做一种
归因之后，一条失败样本可以变成三种资产，而多数团队只做了第一种：
评测集用例。 把这条问题连同期望答案加进回归集，让它以后不再退步。这是最直接的产出，做法见《评测集怎么变成门禁》。
知识库补丁。 如果问题是召回漏或文档过期，真正的修法是补文档、改切片、调同步——而不是加评测用例。用例只能防止退步，不能补上缺失的知识。
提示词或模型样本。 如果问题是生成错或理解错，这条样本可以进提示词的 few-shot 示例，或者积累成微调数据。
三者的优先级通常是知识补丁 > 提示词样本 > 评测用例：先补上缺的知识，再改表述方式，最后才是锁住不退步。反过来做（先加一堆用例）会得到一条漂亮的通过率曲线和一个仍然答不对的系统。
4. 验证：改完要证明变好了
改了之后要能回答两件事：这批用例过了吗，以及线上真的变好了吗。
前者是离线门禁，跑同一批评测集，比对基线。注意要按类别分开看——总分会把单个类别的崩塌平均掉，这一点在《RAG 评测指标怎么选》里反复强调过。
后者是小流量对照：改完不要直接全量，按《灰度与 A/B 怎么分》走一遍。特别是"补了一批文档"这类改动，离线指标会明显变好，但线上可能因为引入了新的干扰项而持平——只有线上数据能告诉你这个。
5. 三个人工侧的入口
闭环不能全自动，有三处必须留人工接口：
人工修正知识。 客服或运营发现答案错了，应当能直接提交正确的说法，走审核后进入知识库。这一条链路的体验直接决定闭环跑不跑得动——如果提交一次要走三天审批，大家就不会提交（具体设计见《反馈回流与人工转接》）。
人工标注归因。 抽样一批失败案例，人工标上属于哪一类。这批标注有两个用途：训练自动归因的规则，以及校准你用来做判断的模型裁判。
人工审核补丁。 知识补丁和提示词改动都要有人看一眼。自动把线上反馈写进知识库是很危险的——用户不满意不代表用户是对的。
6. 三个失败模式
只采不用。 最常见。看板上有十几个指标，每周开会看一遍，然后什么都没变。判据很简单：上一次因为线上数据改了东西，是什么时候？ 说不上来，闭环就是断的。
数据集腐烂。 评测集是资产，也会烂。三种典型腐坏方式：用例泄漏进了训练数据或提示词、用例分布和真实流量脱节、每次出 bug 就加一条于是渐渐只测去年的 bug。数据集要定期清理和重采样，这一点《Agent 怎么评测》里也提过。
闭环太慢。 从发现问题到修复上线要两个月，用户早就流失了，而且你无法验证这次修复到底有没有用（因为流量分布已经变了）。闭环的速度应当按天或周计，不是按季度。慢闭环等于没有闭环。
7. 别把微调当第一选择
线上攒了一批高质量样本之后，很自然的想法是拿去微调。多数情况下这不是最优顺序：
微调解决的是"格式与风格"，不是"知识"。 模型不知道你们最新的退货政策，给它喂一百条相关问答，它仍然可能在下次问到边界情况时编一个。知识缺失要靠检索补，不靠微调——这一点《微调解决什么》讲得更细。
微调会让迭代变慢。 每改一次要重新训练、重新评测、重新部署，而改提示词或补文档是分钟级的。在问题分布还在快速变化的阶段（也就是刚上线那几个月），慢迭代是致命的。
微调会固化一批数据。 今天的高质量样本，半年后可能已经不符合新政策。微调进去的知识很难单独摘出来。
合理的顺序是：先补知识、再调提示词、再上缓存与路由优化，最后才考虑微调。微调是当格式稳定性和成本都成了瓶颈时的选项，不是质量问题的首选解。
8. 一个最小可跑的版本
不用一上来就建平台。四件事做完，闭环就转起来了：
- 在答复上放一个"有没有帮到你"，把结果连 trace ID 一起存下来
- 每周抽 20 条负反馈，人工标上属于哪一类
- 按类别分头修：补文档的补文档、改提示词的改提示词，同时把这些问题加进评测集
- 下次发布时跑一遍评测集，看这批用例有没有过
一周半天的工作量。它的价值不在于规模，在于让"下一个版本改什么"这个问题有据可依——而不是靠谁在会上声音大。