Evaluation评估体系

01为什么评估这么难#eval-why-hard

「感觉不错」不可规模化：手感只能覆盖个位数场景，真实问题分布是长尾的——「demo 惊艳、上线客诉」是行业常态，因为 demo 挑的是顺手问题。

有没有可重复、可比较、可回归的评估，是玩具与产品的分水岭。

三层分工：高考、面试、试用期

三层各管一段、互相不能替代。某客户按榜单选了第一名模型，POC 一跑发现它在自家行业术语上不如第二名——榜单是高考分，客户场景是岗位面试。

评估集是真正的护城河

模型会换、prompt 会改、框架会过时；沉淀下来的是「你的场景里什么算好」加一套能验证它的题——评估集是复用率最高的工程资产。换模型时：

边界声明：本册管「质量」，延迟/吞吐归 LLM-Inference 网页版——快不快找推理，好不好找评估。

02基准测试全景#eval-benchmarks

2026-10 格局一句话：Claude Opus 5（07-24 发布）仍以 96% 领跑 SWE-bench Verified（BenchLM 10-19 榜，已移出该榜加权总分）， 此后各家已换代至 GPT-6 Astra、Gemini 4 Argon、Claude Opus 5.5 / Fable 5.1；OpenAI 2026-02 以污染为由退出 SWE-bench Verified，改推的 SWE-bench Pro 也在 07-08 被其官方撤回推荐——没有全能冠军，按任务选对口基准。能力比拼已从「答题」转向「干活」。

三个暗面：污染、偏好、择优

核实 2026-07-09（基准格局与速查表 2026-08-01 刷新），来源 2026 基准综述、 arXiv 2504.20879。这套「榜单怎么骗人」的弹药与 Model-Landscape 网页版的选型两道防线互为表里。不可外推边界：领跑格局是当期快照，且每个基准只对它那类任务有效——「没有全能冠军」的另一面是：任何单一基准分数都不能外推成整体能力。

03判分四法#eval-methods

BLEU/ROUGE 靠词面重叠打分，来自机器翻译时代——LLM 的答案常与参考措辞完全不同却语义正确，词面重叠会冤枉好答案、放过坏答案。客户的评估方案若还拿 BLEU 当主指标，这本身就是一个咨询切入点。设计评估先想「能不能把题出成可代码判的形式」（选择题化、结构化输出）——大部分企业任务能用「结构化输出 + 代码判」覆盖七成判分需求，评估成本立刻降一个量级。

04LLM 判官深潜#eval-judge

三种判法与四类偏差

LLM 更擅长判别式任务：成对比较（两个输出选更好，最稳）和评分细则（把「好」拆成可核对条款逐条判，最可控）远比裸的单点打分稳定——问「这碗面打几分」难答稳，问「这两碗哪碗好吃」谁都答得准。选题型：

校准四步与使用边界

校准流程：人工标一批金标准判决（几十到几百条）→ 最强模型当判官跑同一批 → 算一致率，达标（常见门槛 85%~90%，视任务）才上量 → 换便宜判官降本后重测。像新阅卷老师先试批 50 份卷子和阅卷组长对口径。2026-03 开源的 Judge Reliability Harness 压测结论：没有判官全面可靠——可靠性是逐任务的属性，不是模型的属性。校准时优先改细则措辞、不急着换模型：多数不一致源于标准含糊。

边界：判官增强而非替代人工——高风险场景人工必须在环；实务分层是「判官全量打分 → 低分与边界样本送人工复核 → 人工判决回流为新校准数据」。评审任何判官方案用判官三问： ①和人工对齐过吗？②换序复核了吗？③高风险有人工兜底吗？

偏差证据来源 arXiv 2306.05685 / 2410.21819 / 2410.02736，校准与可靠性 Judge Reliability Harness（2026-03），核实 2026-07-09。不可外推边界：一致率门槛是常见做法不是通用标准，随任务而变；压测的结论也正是「可靠性是逐任务的属性」——换任务必须重新校准，不能沿用上一个场景的判官结论。

05自建评估#eval-build

黄金集与错误分析

构成配比参考（15% 那档涉及价格、合规话术等）：

错误分析的做法：先逐条看几十条真实输出，每条错误用短语记下来，归并成类别，每个高频类别对应一个评估项——像给 AI 建错题本。实例：某企业问答系统看 50 条日志归出三类高频错误（引用过期文档 38%、过度拒答 24%、术语用错 18%），评估集立刻有了三个专项维度，比拍脑袋写的「准确性/流畅性」有用得多。

冷启动三条路与指标设计

没有标注数据的三条起步路：

三路并进，两周从 0 到 100 题。

指标设计两条：

指标不超过 5 个，每个都要能翻译成一句业务话（事实错误率↔客诉风险；拒答率↔转人工成本）。

进 CI、持续生长

把评估当测试跑：prompt 改动、模型升级、检索配置变更都触发评估集回归，通过率低于门槛就挡住上线——「只改了一个词」和「只改了一行代码」一样都是变更。评估集要持续生长：线上坏例回流（同一个坑不踩第二次），像免疫系统越打越强。两个维护点：防泄漏（评估题别混进微调训练数据）、防过拟合（留 10–20% 保留集不参与日常调优，定期补新题）。

06场景验收#eval-scenarios

RAG：检索与生成分开评（Ragas 三角）

开卷考试三件事：翻到对的页、别抄不相干段落、答案只依据书上写的。

评估顺序：先把检索评到位（recall@k、MRR，代码判、便宜），再评端到端（判官判忠实度，贵）。经验规律：RAG 生产事故的大头出在检索端——先修检索是性价比最高的路径。管线机制见 RAG 网页版。

