AI 评估体系

AI 评估体系

flowchart LR
  A["AI 评估体系"]
  A --> B["分类：工程与生产"]
  A --> C["关键词：AI"]
  A --> D["关键词：评估"]
  A --> E["关键词：Benchmark"]
  A --> F["关键词：LLM-as-judge"]

不评估的 AI 系统，不是在“快速迭代”，而是在放大不确定性。评估不是模型做完之后再补的一层报告，而是你能不能安全地改 Prompt、换模型、上 Agent、做路由、控成本的前提。

---

延伸阅读：

• promptfoo —— 开源 LLM 评估与测试工具
• Braintrust —— 评估、可观测性与线上打分平台

---

这篇文章会讲什么

改了一个 Prompt，怎么知道是变好还是变差？ 换了模型，质量有没有掉？ 上线后用户满意度怎么量化？ 一个 RAG 系统答错了，到底是检索问题、Prompt 问题，还是模型问题？ 一个 Agent 没有完成任务，到底是工具设计不对、规划不对，还是评估方法本身不对？

这些问题最后都会指向同一个主题：评估。

传统软件里，很多事情可以靠测试断言来判断：

• 返回值是否正确
• 接口是否报错
• 数据库状态是否符合预期

但 AI 系统不一样。它的输出经常是开放式的、带不确定性的、带上下文依赖的。你很难总是问一句“对还是错”就结束。于是很多团队会本能地回避评估，退回到一种更熟悉、但也更危险的工作方式：

• 改完 Prompt，自己看几条感觉不错
• 换模型，大家手动试几次觉得还能用
• 上线后，靠投诉和工单发现问题
• 评估报告永远排在“后面再做”

短期看，这样似乎节省时间；长期看，它会把整个系统带入一种很典型的失控状态：

• 你不知道哪次改动真的有效
• 你不知道质量下降发生在哪一层
• 你不知道线上问题是偶发还是系统性回归
• 你无法建立团队对“变更是否安全”的共同判断

所以这篇文章想讨论的，不是“评估工具介绍”，而是一套更接近工程实践的评估框架：

• 为什么 AI 评估比传统软件评估更难
• Benchmark 能解决什么，不能解决什么
• 离线评估、在线评估和生产监控如何衔接
• LLM-as-judge 什么时候有用，什么时候会误导你
• 评估流水线该怎么工程化
• 为什么 Agent 和长流程系统需要更不同的评估视角

如果前面的系列文章在讲架构、推理、成本、选型，那么这一篇其实是在补一个最基础、也最容易被拖延的底座：

没有评估，前面的所有优化都很难被稳定证明。

---

1. 为什么评估在 AI 工程里总被低估

一句话概括：

传统软件更容易围绕“功能是否正确”建立断言；AI 系统则经常要围绕“结果是否足够好、足够稳、足够安全、足够可接受”来设计评估。

这个差异会让 AI 评估天然更难，也更容易被逃避。

1.1 AI 输出常常没有天然标准答案

比如这些任务：

• 客服回复
• 长文档总结
• 创意写作
• 对话回答
• 工单分类与建议
• 工具调用规划
• Agent 执行路径

它们的问题不在于完全不可评，而在于答案常常不是唯一的。 你不能简单写一个 assert output == expected_output 就结束。

这就导致很多团队会误以为：

• “不好量化” = “没法评估”
• “没有标准答案” = “只能靠主观感觉”

其实真正的问题不是不能评，而是需要设计更适合该任务的评估对象和评分方式。

1.2 AI 系统的失败经常不是“报错”，而是“看起来正常，其实不好”

传统软件里的失败通常比较显性：

• 500
• 超时
• 权限错误
• 数据不一致

AI 系统里更麻烦的是这些“伪成功”：

• 回答流畅，但事实不对
• 格式正确，但字段语义错了
• 工具调用成功，但调用了错误工具
• 检索到了文档，但引用结论偏了
• Agent 看起来执行了很多步，但其实没完成目标

如果没有评估体系，这些问题会长期伪装成“系统运行正常”。

1.3 AI 迭代很快，越快越需要评估

AI 系统里真正经常变化的东西很多：

• 模型版本
• Prompt
• RAG 策略
• 路由策略
• 工具描述
• 输出 schema
• 安全规则
• 上下文构造方式

变化越快，越需要一个稳定参考系。否则你每次迭代都在“凭印象”做判断。

