当前位置：首页 > news >正文

Agent 评测系统架构：从指标分层到 GT/Judge 闭环的工程化落地

news 2026/7/9 12:51:47

拆解 Agent 评测如何用指标分层、GT 来源和 Judge 校准，形成可回归的质量闭环。
原文链接：AI 小老六

导语

Agent 上线后，最难回答的问题往往不是“模型有没有变强”，而是“这个 Agent 在业务里到底有没有帮上忙”。传统软件可以用单测、集成测试、覆盖率来兜住质量，Agent 却绕不开自然语言判断：一句回答是否有用、一次路由是否准确、一段诊断是否真的缩短了排障时间，都不是字符串相等能解决的事。

评测系统要解决的是这个落差。它不能只给一个漂亮的总分，也不能靠几条人工样本临时验收。更可靠的做法，是把业务价值拆成几层能独立观测的信号，再用线上行为、LLM 推断和人工 Golden Set 组成 Ground Truth 来源，最后把LLM-as-Judge放进一个可校准、可回归、可持续运行的工程闭环。

这篇文章不展开具体项目故事，只讨论一套可复用的 Agent 评测架构：指标怎么分层，GT 怎么拿，Judge 怎么防偏，知识库和诊断类 Agent 又该怎样接入同一套评测引擎。

Agent 评测的工程矛盾：语义正确性、业务价值和持续运营

图：将自然语言输出、行为信号和业务结果拆成可观测评测层

Agent 评测有三类麻烦，任何一类处理不好，分数都会变得不可用。

第一类是准确性。Agent 的输出通常是自然语言或多步执行结果，正确性强依赖领域知识。一个故障诊断回答可能方向对了，但证据不够；一个知识库回答可能引用了来源，却漏掉了关键约束。二值的“对/错”很难承载这些中间态。

第二类是有效性。Agent 做对了一件事，不等于业务一定变好。回答准确率、路由准确率、诊断采纳率、MTTR 降低幅度属于不同层次的信号，混在一起只会让问题失焦。

第三类是在线运营。离线评测集会过期，线上行为信号又稀疏且带噪声。评测系统必须能持续吸收新问题、识别 badcase、校准 Judge，并在每次版本变更后快速跑出可比较的结果。

图：Agent 评测面对的准确性、有效性、稳定性和在线运营挑战

这也是为什么通用 benchmark 不够用。HELM、AgentBench 这类基准可以告诉我们模型或 Agent 在标准任务上的能力，但业务评测要回答的是另一件事：在一个具体系统里，Agent 是否产生了可验证、可归因、可持续追踪的价值。

指标分层：不要把业务结果和 AI 质量揉成一个数

评测体系的第一步是分层。SRE 里常用 Four Golden Signals 区分系统健康、流量和业务 SLO；Agent 评测也需要类似的拆解。底层信号要快、自动、可定位；顶层信号要接近业务价值，但可以周期更长。

层级	关心的问题	典型指标	用法
AI 性能指标	Agent 能不能稳定运行	成功率、错误率、P99 耗时、TTD	实时发现系统故障和链路退化
AI 质量指标	Agent 做得对不对	路由准确率、知识准确率、Faithfulness、KeyPoints Coverage	定位模型、召回、工具调用或 Prompt 问题
AI 有效性指标	Agent 是否被业务采纳	覆盖率、采纳率、有效回复率	判断 Agent 是否触达并解决真实问题
业务结果	引入 Agent 后业务是否变好	MTTR、定位时长、人工处理成本、SLO 改善	评估投入产出，通常周期更长

这种分层的价值在于归因。比如“有效诊断率”下降，不一定说明模型变差。可能是覆盖率下降，Agent 没有触达足够多的场景；也可能是诊断质量下降，工程师看到了但不采纳；还可能是整体 Oncall 流量结构变了。一个总分无法区分这些原因。

一个更可用的拆解方式是：

AI 有效诊断率 ≈ 诊断覆盖率 × 诊断采纳率诊断覆盖率 = 产生 AI 诊断卡片的 Oncall 数 / 总 Oncall 数诊断采纳率 = 被工程师采纳的 AI 诊断卡片数 / 产生 AI 诊断卡片的 Oncall 数

如果覆盖率低，应该先检查触发策略、白名单、召回入口和工具可用性；如果采纳率低，才进入诊断内容质量、证据完整性和 Judge 评分标准的排查。

图：性能、质量、有效性与业务结果之间的支撑关系

Ground Truth 生成：线上信号优先，LLM 推断兜底，人工集校准

图：从线上确认、上下文证据到人工 Golden Set 的 GT 生产链路

