LLM 评估：从 MMLU 到真实业务

L4 之前我们都在讲”怎么做” LLM 应用。 这一篇讲一个等价重要的问题——怎么知道你做得好不好？

LLM 评估是工程界最被忽视、却最关键的工作之一。

评估的难度

传统 ML 评估简单—— 分类任务有”准确率”、回归有”MSE”。

LLM 不一样：

• 同一个问题有多个对的回答
• “好”是主观的（流畅度、有用性、安全）
• 评估本身可能比模型还贵
• 评估指标随业务变化

没有”一个数字定输赢”。

三个层次的评估

层次 1：学术 Benchmark

固定数据集 + 标准指标。 适合对比模型。

Benchmark	测什么
MMLU	通用知识（57 学科）
GSM8K	数学应用题
HumanEval	Python 编程
MATH	数学竞赛
HellaSwag	常识推理
TruthfulQA	真实性
MT-Bench	多轮对话质量
AlpacaEval	指令遵循
Arena (LMSYS)	真实用户偏好
MMLU-Pro	升级版 MMLU
GPQA	PhD 级问答
SWE-bench	真实代码修复

每个 benchmark 测不同维度——没有单一”GPT 比 Claude 强”的答案。

层次 2：业务 Benchmark

针对你的具体应用——定制评估。

例：客服机器人——

评估 1: 准确率（回答是否正确）
评估 2: 简洁度（不啰嗦）
评估 3: 礼貌度
评估 4: 拒绝率（合理拒绝？过度拒绝？）
评估 5: 一致性（多次问相同问题，答案一致？）
评估 6: 速度（响应延迟）
评估 7: 成本（每次调用 token 数）

每个都需要自己收集数据 + 设计指标。 这是真正决定产品好坏的层次。

层次 3：用户反馈

真实用户在用——最终评判者。

• Thumbs up / down 率
• 用户留存
• 用户 NPS
• 客户支持工单数（产品出问题的 proxy）

线上数据 > 线下评估——但慢、噪声大、不可控。

学术 Benchmark 的局限

1. 数据污染

很多 benchmark 在模型训练数据里出现过—— 模型见过题，自然能答。

MMLU 在 2020 年后大模型上已经”饱和”—— 99% 准确率是过拟合，不是真懂。

2. 风格 vs 能力

某些 benchmark 测”是否答 A/B/C/D 选项”—— 模型可能学到选 A 多但其它正确性低。

3. 单一格式

benchmark 数据格式固定—— 模型可能”格式拟合”，对真实多变输入鲁棒性差。

4. 静态

benchmark 不更新—— 模型能力变化它跟不上。

主流”现代”评估方式

1. LMSYS Arena（Chatbot Arena）

让真人盲测两个模型—— 统计胜率（Elo 评分）。

这是当前最被认可的评估—— 因为它是人类真实偏好，不是机器分数。 但极慢极贵。

2. LLM-as-a-Judge

让另一个 LLM（通常 GPT-4）当裁判：

def evaluate(prompt, response_a, response_b):
    judge_prompt = f"""
    Question: {prompt}
    Response A: {response_a}
    Response B: {response_b}

    Which is better, A or B? Why?
    """
    return gpt4(judge_prompt)

自动化 + 接近人类判断—— 但偏向”风格相似的模型”——GPT-4 当 judge 倾向给 GPT-style 回答高分。

3. AlpacaEval / MT-Bench

固定题库 + LLM judge 自动评估—— 结果接近人类 Arena 但便宜得多。

4. Held-out 自动指标

针对特定任务（如翻译、摘要）的自动指标：

• BLEU (翻译)
• ROUGE (摘要)
• BERTScore (语义相似度)
• F1 (问答)

便宜 + 客观，但不一定反映真实质量。

评估你的 LLM 应用

实战中评估你的 RAG / Agent / 对话产品：

步骤 1：定义评估维度

针对你的产品，列出关心的维度：

产品	关心
客服 bot	准确、简洁、礼貌、拒绝合理
代码助手	代码正确、能跑、风格一致
总结工具	覆盖关键点、不丢失、忠实
创意写作	有趣、原创、连贯

步骤 2：构建评估集

收集有代表性的输入：

评估集大小：
- 起步：50 个样本
- 严肃：200-500 个
- 产品级：1000-5000 个

包括：
- 典型 case (60%)
- 边角 case (20%)
- 对抗 case (10%)
- 出错回归 case (10%)

