一条“复制回答”的埋点，通常会被记成采纳。
但用户可能把回答粘进工作文档，也可能发给同事说“你看它又算错了”。复制动作是真的，接受与否还不知道。即使用户准备直接使用，也可能没有能力识别其中的错误。
如果产品把复制率叫作质量分，后面的分析就已经把一个尚待解释的动作，变成了确定的判断。监控会持续收到数字，却越来越难回答用户究竟得到了什么。
讨论用户反馈之前，可以先把几个动作拆开看。以下工作场景都是说明用的假设例子，不是作者的真实使用记录。
复制、点击、采纳：看到了动作，还缺什么
假设 AI 给出一份广告账户诊断，用户复制了其中一段。产品知道的是“这段文本被取走”，不知道它去向哪里，是否被修改，以及有没有进入实际决策。
可以沿业务流程补一些记录：内容是否被插入报告，插入后是否被撤销，是否在提交前被改，最终是否发送。每补一项，判断就多一点依据。但这些后续动作也不等于事实正确，报告被发送，可能只是用户信任了它。
点击引用来源也如此。用户可能在核验答案，也可能只是好奇；点开了第一条来源，可能因为它相关，也可能因为它最显眼。Joachims 等人的搜索研究表明，排序信任和结果质量都会影响点击，因此不能把点击直接当成绝对相关性标签。[1]
研究里“点击优于跳过的上方结果”的偏好提取方式，在特定实验中比“后点击优于先点击”更可靠。应用到 AI 产品时，应先问比较对象是否真的被展示、用户是否有机会注意到，而不是把任何点击都编码成一分。
接受建议后几秒内撤销，比单纯接受提供了更强的可疑线索：用户可能发现不合适。但也可能是工作计划改变、误操作或对比其他方案。需要保留被接受的内容、撤销时间和附近操作，才能让阅读记录的人判断。
这一类属于行为信号（behavioral signals）。它的优势是融入正常流程，不必每次要求用户评价。在 Copilot 式产品里，每条建议通常都对应接受、忽略或继续编辑等行为；不能把这个特点推广成“所有 AI 输出都必然产生可解释的反馈”。
展示没有成功、用户切走、下游动作在另一系统发生，都可能让一条输出没有可用信号。采集覆盖率高，也只是说明很多动作被记录，不代表质量判断覆盖率同样高。产品需要分别计算“拿到了什么行为”和“哪些行为有足够上下文可以解释”。
行为埋点的成本通常比人工逐条标注低，但不是零。事件设计、跨端关联、日志存储、去重和后续解释都有成本。对需要语义判断的行为，自动识别器还会产生模型费用与维护工作。把它叫便宜，应说清是在与哪种采集方式比较。
“再写一版”与“我刚才已经说过了”
用户接着说“再简短一点”，可能是在正常打磨文案。“我刚才说了不要写收益承诺”，则指向 AI 没遵守已有要求。表面上都多了一轮对话，质量含义却不同。
Langfuse Academy 用音乐 DJ 场景区分引导（steering）与纠正（correction）：要求播放更安静的音乐，可能是追加偏好；“我说了要更安静”，提示此前要求没有得到满足。这个区分可以迁移到写作、诊断和客服，但必须读前文。[2]
判断时至少要看三个问题：要求是否已经提出，AI 是否有合理机会满足，新一轮是否新增了信息。有时用户第一次表达不够明确，随后补充细节；有时 AI 已经做错，用户却用很客气的方式纠正。不能仅凭否定词或语气判断。
“换一种写法”也有多个含义。用户可能要更多候选，也可能觉得上一版不适用。重新生成可以先作为待查看信号；若要进入失败率，应先校准它与实际失败的关系，而不是把所有重试都算成坏体验。
对话信号（conversation signals）来自后续语言，能提供行为埋点没有的语义信息。重新表述同一问题、指出具体事实错误、要求人工、确认成功，都可能告诉团队上一轮有没有落地。收集原话之外，还应保存它指向哪一轮输出。
对话轮数和时长尤其容易被误用。长对话可能是任务复杂、探索深入，也可能是反复补救。Eugene Yan 在 LLM 产品工程模式文章中讨论了这类隐式反馈的解释困难。[3] 如果不知道长度为什么变化，单纯追求缩短会话可能伤害正常的探索流程。
语义识别可以交给自动评估器，但需要审阅标准和校准样本。微软的 SPUR 工作从带满意度标签的对话中提取模式，整理成 rubric，再对未标注对话估计满意程度。它的价值在于把“为什么判为满意或不满”拆成可检查的模式，而不只是返回一个分数。[4]
这不意味着自动识别已经能可靠理解所有产品的反馈。任务不同，不满来源就不同。客服里可能是事实不准，写作里可能是语气、长度或对约束的遵守。SPUR 的跨数据集实验中，使用目标领域学习出的 rubric，比直接沿用 Bing Copilot 的 rubric 获得平均约 13% 的加权 F1 增益。[4] 这个结果支持领域校准，不是所有团队的收益承诺。迁移 rubric 时应使用本场景的人工样本检查，保留版本与误判记录。
WildFeedback 研究分析了 148,715 段多轮对话，报告约 12.8% 含反馈信号，其中含不满（DSAT）的对话为 13,582 段，含满意（SAT）的为 5,447 段。标签来自其特定 rubric 和模型识别，不应读成所有用户的真实满意度分布。[5]
研究在 50 段、超过 500 条话语的人工校验中，报告 GPT-4 的 DSAT 精确率为 83.3%，召回率为 48.4%，F1 为 61.2%；与人类判断的 Cohen’s κ 约为 0.50，SAT 约为 0.69。这组结果说明，识别为不满的样本有核查价值，也存在相当多漏检。[5]
“没有被识别为不满”因此不能改名为“用户满意”。也不能用 48.4% 把线上负面率简单乘以固定系数：误报、类别组成、场景变化和检测器版本都会影响观察曲线。应在自己的目标流量上持续抽查精确率、召回率和漏检类型。
识别器的规则变了，历史曲线也可能变。某天负面率上升，是体验恶化，还是模型更会识别了？若没有记录检测器与 rubric 的版本，这两种解释很难分开。必要时用固定样本同时运行新旧识别器，检查差异来自哪里。
沉默：不能随手填上的标签
用户读完回答，没有继续说，也没有点按钮。这是采集中最常见的空白之一，解释却不能自动补齐。
一份简单操作说明可能已经解决问题；一份错误诊断也可能让人放弃继续追问。沉默既可能包含完成，也可能包含退出。产品若只保留“对话结束”，很难区分两者。
可以记录任务完成事件、结束位置、最后动作、合理时间内是否重开或返回。客服产品还可以按会话结果保留“已解决”“转人工”“放弃”“未知”等状态。但这些状态需要定义与校验，“超时无消息”只是可观测条件，不是用户心里发生了什么。
未标注（unlabeled）和中性也应分开。中性是一个有定义的判断，未标注是没有收到判断。把两者混合，团队就会把记录缺失解释成质量正常。统计时可以显式排除未标注，但应同时报告排除比例和适用范围。
反馈缺失经常与体验有关。Yahoo! Music 的研究中，64.85% 的调查用户表示歌曲偏好影响是否评分；喜欢与中性的歌曲，在经常评分比例上存在明显差异。[6] 这是一项音乐推荐研究，不能把数值直接当作 AI 聊天的缺失比例，能借鉴的是对自选择机制保持警惕。
训练与测试如果都只来自自然发声者，评测可能不能代表全部目标流量。另取随机样本并人工审阅，是检查这种偏差的一种办法。随机抽样并不是把数据随便抽几条：要有覆盖目标流量的样本框，保留抽样规则，并说明无法覆盖的部分。
失望后退出的人还可能没有机会留下信号。只看持续活跃用户，会漏掉一部分退出体验。这是幸存者偏差。主动观察流失与放弃，可以补充信息；但“不再返回”仍可能由很多外部原因造成，不应把它归成 AI 质量失败而跳过调查。
监控沉默的实际目标，是让团队知道自己在哪些区域缺少判断，而不是把每一条沉默都强行打上正负标签。未知比例上升也值得检查：可能是新流程没有接回结果，可能是埋点失效，也可能是用户交互习惯变了。
点踩与投诉：方向清楚，原因还要核查
明确点踩比复制更接近用户主动判断，但它只说明用户表达了不满，不自动说明哪个环节失败。事实错误、没遵守要求、语气不合适、延迟过长，都可能得到同一个按钮事件。
显式评分（explicit ratings）包括点赞点踩、星级、会话满意度、原因选择器和偏好二选一。用户知道自己在评价，极性通常比隐式行为清楚。它适合校准其他信号，也适合在高价值触点收集更明确的原因。
不过，反馈仍是自选的。Meta 的 RLUF 论文报告，约 0.1% 的模型消息收到 Love 正向表情反应。[7] 这是该产品特定表情的覆盖率，不是所有反馈的总覆盖率，更不能用来推导 99.9% 的用户没有感受。
低比例不等于“置信度接近零”。流量足够大时，绝对样本量仍可很大，足以训练反应预测模型或比较某种反应率。真正的问题是，它测量的是什么、发声者是否代表目标用户，以及指标是否被界面和任务类型影响。样本量增大会减少部分统计波动，却不会自动消除选择偏差。
给点踩加原因选项，通常能减少事后猜测。选项应对应不同修复动作，例如事实错误、没有回答问题、忽略限制、语气不合适，同时留“其他”和文本入口。不要要求用户替研发诊断成“检索失败”或“工具路由错误”，他通常看不到内部过程。
原因选项也会引入偏差。排在前面的理由更容易被选，预设列表会漏掉团队没想到的问题，用户可能为了完成操作随手选一项。原因属于用户报告，应保留原始值；后续错误分析可以另存经过证据核查的分类，两者不要互相覆盖。
“这个答案没用”值得打开记录，但不必立刻判成模型质量事故。用户可能对业务政策不满，也可能要求系统做超出边界的事情。一个正确拒绝的回答仍可能被点踩。投诉需要认真处理，质量归因需要依据，两项动作应并行而不是互相替代。
正向反馈也有类似边界。点赞可以表示被接受、表达感谢或喜欢语气；它不保证事实正确、安全或长期有用。正向趋势适合观察，个案在校准时仍要读。不能要求用户一边正常工作，一边承担专家级核查任务。
草稿被改了：继续追到下游处置
当用户把 AI 草稿改完发出去，系统终于获得了比“复制”更具体的证据：这段内容如何进入实际工作。但改动本身也有类型，不能全部算成质量退步。
客服人员改了称呼与语气，可能是在对齐公司表达；修正退款金额，可能是在纠正事实；加入客户未提供的特殊情况，可能是补充新信息。三类改动对应不同问题，如果全部压成“编辑率”，团队会错过修复方向。
Langfuse Academy 的客服教学示例把编辑类型区分为 none、tone、corrected、added。在内部试用阶段，客服人员编辑再发送，草稿与实发内容的差异是主要结果信号；进入客户直接使用阶段，这条人工编辑信号消失，才改用对话与下游工单结果。[8]
它说明采集应该跟着产品流程变化，而没有规定所有团队都必须先行为、再对话、最后结果。能拿到人工编辑差异的内部工具，可以先从这里开始；纯对话产品可以先做重述与转人工；代码助手可以关注接受、撤销和提交时保留情况。
结果信号（outcome signals）通常更接近业务处置，包括字段在审批时被修正、工单重开、代码是否保留到提交、PR 合并或回滚。它们描述已发生的事，比用户一句评价更容易核查；但它们仍受人工判断、外部流程与任务变化影响。
工单七天内因同一问题再次联系，是上述示例使用的重开条件。这个七天是该示例的观察窗口，不是所有业务通用的门槛。新工单是否同一问题、是否因为回答错误，也需要确认。PR 合并可能包含大幅修订，回滚可能因为需求变化，不能只按最终状态判质量。
结果的关联与延迟也要设计。几天后的工单重开，如何写回原会话？草稿多次编辑，哪份才是 AI 原始输出，哪份是实际发送内容？如果只有用户 ID、没有执行或会话标识，下游结果可能被错误归到另一次交互。
有些结果适合做验收锚点，有些也可以用于较快干预。延迟来自业务流程，不是“结果信号必然几天后到”。采纳后撤销可能几秒内发生，工单重开则需要等待。团队应按具体信号安排观察周期，不让尚未成熟的结果进入当日最终质量结论。
建一份能被解释的信号账，而不是一个总分
把四类信号列出来之后，接下来的产品设计工作是确定采集点、记录格式和使用方式。可以从已经存在的工作动作选起，优先考虑它是否能帮助团队作出某个判断，而不是一次性收集所有动作。
| 信号类型 | 比较适合的用途 | 解读时保留的限制 |
|---|---|---|
| 显式评分 | 收集用户态度，校准其他信号 | 低响应、自选择、按钮设计影响 |
| 行为信号 | 发现可疑操作，观察真实工作流程 | 曝光影响，同一个动作有多个原因 |
| 对话信号 | 识别纠正、追加需求和成功确认 | 依赖上下文，语义识别可能漏检 |
| 结果信号 | 检查下游处置，验证实际改进 | 关联难、可能延迟，处置不等于客观真值 |
这张表不是可信度排行榜。事实纠正通常比一次复制更有行动指向，但不同任务的信号强弱仍需验证。一个设计良好的显式原因评价，可能比无法归因的重开更有用；某条结果信号缺乏关联，也可能根本不能用于判断。
每条信号应记录原始事件、发生位置和归属对象。若可以判断极性，另存正向、负向或未知；极性解释还应记录依据或规则版本。归属至少能找到具体输出或会话，并尽量关联任务类别、版本与渠道。仅有“用户点了踩”而找不到被点踩的内容，后续核查很难进行。
事件时间与写入时间最好分别保存。七天后写回的重开，属于原会话的后续结果，不能简单归到写入那一天的模型表现。窗口未结束的样本可以标记“待成熟”，避免把还没机会重开的工单当作最终未重开。
数据统一应统一定义、状态、标识与统计规则，不是把所有信号换成同一个分数。点赞率、事实纠正率、编辑类型占比、重开率，可以各自形成时间序列。把语气调整、事实错误和回滚硬加成一个总分，会丢失它们的业务含义。
分类也可以聚合。可以分别统计 none、tone、corrected、added 的数量和比例，观察某类别的 corrected 是否增加，不需要先把四类任意映射成 0 至 3。跨信号比较时，应讨论它们与业务目标的关系，而不是因为都叫 score 就默认可以相加。
采集应尽早进入交互设计。在哪里问、什么时候问、用户不答时如何记录，会改变得到的样本。事后补埋点也能产生价值，只是有些已经缺失的上下文补不回来。在设计阶段考虑这些问题，能减少后续重建关联和猜测原因的工作。[3]
高成本人工审阅可以抽样，风险个案则按要求单独处理。随机样本用于检查整体，负向筛选用于高效发现问题，长尾或高风险任务可以专门加样。不要把它们合在一起算发生率；如果分层采样，需要保留各层数量与权重，才能解释总体统计。
信号进入优化之前，还要多做一次判断
采集到反馈并不意味着它可以直接进入奖励函数、自动排序或发布门槛。复制、点赞、语气偏好，都可能与业务价值相关，也可能被策略利用。
Meta 的 RLUF 研究展示了稀疏表情反馈可以用于训练预测模型，并在多目标优化中提高正向反应；同时也观察到激进优化下反复情感化收尾。它提醒我们，预测某种反应有效，并不等于已经测量了真实满意或任务质量。[7]
要使用一个信号作优化依据，团队至少需要检验它与目标的关系，检查被操纵的可能，并保留独立质量、安全和任务要求。优化权重变化时观察副作用，效果冲突时回到具体样本。不能要求任何代理“必然证明业务价值”，也不能因为它是代理就一概禁止使用。
OpenAI 的谄媚复盘还提醒，正向 A/B 与离线指标可能覆盖不到新行为问题。其复盘将多项改动组合视为可能原因，要求更重视专家定性测试，并把行为问题正式纳入发布判断。[9] 应用团队可以据此预先写明：谁能因具体风险记录要求暂停，暂停后补充什么验证。
当信号和评估结果冲突时，保留两份信息：用户确实表达了偏好，按任务或风险标准又发现了问题。不要为了得到一个方向而删掉其中一份。安全拒绝受到点踩、错误答案受到点赞，都是需要理解的产品现象。
对用户行为的解释也不是一次完成。把已确认的失败交给错误分析，稳定的模式可以形成评估器，可复现的案例可以进入数据集，修复后再看对应业务结果。这些后续工作让信号逐步获得含义，不是重新给每一个动作编一个质量分。
现在再处理那条“复制回答”的埋点，记录方式可以很简单：保存复制的输出标识、时间和位置，极性尚不明确；有后续插入、编辑或提交时再关联回来。报表仍然显示复制率，只把它叫复制率。
如果产品团队准备给这条信号加“高质量采纳”的名称，就需要补上证据：哪些复制确实进入任务，哪些经过大幅事实修正，抽查发现多少错误，以及这个关系在不同类别上是否稳定。命名慢一点，后面的判断会省去不少返工。
参考材料与口径
- Joachims 等，Accurately Interpreting Clickthrough Data as Implicit Feedback：搜索行为与偏好提取，不能将其点击策略的实验效果直接外推到所有 AI 产品。
- Langfuse Academy，Capturing signals：四类信号、引导与纠正，以及正负与未标注的默认处理建议。
- Eugene Yan，Patterns for Building LLM-based Systems and Products：显式与隐式反馈设计，以及行为解释困难。
- Lin 等，Interpretable User Satisfaction Estimation for Conversational Systems with Large Language Models：SPUR 方法与领域相关 rubric。
- Shi 等，WildFeedback：所列分布、精确率、召回率和一致度均来自论文的特定数据与校验，不是当前所有模型的性能。
- Marlin 等，Collaborative Filtering and the Missing at Random Assumption，UAI 2007：自选评分的缺失机制，2012 为 arXiv 上传年。
- Han 等，Reinforcement Learning from User Feedback：Meta AI 的 Love 反应采集及多目标优化，0.1% 只指该正向表情覆盖率。
- Langfuse Academy，Customer support chatbot：教学示例中的编辑类型、分阶段采集和七天重开窗口，不作为真实客户案例引用。
- OpenAI，Expanding on what we missed with sycophancy：2025 年模型更新复盘及行为发布判断。