想象你负责为一支遍布街角的移动餐车团队选人。你不能直接拿“五星酒店主厨的进阶考卷”来测试应聘者，因为他们需要的是能在狭小餐车里快速出餐、省电省空间、又会用各种小工具的“全能小帮手”。小语言模型（SLM）的评测，也是同一个道理：评估端侧小模型，不能照搬云端大模型的考核标准。我们要把“考卷”换成四门定制科目——MMLU 像全科笔试，HellaSwag 像情景模拟面试，工具调用像实操考核，端侧效率像体能测试。四门成绩合在一起，才能判断这位“小帮手”是否真的适合上车。本文就用这套“餐车招聘”的视角，带你梳理 SLM 评测基准与能力评估体系。

岗位关联

学会科学评测与小模型选型，是端侧 AI 工程师的硬技能：不再被榜单平均分误导，能结合业务场景与硬件约束，为产品挑到真正“跑得动、用得好”的模型。

目录
  1. 可视化演示
  2. 评测原则：先想清楚考什么
  3. 通用知识基准：MMLU 全科笔试
  4. 常识推理基准：HellaSwag 情景模拟
  5. 工具调用评测：实操室里的器材考核
  6. 端侧效率评测：体能测试
  7. 结果解读与选型：综合评定
  8. 评测实践流程：从发卷到复盘
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示小语言模型评测体系：MMLU多学科准确率、HellaSwag常识推理、端侧效率（延迟/内存）权衡，交互式探索各维度评测指标。

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

MMLU多学科评测 57个学科多项选择题准确率 覆盖STEM/人文/社科等领域 acc = correct / total 综合衡量模型通用知识水平

评测原则：先想清楚考什么

给移动餐车选帮手，你首先要问的不是“他会做佛跳墙吗”，而是“他在餐车这么小的地方能不能稳定出餐”。评估小语言模型也一样，第一步不是拿现成榜单直接排名，而是想清楚：这个模型要服务什么场景，端侧能给它多少电、多少内存、多少推理时间。云端大模型评测默认“算力管够”，而 SLM 的宿命是活在手机、耳机、摄像头里，所以评测原则必须围绕端侧资源约束重新设计。

从概念上，评测原则强调“任务适配优先”。同样是对话模型，在智能音箱上需要快速响应和低功耗，在手机输入法上则需要低延迟和隐私安全，在车载助手上还要考虑离线稳定性。因此，不能只看一个准确率指标，而要建立“能力 + 效率”的双维度评价框架。更关键的是，要意识到任何基准都有局限：MMLU 考的是知识记忆，HellaSwag 考的是常识连贯，工具基准考的是调用正确率，没有一张考卷能覆盖所有端侧任务。

为此，我们可以把“适合度”写成一个小公式：

餐车老板最后会拍板：既要菜好吃，也要上菜快。评测原则，就是让你在“好吃”和“快”之间先定好秤杆。

Fit(M)=α⋅Atask(M)+(1−α)⋅(1−L(M)Tmax⁡)\displaystyle \text{Fit}(M) = \alpha \cdot A_{\text{task}}(M) + (1 - \alpha) \cdot \left(1 - \frac{L(M)}{T_{\max}}\right)
这个公式的含义是：模型最终得分 = 任务准确率贡献 + 延迟约束贡献。α 表示你更看重能力还是更看重速度。
  1. 任务准确率项$A_{\text{task}}(M)$ 表示模型在目标任务上的准确率，比如 MMLU 上的得分。
    Atask(M)A_{\text{task}}(M)
  2. 延迟约束项$L(M)$ 是模型端侧推理延迟，$T_{\max}$ 是业务可接受的最大延迟，比值越小说明越“轻快”。
    (1−L(M)Tmax⁡)\left(1 - \frac{L(M)}{T_{\max}}\right)
  3. 权重融合$\alpha$ 用来调节准确率和效率的侧重，$\alpha$ 越大说明你优先追求能力，反之优先追求速度。
    Fit(M)=α⋅Atask(M)+(1−α)⋅(1−L(M)Tmax⁡)\text{Fit}(M) = \alpha \cdot A_{\text{task}}(M) + (1-\alpha) \cdot \left(1 - \frac{L(M)}{T_{\max}}\right)

通用知识基准：MMLU 全科笔试

MMLU（Massive Multitask Language Understanding）就像一场“全科笔试”，考题横跨人文、社科、理工、法律、医学等 57 个学科，累计约 1.4 万道选择题。对于小语言模型来说，这份考卷能快速看出它的“知识底子”是否厚实：一个模型如果连常识概念都记不住，后续的端侧问答和助手任务几乎不可能做好。