OpenAI 的 Evals Cookbook 明确把 evals 定位为改进 LLM 集成的重要手段，并提供了针对 prompt 回归、结构化输出、工具使用、响应质量监控等多个 use-case 的评估示例。1

这背后其实说明了一件很现实的事：

AI 工程里的很多改动，只有经过评估，才配叫“优化”；否则更像是没有基线的试验。

---

2. 评估到底在评什么：先分对象，再谈方法

很多评估文章一上来就讲 benchmark、A/B test、LLM judge，但如果不先把“评估对象”拆开，后面很容易混乱。

一个 AI 系统里，通常至少有四类对象需要被评估。

2.1 模型能力评估

也就是：

• 这个模型大体强不强
• 在某类任务上表现如何
• 相比另一个模型是否更适合当前场景

这一层常见会用公开 benchmark 做初筛，也会做自己的模型对比测试。

2.2 系统输出评估

也就是：

• 给定输入，这个系统输出是否满足预期
• 改 Prompt 后有没有变好
• 改路由后有没有回归
• 同一个任务类型下通过率如何

这是很多业务最常做的评估层。

2.3 流水线 / 组件评估

尤其在 RAG、Agent、多步工作流系统里，这层非常关键。

例如：

• 检索召回是否相关
• 重排是否有效
• JSON 输出是否合规
• 工具调用参数是否正确
• Agent 是否真的完成了目标
• 长流程中哪一步最容易失败

如果只评最终输出，而不评中间组件，问题常常很难定位。

Promptfoo 官方文档已经把评估对象扩展到了 RAG、JSON 输出、coding agents、LLM chains 等系统级场景，而不只是“单个 prompt 打分”。2

2.4 生产行为评估

这层不是实验室里的评测，而是上线后的持续质量观测：

• 用户反馈
• 任务完成率
• 转人工率
• 重试率
• 安全违规率
• 长尾失败模式
• 不同租户 / 渠道 / 版本之间的差异

Braintrust 官方文档把 evals、trace、latency、cost、quality 和 online scoring 放在同一体系里，强调可以对生产 traces 持续打分并配置告警。3

这很重要，因为它提醒我们：

评估不应该只发生在“发布前”；真正成熟的评估体系，一定会延伸到生产环境。

---

3. Benchmark：适合做初筛，但绝不是业务效果替代品

先看定义：公开 benchmark 能帮助你快速形成对模型能力边界的粗认知，但它几乎从来不应该成为业务选型的唯一依据。

3.1 Benchmark 真正有用的地方

公开 benchmark 的价值主要在于：

• 快速建立模型大致能力印象
• 做模型 landscape 的初筛
• 发现某模型在特定维度上的明显强弱
• 帮团队建立共同语言

比如：

• MMLU 看多任务知识和理解
• HumanEval / SWE 相关 benchmark 看代码任务
• GSM8K 看数学推理
• MT-Bench 一类看对话表现

它们最适合回答的是：

• 这个模型大体属于什么水平
• 它在哪些维度上可能更有优势
• 它值不值得进入下一轮业务评估

3.2 Benchmark 的边界非常明确

问题在于，公开 benchmark 几乎总会遇到这些局限：

• 偏通用，不贴近你的业务语料
• 偏英文，不代表中文或多语言效果
• 偏学术，不代表生产环境表现
• 很难覆盖你的结构化输出、工具调用、权限边界、长文档链路
• 很难反映你的成本、延迟、失败恢复和用户体验

这意味着，benchmark 更像一个“市场地图”，而不是你的“业务验收标准”。

3.3 更成熟的态度：benchmark 用来缩小候选范围，而不是直接定胜负

所以最合理的用法通常是：

1. 用公开 benchmark 做初筛
2. 筛掉明显不适合的模型
3. 再用自己的任务集做真实评估

如果反过来，只看 benchmark 排名就全量上线，通常会很快遇到一个现实问题：

公开 benchmark 排名不错，不等于在你的系统里就更好用。

---

4. 离线评估：AI 系统的“回归测试”底座

先看定义：离线评估的目标不是完美模拟真实世界，而是建立一个可重复、可比较、可自动运行的基线，防止系统在迭代中悄悄变差。

4.1 Golden Set 是离线评估的核心

最常见的做法是维护一组固定测试集，也常被叫做：

• Golden Set
• Eval Set
• Canonical Dataset
• Regression Suite

