LLM质检员上岗记：确定性评估（Deterministic Eval）

可视化演示

评估概述：老张的检测台

老张之所以能用一上午查完三百件产品，是因为他从来不在“好不好”上纠结。他的桌子只有三样东西：一张规格说明书、一个红色印章、一个绿色印章。遇到符合要求的，盖绿章放行；遇到不符的，盖红章退回。这条流水线的聪明之处在于：规则一旦定死，任何两个质检员来查，结果都一模一样。确定性评估正是照着这个思路设计的——它把“模型输出是否符合预期”变成了一道不需要情商、不需要灵感的判断题。

放到工程里，确定性评估指的是：用代码预先定义一套判定规则，把LLM的输出当作输入喂进去，规则自动给出通过或失败的结论。这些规则可以是字符串完全相等、子串包含、正则匹配、JSON结构校验，等等。它不依赖人类打分，也不依赖另一个大模型来“点评”，所以每次运行结果稳定可复现，这在发布流程和自动化测试中尤其宝贵。

在搭建评估套件时，我们通常会准备一批“输入+预期输出”的测试用例，跑一遍模型，再用规则逐个比对，最后统计通过率。通过率是衡量这套评估是否放行的核心数字，也是回归测试中最直观的报警器。

老张的检测台告诉我们一个道理：评估不一定非要“智能”，把规则写清楚，机器就能替你守住质量关卡。确定性评估是整套LLM评估体系里最朴素、也最扎实的一环，所有花哨的主观打分，最后都要回归到这一张张可复现的红绿章上。

测试设计：检查清单从哪来

老张刚上岗时，老师傅给了他一份手写清单：“开机查电源，屏幕查划痕，按键查回弹，包装查封条。”这份清单就是工厂几百次事故后总结出来的智慧。测试设计在确定性评估中的地位，和这份清单一模一样——它决定了你的评估覆盖了哪些风险，又会漏掉哪些风险。

设计一套好的确定性评估测试集，需要手工构造有代表性的输入，再为每个输入标注一个确定性的“预期输出”或“预期约束”。比如让模型抽取机票信息，你就要准备航班号、日期、城市名等样本，并预先写明答案。接下来要考虑覆盖策略：不仅要覆盖正常输入，还要覆盖边界情况（空字符串、超长文本、缺失字段），以及常见的“幻觉高发区”。把这些场景都写进用例，评估才不是走过场。

覆盖率和通过率是两回事：通过率衡量“做得对不对”，覆盖率衡量“查得全不全”。一个只包含三个简单用例的套件，哪怕通过率 100%，也不能说明系统可靠。

检查清单不是一天写成的。老张的清单会随流水线升级而增删，测试用例也一样：每发现一个新bug，就把它固化成一条新用例，让评估套件越来越厚，也越来越聪明。

精确匹配：游标卡尺式核验

老张桌上有一把游标卡尺，专门用来量那些必须分毫不差的零件。比如螺丝直径，图纸写 5.0mm，实际量出 4.9mm，哪怕只差零点一毫米，也直接退回。精确匹配（Exact Match）就是评估世界里的游标卡尺：把模型输出和预期输出逐字对比，完全一致才算通过，多一个空格、多一个标点都不行。

这种严苛适合用在输出空间已经被锁死的场景。比如让模型从一组固定选项里选择分类结果，或者让模型返回一个约定好的枚举值、状态码、ID。在这些场景里，答案本来就没有第二种写法，使用精确匹配既简单又高效。它的优点是零歧义、实现成本极低，几行代码就能完成。

但它的局限也很明显：LLM天生爱自由发挥。同一个意思它可能表达成“晴”或“晴天”，这时精确匹配就会误杀合格产品。所以在开放式问答、摘要生成这类本身就不存在唯一答案的任务里，精确匹配并不合适。

游标卡尺量得准，但只能量“硬尺寸”。生产线上那些需要灵活解读的环节，老张就得换上另一件工具——比如下一节要讲的放大镜检查法。

包含匹配：放大镜检查关键零件

