给大模型应用搭一套评测体系：别再凭感觉说变好了

做过一段时间大模型应用的人，多半都有过这种崩溃时刻：你兴冲冲地把提示词改了一版，感觉效果明显变好，结果上线后用户投诉反而多了——你根本不知道是哪里出了问题。根子在于，大模型的输出是不确定的，你没法像传统软件那样，靠几个单元测试就说”我没改坏”。解决这个问题的唯一靠谱办法，就是给你的大模型应用搭一套正经的、可重复跑的评测体系。这篇文章，我把自己在生产环境里一点点跑通的这套评测方法讲清楚，供大家参考。

为什么大模型必须单独做评测

传统软件的输出是确定的：同样的输入，同样的输出，测一遍就够了。但大模型不是。它同样的输入，两次生成可能都不一样；你改一个提示词、换一个模型版本，效果可能全面提升，也可能在你没注意到的角落悄悄退化。如果你没有一套固定的评测在背后盯着，这种退化你根本发现不了，直到用户来骂。

所以大模型应用的评测，本质上是给你装一双”前后对比”的眼睛。它的核心目的，不是给模型打一个绝对分数，而是让你在每次改动之后，能明确地回答：这次到底是变好了、变坏了、还是没变。有了这个，你调提示词、换模型、改流程，才不是盲人摸象。

先建一个评测集：这是地基

一切评测的起点，是一个评测集。别贪多，从你的真实业务里挑出来几十个有代表性的输入，每个都标注好”期望的输出是什么样”。这个评测集要覆盖几种典型情况：最常见的正常请求、容易出错的边界情况、以及那些你之前踩过坑的刁钻案例。

这里有个关键认知：评测集不是写完就锁死的。每次你发现一个线上的 bad case，就要把它补进评测集里。这样你的评测集才会越来越”刁钻”，越来越贴近真实世界。它本质上是你团队踩过的所有坑的集合，越养越值钱。很多人评测做不好，就是因为评测集永远只有那几条精心挑选的”好案例”，测不出真实问题。

怎么判分：从人工到自动

有了评测集，下一个问题是：怎么判断一次生成算不算”好”？最简单可靠的当然是人工看，但几十上百条逐条人工打分，每次改动都来一遍，根本扛不住。所以要分层。

一部分可以用确定性的规则来判。比如你的输出必须是合法 JSON、字段不能缺、字数要在范围内——这种用脚本一跑就知道过没过，快又准。另一部分涉及内容质量、语义是否正确，规则判不了，这时候常用的做法是”用大模型评大模型”：让一个更强的模型当裁判，按照你定义的标准给生成结果打分。这种自动评测大大提高了迭代效率，但要小心它自己的偏差，关键场景仍要抽样人工复核。

我会把这两者结合：规则评测兜底格式和硬指标，模型评测负责语义质量，再定期抽一批人工看。三层下来，既快又不会完全失控。

把评测接进日常迭代

评测体系真正发挥作用，不是你想起来才跑一次，而是要变成日常迭代的一部分。每次你改了提示词、换了模型版本、调了参数，第一反应应该是：跑一遍评测集，看分数和 bad case 的变化。如果新版本在关键指标上退化了，就别上线。

这个习惯一旦养成，你调大模型就从”玄学”变成了”工程”。你不再需要凭手感猜这次改动好不好，而是有数据撑腰。更重要的是，它能帮你挡住那些”看起来很美、实则退步”的改动——这在大模型调优里太常见了，改了之后你自己试的那几条变好了，评测集一跑才发现别的场景垮了。没有评测，你根本抓不到这种退化。

到底该盯哪些指标

很多人做评测一上来就追求一个总分，其实更有意义的是把指标拆开看。我一般会分三类。第一类是硬指标：输出格式合不合法、有没有该拒答的时候乱说、幻觉率高不高。这些通常能用规则或者明确的对错来判，是底线。第二类是任务效果：对你这个具体业务，任务完成得怎么样——比如客服场景，是有没有正确理解用户意图、有没有给出可用的解答。第三类是体验指标：响应快不快、有没有啰嗦跑题、语气对不对。

把指标拆开的好处是，你能精确定位问题。比如一次改版后总分没怎么变，但你细看发现”幻觉率”涨了、”响应速度”降了，那你就知道该往哪个方向调，而不是对着一个模糊的总分干着急。我还会特别看重”坏案例率”——就是那些完全答非所问、明显翻车的比例。这个数字往往比平均分更能影响用户的真实感受，因为用户记住的永远是那些离谱的失败。

几个新手误区

第一个误区是只测”好案例”。评测集里全是顺顺当当的请求，测出来分数一直很高，一上线却被真实的刁钻用户打爆。记住，评测集的价值在于它的”刁钻程度”，而不是它的数量。第二个误区是用模型当裁判却从不复核。自动评测快是快，但裁判模型自己也会犯糊涂、也有偏好，关键场景一定要定期人工抽检，否则你会被一个不可靠的裁判带着走。

第三个误区是评测做一次就放着不动。模型在更新、业务在变化、用户的问题也在演进，评测集和评测标准必须跟着一起维护。一个三个月没更新的评测集，测出来的结论早就失真了。把评测当成一个活的、持续生长的资产来养，而不是一次性的任务。

举个具体的例子。我们有个做客服问答的应用，早期全靠程序员自己试。有一次我们换了个”更聪明”的模型，自己测了几条感觉特别好，兴冲冲上线，结果第二天就被用户发现：它开始对一些它不懂的问题瞎编答案。如果当时有评测集，我们把”应该拒答却乱答”这种案例放进去，换模型那一跑就能看到拒答率明显下降，根本不会等到用户投诉才发现。从那以后，我们立下铁律：任何模型或提示词的改动，评测没通过，一律不许上线。这条规矩，帮我们挡掉了无数次”自嗨式”的发布。

说到底，评测体系不是为了装样子给老板看，而是给你自己装一个不会说谎的雷达。大模型越是看起来什么都懂，你越需要一套客观的办法去检验它到底懂不懂、在哪些地方偷偷退化了。愿意花功夫把这件苦活做扎实的团队，才能把大模型应用越做越靠谱。