AI 客服到底该怎么测？一套四层评测体系讲清规则、Judge 与多轮回归

适用对象：以“回答用户问题，并引导留资、转人工、预约或完成下一步动作”为目标的 AI 客服机器人。
项目实例：IM 客户留资识别 Agent。
当前版本：基于本项目 v1–v3 数据集、四层 Evaluator、LLM Judge、多轮执行和 HTML 台账报告的实践总结。

1. 项目结构与工程分层

这套评测项目按“业务规格、数据资产、执行引擎、报告产物”分层。业务规则与代码分离，数据集与厂商 API 分离，确定性规则与 LLM Judge 分离，使需求变化、接口变化和模型变化可以独立定位、修改和回归。

1.1 核心目录树

test-yiche-im/
├── AGENTS.md                         # 项目开发与评测规则
├── README.md                         # 项目入口、命令和文档导航
├── run-full.sh                       # V3 全量评测短命令
├── product-specs/
│   └── evaluation-requirements.md    # 可验证的产品评测需求
├── constraints/
│   ├── business-rules.md             # BR-001～BR-014 业务规则
│   └── evaluation-gates.md           # 指标门槛和发布门禁
├── datasets/
│   ├── schemas/                      # 单轮、多轮用例 JSON Schema
│   ├── seed/                         # 人工确认的真实 API 冒烟用例
│   └── candidates/
│       ├── v1/                       # 基础业务行为候选集
│       ├── v2/                       # 范围、知识、鲁棒性、安全增强
│       └── v3/                       # 口语、错字、噪声、边界增强
├── src/
│   ├── yiche_im_eval.py              # Adapter、Runner 和执行入口
│   ├── evaluation_rules.py           # L1 确定性业务规则
│   ├── evaluation_metrics.py         # L2～L4 与专项指标聚合
│   ├── llm_judge.py                  # 七维 LLM Judge
│   ├── ai_apiclient.py               # Judge 模型服务客户端
│   └── report_renderer.py             # 交互式单文件 HTML 报告
├── scripts/
│   ├── generate_dataset_candidates.py # V1 确定性生成器
│   ├── generate_dataset_v2.py         # V2 增量生成器
│   └── generate_dataset_v3.py         # V3 增量生成器
├── tests/                              # 规则、数据、指标、报告和多轮回归
├── artifacts/                          # 时间戳 JSON、HTML 和验收截图
├── docs/
│   ├── theory/                         # 四层测试方法提炼
│   ├── references/                     # 外部方法文章归档
│   └── superpowers/                    # 已确认规格和实施计划
└── tasks/active/evaluation-framework/
    ├── ROADMAP.md                      # 阶段路线图
    └── STATE.md                        # 当前状态、风险和验证记录

目录树只展示主路径。artifacts/ 中的历史报告、Python 缓存和临时文件不属于项目结构设计的一部分。

1.2 目录与关键文件职责

模块	主要职责	变化时应检查什么
`product-specs/`	把产品意图转为可验收需求	行为标签、知识边界、Judge 口径
`constraints/`	定义硬规则和发布门禁	规则 ID、否决项、指标阈值
`datasets/`	保存版本化单轮、多轮和冒烟数据	Schema、来源、审核状态、隐私
`src/yiche_im_eval.py`	连接外部 API 并驱动单轮、多轮	请求映射、规范化响应、异常隔离
`src/evaluation_rules.py`	执行 L1 确定性判断	正反例、同义表达和误报风险
`src/evaluation_metrics.py`	聚合分类、Judge、流程和专项指标	空分母、未评测、切片口径
`src/llm_judge.py`	执行七维语义质量评分	Rubric、契约重试、阈值判定
`src/report_renderer.py`	生成可筛选、可下钻的 HTML	隐私、交互、颜色、动态结论
`scripts/`	确定性生成版本化候选集	继承关系、数量矩阵、重复生成一致性
`tests/`	固定规则、指标和报告行为	主路径、边界、异常和历史回归
`artifacts/`	保存每次执行的证据	时间戳、原始 JSON、HTML 和截图
`tasks/active/`	保存可恢复的项目现场	已完成、未完成、风险和验证证据

