为什么需要 Evals:从"能跑"到"够好"

一个熟悉的故事

假设你做了一个问答机器人。你在本地试了 10 个问题,回答都像模像样。你兴奋地发布,一周后,用户反馈堆积如山:

• "问它今天星期几,它说'我无法访问实时信息',但三天前明明能回答。"
• "同一个问题,早上问和下午问答案不一样。"
• "产品上线后成本翻倍,没人知道为什么。"
• "新换的模型版本在某个细分场景突然全线崩溃。"

这不是技术不够好,这是你在盲飞。你没有仪表盘,也没有刻度——这正是 Evals 要解决的问题。

什么是 Evals

Vibe Check 为什么不够

Vibe check(凭感觉测)是每个 LLM 项目的起点,也是很多团队的终点。它之所以致命:

Evals 和传统软件测试的本质差异

传统测试是确定性的:assert add(2, 3) == 5。LLM 是概率性的:同一个输入可能生成 5 种合理的回答,也可能生成 1 种看似合理实则错误的回答。这带来 3 个根本区别:

评估金字塔:从单元到生产

完整的 Evals 体系是分层的,每一层解决不同的问题。最底层快、便宜、覆盖广;最顶层慢、贵、最接近真实。

什么时候开始写 Evals

一个流传甚广的错误观念:"等我做完 MVP 再做 Evals"。事实是:

更务实的推进节奏:

1. Day 1: 写 5-10 条手工 eval,覆盖你最在乎的 happy path 和 1-2 个边界。用 Python assert 或 pytest 就够。
2. 第 1 周: 扩到 30-50 条,引入一个 LLM-as-Judge 作为辅助指标。开始用 Promptfoo / Braintrust。
3. 第 1 月: 从真实日志采样构建 golden set(100+ 条),分层(easy/medium/hard)。CI 集成,PR 自动跑回归。
4. 上线后: 接入生产 trace,做采样评估;用 thumbs up/regenerate 作为隐式信号;跑 A/B 实验。
5. 长期: 评估集和模型一起进化。新 bug 先进 eval set,再修代码(TDD 思维)。

一个最小可行的 Evals 例子

先感受一下"最朴素的 eval"长什么样。下面是一个情感分类任务的 10 行代码评估:

# eval_sentiment.py — 最小可行 eval
from openai import OpenAI
client = OpenAI()

# 评估集:输入 + 期望标签
cases = [
    ("这部电影太棒了,值回票价", "positive"),
    ("浪费了两个小时,剧本稀烂", "negative"),
    ("还行吧,没什么惊喜也没什么雷点", "neutral"),
    # ... 假设共 50 条
]

def classify(text):
    rsp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "只返回一个词:positive/negative/neutral"},
            {"role": "user", "content": text},
        ],
    )
    return rsp.choices[0].message.content.strip().lower()

correct = sum(classify(t) == label for t, label in cases)
print(f"accuracy = {correct}/{len(cases)} = {correct/len(cases):.1%}")

这 20 行代码已经战胜了 vibe check。你可以:

• 改 prompt,重跑,看准确率变化
• 换模型(gpt-4o vs gpt-4o-mini),直接对比
• 发现 bad case,加进评估集,永不再犯

本章小结

下一章我们进入指标设计:准确率不够用时,该怎么测"生成式"任务的好坏?