街角要举办一年一度的“羊驼美食擂台赛”——组委会正是 AlpacaEval。规则很简单：每家 AI 餐厅用同一道考题（指令）做菜，首席品鉴官（通常由 GPT-4 扮演）把参赛者的菜端上来盲品，每道菜都要和总厨的招牌菜 PK 一场。赢一道记一胜，输一道记一负，平分秋色就算平局。比完几百道菜，记分员一算胜率，门口的排行榜立刻更新。这场擂台赛最妙的地方在于：首席品鉴官不要工资、不知疲倦，一次能连品几百道菜，成本比请人类美食家低了好几个量级。今天这篇文章，就是带你看懂这套“美食擂台赛”的里里外外——它的正式名字叫 AlpacaEval，是评估大模型“听不听话”（指令跟随能力）的自动评测框架，也是一张每天都在变的“厨艺排行榜”。

岗位关联

学会 AlpacaEval，你就能在模型选型、版本升级、提示词调优时，用一份自动化报告快速回答“新模型到底有没有变好”——这是 AI 评测工程师的必备基本功。

目录
  1. 可视化演示
  2. 评测动机
  3. 自动评估器
  4. 胜率机制
  5. 排行榜解读
  6. 低成本方案
  7. 端到端实践
  8. 局限与改进
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

LLM-as-Judge: GPT-4评判模型输出 GPT-4 JudgeLLM-as-Judge核心GPT-4 JudgeGPT-4 JudgeLLM-as-Judge核心GPT-4 Judge GPT-4 JudgeLLM-as-Judge核心GPT-4 JudgeGPT-4 JudgeLLM-as-Judge核心GPT-4 Judge

评测动机

办一场擂台赛之前，必须先回答“为什么要有这场比赛”。过去想知道一家餐厅好不好吃，要请十几位美食家（人类标注员）逐道试吃：备菜、试吃、讨论、写评语，一天最多评几十道，每人还得付一笔不菲的劳务费。所以很多餐厅干脆不参赛——测不起。AI 领域也一样：判断“模型是否听懂了指令”，最传统的方法是人工评测——标注员把模型的输出和参考答案摆在一起，逐条打分。几百条样本就要耗掉一整天，预算和时间双双告急。

于是“自动评估”应运而生：与其请人类美食家，不如让一位“信得过的大模型”来当裁判。GPT-4 因为输出质量最接近人类偏好，自然成了组委会眼中的“首席品鉴官候选人”。AlpacaEval 正是顺着这个思路诞生的评估框架：用 GPT-4 充当自动评估器，对模型的指令跟随输出进行成对比较，从而把“好不好”变成“胜不败”。

这套做法背后的成本账可以这样看：

一句话总结：人工评测是“请十个美食家吃一天”，AlpacaEval 则是“让一位不领工资的品鉴官连轴转”。前者让大多数团队望而却步，后者让“每周测一遍”成为可能。

Ctotal=N×(Clabel+Creview)C_{\text{total}} = N \times (C_{\text{label}} + C_{\text{review}})
评测总成本等于样本数量乘以“标注费 + 评审费”。人工评测时两项都是真金白银，自动评测则把评审费压到近乎为零。
  1. 评测总成本 $C_{\text{total}}$这是整个评测项目的总开销，单位可以折算成钱或工时，是整个公式的最终结果。
    CtotalC_{\text{total}}
  2. 样本数量 $N$需要评分的指令条数。N 越大，评测越全面，成本也跟着线性上涨。
    NN
  3. 单样本成本累加每条指令既要有人标出好答案，又要有专家评审打分，两种费用叠加在一起。
    Clabel+CreviewC_{\text{label}} + C_{\text{review}}

自动评估器

擂台赛的核心永远是裁判。AlpacaEval 的首席品鉴官每次收到两道菜：一道来自参赛模型（候选答案），一道是总厨的招牌菜（参考答案），两份用的是同一份考题（指令）。品鉴官不看店名、不知先后，只凭内容判断“哪道更好”。

技术上看，裁判是一个完整的 LLM（通常就是 GPT-4）。它要做的是“成对比较”：把同一个指令 $P$、候选模型的回答 $A$、参考模型的回答 $B$ 塞进同一个提示词，让它输出三选一的判词。这里的参考模型在官方基准里常选用 GPT-4-Turbo，早期版本则用 text-davinci-003。通过大量成对比较，我们就能把任意两个模型的输出质量排出先后——这就是“质量排序”。

整个判定过程可以写成：

