一次讲清大模型应用评测：从 Recall@k、LLM Judge 到 Agent 上线门禁
**文章摘要：**大模型应用不能只靠"感觉回答不错"来验收。本文从真实业务目标出发，系统讲清模型、RAG、意图识别、工具调用与 Agent 应该评什么，解释 Recall@k、MRR、nDCG、Macro-F1、FPR/FNR、pass@k 与 pass^k，并给出三类 Grader、评测数据集、Trace、LLM Judge 校准、发布门禁和线上闭环的完整落地方法。
很多团队第一次做大模型评测，通常会从下面几个问题开始：
- 准确率是多少？
- 有没有一个通用 Benchmark 可以证明模型够好？
- RAG 的 Recall@5 达到多少才能上线？
- 开放式回答没有唯一标准答案，应该怎么评分？
- LLM Judge 能不能代替人工？
- Agent 明明说"任务已完成"，为什么还不能算成功？
这些问题都很重要，但如果直接从指标开始，评测很容易变成一张漂亮却无法指导发布的成绩单。
大模型评测真正要解决的是：
在明确的业务目标和风险约束下，这个 AI 系统能否稳定完成真实用户任务；如果失败，失败在哪里；一次成功需要付出多少延迟、成本和人工监督。
这里的"系统"不只是某个模型，而是：
text
模型
+ System Prompt
+ RAG
+ Memory
+ Tools
+ Permissions
+ Agent Loop
+ Runtime Configuration因此，大模型应用评测不是一次模型考试，而是一套贯穿开发、发布和生产运营的工程系统。
一、先建立正确边界：你评的不是模型，而是完整系统
公开 Benchmark 可以比较模型在数学、代码、知识和推理等任务上的能力，但产品中的真实表现还会受到很多因素影响：
- Prompt 是否明确；
- 知识库是否最新；
- Retriever 是否找到了正确证据；
- 上下文是否混入无权限数据；
- 工具描述和参数 Schema 是否准确；
- Agent 是否选择了正确工具；
- 记忆是否过期或串用户；
- 模型版本、温度、Token 预算和重试策略是否变化。
所以，一套完整评测至少需要三层。
| 层级 | 被测对象 | 主要用途 |
|---|---|---|
| 基座模型层 | 模型本身 | 模型初筛、能力画像、成本与延迟比较 |
| 组件层 | 意图、检索、重排、生成、工具、记忆、权限 | 定位问题、快速回归、优化局部能力 |
| 端到端与生产层 | 完整用户旅程和最终业务状态 | 判断任务是否完成、系统能否安全上线 |
三层不能互相替代。
- 只做模型 Benchmark，不知道产品是否解决真实问题；
- 只做组件评测，不知道组件组合后是否完成任务；
- 只看端到端成功率，出了问题又不知道应该修检索、Prompt 还是工具编排。
正确做法是同时保留组件证据和端到端结果。
二、大模型应用到底应该评测什么
1. 任务与业务结果
第一优先级不是"回答像不像人"，而是用户的任务是否真正完成。
常见指标包括：
- Task Success Rate：任务是否达到预期目标；
- End-state Correctness：数据库、订单、工单、文件或日程最终状态是否正确；
- Constraint Satisfaction：权限、合规、时间和流程约束是否满足；
- Human Handoff Quality：需要转人工时是否正确转交，信息是否完整；
- Cost per Successful Task：完成一次成功任务的真实成本。
例如，客服 Agent 回复"已经为你退款"，并不能证明退款成功。评测必须检查：
text
是否完成身份验证
↓
是否调用正确退款工具
↓
订单号和金额是否正确
↓
数据库是否真的生成退款记录
↓
是否发生越权或重复退款对有现实副作用的 Agent，最终文本只是一条证据，真实环境状态才是核心结果。
2. 回答质量
"回答质量"不应该只给一个笼统的 1～5 分，最好拆成独立维度：
| 维度 | 要回答的问题 |
|---|---|
| Correctness | 结论是否正确，是否有事实错误 |
| Completeness | 完成任务所需的关键点是否遗漏 |
| Relevance | 是否直接回答问题，是否包含无关内容 |
| Instruction Following | 格式、语言、长度、范围和禁止项是否遵守 |
| Attribution | 需要证据的结论是否有来源支持 |
| Uncertainty Handling | 证据不足时是否澄清、拒答或表达不确定 |
| Interaction Quality | 表达是否清晰、简洁，语气和下一步是否合适 |
这里必须区分两个容易混淆的概念：
- Faithfulness：回答是否忠实于本次提供的上下文；
- Factual Correctness：回答是否符合真实世界事实或权威答案。
如果知识库里是一份过期政策，模型完全忠实地复述了它，那么 Faithfulness 可能很高，但 Factual Correctness 仍然很低。
3. RAG：检索和生成必须拆开测
RAG 出错至少有两种可能：
- 没有找到正确资料；
- 找到了正确资料，但模型没有正确使用。
因此要分成两层。
检索层主要观察：
- Recall@k、Hit Rate@k、MRR、nDCG@k；
- Context Precision；
- 文档是否权威、最新、版本正确；
- ACL 和租户隔离是否正确；
- 不同语言、问题类型、文档类型和上下文长度下的表现。
生成层主要观察：
- Answer Correctness；
- Claim-level Faithfulness；
- Citation Correctness：引用是否真的支持旁边的陈述；
- Citation Coverage：需要证据的陈述是否都有引用；
- 没有足够证据时，是否正确拒答或澄清。
一个很实用的定位方法是进行两次生成实验：
text
实验 A：使用人工提供的正确证据，即 Oracle Context
实验 B：使用系统实际检索到的 Context- A 正确、B 错误：问题主要在检索；
- A、B 都错误：问题更可能在生成、Prompt 或任务定义；
- B 的资料无权限：问题属于权限或 Context Assembly，而不是普通相关性问题。
4. 意图识别、工具调用与 Agent
意图识别不能只看总体 Accuracy，还应该关注：
- Macro-F1；
- 每个关键意图的 Precision、Recall 和 F1；
- 高风险类别的 False Negative Rate；
- Unknown、Out-of-scope 和 Ambiguous 请求的澄清准确率；
- 多意图、上下文依赖与类别漂移；
- Confidence Calibration。
工具调用与 Agent 还要评测：
- 是否选择了正确工具；
- 是否能正确选择"不调用工具"；
- 参数名称、类型、枚举、时间和实体是否准确；
- 多步或并行调用的依赖关系是否正确；
- 工具失败后能否恢复、重试、降级或转人工；
- 最终业务状态是否正确；
- 是否发生非必要调用、循环调用或未授权操作。
5. 记忆、安全、可靠性与成本
记忆系统至少应测试：该记的信息能否正确写入和找回，不该记的内容是否误存，旧事实能否被更新，不同用户和租户是否隔离，删除请求是否真正传播到索引与缓存。
安全测试至少应覆盖：Prompt Injection、Jailbreak、敏感数据泄露、跨租户访问、Excessive Agency、过度拒绝和资源消耗攻击。
生产工程指标还包括：
- pass@1 与重复运行稳定性；
- P50、P95、P99 延迟；
- Token、工具和基础设施成本；
- Timeout、Retry、Fallback 与降级表现；
- 提示词扰动、输入噪声、长对话和供应商切换下的稳健性。
三、从应用架构反推评测点
与其先收集一堆指标，不如先问：系统在哪些位置引入了不确定性？
| 应用架构 | 新增的不确定性 | 重点评测 |
|---|---|---|
| Single-turn | 单次输入与输出 | 指令遵循、功能正确性、输出格式 |
| Workflow | 多个模型步骤串联 | 每一步的输入输出，以及最终组合结果 |
| Single-agent | 动态选择工具和行动 | 工具选择、参数精度、澄清、恢复、最终状态 |
| Multi-agent | Agent 之间移交控制权 | Handoff 准确率、职责边界、循环移交、成本与延迟 |
例如一个订单查询 Workflow：
text
提取订单号
→ 查询订单工具
→ 解析工具结果
→ 生成用户回复既要逐步测试订单号抽取、工具参数和结果解析，也要测试最终回答是否包含正确状态、时间和追踪信息。
Multi-agent 并不天然比 Single-agent 更高级。多一个 Agent 就多一层路由、状态、权限、延迟和故障边界。是否拆成 Multi-agent，应该由评测证明：只有当单 Agent 在指令规模、工具规模或专业边界上出现可测量瓶颈，而且拆分收益超过复杂度成本时，才值得采用。
四、常用指标怎么理解
1. Recall@k、Hit Rate、MRR 与 nDCG
假设一个问题的检索结果是：
text
[A, B, C, D, E]其中 B 和 D 是相关文档。
Recall@k：相关材料找回了多少
text
Recall@k = Top k 中相关项数量 / 全部相关项数量如果知识库中共有 4 份相关文档，Top 5 找回 3 份：
text
Recall@5 = 3 / 4 = 0.75它表示前 5 条结果覆盖了 75% 的相关材料，而不是"必须找到 5 条相关文档"。
Hit Rate@k：至少命中一个了吗
text
Hit@k = 1，Top k 至少有一个相关项
Hit@k = 0，Top k 一个相关项也没有如果任务只需要找到一个正确入口，Hit Rate 很有用；但它无法区分命中 1 个还是命中全部证据。
MRR：第一个相关结果出现得有多早
对单个查询：
text
Reciprocal Rank = 1 / 第一个相关项的排名前面例子中，第一个相关文档 B 排在第 2 位，因此：
text
RR = 1 / 2 = 0.5MRR 是对所有查询的 RR 求平均。它非常关注第一个正确结果，但基本不关心后续相关文档。
nDCG：高相关度结果是否排在前面
nDCG 同时考虑：
- 排名越靠前，贡献越大；
- 相关性可以不是 0/1，而是核心、一般、弱相关等等级；
- 最终结果归一化到 0～1，便于不同查询之间比较。
选择指标时可以这样记：
| 业务需要 | 优先指标 |
|---|---|
| 需要多个互补证据 | Recall@k |
| 只需命中任意一个入口 | Hit Rate@k |
| 用户主要看第一个有效结果 | MRR |
| 相关性有等级且排序很重要 | nDCG@k |
2. TP、FP、FN、TN 与分类指标
假设把"退款意图"设为正类：
| 真实情况 | 模型预测 | 名称 | 含义 |
|---|---|---|---|
| 退款 | 退款 | TP | 正确识别 |
| 非退款 | 退款 | FP | 误报 |
| 退款 | 非退款 | FN | 漏报 |
| 非退款 | 非退款 | TN | 正确排除 |
由此得到：
text
Precision = TP / (TP + FP)
Recall = TP / (TP + FN)
F1 = 2 × Precision × Recall / (Precision + Recall)
FPR = FP / (FP + TN)
FNR = FN / (FN + TP) = 1 - Recall它们回答的问题不同：
- Precision：模型预测为退款的请求中，有多少真的是退款；
- Recall：所有真实退款请求中，有多少被找出来；
- FPR：所有真实非退款请求中，有多少被误判为退款；
- FNR：所有真实退款请求中，有多少被漏掉。
指标选择取决于错误代价：
- 急救、欺诈和高风险投诉最怕漏报，应重点控制 FNR；
- 自动退款、封禁和现实动作最怕误伤，应重点控制 FPR 与 Precision；
- 一个阈值通常无法同时让误报和漏报都下降，需要结合业务代价选择。
3. 为什么类别不均衡时要看 Macro-F1
Macro-F1 的计算方式是：先分别计算每个类别的 F1，再做等权平均。
text
Macro-F1 = (F1_类别1 + F1_类别2 + ... + F1_类别N) / N假设三个意图的 F1 分别为 0.90、0.80 和 0.30：
text
Macro-F1 = (0.90 + 0.80 + 0.30) / 3 ≈ 0.67即使"普通咨询"占全部流量的 90%，少数但关键的"退款""投诉"仍然与大类拥有同等权重，不会被总体 Accuracy 掩盖。
意图识别至少建议同时报告：
- Macro-F1；
- 每个类别的 Precision、Recall、F1；
- Confusion Matrix；
- 高风险类别的 FNR；
- Unknown / Ambiguous 的澄清准确率；
- 置信度校准；
- 按业务严重度统计的错误数。
4. pass@k 与 pass^k：Agent "能成功"和"稳定成功"不是一回事
Agent 具有非确定性，同一任务多次运行可能得到不同结果。
| 指标 | 含义 | k 增大时 | 适用场景 |
|---|---|---|---|
| pass@k | k 次尝试中至少成功一次 | 通常上升 | 可以生成多个候选，只要一个可用 |
| pass^k | k 次尝试全部成功 | 通常下降 | 面向用户、每次都应该可靠 |
若单次成功率为 75%，并暂时假设每次 Trial 相互独立：
text
pass@3 = 1 - (1 - 0.75)^3 ≈ 98.4%
pass^3 = 0.75^3 ≈ 42.2%这意味着同一个 Agent 可能"多试几次几乎总能成功"，但"连续三次都成功"的概率不足一半。
对候选代码生成，可以关注 pass@k；对直接操作订单、文件或账户的 Agent，更应该关注 pass@1、pass^k 和真实重复运行结果。
五、三类 Grader：不是三选一，而是组合使用
Grader 是对某个表现维度执行评分的逻辑。常见有三类。
| Grader | 适合评什么 | 优点 | 局限 |
|---|---|---|---|
| Code / Metric-based | Schema、数值、工具、测试、数据库状态、延迟、成本 | 快、便宜、客观、可复现 | 不擅长开放式语义 |
| Model-based / LLM Judge | 相关性、完整性、语气、语义等价、证据支持 | 可规模化处理开放式内容 | 有随机性和偏差，需要校准 |
| Human Grader | 高风险、争议、领域专业判断、Judge 校准 | 最接近真实专家标准 | 慢、贵，也存在评审分歧 |
它们不是固定三选一。一条任务完全可以同时使用多个 Grader。
以退款客服 Agent 为例：
text
确定性 Hard Gates
- 是否完成身份验证
- 工具和参数是否正确
- 数据库退款状态是否正确
- 是否发生越权副作用
LLM Judge
- 政策解释是否清楚
- 是否忠实于工具结果
- 语气和同理心是否合格
Human Review
- 校准 Judge
- 复核高风险、争议和 Unknown 样本
- 抽查普通样本一个实用原则是：
能确定性判断的，优先用代码；需要语义弹性的，使用经过校准的模型；高风险、疑难和标准设计交给人。
评分组合通常有三种：
- Binary：所有硬条件都必须通过；
- Weighted：多个质量维度加权达到阈值；
- Hybrid：安全和状态使用硬门禁，开放式质量使用加权分。
生产系统通常应该选择 Hybrid，因为一次跨租户泄露不能被几十条"语气很好"抵消。
六、Agent 评测的对象模型：Task、Trial、Trace 与 Outcome
只保存"输入问题 + 最终答案"，对 Agent 来说远远不够。
一套完整对象关系是：
text
Evaluation Suite
└─ Task
└─ Trial × N
├─ Agent Harness
├─ Environment
├─ Transcript / Trace
└─ Outcome
↓
Code / Model / Human Graders几个核心术语：
| 术语 | 含义 |
|---|---|
| Task | 一条具有输入、初始状态、约束和成功标准的测试 |
| Trial | Agent 对同一 Task 的一次独立尝试 |
| Transcript / Trace | 模型输出、工具调用、中间结果和错误恢复的完整轨迹 |
| Outcome | Trial 结束时数据库、文件、订单、工单或 UI 的真实状态 |
| Evaluation Harness | 创建环境、运行任务、记录、评分和聚合结果的评测基础设施 |
| Agent Harness | Prompt、上下文、工具、Agent Loop 和终止条件等被测运行系统 |
Evaluation Harness 和 Agent Harness 不能混为一谈：前者负责"怎样测试"，后者属于"被测试的系统"。
每个 Trial 应从干净、可重置、尽量接近生产的环境开始。否则，上一次运行留下的缓存、文件、Git 历史或数据库状态可能泄露答案，也可能让多个失败由同一个环境问题引起。
七、真实项目中的完整落地步骤
Step 1：选择一条用户旅程，写清 Eval Contract
不要从"评测整个智能客服"开始，而要从边界清晰的任务开始，例如：
用户咨询会员退款资格；系统必须检索当前政策；若信息足够则回答资格与依据；在没有订单、身份验证和授权时不得创建退款。
Eval Contract 至少要定义：
- 什么叫成功；
- 回答必须包含什么；
- 哪些情况必须澄清、拒答或转人工；
- 允许、要求和禁止哪些工具；
- 期望最终状态；
- 哪些 invariant 绝对不能破坏；
- 延迟、成本、调用次数和风险预算。
指标应该在目标之后选择，而不是反过来用现成指标定义产品成功。
Step 2：记录可回放的完整 Trace
建议至少记录：
trace_id、用户输入、历史消息和时间；- 意图、候选分类和置信度；
- 检索文档 ID、版本、排序、分数与 ACL 决策；
- 读取和写入的记忆；
- Prompt、模型版本和推理参数；
- 工具名、参数、返回值、错误和重试；
- 最终回答、Claim 与 Citation 对应关系；
- 数据库或业务最终状态；
- Token、延迟、成本、转人工和用户反馈。
没有 Trace，看到错误回答时无法判断问题发生在意图、检索、上下文、生成、工具还是业务系统。
Step 3：构建分层数据集
数据来源可以包括：
- 脱敏后的真实生产流量；
- 历史投诉、事故、人工接管和失败案例；
- 领域专家设计的典型任务；
- 长尾、无答案、文档冲突、多意图和多轮场景；
- Prompt Injection、越权、隐私与成本攻击；
- 经过人工检查的合成数据。
建议至少拆成四类集合：
| 数据集 | 用途 | 管理原则 |
|---|---|---|
| Development Set | 快速迭代 Prompt、RAG 和代码 | 团队可见，可频繁运行 |
| Regression Set | 固化历史 Bad Case 和稳定能力 | 每次变更必跑，不轻易删除 |
| Hidden Release Set | 检测泛化并防止对可见题过拟合 | 与开发隔离，定期换新 |
| Red-team Set | 安全、高风险和对抗边界 | 限制访问，持续扩充 |
早期可以采用 80/20 Approach：先把 20～50 条最有价值的真实手测和失败案例变成可重复任务，快速建立反馈闭环。
但要注意：
20～50 条是启动建议，不是生产可靠性的统计证明；低频高危事件也不能因为不符合"高频 80%"而被排除。
Step 4：不要只标注一篇"标准答案"
开放式回答可能有很多种正确说法。只保存一篇标准答案，会把措辞差异误判为错误，也无法评测证据、工具和最终状态。
一条 Eval Case 更适合包含：
json
{
"id": "refund-017",
"input": "我上个月买的会员可以退款吗？",
"context": {
"as_of": "2026-08-21",
"knowledge_snapshot": "kb-2026-08-21",
"initial_state": {"refund_created": false}
},
"expected": {
"intent": "refund_policy",
"evidence": [
{
"doc_id": "refund-policy",
"version": "v7",
"span_id": "refund-window"
}
],
"required_claims": [
"会员退款期限为购买后7天内"
],
"acceptable_paraphrases": [
"会员购买后7天内可以申请退款"
],
"forbidden_claims": [
"退款期限为30天",
"系统已经创建退款"
],
"response_behavior": {
"should_answer": true,
"should_abstain": false
},
"required_tools": ["search_knowledge"],
"forbidden_tools": ["create_refund"],
"expected_end_state": {"refund_created": false},
"invariants": ["不得修改订单或创建退款记录"]
},
"slices": [
"time_sensitive",
"missing_order_id",
"side_effect_prohibited"
]
}这不是要求所有团队照抄同一个 JSON Schema，而是说明以下内容应该分别可判定：
text
意图
+ 证据
+ 必须事实
+ 禁止错误
+ 回答行为
+ 工具边界
+ 最终状态
+ 风险切片Step 5：组件评测和端到端评测一起做
| 子系统 | 固定条件 | 主要观测 |
|---|---|---|
| 意图与路由 | 输入和 Gold Label | Macro-F1、逐类指标、FNR、澄清、校准 |
| Retriever / Reranker | 知识库快照和 Gold Evidence | Recall@k、MRR、nDCG、权限、时效 |
| Generator | Oracle Context 与实际 Context | 正确性、Faithfulness、引用、拒答 |
| Tool / Agent | 可重置 Sandbox 与初始状态 | 参数、调用序列、恢复、最终状态、越权 |
| E2E | 完整系统版本和环境 | 任务成功、安全、稳定性、延迟、成功成本 |
还应主动注入故障：Timeout、Rate Limit、空结果、字段变化、部分失败和服务不可用。只测试所有工具都正常的 Happy Path，无法证明系统具备生产可靠性。
Step 6：固定 Baseline，进行同题配对比较
把当前线上配置固定为 Baseline，包括：
- 模型和模型版本；
- Prompt；
- Retriever、Reranker 和知识库快照；
- 工具定义；
- Agent Loop；
- 推理参数和预算。
Candidate 与 Baseline 使用同一数据、Rubric、Judge 和环境运行。一次实验尽量只改变一个主要变量。
对有随机性的 Agent，同一 Task 应重复多个 Trial，报告：
- pass@1；
- 多次运行成功分布；
- pass@k 或 pass^k；
- 环境失败与 Agent 失败的区分。
Step 7：报告失败结构，而不只是总体平均分
一份能够支持发布决策的报告至少应包含：
- Baseline 与 Candidate 的绝对值和差值；
- 样本数及适当的置信区间；
- 按意图、语言、用户群、风险、文档类型和长度切片；
- 最差切片与历史回归案例；
- 严重错误数量和典型 Bad Case；
- 多次运行稳定性；
- P50、P95、P99 延迟；
- 总成本和 Cost per Successful Task；
- 已知盲区和未覆盖风险。
不要寻找一个"万能总分"。平均分会掩盖类别不均衡、关键切片回退和不可被交换的安全风险。
Step 8：把指标转成发布门禁
门禁可以分为两类：
Hard Gates：
- 跨租户数据泄露不得发生；
- 未授权现实操作不得发生；
- 严重事实错误不得发生；
- 关键业务 invariant 不得被破坏。
Quality Gates：
- 任务成功率达到要求；
- 关键切片不得相对 Baseline 回退；
- RAG、意图和工具等组件指标达到各自阈值；
- 延迟、成本和重试在预算内。
"当前测试集里严重事故为 0"只能说明没有在这批有限样本中观察到事故，不能证明真实风险概率为 0。报告必须同时写明样本量、攻击覆盖和未测场景。
Step 9：从离线门禁进入线上渐进发布
推荐顺序：
text
Offline Eval
→ Shadow
→ Canary
→ A/B Testing
→ 分阶段扩大
→ 持续监控
→ Bad Case 回流 Regression Set- Shadow：接收真实流量，但不影响用户；
- Canary：只向少量低风险流量开放；
- A/B：比较用户结果和真实业务结果；
- 持续监控：观察重复追问、纠错、重新打开、转人工、安全事件、延迟和成本；
- 回流：事故和高价值 Bad Case 固化为回归任务。
这才构成真正的 Continuous Evaluation。
八、LLM Judge 应该怎样校准
LLM Judge 适合对相关性、完整性、语义等价、语气和证据支持进行规模化评分，但它不是真值生成器。
常见偏差包括：
- Position Bias：偏好排在某个位置的答案；
- Verbosity Bias：偏好更长、更详细的答案；
- Self-preference：偏好与自身表达风格或模型来源相近的答案；
- Rubric Ambiguity：评分标准含糊导致不稳定；
- Judge Drift：Judge 模型或数据分布变化后，评分口径发生漂移。
正式使用前建议：
- 让领域专家独立评分一批代表性输出；
- 给 Judge 相同的问题、参考证据和 Rubric；
- 比较 Judge 与专家的一致率及高风险误判；
- 修改 Rubric、示例和输出结构；
- 固定并记录 Judge Version；
- 上线后持续抽样复核，模型升级后重新校准。
开放式评分尽量设计为：
- Pairwise Comparison；
- Classification；
- 分维度 Pass/Fail；
- Reference-guided Grading。
相较于"请自由评价这个答案"，这些任务的边界更明确，也更容易校准。
进行 A/B 盲评时，评审者应该看到问题、答案、参考证据和 Rubric，但不应知道：
- 哪个是线上版本；
- 哪个是候选版本；
- 使用了哪一家模型；
- 团队更希望哪个版本获胜。
A/B 顺序还应该随机化，必要时交换顺序重复评分，以检查位置偏差。
九、Capability Eval 与 Regression Eval 要分开维护
这两类评测的目标不同。
| 类型 | 核心问题 | 任务难度 | 期望通过率 |
|---|---|---|---|
| Capability Eval | 当前能力边界在哪里 | 应包含尚不擅长的困难任务 | 可以较低，并逐步提升 |
| Regression Eval | 过去会做的任务有没有退化 | 稳定能力和历史 Bad Case | 应接近 100% |
当 Capability Suite 长期接近满分时，它已经失去区分能力。此时应增加更难、更长、更多工具或更贴近新能力边界的任务，并把已经稳定掌握的任务转入 Regression Suite。
评测集不是一次性 Benchmark，而是一项需要长期负责人、版本和维护策略的产品资产。
十、资源有限时，如何用 80/20 方法启动
如果团队目前几乎没有 Eval，可以先建立最小闭环：
- 选择 1～3 条最重要的用户旅程；
- 从手测、Bug、投诉和支持记录中整理 20～50 条真实任务；
- 为每条任务定义初始状态、成功 Outcome、禁止副作用和至少一条 Reference Solution；
- 让每个 Trial 从可重置环境开始；
- 保存完整 Trace；
- 先实现 Schema、工具、权限、状态等确定性 Grader；
- 对开放式质量加入分维度 LLM Judge，并用专家样本校准；
- 固定 Baseline，每次变更运行同题比较；
- 人工阅读失败 Trace，修 Agent，也修不公平的 Task 与 Grader；
- 新的生产 Bad Case 持续加入 Regression Set。
80/20 的含义是先用少量高价值任务获得大部分早期反馈，不是只测高频任务，也不是用几十条样本宣称系统已经安全可靠。
十一、最常见的评测误区
误区 1：用公开 Benchmark 代替产品评测
Benchmark 可以做模型初筛，但无法覆盖你的知识库、工具、用户分布、权限和业务状态。
误区 2：Vibe-based Eval
"试了几个问题，感觉还不错"不可重复，既无法区分真实提升与随机波动，也无法发现回归。
误区 3：只看一个总体分数
高频普通问题会掩盖低频高风险问题；大量流畅回答不能抵消一次严重越权。
误区 4：只准备一篇标准答案
开放式任务存在多种正确表达。应该标注必须事实、可接受说法、禁止错误、证据和行为边界。
误区 5：Agent 只评最终文本
Agent 可能声称成功，但工具未执行或数据库状态错误。必须检查 Trace 和 Outcome。
误区 6：把 LLM Judge 当作真值
Judge 会有位置、长度和 Rubric 偏差，必须用人工标签校准并保存版本。
误区 7：直接复制别人给出的阈值
Recall@5 = 0.85 或某个 Judge Score，只能在具体数据、风险和业务目标下解释。不存在通用及格线。
误区 8：只测试 Happy Path
真实生产中一定会遇到空结果、超时、限流、字段变化、多意图、长上下文、权限冲突和恶意输入。
误区 9：所有测试都对开发者可见
持续针对可见回归集优化会产生过拟合。应该保留 Hidden Release Set，并不断吸收新的真实分布。
误区 10：一开始就使用 Multi-agent
Multi-agent 会增加 Handoff、循环、状态、成本和运维复杂度。先用 Eval 证明单 Agent 的瓶颈，再决定是否拆分。
十二、一张可以直接使用的评测报告模板
text
1. 本次变更
- Baseline 版本
- Candidate 版本
- 唯一主要变量
2. 数据与协议
- 数据集版本、样本数和切片
- 环境与知识库快照
- Judge / Grader 版本
- Trial 次数
3. 核心结果
- Task Success Rate
- End-state Correctness
- Hard-gate Violations
- Cost per Successful Task
4. 组件指标
- Intent：Macro-F1、逐类 Recall/FNR
- RAG：Recall@k、MRR、nDCG、Citation
- Tool：Selection、Arguments、Execution
- Generation：Correctness、Faithfulness、Completeness
5. 可靠性与工程指标
- pass@1、pass@k / pass^k
- P50 / P95 / P99 Latency
- Token、工具调用和总成本
6. 风险与失败结构
- 最差切片
- 严重错误和 Bad Case
- 与 Baseline 的回归
- 已知盲区和未测风险
7. 发布结论
- Hard Gates：Pass / Fail
- Quality Gates：Pass / Fail
- Shadow / Canary / Rollback 方案十三、最终检查清单
上线前可以逐项确认：
- 被评对象包含模型、Prompt、RAG、工具、记忆、权限和运行配置；
- 成功标准来自真实用户任务，而不是现成指标；
- 同时存在组件评测和端到端评测；
- Agent 评测检查 Trace 与真实 Outcome；
- 数据集包含典型、边界、无答案、故障和对抗场景；
- Development、Regression、Hidden、Red-team Set 分开管理；
- 高风险切片不会被总体平均分掩盖；
- 确定性条件优先使用代码 Grader；
- LLM Judge 已用人工样本校准并记录版本；
- 随机 Agent 对同一任务执行多个独立 Trial；
- Baseline 与 Candidate 使用同题、同环境、同评分协议；
- 发布门禁同时包含 Hard Gates 与 Quality Gates；
- 离线通过后仍采用 Shadow、Canary 或 A/B；
- 生产 Bad Case 会持续回流回归集。
结语
专业的大模型评测，不是寻找一个万能指标，也不是选择一个"最强 Judge"。它本质上是一套持续回答以下问题的系统：
text
用户任务是否完成？
↓
失败发生在哪一层？
↓
失败是否安全、可恢复？
↓
系统是否稳定、经济、可发布？
↓
新问题能否回流并防止再次发生？如果只能记住一句话，可以记住：
从业务成功定义评测目标，从系统不确定性拆分评测点，用代码、模型和人工组合评分，再让生产 Bad Case 持续回流。
当这条闭环真正建立起来，Eval 才不再是一份发布前的成绩单，而会成为大模型产品迭代最重要的工程基础设施之一。
参考资料
- OpenAI Docs：Evaluation best practices
- Anthropic Engineering：Demystifying evals for AI agents
- RAGAS：Automated Evaluation of Retrieval Augmented Generation
- Berkeley Function-Calling Leaderboard
- τ-bench：A Benchmark for Tool-Agent-User Interaction in Real-World Domains
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
- NIST AI 600-1：Generative AI Profile
- OWASP Top 10 for Large Language Model Applications