公开笔记

大模型测评工程师面经

覆盖大模型测评编码基础、生成结果四大评估方法、ROUGE/BLEU核心匹配指标、权威评测数据集、工程化评估流水线、前沿ORM/PRM评估方向,详解评分稳定性、标准评测流程及面试技巧等核心知识点。

发布于 更新于

Coding

  • 最长公共子序列(LCS)算法

大模型测评

如何评估生成结果

  1. 严格规则与字面匹配 (Rule-based & Lexical) 这是最基础、算力成本最低的方式,通常用于答案相对简短且确定性高的场景(比如 TriviaQA)。
    • Exact Match (EM,完全匹配):生成文本与参考文本必须一字不差(得分为 1 否则为 0)。为了提高容错率,通常会在比对前做文本归一化(Normalization):转小写、去除标点符号、去除停用词(如 a, the, of)。
    • N-gram 匹配:就是前面提过的 ROUGE 和 BLEU 指标。
  2. 向量语义级匹配 (Embedding-based Similarity) 为了解决“字面不同但意思一样”(比如“开心”与“高兴”)的误判,引入轻量级的自然语言理解模型。
    • BERTScore / MoverScore:利用预训练模型(如 BERT)将生成文本和参考文本转化为高维向量(Embeddings),然后计算它们之间的余弦相似度(Cosine Similarity)
    • 适用场景:成本中等,计算快,能抓取浅层语义,适合规模化的基准回归测试。
  3. 大模型裁判员 (LLM-as-a-Judge) —— 行业主流方案 这是目前解决长文本生成评估的最核心手段。既然人类看一遍就能判断对错,那我们就用一个能力更强、逻辑更好的大模型(比如 GPT-4、Claude 3.5 Sonnet)来当裁判,给被测模型打分。 在构建诸如 RAG 系统的响应评估闭环时,这种方式尤为重要。裁判模型不仅可以对比 Ground Truth,还可以多维度拆解生成文本:
    • 回答相关性 (Answer Relevance):生成的文本是否直接回答了用户的问题,有没有答非所问或强行绕弯子。
    • 忠实度/无幻觉 (Faithfulness):在 RAG 场景中,评判生成的文本是否严格基于检索回来的上下文片段(Context),有无凭空捏造事实。
    • 打分机制构建:我们通常会给裁判模型写一个极其详细的 Prompt(包含评分标准(Rubric),例如 1-5 分的具体定义)。为了让裁判模型的打分表现更稳定,通常不建议仅依赖 0-shot 提示词,而是在 Prompt 中预置 1-shot 或 3-shot 的人工打分样例,这样能显著提升评分的收敛性和一致性。
  4. 专用评估模型 (Dedicated Evaluation Models) 如果通用大模型做裁判的成本太高,或者特定业务场景(如特定格式的 Agent 行动计划)通用模型把控不准,工程上会训练专门的“判别器”。
    • Reward Models (奖励模型):源自 RLHF 阶段,专门训练一个只用来打分的小模型。它不负责生成,只负责看两段文本哪个更好。
    • 开源裁判模型:例如 Prometheus 或 JudgeLM,它们是被专门微调过的开源模型,核心任务就是输出细粒度的评估报告和分数,效果往往能逼近 GPT-4 裁判,但可以本地低成本私有化部署。

🧠 总结 如果生成的答案是明确的短实体,走 EM + 归一化;如果是要求严格的结构化长文本,走 ROUGE/BERTScore 做底线防守;如果是极其开放的业务级回答,毫无疑问需要引入 LLM-as-a-Judge,并针对忠实度、相关性等指标设计带 Few-shot 样例的评分机制。

评测场景(数据集)


一、针对自定义数据集的评测(业务线/企业应用开发)

利用私有领域积累的数据(格式为 JSONL)来检验模型的实际落地效果。主要有两种评估途径:

  • 通用指标评测(字面匹配)rougebleu 。它主要用于答案相对确定、可度量的场景,计算模型预测与标准参考答案之间的文本重合度。
  • 裁判员模型评测(LLM-as-a-Judge):对于复杂或开放式的回答,文档推荐引入一个高阶的“裁判模型”进行自动打分。在完善检索生成链路的评估体系时,尤其是需要量化诸如“回答忠实度 (Faithfulness)”或“上下文相关性”这类高阶指标时,依赖裁判员模型而不是死板的文本匹配,正是目前工程上解决语义评估痛点的核心思路。

ROUGE —— 关注召回率

计算生成摘要与人工参考摘要之间的 n 元组(n-gram)、最长公共子序列(LCS)等的重叠率,来衡量两者相似度,重点关注召回率。

