第 25 章：垂类评测方法论与行业案例

25.1 通用框架可以迁移，风险标准必须重建

客服 Agent 的评测体系已经比较成熟：有指标树、Eval Case、RAG 评测、工具评测、红队、门禁和线上监控。现在团队希望把这套方法迁移到金融客服。

如果只是复用样本和指标，会很快遇到问题。

金融客服不仅要回答业务问题，还要处理投资建议边界、适当性义务、风险揭示、合规话术和用户资产隐私。医疗、代码、AIOps、多模态和具身智能也都有不同的高风险边界。

垂类评测的原则是：方法框架可以复用，风险定义、Rubric、专家仲裁和门禁阈值必须按行业重建。

本章的定位是“迁移方法”，不是医疗、金融、AIOps、多模态或具身智能的行业合规指南。行业案例只用于说明同一套评测闭环如何替换行业语义：把业务目标换成行业任务，把风险清单换成行业事故，把通用 Rubric 换成专家标准，把发布门禁换成行业红线。任何涉及监管解释、诊疗建议、投资建议或高影响操作的具体规则，都应由对应领域专家、合规团队和业务负责人共同确认。

25.2 垂类适配流程

垂类评测适配可以按六步进行。

步骤	目标
专家访谈	获取行业任务、风险和真实事故
事故复盘	从历史失败中抽取高价值场景
规范转化	将行业规则转成评测用例和 Rubric
样本分层	构建核心、回归、高风险和红队样本
专家仲裁	对争议样本建立裁决标准
门禁上线	将高风险指标接入发布流程

这套流程与客服 Agent 主线一致：从业务目标出发，拆风险场景、指标、数据和门禁。

25.2.1 垂类迁移的三个不可复用

从客服 Agent 迁移到其他行业时，最容易误用的是“把原有指标和样本复制过去”。真正可复用的是闭环方法，不可直接复用的是行业判断。

不可直接复用	原因	迁移动作
风险等级	不同行业的错误代价不同	重新定义 P0 / P1 / P2
Rubric 权重	行业对正确性、安全、体验的优先级不同	由领域专家重建评分标准
门禁阈值	可接受风险和监管要求不同	结合业务影响和合规要求设定

例如，客服场景中的“回答不够清楚”可能只是体验问题；医疗场景中的“不确定性表达不清楚”可能导致用户误解健康风险；金融场景中的“收益表达不严谨”可能触发合规问题。

垂类评测的核心动作，是把通用闭环中的每个节点换成行业语义：业务目标换成行业任务，风险清单换成行业事故，指标树换成专家 Rubric，评测数据换成行业 Case，门禁换成行业红线。

25.3 领域专家如何参与

垂类评测不能只由评测工程师完成。领域专家至少参与四件事：

定义高风险场景。
编写或审查 Rubric。
标注关键样本。
仲裁争议 Case。

专家不需要参与所有样本标注，但必须参与标准建立。否则评测系统会用通用语言偏好替代行业判断。

例如，医疗问答中，一个回答语气温和、结构清晰，但如果越过诊疗边界给出具体用药建议，仍可能不合格。

25.3.1 专家仲裁要产品化

专家参与不能停留在“请专家看一批样本”。出版级、企业级的垂类评测，需要把专家判断沉淀为可复用资产。

专家活动	应沉淀的资产
场景访谈	高风险场景表、事故类型、任务边界
样本标注	标注指南、正反例、争议记录
Rubric 审查	评分维度、扣分规则、一票否决项
分歧仲裁	仲裁案例库、优先级规则、边界说明
发布评审	门禁阈值、风险接受条件、豁免规则

专家最宝贵的不是一次性标注劳动力，而是行业判断结构。评测团队要把这些判断转成 Rubric、样本、Evaluator 校准集和门禁规则。

例如金融客服中，“这是投资建议还是风险教育”经常存在边界分歧。专家仲裁后，应形成可引用的边界案例：哪些回答只能引导查看材料，哪些可以解释产品条款，哪些必须提示联系持牌顾问。

25.3.2 专家样本要覆盖“看似正确但不可接受”

垂类评测中，最有价值的专家样本往往不是明显错误样本，而是看起来表达合理、实际违反行业边界的样本。

行业	看似正确	不可接受原因
医疗	回答给出具体药物和剂量，语气谨慎	越过远程诊疗边界，缺少病史和医生判断
金融	解释产品优点并建议买入	可能构成不适当投资建议
代码	测试通过且回答自信	可能删除断言或引入安全漏洞
AIOps	给出快速恢复命令	可能扩大故障影响或绕过变更审批
多模态	图像符合提示且美观	可能侵犯版权或违反品牌安全

这些样本能校准 Judge 和评测团队的行业敏感度。没有这类样本，自动评估器很容易奖励“表达自然”，却漏掉专业红线。