使用 MMLU 评测 SLM 时，通常以“平均正确率”作为主指标，但更专业的做法是分学科统计。就像餐车面试不能只看“厨师证总分”，还要看他是擅长炒菜还是擅长做甜点；一个在数学上 40 分、历史上 80 分的模型，平均分也许尚可，但如果你要做数学解题助手，它就不合格。

MMLU 的准确率可以写成：

回到比喻中，MMLU 就像一场覆盖 57 个科目的统一笔试。它能筛出“知识面广”的候选人，但最终录用谁，还得结合岗位需求看分科成绩。

AccMMLU=1N∑i=1NI(y^i=yi)\displaystyle \text{Acc}_{\text{MMLU}} = \frac{1}{N}\sum_{i=1}^{N} \mathbb{I}(\hat{y}_i = y_i)
简单说，就是“做对的题数 ÷ 总题数”，但你的视线要落到每一个分科上面。
  1. 总题数$N$ 是评测集里的题目总数，MMLU 大约有 1.4 万道。
    NN
  2. 命中指示$\mathbb{I}(\hat{y}_i = y_i)$ 在第 $i$ 题预测正确时等于 1，错误时等于 0。
    I(y^i=yi)\mathbb{I}(\hat{y}_i = y_i)
  3. 求平均$\frac{1}{N}\sum_{i=1}^{N}$ 把所有 0 和 1 加起来再除以总数，得到平均正确率。
    1N∑i=1N\frac{1}{N}\sum_{i=1}^{N}

常识推理基准：HellaSwag 情景模拟

如果说 MMLU 是笔试，那 HellaSwag 就是“情景模拟面试”。它会给出一段日常情境描述，比如“小明走进厨房，拿起刀和砧板”，然后让模型从几个候选结尾里选出最合理的后续，比如“他开始切菜”而不是“他飞上了月球”。表面看是在考完形填空，本质上考的是模型对世界常识的理解。

HellaSwag 特别设计了“对抗样本”：大量错误选项由语言模型自动生成，乍一看语法通顺、内容看似合理，但细想并不符合常识。这让模型无法靠“句子是否流畅”来作弊，必须真正理解情境。因此，它能反映小模型在开放世界里的“常识连贯感”，是评估 SLM 是否适合做端侧助手的重要参考。

其准确率表示为：

情景模拟看似简单，却非常考验“生活经验”。就像餐车面试官会问“客人点餐后你先收钱还是先做饭”，HellaSwag 考的正是这种直觉般的常识排序。

AccHellaSwag=1N∑i=1NI(arg⁡max⁡jPθ(ej(i)∣ci)=yi)\displaystyle \text{Acc}_{\text{HellaSwag}} = \frac{1}{N}\sum_{i=1}^{N} \mathbb{I}\left(\arg\max_{j} P_{\theta}(e_j^{(i)} \mid c_i) = y_i\right)
大意是：模型给每个候选结尾计算“接上去是否通顺”的概率，谁概率最高就选谁，再看是否和人工标注的正确结尾一致。
  1. 候选结尾$e_j^{(i)}$ 表示第 $i$ 题中的第 $j$ 个候选结尾。
    ej(i)e_j^{(i)}
  2. 条件概率$P_{\theta}(e_j^{(i)} \mid c_i)$ 是模型给出情境 $c_i$ 后，认为结尾 $e_j^{(i)}$ 合理的概率。
    Pθ(ej(i)∣ci)P_{\theta}(e_j^{(i)} \mid c_i)
  3. 取最大概率$\arg\max_{j}$ 表示从所有候选结尾中挑概率最高的一项，与正确答案 $y_i$ 比较。
    arg⁡max⁡jPθ(ej(i)∣ci)=yi\arg\max_{j} P_{\theta}(e_j^{(i)} \mid c_i) = y_i

工具调用评测：实操室里的器材考核

端侧小模型经常要扮演“工具调度员”，比如帮你查天气、定闹钟、发消息、开智能家居。这时候，光会聊天不够，还得能准确“选对工具并正确传参”。工具调用评测，相当于把应聘者带进实操室，让他操作咖啡机、烤箱和收银机，看每一步是否用得对、用得稳。

