归因顺序决定修复成本：从最便宜的那层往下查。
反馈不是"收集起来看看"
上线后用户会点踩、会改写、会放弃。这些信号极其宝贵（它们标出了系统的真实短板），
但如果只堆在日志里，等于没有。要做成闭环：收集 → 分类 → 归因 → 修复 → 回归。
一、收集：把反馈接到具体请求
· 每条反馈必须带上请求 id（否则无法定位当时的输入、模型版本、检索结果）；
· 记录反馈类型：点踩 / 改写 / 放弃 / 转人工；
· 记录上下文（用了哪个入口、第几轮、是否走了降级）；
· 给用户一个可选的文字说明入口（哪怕一句话，价值很高）。
二、分类：把反馈变成失败类型
原始反馈是杂乱的，要归到有限几类（数量控制在 8~12 类）例如：
· 事实错误 / 编造；
· 漏答（该说的没说）；
· 格式不符（要 JSON 给了散文）；
· 理解偏差（答非所问）；
· 延迟不可接受；
· 语气/长度不合预期。
分类要人工先标 100~200 条，形成标准后能量化的再自动化。
三、归因：别停在"答错了"
每一类继续往下问：
· 输入是否清楚？（需求本身模糊 → 加澄清机制）
· 检索是否给对了片段？（片段不足导致的错不该记在生成头上）
· 提示词是否约束不足？（格式类问题多半在此）
· 模型能力不足？（换模型是最后手段）
归因顺序决定了修复成本 —— 从最便宜的那层往下查。
四、修复与回归
· 每次修复都要转成一条评测样本（否则同类问题会再犯）；
· 修复后跑评测集（见"评测集接进流水线"那篇），确认没有引入新问题；
· 记录"修复前/后"的失败率变化，用数据说明有效。
五、定期看两件事
1. 失败类型的分布变化（不是总量）—— 总量下降但"编造"占比上升，说明质量在恶化；
2. 沉默的失败：用户没点踩但直接离开了 —— 这类信号要靠行为埋点（重试、二次提问、放弃）捕获。
一个最小闭环（一周可跑起来）
1. 反馈接请求 id（半天）；
2. 人工标 150 条，归纳 8 类（一天）；
3. 每周挑占比最高的 2 类做归因与修复；
4. 每条修复进评测集；
5. 周会上只过一张图：失败类型分布 + 本周修复项。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：长文摘要流水线：切分、归并、校验、成稿
下一篇：AI 功能的容量规划：怎么估并发与峰值 →
第 39 / 171 篇