第一次接触模型评测时，很容易先去找完整框架和公开榜单，最后花很多时间搭环境，却仍不知道自己的应用是否变好。我更建议先写十个真实问题：它们来自用户咨询、工作资料或过去发生过的错误，答案和判断标准自己能够确认。
十个问题里不要全是正常输入。加入一个资料里没有答案的问题、一个容易混淆数字的问题、一个需要引用来源的问题、一个格式严格的问题，再放两三个业务边界案例。这样很快能看到模型是知识不足、检索失败、格式不稳，还是会在缺少证据时编造。
每个问题记录输入、期望要点、不能接受的错误和验证方法。代码实际运行，数字自己重算，引用打开原文，结构化结果交给解析器。开放式文字可以由两个人分别评价事实、完整性和可用性，别只给“喜欢/不喜欢”的总分。
第一轮只建立基线，不急着调 Prompt。随后一次改变一个因素：模型、资料切分、检索数量、提示词或输出约束。使用同一组问题重跑，记录改善和退化。若只有一两个案例变好，要警惕是不是对测试集过度适配。
等十个问题的流程跑顺，再扩展到五十或一百个，并考虑自动化。小评测集并不完美，但它能让团队从“这个回答看起来不错”走向可重复比较。欢迎分享你所在场景里最容易让模型翻车的问题类型。