有了这位不眠不休的裁判，组委会才能一口气品完几百道菜。裁判的每一次“举牌”，都是后续记分员写下胜、负、平的一笔。

J(P,A,B)→{A≻B, A≺B, A∼B}J(P, A, B) \rightarrow \{A \succ B,\ A \prec B,\ A \sim B\}
裁判函数 $J$ 吃进三元组（指令、候选答案、参考答案），吐出一个判词：要么候选胜，要么参考胜，要么双方平手。
  1. 裁判函数 $J$$J$ 代表自动评估器这个“函数”，它可以是 GPT-4，也可以是其他被指定的大模型；输入是文本，输出是判定。
    J(P,A,B)J(P, A, B)
  2. 输入三元组$(P, A, B)$ 三个参数缺一不可——没有考题 $P$，两道菜就无从比较；没有参考答案 $B$，就失去了擂台赛的“守擂方”。
    (P,A,B)(P, A, B)
  3. 三种判词$\succ$ 表示 A 胜，$\prec$ 表示 A 负（即 B 胜），$\sim$ 表示平局。每次比较必居其一。
    {A≻B, A≺B, A∼B}\{A \succ B,\ A \prec B,\ A \sim B\}

胜率机制

比完 100 道菜，记分员该出场了。他翻开记录本：这 100 场里，参赛餐厅赢了几道、输了几道、几道和总厨打成平手？赢的比例就是这位厨师的“擂台胜率”。

胜率的计算朴素而直接——胜场数除以总场数：

这里有一个关键前提：守擂方是谁。AlpacaEval 的基线（baseline）是固定的参考模型，所以所有参赛者的分数都锚定在“对 GPT-4 的胜率”上。只有当所有模型在同一期、同一条基线、同一套考题下比赛，榜单上的数字才可比——这是读懂所有排行榜的第一把钥匙。

WinRate=WW+L+T×100%\text{WinRate} = \frac{W}{W + L + T} \times 100\%
胜率 = 胜场 ÷ 总场数。50% 意味着和守擂方打成平手，60% 说明每 5 道菜里能赢 3 道。
  1. 胜场 $W$记分员数出判词为“候选胜”的场次数，这是胜率的分子。
    WW
  2. 总场数 $W + L + T$胜场、负场 $L$、平局场 $T$ 三者之和就是全部比赛场数，即评测样本总数 $N$。
    W+L+TW + L + T
  3. 胜率转化百分数用胜场除以总场数再乘以 100%，得到一个 0 到 100 之间的百分比，方便在排行榜上直接比较。
    WW+L+T×100%\frac{W}{W + L + T} \times 100\%

排行榜解读

擂台赛的终点，是门口那张花花绿绿的排行榜。组委会把每家餐厅的胜率从高到低排开，第一名就是本期的“羊驼厨神”。AlpacaEval 的排行榜结构类似：左边是模型名（参赛餐厅），右边是胜率（对基线 GPT-4 的战绩），按胜率降序排列，随时更新。

排名的数学含义很轻巧——谁比我强，我就往后让一位：

读榜时请记住：胜率是“相对分”而非“绝对分”。70% 比 60% 好，但 70% 只说明“在这批指令上，裁判更认可谁”。想要判断自家模型有没有进步，必须和旧模型同一期榜单、同一套考题对比。就像美食榜上的名次，换个评判标准就可能天翻地覆。

Ranki=∑jI[WinRate(Mj)>WinRate(Mi)]+1\text{Rank}_i = \sum_{j} \mathbb{I}\big[\text{WinRate}(M_j) > \text{WinRate}(M_i)\big] + 1
模型 $M_i$ 的排名，等于“胜率比它高的模型个数 + 1”。胜率最高的模型，比它高的个数为 0，所以稳坐第一。
  1. 单模型胜率 $\text{WinRate}(M_i)$每个参赛模型对应一个胜率数字，它是排名的唯一依据。
    WinRate(Mi)\text{WinRate}(M_i)
  2. 指示函数计数$\mathbb{I}[\cdot]$ 是一个“计数器”，括号里的条件成立记 1，不成立记 0；把 $j$ 遍历所有模型，就数出了“谁比我强”。
    I[WinRate(Mj)>WinRate(Mi)]\mathbb{I}\big[\text{WinRate}(M_j) > \text{WinRate}(M_i)\big]
  3. 排名加一比自己强的人数加 1，就是自己的名次；并列的模型会得到相同名次区域。
    ∑jI[⋅]+1\sum_{j} \mathbb{I}[\cdot] + 1