它通常由 50 到几百条高价值样本组成，不一定需要很大，但要有代表性。

更关键的是它要覆盖：

• 主流程样本
• 高频样本
• 高风险样本
• 历史失败样本
• 边界 case
• 长上下文或长输出样本
• 格式严格场景
• 安全或拒答边界样本

很多团队最开始只收集“正常样本”，这样评估集看起来分数很高，但一到线上就暴露问题。 真正有价值的 Golden Set，往往包含那些“不好答、容易错、值得持续盯”的样本。

4.2 Golden Set 最好来自真实请求，而不是纯脑补

理想来源通常包括：

• 线上真实用户请求采样
• 客服工单
• 失败案例回放
• 安全测试样本
• 人工构造的边界条件
• 产品和运营特别关心的核心场景

这样做的好处是评估更贴近真实分布。 否则你很容易得到一套“在评估集上很好、在真实世界里不够用”的测试集。

4.3 离线评估应该怎么打分

这取决于任务类型。常见可以分成三类。

第一类：可规则判定

例如：

• JSON schema 是否合法
• SQL 是否执行成功
• 分类标签是否匹配
• 是否包含必需字段
• 是否命中引用
• 工具参数是否合法

这类任务通常优先用规则和程序校验，因为更稳定、可解释、成本更低。

Promptfoo 官方文档明确支持 deterministic assertions、JSON 结构校验、自定义断言和 model-graded assertions。5

第二类：可弱规则 + 人工抽查

例如：

• 总结是否覆盖关键信息
• 改写是否保留原意
• 回复是否符合风格要求

这类任务可以用部分自动规则，再配合人工 spot check。

第三类：开放式质量判断

例如：

• 回答是否有帮助
• 多轮对话是否相关
• Agent 是否完成目标
• 创意写作是否符合要求

这类任务常会用 LLM-as-judge 或人工评审。

4.4 离线评估最核心的价值：防回归

离线评估不是为了证明系统“已经最好”，而是为了在每次改动后回答一个更现实的问题：

这次改动有没有把系统搞坏？

这就是为什么它特别适合接在这些变更后面：

• 改 Prompt
• 换模型
• 调路由
• 调 RAG 召回 / 重排
• 改工具描述
• 上新的结构化输出 schema

一旦评估流水线跑起来，离线评估就会越来越像传统软件里的回归测试： 不能保证没有 bug，但能显著降低“悄悄退化”的概率。

---

5. 在线评估：离线说“看起来更好”，线上才知道“到底有没有更好”

先看定义：离线评估解决的是“可重复比较”，在线评估解决的是“真实分布下是否有效”。

5.1 为什么离线好，不代表线上一定好

离线评估天然有几个优点：

• 成本可控
• 可重复
• 易于做版本比较
• 可快速自动化

但它也有几个天然局限：

• 样本分布可能老化
• 用户行为会变化
• 新场景会不断冒出来
• 某些产品体验只能在线上体现
• 某些质量问题只有在长链路或真实上下文里才会暴露

所以离线评估更像“实验室验证”，而线上评估才是“真实世界验证”。

5.2 在线评估常见的几种方式

A/B 测试

最经典，也最直接。

适合比较：

• 两版 Prompt
• 两个模型
• 两套路由策略
• 两种 RAG 配置

关键不是只看点击率，而是看与你业务目标真正相关的指标，比如：

• 任务完成率
• 二次追问率
• 转人工率
• 付费转化
• 工单关闭率
• 用户停留与复访

用户反馈

例如：

• 点赞 / 点踩
• 五分制评分
• “这条回答有帮助吗”
• 手动纠错与纠偏

它的价值在于覆盖真实场景，但问题是：

• 噪声大
• 反馈率低
• 容易受界面和交互设计影响
• 常常偏向极端体验

所以用户反馈很重要，但不适合单独作为唯一质量信号。

生产行为指标

这类指标看起来不像“评估分数”，但非常有用，比如：

• 重试率
• 追问率
• 会话中断率
• 工具失败率
• 转人工率
• 安全拒绝率
• 任务中途取消率

这些都是很重要的间接质量指标。

5.3 在线评估和离线评估的关系

一个很实用的经验是：

• 离线说差，线上大概率也差
• 离线说好，线上未必真的好
• 线上出现问题，应该反哺回离线集

这就形成了一个真正有价值的闭环：

1. 线上暴露失败模式
2. 把失败样本加入 Golden Set
3. 离线评估补上该场景
4. 以后每次迭代都能防止同类问题复发