1.3 从数据到报告的执行链路

产品原型与业务规则
        ↓
版本化数据集与多轮剧本
        ↓
HTTP Adapter → 外部 Agent API → 规范化响应
        ↓
L1 硬规则 → L2 意图统计 → L3 LLM Judge → L4 多轮流程
        ↓
任务完成 / 范围 / 知识 / 鲁棒性 / 安全 / 性能指标
        ↓
时间戳 JSON + 可交互 HTML + bad case 回归闭环

这个结构最重要的价值不是文件整齐，而是失败可归因：接口异常、规则误报、意图错误、话术低分和多轮顺序失败不会混成一个模糊的“回答不好”。

2. 先明确评测要回答什么

AI 客服评测不是判断一句话“像不像人”，而是回答以下问题：

是否理解了用户当前意图。
是否基于允许的知识正确回答。
是否遵守事实、安全、合规和流程红线。
是否完成业务动作，例如留手机号、授权、预约或转人工。
话术是否自然、清晰、有价值且符合上下文。
多轮对话中的顺序、状态和记忆是否正确。
面对错别字、口语、噪声、错误前提和攻击输入时是否稳定。
新版本相对旧版本究竟提升了什么、退化了什么。

因此不能只看“整体通过率”，也不能只靠 LLM 打一个总分。正确方法是把确定性约束、分类能力、生成质量和多轮流程分层评测。

3. 评测基本原则

3.1 需求先变成可验证规则

产品描述通常是“自然引导”“不要乱说”“简短一点”。这些表达不能直接测试，必须改写为：

产品要求	可验证规则	评测方式
先简答，再引导	回复必须回答当前问题；不能只索要电话	代码规则 + Judge
不得编造	输出事实必须能追溯到 knowledge	代码规则 + Judge + 人工复核
实时信息交给店家	价格、库存、优惠、车况、试驾时间不得承诺	代码规则
只引导手机号	用户未提微信时不得主动推荐微信	代码规则
负面反馈先安抚	道歉必须出现在留资或营销动作之前	顺序规则 + Judge
用户结束就停止	不回答新问题、不营销、不继续留资	代码规则 + 多轮剧本
回复自然	口语、清晰、不机械重复	LLM Judge

一条需求如果无法写出触发条件、期望行为、禁止行为和观察点，就还不具备实施评测的条件。

3.2 硬规则与软质量分开

能通过字符串、结构化字段、顺序或知识字段确定的要求，用普通代码判断。
需要理解语义、自然度、承接关系的要求，使用 LLM Judge。
事实编造、越界承诺、结束后营销等红线独立否决，不能被高质量分抵消。
Judge 失败应标记“未评测”，不能填 0 分，也不能把未评测算成业务失败。

3.3 黑盒只评价可观察行为

本项目只能看到 API 请求与响应，因此评价：

输入、历史和知识条件下的输出。
返回的意图 code/name。
多轮 conversationId 和外部行为顺序。
API、Judge 的成功率和耗时。

不要猜测模型内部路由、检索节点、状态机或思维过程。没有检索轨迹时，也不能声称测得真实 Context Precision、检索 Recall 或 TTFT。

3.4 总分用于趋势，门禁用于决策

综合分方便看趋势，但发布决策必须查看：

是否新增红线失败。
关键意图 recall 是否下降。
多轮关键流程是否失败。
Judge 可用率是否足够。
数据集、模型和参数是否可比。

4. 从需求到评测的规划流程

第一步：冻结业务事实源

按优先级整理：产品原型、业务规则、接口文档、知识字段、历史 bad case。发生冲突时停止实现并找产品确认，不能让测试人员自行改写业务含义。

本项目的关键业务顺序是：

明确结束或拒绝联系。
事实、安全和禁止承诺。
已提供手机号后的识别与授权提示。
回答当前问题。
引导留手机号并说明联系价值。

高优先级行为不能被“提升留资率”覆盖。

第二步：建立行为标签

标签应该代表机器人应采取的业务策略，而不只是用户话题。本项目采用十类：

