LLM-08工程级14 min

模型评估:不只是 BLEU 和 ROUGE

LLM 时代,BLEU/ROUGE 已经不够用了。本文详解 LLM 评估的四大范式:自动评估(G-eval、MMLU)、RLHF 评估、人类评估、A/B测试,以及 RAG 场景的专用评估框架,帮助你在跨境电商项目中做出可靠的模型选择决策。

LLM评估G-evalRAG评估A/B测试

为什么 BLEU 和 ROUGE 不够了

BLEU(Bilingual Evaluation Understudy)和 ROUGE(Recall-Oriented Understudy for Gisting Evaluation)是比较生成文本和参考文本重叠度的指标,最初用于机器翻译评估。它们衡量的是字面重叠,不是语义质量。

LLM 时代的问题是:模型生成的优秀答案往往和任何一条参考文本都不一样(表达方式不同但意思相同),BLEU/ROUGE 会给低分;而一条"看起来正确但有幻觉"的回答,可能和某条参考文本高度重叠,反而得高分。

bleu_rouge_limit.py
from collections import Counter

def bleu_score(candidate, reference):
    cand_tokens = candidate.split()
    ref_tokens = reference.split()
    overlap = sum((Counter(cand_tokens) & Counter(ref_tokens)).values())
    return overlap / max(len(cand_tokens), 1)

candidate = "Nike Air Max 270 provides excellent cushioning for runners with its air unit"
reference = "Nike Air Max 270 跑步鞋采用气垫缓震技术,适合跑步爱好者"

bleu = bleu_score(candidate, reference)
print(f"BLEU 分数: {bleu:.3f}")
print("结论: 语义相关但中文参考下 BLEU 接近0 -> 不能反映真实质量")

high_quality = "Air Max 270 uses a large Air unit in the heel for cushioning"
ref1 = "Nike Air Max 270 缓震性能好,气垫踩上去很舒服"
low_quality = "Nike Air Max 270 is a popular Nike sneaker"

print(f"\n高质量答案 BLEU: {bleu_score(high_quality, ref1):.3f}")
print(f"低质量答案 BLEU:  {bleu_score(low_quality, ref1):.3f}")

BLEU/ROUGE 的适用场景:在有标准答案的受限任务上(如格式化输出、代码生成、标准化摘要),BLEU/ROUGE 仍有参考价值。但对于开放性问答、内容创作、对话系统等任务,请用 LLM-based评估或人工评估。

范式一:LLM-as-Judge(G-Eval)

G-Eval(OpenAI 2023)是目前最主流的 LLM 评估方法:用一个大模型(如 GPT-4)作为裁判,评估另一个模型的输出质量。评分维度通常包括:相关性、准确性、有帮助性、完整性。

核心流程:给裁判模型一个评分标准和待评估的回答,让它打分(通常1-5 分)并给出理由。可以用 CoT(Chain-of-Thought)让评分理由先输出,再汇总成最终分数。

g_eval.py
def g_eval_score(question, answer):
    scoring_criteria = """
评分维度(每项1-5分):
1. 准确性:回答中的事实是否正确
2. 相关性:回答是否针对用户问题
3. 完整性:回答是否覆盖了问题的各个方面
4. 可读性:表达是否清晰、简洁

评分规则:
- 4分:基本满意,有小缺陷
- 5分:优秀,全面准确
- 3分:有明显不足
- 1-2分:严重错误或完全不相关
"""
    prompt = f"""你是一个专业的 AI 评估专家。请评估以下回答的质量。

问题:{question}

回答:{answer}

{scoring_criteria}

请先说明每个维度的评分理由,最后给出总分(1-5)。
格式:
准确性:X/5 - 理由
相关性:X/5 - 理由
完整性:X/5 - 理由
可读性:X/5 - 理由
总分:X/5
"""
    return prompt

question = "Nike Air Max 270 的气垫能跑马拉松吗?"
answer_good = "Air Max 270 的气垫设计更适合日常跑步和训练,马拉松等专业长距离跑步建议选择专用的竞速跑鞋(如 Nike Vaporfly 系列),因为气垫缓震在长距离上可能偏硬。"
answer_bad = "Nike Air Max 270 是一款很流行的运动鞋,很舒适。"

print("G-Eval Prompt 示例:")
print(g_eval_score(question, answer_good))

范式二:标准 Benchmark(MMLU、HumanEval 等)

标准 benchmark 是模型能力的客观尺度,适合在不同模型之间做横向对比。几个关键 benchmark:

MMLU(Massive Multitask Language Understanding):57 个学科的选择题,覆盖数学、历史、法律、医学等,衡量模型的知识储备和推理能力。GPT-4o 达到约 88%,Claude3.5 Sonnet 约 88.7%。

