AI 用户研究 Agent Evals：从专家反馈到持续监控
先让专家指出哪里不像一份可信的研究，再把这些具体问题变成可以持续监控的指标。
评测 atypica 这样的 AI 用户研究 Agent，最难的不是找一个更强的模型来打分。
最难的是，一开始我们并不知道应该评什么。
有一次，atypica 为一项饮料品牌研究找来了八位受访者：刚工作的程序员、咖啡店主、健身教练、带娃的年轻妈妈……
他们的年龄、职业和生活状态都不一样，但聊到这个品牌时，回答几乎是同一句：
“感觉这是我爸那辈人喝的东西。”
还有一次，报告中写道：
“一位 26 岁的受访者提到，她会在加班后奖励自己一杯。”
这句话读起来很自然，也很像一条不错的洞察。客户甚至把它划了出来。
但我们回到访谈记录中检查，发现没有人说过这句话。
这两类错误都不在最初的测试清单里。它们是在研究真实运行、被专家逐步检查以后，才被发现的。
所以，我们没有急着设计一张“大而全”的评测表，而是先问：
这份研究具体哪里让你不放心？
然后，我们把反复出现的问题定义成错误维度，再让 LLM 持续检查这些已知问题。
这就是 atypica 建立 Agent Evals 的起点。
复杂 Agent 不能只评最终答案
一次 AI 用户研究不只有最终报告。
在 atypica 中，一项研究会经过多个步骤。每一步看起来都可能正常，却在最后累积成一份不可信的报告。
如果只给最终报告打一个总分，我们可能知道“结果不好”，却不知道问题从哪一步开始，也不知道应该改哪里。
因此，复杂 Agent 的评测不能只看最终输出，还要把问题放回具体的 Agent 步骤。
这里也要说明一个边界。
企业为什么信任合成消费者，涉及数据来源、模拟保真度、与通用大模型的区别以及数据安全。我们在 中讨论了这些问题。
这篇文章关注的是下一层：即使底层方法成立，一次具体研究仍然可能在执行过程中出错。Agent Evals 要帮助我们发现这些错误，并避免它们在改版后重新出现。
第一步：从真实反馈里发现该评什么
我们在研究回放页的每个 Agent 步骤旁放了一个反馈入口。
专家看到问题后，可以直接写下：
八个人的职业虽然不同，但观点、理由和表达方式几乎一样。
我们没有先让专家从一张完整的问题清单中选择，也没有只让他们打 1～5 分。
因为“访谈质量 2 分”只能说明结果不好，不能告诉团队哪里出了问题。
相比之下，下面这些反馈可以直接帮助团队定位：
- 用户只是拿 Nike 举例，Agent 后面却把 Nike 当成了研究对象。
- 受访者都说不喜欢，但访谈没有继续问他们实际会不会购买。
- 报告称这是“普遍需求”，实际上只有一位受访者提过。
- 这句话用了引号，但在访谈记录中找不到原文。
- 计划承诺研究八个平台，最后只分析了三个。
这个阶段不要求专家使用统一术语，只要求把问题说具体：
- 哪里不对？
- 从哪段内容看出来的？
如果得到的是“Persona 不够真实”“报告不够专业”这样的评价，就继续追问：
如果只能指出一个具体问题，会是哪一个？
通常，第二次回答才真正可以用于评测。
第二步：把相似反馈归为同一种错误
同一个问题，专家可能会用不同的方式表达：
- 八个人像同一个人；
- 所有 Persona 都在说同一种话；
- 职业变了，回答没有变；
- 这些访谈互换名字也看不出区别。
这些反馈描述的是同一种错误。
我们把可以在不同研究中重复识别的错误类型，称为一个错误维度。
例如：
受访者回答趋同：不同背景的受访者，在核心观点、理由、经历或表达方式上高度相似，没有体现背景差异。
LLM 可以帮助整理反馈，但不能直接决定错误维度：
- 能归入已有维度的，优先归入已有维度；
- 现有维度无法覆盖时，可以提出候选新维度；
- 最终是否新建、合并或拆分，由 PM 或研究负责人确认；
- 信息不足的反馈留给人判断，不要强行归类。
一个错误维度，至少要说清楚三件事：
例如，八个人都不喜欢同一个产品，不一定代表 Persona 趋同。
一个人可能觉得价格太高，一个人担心糖分，一个人受到家庭习惯影响，还有一个人找不到适合自己的饮用场景。他们的结论相同，但背后的经历和判断方式不同，仍然是不同的人。
真正需要警惕的是：结论相同，理由相同，经历也可以互换，连表达方式都高度相似。
经过第一轮整理，我们逐渐形成了这样一批错误维度：
与“研究质量不好”相比，这些维度都指向了一个具体环节和一种具体行为。团队知道去哪里检查，也更容易讨论应该怎么修。
第三步：看新的错误是否还在出现
既然不一开始列完错误，接下来就有一个问题：
反馈要收集到什么时候？
我们看的是每天新增了多少个错误维度，而不是累计有多少个。
atypica 第一次集中检查真实研究时，第一天发现了 14 个此前没见过的错误类型，第二天 4 个，第三天 4 个，第四天 3 个。到月底，新的专家反馈已经很少再产生新的错误维度。
累计维度只会越来越多。新增维度持续减少，才说明这批研究里的主要问题已经看得差不多了，可以开始自动检查这些已知错误。
这不代表以后不会再有新问题，只代表这一轮可以先告一段落。
第四步：让 LLM 重复检查已知问题
专家善于发现新的问题，但不可能每天检查所有研究。
atypica 的专家在第一轮一共留下了不到 300 条反馈。之后两个月，LLM 拿着这份错误维度清单，检查了 1,500 多个研究。
两者的分工很清楚：
人负责发现和定义问题，LLM 负责规模化检查已知问题。
不要直接问 LLM：
这次研究做得好不好？
这个问题太宽，模型很容易给出一段听起来合理、实际无法复核的评价。
更好的方式是把问题缩小：
这次研究中的受访者回答是否趋同？
或者：
报告是否把研究过程中没有出现的内容写成了用户原话？
每个判断任务只检查一个维度，而且必须保留证据。
例如，检查“受访者回答趋同”时，一个有用的结果应该是：
而不是：
多位 Persona 缺少差异性，建议增强个性化。
后者只有结论，没有依据，PM 无法判断 Judge 是否理解对了。
下面是一份简化的 Judge 提示词：
这里必须守住一条边界：
Judge 只监控已有维度，不负责发现新的错误维度。
新的错误仍然要从专家反馈中产生，也可能先由用户行为或异常信号暴露，再由人回到研究记录中确认。
第五步：先验证 Judge，再使用它的结果
Judge 能批量运行，不代表它判得准。
在使用 Judge 的结果之前，需要准备一批由专家标好答案的研究记录，检查它与专家的判断是否一致。这批数据通常叫作黄金测试集。
黄金测试集既要有正例，也要有反例。
以“受访者回答趋同”为例：
- 正例：多位受访者的结论和理由都高度相似；
- 反例：结论相同，但经历和决策方式明显不同；
- 边界案例：目标人群确实存在共识，回答因此比较接近。
验证 Judge 时，不要只看一个整体准确率。至少要分开看：
- 误报：正常研究被判成有问题；
- 漏报：真实问题没有被发现。
不同维度，对两者的容忍程度不同。
例如，“无中生有的引用”一旦漏报，虚假证据可能进入客户决策；而“受访者回答趋同”如果误报太多，又可能把真实存在的人群共识当成错误。
Judge 判不准时，也不要立即开始堆提示词。先检查错误定义是否清楚、正反例的边界是否一致，以及 Judge 是否看到了判断所需的材料。
很多时候，Judge 暴露的不是模型能力不足，而是团队还没有把“什么算错”说清楚。
第六步：用固定输入比较 Agent 版本
黄金测试集验证的是 Judge，不是 Agent。
如果要判断 Agent 修改后有没有变好，需要另外保存一批固定的研究输入。每次修改 Agent 后，都用同一批课题重新运行，再由经过验证的 Judge 检查结果。
我们用出现率比较不同版本：
出现率 = 出现过某个问题的研究数 ÷ 这段时间运行的研究总数
假设用同一批研究课题分别运行 Agent v1 和 v2：
v2 改善了 Persona 差异和访谈深度，但虚构引用变多了。
这时不能把所有维度平均成一个总分，再宣布 v2 更好。
Agent 的一次改动可能修好一个问题，又让另一个问题变差。回归评测的意义，就是在上线前把这种变化暴露出来。
这两批数据的区别可以简单记成：
黄金测试集验证 Judge，固定输入比较 Agent。
第七步：自动监控旧问题，人继续发现新问题
产品上线以后，评测系统需要同时运行两条链路：
LLM 持续检查已知错误，人继续发现新的错误。
已有维度可以看出现率和变化趋势。某个维度连续上升时，再进入具体研究，检查 Judge 引用了哪些证据，以及问题最早发生在哪个 Agent 步骤。
但专家反馈入口不能关闭。
atypica 完成第一轮错误维度整理后，后续仍然出现了新的问题。其中一个叫“覆盖度虚标”：Agent 承诺研究八个平台，最后只分析了三个。
旧的 Judge 不会主动发现它，因为这个错误此前没有被定义过。
所以，Agent Evals 不是建立一张永久不变的指标表，而是一个持续循环：
真实运行暴露问题
→ 人把问题说清楚
→ 团队定义错误维度
→ Judge 持续检查
→ 产品变化后继续发现新问题
有些 Eval 问题，其实是产品问题
并不是每个错误维度都能靠修改提示词解决。
例如，用户没有把需求说清楚时，Agent 应该自己做出合理假设，还是停下来继续追问？
主动往下做，效率更高，但可能研究错范围；停下来追问，更谨慎，也可能让用户觉得流程太长。
如果团队没有先定义 Agent 应该多主动，就无法稳定判断某次行为到底是正确还是错误，Judge 也不可能得到一致的标准答案。
因此，Evals 有时发现的不是一个 bug，而是团队尚未做出的产品决定。
这也是 PM 应该参与 Agent Evals 的原因：评测不仅是在检查模型表现，也在迫使团队说清楚产品究竟应该怎样工作。
如果你想开始，只做一个维度就够了
你不需要一开始搭建完整的 Eval 平台。
先找一个真正影响用户信任的问题，例如“受访者回答趋同”，让它走完一遍最小闭环：
- 从真实运行中找到具体案例；
- 请专家写清问题和证据；
- 定义什么算错误、什么不算；
- 让 Judge 检查新的研究记录；
- 用少量正反例验证 Judge；
- 用同一批输入比较两个 Agent 版本。
如果只是想跑通 Demo，可以先使用示例数据。但如果要发现自己产品真正的问题，最终还是要回到真实运行。
先不要急着做综合总分、几十个维度或一套复杂看板。
先把一个问题说清楚，并确认人和 Judge 能够相对稳定地识别它。你就已经有了一个有用的 Agent Evals 起点。
最后
atypica 最初发现的两个问题，一个是八位受访者说得太像，另一个是报告中多出了一句没人说过的话。
在专家指出它们以前，我们甚至不知道应该把什么写进评测清单。
现在，这些问题有了固定的名字、清楚的边界和可以复核的证据。LLM 可以持续检查它们；Agent 每次修改后，也可以用同一批输入重新运行，看看问题是真的减少了，还是从一个环节转移到了另一个环节。
所以，Agent Evals 的起点不是先坐在会议室里列完所有指标。
更实际的起点是打开一份真实运行，找到那个让你不放心的地方，然后问：
它具体错在了哪里？
下一次，我们能不能更早发现它？