这比把离线评估集当成静态资产要成熟得多。

---

6. LLM-as-Judge：非常有用，但绝不能被神化

先看定义：LLM-as-judge 是开放式任务评估里非常实用的放大器，但它不是客观真理，更像一种可扩展、可调校、但会带偏差的评审器。

Promptfoo 官方文档明确提供 llm-rubric 等 model-graded assertions，以及对 conversation relevance、context relevance、context faithfulness、trajectory goal success 等模型评分能力的支持。7 Braintrust 官方文档则支持用 LLM、代码或人工来做 scorer，并支持 trace-level scorer 对整条会话或 agent trace 进行评估。3

这说明 LLM-as-judge 已经不是“研究论文里的想法”，而是很多工程工具的常规能力。

6.1 它为什么有吸引力

因为很多任务很难写规则：

• 总结是否好
• 回答是否相关
• Agent 是否真正完成了任务
• 多轮对话是否保持上下文
• 工具使用是否合理
• 风格和帮助度是否达标

这时 LLM judge 的优势就很明显：

• 成本低于大规模人工评审
• 易于扩展到大样本
• 能快速比较不同版本
• 适合开放式输出
• 可以做多维度评分

6.2 Judge Prompt 设计，比“选哪个 judge 模型”更影响结果

一个常见误区是只讨论 judge 用哪个模型。 但很多时候，更决定评估质量的是：

• 评分标准是否具体
• 是否给出 rubric
• 是否分维度打分
• 是否提供 few-shot 校准样例
• 是否要求解释评分理由
• 是否要求引用依据

更成熟的 Judge Prompt 通常会：

• 明确任务目标
• 定义“好”的标准
• 定义“坏”的具体表现
• 拆成多个维度分别打分
• 避免一句笼统的“请评价质量”

6.3 LLM-as-judge 最常见的偏差

它当然不是没有问题。常见风险包括：

偏向措辞漂亮而不是事实正确

语言流畅、结构清晰的回答，可能更容易拿高分，但不一定更准确。

偏向和 judge 模型风格更相似的输出

judge 自己的价值观和表达偏好，可能影响评分。

在高专业性任务上判断不稳

例如：

• 法律条文适用
• 医学事实
• SQL 逻辑正确性
• 复杂代码行为

这类问题如果没有额外规则和人工复核，judge 很容易自信地打错分。

评分漂移

judge 模型版本变了、judge prompt 变了，历史分数可比性就可能下降。

6.4 更稳妥的使用方式

LLM-as-judge 最适合做的，不是“终极裁判”，而是：

• 开放式任务的大规模初筛
• 多版本横向比较
• 风格、相关性、完整性等软指标判断
• 和规则校验、人审结合后的中间层

换句话说：

有明确对错的任务，优先用规则；难以规则化的部分，再交给 LLM judge。

---

7. RAG、工具调用、Agent：评估对象已经不是“回答文本”这么简单了

很多团队的评估体系之所以不够用，是因为它仍然只围绕“最终回答好不好”来设计。 但一旦系统变成 RAG、工具调用或 Agent，这就不够了。

7.1 RAG 系统要分层评估

至少要拆成这几层：

• 召回是否相关
• 重排是否有效
• 注入上下文是否足够支撑回答
• 回答是否忠实于上下文
• 是否引用了正确来源

Promptfoo 官方文档已经支持针对 RAG 的 context-relevance、context-recall、context-faithfulness 这类模型评分指标。8

这类拆分非常重要，因为一个 RAG 系统答错时，根因可能完全不同：

• 没召回到该文档
• 召回到了，但排序太靠后
• 召回片段不够完整
• 模型忽略了正确证据
• 模型编造了超出证据的结论

如果只看最终“答错了”，你很难知道该优化哪一层。

7.2 工具调用系统要评估“动作正确性”

在工具调用场景里，最终自然语言回答只是最后一层表象。 真正重要的常常是：

• 是否选对工具
• 是否在正确时机调用
• 参数是否正确
• 是否调用了不该调用的工具
• 工具失败后是否恢复合理
• 最终结果是否利用了工具输出

这类任务不能只看“最后答案像不像对”。 因为有时回答看起来没问题，但整个执行路径其实是错误的，或者只是碰巧蒙对。

7.3 Agent 评估要看轨迹，而不是只看结局