Agent 评测的上限，常常不是 Judge 模型决定的，而是 Ground Truth 决定的。GT 不可信，后面的评分再复杂也没有意义。

可以把 GT 来源分成三类。

GT 来源	适用场景	优点	风险
线上行为信号	用户有明确操作反馈，如点击采纳、确认处理、选择团队	实时、低成本、贴近真实业务	覆盖不全，沉默用户无法解释
LLM 推断	有上下文但没有直接标注，如从群聊推断实际处理团队、从对话判断诊断是否被采纳	自动化、覆盖更广	需要防幻觉，必须有置信度和排除机制
人工 Golden Set	知识库问答、关键业务规则、无法从行为推断的内容	最可靠，可复用	成本高，会过期，需要维护

工程上不建议把三者看成互斥方案。更稳妥的策略是分级兜底：

图：线上信号、LLM 推断和人工 Golden Set 的分级兜底机制

这里最关键的原则是“无法判断时排除，而不是猜”。把噪声样本硬塞进分母，会让指标看起来覆盖更全，实际上是在稀释判断力。

对于路由类问题，线上按钮点击往往是最可靠的信号；没有点击时，可以用群聊里的处理人、关闭前最后处置人、明确“已修复/已回滚”的发言来推断；仍然无法解析时，就不要计入准确率分母。对于知识库问答，人工核准的标准答案和 Key Points 更适合作为 GT，线上 query 可以用来扩充问题池，但不能自动升级成准确率评测集。

LLM-as-Judge：先拆任务，再评分

图：用事实抽取、分项评分和人工抽检降低 Judge 偏差

LLM-as-Judge 很好用，也很容易被用坏。常见偏差包括位置偏差、冗长偏差和自我增强偏差。更长的回答看起来更“完整”，排在前面的答案更容易被偏袒，同源模型也可能对自己的输出更宽容。

可靠的 Judge 设计不是让模型“一步给分”，而是把判断拆开。

几个细节很重要。

设计点	解决的问题	推荐做法
任务拆解	一步评分容易幻觉	先抽取根因和证据，再进入评分
三级评分	二值评分看不到中间改进	使用 0 / 0.5 / 1 捕捉“方向对但证据薄”的状态
Gating 熔断	冗长回答可能拿虚高分	结论准确性为 0 时直接 rejected，不再加权
业务类型打标	不同问题的满分标准不同	先识别 issue_tag，再按类型套评分标准
异源裁判	既当选手又当裁判	Judge 模型和被评 Agent 不同源，且不读取被评系统内部状态
人工抽检	Judge 偏差会积累	每轮抽 3%~5% 样本复核，用于修 Prompt 和阈值

知识库评测也适合类似结构。准确率不应该只看“回答像不像标准答案”，而要拆成三个维度：

指标	权重	检测对象
Answer Relevancy	0.2	是否回答了目标问题，是否偏题或用通用话术搪塞
KeyPoints Coverage	0.5	是否覆盖人工核准的必答要点，是否漏掉关键边界条件
Faithfulness	0.3	是否有出处支撑，是否与来源材料冲突或无中生有

其中 KeyPoints Coverage 通常最有价值。很多知识库回答看上去写了不少，其实漏掉了“例外条件”“适用边界”“违反规则后的处理方式”。整体相似度很难抓住这类问题，逐条 Key Point 判定更稳。

覆盖率判定：识别“看似回答，实际拒识”

知识库 Agent 的覆盖率不是“有没有吐出文字”。真正要判断的是：知识库是否掌握了这个问题需要的知识，并且回答是否建立在可追溯的证据上。

有些系统不会直接说“不知道”，而是输出领域通用知识、反问用户补充信息，或者确认政策存在但不给具体内容。这些都属于未覆盖，只是形式比显式拒识更隐蔽。

图：结构化信号与 LLM 偏转检测结合判断覆盖状态

覆盖率和准确率必须分开看。覆盖率高、准确率低，说明系统愿意回答但答得不稳；准确率高、覆盖率低，说明系统保守，能答的范围太窄。把二者合成一个分数，会把完全不同的工程问题盖住。

评测数据集：L1 问题池和 L2 Golden Set 分工

一套评测集同时承担“看覆盖面”和“看准确性”会很吃力。更可维护的设计是两层数据集。

层级	作用	关键字段	准入标准
L1 问题池	覆盖率分母，越全越好	问题、来源文档、优先级、LLM 草稿答案、Key Points 初稿	可由线上 query、文档切分、LLM 扩展生成
L2 Golden Set	准确率和回归基准，越精越好	L1 字段 + 人工核准标准答案 + 人工核准 Key Points	必须人工核准，P0 问题优先进入