主流的工具调用评测，比如 BFCL 和各类 ToolBench，会构造大量“用户指令 + 可用工具列表”，要求模型输出该调用的函数名和参数。复杂一点的基准还会加入多轮对话：第一次查天气，第二次提醒带伞，第三次设置闹钟，模型必须记住上下文并连续调用不同工具。评价指标通常是“任务级通过率”，也就是整个多轮流程最终是否完成。

通过率的计算公式：

实操考核最能刷掉“纸上谈兵”的候选人。一个模型可能笔试满分，但调用工具时给错参数、选错函数，这种“帮倒忙”的助手，餐车老板可不敢让它碰烤箱。

PassRate=1N∑i=1NI(execute(M,τi)=expectedi)\displaystyle \text{PassRate} = \frac{1}{N}\sum_{i=1}^{N} \mathbb{I}\left(\text{execute}(M, \tau_i) = \text{expected}_i\right)
不是看模型“说了什么”，而是看最终“做成了没有”。成功完成一个任务算 1 分，最后取平均。
  1. 测试任务$\tau_i$ 表示第 $i$ 个需要调用工具完成的任务。
    τi\tau_i
  2. 执行结果$\text{execute}(M, \tau_i)$ 表示模型调用工具后的最终返回结果。
    execute(M,τi)\text{execute}(M, \tau_i)
  3. 与预期比较$\mathbb{I}(\cdot = \text{expected}_i)$ 表示执行结果和期望结果一致时记 1，最终求平均得到通过率。
    I(execute(M,τi)=expectedi)\mathbb{I}\left(\text{execute}(M, \tau_i) = \text{expected}_i\right)

端侧效率评测：体能测试

端侧模型生活在一个“省着花”的环境里：电池有限，内存紧张，芯片发热还会降频。因此，除了能力分，我们还要做“体能测试”——关注模型体积、推理延迟、内存占用和功率能耗。就像移动餐车选人，你不能雇一位做菜极好吃但切三分钟菜就气喘吁吁的大厨。

常见的效率指标有：模型体积（MB 数）、首 token 延迟（TTFT）、推理吞吐（tokens/s）、峰值内存和平均功耗。其中“单 token 能耗”是一个非常直观的指标，它把功耗、耗时和输出长度捆绑在一起，可以回答“生成 1000 个字要烧多少电”。这一指标对手机、耳机、IoT 设备尤其重要。

单 token 能耗的公式：

体能测试的意义在于：一辆餐车容量有限，你需要的不是“最强大厨”，而是“最耐跑的帮手”。能力再强，如果跑几步就断电，终究无法出摊。

Etoken=P⋅ttotalNtokens\displaystyle E_{\text{token}} = \frac{P \cdot t_{\text{total}}}{N_{\text{tokens}}}
平均功率 × 总耗时 ÷ 生成的 token 数，就是每生成一个 token 所消耗的能量。数值越小，模型越“省电”。
  1. 平均功率$P$ 是推理过程中设备的平均功耗，单位通常是瓦特（W）。
    PP
  2. 总耗时$t_{\text{total}}$ 是从输入到输出结束经过的总时间。
    ttotalt_{\text{total}}
  3. 输出 token 数$N_{\text{tokens}}$ 是模型生成的 token 总数，用它把总能耗分摊到每一个 token 上。
    Etoken=P⋅ttotalNtokensE_{\text{token}} = \frac{P \cdot t_{\text{total}}}{N_{\text{tokens}}}

结果解读与选型：综合评定

四门考试都考完了，接下来是“综合评定”。很多新手只看 MMLU 平均分，把两个模型排个序就完事。但在端侧场景，这就像只看厨艺不看体力、只看知识不看工具熟练度，非常容易选错。正确做法是：按业务目标给四个维度设定权重，算出一个综合评分。

例如，如果你做的是离线语音助手，可能需要“常识推理 30%、工具调用 30%、效率 30%、通用知识 10%”；如果你做的是端侧教育问答，则“通用知识 40%、推理 30%、效率 20%、工具 10%”。权重不同，同一个模型的排名可能完全不同。这也是为什么我们说“没有最好的模型，只有最合适的模型”。

综合加权评分：

这就好比餐车老板综合“刀工、火候、体力、服务态度”四个维度给候选人打分。你要先确定这家餐车的客群和菜单，再决定是“口味分”权重高还是“出餐速度”权重高。