HumanEval:LeetCode 编程题,衡量代码生成能力。GPT-4o 达到约 90%,Claude3.5 Sonnet 约 92%。

MATH:数学竞赛题,衡量复杂推理。约 40-50%(即使是顶级模型)。

benchmark_compare.py
benchmarks = {
    "MMLU": {
        "GPT-4o": 88.0, "Claude 3.5 Sonnet": 88.7,
        "Gemini-1.5-Pro": 85.9, "Qwen2.5-72B": 86.1
    },
    "HumanEval": {
        "GPT-4o": 90.2, "Claude 3.5 Sonnet": 92.0,
        "Gemini-1.5-Pro": 84.1, "Qwen2.5-72B": 79.3
    },
    "MATH": {
        "GPT-4o": 45.8, "Claude 3.5 Sonnet": 43.8,
        "Gemini-1.5-Pro": 42.3, "Qwen2.5-72B": 52.0
    }
}

print("主流模型 Benchmark 对比:")
for benchmark, scores in benchmarks.items():
    print(f"\n{benchmark}:")
    for model, score in sorted(scores.items(), key=lambda x: x[1], reverse=True):
        bar = "=" * int(score / 2)
        print(f"  {model:<25}: {score:>5.1f} {bar}")

Benchmark 的局限:Benchmark衡量的是通用能力,不反映你的垂直场景效果。一个 MMLU 98% 的模型,在跨境电商产品分析上可能不如专门微调过的 80% 模型。所以 Benchmark 是选型的参考,不是最终决策依据。你的业务数据上的实测永远比 Benchmark 更重要。

范式三:RAG 专用评估框架

RAG 系统的评估比纯生成任务更复杂,需要拆解成两个独立维度:

检索质量:Context Precision@K、Context Recall@K。衡量召回的 chunks 中有多少是真正相关的(Precision),以及所有相关 chunks 中有多少被成功召回(Recall)。

生成质量:Faithfulness(答案是否忠实于召回的上下文)、Answer Relevance(答案是否针对用户问题)。

rag_evaluation.py
def context_precision_at_k(retrieved_chunks, relevant_chunks, k=5):
    if k == 0:
        return 0.0
    relevant_retrieved = sum(1 for chunk in retrieved_chunks[:k] if chunk in relevant_chunks)
    return relevant_retrieved / k

def context_recall_at_k(retrieved_chunks, relevant_chunks, k=5):
    if not relevant_chunks:
        return 1.0
    relevant_retrieved = sum(1 for chunk in retrieved_chunks[:k] if chunk in relevant_chunks)
    return relevant_retrieved / len(relevant_chunks)

retrieved = ["chunk_A", "chunk_B", "chunk_C", "chunk_D", "chunk_E"]
relevant = ["chunk_A", "chunk_C"]


precision = context_precision_at_k(retrieved, relevant, k=5)
recall = context_recall_at_k(retrieved, relevant, k=5)

print(f"Context Precision@5: {precision:.2f}")
print(f"Context Recall@5: {recall:.2f}")

print("\n不同 k下的 Precision/Recall:")
for k in [1, 3, 5, 10]:
    p = context_precision_at_k(retrieved, relevant, k)
    r = context_recall_at_k(retrieved, relevant, k)
    print(f"  k={k:>2}: Precision={p:.2f}, Recall={r:.2f}")

RAGAS:轻量级 RAG 评估指标

RAGAS(Retrieval-Augmented Generation Assessment)是一个轻量级的 RAG 评估框架,只需要 LLM API,不需要人工标注 ground truth。它定义了三个核心指标:

Answer Faithfulness:给定上下文,答案中的每个陈述是否都能从上下文中找到支持。防止模型在上下文中"找不到答案就编造"。

Answer Relevance:给定问题和答案,评估答案对问题的针对性和完整性。如果答案正确但不完整或答非所问,这个分数会低。

ragas_score.py
def faithfullness_score(context, answer):
    context_set = set(context.lower().split())
    answer_set = set(answer.lower().split())
    coverage = len(context_set & answer_set) / max(len(answer_set), 1)
    return min(coverage * 1.2, 1.0)

def answer_relevance_score(question, answer):
    q_words = set(question.lower().split())
    a_words = set(answer.lower().split())
    overlap = len(q_words & a_words) / max(len(q_words), 1)
    return min(overlap * 1.5, 1.0)

context = "Nike Air Max 270 has Air Max cushioning, weighs 280g, uses mesh upper for breathability"
answer_good = "Air Max 270 uses Air Max cushioning and mesh upper for breathability, weighs 280g"
answer_bad = "Nike Air Max 270 is a great shoe. It looks nice and many people like it."

