用户点赞点踩怎么用起来，形成数据飞轮？
谁在问：三面 / 业务负责人；产品与工程交界处的题
口语化问法
- 我们产品里有点赞点踩按钮，这些数据你们怎么用？
- 怎么让线上数据反哺回来，让系统越用越好？
- 用户反馈能直接拿去训模型吗？
考察意图
这题常出现在三面或业务负责人手里，因为它横跨产品与工程。面试官在判断：
- 你知不知道显式反馈是个稀疏且重度有偏的信号。 把点踩率当质量指标是最常见的错误。
- 你有没有把反馈接到评测集上。 反馈只用来看曲线、不进评测集，飞轮就是假的。
- 你懂不懂指标反噬。 一旦点踩率变成 OKR，这个信号本身就会被破坏。
参考答案
60 分答案（及格线）
点赞点踩我们会落库，统计点踩率作为质量指标看趋势。点踩的样本会定期人工看一下，找出常见问题，然后针对性地改 prompt 或者补知识库。如果积累得多，也可以用来做微调数据或者放进 few-shot 示例里。
方向没错：落库、看趋势、人工看、反哺。所以能过。
它的问题是三个：把点踩率当质量指标（稀疏且有偏）、「定期人工看一下」不是流程（没有归类、没有沉淀）、以及跳到微调太快（大部分情况下这不是最优解，而且直接拿用户反馈当训练数据风险很大）。
90 分答案（有生产经验的回答）
我把它拆成四步，核心观点是：显式反馈的正确定位是采样器，不是标注，更不是指标。
一、先接对数据。 反馈事件必须带 trace_id 和 conversation_id 落库，否则你只知道「有人不满意」，不知道他不满意什么——这是产品和工程之间最常见的接口漏配。除此之外要记：反馈发生在第几轮、当时的渠道、以及可选的自由文本原因（哪怕填写率只有个位数，这些文字是失败分类的最好素材）。
二、认清它的统计性质。
- 反馈率通常只有个位数百分比，而且重度偏向不满的用户——满意的人不会点赞，愤怒的人一定会点踩。所以点踩率的绝对值没有意义，只能看同口径下的趋势。
- 点赞几乎没有信息量，点踩才有。 更值钱的是隐式负反馈：立刻重问、改写问题再问一次、会话中途放弃、转人工、复制了但没使用。这些不需要用户动手，覆盖率高一个数量级，而且更难被刷。
- 所以我们的口径是：显式反馈当采样器（决定看哪些样本），隐式信号当趋势指标（决定有没有变差）。
三、飞轮的核心是错误分析，不是「看一下」。
点踩 + 隐式负反馈 + 低判分 → 候选失败池 │ ├─ 开放编码：每条失败写一句话，描述它错在哪（不预设类别） ├─ 轴心编码：把这些句子归并成 5–10 个失败类别 ├─ 每个类别挑最小可复现输入，补 1 条评测用例（不是整条 trace） └─ 用例进门禁集 → 门禁变严 → 同类问题不再复发判断什么时候看够了：一般先看 100 条，约 20 条不再出现新类别就可以停（理论饱和）。 两条可背判据：① 每一次线上事故都必须以「评测集新增一条用例」结束；② 评测集不是只增不减，把所有版本都 100% 通过的用例降级到冒烟集，它们已经没有区分度。
四、反哺路径要按代价从低到高走，微调排最后。
顺序 手段 代价 1 补进评测集（先有度量） 极低 2 补知识库 / 修检索（如果是「不知道」类） 低 3 改 prompt / 加约束 / 加校验重试 低 4 补 few-shot 示例（注意占上下文、且有污染风险） 中 5 微调 高，且基座一升级就贬值 绝对不能做的是把原始用户反馈直接当训练数据。 三个原因：点踩的原因很可能不是模型的错（用户问的本来就超出范围、或者他想要的是政策上不能给的东西）；反馈样本重度有偏，直接训会把模型往「讨好抱怨者」的方向拉；还有数据合规问题——用户输入里常有 PII。反馈必须先经过人工归类和改写，才能进任何训练或示例集合。
追问链
点踩率能当质量指标吗？
期望不能当绝对指标，只能看同口径趋势 —— 反馈率低、样本重度偏向不满者，而且反馈率本身随 UI 改动而变：按钮挪个位置点踩率就降，质量没变。更稳的做法是隐式信号做趋势（重问率、转人工率、放弃率），点踩只用来挑样本。一定要报一个数，就报「点踩样本中经人工确认确实是系统问题的比例」信号「点踩率是我们的核心质量指标」 → 典型错误；主动提「UI 一改点踩率就变，跨期不可比」 → 做过产品数据的人才会注意到我们产品反馈量很少，一天就十几条，飞轮转不起来怎么办？
期望常态，不是异常：解法不是提高反馈率，是换信号源 —— 隐式负反馈（重问、改写、放弃、转人工）大一到两个数量级 → 系统侧硬信号（解析失败、报错、截断、拒答、无命中）不依赖用户 → 采样 judge 的低分样本。飞轮的输入不是「用户反馈」，是「疑似失败样本」信号说「引导用户多点反馈」 → 治标，而且会引入新的偏差；能区分「找失败模式需要的量」和「统计趋势需要的量」 → 强信号从一条点踩到一条评测用例，中间具体怎么做？
期望提炼最小可复现输入，别塞整条 trace —— 那样又慢又脆。三件事：① 脱敏改写，去 PII 保留触发失败的结构；② 冻结外部依赖，检索结果与工具返回存成 fixture，否则明天就不复现；③ 写清判据，不能只写「应该答对」。再去重、打类别标签信号说「把 bad case 加进评测集」 → 没有落地细节；提到「冻结外部依赖」 → 维护过评测集的人才会说，这是最容易让用例失效的坑这套飞轮怎么衡量它自己有没有效果？
期望「评测集变大了」是产出不是成效。要看四个数：同类失败的复发率（补了用例的那类还出现吗）、失败类别的新增速度（一直冒新类别说明覆盖还浅）、从线上发现到补进评测集的周期（飞轮转速）、门禁集拦下的真实问题数。再定期跑从不参与迭代的保留集，回答「这半年是真变好，还是只把门禁集刷穿了」信号只说「评测集从 100 条涨到 800 条」 → 把产出当成效；能说出「门禁拦下过几次真实问题」 → 向老板汇报时最有力的口径业务负责人要求把「点踩率下降 30%」写进季度 OKR，你怎么回应？
期望先认可诉求，再给两条理由：① 不可比 —— 反馈率随 UI、流量结构、渠道变化，按钮做得不显眼点踩率立刻降 30%，零成本作弊路径最致命；② 重度有偏且稀疏，个位数反馈率下 30% 多半是噪声。三层替代：主目标换业务终审指标（工单解决率）→ 辅助目标用离线固定评测集合格率 → 点踩降级为运营信号，不入 OKR信号直接答应 → 一个季度后这个数会好看，质量不会；直接拒绝且不给替代 → 会被当成不配合，方法论也推不下去
评分要点
- 明确显式反馈的定位是采样器，不是标注、不是指标
- 反馈事件必须带 trace_id / conversation_id，否则无法定位
- 知道点赞几乎无信息量，隐式负反馈覆盖率高一个数量级
- 飞轮的核心是错误分析（开放编码 → 轴心编码 → 补用例），并知道理论饱和的停止条件
- 补用例要最小可复现输入 + 冻结外部依赖 + 写清判据 + 去重
- 反哺路径按代价排序，微调排最后
- 明确不能把原始用户反馈直接当训练数据，并说得出三个理由
- 飞轮成效看复发率、新类别速度、门禁拦截数，不是评测集条数