Agent：结果与轨迹双轨，五层展开

结果评估管验收（办成没有），轨迹评估管定位（该调的工具调了吗、有没有绕路死循环）——像考驾照：只看到没到终点，危险驾驶也算通过。再往下拆五层：Outcome → Trajectory → Tools → Safety → Efficiency。「危险的成功」是五层存在的理由：任务完成了但中途越权改了库——只评结果会把它放行。多次运行看 pass^k（k 次全过才算稳）；专门造「工具报错、返回为空、用户中途改主意」的扰动用例，别只评顺风局。Agent 侧的护栏与验收线见 Agent 网页版。

微调与安全维度

微调验收别只看 loss：目标能力提升了吗、通用能力掉了吗（灾难性遗忘）、格式与安全行为稳吗、线上 A/B 赢了吗——训前冻结一套与训练数据零重叠的通用回归集，训后先过回归再上线。安全维度进验收清单：有害内容率、注入抵抗、泄露、幻觉率（无依据陈述比例）——同样可以出题、判分、算通过率。护栏与评估的分工：护栏是在线安检门挡个案，评估是离线体检看水位——互补不互替，护栏拦得准不准也要靠评估度量。

07工具链与闭环#eval-tooling

开发期三件套（可组合不互斥）

平台型（LangSmith / Braintrust / Arize Phoenix / W&B Weave）管数据集版本、评估记录、trace、生产监控：深绑 LangChain 选 LangSmith，重开源自托管选 Phoenix。

评估资产要可迁移

OpenAI 平台内置 Evals 已官宣 2026-10-31 起只读、11-30 关停——教训：评估资产（题集、细则、历史结果）的寿命远长于任何平台。落地三件事：黄金集进 git 管版本、判官 prompt 与细则当代码管、结果定期导出归档。口诀：「题在手，平台任你换；题在云，平台绑你走。」三大云均有托管评估服务（Bedrock 评估作业 / Foundry 评估器 / Vertex 评估服务）——客户在哪朵云就从哪家起步，黄金集保持平台无关。

四道发布门与质量飞轮

把评测结果变成发布决策的四道门：

两条铁规矩：不能用下游平均分覆盖上游硬失败；数据集与评分器的版本是门禁的一部分——换了判官必须重新校准、重建可比基线。

质量飞轮：线上坏例 → 错误分析归类 → 进评估集 → 针对性修 → 过回归门禁 → 上线 → 监控采样 → 新坏例……每转一圈评估集厚一分。给客户的运营建议：每周半天「评估例会」一起看坏例——整个体系里回报率最高的投入。上线不是项目结束，而是飞轮起点。

工具与云服务格局核实 2026-07-09，来源 2026 对比评测与 OpenAI 官方文档。不可外推边界：平台清单是当期快照，能力与存续都会变（本节的关停案例就是），它不构成对任何一家的能力背书；可迁移的是你的题集与细则，不是平台。

08速查与问答#eval-cheatsheet

「哪个模型最好」应答三步

POC 验收四件套

谈判三要点

「先对题、再对线、后跑分」，顺序反了 POC 就变扯皮现场。

现场高频追问

只收会改变某个决定的问题——会改变技术方案、风险判断、验收方法、对客沟通或下一步行动。

每题标出它加入本题库的日期：2026-07-09 来自讲义首版对练页， 2026-07-12 来自五层栈与发布门深潜增补，2026-07-23 是按客户交锋场景补的两题（已有 QA 流程 / 评估过了还出问题）。

09上云怎么落地#cloud

托管评估服务：客户在哪朵云，就从哪家起步

顺着追问什么：客户的模型跑在哪朵云——评估服务跟着走，还是要单独选？评估集里有没有真实业务数据，要不要跟数据同区域、不出 VPC？判官用平台内置的，还是要换成私有部署的模型？

云替你做不了什么：托管评估服务替你跑分、给你现成指标，不替你出题——黄金集是客户的真题，谁出题、谁签字确认，仍是 POC 第一周要谈下来的事，顺序是先对题、再对线、后跑分。内置判官同样要校准：换了判官就得重新校准、重建可比基线，否则「过门」这件事本身就不可信。

跑在谁的机器上：开发期、生产期与数据边界

顺着追问什么：现在有 CI 吗，评估要不要卡进构建里、挂了就阻断？评估集算不算业务敏感数据，归谁管、能不能出这朵云？评估结果谁看——技术团队看逐样本证据，领导只看那三个数，汇报口径得先说清。

云替你做不了什么：自托管解决的是数据放在谁的机器上，解决不了「谁来运维」——部署、升级、扩容这些活会跟着一起搬到你这边。判官校准不在这份清单里：托管也好自托管也好，先对齐人工再上量、换判官就重测一致率，这活始终是你的。

本节服务清单与「给客户一句话」与讲义各章的「上云怎么落地」页同源，未引入新事实；「顺着追问什么」与「云替你做不了什么」两格是网页版补的售前视角。不可外推边界：这是「哪个环节有云服务可用」的地图，不是选型结论——具体产品的地域可用性、配额、计价单位与生命周期状态会月级变动，出方案前按当期官方文档逐项复核。

10相关模块#related

同一个概念在库里只有一个主要归属，其余模块讲的是它的另一个层面。

11来源与核实#sources

本页时效性数字均经联网核实后写入，完整登记（事实 × 核实日期 × 信源）见本模块 MANIFEST。核实窗口 2026-07-09（深潜页 2026-07-12）。引用任何数字前先核日期。