for label, ans in [("好的回答", answer_good), ("差的回答", answer_bad)]:
    fs = faithfullness_score(context, ans)
    ar = answer_relevance_score("Nike Air Max 270 specs?", ans)
    print(f"{label}:")
    print(f"  Faithfulness: {fs:.2f}, Answer Relevance: {ar:.2f}")

范式四:A/B 测试

无论多少 benchmark 和评估框架,最终在生产环境上验证的唯一可靠方式还是 A/B 测试。A/B 测试的核心是:控制其他变量,只改变模型/prompt/策略,观测下游业务指标(转化率、满意度、响应准确率)的变化。

跨境电商场景的 A/B 测试指标:

· 直接指标:回答采纳率(用户是否按 AI建议操作)、幻觉投诉率
· 间接指标:用户停留时长、转化率、工单解决率
· 成本指标:平均每次调用的 token 消耗

ab_test.py
import numpy as np
from scipy import stats

def ab_test(control, treatment, metric_name="转化率"):
    c_mean = np.mean(control)
    t_mean = np.mean(treatment)
    lift = (t_mean - c_mean) / c_mean * 100
    t_stat, p_value = stats.ttest_ind(treatment, control)
    significant = p_value < 0.05
    return {
        "control_mean": c_mean,
        "treatment_mean": t_mean,
        "lift_pct": lift,
        "p_value": p_value,
        "significant": significant,
        "conclusion": "显著提升" if significant and t_mean > c_mean else
                     "显著下降" if significant and t_mean < c_mean else "无显著差异"
    }

np.random.seed(42)
control_responses = np.random.normal(0.12, 0.03, 1000)
treatment_responses = np.random.normal(0.135, 0.03, 1000)

result = ab_test(control_responses, treatment_responses, "产品推荐采纳率")
print("A/B 测试结果:")
print(f"  控制组均值: {result['control_mean']:.3f}")
print(f"  实验组均值: {result['treatment_mean']:.3f}")
print(f"  提升: {result['lift_pct']:+.2f}%")
print(f"  p-value: {result['p_value']:.4f}")
print(f"  结论: {result['conclusion']}")

A/B 测试的最小样本量:跨境电商场景的转化事件相对稀疏(转化率通常 1-5%),要达到统计显著(p < 0.05)需要较大的样本量。粗略估算:如果 baseline转化率是 3%,想检测 10% 的相对提升(3.3%),每组至少需要约 15,000 个样本。样本量不够的 A/B 测试结论不可信。

跨境电商场景的评估指标设计

通用 benchmark 和通用评估框架是基础,但你的业务指标才是最终目标。跨境电商 LLM 应用的评估应该分层设计:

ecommerce_eval_design.py
def ecommerce_eval_design():
    layers = [
        {
            "layer": "L1: 底层能力",
            "what": "模型在标准任务上的表现",
            "how": "MMLU、HumanEval、Math benchmark",
            "metric": "准确率/正确率",
            "cadence": "每次换模型时测一次"
        },
        {
            "layer": "L2: 任务能力",
            "what": "在电商任务上的端到端表现",
            "how": "G-Eval + 人工抽样评估",
            "metric": "任务完成率/格式准确率",
            "cadence": "每周抽100条"
        },
        {
            "layer": "L3: RAG 检索",
            "what": "召回质量(检索是否精准)",
            "how": "Context Precision@5, Recall@5",
            "metric": "Precision/Recall",
            "cadence": "每次知识库更新后测"
        },
        {
            "layer": "L4: 业务指标",
            "what": "实际业务产出(用户是否满意)",
            "how": "A/B 测试",
            "metric": "转化率/采纳率/投诉率",
            "cadence": "持续运行"
        }
    ]
    return layers

for layer in ecommerce_eval_design():
    print(f"【{layer['layer']}】")
    print(f"  评估什么: {layer['what']}")
    print(f"  怎么测: {layer['how']}")
    print(f"  指标: {layer['metric']}")
    print(f"  频率: {layer['cadence']}\n")

关键结论

· BLEU/ROUGE 适合受限任务:格式化输出、代码生成。不适合开放性问答和内容生成
· G-Eval 是 LLM 评估的主流:用大模型做裁判,CoT 评分,自动且可复现
· Benchmark 是选型参考,不是最终决策:你的业务数据上的实测永远比通用 benchmark 更重要
· RAG 评估要分层:检索质量(Precision/Recall)和生成质量(Faithfulness/Relevance)分开测
· A/B 测试是生产验证的唯一可靠方式:需要足够的样本量才有统计意义,跨境电商转化率低需要大样本
· 分层评估:底层能力 → 任务能力 → RAG 检索 → 业务指标,逐层验证才能确保最终效果