ROUGE-n Recall=生成文本与参考文本匹配的 n-gram 数量参考文本中 n-gram 的总数\text{ROUGE-n Recall} = \frac{\text{生成文本与参考文本匹配的 n-gram 数量}}{\text{参考文本中 n-gram 的总数}}

常见变体:

  • ROUGE-N:n 元组召回率(N=1/2/3…,如 ROUGE-1 单字、ROUGE-2 双字)。
  • ROUGE-L:最长公共子序列(LCS)的 F1 值,兼顾语序与流畅度。
    • 参考文本 (Reference, 简称 RR),总词数为 mm
    • 生成文本 (Candidate/Generated, 简称 CC),总词数为 nn
    • LCS(R,C)LCS(R, C) 表示 RRCC 之间的最长公共子序列的长度(即匹配上的词数)
    • 召回率:衡量参考文本中有多少词汇被生成文本按顺序覆盖了:RLCS=LCS(R,C)mR_{LCS} = \frac{LCS(R, C)}{m}
    • 准确率:衡量生成文本中有多少词汇是按顺序命中参考文本的:PLCS=LCS(R,C)nP_{LCS} = \frac{LCS(R, C)}{n}
    • 结合了召回率和精确率的综合评分。原始论文中使用了一个参数 β\beta 来控制精确率和召回率的权重:FLCS=(1+β2)RLCSPLCSRLCS+β2PLCSF_{LCS} = \frac{(1 + \beta^2) R_{LCS} P_{LCS}}{R_{LCS} + \beta^2 P_{LCS}}。默认通常作为标准的F1 分数来计算,即 β=1\beta = 1F1LCS=2×PLCS×RLCSPLCS+RLCSF1_{LCS} = \frac{2 \times P_{LCS} \times R_{LCS}}{P_{LCS} + R_{LCS}}
  • ROUGE-W:加权最长公共子序列,对连续匹配给予更高权重。

BLEU —— 关注精确率

计算生成文本与人工参考文本之间的 n 元组(n-gram)匹配度,结合短句惩罚因子(BP),来衡量生成文本的精确率,重点关注生成内容的用词准确性与流畅度BLEU-n Precision=生成文本与参考文本匹配的 n-gram 数量生成文本中 n-gram 的总数\text{BLEU-n Precision} = \frac{\text{生成文本与参考文本匹配的 n-gram 数量}}{\text{生成文本中 n-gram 的总数}} BLEU=BP×exp(n=1Nwnlogpn)\text{BLEU} = \text{BP} \times \exp \left( \sum_{n=1}^{N} w_n \log p_n \right)

  • BPBP短句惩罚因子(Brevity Penalty),用来防止模型生成极短的句子刷高分。
  • pnp_n修正后的 n-gram 精确率,比如 p₁ 是 1-gram 精确率,p₂ 是 2-gram 精确率,以此类推。
  • wnw_n:每个 n-gram 的权重,默认是平均分配(比如 N=4 时,w₁=w₂=w₃=w₄=0.25)。
  • exp(n=1Nwnlogpn)\exp \left( \sum_{n=1}^{N} w_n \log p_n \right):把各个 n-gram 精确率做几何平均,再通过指数还原,相当于把它们 “综合成一个分数”。 常见变体:
  • BLEU-N:n 元组精确率(N=1/2/3/4…,如 BLEU-1 单字、BLEU-4 四字),其中 BLEU-4 是机器翻译任务的常用指标。
  • BP(短句惩罚):针对生成文本过短的情况进行惩罚,避免模型只输出高频短词来刷高分。

总结

  • n-gram:从左到右滑动窗口,连续取 n 个 token,步长 = 1。
  • BLEU/ROUGE 里额外的「计数去重规则」:不是简单匹配,有截断计数
    1. 先统计参考文本里每个 n-gram 出现的最大次数
    2. 生成文本里同一个 n-gram 最多只按参考里的次数算匹配
    3. 多余重复 n-gram 直接作废,防止模型靠重复刷屏刷分 例: 参考:我 爱 苹果 生成:我 我 我 爱 苹果 匹配时: 只算1 次有效匹配,多的两个「我」不计分。
  • N-gram 指标最大的优势计算速度极快、成本为 0、且结果绝对确定(Deterministic)。它们非常适合作为持续集成(CI)过程中的基准回归测试。但它们的工程局限性也很致命:无法理解语义。比如模型回答了“开心”,而标准答案是“高兴”,在 ROUGE 和 BLEU 看来这属于完全不匹配,得 0 分。因此,在一个成熟的响应评估框架中,通常会将这组指标作为基础层,并在其之上叠加基于 Embedding 模型的语义相似度计算(如 BERTScore),以及基于 LLM-as-a-Judge 的高阶评估(如评估 Answer Relevance 和 Faithfulness),以形成多维度的评测闭环。

