评测题从哪里来？

评测集的第一道题，不是把大脑 cpu 干烧了想出来的。它藏在业务场景的细枝末节里：用户的咨询、修过的 bug、意外发现的坑。

继续老演员登场：「给订单金额按大小降序排列」

1. 一条反复出现的问题。
第一个来源：真实需求。翻翻 LangSmith 和 Langfuse 的文档，说的这个事实来源，上线之后的生产运行记录就是评测数据集。
2. 一份 bug 修复记录。
第二个来源：历史故障。假设在客户反馈大群中接到一个投诉，说金额返回错了，然后修复上线后，这个历史故障就是一道题。这和传统测试中的线上缺陷库的功能类似。
3. 一份手工执行的测试用例。（这是 Anthropic 对这一步的直接建议）
第三个来源：人工测试。输入一张空订单表，看它怎么办；填两笔相同的订单金额，再看一次。这些都是传统测试用例中的等价类和边界值，以及错误经验，人工测试虽然比不上自动化的可复用性高，但是胜在发现失败的速度最快。然后，把手工测试的结果分类汇总沉淀到评测集。
4. SWE-bench和τ-Bench
第四个来源：公开基准。看看公开基准的题都来自哪里，SWE-bench 的题来自真实 issue，τ-Bench 的领域数据是参考真实场景简化的合成物（贴近真实，不等于来自真实）。但是，公开题有被模型背诵过的风险。所以，测自己的场景，终究要靠自建的私有题。

从这些来源获取的还只能被当做原始素材，还不能被当做评测集中的题。每条原始素材入集前都需要经过以下工序：泛化脱敏，按五个字段写清，编号入集。

好题有个很朴实无华的判断依据：
1. 找两名懂这个业务领域的人（比如都懂订单业务的测试工程师），让他们互不通气、各自独立地判同一份 AI 回答的「过 / 不过」，两人判得一致，说明判定标准本身无歧义。两人判不一致，说明在题面或判法存在模糊处。
2. 每题再配一份参考解：人写得出解，证明题可解；再把参考解喂给判分器，如果它该判过，却判了不过，错的就是判分器。

评测集在起步时，应注重质量，而非数量，几十道源自真实失败的题，就够搭建评测集了。大家可以试试：翻翻最近的客户反馈与监控故障记录，挑一挑反复出现的问题，然后，写成第一道题，放进评测集，之后再慢慢的从这四个来源筛选和积累题目。

创作说明：AI 协助制图。来源：Anthropic〈Demystifying evals for AI agents〉，SWE-bench / τ-Bench / LiveCodeBench / GSM1k 论文。