推文

@fireandstart · 2026-10-11 02:06

95% 的离线通过率、工具调用成功和零报错，仍可能与糟糕的真实体验同时存在。这个提醒很重要：评测集通常覆盖的是团队预想得到的任务，而线上暴露的是用户真正遇到的表达、上下文和流程断点。像 prompt 重复率、挫败信号、上下文丢失、虚报成功、对话中途放弃和 agent 漂移，未必会让服务报错，却会让用户一次次重试，最后悄悄离开。 因此离线与在线评估需要配合：离线评测负责可重复地比较版本、定位回归；线上分析负责发现测试集尚未覆盖的失败模式。把真实对话中的问题脱敏归纳成案例，再配上可解释的 grader 和 trace，才能让偶发抱怨变成能复现、能修复、能防回归的证据。 我尤其认同“分析用于发现，评测用于验证”这个分工。指标本身不是目标：重复提示可能意味着模型没听懂，也可能是用户在补充条件；对话结束也不必然代表满意。需要把信号与任务结果、用户反馈和人工抽查结合起来，避免为了压低一个数字而伤害实际完成率。真正有价值的闭环，是发现问题、形成用例、修复根因、验证回归，再回到生产看用户是否真的少踩了这个坑。

曝光 23 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 0.9987568685493001