公开基准测不出你的业务问题。自建一个小而精的评测集（eval set），是模型选型、提示词迭代和版本升级时最值得投入的基础设施。

【一、样本从哪里来】
- 真实日志：从线上请求中抽样，脱敏后使用，最能反映真实分布。
- 困难样本：专门收集过去出错的案例、边界情况、长输入、多语言混杂输入。
- 对抗样本：故意设计的诱导、歧义、缺失信息的问题，用来测试模型是否会“编造”。
建议各类样本保持一定比例，并给每条样本打上类别标签，便于分组统计。

【二、定义“什么是对的”】
- 有标准答案的任务（分类、抽取、数学）：用精确匹配、字段级 F1 或规则校验。
- 开放式任务（摘要、问答）：写清评分细则（rubric），例如“事实正确 / 覆盖要点 / 无编造 / 格式合规”各占几分。
- LLM-as-a-judge：可以用强模型打分以降低人工成本，但要注意它可能偏好更长的回答、偏好与自己风格相近的输出，也可能受答案顺序影响。建议定期抽样人工复核，计算人工与模型打分的一致率。

【三、让结果可重复】
- 固定提示词版本、模型版本、temperature、max_tokens 等参数，并记录在结果文件里。
- 对随机性较大的设置，多跑几次取平均，并看波动范围。
- 评测集本身也要做版本管理，新增样本不要覆盖旧版本，否则前后结果无法对比。

【四、常见坑】
- 评测集太小、太简单，所有模型分数都接近满分，失去区分度。
- 评测样本被用来调提示词，导致“过拟合评测集”。建议留出一部分作为盲测集。
- 只看平均分，忽略了某一类关键样本的严重退化。

【五、落地建议】
起步不需要很大规模，一两百条高质量样本加上一个简单脚本，就能在每次改提示词或换模型时快速回归。之后再逐步接入 CI，实现自动化回归测试。

讨论：
1. 你们的评测集大概多少条？如何维护和更新？
2. 用 LLM 做裁判时，你们是如何校准它的？