生产反馈信号

显式反馈是一份来自错误人群的、极小且有偏的样本。

点赞点踩控件是每个团队最先上线的东西，也是他们最不该依赖的东西。问题不在于数据糟糕——而在于这份数据描述的是一个自选择的少数群体，其构成会随你的界面而变，而它误导你的各种方式全都指向同一个方向。

• 回收率低到让任何切片都失去意义。大多数产品的显式评分覆盖率远低于交互总数的百分之一。这足以在一个季度里给两个版本排序，却远远不足以回答"上周二那次提示词改动是不是伤到了财务工作流"——而后者才是你真正的问题。
• 这个人群天生是双峰的。人们只在事情"值得一提"时才评分。占绝大多数的中间地带——够用地把活干完的回答，以及被悄悄改掉的轻微错误——从不留痕，而那个"轻微错误"的桶里装着你几乎全部可挽回的质量。
• 点赞量的是满意度，而满意度不是正确性。一个流畅、自信、错误的回答，会从一个无力核验它的用户那里得到好评——这恰恰是你最需要检测的失败模式。任何奖励点赞率的目标，都是在奖励自信，而模型极其擅长供应自信。
• 你一动按钮，信号就跟着动。位置、提示文案与出现时机能把回收率改变数倍，这意味着跨越一次界面改版的同比比较，比的是两台不同的仪器。如果你要留着这个控件，就冻结它的呈现方式，并把对它的任何改动当作一次仪器重新标定。
• 自由文本评论才是值得留下的那部分。量少、信息密度高，而且它们能叫出你的分类体系里还没有的失败模式。去读它们；不要把它们汇总成一个情感分数，那会把它们唯一的价值扔掉。

编辑就是标签。把输出与最终交付物之间的差异捕获下来。

几乎每一个产出物件的智能体——一份草稿、一个补丁、一条查询、一段摘要、一封回复——都会把它交给一个人，那个人随后改动它并使用它。那次改动，是一位掌握完整上下文的领域专家生成的、免费而稠密的逐例纠正；而在多数产品里，它在用户点下发送的那一刻就被扔掉了。

• 存这一对，而不是存分数。智能体的输出与最终物件，以任务 ID 关联，并附上 trace。"原样接受"的一对是正例；"被大幅重写"的一对是一个附带了正确答案的已标注失败。这是你的产品所生成的最高价值数据，而它的成本是一个数据库字段。
• 编辑距离是指标，差异本身是证据。把归一化编辑距离作为连续质量信号来追踪——它稠密、可实时计算，且与"有用性"的相关度远高于任何评分。然后去读那些差异，因为指标只告诉你质量动了，只有差异才告诉你智能体错在哪。
• 把差异聚类，分类体系会自己写出来。按"改了什么"分组——语气、一个错误的常量、一句被略掉的限定、一段过长的开场白、一个凭空捏造的字段。实践中少数几个簇就覆盖了大部分编辑，而每个簇都是一个具体、可着手的缺陷，而不是"质量有点低"。
• 把"纠错"与"个人偏好"区分开。用户改写一条事实陈述，是缺陷；用户把"你好呀"改成"嗨"，是文风偏好，把后者当缺陷会让你去优化噪声。按簇把它们分开，只有第一类才进评测集。
• "原样接受"是有歧义的，必须拆开。它要么意味着"这是对的"，要么意味着"我根本没读"。用你的界面允许的任何代理量去消歧——呈现到接受之间的时间、物件是否被打开过、用户随后是否回退过——因为一群"盖章式"用户会在质量根本没被测量的情况下抬高你最好的那个指标。

按行为信号真实的含义去读它，而不是按你希望的含义去读。

除编辑之外，一次会话还会释放少数几种携带真实信息的行为。每一种都有方向性，没有一种不言自明；常见错误是在还没确立"它到底量的是什么"之前，就把某一种提拔成头条指标。

• 立刻换个说法重问，是你手上最强的负面信号。用户问了、拿到了东西，几秒内换个措辞又问了一遍。量大、延迟低、方向明确。要仔细分段：在智能体明确提出澄清问题之后的重问，是系统在正常工作。
• 任务中途放弃，有用的部分是"在哪一步"。人们离开的那一步，对缺陷的定位远好于一个整体完成率——五分之一的用户在同一个确认页离开，那是一个有门牌号的设计 bug。
• 升级转人工是一个附带处置方案的已标注失败。这次移交既携带了击败智能体的那份上下文，又会在不久后带来"正确处理应该是什么"。它是整套信号里最富含信息的单个事件，而且它到达时已经裁定完毕。
• 复制、导出、发送是弱正信号；就按弱信号对待。它们表明输出被使用了，不表明它是对的。作为分母有用，作为目标危险。
• 一周内的二次联系，是能预测流失的那一个。同一个用户把同一个问题又带回来，是"第一次处置只是表面功夫"最清晰的可得证据，而它在任何按会话计算的指标里都是隐形的。
• 每一个信号都被流量构成所混淆。重试率上升可能是因为一个措辞习惯特别的新客户刚上线，而不是因为模型回归了。在相信任何一次波动之前，先按客户队列、任务类型与入口分段——这与质量回归检测所坚持的是同一套纪律。