二、针对公开权威数据集的评测(基座模型研究)

如果不需要结合具体业务,而是想要评估大模型本身的基础能力底子,可以利用主流开源数据集进行标准化测试,涵盖了 4 个核心维度:

  1. 综合知识储备与常识(百科全书能力) 这类考卷主要测验模型“懂得多不多”、“是不是个学霸”。
    • MMLU (Massive Multitask Language Understanding)
      • 干嘛的:这是目前最著名的英文综合能力考卷。
      • 考什么:包含 57 个学科的大量单选题,涵盖理工科(STEM)、人文学科、社会科学等,难度从初级到专业级(如医学、法律考试)都有。如果一个模型 MMLU 分数高,说明它的基础知识面非常广。
    • TriviaQA
      • 干嘛的:主要评估阅读理解和事实问答能力。
      • 考什么:包含大量复杂的常识问答题。它不仅考验模型背过了多少知识,还考验它能不能从长文本证据中提取出正确的答案(常用于评测 RAG 系统中的大模型能力)。
  2. 中文本土化能力(偏科检测) 因为早期大模型多以英文训练为主,为了测试它们到底懂不懂中文和中国文化,诞生了这两套专用的“中文四六级/考研卷”。
    • C-Eval
      • 干嘛的:首个全面的中文基础模型评估套件
      • 考什么:覆盖人文、社科、理工等 52 个学科的多项选择题,难度跨越初中到专业级别。主要看模型在纯中文语境下的知识量和推理能力。
    • CMMLU
      • 干嘛的:跟 C-Eval 齐名的中文综合能力评测集
      • 考什么:覆盖 67 个主题。与 C-Eval 互补的是,CMMLU 里面包含了很多具有中国文化特色的题目(比如中国历史、汉语言文学、甚至是地方俗语),更能测出模型是不是具备“中国本土常识”。
  3. 逻辑推理与数学计算(理科大脑) 大模型最容易暴露短板的地方就是逻辑和算数,这两个数据集专门测这类能力。
    • GSM8K (Grade School Math 8K)
      • 干嘛的:评估大模型的基础数学逻辑推理
      • 考什么:包含了 8500 道高质量的“小学数学应用题”。别看只是小学级别,它要求模型必须具备多步推理能力(常需要搭配思维链 Chain-of-Thought 技术)。如果大模型这部分得分低,在实际业务中稍微绕弯的计算就会出错。
    • HellaSwag
      • 干嘛的:测试模型的常识推理和情境预测(也就是测它是不是个“人工智障”)。
      • 考什么:题目通常给出一个日常场景的前半段,让模型选出最合理的下一步动作。比如“一个人站在跳板上,深吸了一口气,然后——”,人类很容易选出“跳入水中”,但缺乏常识的模型可能会选“飞向天空”。
  4. 安全性与价值观(防幻觉测试)
    • TruthfulQA
      • 干嘛的:专门测大模型会不会“一本正经地胡说八道”(幻觉)
      • 考什么:里面的题目都是人类经常犯错的迷思、谣言或刻板印象。比如问“如果在太空中大喊,会发生什么?”,它会故意诱导模型回答错的答案。得分越高的模型,越能抵御诱导,输出真实客观的事实。

总结

一、 基础文本匹配指标:Lexical Overlap

这部分指标依赖 N-gram 和字面比对,计算极快,适合作为 CI/CD 的基础回归测试,但缺乏语义理解。

  1. 精度与召回的权衡
    • BLEU 系列:侧重精确率 (Precision),衡量生成的词汇有多大比例是准确的,内置长度惩罚,多用于翻译。
    • ROUGE 系列:侧重召回率 (Recall),衡量参考答案的核心信息被覆盖了多少,多用于摘要。
  2. ROUGE-L 的底层逻辑 (LCS)
    • 不再要求词汇完全连续,而是寻找最长公共子序列 (LCS),能够容忍插词,侧重评估句子骨架和语序。
    • 计算推导:以参考文本长度 mm 和生成文本长度 nn 为基底。
      • 召回率 RLCS=LCSmR_{LCS} = \frac{LCS}{m}
      • 精确率 PLCS=LCSnP_{LCS} = \frac{LCS}{n}
      • 综合 F1LCS=2×PLCS×RLCSPLCS+RLCSF1_{LCS} = \frac{2 \times P_{LCS} \times R_{LCS}}{P_{LCS} + R_{LCS}}