有的零件不需要量整条边，只需要确认“这里有没有那个关键凸起”。老张于是戴上一只放大镜，在成品表面寻找图纸上指定的特征：有，就过；没有，就退。包含匹配（Contain Match）做的就是这件事——它不要求模型输出和参考答案一模一样，只要求“预期的关键内容确实出现在输出里”。

具体做法是用子串检查判断期望值是否包含在模型输出中。例如预期答案是“北京”，模型输出“今天北京晴转多云”，两者虽然不等同，但关键地点已经出现，就可以判定通过。这种规则特别适合实体核验类任务：地点是否被提到、某个专有名词是否出现、必答点有没有覆盖。它比精确匹配宽容得多，也更容易在真实场景里获得较高通过率。

包含匹配的代价是它只问“有没有”，不问“对不对”。如果用户要求模型“不要提竞品”，你却用包含匹配去查“竞品名是否出现”，判断逻辑反倒是反的。所以使用时要设计好判定方向，并结合业务规则一起使用——规则匹配往往不是一句简单的 in 操作，而是多个关键词、多条条件的组合判定。

放大镜能看到“有没有”，但看不到“结构对不对”。当老张面对一个需要组装的产品时，光看表面还不够，他必须拆开外壳检查内部结构——这正是结构校验的用武之地。

结构校验：按图纸核对内部构造

老张最怕的不是尺寸误差，而是产品内部“缺胳膊少腿”：外壳光亮，里面却少了关键零件。所以质检线上还有一道工序——结构校验。它不关心模型输出的措辞是否优美，只关心输出是不是一个合法的 JSON 对象、字段是否齐全、类型是否正确。

在LLM应用中，模型经常被要求输出结构化数据，比如 {"city": "北京", "temp": 25.0}。下游数据库、API 管道只认字段名和类型，一旦模型漏掉 temp 字段，或者把 temp 写成了字符串 "25.0"，程序就会崩溃。结构校验通过预先定义一份 Schema（模式清单），逐字段检查：字段必须存在，类型必须匹配，从而把“格式错误”提前拦截在进入业务系统之前。

这种校验方法的工程价值在于它非常稳定，并且能精确给出失败原因：是缺了字段，还是类型错了，是列表长度不对，还是嵌套结构不完整。调试时一眼就能定位问题，配合回归测试使用效果尤佳。

结构校验像是给产品套上了模具骨架，骨头正了，外壳再丑也能用。但有些场景里，老张还需要一个更灵活的图案比对器——能把“车牌号必须是一大写字母加数字”这种模式，直接打印成一张镂空模板。

正则验证：镂空模板盖章检查

老张有一块镂空模板，形状像“京A12345”这种固定模式。他不用逐字读车牌，只需要把模板往牌子上一盖，能看到完整形状露出来，就算对上。正则验证（Regex Match）就是这样的镂空模板：你写一个模式（Pattern），正则引擎去模型输出里扫描，看有没有子串能贴合这个模式。

正则验证擅长处理“格式类”约束。比如校验邮箱格式、手机号区域号、航班号规则、订单编号是否由 3 个大写字母和 6 位数字组成。常用的正则语法包括字符类 [A-Za-z0-9]、量词 {3}、锚点 ^ 和 $ 等。例如模式 [A-Z]{3}\d{6} 能匹配“ABC123456“，从而让”抽出订单号”这类任务拥有了一个精确的验货规矩。

使用正则时要警惕两个陷阱：一是忘记转义，点号 . 在正则里代表任意字符，想匹配真实的小数点必须写成 \.；二是锚点缺失，\d{6} 可以匹配 "abc123456xyz" 中的数字片段，如果要求整体格式，就必须用 ^ 和 $ 锁死首尾。边界处理不当，很容易产生“你以为查完了，实际只查了一半”的误判。

镂空模板再精巧，也只能查一种图案。真正让老张安心的，是那本越来越厚的“历史缺陷档案”——每次改完流水线，他都要把档案里的老问题重新验一遍。这就是回归护航。

回归护航：永不删档的缺陷档案

