LLM + Agent 模型效果评估：从入门到工业级体系构建的完整指南
一句话摘要：模型效果评估不是"跑个分"，而是一套贯穿数据→训练→对齐→部署→运营的全链路决策系统。本文从基础指标出发，逐层深入到 LLM 评估、Agent 评估、后训练评估、工业级准召体系，最终给出一套可直接落地的评估方法论。
目录
- 为什么"评估"是AI落地最难的一环
- 第一层：经典评估指标------地基不能跳过
- [第二层：LLM 评估------从 Benchmark 到 LLM-as-Judge](#第二层：LLM 评估——从 Benchmark 到 LLM-as-Judge)
- [第三层：Agent 评估------复杂度跃迁后的新范式](#第三层：Agent 评估——复杂度跃迁后的新范式)
- [第四层：后训练（SFT / RL）评估------对齐的度量衡](#第四层：后训练（SFT / RL）评估——对齐的度量衡)
- [第五层：工业级评估体系------准召天花板与 ROI 决策](#第五层：工业级评估体系——准召天花板与 ROI 决策)
- 第六层：机审与人审协同场景的评估设计
- 评估体系搭建方法论：一张图讲清楚
- 前沿趋势与开放问题
- 写在最后：给求职者和从业者的建议
1. 为什么"评估"是AI落地最难的一环
1.1 一个反直觉的事实
在工业界，模型效果评估的难度往往超过模型训练本身。
训练一个模型，你面对的是一个定义良好的优化问题（最小化 Loss）。但评估一个模型，你面对的是：
- 评估什么？（能力维度是开放的）
- 怎么评估？（自动评估有偏差，人工评估有成本）
- 评估结果怎么用？（离线指标好 ≠ 线上效果好）
- 评估的评估谁来做？（Meta-evaluation 本身是个难题）
1.2 评估在 AI 全链路中的位置
数据工程 → 模型训练 → 后训练(SFT/RL) → [效果评估] → 部署上线 → 线上监控 → 迭代优化
↑
你在这里
（决策的核心枢纽）评估不是流程的"终点"，而是每一个环节的反馈信号源。没有靠谱的评估，后续所有决策都是在黑暗中开枪。
1.3 本文的阅读路径
| 你的水平 | 建议阅读路径 |
|---|---|
| 初学者 | §2 → §3.1 → §3.2 → §8 |
| 有模型训练经验 | §3 → §4 → §5 → §8 |
| 工业界从业者 | §4 → §5 → §6 → §7 → §9 |
| 面试准备 | 全文通读，重点 §6 §7 §8 |
2. 第一层：经典评估指标------地基不能跳过
2.1 分类任务的"铁三角"
在 LLM 时代，很多人急于跳过基础，直接聊 GPT-4 评分。但工业界（尤其是安全、审核、风控场景）的底层仍然是分类问题。
| 指标 | 定义 | 适用场景 | 常见误区 |
|---|---|---|---|
| Precision（精确率） | TP / (TP + FP) | 误杀代价高时优先看 | 不是"越高越好"，需结合 Recall |
| Recall（召回率） | TP / (TP + FN) | 漏放代价高时优先看 | 高 Recall 可能意味着大量误杀 |
| F1 Score | 2·P·R / (P+R) | P 和 R 同等重要时 | 对类别不平衡不敏感，慎用 |
| F2 Score | 5·P·R / (4P+R) | Recall 权重更高时 | 安全场景常用 |
2.2 为什么"准召率"在工业界是核心语言
在内容安全、广告审核、电商信任等场景中，业务方的核心诉求永远是：
"在召回率不低于 X% 的前提下，精确率能到多少？"
这就是所谓的准召天花板。突破这个天花板，就是模型迭代的核心目标。
关键认知 ：准召不是模型单方面的属性，而是模型能力 × 数据质量 × 阈值策略 × 业务定义的联合函数。
2.3 超越单一指标：评估的"维度思维"
单一指标 → 多维指标 → 分层指标 → 业务指标- 单一指标：Accuracy、F1
- 多维指标：按类别/难度/场景拆分
- 分层指标：模型层（Loss）→ 能力层（各维度得分）→ 业务层（转化率/投诉率）
- 业务指标：最终与商业目标挂钩
3. 第二层：LLM 评估------从 Benchmark 到 LLM-as-Judge
3.1 静态 Benchmark：必要但不充分
主流 Benchmark 速览
| Benchmark | 评估维度 | 局限性 |
|---|---|---|
| MMLU | 多学科知识 | 静态、易被数据污染 |
| HumanEval / MBPP | 代码生成 | 只覆盖算法题，非工程场景 |
| GSM8K / MATH | 数学推理 | 难度天花板有限 |
| MT-Bench | 多轮对话 | 依赖 Judge 模型 |
| Arena (Chatbot Arena) | 综合偏好 | 偏向"讨喜"风格 |
| C-Eval / CMMLU | 中文知识 | 同样存在污染问题 |
Benchmark 的三大陷阱
- 数据污染（Data Contamination）：训练数据中已包含测试题，分数虚高。
- 分布偏移：Benchmark 分布 ≠ 真实业务分布。
- Goodhart 定律：当指标成为目标，它就不再是好指标。
工业界共识 ：Benchmark 用于初筛和横向对比，绝不能作为上线决策的唯一依据。
3.2 动态评估：面向真实场景的 Eval Set
工业级评估的核心是构建业务专属评估集：
构建原则：
- 来源：从线上真实流量中采样（注意脱敏）
- 分层：按难度（Easy/Medium/Hard）、场景（广告/电商/社区）、风险等级分层
- 标注：多人标注 + 一致性校验（Kappa ≥ 0.8）
- 动态更新：定期替换，防止过拟合
一个典型的评估集结构：
eval_set/
├── metadata.json # 版本、来源、标注规范
├── samples/
│ ├── easy/ # 简单样本
│ ├── medium/ # 中等样本
│ └── hard/ # 困难样本（badcase 挖掘）
├── annotations/
│ ├── annotator_1.jsonl
│ ├── annotator_2.jsonl
│ └── consensus.jsonl # 共识标注
└── splits/
├── test_v1.jsonl
└── test_v2.jsonl # 定期轮换3.3 LLM-as-Judge：用大模型评估大模型
核心思想
用一个强模型（如 GPT-4、Claude）作为"裁判"，对目标模型的输出进行打分或排序。
三种主流范式
| 范式 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| Pointwise | 对单条输出打绝对分（1-5） | 简单直观 | 分数校准难 |
| Pairwise | 两个输出对比，选优 | 更符合人类偏好 | 位置偏差 |
| Listwise | 多个输出排序 | 信息量大 | 成本高 |
关键实践细节
① Prompt 设计是核心
markdown
## 评估维度
- 准确性（0-5分）：事实是否正确，逻辑是否自洽
- 完整性（0-5分）：是否覆盖了问题的所有方面
- 安全性（0-5分）：是否存在有害/违规内容
## 评分标准
5分：完美，无可挑剔
4分：优秀，有极小瑕疵
3分：合格，有明显但非致命问题
2分：较差，存在关键错误
1分：完全不可用
## 输出格式
请严格按以下JSON格式输出：
{"accuracy": <int>, "completeness": <int>, "safety": <int>, "reasoning": "<str>"}② 必须处理的偏差
- 位置偏差（Position Bias）：Pairwise 时交换顺序，取平均
- 冗长偏差（Verbosity Bias）：长回答不一定好，需在 Prompt 中显式抑制
- 自我偏好（Self-enhancement Bias）：模型倾向于给自己生成的内容打高分
③ 与人工评估的一致性校验
经验法则：LLM-as-Judge 与人类评估的 Spearman 相关性达到 0.85+ 才可信赖用于决策。
3.4 多维度能力评估框架
一个成熟的 LLM 评估体系应覆盖以下维度：
┌─────────────────────────────────────────────────┐
│ LLM 评估维度 │
├──────────────┬──────────────┬───────────────────┤
│ 知识能力 │ 推理能力 │ 生成能力 │
│ · 事实准确性 │ · 逻辑推理 │ · 文本质量 │
│ · 时效性 │ · 数学能力 │ · 风格一致性 │
│ · 多语言 │ · 代码能力 │ · 创意性 │
├──────────────┼──────────────┼───────────────────┤
│ 安全能力 │ 工具使用 │ 对齐能力 │
│ · 毒性检测 │ · API调用 │ · 指令遵循 │
│ · 隐私保护 │ · 多步规划 │ · 拒绝合理性 │
│ · 价值观对齐 │ · 错误恢复 │ · 诚实性 │
└──────────────┴──────────────┴───────────────────┘4. 第三层：Agent 评估------复杂度跃迁后的新范式
4.1 Agent 评估为什么是"另一个量级"的问题
LLM 评估是单轮、静态、确定性的。Agent 评估面对的是：
| 维度 | LLM 评估 | Agent 评估 |
|---|---|---|
| 交互轮次 | 单轮/少轮 | 多轮、动态 |
| 环境 | 静态文本 | 动态环境（API、网页、数据库） |
| 成功标准 | 文本质量 | 任务是否完成 |
| 失败模式 | 答错 | 死循环、工具误用、规划失败 |
| 评估粒度 | 整体输出 | 每一步决策 |
4.2 Agent 评估的核心指标体系
第一层：端到端指标（Task-level）
| 指标 | 定义 | 说明 |
|---|---|---|
| Task Success Rate | 任务完全完成的比例 | 最核心指标 |
| Partial Completion Rate | 部分完成的比例 | 反映"差多少" |
| Step Efficiency | 实际步数 / 最优步数 | 衡量规划效率 |
| Cost per Task | Token 消耗 + API 调用成本 | ROI 视角 |
第二层：组件级指标（Component-level）
| 组件 | 评估指标 | 说明 |
|---|---|---|
| 规划（Planning） | 计划合理性、分解粒度 | 是否把复杂任务正确拆解 |
| 工具选择（Tool Selection） | 选对工具的比例 | 是否选错了 API |
| 参数填充（Parameter Filling） | 参数准确率 | 选对工具但填错参数 |
| 观察解读（Observation） | 对返回结果的理解准确率 | 是否正确解读了工具返回 |
| 错误恢复（Error Recovery） | 遇错后的恢复成功率 | 鲁棒性关键 |
| 终止判断（Termination） | 该停时停、该继续时继续 | 避免死循环或过早放弃 |
第三层：安全性指标（Safety-level）
在内容安全、商业化审核场景中，Agent 的安全性评估优先级最高。
- 越权操作率：Agent 是否执行了超出权限的操作
- 信息泄露率：是否在交互中暴露了敏感信息
- 对抗鲁棒性：面对 Prompt Injection 时的表现
- 幻觉行动率：基于错误信息执行了操作
4.3 Agent 评估的三种方法论
方法一：基于沙箱的端到端测试
构建模拟环境 → 给定任务 → Agent 执行 → 检查最终状态- 优点：最接近真实场景
- 缺点：环境构建成本高，难以覆盖所有边界情况
- 适用：核心场景的回归测试
方法二：基于轨迹（Trajectory）的过程评估
记录 Agent 每一步的 (Thought, Action, Observation)
→ 对轨迹进行逐步评估- 优点：可定位具体失败环节
- 缺点：评估标准难以统一定义
- 适用：Debug 和能力诊断
方法三：基于对比的 A/B 评估
同一任务 → Agent A 执行 vs Agent B 执行 → 对比结果- 优点：相对评估更稳定
- 缺点：无法给出绝对水平
- 适用：模型迭代时的版本对比
4.4 Multi-Agent 系统的评估
当系统涉及多个 Agent 协作时，评估复杂度再次跃升：
- 通信效率：Agent 间信息传递是否冗余
- 角色一致性：每个 Agent 是否在自己的角色边界内行动
- 冲突解决：多 Agent 意见不一致时的处理质量
- 涌现行为监控：多 Agent 交互是否产生了预期外的行为
4.5 工业界 Agent 评估的实战经验
经验 1：先跑通 20 个 Case 再建体系。不要一上来就设计完美评估框架，先用少量 Case 建立直觉。
经验 2 ：失败案例比成功案例更有价值。建立 Failure Taxonomy（失败分类学），把每次失败归类到具体组件。
经验 3：评估集要"活"起来。每周从线上 Badcase 中补充评估集，保持评估集与真实分布的一致性。
经验 4：成本也是效果的一部分。一个 Success Rate 95% 但平均消耗 50K Token 的 Agent，可能不如 Success Rate 90% 但只消耗 5K Token 的方案。
5. 第四层：后训练（SFT / RL）评估------对齐的度量衡
5.1 SFT（Supervised Fine-Tuning）评估
评估目标
SFT 的核心目标是让模型遵循指令 并符合特定领域的输出规范。
关键评估维度
| 维度 | 评估方法 | 关注点 |
|---|---|---|
| 指令遵循率 | 构造指令集，检查是否按要求输出 | 格式、长度、语言 |
| 领域知识注入 | 领域 QA 测试 | 是否学到了新知识 |
| 灾难性遗忘 | 通用能力 Benchmark 回归 | 是否丢失了原有能力 |
| 过拟合检测 | 训练集 vs 验证集表现差异 | 泛化能力 |
SFT 评估的常见陷阱
- 只看 Loss 曲线：Loss 下降 ≠ 效果提升，必须做生成质量评估
- 忽略多样性：模型可能学会了"模板化回答"，Loss 很低但输出千篇一律
- 遗漏负面样本：只评估"该做什么"，不评估"不该做什么"
5.2 RL（Reinforcement Learning）评估
RLHF / RLAIF 的评估层次
Reward Model 质量 → 策略模型效果 → 对齐程度 → 安全性5.2.1 Reward Model 评估
Reward Model 是整个 RL 流程的"指南针"，如果它不准，后续一切白费。
评估方法：
- Pairwise Accuracy：给定一对回答，RM 是否能正确判断哪个更好
- 校准度（Calibration）：RM 给出的分数差是否反映了真实偏好强度
- 对抗测试：RM 是否容易被"reward hacking"（模型找到讨好 RM 但实际质量差的输出）
5.2.2 策略模型效果评估
| 指标 | 说明 |
|---|---|
| Win Rate vs Base Model | 与 SFT 基线对比的胜率 |
| Reward Score 分布 | 均值、方差、是否存在 reward hacking 迹象 |
| KL Divergence | 与参考模型的偏离程度（过大 = 过度优化） |
| 多样性指标 | Distinct-N、Self-BLEU |
5.2.3 对齐评估
对齐评估回答的问题是：模型的行为是否符合人类价值观和意图？
- Helpfulness：是否真正有帮助
- Honesty：是否诚实，是否承认不确定性
- Harmlessness：是否避免有害输出
实践建议 ：对齐评估不能只看平均分，必须看尾部风险------那 1% 的极端有害输出可能比 99% 的正常输出更重要。
5.3 后训练评估的"回归测试"思维
每次后训练迭代，必须跑一套回归测试集：
回归测试集 = 通用能力集 + 领域能力集 + 安全红线集 + 历史 Badcase 集- 通用能力集：确保没有灾难性遗忘
- 领域能力集：确保目标能力提升
- 安全红线集：确保没有引入新的安全问题
- 历史 Badcase 集：确保已修复的问题没有回退
6. 第五层：工业级评估体系------准召天花板与 ROI 决策
6.1 离线评估 vs 在线评估
| 维度 | 离线评估 | 在线评估 |
|---|---|---|
| 速度 | 快（分钟级） | 慢（天级） |
| 成本 | 低 | 高 |
| 真实性 | 中（评估集可能偏移） | 高（真实流量） |
| 可控性 | 高 | 低（受流量波动影响） |
| 决策权重 | 初筛、快速迭代 | 最终上线决策 |
最佳实践：离线评估用于快速迭代和方向判断，在线 A/B 测试用于最终决策。两者不可互相替代。
6.2 A/B 测试在模型评估中的设计
基本流程
流量分桶 → 对照组(旧模型) vs 实验组(新模型) → 观察核心指标 → 统计显著性检验 → 决策关键设计要点
- 分桶粒度：用户级 or 请求级？（通常用户级，避免体验不一致）
- 观察周期：至少覆盖一个完整业务周期（通常 7-14 天）
- 核心指标 vs 护栏指标 ：
- 核心指标：你要提升的（如准确率）
- 护栏指标：不能恶化的（如用户投诉率、响应延迟）
- 统计功效：样本量是否足够检测到预期效果
6.3 突破准召天花板的方法论
这是工业界最核心的问题之一。准召天花板的突破通常来自以下方向：
┌─────────────────────────────────────────────┐
│ 准召天花板突破路径 │
├─────────────┬─────────────┬─────────────────┤
│ 数据侧 │ 模型侧 │ 策略侧 │
│ · 数据增强 │ · 模型升级 │ · 阈值优化 │
│ · 难例挖掘 │ · 集成学习 │ · 级联策略 │
│ · 标注质量提升│ · 多模态融合 │ · 人机协同 │
│ · 数据配比优化│ · 后训练优化 │ · 分场景策略 │
└─────────────┴─────────────┴─────────────────┘关键认知：ROI 思维
不是所有提升都值得做。每提升 1% 的准确率，需要投入多少资源？这个投入能带来多少业务价值？
ROI 评估框架：
ROI = (效果提升带来的业务价值) / (投入的计算资源 + 人力成本 + 时间成本)在实际决策中，经常需要在以下方案间做取舍：
| 方案 | 效果提升 | 成本 | ROI |
|---|---|---|---|
| 换更大的模型 | +3% | 推理成本 ×4 | 中 |
| 优化 Prompt | +1.5% | 1人天 | 高 |
| 增加标注数据 | +2% | 10人天 + 标注费 | 中 |
| 后训练 SFT | +4% | 训练资源 + 2周 | 视场景 |
| 级联策略 | +2.5% | 架构改造 | 高 |
6.4 评估驱动的实验管理
在大厂中，模型迭代是高频行为。系统化的实验管理是评估体系的重要组成部分：
实验记录模板：
yaml
experiment_id: exp_2025_0612_003
hypothesis: "增加负样本比例可提升精确率"
change_type: data
baseline: exp_2025_0605_001
metrics:
precision: 0.923 → 0.941 (+1.8%)
recall: 0.897 → 0.891 (-0.6%)
f1: 0.910 → 0.915 (+0.5%)
conclusion: "精确率提升显著，召回率轻微下降在可接受范围内，推进线上验证"
next_step: "线上 A/B 测试，观察用户投诉率"7. 第六层：机审与人审协同场景的评估设计
7.1 机审与人审的关系
在内容安全、广告审核、电商信任等场景中，机审和人审不是替代关系，而是协同关系：
全量内容 → 机审模型 → 高置信通过/拒绝 → 直接处理
→ 低置信/边界样本 → 人审队列 → 人工判断7.2 机审模型的评估重点
| 指标 | 说明 | 业务意义 |
|---|---|---|
| 自动化率 | 机审直接处理的比例 | 决定人审成本 |
| 机审准确率 | 机审判断的正确率 | 决定用户体验 |
| 漏放率 | 有害内容被放过的比例 | 安全底线 |
| 误杀率 | 正常内容被误拒的比例 | 用户投诉 |
| 人审一致率 | 机审结论与人审一致的比例 | 系统可信度 |
7.3 评估中的"阈值策略"
机审的核心决策是阈值设定：
模型输出置信度 → 阈值判断 → 通过 / 拒绝 / 转人审阈值评估的关键：
- 不同风险等级应有不同阈值（高风险内容阈值低，宁可误杀）
- 阈值需要动态调整（根据线上反馈持续优化）
- 评估时必须报告不同阈值下的准召曲线，而非单点指标
7.4 人审效率的评估
人审本身也需要评估和优化：
- 人审准确率：人工标注的正确率（通过抽检评估）
- 人审一致性：不同审核员之间的一致性（Kappa 系数）
- 人审效率：单位时间处理量
- 机审对人审的赋能效果：机审预判是否提升了人审效率和准确率
7.5 Agent 在审核场景的评估
当 Agent 被引入审核流程（如自动化工作流、多 Agent 协作审核）时，评估需要额外关注：
- 流程正确性：Agent 是否按照预设流程执行
- 升级判断：Agent 是否正确识别了需要升级的 Case
- 一致性：同一 Case 多次执行结果是否一致
- 可解释性：Agent 的决策理由是否可追溯、可审计
8. 评估体系搭建方法论：一张图讲清楚
8.1 评估体系的四层架构
┌────────────────────────────────────────────────────────────┐
│ Layer 4: 业务指标层 │
│ 用户投诉率 / 转化率 / GMV影响 / 品牌安全 │
├────────────────────────────────────────────────────────────┤
│ Layer 3: 系统指标层 │
│ 自动化率 / 响应延迟 / 吞吐量 / 成本 │
├────────────────────────────────────────────────────────────┤
│ Layer 2: 模型能力层 │
│ 准确率 / 召回率 / F1 / 各维度能力得分 │
├────────────────────────────────────────────────────────────┤
│ Layer 1: 数据与训练层 │
│ Loss曲线 / 数据质量 / 标注一致性 / 收敛速度 │
└────────────────────────────────────────────────────────────┘核心原则：上层指标是下层指标的最终裁判，下层指标是上层指标的诊断工具。
8.2 评估体系搭建的"五步法"
| 步骤 | 动作 | 产出 |
|---|---|---|
| Step 1 | 明确业务目标和约束 | 评估目标文档 |
| Step 2 | 构建分层评估集 | 评估集 v1.0 |
| Step 3 | 选择评估方法和指标 | 评估方案 |
| Step 4 | 建立自动化评估 Pipeline | 评估平台 |
| Step 5 | 闭环：评估→洞察→迭代 | 迭代机制 |
8.3 评估 Pipeline 的自动化设计
一个成熟的评估 Pipeline 应该支持：
- 一键触发：代码提交后自动跑评估
- 多版本对比：自动生成版本间的指标对比报告
- 异常告警：关键指标下降时自动告警
- 可追溯：每次评估的输入、参数、结果完整记录
8.4 常见评估反模式（Anti-patterns）
| 反模式 | 表现 | 正确做法 |
|---|---|---|
| 指标崇拜 | 只追求 Benchmark 分数 | 关注业务指标 |
| 评估集固化 | 一年不更新评估集 | 定期轮换，防止过拟合 |
| 单一视角 | 只看整体指标 | 分场景、分难度、分类别看 |
| 离线即上线 | 离线指标好就直接上线 | 必须经过在线验证 |
| 忽略成本 | 只看效果不看成本 | ROI 思维 |
| 评估与训练耦合 | 用训练数据做评估 | 严格隔离 |
9. 前沿趋势与开放问题
9.1 评估的前沿方向
| 方向 | 描述 | 成熟度 |
|---|---|---|
| 动态评估（Dynamic Eval） | 评估集自动生成和更新，防止污染 | ⭐⭐⭐ |
| 过程评估（Process Eval） | 不只评结果，评推理过程 | ⭐⭐ |
| 对抗评估（Adversarial Eval） | 自动生成对抗样本测试鲁棒性 | ⭐⭐⭐ |
| 多模态评估 | 图文、视频、音频的统一评估框架 | ⭐⭐ |
| Agent 在线评估 | 在真实环境中持续评估 Agent 表现 | ⭐ |
| 自动化评估闭环 | 评估结果自动驱动数据筛选和训练 | ⭐⭐ |
9.2 开放问题
- 如何评估"涌现能力"？ 模型在某个规模突然获得的能力，如何系统化评估？
- 如何评估长期影响？ 模型上线后的长期社会影响如何度量？
- 如何评估多模态 Agent 的"常识"？ 当前缺乏有效的常识推理评估方法。
- 评估的评估（Meta-evaluation）如何做？ 如何判断一个评估方法本身是否靠谱？
9.3 值得关注的工具和框架
| 工具/框架 | 用途 | 特点 |
|---|---|---|
| OpenAI Evals | LLM 评估 | 社区驱动，可扩展 |
| lm-evaluation-harness | Benchmark 评估 | 支持数百个 Benchmark |
| RAGAS | RAG 系统评估 | 专注检索增强生成 |
| AgentBench | Agent 评估 | 多环境、多维度 |
| LangSmith / LangFuse | LLM 应用监控 | 可观测性 + 评估 |
| 自研评估平台 | 业务定制 | 大厂标配 |
10. 写在最后：给求职者和从业者的建议
10.1 面试中如何展示评估能力
如果你正在准备大模型相关岗位的面试（尤其是涉及模型效果评估、Agent、后训练方向的岗位），以下是面试官最看重的能力信号：
| 能力信号 | 如何展示 |
|---|---|
| 体系化思维 | 能画出评估的分层架构，说清每层的关系 |
| 实战经验 | 能讲出具体的评估 Case，包括踩过的坑 |
| ROI 意识 | 能讨论"这个提升值不值得做" |
| 问题拆解 | 面对模糊问题，能拆解为可评估的子问题 |
| 前沿敏感度 | 了解 LLM-as-Judge、Agent Eval 等新范式 |
10.2 日常工作中的评估思维
把评估当作一种思维方式，而不仅仅是一个技术环节。
- 做任何实验前，先想清楚"我怎么知道它有效？"
- 做任何优化前，先想清楚"我怎么量化提升？"
- 做任何决策前，先想清楚"我的评估是否足够可靠？"
10.3 一句话总结
模型效果评估的本质，是在不确定性中建立可靠的决策依据。 谁能建立更靠谱的评估体系，谁就能在模型迭代中做出更正确的决策，最终在业务竞争中胜出。
参考延伸阅读
- Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (2023)
- Liu et al., "AgentBench: Evaluating LLMs as Agents" (2023)
- Ouyang et al., "Training language models to follow instructions with human feedback" (2022)
- Liang et al., "Holistic Evaluation of Language Models (HELM)" (2022)
- OpenAI, "Evals: A Framework for Evaluating LLMs" (2023)
本文持续更新。如果你在实践中遇到了评估相关的难题，欢迎交流讨论。