低成本方案

为什么羊驼擂台赛能天天办、周周更？因为请首席品鉴官几乎不花钱。人类美食家每人每天几千元，而 GPT-4 品一道菜（一次 API 调用）只要几分钱。更妙的是，不用给每道菜配“标准答案制作团队”——参考答案就是总厨顺手做的招牌菜。

AlpacaEval 的评测集设计得很精简：官方使用约 805 条指令样本，每条指令让候选模型和参考模型各生成一次回答，再由裁判做一次成对比较。也就是说，一次完整评测只需几百次 API 调用，几分钟就能出结果。不需要人工标注，不需要训练数据，不需要部署专门的服务。

成本差距可以写成：

这份“便宜”直接换来了“快”：上午微调完模型，下午就能跑完评测拿到胜率报表。对需要频繁迭代的团队来说，低成本不只是省钱，更是把“评测”从每周一次变成了想跑就跑的日常动作。

Cauto=N×CLLM≪N×ChumanC_{\text{auto}} = N \times C_{\text{LLM}} \ll N \times C_{\text{human}}
自动评测的成本是“样本数 × 单次 API 费”，远小于“样本数 × 人类专家工时费”。$\ll$ 的意思是“远远小于”。
  1. 自动评测总成本 $C_{\text{auto}}$左边这一串就是整场擂台赛的账单：样本数乘以每次调裁判的 API 费用。
    Cauto=N×CLLMC_{\text{auto}} = N \times C_{\text{LLM}}
  2. 人工评测总成本右边是传统做法的账单：同样 N 条样本，每条都要付人类专家标注和评审的工时费。
    N×ChumanN \times C_{\text{human}}
  3. 远小于符号 $\ll$$C_{\text{LLM}}$ 通常比 $C_{\text{human}}$ 低两到三个数量级，所以左式远小于右式。
    ≪\ll

端到端实践

现在把擂台赛搬进自家的 RAG 客服系统。你是一家生鲜电商的 AI 工程师，想让客服机器人更听话。过去的做法是攒一批人工好评测集，请运营同学加班打分，一周才出一版报告。有了 AlpacaEval，你可以这样办：第一步，构造“客服考题集”，把 FAQ 问答、订单查询、退货投诉、多轮追问等场景写成 100 条客服指令；第二步，让新旧两个客服模型（旧版 A 和新版 B）分别作答，同时收集 GPT-4 的参考回答；第三步，写评测脚本把三元组喂给裁判，逐条判定胜负。

把模型质量压缩成一个数字的公式如下：

跑完之后不要只看总分。把胜率按"FAQ"“投诉”“多轮”三个场景分别统计：如果新版模型在投诉场景胜率暴跌，说明它“学坏了”某个专项能力。就像擂台赛不仅要看总战绩，还要看川菜、粤菜各赢了几个菜式——分层分析，才能让排行榜真正服务于业务决策。

Q(M)=1N∑i=1NI[J(Pi,Mi,Ri)=胜]Q(M) = \frac{1}{N}\sum_{i=1}^{N} \mathbb{I}\left[ J(P_i, M_i, R_i) = \text{胜} \right]
$Q(M)$ 就是模型 $M$ 的最终质量分：在所有评测样本中，裁判判定“模型输出胜过参考答案”的占比——也就是前面说的胜率。
  1. 平均符号与质量分 $Q(M)$$\frac{1}{N}\sum$ 表示“把所有样本的得分加起来求平均”，$Q(M)$ 是模型最终拿到的质量分。
    Q(M)=1N∑i=1NQ(M) = \frac{1}{N}\sum_{i=1}^{N}
  2. 逐样本求和$i$ 从 1 跑到 $N$，每个样本贡献 0 或 1 分，全部累加。
    ∑i=1NI[⋅]\sum_{i=1}^{N} \mathbb{I}[\cdot]
  3. 判定条件$J(P_i, M_i, R_i) = \text{胜}$ 表示“对第 $i$ 条指令，裁判认为模型回答胜过了参考回答”。
    J(Pi,Mi,Ri)=胜J(P_i, M_i, R_i) = \text{胜}

局限与改进

擂台赛再热闹，也要小心裁判的偏心。研究者和社区发现，GPT-4 这类品鉴官有个明显的“审美偏好”：喜欢摆盘复杂、分量大的菜——对应到文本，就是回答更长的输出更容易被判胜，这叫长度偏差（length bias）。此外还有位置偏差：两道菜端上来的先后顺序可能影响判定；以及裁判自身的偏差：换一位裁判，也许结论就变了。

