大模型评测（LLM Evals）：为什么你的 AI 应用上线前必须做这件事

如果你做过 AI 应用，一定有过这种错觉：本地试聊几句，模型回答得头头是道，感觉「成了」。可一上线，用户随便问个边界问题，它就开始胡说、格式崩坏、甚至把上周还好好的功能改坏了。

问题不在模型，在于你从来没用「可量化的标准」测过它。大模型评测（LLM Evals）就是解决这件事的：用一组带标准答案的题，自动跑、自动打分，把「行不行」变成数字。

为什么需要 Evals

靠人肉试聊有三个致命短板。第一是回归陷阱：你优化了一个 prompt，自己手感更好了，但可能悄悄搞砸了之前能答对的三类问题——没有对照基线，你根本发现不了。第二是规模：你不可能把上千种用户问法都手动试一遍。第三是幻觉难察觉：答案看起来通顺，事实却是错的，人眼抽查很容易漏。Evals 把「主观感觉」换成「可回归的指标体系」，每次改动都能看到分数涨跌。

Evals 的基本结构

一套最小可用评测由四步串起来：准备数据集（输入 + 参考标准）、用被测模型跑出回答、用评分器打分、最后聚合出指标。评分器本身可以是硬规则、可以是另一个模型当裁判，也可以人工抽检。

一个最小可运行的例子

最朴素也最稳的做法，是用单元测试的框架（如 pytest）把「期望」写死：

import pytest

cases = [
    {"q": "中国的首都是哪？", "expect": "北京"},
    {"q": "1+1 等于几？", "expect": "2"},
]

def call_model(q: str) -> str:
    # 这里换成你真实的模型调用
    return "北京" if "首都" in q else "2"

@pytest.mark.parametrize("c", cases)
def test_basic(c):
    got = call_model(c["q"])
    assert c["expect"] in got, f"期望含 {c['expect']}，实际 {got}"

当你的场景变复杂（开放问答、长文本），再用「模型当裁判」（LLM-as-Judge）给定评分标准来打分，把分数也接进这套 pytest，就能在 CI 里跑回归。

取舍与边界

• LLM 裁判有偏见：它会偏爱长答案、会被措辞带偏，且每次调用要花钱、有延迟。关键场景一定要留人工抽检兜底。
• 小样本不代表全量：十道题全过，不等于线上万级流量没问题；数据集要持续收集真实 bad case 扩充。
• 先建基线再优化：没基线前别乱调 prompt，否则你永远不知道改动是变好还是变坏。
• 指标要分层：整体通过率之外，最好拆出「格式正确率」「事实准确率」「拒答恰当率」，定位问题更快。

Tips

• 把最容易出错的 20 个真实问题整理成数据集，接进 pytest 跑通。
• 把评测接进 CI：每次改 prompt / 换模型，分数掉就拦下。
• 开放问答类问题，引入 LLM-as-Judge，但保留 5% 人工抽检。
• 线上一旦出现 bad case，立刻收录进数据集，让评测集跟着业务长。
• 别追求「一个总分」，按格式 / 事实 / 安全分维度看，问题才好修。