S(M)=w1AMMLU+w2AHellaSwag+w3Tpass+w4Eeff\displaystyle S(M) = w_1 A_{\text{MMLU}} + w_2 A_{\text{HellaSwag}} + w_3 T_{\text{pass}} + w_4 E_{\text{eff}}
其中每个 $w_k$ 是各维度权重，所有权重加起来等于 1。最终 $S$ 越高，代表这个模型越适合你的任务。
  1. 四个维度得分$A_{\text{MMLU}}$、$A_{\text{HellaSwag}}$、$T_{\text{pass}}$、$E_{\text{eff}}$ 分别代表知识、推理、工具和效率的归一化得分。
    AMMLU, AHellaSwag, Tpass, EeffA_{\text{MMLU}},\ A_{\text{HellaSwag}},\ T_{\text{pass}},\ E_{\text{eff}}
  2. 权重系数$w_1$ 到 $w_4$ 是人工设定的权重，表示各维度的重要程度，满足 $w_1+w_2+w_3+w_4=1$。
    w1+w2+w3+w4=1w_1+w_2+w_3+w_4=1
  3. 综合得分加权求和后得到 $S(M)$，再对不同模型排序，完成选型决策。
    S(M)=∑k=14wk⋅ScorekS(M) = \sum_{k=1}^{4} w_k \cdot \text{Score}_k

评测实践流程：从发卷到复盘

最后，我们聊一聊“怎么把评测落地”。选定了基准和指标，还需要一套规范的流程：准备数据、执行评测、分析结果、持续监控。这就像组织一次标准化的餐车员工考核，不能今天在室内考，明天在雨天考，环境一变分数就没法比。

准备数据时，除了使用 MMLU、HellaSwag 等公开基准，最好再加入与你的端侧业务相关的私有数据。执行评测时，要固定硬件、温度、量化方式、上下文长度等条件，保证结果可复现。分析结果时，则不要只看点估计，还要看置信区间：如果评测集只有 100 道题，62% 和 68% 的差距可能只是随机波动。

评测误差可以用置信区间描述：

评测不是一次性活动。模型更新、芯片换代、应用场景变化后，都要重新“发卷”。就像餐车菜单换了，你自然要重新考核员工适不适合新菜式。

CI=p^±1.96p^(1−p^)N\displaystyle \text{CI} = \hat{p} \pm 1.96 \sqrt{\frac{\hat{p}(1 - \hat{p})}{N}}
这里的 $\hat{p}$ 是模型在评测集上的正确率，$N$ 是样本量。区间越窄，说明评测结果越可信。
  1. 样本正确率$\hat{p}$ 是评测集上的平均正确率，比如 0.62。
    p^\hat{p}
  2. 标准误$\sqrt{\frac{\hat{p}(1-\hat{p})}{N}}$ 衡量由于样本量有限带来的估计波动。
    p^(1−p^)N\sqrt{\frac{\hat{p}(1-\hat{p})}{N}}
  3. 95% 置信区间$1.96$ 是正态分布下 95% 置信水平对应的 Z 值，最终得到一个区间，用来评估分数的稳定性。
    p^±1.96p^(1−p^)N\hat{p} \pm 1.96 \sqrt{\frac{\hat{p}(1-\hat{p})}{N}}

AI 应用场景

手机语音助手模型选型

阶段：模型选型评估

解决的问题：传统做法只看云端公开榜单，导致选了准确率高但体积过大的模型，装入手机后发热严重、响应卡顿。现在用 MMLU + HellaSwag + 端侧效率基准，在真实机型上测延迟、内存和单 token 能耗，决策更贴近落地。

具体案例：某手机团队在 3 款 1-3B 小模型中做对比，小 A 模型 HellaSwag 最高但内存超限，小 B 模型 MMLU 中等但效率最优，最终按“效率 40%、常识 30%、知识 30%”的权重选择小 B。

离线智能客服工具调用验收

阶段：功能验收与回归测试

解决的问题：小模型在无网环境下调用查库存、下订单工具，错误率难以发现。利用工具调用基准构造多轮任务，并以 PassRate 为门槛，可提前暴露“乱选函数、参数遗漏”的问题。

具体案例：某家电品牌在离线客服机器上，用 500 个工具调用测试任务验收模型，要求 PassRate ≥ 85%，未达标则回退版本或更换模型。

边缘设备模型定期监控

阶段：模型上线后持续评测

解决的问题：模型升级后能力可能回退，传统人工抽测效率低。建立自动化评测流水线，定期跑 MMLU、HellaSwag 和能耗指标，用置信区间判断变化是否显著。

具体案例：某智慧社区门禁团队每月自动评测 5 款 SLM，记录端侧延迟和功耗，发现新版本在“常识推理”上下降 3% 且超出置信区间，立即回滚。

Python 演示