问题优先级也要进入数据结构。

优先级	含义	处理方式
P0	必须答对，答错会造成实质影响	强制升级 L2，进入回归红线
P1	应该答对，答错会明显影响体验	优先升级 L2
P2	补充知识或低频问题	可长期停留 L1，先扩大覆盖率分母

L1 可以通过三类来源融合构建：历史用户 query、权威文档切分后的知识点、LLM 从边界条件和跨章节关系中补充的问题。这里 LLM 适合做批量扩展，不适合直接做最终裁判。它生成的答案和 Key Points 必须带“待验证”标记，人工核准后才能升级成 L2。

问题池大小也要和告警精度匹配。50 道题只能可靠捕捉较大的覆盖率变化；100 道题可以看 3% 左右的波动；如果希望把 2% 作为回归告警阈值，问题池通常需要扩到 300 题量级。

稳定性评测：pass@k 看上限，pass^k 看下限

Agent 的非确定性决定了“跑一次通过”不够。多次运行可以回答两个完全不同的问题。

指标	定义	衡量对象	适用场景
pass@k	k 次中至少 1 次通过	峰值能力：Agent 有没有可能做到	新能力探索，看上限
pass^k	k 次全部通过	稳定性：Agent 是否每次都能做到	生产上线门槛，看下限

如果 pass@1 高但 pass^5 低，说明系统处在“偶发成功”状态。它有能力答对，但不可靠。对故障定位、安全审计这类关键决策 Agent，pass^k 的失败容忍度应该接近 0；对辅助分析类 Agent，可以接受少量波动；对创意生成或代码建议类场景，多样性本身是特性，稳定性阈值可以更宽。

Agent 类型	pass^k 失败容忍	原因
关键决策类	0%	任意一次失败都可能造成严重误判
辅助分析类	≤ 10%	偶发偏差可通过人工复核兜底
创意生成类	≤ 40%	输出多样性本身有价值

评测集生命周期：能力集找上限，回归集守底线

图：能力探索、badcase 修复和回归红线构成持续运营闭环

单一评测集很快会失效。更健康的做法，是把评测集分成 Capability 和 Regression 两类。

类型	核心问题	目标通过率	更新方式	触发机制
Capability 能力测评集	Agent 能把什么做好	起步 20%~50%，随迭代爬坡	频繁调整，加入新能力和边界场景	新 Skill、新链路、新能力开发时启动
Regression 回归测评集	原有能力是否还在	接近 100%	只增不减，作为守门员	每次 PR、CI、模型或知识库版本更新触发

两类集合之间要有流转机制：

图：线上 badcase 从能力集沉淀到回归集的持续运营链路

这样评测系统就不只是验收工具，而是持续改进机制。线上发现的 badcase 会进入能力集，修复稳定后沉淀为回归红线，后续版本不能再把同一个坑踩回去。

落地顺序：先跑通基线，再补全自动化

大型评测体系不要一口吃完。比较现实的顺序是：

Phase 1：跑通核心链路 - 打通目标 Agent 接口到评测引擎的数据通路 - 先做 P0 问题，构建 30–50 条最小评测集 - 算出第一版基线，明确当前质量水位 Phase 2：补全能力和自动化 - 扩充 L1 问题池，分层管理 P0/P1/P2 - 接入 LLM Evaluator、覆盖率判定和回归告警 - 建立趋势看板，版本变更后能自动比较 Phase 3：进入持续运营 - 按周期抽检 Judge 偏差 - 根据线上 badcase 扩充评测集 - 支持多 Agent、多知识库横向对比

第一阶段最重要的是跑出可信基线，而不是追求评测集完美。只要分层指标、GT 来源和回归触发机制先站住，后续问题池、Judge Prompt、Adapter 和看板都可以迭代。

结语

Agent 评测不是给模型打一个分数，也不是上线前做一次抽查。它更像一套质量基础设施：底层看运行稳定性，中层看回答和动作是否正确，上层看业务是否真的被改善。

这套基础设施的关键不在复杂，而在克制。指标分层，不把不同问题揉成一个总分；GT 分级，不把猜测伪装成事实；Judge 拆解，不让模型一步做完所有判断；评测集分生命周期，不让一次性验收变成长期幻觉。

当这些机制连起来，Agent 的每次改动就能留下可比较的质量轨迹。团队不再靠感觉判断“好像变聪明了”，而是能看到它在哪一层进步，在哪一层退化，哪个 badcase 已经修掉，哪个红线不能再破。