大多数构建 AI 产品的团队会花费数周时间设计评分组件、星级点击、点赞/点踩按钮。然而六个月后，他们查看数据时发现响应率仅为 2% —— 数据偏向于极端体验，被那些带有强烈偏好的人主导，而且在区分 7/10 和 9/10 的输出方面几乎毫无用处。
与此同时，每一个用户会话都在产生源源不断的真实、明确的行为信号。接受代码建议并继续操作的用户是满意的。立即按下 Ctrl+Z 的用户则不满意。连续四次重新组织问题的用户正在告诉你一些显式评分永远无法捕捉到的信息：前三次回答都失败了。无论你是否收集，这些信号都存在。问题在于你是否正在闭合这个反馈回路。
为什么点赞评分在结构上是失效的
显式反馈（Explicit feedback）有一个根本性问题：它捕捉的是用户怎么说，而不是用户怎么做。这两者经常发生背离。
用户可能会给一个 AI 写作助手打五星，同时却在修改它生成的每一条回复中 80% 的内容。评分捕捉的是情绪 —— 这个工具感觉很有用，用户喜欢这个产品。而编辑行为捕捉的是质量 —— 输出结果一直有误，以至于需要手动纠正。如果你只根据评分进行优化，你将构建出一个让人感觉印象深刻但产出不可靠的系统。
这种背离也存在于另一个方向。那些默默满意的用户 —— 接受输出并继续操作的人 —— 很少进行评分。他们没有理由停下来去点一颗星。你的 4.7 分平均分是建立在那些带有强烈观点的人的声音之上的，而不是中位数的体验。
关于多轮对话系统的研究发现，在对话后期，超过一半的用户表达中会出现隐式反馈信号，而显式评分仅在极小比例的互动中被收集。行为数据更丰富、频率更高，且是自动生成的。你已经在为产生这些数据的基础设施付费了。
值得收集的行为信号
并非所有隐式信号都具有同样的参考价值。有些需要结合上下文才能正确解读。以下是大致按可靠性排序的信号分类：
高置信度负面信号：
- 立即撤销（在接受建议后的几秒钟内按下 Ctrl+Z）
- 在同一会话内重新表述查询（用户因为上次回答失败而在重试）
- 未完成任务即放弃会话（在工作流中途离开）
- 直接覆盖完整输出，而不是针对性的编辑
高置信度正面信号：
- 无需修改或后续操作直接进入下一个任务
- 将输出复制到下游工具或分享到外部
- 生成输出后，提出基于该输出的后续问题
Context-dependent signals：
- 接受的响应长度 vs. 截断长度（如果用户总是滚动并继续阅读，则长度适中；如果他们总是在第 10 行停止阅读，则长度不当）
- 对 AI 生成内容的编辑率（需要基准线：法律合同 30% 的编辑率是正常的；而写作助手生成的客户邮件同样的编辑率则过高）
- 对话持续性（用户回应 vs. 保持沉默）
对话系统的一项研究发现：一个简单的基于长度的隐式信号 —— 用户生成的响应是否超过阈值长度 —— 与基准模型相比，带来了 12 个点的胜率提升。对于一个单一且低成本收集的行为指标来说，这是一个非常有力的信号。
构建从行为到评估数据集的流水线
目标是将行为信号转化为带标签的数据对：(input, output, quality_label)，你可以用它来构建评估数据集、微调奖励模型或识别退化案例。以下是一个实用的流水线。
第一步：对交互层进行监测 (Instrument the interaction layer)
标准的观测性指标 —— 延迟、错误率、Token 数量 —— 是不够的。你需要交互层面的观测能力：
- 记录会话 ID 和对话轮次序列，而不只是单个请求
- 记录编辑事件以及相对于输出生成的时间戳
- 捕获导航事件（用户是离开了产品，还是进入了更深层，或者是重复了某个步骤？）
- 记录查询重构（同一会话、相似的语义意图、新的措辞 = 重试信号）
你不需要捕获具体内容。你需要捕获结构：响应后发生了什么，发生了多久，以及朝哪个方向发展。
第二步：根据产品语境定义行为标签
行为信号在不同的语境下意义不同。对代码建议的立即编辑可能意味着模型错了，也可能意味着开发者想加入自己的定制。你必须为你特定的产品定义每个信号的含义。
一个有用的练习：对于你监测的每个行为信号，写出可能产生该信号的两到三种用户意图解释，并设计日志模式（schema）以便尽可能地区分它们。如果你无法区分，请将该信号视为弱信号而非强信号。
第三步：策略性采样，而非随机采样
你不需要收集每个会话的标签。高价值的案例在于边缘地带：
- 用户表现出混合信号的会话（部分编辑，然后继续）
- 高重试会话（针对同一底层任务进行了 3 次以上的重构）
- 与历史基准不匹配的新交互模式
- 在其他指标上模型表现最差的用户群体的会话
从分布的尾部采样可以让你发现最可能暴露模型弱点的案例。随机采样只会给你带来大量确定的成功案例，这对提高评估覆盖率毫无帮助。
第四步：转化为评估示例
对于每个带标签的会话，提取规范的 (prompt, response, label) 三元组：
- Prompt 是用户最终成功的措辞（在任何重试之后）
- Response 是模型在那一轮产生的输出
- Label 可以是二元的（接受/拒绝）或分级的（无编辑、轻微编辑、重大编辑、完全替换）
对于重试案例，你现在拥有了更有价值的东西：一个自然的 A/B 对。模型的第一次响应被拒绝了；重构后的查询产生了一个用户接受的结果。这是一个无需任何标注的偏好对（preference pair） —— 行为序列本身就是标签。
标注预算账
当你核算人工标注的成本时，行为信号的经济优势就变得显而易见了。
在标准质量下，人工标注的成本约为每个标签 0.08 美元。而基于 LLM 的标注成本约为每个标签 0.002 美元。在同等成本下，LLM 标注能为你提供 40 倍的已标注数据——而且在规模化（约 25,000 个示例）的情况下，LLM 标注的数据集在下游模型质量上可以与人工标注的数据集相媲美。
行为信号的每个标签成本几乎为零，因为用户在与你的产品交互时就是在进行标注。其成本在于基础设施和流水线工程，而非单条数据的劳动力成本。在任何具有一定用户规模的情况下——哪怕只有数千名月活跃用户——你生成已标注评估数据集的速度都会超过任何人工标注工作流。
但问题在于噪声。隐式信号虽然频繁但伴随着噪声。一次重试可能意味着模型失败了，也可能意味着用户改变了主意。一次会话放弃可能意味着不满，也可能意味着用户被会议中断了。从行为信号中构建干净的评估数据集需要过滤、聚合，并对标签的不确定性有一定的容忍度。关于重复隐式反馈的研究发现，测量多个交互事件中的不确定性——而不是依赖单一的行为事件——可以显著提高信号的可靠性。
Microsoft 的语义遥测做对了什么
Microsoft Research 构建了一个他们称之为语义遥测（semantic telemetry）的框架，用于理解用户如何大规模地与 AI 系统交互。其核心洞察是使用 LLM 对交互模式进行分类，而不仅仅是统计事件数量。
他们的流水线分为三个步骤：
- 生成分类法 (Taxonomy)：将对话样本输入 LLM，并要求其生成一套分类类别——主题、任务类型、复杂程度。
- 大规模分类：将这些类别应用于数百万次匿名交互。
- 分析分布偏移：观察主题和任务复杂度的分布如何随时间、在不同人群或不同模型版本之间发生变化。
使这一方法对评估产生价值的是第 3 步。如果你产品的高级用户群体开始从“查找与检索”任务转向“综合与分析”任务，你的评估数据集就需要反映这种转变。行为遥测让这种偏移变得可见。如果没有它，当实际使用分布在发生演变时，你的评估数据集仍会保持停滞。
你已经忽略的沉默信号
有些行为信号不需要新的埋点，因为它们已经存在于你的交互日志中——只是尚未被提取和利用。
Ctrl+Z / 撤销事件：如果你的产品涉及将 AI 生成的内容应用到文档或编辑器中，编辑器已经记录了撤销事件。在接受建议后的几秒钟内执行撤销，是你无需询问任何人就能收集到的最清晰的负面标签。
分享或导出事件：如果用户将 AI 生成的输出复制到剪贴板、分享链接或将内容导出到其他工具，这是一个强烈的认可信号。这意味着他们足够信任该输出，从而将其流转到下游。
从结果页面后退：如果用户点击进入 AI 生成的结果并立即返回，这是一个拒绝信号。这与搜索中的跳出率结构相同——结果与意图不匹配。
后续问题的结构：在之前回答基础上构建的后续问题（如“现在把它缩短”或“为边缘情况 X 添加一个异常”）是积极的参与信号。而重新解释原始任务的后续问题（如“不，我的意思是……”）则是修正信号——模型理解错了。
这些都不需要评分提示。如果你在会话级别记录交互，它们就已经存在于你的日志中了。
闭环：从信号到持续评估
目标不仅是收集标注数据，而是构建一个反馈闭环，持续更新你对生产环境中模型质量的理解。
一个实用的闭环架构如下：
- 在会话级别埋点 (Instrument) 交互事件
- 使用你为产品定义的信号分类法对行为事件进行标注 (Label)
- 从分布尾部进行采样 (Sample)，以构建针对性的评估分片 (eval slices)
- 在部署前针对这些分片评估 (Evaluate) 模型变更
- 监控 (Monitor) 行为信号中的分布偏移，作为质量退化的先行指标
监控步骤是大多数团队会忽略的一步。行为信号分布是早期预警系统。如果模型更新后重试率飙升，这就是一个质量退化信号——通常比等待显式用户投诉或正式评估结果汇总要快得多。相反，如果会话完成率在没有任何提示词更改的情况下有所提高，那么底层模型行为中某些评估未能预测的东西发生了变化。
最危险的 AI 系统故障不是那些响亮崩溃的系统，而是那些在保持运行、听起来充满信心，却在悄无声息地向错误方向偏移的系统。行为遥测能让你在用户发现这种偏移之前先看到它。
本周要做什么
你不需要立即构建完整的流水线。从以下两件事开始：
第一，审计你已经在记录的日志。检查你的交互日志是否包含会话 ID (session ID)、轮次序列 (turn sequences) 以及任何响应后的用户行为。如果已经包含这些，你就可以开始从现有数据中提取行为标签，而无需编写新的埋点 (instrumentation) 代码。
第二，选择一个在你的产品上下文中含义明确的信号，并有针对性地进行埋点。对于大多数产品来说，查询重试率 (query retry rate) 是现有信号最强、噪声最低的行为指标。一个重新组织语言并再次提交的用户，正在明确地告诉你第一个响应没起作用。就从这里开始。
无论你是否闭环，反馈循环始终存在。每一个用户会话都在对你的模型进行一场无声的评估。唯一的问题在于，你是否在阅读这些结果。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