python55 行
# -*- coding: utf-8 -*-"""SLM 评测小工具: 模拟 MMLU 与 HellaSwag 的评测流程"""import json  def load_data(path):    with open(path, "r", encoding="utf-8") as f:        return json.load(f)  def accuracy(preds, labels):    if not preds:        return 0.0    correct = sum(1 for p, y in zip(preds, labels) if p == y)    return correct / len(preds)  def predict_mmlu(model, item):    return model(item["question"], item["choices"])  def predict_hellaswag(model, item):    return model(item["context"], item["endings"])  def run_eval(model, mmlu_path, hs_path):    mmlu_data = load_data(mmlu_path)    hs_data = load_data(hs_path)    mmlu_preds = [predict_mmlu(model, x) for x in mmlu_data]    hs_preds = [predict_hellaswag(model, x) for x in hs_data]    return {        "mmlu_acc": accuracy(mmlu_preds, [x["correct"] for x in mmlu_data]),        "hellaswag_acc": accuracy(hs_preds, [x["correct"] for x in hs_data]),    }  def dummy_model(question, choices):    # 固定返回第一个选项, 用于演示完整流程    return 0  if __name__ == "__main__":    sample_mmlu = [        {"question": "中国的首都是?", "choices": ["北京", "上海", "广州"], "correct": 0},        {"question": "1+1等于?", "choices": ["1", "2", "3"], "correct": 1},    ]    sample_hs = [        {"context": "小明走进厨房", "endings": ["他拿起杯子喝水", "他飞向月球", "他打开电视"], "correct": 0},    ]    with open("sample_mmlu.json", "w", encoding="utf-8") as f:        json.dump(sample_mmlu, f, ensure_ascii=False)    with open("sample_hs.json", "w", encoding="utf-8") as f:        json.dump(sample_hs, f, ensure_ascii=False)     print(run_eval(dummy_model, "sample_mmlu.json", "sample_hs.json"))
目的：实现一个极简评测框架，依次读取 MMLU 与 HellaSwag 格式的 JSON 数据，调用模型预测并计算两个准确率。
  1. def run_eval(model, mmlu_path, hs_path):评测入口，统一管理两个基准流程。
  2. mmlu_preds = [predict_mmlu(model, x) for x in mmlu_data]对每道 MMLU 题调用模型预测。
  3. accuracy(mmlu_preds, [x["correct"] for x in mmlu_data])将预测结果与标准答案比较，计算正确率。
  4. def dummy_model(question, choices): return 0使用固定选第一个选项的桩模型，先跑通评测管线。
  5. json.dump(sample_hs, f, ensure_ascii=False)将测试样例写入 JSON 文件，模拟真实评测数据集。

常见误区

误区我拿 MMLU 和 HellaSwag 测了一下 7B 和 70B 模型，发现小模型低了 30 分，所以小模型很弱。

正解拿五星酒店主厨考卷去考移动餐车帮厨，分数低很正常。SLM 的目标是在端侧用有限资源完成高频率小任务，应结合端侧评测集和资源指标综合判断。直接对比绝对分，忽略了场景和资源约束。

为何常见：厂商榜单常用同一套基准，数据公开易得，大家习惯了“分数即质量”。

误区小模型 MMLU 平均分有 65，说明各学科水平差不多。

正解平均分会掩盖学科差异，比如数学 40 分、历史 80 分。餐车店员“总体不错”不代表会做咖啡拉花。评测时必须分学科看短板，才能判断它是否胜任具体任务。

为何常见：公开排行榜只展示平均分，用户容易用整体印象代替细节分析。

误区既然 HellaSwag 是推理基准，分数高就代表逻辑推理能力很强。

正解HellaSwag 侧重日常情境的常识连贯判断，更像“生活常识面试”，不是多步逻辑推理。它由语言模型生成干扰结尾，能衡量语义连贯性，但不能替代数学推理或符号推理基准。

为何常见：“推理”一词被泛化使用，导致人们把常识判断和逻辑推理混为一谈。

误区模型准确率最高就选它，不用测延迟、内存和功耗。

正解端侧资源有限，高准确率往往伴随大模型体积和高功耗，设备会发热、掉电快。就像雇了会做满汉全席但推不动餐车的厨师。必须把每秒 token 数、内存峰值、能耗加入选型指标。

为何常见：云端评测环境默认硬件无限，而端侧真实约束是电池、内存与散热。

误区选了一个 10 万条的大数据集，测一次就一定代表模型真实水平。