Anthropic 在 2026 年 1 月发布的《Demystifying evals for AI agents》中明确强调，agent 的自主性、智能和灵活性同时也让它更难评估，并分享了在真实 agent 场景中设计更严格、更有用 evals 的经验。10

这点非常关键。因为 Agent 和普通问答系统最大的差别之一是：

它不是只输出一个答案，而是在执行一条轨迹。

因此 Agent 评估通常要看：

• 是否完成目标
• 是否在合理步数内完成
• 是否选择了合适工具
• 是否绕路太多
• 是否卡死循环
• 是否在失败后恢复
• 是否触发了高风险动作

Braintrust 的 trace-level scorer 支持针对整条 trace 和完整对话线程做评估，这类设计就非常适合 agent / workflow 场景。9

这意味着，Agent 评估不只是“回答有没有帮助”，而是“这套行为过程是否可靠”。

---

8. 评估指标：不要只盯“准确率”，而要建立多维约束

很多团队会问：AI 系统最重要的评估指标是什么？

更现实的答案通常是：没有单一指标能概括所有场景。

8.1 质量指标

常见包括：

• 准确率
• 通过率
• 任务完成率
• 引用正确率
• 工具调用成功率
• 结构化输出成功率
• 用户满意度
• 人工审核通过率

8.2 延迟指标

尤其在交互式系统里非常重要：

• TTFT
• 总延迟
• P95 / P99
• 长任务完成时间
• 工具调用阶段延迟

8.3 成本指标

如果不和质量一起看，很容易做出“看起来省钱、其实不划算”的优化：

• token / 请求
• 成本 / 请求
• 单位有效结果成本
• fallback 成本
• judge 成本
• 评估运行成本

8.4 安全与风险指标

例如：

• 有害输出率
• 误拒率 / 漏拒率
• 权限越界率
• 数据泄露风险
• 工具误用率
• 高风险动作拦截率

8.5 最关键的一条：要有一个北极星指标，再配约束指标

比如：

• 客服系统：问题解决率 为北极星指标 约束：成本、延迟、转人工率、安全违规率

• 抽取系统：字段正确率 / 结构化成功率 为北极星指标 约束：延迟、成本、重试率

• Agent 工作流：目标完成率 为北极星指标 约束：平均步数、失败恢复率、人工接管率、风险动作误触发率

如果没有北极星指标，团队会陷入“每个指标都重要，但不知道最终要优化什么”的状态。

---

9. 评估流水线：没有工程化，就很难持续

先看定义：评估最怕的不是做不到，而是“每次都得靠人手工跑一遍”。一旦如此，它几乎注定不会长期坚持。

9.1 一条最小可用的评估流水线长什么样

Golden Set / 线上采样集
        ↓
触发评估（手动 / CI / 定时）
        ↓
调用候选系统版本
        ↓
规则校验 / LLM Judge / 人工抽样
        ↓
汇总质量、成本、延迟指标
        ↓
与 baseline 对比
        ↓
Dashboard 展示 / 告警 / 是否允许发布

这条链路里最关键的，不是用什么大平台，而是几件事：

• 数据集是可维护的
• 评估可重复运行
• 评分逻辑是版本化的
• 结果能和 baseline 比较
• 失败能被看见，而不是埋在日志里

9.2 CI 里的评估，不一定要从“全量”开始

一个很实用的做法是分层：

• 轻量回归集：每次 PR 或部署前跑，样本少、速度快
• 全量评估集：每天 / 每周跑，覆盖更广
• 专项评估集：RAG、Agent、安全、长上下文等高风险场景单独跑

这样不会把评估搞成一套太重、没人愿意跑的流程。

9.3 Dashboard 和告警不是锦上添花

Braintrust 官方文档明确支持生产 traces 的在线评分、信号查看和自动规则，这本质上就是把评估结果接到了持续监控层。4

这很重要，因为评估一旦不进入 dashboard 和告警，通常就会停留在“实验室里有个分数”：

• 没人持续看
• 没法关联版本
• 线上回归不能第一时间发现
• 无法和延迟、成本、trace 放到一起看

而成熟 AI 系统最终需要的是：

质量像延迟和错误率一样，成为一个一等监控对象。

---

10. 持续评估：最难的不是跑一次，而是让评估集跟着系统一起成长

AI 系统会发生两种漂移：

• 模型漂移：模型版本、行为风格、工具能力变了
• 数据漂移：用户问题、输入分布、业务场景变了