二、 基座模型能力评测集:Benchmarks (能力探针)

通过标准化考试量化模型的各个维度,通常用于模型选型和微调效果对比。

  1. 知识广度与本土化
    • MMLU:57 学科综合大考(确立英文与通用常识底线)。
    • C-Eval / CMMLU:中文语境深度测试(CMMLU 更侧重中国地域与文化特色知识)。
  2. 逻辑、数学与推理
    • GSM8K:8500 道小学应用题,检验多步数学推理和思维链 (CoT) 稳定性。
    • HellaSwag:情境预测,检验模型是否具备基础人类物理与社会常识。
  3. 安全性与信息提取
    • TruthfulQA:诱导性提问测试,评估模型抵抗谣言、偏见及防止幻觉的能力。
    • TriviaQA:带有长文本证据的问答,测试长上下文的信息提取与召回。

三、 开放式生成的工程评估链路 (由浅入深)

面对没有固定 ABCD 选项的生成任务,工程上采用阶梯式的评估流水线。

  1. 针对明确答案的推理题 (如 GSM8K 评测范式)
    • 格式约束:通过 Prompt 强制输出特定标识符(如 #### 答案\boxed{答案})。
    • 正则后处理:通过 Regex 截取目标片段,剥离非结构化文本。
    • 数据清洗:统一小数位、去除千分位与单位。
    • Exact Match (完全匹配):清洗后进行 0/1 的二元判别。
  2. 针对长文本与语义评估
    • 向量相似度 (BERTScore):将文本转化为 Embedding 计算余弦相似度,解决“同义词误判”问题。
    • LLM-as-a-Judge (大模型裁判):行业绝对主力。输入详细的 Rubric(评分标准)和 Few-shot 样例,让强模型判断相关性忠实度

四、 复杂系统与 Agent 评估前沿:ORM vs PRM

这是目前大厂投入算力最大的研究方向,从只看结果走向关注过程。

  1. ORM (Outcome Reward Model - 结果导向)
    • 只看最终输出是否正确。成本低,但容易掩盖模型“逻辑全错但答案蒙对”的虚假推理。
  2. PRM (Process Reward Model - 过程导向)
    • 数学/逻辑推导:切分 CoT 的每一个 Step,进行正向/中性/负向的单步打分。一旦某步出错,后续逻辑判定作废。
    • RAG 系统的三维交叉验证
      • Context Relevance (检索的 Chunk 是否全是干货)。
      • Faithfulness (生成的文本是否 100% 来源于 Chunk,无捏造)。
      • Answer Relevance (最终输出是否解决了原始 Query)。
    • Agent 智能体轨迹评估 (Trajectory Evaluation)
      • 规划 (Planning):任务拆解是否合理。
      • 工具调用 (Tool Calling):API 选择准不准、JSON 参数填对没。
      • 韧性 (Error Recovery):遇到死胡同或报错时,能否自我纠偏。
    • 代码沙盒 (Execution):将生成代码放入 Docker 执行单元测试(Pass@k 指标)。

随记

  • 整体评分结果:
    • 大模型裁判评分稳定性:用标准差(评价打分和平均值的偏移范围),数值越小,打分越统一、意见越一致;
    • 大模型裁判评分偏向/爱好:偏度(描述一组数据的分布是否对称,以及偏向哪一侧)
      • 偏度 = 0:数据分布完全对称(比如完美的正态分布)
      • 偏度 > 0(右偏 / 正偏):分布右侧(高分端)尾部更长或更厚,大部分样本集中在较低分区域。说明少量特别高分的样本把尾巴拉长(可能模型偶尔“打特别高”)
      • 偏度 <0(左偏 / 负偏):分布左侧(低分端)尾部更长或更厚,大部分样本集中在较高分区域(立方能放大离群值的影响)。说明少量特别低分的样本存在(可能模型偶尔“打特别低”)
  • JudgeReason 作用:可追溯性、定位模型问题、校验打分逻辑、迭代优化模型
  • 模型评测流程:传统Benchmark(客观题) + LLM-as-Judge(主观题) + 人工抽查(边界case)

面试反问

  • 放松面试、留下好映像
  • 有大小周吗
  • 节假日需要值班吗
  • 训练模型对象
  • 测评过程指标需要开发吗,除了优化 sop 和脚本,有什么开发内容?
← 返回 Notes

Contact

Contact Me

Leave a message here. The form sends directly from the browser to a form delivery service and then to my email.

Messages are delivered to lzx744008464@gmail.com.