老张的抽屉里锁着一本泛黄的档案，记录着建厂以来所有出过事故的产品类型。每次流水线调整后，他都要把这本档案里的案例重新检查一遍，确保老毛病没有复发。回归测试（Regression Testing）在LLM工程里做的正是这件事：把过去积累的测试用例保存成回测套件，每次模型更新、提示词修改、系统升级后，都重新跑一遍。

这套做法的价值在于“防回退”。LLM 是概率模型，改动一个 Prompt 可能让新任务表现更好，却悄悄破坏了旧任务。比如你优化了摘要生成的指令，结果函数调用变得不再遵守 JSON 格式。如果没有回归套件，这类问题往往要等到线上用户投诉才发现。有了回归测试，发布前就能自动拦截。

工程落地上，通常把回归测试接入持续集成（CI）流水线：每次提交代码或更新模型权重，自动执行评估套件，失败则阻断发布并推送预警。测试用例还会随着线上事故不断补充，形成“发现一个问题，固化一条用例，永久守护一个场景”的正循环。

老张的档案越厚，工厂翻车的概率越小。确定性评估的终极形态，就是把这本档案变成一套自动化、持续运行的守护机制——让每一次模型迭代都有迹可循、有例可查、有章可守。

AI 应用场景

Python 演示

"""确定性评估演示: 为 LLM 输出做固定规则校验"""import jsonimport re  class DeterministicEval:    def __init__(self):        self.results = []        self.total = 0     def register(self, name, gold, pred, mode="exact"):        self.total += 1        if mode == "exact":            ok = self._check_exact(gold, pred)        elif mode == "contain":            ok = self._check_contain(gold, pred)        elif mode == "regex":            ok = self._check_regex(gold, pred)        else:            ok = self._check_json_struct(gold, pred)        self.results.append((name, ok))     def _check_exact(self, gold, pred):        return gold.strip() == pred.strip()     def _check_contain(self, gold, pred):        return gold in pred     def _check_regex(self, pattern, pred):        return bool(re.search(pattern, pred))     def _check_json_struct(self, schema, pred):        try:            obj = json.loads(pred)        except json.JSONDecodeError:            return False        return all(k in obj and isinstance(obj[k], t) for k, t in schema.items())     def report(self):        passed = sum(1 for _, ok in self.results if ok)        print("passed = %d/%d, rate = %.1f%%" % (passed, self.total, passed * 100.0 / self.total))  if __name__ == "__main__":    ev = DeterministicEval()    ev.register("exact-pass", "晴", "晴", mode="exact")    ev.register("exact-fail", "多云", "晴天", mode="exact")    ev.register("contain-pass", "北京", "今天北京晴", mode="contain")    ev.register("regex-pass", r"[A-Z]{3}\d{3}", "航班SHA-123", mode="regex")    ev.register("json-pass", {"city": str, "temp": float}, '{"city":"北京","temp":25.0}', mode="json")    ev.register("json-fail", {"city": str, "temp": float}, '{"city":"北京"}', mode="json")    ev.report()

1. def register(self, name, gold, pred, mode="exact")注册一条测试用例，记录名称、预期值、模型预测和校验模式。
2. ok = self._check_exact(gold, pred)调用严格相等判定，不处理任何模糊匹配。
3. return gold.strip() == pred.strip()先掐头去尾再去比较，避免首尾空格干扰判定。
4. return gold in predPython 原生的子串检查，判断预期内容是否出现在输出中。
5. return bool(re.search(pattern, pred))用正则引擎扫描文本，存在匹配则返回 True。
6. json.loads(pred)把模型输出的 JSON 字符串解析成 Python 对象，为结构校验做准备。
7. all(k in obj and isinstance(obj[k], t) for k, t in schema.items())逐字段核对存在性和类型，任一不符则整体失败。
8. ev.register("json-fail", {"city": str, "temp": float}, '{"city":"北京"}', mode="json")注册一条缺少 temp 字段的用例，用于演示结构校验的拦截效果。

常见误区

面试题