标签	典型问题	核心检查
`VEHICLE_INFO`	价格、里程、配置、手续	已知简答；未知或实时信息转店家
`STORE_INFO`	地址、门店、营业信息	已知信息回答；到店前安排确认
`APPOINTMENT`	看车、试驾、预约	不承诺时段或库存，引导联系确认
`PRICE_NEGOTIATION`	底价、优惠、砍价	不承诺成交价或优惠
`WECHAT_REQUEST`	加微信、发微信	不接受或主动推荐微信，转手机号
`NEGATIVE_FEEDBACK`	投诉、不满、质疑	先道歉，再记录、留资和专人处理
`OTHER_VEHICLE`	其他车源	不使用当前车辆知识冒答
`OFF_TOPIC`	非车源问题	不展开，简短收束或转专人
`PHONE_PROVIDED`	用户提供电话	返回 `intent.code=9`，不重复索取
`END_CONVERSATION`	不用了、别联系、再见	立即结束，不补充营销

标签数量不是越多越专业。能够对应不同业务动作、可以稳定标注、失败后能够定位修复，才值得单独建类。

第三步：形成规则台账

每条规则至少包含：

稳定规则 ID。
触发条件。
必须行为。
禁止行为。
适用层级。
是否一票否决。
正例、反例和边界例。

稳定 ID 很重要。报告中的 BR-005 应能直接追溯到规格和测试，而不是只有一句“回复不合格”。

第四步：定义数据契约

请求与期望必须分离。request 发给被测 API，expected 只供 Evaluator 使用：

{
  "id": "VEHICLE_INFO-001",
  "request": {
    "input": "这车跑了多少公里",
    "chatHistory": [],
    "knowledge": {
      "carConfigInfo": {
        "archives": {"mileage": "3.37万公里"}
      }
    }
  },
  "expected": {
    "behavior": "VEHICLE_INFO",
    "expected_outcome": "DIRECT_ANSWER",
    "required_knowledge_points": [
      {
        "path": "carConfigInfo.archives.mileage",
        "value": "3.37万公里",
        "usage": "answer"
      }
    ],
    "assertions": {
      "max_sentences": 2,
      "requires_phone_guidance": true,
      "requires_lead_value": true
    }
  },
  "priority": "P1",
  "test_family": "KNOWLEDGE",
  "review_status": "candidate"
}

input 就是当前用户消息；chatHistory 是上下文；knowledge 是本轮允许使用的事实。历史只能帮助理解和保持风格，不能替代当前 knowledge 成为事实源。

第五步：先定门禁，再跑数据

不要看到首轮结果后再挑对当前版本有利的阈值。先约定：

哪些错误零容忍。
哪些类别属于关键类别。
Judge 最低可用率。
新旧版本使用的数据集、Judge 模型、参数和重复次数。
候选数据是否只做探索性分析。

5. 四层 Evaluator 体系

L1：确定性业务规则

适合检查：

句数、禁用词和明确格式。
主动推荐微信。
承诺最新价格、优惠、库存、车况或试驾时间。
缺失和实时信息是否交给店家确认。
提供手机号后是否再次索要。
结束后是否继续营销。
负面回复中的动作顺序。

L1 的优点是快速、便宜、稳定和可解释。缺点是关键词规则容易出现误报、漏报，因此规则应尽量使用“触发条件 + 语义对象 + 动作”的组合，而不是单个词。

例如，“具体年份让店家确认”已经说明了联系价值。如果规则只识别“最新价格、车况、优惠、到店安排”等固定词，就会误报“未说明联系价值”。正确改进方式是识别“具体待确认事项 + 店家确认”，而不是把泛化的“确认”直接加入白名单。

同样，“店家细说、销售核算、销售对接、负责人核实、门店安排”等都是安全承接的等价表达。确定性规则应识别“明确店家主体 + 确认/说明/安排类动作”，而不是维护整句话术白名单。结束场景中，“好的，您有需要再联系”属于被动礼貌收尾；只有继续索要手机号、主动联系、报价、优惠或安排到店时才算结束后营销。

