Evaluation · 面试核心

大模型评估体系

「模型好不好」不能一句带过。面试常要求你设计评估方案：用什么指标、怎么避免自吹自擂、RAG/对话/Agent 各怎么评。本文给出通用评估框架（RAG 专项见 rag/rag-evaluation）。

01评估看什么：三维

① 能力

知识、推理、代码、数学、长上下文、多模态等「硬实力」。

② 对齐

有用、诚实、无害（3H），以及指令遵循、格式合规。

③ 工程

延迟(TPOT/TTFT)、吞吐、成本、稳定性、可复现。

关键点：不同应用侧重不同。客服机器人重「对齐+工程」，科研助手重「能力+长上下文」。评估方案要贴合场景。

02能力基准（Benchmark）

通用知识

MMLU（57 学科多选）、C-Eval / CMMLU（中文）、BBH（复杂推理）。

数学/推理

GSM8K（小学应用题）、MATH、GPQA（研究生级）。

代码

HumanEval、MBPP（函数级）；LiveCodeBench（防污染）。

长上下文

Needle-In-A-Haystack（大海捞针）、多文档 QA。

「刷榜」陷阱：很多基准已被训练数据污染，分数高≠真实能力强。面试要能指出这点，并强调用 held-out / 在线数据。

03LLM-as-Judge

开放式生成无法用精确匹配，于是用更强的 LLM（如 GPT-4）当裁判，按维度（有用性、相关性、安全性）打分或 pairwise 比较。

待评回答 A/B+ 提示 + 标准 裁判 LLM按维度打分/比较 分数 / 排名可批量、可自动化
  • 优点：接近人类语义判断、可规模化、成本低。
  • 缺点：裁判自身有偏见（位置偏见、长答案偏好、自我偏好）；需校准、需人工抽检一致性。
  • 改进：多裁判投票、成对比较代替绝对打分、用 rubric 约束。

04人工评估

对安全性、风格、复杂指令遵循等「机器难判」的维度，仍需人工标注（标注员按 rubric 给分或 pairwise 胜出）。它是金标准，但慢且贵，常用于终验与法官模型校准。

05工程指标

TTFT / TPOT

首 token、每 token 延迟（见 deploy 目录）。

Throughput

token/s、请求/s，决定并发容量。

成本

每千 token 费用、每请求 GPU 时。

06常见陷阱

数据污染

测试集泄露进训练，分数虚高。

指标错配

用 BLEU 评开放生成，意义有限。

裁判自偏

用自家模型当裁判易高分。

只看均值

长尾失败（幻觉/越狱）更致命。

07面试速记卡

三维

能力 + 对齐 + 工程，按场景取舍权重。

基准

MMLU/GSM8K/HumanEval/Needle 等，警惕污染。

LLM-as-Judge

可规模化但有偏见，需校准+人工抽检。

RAG 评估

检索/生成分层指标见 rag/rag-evaluation。

关联：安全与红队评测见《安全与红队》；RAG 质量评估见 rag 目录。