正解数据集再大，若领域不相关、存在数据污染或分布偏差，依然不能反映端侧表现。评测要像控温保存食材一样控制环境，固定测试版本、硬件条件和输入长度，才能让分数有可比性。

为何常见：人们常把“数量大”等同于“质量高”，忽略了数据分布和评测规范性。

面试题

Q1. 评估小模型为何不应照搬大模型基准？

单选题 · easy

  • A.两者参数量差距巨大
  • B.端侧场景需求差异明显← 正确答案
  • C.小模型不支持中文测试
  • D.大模型基准过于简单

答案：B。小模型部署在端侧，面临内存、电量、延迟等硬约束，照搬大模型基准会忽略这些关键因素。A 只说参数量差异但不是根本原因，C 不符合事实，D 也不准确。

Q2. MMLU 主要考察模型的什么能力？

单选题 · easy

  • A.多学科通用知识掌握← 正确答案
  • B.复杂编程代码生成
  • C.图像识别与分类
  • D.声音信号处理能力

答案：A。MMLU 是覆盖 57 个学科的选择题基准，重点考察通用知识广度。编程、图像、声音不是它的考察目标，因此 B、C、D 错误。

Q3. HellaSwag 的任务形式是什么？

单选题 · easy

  • A.根据上下文选择结尾← 正确答案
  • B.对文本进行机器翻译
  • C.从图像中识别物体
  • D.生成一段完整代码

答案：A。HellaSwag 给出一段情境文字，让模型从多个候选结尾中选择最合理的一项，属于常识完形选择。它不涉及翻译、图像识别或代码生成。

Q4. MMLU 共覆盖多少个学科？

单选题 · mid

  • A.约七个基础学科
  • B.约三十个交叉学科
  • C.约五十七个学科← 正确答案
  • D.约一百个细分学科

答案：C。MMLU 横跨人文、社科、理工、法律、医学等 57 个学科，约 1.4 万道题。7、30、100 均不是正确数值。

Q5. 工具调用评测中 PassRate 的含义是什么？

单选题 · mid

  • A.测试任务全部通过占比← 正确答案
  • B.模型输出文本平均长度
  • C.模型训练数据总量大小
  • D.模型推理速度的快慢

答案：A。PassRate 表示“成功完成工具调用任务的比例”。它关注最终执行结果，而不是输出长度、训练数据量或推理速度。

Q6. 端侧效率评测通常关注哪些指标？

多选题 · mid

  • A.模型体积与内存占用← 正确答案
  • B.端侧推理延迟时间← 正确答案
  • C.设备功耗与发热情况← 正确答案
  • D.模型是否开源生态

答案：ABC。端侧效率关注模型体积、内存、延迟、功耗等物理资源指标。D 的开源生态属于社区属性，不是效率评测指标。

Q7. 解读 SLM 评测结果时应注意什么？

多选题 · mid

  • A.结合任务场景综合判断← 正确答案
  • B.只看平均分不看分科
  • C.重视资源占用与延迟← 正确答案
  • D.直接忽略基准局限

答案：AC。解读结果要结合场景、看分科差异、关注资源指标，同时承认基准局限。B 和 D 都是容易导致误判的做法。

Q8. 关于 HellaSwag 的对抗样本设计，正确的是？

单选题 · hard

  • A.由语言模型生成干扰结尾← 正确答案
  • B.人工撰写全部错误选项
  • C.随机抽取新闻做干扰项
  • D.只保留简单直白选项

答案：A。HellaSwag 的关键设计是用语言模型自动生成“看似流畅但不符合常识”的干扰项，防止模型靠语言通顺度作弊。B、C、D 与其设计不符。

Q9. 构建 SLM 评测基准时需要满足哪些条件？

多选题 · hard

  • A.样本量足够保证稳定← 正确答案
  • B.覆盖目标场景任务← 正确答案
  • C.尽量照搬云端大模型
  • D.记录硬件与温度环境← 正确答案

答案：ABD。评测基准需要足够样本量、覆盖真实任务场景，并记录硬件、温度等环境以保证可复现。照搬云端大模型基准无法体现端侧特点，所以 C 错误。

Q10. 某模型单 token 能耗为 0.5 mJ，推理 200 个 token 共消耗多少能量？

单选题 · extreme

  • A.400 毫焦
  • B.100 毫焦← 正确答案
  • C.200 毫焦
  • D.50 毫焦

答案：B。由公式 E = P × t / N 得单 token 能耗 × token 数 = 总能耗，即 0.5 × 200 = 100 mJ。其他选项均没有正确反映乘法关系。