L2：行为和意图识别

核心指标：

Accuracy：总体判对比例，只适合分布稳定时辅助查看。
Precision：被预测为某类的样本中有多少是真的，反映误触发。
Recall：某类真实样本中有多少被识别，反映漏识别。
F1：Precision 与 Recall 的调和平均。
Macro F1：各类等权，防止大类掩盖小类。
Micro F1：按全部样本汇总，反映总体表现。
混淆矩阵：直接定位某类被错分成什么。

关键类别应优先看 Recall。例如手机号识别漏掉会损失线索，结束意图漏掉会导致骚扰，负面反馈漏掉会导致错误营销。

只有一个类别或没有有效预测时，部分 precision、F1 没有数学意义，应显示“未评测”，不能强行计算或让聚合程序崩溃。

L3：生成回复质量

先执行 L1，再使用七维 LLM Judge：

维度	判断内容	为什么需要
回答相关性	是否回应当前问题	防止只留资、不回答
事实准确性	是否忠实于 knowledge	发现同义改写、矛盾和隐性编造
必要信息覆盖	是否使用题目要求的知识点	防止答非所问或漏掉核心字段
任务完成度	是否完成该类业务动作	判断简答、转店家、授权或结束是否完整
留资价值	是否说明联系后能得到什么	避免机械索要电话
清晰与语气	是否简洁、口语、自然	衡量实际客服体验
上下文一致性	是否承接历史且不自相矛盾	多轮和有历史场景的核心质量

Judge 必须返回结构化分数、理由、事实风险和适用性。契约错误可做有限纠正重试；最终失败则单列 JudgeError。

本项目的单用例 Judge 判定口径：

回答相关性、事实准确性、任务完成度任一适用分数低于 3：failed。
不满足失败条件，但任一适用维度低于 4：review。
所有适用维度不低于 4，且无事实风险：passed。
疑似事实风险：review。
null 且明确不适用的维度不参与判定。
JudgeError：标记未评测，不填默认分、不改变已有业务状态。

L1/L2 硬失败始终优先，Judge 高分不能抵消；全量 Judge 均分 >=4.0 是正式基线建立后的版本级建议门槛，与单用例阈值同时使用。

Judge 不是绝对真理。启用前应准备人工高、中、低分锚点，抽检一致性。若 Judge 经常在关键合规项上与人工冲突，应把该项改成确定性规则或人工裁决。

L4：多轮流程回归

单轮正确不代表整段对话正确。必须覆盖：

咨询 → 引导 → 提供手机号 → intent.code=9。
用户提微信 → 转手机号 → 提供手机号。
负面反馈 → 道歉 → 记录 → 专人处理。
用户拒绝留资 → 停止追问 → 后续重新咨询可正常回答。
用户结束 → 立即结束。
已留手机号后继续咨询 → 回答，不重复索取。
knowledge 从有值变为空 → 不沿用旧事实。
切换车辆、指代变化和上下文噪声。

每个剧本应声明逐轮输入、knowledge 变化、期望行为、禁止行为和最终会话结果。黑盒评测只断言 API 可观察到的顺序和结果。

6. 专业指标体系

6.1 红线与合规指标

指标	定义	价值
硬规则通过率	所有确定性规则通过的用例占比	最直接的业务合规健康度
事实违规率	经确认的编造或矛盾占比	控制信任与投诉风险
越界承诺率	承诺实时价格、库存等占比	控制交易和履约风险
结束后继续率	明确结束后仍营销的占比	控制骚扰和体验风险
主动微信率	用户未提微信却主动推荐的占比	控制渠道合规
敏感信息泄露数	日志和报告中的手机号等泄露数量	安全红线，目标为 0

6.2 业务识别指标

重点报告逐类 Precision、Recall、F1、Macro/Micro F1、混淆矩阵，以及：

手机号识别 Recall。
intent.code=9 准确率。
结束、负面、砍价等关键类别 Recall。
多意图冲突下高优先级行为命中率。

6.3 任务完成指标

不要把所有问题都当“回答题”。按期望结果分层：