反馈是一台抽样仪器，不是一个指标。把它对准你的评测集。

让这一切开始回本的重构是：不再问"我们的反馈分是多少"，改成问"这一周最值得人来看一眼的五十次交互是哪些"。反馈非常擅长回答第二个问题，而在结构上没有能力回答第一个。

• 建一个按信号强度排序的分诊队列。带评论的点踩、高编辑距离、先重试再升级、在靠后步骤放弃。排好序、去重，并且短到人真的能清空它——每周五十条被认真看过，胜过五千条被汇总。
• 每一个被确认的缺陷都变成一个附带正确输出的黄金用例。这正是全部要点所在。那份纠正已经存在于差异或升级处置里，所以把它提升为评测用例几乎是免费的——而这正是评估驱动开发得以持续、而不是变成一次英雄主义的一次性标注工程的原因。
• 用信号来为"裁判"抽样，而不是用它取代裁判。让 LLM 裁判跑在一份按反馈加权的样本上，每 token 换来的信息远多于跑在均匀流量上，因为你把预算花在了有意思的用例所在之处。
• 永远不要直接优化一个反馈比率。把目标对准点赞率，你会得到一个更会奉承、更少设限、并且不再拒绝那些本该拒绝的事情的智能体。只把目标对准编辑距离，你会得到更短的输出。反馈负责挑出该检查什么；而你据以优化的，是那个留出的、带标签的评测集。
• 同时并行跑一条均匀随机抽样。按反馈加权的抽样是刻意有偏的，所以它无法告诉你基准率。一条用同样方式裁定的、小而无偏的流，才是让加权流变得可解读的东西。

在同一套系统里闭环，否则信号会衰减成一份没人读的报告。

失败模式不是"没有采集数据"——团队确实在采集。而是信号落进了分析工具、评测集住在代码仓库里，而两者之间的连接是一个"记得这件事的人"。那个连接必须是一条流水线。

• 在写入时就把反馈与 trace 关联起来。一个没有 trace 的点踩是一条意见；一个关联了模型版本、提示版本、工具调用、检索上下文与延迟的点踩是一份诊断。把 ID 一路带过前端，让这成为一个外键而不是一次事后重建——这就是追踪是这一切前置条件的原因。
• 让"提升为评测用例"在评审工具里是一次点击。这里的摩擦，就是"每周生长的测试集"与"上线那天写完的测试集"之间的全部差别。如果评审员必须打开仓库、手写 YAML，那这套测试集会在第九天停止生长。
• 给评测集做版本，并连同"加了什么、为什么加"一起汇报。一个不断生长的测试集会悄悄改变你那个质量数字的含义；没有变更记录，"因为集合变难了而下降的分数"与"一次回归"无从区分。
• 把已确认的缺陷簇送进发布闸门。一个连续三周出现的簇不是 bug 列表上的一项，而是一项缺失的能力，而闸门正是让它对做优先级的人可见的地方。
• 当用户的反馈真的改变了什么时，回头告诉他。当人们发现反馈确实去到了某个地方，显式反馈的回收率会显著上升，而这是你在这个"无法靠埋点绕开"的信号上能做的最便宜的干预。

陷阱：同意、幸存者偏差，以及那个会吃掉自己的反馈回路。

隐式反馈之所以强大，恰恰因为它无需询问即可采集，而这也正是它一切问题的来源。有三个值得在建流水线之前、而不是之后就点出名字。

• 编辑与草稿是用户内容，使用它们是一个治理问题。为改进模型而保留某个人写下的东西，需要合法性基础、保留期限、删除路径，以及在多数企业合同里的一条明确条款。在流水线存在之前就与数据治理把它定下来，因为往一份你已经拿去训练的语料上补追同意，是做不到的事。
• 幸存者偏差是内建的，而且会复利。每一个信号都来自留下来的用户。被智能体伤得最重的那些人在第一周就走了、什么也没贡献，所以一份由反馈驱动的路线图，会稳定地朝着"已经能容忍这个产品的人群"去优化。要用首轮会话队列和流失信号刻意对冲它，否则你的指标会一路变好，而你的市场一路变窄。
• 按反馈加权的训练会收窄分布。如果你的评测集只由"产生了信号"的用例构成，那你是在逐步拟合尾部、丢掉中段。STEP 4 里那条均匀抽样正是纠偏手段，而它也是预算一紧就最先被砍掉的东西。
• 任何可见且被奖励的东西都会被操纵。如果某个支持团队的奖金取决于点赞率，那你现在拥有的是一个点赞率，以及零信号。让这台仪器远离任何人的薪酬，就像你对待任何一个还打算继续信任的测量一样。
• 不要让裁判和反馈互相背书。用反馈挑出来的用例去调裁判，再用裁判去解读反馈，会造出一个自洽却与现实脱节的闭合系统。用周期性的人工裁定给两者同时锚定——这正是裁判校准的论证。

相关：在线 vs 离线评测讲每种信号该待在哪，智能体的 SLO 与错误预算是这些信号所处的分层，评估智能体是地基。