长度偏差可以建模成一个简单的校正公式：

对抗这些偏差，组委会常用的改进方向有五条：交换 A/B 答案顺序各评一次取平均（抵消位置偏差）、限制输出最大长度（压缩长度偏差）、换用不同裁判模型交叉验证（稀释裁判偏差）、扩大评测样本集（减小随机噪声）、结合人工抽检（守住底线）。毕竟，擂台赛的意义不是让裁判封神，而是让每一道菜都被公平地品尝。

WinRateadj=WinRate−α×LenBias\text{WinRate}_{\text{adj}} = \text{WinRate} - \alpha \times \text{LenBias}
校正后胜率 = 原始胜率 − 长度偏差惩罚项。$\alpha$ 是惩罚力度，$\text{LenBias}$ 是长回答带来的虚高部分。
  1. 校正后胜率 $\text{WinRate}_{\text{adj}}$这是扣除裁判偏见后的“真实成绩”，比原始胜率更值得信任。
    WinRateadj\text{WinRate}_{\text{adj}}
  2. 长度偏差惩罚项 $\alpha \times \text{LenBias}$$\text{LenBias}$ 量化裁判对长答案的偏好程度，$\alpha$ 控制我们愿意多狠地扣掉这部分虚高。
    α×LenBias\alpha \times \text{LenBias}
  3. 整体相减用原始胜率减去惩罚项，得到一个更保守、更诚实的分数。
    WinRate−α×LenBias\text{WinRate} - \alpha \times \text{LenBias}

AI 应用场景

RAG 客服系统的模型选型

阶段：模型评测与选型

解决的问题：RAG 客服系统要从多个候选大模型里选一个上线。传统做法是组织人力逐条对比回答质量，耗时数天且主观性强。AlpacaEval 用一套客服考题集 + GPT-4 裁判，两小时内给每个候选模型打出对 GPT-4 的胜率，把选型从“开会争论”变成“看数据说话”。

具体案例：某电商团队在 Llama-3.1-8B、Qwen-2.5-7B、GPT-4o-mini 三个候选项中纠结。他们构造了 120 条客服指令（FAQ、订单、投诉、多轮），用 AlpacaEval 流程分别评测，最终选出的模型在投诉场景胜率领先 12 个百分点，上线后人工质检好评率同步提升。

微调版本回归测试

阶段：模型迭代与回归

解决的问题：模型微调后贸然上线，可能在某些指令上“偏科”。传统回归测试需要维护庞大的人工标注集。AlpacaEval 提供轻量快速的对比通道：微调前后两个版本在同一指令集上 PK，用胜率变化确认“改好了哪些、改坏了哪些”。

具体案例：一家金融科技公司给客服模型做了指令微调，用 AlpacaEval 对比新旧版本，发现整体胜率提升 8%，但“拒答类”指令胜率下降 15%，及时回滚并补充了拒答样本数据。

提示词模板调优

阶段：提示词工程与效果验证

解决的问题：同一模型在不同提示词模板下表现差异巨大，人工逐个试错成本高。AlpacaEval 的成对比较机制天然适合“模板擂台赛”：两个模板的输出互相对战，让裁判选出更优者。

具体案例：某团队为 RAG 系统设计答案润色提示词，收集了 5 个模板，互相做两两对比，发现“先引用证据再下结论”的模板胜率最高，最终被写入线上配置。

Python 演示