ANSWERABLE：知识中有答案，应正确简答。
HANDOFF_REQUIRED：实时、缺失或不可确认，应安全转店家。
OUT_OF_SCOPE：知识范围外，应拒绝展开或转专人。
CONTROL：手机号、结束、拒绝等流程控制，应完成状态动作。

分别统计各层任务完成率，才能判断失败来自知识回答、转人工还是流程控制。

6.4 范围判断指标

仅对 ANSWERABLE 和 OUT_OF_SCOPE 做 TP/TN/FP/FN：

In-scope Recall：该回答的问题是否被正确回答。
Answer Precision：实际回答的内容是否应该回答。
Scope Accuracy：回答/不回答的边界是否正确。

HANDOFF_REQUIRED 不是范围判断错误，而是一种正确的安全承接；不能混入二分类分母。

6.5 知识质量指标

Faithfulness：回复中的事实是否被 knowledge 支持。
Required Knowledge Coverage：要求使用的知识点是否被覆盖。
Fact Risk Review Rate：Judge 标记需人工复核的比例。

Faithfulness 高不代表回答完整，因此要和必要知识覆盖同时看。Judge 标记的事实风险是复核队列，不应未经人工确认直接定性为事实违规。

6.6 鲁棒性指标

Noise Robustness：加入无关历史后行为是否保持一致。
Metamorphic Pair Consistency：同一语义的 clean/variant 是否得到等价行为。
Typo/ASR Pass Rate：错字、谐音、漏字、断句下的通过率。
Wrong-premise Safety Rate：面对错误前提是否纠正或安全承接，而非顺着编造。
Context-switch Accuracy：切车、换话题、指代变化后的正确率。

鲁棒性必须成组设计。只测一条错别字问法，无法判断它比正常问法退化了多少。

6.7 安全指标

覆盖提示注入、角色劫持、系统提示索取、隐私索取、绕过规则、超长输入和矛盾指令。报告攻击类型覆盖数和各类通过率。

安全样本不能只追求数量，应检查攻击是否真的针对当前 Agent 的资产和权限边界。

6.8 稳定性与性能指标

Repeat-run Consistency：同用例重复运行的行为一致率。
Score Stability：Judge 各维分数的均值和离散程度。
API Success/Error Rate：区分被测业务失败与基础设施失败。
API Latency：均值、P50、P90、P95、最大值。
Judge Availability/Latency：Judge 成功率和额外耗时。

性能指标是体验与执行成本指标，不应和回答质量混成一个总分。概率性结果至少重复三次后再判断小幅变化。

7. 数据集设计方案

7.1 数据来源优先级

已确认的产品原型和业务规则。
脱敏后的真实用户会话与投诉 bad case。
测试和产品人员确认的边界表达。
基于真实表达模式构造的合成变体。
LLM 辅助扩写的候选样本。

合成样本必须明确标记，不能描述为真实用户数据；LLM 生成样本不能自动进入正式基线。

7.2 每条用例必须具备的信息

稳定且唯一的 ID。
标题、描述和业务行为标签。
input、chatHistory、knowledge。
期望结果类型和必要知识点。
适用断言与评测层。
优先级、测试族、来源和版本。
候选/已审核状态及变更原因。
需要时提供 clean/variant 配对关系。

7.3 必须覆盖的用例类型

按业务行为

十类行为均需覆盖，关键类增加边界和反例。数据量不要平均分配，应按业务频率、错误损失和历史失败加权。

按难度

P0：事实、安全、结束、手机号、关键顺序等红线。
P1：主流咨询、留资、门店、价格和预约。
P2：低频表达、复杂噪声、长尾组合。

按路径

主路径：标准、清晰表达。
边界：暂缓与结束、询价与砍价、抱怨与普通质疑。
异常：API 错误、Judge 错误、字段缺失、空历史。
回归：已修复且具代表性的 bad case。

按语言表达

标准问法和真实口语。
省略、短句、连续追问和指代。
错别字、同音字、漏字、ASR 断句。
数字缩写、英文配置词和中英混合。
重复、无关历史和话题切换。

按知识边界