25.4 医疗健康

医疗健康评测重点不是“回答得像医生”，而是安全边界。

高风险维度包括：

维度	评测重点
医学事实	是否符合权威医学知识
诊疗边界	是否避免替代医生诊断
风险提示	是否提示紧急症状和就医路径
药物安全	是否避免错误剂量和禁忌建议
隐私保护	是否保护病史和身份信息
不确定性表达	是否说明不能远程确定诊断

医疗评测需要专家 Rubric 和严格人工复核。通用 Judge 不能独立裁决高风险医学建议。

25.5 金融科技

金融场景的核心是合规和风险揭示。

高风险维度包括：

维度	评测重点
投资建议边界	是否避免向不适当用户给出具体买卖建议
适当性义务	是否考虑用户风险承受能力
风险揭示	是否充分说明产品风险
合规话术	是否符合机构要求
资产隐私	是否保护账户和交易信息
误导性承诺	是否避免保证收益

将客服 Agent 方法迁移到金融客服时，原来的“回答正确性”要增加“风险揭示充分性”和“投资建议边界”指标。

例如，用户问“我现在能不能买这个基金”，合格回答不能直接说“可以买”，而应说明需要结合风险承受能力、投资目标、产品风险等级，并引导用户查看合规材料或联系持牌顾问。

25.5.1 客服 Agent 迁移到金融的关键差异对照表

将企业客服 Agent 的评测体系迁移到金融场景时，不是简单换一批测试题，以下维度必须重建：

维度	通用客服 Agent	金融客服/投顾 Agent	迁移要点
P0 风险定义	越权查询、错误退款承诺	违规投资建议、未做适当性匹配、保本承诺、泄露持仓	P0 范围大幅扩展，涉及买卖建议均需重新定级
正确性评判	政策忠实、答案与知识库一致	不仅要正确，还必须充分揭示风险，缺风险提示即不合格	增加“风险揭示完整性”作为独立维度
Judge 适用性	语义质量、表达清晰度可由 Judge 评估	投资建议边界、适当性义务须由规则+专家+合规审核	Judge 在金融高风险场景不可单独裁决
人工复核	高风险退款、Judge 低置信需复核	所有涉及产品推荐、买卖建议的样本必须人工+合规双重复核	复核比例显著提高，合规角色必须介入
门禁策略	P0 一票否决，P1 阻断，P2 监控	合规类指标全部硬阻断，适当性匹配缺失等同于 P0	门禁更严格，灰度中合规问题零容忍
线上监控	转人工率、投诉率、追问率	增加投诉中合规关键词监控、监管抽检合格率	线上信号必须对接合规部门
证据链要求	Run 血缘、Trace、日志	还需保留完整对话、风险提示文本、用户确认记录满足审计	证据保留周期更长，字段更全
数据隔离	训练-评测数据隔离	增加用户真实对话数据不得直接用于训练的合规隔离	数据使用必须经过脱敏和合规审批

核心原则：金融场景中，“说对话”和“不说错话”同等重要。一个回答事实正确但缺少风险揭示，在通用客服中可能是 P2，在金融中是 P0。

25.6 代码 / 软件工程 Agent

代码 Agent 的评测对象包括代码质量、测试、依赖、安全和执行过程。

关键指标：

测试通过率。
修改范围是否合理。
是否引入安全漏洞。
是否破坏依赖兼容。
是否修改无关文件。
是否能解释修复原因。
沙箱资源是否可接受。

代码 Agent 不能只看最终测试通过。它可能通过硬编码、跳过测试、删除断言或修改无关模块达成表面成功。

因此，代码评测要包含仓库 diff 检查、安全扫描、测试覆盖和过程 Trace。

25.7 多模态生成

多模态评测需要处理文本、图像、视频、音频之间的一致性。

关键维度：

维度	说明
文本-图像对齐	生成内容是否符合提示
空间一致性	物体位置、数量和关系是否正确
时序一致性	视频中人物、动作和场景是否连贯
安全内容	是否生成敏感、不当或违规内容
版权风险	是否过度模仿受保护风格或角色
可控性	局部编辑是否只影响目标区域

多模态评测通常需要人工、模型评估和规则检测组合，且更依赖样本可视化审查。

25.8 AIOps / 企业运维

AIOps Agent 面向监控、告警、诊断和操作建议。

高风险维度：

根因诊断是否准确。
是否误判变更影响。
是否遵守 SLA 优先级。
是否给出危险操作建议。
是否区分建议和自动执行。
是否保留审计证据。

例如，Agent 面对数据库延迟告警，不应直接建议重启核心服务，而应先收集指标、排查变更、判断影响范围，并给出低风险验证步骤。

AIOps 评测需要沙箱或仿真环境，不能只用静态问答。

25.9 端侧与具身智能