所以评估不能“做一次就完”。

10.1 为什么评估集会老化

因为真实系统会不断变化：

• 新用户来了
• 新场景出现
• 旧场景比例下降
• 新失败模式出现
• Prompt 和工具设计变了

如果 Golden Set 长期不更新，就会出现一种假象： 评估分数很稳定，但它评估的其实是“过去的问题”。

10.2 一个成熟的评估集更新机制通常包括

• 从线上失败样本持续回捞
• 从用户点踩 / 转人工 / 工具失败样本中抽样
• 定期清理明显过时、失去代表性的样本
• 为新增功能和新风险场景建立专项子集
• 给样本打标签，便于按场景切片分析

10.3 持续评估真正要形成的是“评估飞轮”

一个理想闭环大致是：

1. 新版本上线
2. 线上数据暴露新问题
3. 问题样本进入评估集
4. 离线评估覆盖该问题
5. 后续版本不再轻易复发

这样评估集会越来越贴近真实业务，而不是越跑越空洞。

---

11. 工具怎么选：不要先看平台有多全，而要看你是否真的能把评估跑起来

原文提到的几类工具，定位其实不一样。

11.1 promptfoo：轻量、声明式、适合从测试集起步

Promptfoo 文档明确支持：

• YAML 配置
• 变量化 test cases
• deterministic assertions
• llm-rubric
• JSON 结构评估
• RAG / conversation / trajectory 类模型评分
• CI/CD 集成27

这意味着它非常适合：

• 从 prompt / model regression 开始
• 小团队快速搭一套本地或 CI 里的 eval
• 想把评估变成类似测试用例的资产

它的价值在于上手快、成本低、足够工程化。

11.2 Braintrust：更强调实验、trace、生产评分和协作

Braintrust 的官方介绍和文档里，除了 evals，还明确强调：

• experiments
• traces
• scorers
• online scoring
• alerts
• 质量、延迟、成本的联动观测39

这使它更适合：

• 团队协作
• 线上离线联动
• 需要把评估和生产观测打通
• 需要实验管理、trace 查看和可视化

11.3 工具只是加速器，不是替你定义标准

这点很重要。

无论是 promptfoo、Braintrust，还是别的 eval 工具，它们都不能替你回答：

• 什么才算“好”
• 哪些失败最危险
• 你的北极星指标是什么
• 哪些样本必须进 Golden Set
• 哪些线上信号要进告警

工具只能让你更快、更稳定地执行评估； 评估标准本身，仍然是业务和工程共同定义的。

---

12. 什么时候该让评估真正“卡发布”

这是很多团队走到后面才会问的问题。

一开始你可能只是“跑一下看看”。 但到了某个阶段，评估体系要开始承担更硬的职责：

• 分数掉到阈值以下，不允许发布
• 安全专项评估不过，不允许灰度
• 结构化成功率下降，不允许替换主模型
• 高风险场景评估样本不通过，不允许全量上线

这一步的核心不是“更严格”，而是你开始把评估当成真正的工程护栏，而不是参考意见。

当然，并不是所有指标都适合强卡发布。 更现实的做法是分层：

• 硬门槛：格式正确率、安全红线、严重回归
• 软门槛：帮助度、文风、用户偏好，可先灰度观察

这样既不会因为评估过于理想化而卡死迭代，也不会让“分数再差也能上”。

---

小结

AI 评估体系的核心，不是多跑几个 benchmark，也不是堆一个看起来很全的 dashboard，而是建立一套持续工作的判断机制：

• Benchmark 用来做模型初筛，不是业务效果替代品
• 离线评估 用来建立可重复、可比较、可自动回归的基线
• 在线评估 用来验证真实用户分布下的效果
• LLM-as-judge 是开放式任务里很有用的放大器，但必须与规则、人审和组件级评估配合使用
• RAG、工具调用、Agent 需要分层评估，不能只看最终回答
• 评估流水线 要进入 CI、Dashboard、告警和发布流程，才能真正发挥作用
• 持续评估 的关键不只是重复跑，而是让线上失败样本不断回流，推动评估集进化

如果要把这篇文章压缩成一句话，大概就是：

评估不是 AI 工程的附属品，而是让系统可以安全迭代、可解释优化、持续变好的质量底座。

没有它，你会一直在“感觉上”改进系统； 有了它，你才开始真正拥有一套能被证明的工程方法。

---