字段有值，可直接回答。
字段为空或缺失。
字段存在但属于实时变化信息。
用户陈述与 knowledge 冲突。
用户询问另一车辆或知识范围外内容。

按多轮状态

留资前、留资中、留资后。
已拒绝、已结束、重新发起咨询。
已投诉、已记录、继续追问。
knowledge 更新和车辆切换。

按安全与鲁棒性

提示注入、角色劫持、隐私和规则绕过。
clean/改写/错字/噪声/矛盾配对。

7.4 如何从一条需求扩展成用例族

以“查询车辆年份和里程”为例：

标准：这车哪年的，多少公里？
口语：哪年车啊，跑得多不多？
错字：这车那年的，多少公理？
ASR：这车哪年的多少公里
省略：结合历史后问 那年份呢？
错误前提：不是 2023 年、只跑一万吗？
缺失字段：knowledge 无年份，但有里程。
冲突历史：历史提到另一辆车的年份。
实时追问：现在实际里程还是这个数吗？
多轮：问里程 → 问年份 → 留电话 → 继续问手续。

每个变体都应保留同一个业务意图，但改变一种挑战因素。不要在一条用例里同时塞入五种噪声，否则失败后无法归因。

7.5 数据集配比建议

没有统一黄金比例。初版可按以下结构起步：

50%–60% 核心业务主路径和常见口语。
15%–20% 知识边界与实时信息。
10%–15% 错字、ASR、噪声和变形配对。
5%–10% 安全与提示注入。
10% 左右多轮关键路径和历史 bad case。

随后用真实流量频率和错误损失调整。本项目 v3 采用 360 条单轮、50 条多轮，并在 v2 基础上新增真实购车口语、错别字/ASR、混合表达、错误前提、上下文噪声、实时边界和安全专项。

7.6 数据质量门禁

生成或修改数据后自动检查：

数量、分类和优先级矩阵符合规划。
ID 唯一，版本继承不静默改变旧样本。
所有对象通过 JSON Schema。
ANSWERABLE 的必要知识路径真实存在且值一致。
HANDOFF_REQUIRED 含店家确认和禁止承诺断言。
clean/variant 配对完整。
历史角色规范化为 user/assistant。
无真实手机号、密钥或未脱敏完整会话。
新增候选保持 candidate，未被误标为正式基线。
生成器重复执行结果一致。

8. 实施架构

保持链路简单：

版本化数据集
    ↓
HTTP Adapter（厂商协议映射、超时、脱敏）
    ↓
规范化响应
    ↓
L1 硬规则 ── L2 意图统计 ── L3 LLM Judge
    ↓                         ↓
L4 多轮剧本              人工复核队列
    ↓
指标聚合
    ↓
时间戳 JSON + 交互 HTML 报告

实现时关注：

API 厂商字段只存在于 Adapter，数据集和 Evaluator 不依赖它。
不明确幂等性时不要自动重试被测 Agent，避免重复留资或污染会话。
Judge 可有限重试结构化契约，但不能伪造缺失分数。
单条异常不应中断全量运行；报告需区分业务失败、API 异常和 Judge 异常。
日志只输出 case ID、状态、意图、规则 ID、分数、耗时和 ETA，不输出手机号和完整对话。

9. 执行策略

9.1 运行分级

场景	建议执行
本地规则改动	单元测试 + L1 全量
提示词小改	代表性 smoke + 对应行为族 + Judge
意图模型改动	L2 全量，至少重复 3 次
多轮逻辑改动	L4 关键剧本全量
发布前	固定正式集上的 L1–L4 完整比较
日常巡检	少量真实 API 冒烟 + 定期全量

9.2 当前项目命令

运行 v3 全量评测，包括 360 条单轮、50 个多轮、LLM Judge 和 HTML 报告：

./run-full.sh

先运行前 10 条验证环境：

./run-full.sh 10

执行本地回归：

uv run --python 3.12 --with pytest python -m pytest -q

建议先跑小样本，确认 API、Judge、输出目录和报告正常，再跑全量。全量日志应逐条显示进度、通过/失败、意图、断言、Judge、耗时和动态 ETA。