python39 行
# -*- coding: utf-8 -*-"""simplified AlpacaEval: use a judge model to compare candidates with GPT-4."""import random PROMPTS = [    "用一句话解释什么是检索增强生成",    "写一封请假邮件给主管",    "把这句话改得更礼貌: 给我水",] def generate_response(model, prompt):    """Generate a response; replace with a real LLM API in practice."""    if model == "gpt4":        return "参考版: 对[" + prompt[:8] + "]的完整回答"    return "候选版: 对[" + prompt[:8] + "]的简洁回答" def judge(candidate, reference, prompt):    """Judge output; replace with a GPT-4 judge API in practice."""    return random.choice(["candidate", "reference", "tie"]) def alpaca_eval(candidate_model="my_model", ref_model="gpt4", prompts=None):    prompts = prompts or PROMPTS    results = []    for i, p in enumerate(prompts, 1):        cand = generate_response(candidate_model, p)        ref = generate_response(ref_model, p)        verdict = judge(cand, ref, p)        results.append({"round": i, "prompt": p, "verdict": verdict})        text = {"candidate": "胜", "reference": "负", "tie": "平"}[verdict]        print("第 %d 轮: 候选模型%s" % (i, text))    wins = sum(1 for r in results if r["verdict"] == "candidate")    ties = sum(1 for r in results if r["verdict"] == "tie")    win_rate = wins / len(results) * 100    print("总轮数: %d, 胜场: %d, 平局: %d" % (len(results), wins, ties))    print("候选模型 vs GPT-4 胜率: %.1f%%" % win_rate)    return win_rate if __name__ == "__main__":    alpaca_eval()
目的：用最小可运行脚本演示 AlpacaEval 的核心流程——收集双方输出、裁判逐条判定、统计并输出胜率。真实使用时，只需把 generate_response 和 judge 换成真实的模型 API 调用。
  1. def judge(candidate, reference, prompt):定义裁判函数，真实场景这里应调用 GPT-4 判官接口，返回三选一判词
  2. verdict = judge(cand, ref, p)核心一步：对同一条指令的两份回答做一次成对比较，得到“胜/负/平”
  3. results.append({"round": i, "prompt": p, "verdict": verdict})把每一轮的判定结果存档，相当于记分员的记录本
  4. wins = sum(1 for r in results if r["verdict"] == "candidate")统计总胜场，只数判词为“候选胜”的记录
  5. win_rate = wins / len(results) * 100胜率公式的落地：胜场除以总轮数再转成百分数

常见误区

误区新人看到排行榜上某模型胜率 55%，立刻得出结论：“它比 GPT-4 更强！”然后在汇报里大张旗鼓地宣传，仿佛已经超越了行业标杆。

正解胜率是“相对基线的擂台成绩”，不是绝对质量。55% 只说明在这批指令上，裁判（GPT-4）更常认可它的回答。评测集只有几百条指令，样本有限，加上裁判自身存在偏差，几个百分点的差距很可能落在噪声范围内。就像擂台赛只比了 100 道菜，代表不了全部菜系。

为何常见：排行榜把复杂的质量压缩成一个数字，人天生喜欢“越高越好”的简单解读，忽略了数字背后的比较基准。

误区听到名字里有"Alpaca"，以为是又一个开源羊驼模型大家族成员，想直接下载权重来部署，结果到处找不到模型文件。

正解AlpacaEval 是评估框架/基准，不是模型。它提供评测指令集、自动评估器（通常由 GPT-4 扮演）和排行榜体系。打个比方：它不是参赛的餐厅，而是办擂台赛、贴排行榜的组委会。想“用”它，不是部署它，而是调用它的评测流程。

为何常见：名字与斯坦福的 Alpaca 模型系列相似，加上 AI 圈“羊驼命名”盛行，很容易张冠李戴。

误区有同学发现长回答胜率更高，于是把 `max_tokens` 调大，甚至让模型先自我复述一遍再回答，强行把输出撑长，还得意地宣称发现了“刷榜技巧”。

正解这正是著名的长度偏差（length bias）：GPT-4 类裁判在盲评时容易被更长的答案迷惑，误以为“写得多 = 答得好”。AlpacaEval 官方社区也公开讨论过这一现象。正确做法是控制输出长度上限、交换答案顺序多评几次、用多个裁判交叉验证，而不是把“变长”当成优化目标。

为何常见：短期试出了正向反馈就急于复用，把裁判的“审美 bug”误当成模型的真实能力提升。

误区某个新模型在 AlpacaEval 排行榜上名列前茅，团队直接用它替换了线上的 RAG 客服模型，结果用户投诉率反而上升了，大家一脸茫然。

正解AlpacaEval 的指令集偏通用指令跟随，不一定覆盖客服垂直场景（FAQ、多轮追问、拒答话术）。RAG 场景必须先构造自己的评测集跑一遍，再结合线上指标（解决率、转人工率、满意度）综合决策。擂台上比的是“家常菜”，而你们餐厅主打“川菜”——榜单第一的厨师未必会做毛血旺。

为何常见：把“通用评测分数”直接等同于“线上业务效果”，跳过了领域适配这个关键步骤。

面试题

Q1. AlpacaEval 的核心定位是什么？

单选题 · easy

  • A.一个开源对话大模型
  • B.一套自动评估基准← 正确答案
  • C.一种数据清洗工具
  • D.一个参数高效微调法