手工 + AI 合成混合构建—— 不要全 AI 生成（同质化），也别全人工（贵慢）。

步骤 3：定义”参考答案”或”评估准则”

两种思路：

A. 参考答案对比

每个输入有标准答案 — 计算相似度。 适合：客观任务（QA、翻译、计算）。

B. 评估准则

不定标准答案 — 定义”什么是好回答”的规则。 适合：主观任务（创意、对话）。

# 评估准则示例
criteria = {
    "factual_accuracy": "回答是否事实正确？",
    "relevance": "回答是否切题？",
    "conciseness": "回答是否简洁？",
    "tone": "回答是否礼貌？",
    "safety": "回答是否安全（无有害内容）？",
}

步骤 4：执行评估

用 LLM 当 judge：

from openai import OpenAI
client = OpenAI()

def evaluate_response(prompt, response, criteria):
    judge_prompt = f"""
    Evaluate this response against the criteria.
    Return JSON with scores 1-5 for each criterion.

    Prompt: {prompt}
    Response: {response}
    Criteria: {criteria}
    """
    result = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": judge_prompt}],
        response_format={"type": "json_object"}
    )
    return json.loads(result.choices[0].message.content)

跑遍评估集 → 算每个维度的平均分。

步骤 5：错误分析

比分数更重要的是—— 哪些 case 错了，为什么：

def analyze_errors(evaluation_results):
    errors = [r for r in evaluation_results if r["score"] < 3]

    # 用 LLM 分类错误类型
    for error in errors:
        category = classify_error(error)
        error["category"] = category

    # 统计：哪种错误最多
    print(Counter(e["category"] for e in errors))

错误模式告诉你最该改什么。

一个真实评估流程

某 RAG 客服产品的实际评估：

1. 评估集：500 个真实用户问题 + 标准答案
2. 评估维度：
   - 准确（GPT-4 judge）
   - 来源引用（自动检测）
   - 长度（自动统计）
   - 拒绝合理性（人工标 + LLM judge）

3. 跑评估：
   - 每天自动跑（CI 集成）
   - 改 prompt / 改 RAG → 立刻看分数
   - 关键指标：accuracy >= 85%, 拒绝率 < 5%

4. A/B 测试：
   - 用户被随机分两组
   - 5% 流量进新版本
   - 监控 thumbs up 率 / NPS / 续费率

5. 持续监控：
   - 生产环境每 100 个请求 sample 1 个
   - 人工抽检
   - 异常告警

这是工程化 LLM 应用的”评估栈”—— 没这套，你的产品质量靠运气。

自动评估的陷阱

1. LLM-as-Judge 的 bias

GPT-4 当裁判倾向：

• 偏好 GPT 风格回答
• 偏好长回答（不一定更好）
• 偏好”显得自信”的回答
• 第一个回答得分高（位置偏见）

应对：

• 多 judge ensemble
• 随机交换 A/B 顺序
• 用不同 judge 模型对比

2. 评估集污染

确保评估集不在训练数据里—— 否则模型”答得对”是因为见过。

3. 单维度优化

如果只看一个指标（如准确率）—— 其它维度会退化（变啰嗦、变机械）。

多维度评估永远必要。

4. 测试环境 ≠ 生产环境

实验室准确率 95% — 上线 70%？常见。 原因：

• 真实用户输入多变
• 时序数据漂移
• 长尾问题没在评估集里

线下评估是 indicator，不是 guarantee。

推荐工具

工具	用途
LangSmith（LangChain）	评估 + 追踪 LLM 应用
Helicone	监控 + 评估
Phoenix（Arize）	开源 LLM observability
RAGAS	RAG 专用评估
DeepEval	LLM 应用单元测试
lm-eval-harness	学术 benchmark 自动化
Promptfoo	A/B 测试 prompt

实战起步推荐：LangSmith 或 RAGAS（RAG 专用）。

评估的”哲学"

"评估比训练更难”

训模型有清晰目标（最小化 loss）—— 评估没有。你不知道你想要什么。

LLM 工程的核心能力之一——定义”好”是什么。

“好的评估塑造产品”

你测什么——你的团队就优化什么。 评估指标的选择本身就是产品策略。

“永远要人工 review”

自动评估再好—— 关键发布前必须人工抽样 review。 LLM judge 看不出的问题，人能看出。

下一篇推荐：L4-09 Tool Use 工程实战 或 L4-10 LLM 应用的成本管控。