9.3 可比性控制

版本对比时必须固定：

数据集版本和审核状态。
被测 Agent 版本和配置。
Judge 模型、prompt、温度和输出契约。
重复次数、并发和超时。
规则版本和评分口径。

规则或 Judge rubric 变化后，旧结果不能直接和新结果横向比较；应重新评分或明确标记口径不同。

10. 报告应该如何设计

10.1 报告目标

报告需要同时服务三类读者：

产品和负责人：能否发布，主要风险是什么。
算法和开发：哪一层、哪一类、哪条规则失败。
测试和标注人员：请求、返回、断言、Judge 和复核依据是什么。

10.2 必须包含的模块

评测对象说明。
评测方法和四层边界。
数据集版本、来源、审核状态和覆盖矩阵。
核心门禁与红线结果。
十类行为的 P/R/F1 和混淆矩阵。
七维 Judge 分数、可用率和异常原因。
任务完成、范围、知识忠实度。
鲁棒性、安全、稳定性和性能。
多轮场景和关键顺序结果。
可筛选、可展开的用例台账。
人工复核队列和未评测原因。
限制、风险和结论。

10.3 用例详情必须可下钻

每条用例至少展示：

用例 ID、类别、优先级和测试族。
脱敏后的请求：input、历史条数、knowledge 是否存在。
规范化返回：output、intent、耗时或异常类型。
每项断言的期望、状态、规则 ID 和原因。
Judge 七维分数、理由、事实风险或未评测原因。
Judge verdict、触发阈值的具体维度与原因。
多轮时展示逐轮结果和会话结论。

失败断言应整行突出，不能只在顶部给一个 failed。Tab、筛选、全部展开/收起能显著降低定位成本，但报告仍应保持单文件、离线可打开和无外部前端依赖。

视觉上建议采用“中性背景 + 高饱和状态色”：大面积页面使用暖白、米色或浅灰，保证长时间阅读舒适；通过、失败、复核、异常分别使用高辨识度的绿、红、橙、蓝，并统一应用于统计数字、图表、徽标、断言行和结论卡。标题、正文、说明、元数据至少形成四档文字深度，不能只靠字号区分，也不能只靠颜色表达状态。

10.4 结论写法

不要只写“通过率 85%，整体良好”。推荐结构：

数据有效性：执行数、异常数、Judge 可用率、候选/正式状态。
阻断项：是否出现事实、结束、微信、隐私或多轮顺序红线。
核心能力：关键意图 Recall、任务完成、Judge 质量。
主要缺陷：按问题类型列出数量和代表用例。
发布建议：通过、带风险通过、阻断或仅供探索。
修复与复测范围：指出需要重跑的用例族，而非默认全量。

11. bad case 迭代闭环

一个失败样本进入永久回归集前必须满足：

可稳定复现。
期望行为明确并经过确认。
根因明确。
能代表一类问题，而非偶然措辞。
已完成脱敏。

建议归因顺序：

数据标签或规则是否错误。
Adapter 或响应规范化是否错误。
L1 关键词规则是否误报。
意图识别是否错误。
knowledge 使用或事实边界是否错误。
话术 prompt 是否错误。
多轮状态或会话接线是否错误。
Judge 契约或评分是否错误。

修复后不要只保留原 bad case，应补充最小对照组：原问法、语义等价问法、近邻反例和必要的多轮版本。

12. 本项目多轮优化中的经验

12.1 硬规则要可解释，也要防误报

requires_lead_value=true 的含义不是必须出现固定营销词，而是用户能知道“留下电话后能获得什么”。“让店家确认具体年份”本身就是价值。规则应识别具体事项，不应把所有“确认”都判为合格，也不应只维护狭窄关键词表。

12.2 用例状态失败必须能看到具体原因

曾出现意图错误导致用例失败，但详情中没有对应断言行。解决方式是把 L2 意图作为显式断言展示，使报告状态与详情一致。

12.3 Judge 异常不能污染质量指标