答案：B。AlpacaEval 提供指令集、自动评估器和排行榜，本质是评估框架而不是模型。它像擂台赛组委会，负责组织比赛和发布榜单，而非亲自参赛。

Q2. AlpacaEval 中的“裁判”通常由什么担任？

单选题 · easy

  • A.人类专家评审团
  • B.正则表达式脚本
  • C.另一个大模型判官← 正确答案
  • D.随机抽样小程序

答案：C。自动评估器的核心思想是“用大模型评大模型”，官方常用 GPT-4 扮演裁判。它不需要人类参与，也不依赖规则脚本，而是靠 LLM 的语义理解做盲评。

Q3. 某模型参加 100 场评测，胜 40 场、平 20 场，它的胜率是？

单选题 · mid

  • A.30%
  • B.40%← 正确答案
  • C.50%
  • D.60%

答案：B。胜率 = 胜场 ÷ 总场数 = 40 ÷ 100 = 40%。平局计入总场数分母但不加分，所以不是 40 ÷ 80 = 50%，务必注意分母是全部评测样本。

Q4. AlpacaEval 排行榜主要按什么指标排序？

单选题 · mid

  • A.训练数据规模
  • B.模型参数规模
  • C.对参考模型胜率← 正确答案
  • D.推理响应延迟

答案：C。榜单依据每个模型对固定参考基线（如 GPT-4）的胜率降序排列。胜率是相对分，不是绝对质量分；参数量、数据量、延迟都不是排序依据。

Q5. AlpacaEval 评测成本低的最主要原因是？

单选题 · mid

  • A.用随机数免去推理
  • B.自动裁判免人工← 正确答案
  • C.完全离线无需API
  • D.无需指令样本集

答案：B。自动评估用 LLM 当裁判，免去了人类标注和评审的高额工时费，单次 API 调用只需几分钱。它仍然需要推理和指令样本，但省掉的是最贵的人工环节。

Q6. 已知裁判存在长度偏差，那么回答更长的模型，其胜率通常会？

单选题 · hard

  • A.被显著压低
  • B.出现虚高现象← 正确答案
  • C.完全不受任何影响
  • D.直接失去参考价值

答案：B。长度偏差指裁判偏爱更长的回答，认为“写得越多越好”。因此长回答模型的胜率会虚高。评测时要限制输出长度或用校正公式扣掉这部分的虚高。

Q7. 某模型在 AlpacaEval 上胜率为 52%，最合理的解读是？

单选题 · hard

  • A.一定全面强于 GPT-4
  • B.略优但可能属噪声范围← 正确答案
  • C.明显弱于 GPT-4 基线
  • D.没有任何参考价值可言

答案：B。52% 只是略高于 50% 的平手线，评测样本有限、裁判又有偏差，几个百分点的优势很可能在噪声范围内。需要看置信区间、分场景胜率，并与其他评测交叉验证。

Q8. 下列哪些属于自动评估中常见的偏差？（多选）

多选题 · mid

  • A.裁判偏爱长回答← 正确答案
  • B.答案顺序影响判定← 正确答案
  • C.裁判模型自身偏见← 正确答案
  • D.网络请求延迟高低

答案：ABC。长度偏差（偏爱长答案）、位置偏差（先看先评的答案占优）、裁判偏差（不同 LLM 口味不同）都是已知问题。网络延迟是工程问题，不影响判定偏好，不属于评测偏差。

Q9. 在 RAG 客服系统中使用 AlpacaEval 的正确做法有哪些？（多选）

多选题 · mid

  • A.构造客服场景指令集← 正确答案
  • B.收集新旧模型输出← 正确答案
  • C.裁判成对对比算胜率← 正确答案
  • D.直接重训模型参数

答案：ABC。正确流程是：构造领域指令集 → 让新旧模型分别作答 → 用裁判成对比较并计算分场景胜率。重训模型是评测之后才可能做的动作，不是评测本身。

Q10. 下列哪些是降低 AlpacaEval 评测偏差的改进方法？（多选）

多选题 · extreme

  • A.交换答案顺序再评一次← 正确答案
  • B.限制模型输出最大长度← 正确答案
  • C.更换多个裁判交叉验证← 正确答案
  • D.把胜率当作绝对真理使用

答案：ABC。交换顺序可抵消位置偏差，限制长度可压缩长度偏差，多裁判交叉验证可稀释单一裁判的偏见。D 恰恰相反——胜率是相对指标，必须结合场景与业务指标综合判断。