端侧和具身智能评测更接近真实环境系统评测。

关键维度：

维度	说明
真机稳定性	设备差异、系统版本、传感器误差
功耗	电池和性能限制
弱网	网络波动下的功能退化
Sim2Real	仿真结果到真实环境的迁移
安全动作	是否避免危险动作
人机交互	用户是否能理解和干预

这类评测更强调环境保真度、物理安全和长周期稳定性。

25.10 垂类最小可用评测体系

没有完整专家团队时，也可以先建立最小闭环。

最小可用垂类评测体系包括：

选一个高价值业务场景。
找 1-2 名领域专家做访谈。
抽取 50-100 条真实或模拟样本。
定义 5-8 个核心 Rubric 维度。
建立高风险样本小集。
用人工校准 Judge 或规则。
接入最基本发布门禁。
从线上 Bad Case 持续补充。

不要一开始追求覆盖整个行业。先把一个高风险场景做成闭环，再扩展。

25.10.1 从客服 Agent 迁移到垂类场景的检查表

企业可以用客服 Agent 的闭环作为迁移模板，但迁移时必须逐项替换行业语义。

客服 Agent 资产	垂类迁移时要重建什么
用户意图分类	行业任务分类和高风险意图
退款 / 订单政策	行业规范、专业知识和适用条件
身份核验规则	行业权限、资质、授权和隐私规则
转人工策略	专家介入、人工审批、线下服务路径
工具调用 Case	行业系统、操作副作用和终态校验
Red Team 样本	行业特定诱导、越权和滥用路径
线上监控指标	行业事故、投诉、合规和业务结果指标

迁移成功的标志不是新行业也有一套表格，而是每个评测资产都能回答该行业的真实风险问题。医疗要回答诊疗边界和用药安全，金融要回答适当性和风险揭示，代码 Agent 要回答仓库安全和修改合理性，AIOps 要回答操作安全和故障影响。

25.10.2 垂类评测的最小验收标准

一个垂类评测体系即使规模不大，也应满足最小验收标准。

验收项	标准
场景聚焦	至少选定一个高价值、高风险或高频任务
专家参与	至少有领域专家参与风险定义、Rubric 和争议样本仲裁
风险分级	明确哪些错误阻断发布，哪些进入审批或观察
样本分层	区分核心样本、回归样本、高风险样本和红队样本
证据要求	明确回答必须基于哪些行业知识、规则或工具结果
人评校准	高风险和争议样本不能只依赖通用 Judge
门禁接入	至少将少量行业红线接入发布流程
线上回流	行业 Bad Case 能进入回归和专家复核

这套验收标准能避免垂类评测停留在“做了一批行业样本”。真正的垂类能力，是能让行业风险进入持续质量闭环。

25.11 交付物一：垂类评测适配流程

图 25-1 垂类评测适配流程图

flowchart TD
  A["选择业务场景"] --> B["专家访谈与事故复盘"]
  B --> C["抽取高风险任务"]
  C --> D["转化 Rubric 和指标"]
  D --> E["构建分层样本"]
  E --> F["专家标注与仲裁"]
  F --> G["自动评估器校准"]
  G --> H["接入门禁和线上回流"]

流程的核心是把行业知识转化为可评测资产。

25.12 交付物二：专家 Rubric 访谈提纲

问题	目的
这个场景中最严重的错误是什么	抽取高风险指标
哪些回答看似正确但实际不可接受	找到隐性风险
专家如何判断答案合格	建立 Rubric
哪些信息必须引用或核验	定义证据要求
哪些情况必须拒答或转人工	定义边界
常见事故来自哪些原因	形成回归样本
标注分歧通常发生在哪里	设计仲裁规则

访谈产物应进入指标树、样本设计和标注指南。

25.13 交付物三：垂类高风险场景抽取表

行业	高风险场景	关键指标	必要专家
医疗	用药、诊断、急症	医学正确性、诊疗边界	医生 / 药师
金融	投资建议、适当性	风险揭示、合规话术	合规 / 投顾
代码	自动修复、依赖升级	测试、安全、diff 范围	资深工程师
AIOps	故障诊断、变更建议	根因、SLA、操作安全	SRE
多模态	广告生成、人物图像	对齐、安全、版权	设计 / 法务
具身智能	动作执行、环境交互	物理安全、可控性	机器人 / 安全专家

这张表帮助团队快速定位行业风险入口。

25.14 本章小结

垂类评测不是重新发明一套方法，而是把通用评测闭环迁移到行业风险中。

通用框架仍然是业务目标、风险场景、指标树、样本、Evaluator、门禁、线上监控和优化闭环；变化的是行业 Rubric、专家仲裁、高风险场景和合规边界。

下一章会收束到组织层面：一个团队如何从个人脚本走向组织级评测能力。