模型返回 not_applicable: null、字段缺失或格式错误时，应先做无歧义规范化，再有限重试。仍失败则记录异常原因和可用率，不能默认补分，也不能阻塞其他用例和报告生成。

12.4 小样本统计要允许无定义

只跑前 N 条时，可能只有一个标签，某些 precision/F1 没有数据点。正确结果是“未评测”，不是 0，也不是聚合程序异常退出。

12.5 候选集和正式基线必须隔离

自动扩写解决覆盖问题，不解决标签可信度问题。v1、v2、v3 在人工逐条审核前都是 candidate，只能用于探索性评测，不能用于正式发布裁决。

12.6 版本继承要可证明

新数据集应完整保留旧版本的 ID、内容和顺序，通过深度比较与确定性生成证明“新增覆盖”而不是静默改题。需要修改旧期望时，应记录原因并形成新版本。

12.7 报告必须支持从结果到证据

专业报告不是图表越多越好，而是每个指标都能下钻到具体用例、请求、返回、断言和 Judge 理由。没有证据链的总分无法指导修复。

12.8 不可测指标要明确声明

黑盒接口没有检索轨迹，就不要报告检索 Recall；非流式接口没有首 token 事件，就不要报告 TTFT。明确写“未评测及原因”比用替代指标冒充更专业。

12.9 日志可观察性决定全量执行体验

长任务必须显示当前条数、单条状态、失败规则、Judge 状态、耗时和 ETA。基础设施异常只记录安全摘要，避免整批跑完后才发现 Judge 从第一条就没有执行。

12.10 红线零容忍不等于所有指标都要求 100%

事实、安全、结束和隐私可以零容忍；自然度、口语和普通类别 F1 应依据人工基线、业务损失和模型方差设门槛。把所有指标都设成 100% 会导致门禁失去区分度。

13. 落地检查清单

需求和规划

业务事实源、知识边界和优先级已确认。
每条要求已转为触发条件、必须行为和禁止行为。
红线、质量指标和不可测范围已区分。
行为标签能映射到不同业务策略。

数据集

主路径、边界、异常、回归均有覆盖。
业务行为、难度、语言、知识、多轮、安全均有覆盖。
clean/variant 配对能衡量鲁棒性。
来源、版本、审核状态和变更原因明确。
Schema、隐私、重复和知识路径检查通过。
LLM 或合成样本未自动进入正式基线。

Evaluator

L1、L2、L3、L4 分层实现。
硬规则失败不被 Judge 高分抵消。
Judge 异常标记未评测并保留原因。
单条异常不会中断整批执行。
指标空分母得到“未评测”而非 0 或异常。

执行

小样本先验证 API、Judge、报告链路。
全量运行显示逐条状态、耗时和 ETA。
新旧版本的环境、数据、Judge 和参数一致。
概率性评测按约定重复运行。

报告和决策

报告声明数据集是否已人工审核。
红线、核心能力和软质量分开呈现。
每个失败都能下钻到请求、返回、断言和 Judge。
API 异常、业务失败、Judge 异常和人工复核分开统计。
结论包含风险、修复建议和明确复测范围。

14. 推荐的建设顺序

如果从零建设一套 AI 客服评测体系，推荐按以下顺序：

冻结产品规则、知识边界和风险优先级。
建立行为标签、规则 ID 和数据 Schema。
先实现 Adapter、L1 和少量冒烟用例。
建设人工确认的核心单轮集，接入 L2 指标。
接入结构化 LLM Judge，并完成人工校准。
增加多轮剧本和关键流程门禁。
增加范围、知识、鲁棒性、安全和稳定性专项。
生成可下钻的 JSON/HTML 报告。
建立 bad case 归因、审核和永久回归流程。
基线稳定后再接入 CI、版本对比或 Langfuse 等平台。

先把规则、数据、证据链和执行闭环做好，再考虑平台化。工具可以替换，清晰的业务契约和可信数据集才是评测体系长期有效的基础。

#AI评测 #智能客服 #AIAgent #大模型测试 #LLMJudge #测试工程 #自动化测试 #数据集设计 #质量保障 #多轮对话 #模型评估 #人工智能