多维评估体系

• 指标分层与维度划分的能力
• 硬指标与软指标、质量指标与系统指标的分工
• 指标之间权衡关系的理解

把这些指标分成"质量维度"与"系统维度"两类，并建立指标字典。质量维度包括：任务成功（用户目标是否达成，通常是业务层的漏斗指标）、正确性（事实是否准确）、忠实度（回答是否忠于上下文/检索来源，不编造）、相关性（回答是否贴合问题）、格式（是否符合 JSON/Schema/排版要求）、安全（是否有有害内容、越权、幻觉风险）。系统维度包括延迟（TTFT、TPOT、P95）与成本（Token、缓存命中率、每请求成本）。每个指标都要有明确的定义、度量方式、评分量纲（0-1、分类、布尔）、数据来源和最低门槛。最后用"指标树"组织：顶层是任务成功，下层是支撑它的质量与系统指标，避免各指标各自为政。

关键不是"堆指标"，而是定义每个指标"在什么场景下、用什么数据、达到多少算好"。硬指标（任务成功、格式合法）决定能否上线，软指标（语气、相关性）决定体验。延迟与成本是约束条件，不能与质量并列竞争，而是作为门槛参与取舍。

• 每种评估手段的优缺点与偏差来源
• 评估金字塔与互补策略
• 何时用哪种手段

离线评估集偏差：样本固定、覆盖有限、可能泄露或过拟合、与真实流量分布有 gap。专家人工评审偏差：成本高、覆盖样本小、存在标注者主观不一致、可能随时间漂移。LLM-as-Judge 偏差：位置/长度/自褒/锚定等系统性偏差、随模型升级漂移、对领域幻觉不敏感。线上用户反馈偏差：多数人偏好不等于正确、噪声大、有沉默偏差（只有强烈情绪才反馈）、受 UI 影响。互补策略：用离线集做快速 CI 回归与横向对比，用 LLM-as-Judge 做大规模批量评分，用专家人工评审做关键样本的校准与 golden set 构建，用线上指标（解决方案率、接单率、用户编辑）做最终验证。四者形成"离线快速 + 大规模自动 + 关键人工 + 线上真相"的闭环。

没有单一无偏手段。正确做法是让离线集与线上行为对齐（用线上 badcase 回流），用人工标注校准 Judge，用线上指标验证离线结论。任何单一来源都不可作为最终真相。

• 各类 Judge 偏差的机理
• 换序与多 Judge 的缓解原理
• 偏差消解的实际技巧

位置偏差：Judge 倾向给排在前面的候选更高分。长度偏差：Judge 倾向给更长、更"详细"的回答更高分。自我偏好：Judge 倾向于偏好自己模型（或同族模型）生成的回答。锚定偏差：Judge 受先出现的参考或预置分数影响。格式偏差：Judge 对格式不规整、Markdown 混乱的回答打低分。缓解手段：换序（把 A/B 顺序对调各评一次，两者都赢才算赢）可消除位置偏差；对长度做控制或归一化；评分时隐藏答案来源模型名以消除自褒；用清晰 rubric 与参考样本减少锚定；规定明确的输出格式。多 Judge 集成（多模型投票）可减少单一模型偏差，但成本增加，需权衡。

换序是 LLM-as-Judge 最经典的去偏手段，因为位置偏差是系统性的。多 Judge 能降低单一模型偏差方差，但引入成本与延迟，应用在关键评估而非全部。

• Judge 与业务指标对齐的校准方法
• 离线-线上指标 gap 的根因
• 校准闭环

首先建立"对齐验证"：用一批人工标注的 golden 样本，计算 Judge 分数与人工评分/用户行为（如接单率、点赞率、客服接管率）的一致性（相关、AUC、Kappa）。若不一致，说明 Judge 的评分标准与真实业务目标脱节。校准方式：1) 用业务指标反馈更新 rubric 与评分权重；2) 用线上 badcase 大规模回流补充训练 Judge 的参考样本；3) 对 Judge 分数做统计校准（如 Platt/isotonic 映射到业务概率）；4) 定期做"Judge 漂移检测"，Judge 升级后重新校准。最终把"离线分数"当作代理指标，把"线上业务指标"当作真值，持续对齐。

离线高分线上翻车通常因为 Judge 优化的不是用户真正关心的维度（如 Judge 看重长度、用户看重简洁）。必须让代理指标与真值对齐，并定期校验对齐度。

• 多 Judge 的适用场景
• 成本-可信度权衡
• 分级评审策略

多 Judge 集成适用于高风险、高价值、结论影响动作的场景，例如：线上发布门禁、事故复盘、医疗/法律等高风险领域、需要上报给客户或发布的关键结论。因为这些场景的误判代价高。低风险场景（内部快速迭代、海量样本粗筛）用单 Judge 即可。成本-可信度权衡：多 Judge 增加延迟与 Token 费，但降低单模型偏差方差。常用策略是"两阶段"：先用单 Judge 低成本粗筛，只对边界样本/高置信度差别大的样本启用多 Judge 或人工复核（human-in-the-loop）。

关键不是"处处多 Judge"，而是按风险分级：高风险必多/必人工，低风险单 Judge。分级评审把成本花在刀刃上。

• Pairwise vs Likert 的优缺点
• Bradley-Terry/ELO 的使用场景
• 评分方案选型

Pairwise 更稳定（两两比较的标注者一致性高、更少受绝对尺度影响）、更费成本（O(n²)比较），但解释性差（只知道 A 优于 B，不知道绝对好坏）。Likert 更便宜、可解释（直接给出分数），但不同标注者尺度不一致（有人 3 分算好有人 4 分），稳定性差。当需要把大量 pairwise 结果聚合成一个全局排序时，用 Bradley-Terry 模型或 ELO 评分（如 Chatbot Arena 的做法），把它们映射为可比较的全局分。适合用 BT/ELO 的场景：开源模型排名、竞品对比、需要大规模横向排序。

产品内部用 Likert 更实用（可解释、可设门槛），研究/基准对比用 pairwise + BT/ELO 更稳健。关键是根据"是否需要全局排序"和"成本预算"选择。

• rubric 设计原则
• 盲评与标注流程
• 一致性度量（Cohen's Kappa / Fleiss）

rubric 设计：每个维度给出明确的等级定义与示例（如相关性 1-3 级各配好坏样例），避免模糊描述。盲评：标注者不看到答案来源模型、作者、顺序，防止偏见。标注培训：先让标注者用种子样本标注并校准，直到与 golden 一致率达标。争议仲裁：两人标注不一致时，由资深专家或第三标注者仲裁，双人达成一致才定稿。一致性测量：用 Cohen's Kappa（两标注者）或 Fleiss' Kappa（多标注者）衡量随机校正后的一致性，Kappa 低于 0.7 视为不可靠，需加强培训或简化 rubric。

评估质量的前提是标注者之间"口径一致"。Kappa 衡量的是"排除随机碰巧一致以外的真实一致"，是人工评估可靠性的核心指标。

• 基准集分层维度
• hard cases 与回归集的设计
• 基准集治理

分层维度：按业务（客服、创作、编程各有独立 subset）、按难度（easy/medium/hard，让分数不会全满分或全零分）、按语言（中文/英文/多语）、按风险（低/中/高风险，高风险子集独立统计）。hard cases 维护：专门收集曾被模型答错的、边界模糊的、需要强推理的样本，作为"难度锚点"，防止模型变"聪明"后数据区分度下降。回归集：固化一批"历史曾出错的样本"，每次变更必须通过，防止旧问题复发。整体用分层抽样的方式保证每个子集的代表性，并定期评估每个子集的区分度（区分度差的子集要替换）。

基准集的价值在于"区分度"，如果所有样本都轻易答对，就没法测出回归。分层 + hard cases + 回归集正是为了保持区分度与覆盖。

• 硬指标与软指标的定义与区别
• 两类指标在门禁与迭代中的不同作用
• 指标体系设计

硬指标是"对错明确、可自动判定、不可妥协"的指标，如任务成功（是否达成用户目标）、格式合法（是否返回合法 JSON/Schema）、安全（是否含有害内容）、引用完整性。软指标是"主观、体验导向、可评判好坏但无绝对对错"的指标，如语气是否亲和、是否符合品牌调性、详略是否得当。设计上：硬指标作为发布门禁与阻断项（不达标不让上线），软指标作为体验优化目标（持续打磨），两者都要纳入评估体系但权重与用途不同。硬指标用自动化规则/Judge 判定，软指标用人工抽样或 Judge 评分。

硬指标管"能不能用"，软指标管"好不好用"。若只做硬指标，产品功能正确但体验差；只做软指标，则可能上线错误内容。两者缺一不可。

• 通用评估框架与业务定制的关系
• 不同业务的关键指标差异
• 模板复用与定制的平衡

采用"通用框架 + 业务定制"的混合模式。通用框架固定共性的质量维度（正确性、相关性、格式、安全、延迟、成本），这些是各业务都需要的。但业务特有的关键指标必须定制：客服看重解决方案成功率、语气亲和、多轮澄清能力；编程看重代码可编译、测试通过、正确性；创作看重创意、风格一致性、是否忠于需求；医疗看重引用准确、安全风险、免责声明、容错性。硬性安全与合规指标（如医疗的准确性）必须业务强定制。因此：框架统一、维度可复用、但权重的业务专属指标分开。

完全复用一套模板会漏掉业务关键风险（如医疗的引用安全），完全定制则无法跨业务对比。正确做法是框架公共、业务指标独立。

• 对抗样本在评估集中的作用
• 对抗样本比例设计
• 对抗与常规样本的平衡

对抗样本是专门设计用来诱导模型出错或暴露安全漏洞的样本，如提示注入、越狱、边界模糊、敏感信息诱导、格式陷阱。数量上不应追求固定百分比，而应"按风险覆盖"：首先覆盖已识别的风险类别（每类至少若干样本），再按业务风险偏好设定比例。通常对抗样本占评估集的 5%-20%，且是独立统计的安全子集，不混入常规质量统计。关键是在"覆盖主要风险类别"与"不挤压正常样本代表性"之间平衡，且对抗样本需要持续从线上事故与威胁情报更新。

对抗样本的价值是"覆盖已知风险"，而非追求数量。比例过高会失真（评估集不代表真实流量），过低则漏测风险。要求按风险类别覆盖并独立统计。

• 答案不唯一题目的评估难点
• reference set 与 pairwise 的用法
• 相对评测 vs 绝对评测

创作、开放题等答案不唯一，给绝对分（如"7 分"）缺乏可解释基准，且不同标注者尺度差异大。改用相对评测：1) reference set：为题目准备一批高质量参考答案（golden 参考），让 Judge/标注者把候选答案与参考集对比，评估"是否达到参考水平/是否优于参考"，而非给绝对分；2) pairwise 比较：直接比较两个候选答案哪个更好，用两两比较的结果聚合（如 Elo/Bradley-Terry），避免绝对尺度。这样把"主观打分"转换为"可比较的相对判断"，更稳定。

答案不唯一时，绝对分缺乏参照系，相对比较（pairwise、与参考集比）因有明确参照物而更稳定、标注者一致性更高。

• Judge 过拟合/Goodhart 效应
• 防止指标工程化的手段
• 多信号交叉验证

这是 Goodhart 定律的典型表现（当指标成为目标，就不再是好指标）。防止手段：1) 将 Judge 分数与真实业务/人工指标绑定校验，离线分数提升必须伴随线上行为改善才可信；2) 定期更换/轮换 Judge 模型和多 Judge 集成，避免单一措辞偏好被钻空子；3) 盲评，隐藏被评答案来源；4) 设"反指标"与护栏，如长度、自褒、冗余会被惩罚；5) 用 hard 样本集做盲测，观察分数提升是否泛化到未知样本；6) 人工抽检覆盖，防止只看 Judge 分数。

核心是"分数不是目标，任务成功率才是"。让 Judge 分数与真实业务指标对齐，并引入护栏与人工抽检，防止指标被优化而业务没变好。

• Judge 升级导致的分数漂移
• 校准与基准桥接
• 双轨评估

Judge 升级会导致系统性分数漂移（新模型更聪明更严格，或更宽松）。处理方式：1) 升级前用同一批固定 golden 样本分别用新旧 Judge 评分，计算分数差与分布差异，建立"桥接映射"（如新分数 = 旧分数 + 偏移量）；2) 双轨运行：新旧 Judge 并行评分一段时间，验证一致性后再切换；3) 记录评价版本，历史分数标注所用 Judge 版本，避免跨版本直接比较；4) 用排名/相对比较而非绝对分数作为跨版本可比信号；5) 校准后重新设定发布门槛阈值。

关键是不能让 Judge 版本变化造成"虚假的分数涨跌"。用 golden 样本桥接 + 双轨并行 + 版本标注，保证评估结论跨越版本可比。

• 人机一致性度量方法
• 一致性阈值
• Judge 可信度判断

人机一致性用随机校正的一致性指标度量，如 Cohen's Kappa（二分类）或加权 Kappa（等级）、Spearman 相关（连续分）。阈值参考：Kappa > 0.8 认为是强一致（Judge 可信），0.6-0.8 中等一致（基本可用但需注意），< 0.6 一致性较弱（Judge 结果不可直接采信，需校准或更换）。同时要注意基准：先测量"人类标注者之间的一致性"（human-human），人机一致性不应显著低于 human-human 基准，否则 Judge 还不如人类。

人机一致性需随机校正（Kappa），且要与人-人一致性对比。若 Judge 与人类的一致性低于人类彼此的一致性，说明 Judge 不可信。

• Judge 自一致性评估
• 温度与随机性影响
• 稳定性测试方法

对同一批答案用相同 Judge 多次评分（如温度较高下跑 N 次），统计分数分布：方差、标准差、各次评分是否落入同一类别/区间。若评分在同一次结果普遍波动大，说明 Judge 不稳定。评估方法：1) 重复评分一致性（同一答案多次评分，看是否一致，如 Kappa/AUC）；2) 边界稳定性（对处于门槛附近的答案，反复评分是否稳定通过/不通过；若反复翻车，说明门槛不可靠）；3) 设计时用较低温度（如 0）降低随机性，但保持一定多样性。稳定性差时，用多 Judge 投票或多轮重评取多数。

Judge 的可靠性来自"同一输入产生稳定输出"。通过重复评分一致性、边界稳定性评估，必要时量化随机性并采取多轮/多 Judge 兜底。

• 专家标注的偏差来源
• 多标注者与仲裁机制
• 标注可靠性提升

专家标注偏差来源：专家可能对领域有个人偏好、对问题理解不同、受自身经验/风格影响、疲劳与注意力漂移、甚至是"专家盲区"（对某些错误模式不敏感）。单一专家很难中立全面。提升手段：多人标注（3 人以上背靠背标注，互不知情），用统计一致性（Fleiss' Kappa）量化；标注不一致的样本进入仲裁，由资深仲裁人或多数投票决定；标注前统一培训与 rubric 校准；仲裁结果作为 golden 回流。多人标注 + 仲裁把"个人主观判断"转换为"集体共识"，显著降低单一专家偏差。

"专家"不等于"无偏"，单一专家可能有系统偏好。多人标注 + 仲裁的本质是用集体共识和一致性度量来稀释个人偏差。

• 指标复审周期
• 指标漂移的成因
• 指标治理机制

指标应定期复审，通常按业务迭代节奏（如每月/每季度）或关键变更时（模型升级、产品大改、业务目标变化）触发。复审内容包括：指标是否仍与业务目标相关、样本分布是否仍代表真实流量、门槛是否仍合理、Judge 是否仍与人工对齐。防"指标漂移"关键：指标与业务真值（线上行为、人工评分）持续对齐校验，当指标与真值脱钩（如分数涨但用户不满）时立即审查；用"指标健康度"监测（相关性、区分度、与人工一致性）；设定指标 owner 与评审流程。

指标漂移通常表现为"指标数值好看但业务没变好"。定期复审 + 与真值对齐校验是防止脱钩的核心。

• 三层评估体系架构
• 各层作用与衔接
• 完整闭环

三层体系：第一层离线评测集，在 CI 中快速回归，用固定 golden 集 + Judge 评分，评估 Prompt 变更、模型升级、代码变更，速度快、可复现、覆盖已知风险。第二层在线指标，监控线上真实行为：任务成功率、延迟、成本、引用支持率、用户点踩率、错误率等，反映真实流量下的表现。第三层人工抽检，按风险分层抽样，人工资深评审关键样本，校准与发现离线集没覆盖的新问题。衔接：离线集发现的问题回流入在线监控；在线 badcase 回填离线评测集；人工抽检结果校准离线 Judge 与在线指标。三层各司其职又形成闭环。

离线快但覆盖有限，在线真但噪声大，人工准但成本高。三层互补，形成"快速回归 → 真实监控 → 人工校准"的完整闭环。

• 评估代码的模块化结构
• 可复现性设计（固定种子、版本快照）
• 偏差校准与自动评分的实现

源码级实现应包含几个关键模块：1) 评估数据层（Dataset 版本化，含输入、golden 输出、rubric 元数据）；2) 运行器（Runner），串起"取样本 → 调用被测应用 → 调用 Judge → 记录结果"，支持并发与批处理；3) Judge 层，抽象为可切换的 Judge 后端（OpenAI/本地/多 Judge 投票），并实现换序（position swap）逻辑；4) 校准层，对 Judge 原始分数做温度/isotonic 校准，含标定样本缓存；5) 报告层，输出按维度分层的指标，并导出 artifact 供追踪。可复现性：固定随机种子、锁定被测应用与 Judge 的版本快照（model snapshot）、记录 Prompt 版本与 dataset commit，把"评估结果"与"代码/模型/数据版本"绑定，保证 CI 可复现。

落地的关键是把评估做成"可复现的工程化流水线"，而不是临时脚本。源码级的关键是"版本绑定 + 可插拔 Judge + 校准层 + 结构化报告"。

• 发布单元的概念
• 各变更要素的版本绑定
• 变更可测试性的设计

一个"可测试发布单元"指把一次 AI 应用变更涉及的所有要素绑定为一个整体：Prompt 版本、模型版本、推理参数（温度、max_tokens）、工具 Schema 版本、检索索引版本、工作流（多 Agent 编排）版本。它们组合成一个"快照"（snapshot/manifest），作为一次可测试、可回滚、可对比的发布单元。变更任何一个要素时，其余要素固化，从而能归因"是哪个要素的变更导致指标变化"。测试时对该快照整体跑评估集，并生成 manifest 记录每个要素的版本 hash，供审计与回滚。

AI 应用是多要素耦合的，单独改一个要素难以定位问题。把各要素版本绑定为发布单元，才能隔离变量、可复现、可回滚。

• 确定性逻辑的测试方法
• 概率性输出的属性测试
• 容差与不变量设计

确定性代码（函数、解析器、路由、Prompt 组装）用传统单元/集成测试：给定输入断言精确输出，覆盖边界与异常。概率性输出（LLM 返回）断言"精确内容"不可靠，改用属性测试与不变量：断言输出始终满足结构属性（JSON 可解析、字段齐全、工具参数类型合法）、安全属性（不含敏感词/注入）、语义属性（忠实于上下文、相关性达阈值）。对数值型指标用容差（允许在一定范围内波动），对多次运行用统计断言（如成功率>0.9）。整体思路：把"内容"断言降级为"属性、不变量、容差"断言。

AI 测试的核心能力是区分"确定逻辑"与"概率输出"，前者用精确断言，后者用属性/不变量/容差断言，避免测试因模型随机性而 flaky。

• 四种测试方式的特点
• 各自能发现的问题类型
• 测试环境的组合策略

Mock Provider：用桩响应替代真实模型，速度快、确定性高，能发现"代码逻辑错误、参数拼装错误、错误处理缺失"，但无法验证真实模型行为。VCR 回放：录制真实请求响应并回放，能复现线上问题、确定性可复现，适合调试与回归，但录制的数据会过期、无法发现模型行为变化。本地模型容器：跑真实开源模型做集成测试，能验证"与真实模型的交互、Prompt 格式、工具调用"，但本地模型能力弱于线上，且资源开销大。真实 Provider 测试：用真实模型冒烟，能发现"真实答非所问、延迟、配额、模式漂移"，但成本高、不稳定、不能进 CI 主链路。组合策略：单元用 Mock，集成用 VCR/本地容器，上线前用真实 Provider 冒烟。

四者按"确定性→真实性"排列，各有取舍。正确做法是分层组合：Mock 保证逻辑，VCR 复现 bug，本地容器验证交互，真实 Provider 做上线前冒烟。

• 时间敏感性问题
• Provider 行为漂移的处理
• 回放数据治理

时间敏感性问题：录制时的时间戳、缓存、限流、相对时间文案会随回放时间变化。处理：对时间相关字段做归一化/替换（把绝对时间替换为相对偏移），或冻结时间（用 fake clock），使回放时有确定性。Provider 行为漂移：录制时的模型行为已过时，回放结果可能与当前 Provider 不一致。处理：回放数据设置过期时间（TTL），定期重新录制；对"知识/行为会变"的样本标记 freshness；回放主要用于"逻辑回归与复现"，对"模型质量"需用真实 Provider 或本地容器重测。建立"录制数据版本 + 过期策略 + 漂移检测"，当回放与真实结果差异大时提示重新录制。

录制回放是"确定性"与"真实性"之间的折中。时间敏感用归一化/冻结时间解决，行为漂移用 TTL、定期重录与漂移检测解决。

• 流式响应的异步测试
• 首 token 与 token 间隔指标
• 事件序列断言

流式响应测试要异步接收事件（SSE/WebSocket），断言点包括：1) 首 token 时间（TTFT）：从请求发出到首个内容事件的时间，断言它小于阈值；2) token 间隔（TPOT）：计算相邻 token 到达时间间隔，断言 P50/P95 在可接受范围；3) 完整事件序列：断言事件顺序正确（如 start → delta → tool_call → finish），事件字段完整、无缺失/乱序；4) 超时与中断：断言在超时时间内流结束、无挂起。实现上用异步测试框架（如 pytest-asyncio、WebSocket 客户端），收集事件到列表后统一断言，用"事件收集 + 聚合指标 + 阈值断言"完成异步验证。

流式响应不是一次性返回，要点是"收集事件流 + 计算时间与序列指标 + 异步断言"。异步断言解决"等待流结束"与"实时断言"的矛盾。

• 故障注入的类型
• 流式故障的模拟方法
• 恢复与幂等验证

故障注入针对流式链路的关键故障点：乱序注入（人为打乱事件顺序，验证客户端容错）；半包注入（截断数据包，验证分片重组与重连）；限流注入（模拟 429/Retry-After，验证退避重试）；超时注入（人为延长响应，验证超时预算与超时处理）；工具失败注入（让工具调用返回错误，验证错误处理与降级）；取消传播注入（客户端中断，验证取消信号传播到上游、释放资源）。实现：用代理/中间层（如测试 Proxy、mock 网关）在关键链路注入故障，或对 Provider 客户端做故障包装。断言：系统不崩溃、错误被正确处理、有合理降级、资源被释放、副作用不重复。

故障注入测试验证系统的"恢复能力"而非"正常路径"。流式故障尤其要测乱序、半包、超时与取消传播，因为在真实网络下这些很常见。

• 回放数据脱敏
• 过期时间与保鲜
• 动态知识/行为漂移处理

脱敏：录制前对请求/响应中的 PII、密钥、内部信息做字段级脱敏（替换为占位符或哈希），确保回放数据可安全存储与共享。过期时间：给录制数据设置 TTL（如 30 天），过期后标记失效或重新录制，避免引用过时行为。动态知识：对知识会变化的样本（如新闻、实时数据）单独标记 freshness，回放时区分"知识敏感"样本；Provider 行为漂移：录制数据绑定模型版本与日期，检测到漂移（回放结果与当前 Provider 差异大）时重新录制或改用真实 Provider 冒烟。不能把回放数据当作永恒真值。

回放数据是"历史快照"，必须处理脱敏（安全）、过期（保鲜）、动态知识（时效）与行为漂移（失真）。核心是"回放只用于逻辑回归，不用于模型质量判断"。

• 概率输出的属性断言
• 结构合法性与安全属性
• 语义属性的测试

对概率性输出断言属性而非精确内容：1) 结构属性：输出可正确解析（JSON/XML 合法）、字段齐全、类型正确、工具调用参数格式合法；2) 安全属性：不含敏感词、PII、注入语句、越权内容；3) 语义属性：忠实于上下文、相关性达标、无关键遗漏；4) 业务属性：符合特定业务规则（如金额格式、免责声明存在）。对数值指标用容差/统计断言。这些属性由解析器、规则校验器、分类器或 Judge 实现，断言"必然满足"或"以高概率满足"。

概率输出测试的要点是"断言属性而非内容"。属性测试既保证结构可用，又保证安全合规，还能结合语义校验，避免 flaky。

• 快照选样策略
• 避免脆弱快照
• 快照的分层与容差

golden snapshot 选样要"选稳定、有代表性、低敏感"的样本：1) 选输出稳定、受模型小升级影响小的样本（基准问题、结构化输出），避免选极端/边界/易变样本；2) 对每个业务域分层抽样；3) 快照应断言"语义属性 + 关键要素"而非逐字精确匹配，用容差/相似度比较；4) 把"必须精确通过"的强快照与"允许容差"的弱快照分开，模型升级时只刷新弱快照；5) 为快照设定版本，模型升级时按需重新生成快照基线与评测。避免"模型小升级导致大批量失败"的关键是快照断言设计成"语义级"而非"字符级"。

快照脆弱源于"逐字精确比较"与"选了易变样本"。选稳定样本 + 语义级断言 + 容差 + 分层，才能在模型升级时保持稳定。

• 回归集样本类型
• 各类样本的比例设计
• 回归集覆盖原则

回归集应包含：happy path（正常主流程，验证基本功能）、边界（边界条件、空输入、超长输入、极端值）、对抗（注入、诱导、越狱、敏感场景）、慢路径（长上下文、多轮、大输出、低资源场景）。比例设计：happy path 占大头（约 50%-60%），边界占 20%-30%，对抗占 10%-20%，慢路径占 5%-10%。比例原则：以"业务风险与真实流量分布"为基准，happy path 保证主流程稳定，边界与对抗覆盖风险，慢路径保证性能与资源安全。比例不是固定，需随业务演进调整。

回归集是"防回潮"的稳定集，四类样本分别覆盖"主流程、边界、对抗、性能"。比例要平衡覆盖与效率，避免全是 happy path 漏掉风险。

• 可复现性的固定要素
• 各版本要素的固定方法
• 可复现测试设计

可复现测试要固定所有影响输出的要素：1) 模型快照：固定模型版本（model id/日期），避免同模型升级导致输出变化；2) Provider 后端：固定实际使用的 Provider 与端点（如 OpenAI vs Azure），不同后端行为不同；3) Prompt 版本：固定 Prompt 的精确版本（hash/commit），避免 Prompt 漂移；4) 推理参数：固定温度、max_tokens、top_p 等；5) Embedding 模型：固定 embedding 模型版本，因为检索结果依赖它；6) 随机种子：对本地/开源模型固定 seed。把这些要素写入 manifest，测试运行时按 manifest 加载，保证同一套代码+快照可复现。

可复现性是 AI 测试的基础。不固定模型快照、Provider、Prompt、Embedding、参数，结果就无法复现，也无法归因。用 manifest 统一记录。

• 传统测试金字塔 vs AI 测试金字塔
• 概率性输出的特殊性
• 新增层的作用

传统测试金字塔是"单元→集成→端到端"，因为逻辑是确定性的。AI 应用输出是概率性的，无法仅靠确定性测试覆盖质量，因此金字塔新增：评估集层（用 golden 集 + Judge 评估模型输出质量，覆盖确定性测试无法验证的语义正确性）、真实模型抽样层（对真实模型做抽样评估，验证真实行为，因为 mock/VCR 无法反映真实模型质量）、线上监控层（线上指标持续监控真实用户行为，发现离线没覆盖的回归）。新增层服务于"质量验证"这一确定性测试做不到的目标。

确定性测试验"代码逻辑"，评估集验"输出质量"，真实模型抽样验"真实行为"，线上监控验"真实分布"。AI 金字塔在这些层上扩展，因为概率性是 AI 的本质。

• 测试用例代码化
• Git 版本管理
• 测试资产可追溯

测试用例应"代码化"：把评测集样本、golden 答案、rubric、配置以代码/数据文件形式（JSON/YAML/标注代码）纳入 Git 版本管理，而不是只存在于某次人工运行的临时产物。这样每个测试用例都有版本、可 review、可回滚、可追溯。避免丢失的措施：测试集随代码一起提交、用 commit hash 关联测试结果、测试变更走 code review、CI 运行结果与用例版本绑定。避免"依赖某次人工运行"：把人工运行结果固化进版本库，作为基线与回归，而非依赖个人记忆或临时文件。

"测试集即代码"是 AI 测试工程化的关键。让测试资产进 Git、走 review、与结果版本绑定，才能保证可追溯、可复现、不丢失。

• 工具调用参数断言
• 调用顺序与错误处理
• 副作用幂等

工具调用测试断言：1) 参数合法性：工具名正确、参数 Schema 合法、类型/必填字段正确、无注入；2) 调用顺序：多步调用时顺序正确（如先查后写）、依赖关系满足；3) 错误处理：工具返回错误时，Agent 正确捕获、重试或降级、错误信息传播合理；4) 副作用幂等：对写库、发消息等有副作用调用，重复/重试不产生重复副作用（用幂等键去重）。实现上 Mock 工具记录调用序列，断言参数与顺序；对副作用用幂等键和"只执行一次"语义验证。

工具调用是 Agent 的核心，测试要覆盖"参数、顺序、错误、副作用"四类，尤其副作用的幂等性，避免重试造成重复副作用。

• LLM-as-Judge 的评估流程
• 各类偏差及其缓解
• Judge 提示词设计

流程：把"问题 + 待评回答 + rubric"发给 Judge，要求输出结构化评分（JSON 分数 + 理由）。偏差缓解：1) 顺序偏差：换序（position swap）各评一次，一致才采纳；2) 长度偏差：rubric 中明确"简洁加分/冗长不加分"，或对长度归一化；3) 自褒偏差：隐藏模型来源，用多 Judge 投票；4) 锚定偏差：独立评分、不预置参考分数；5) 格式偏差：rubric 强调只看内容实质。提示词设计要给出清晰 rubric、要求 JSON 输出、设定好温度（低）。Judge 分数需与人工/业务对齐验证。

LLM-as-Judge 是低成本批量评估方案，但系统性偏差必须缓解。换序、多 Judge、rubric 规范、隐藏来源是核心手段。

• Agent 评估指标
• 过程指标与终态指标
• 长任务评估的归因

Agent 评估分过程与终态：1) 步骤成功率：每步决策/子任务是否成功（用 Judge 或规则判断每步）；2) 工具调用正确率：工具名、参数、顺序是否正确；3) 终态达成率（任务完成率）：最终是否达成用户目标（关键指标）；4) 效率指标：步数、Token、耗时；5) 安全性：是否有越权/副作用。评估需"轨迹级"分析：记录每一步（输入、工具调用、观察、输出），用 Judge 或规则逐段评估，并归因失败发生在哪一步（改写、检索、推理、执行）。终态达成率是主指标，过程指标用于归因。

Agent 是长任务，评估不能只看最终结果，要拆解到步骤与工具调用。终态达成率管"是否做对"，步骤与工具正确率管"哪一步做错"，用于归因优化。

• Prompt 与模型耦合
• 模型升级专项测试
• 升级的风险评估

Prompt 是为特定模型调优的，模型升级后其行为、能力、输出格式偏好、指令遵循度都可能变化，导致原先调好的 Prompt 失效（如格式输出变化、工具调用不稳定、推理质量下降）。因此需要"模型升级专项测试集"：专门针对新模型评估 Prompt 兼容性、输出格式、工具调用、指令遵循、安全边界，并对比新旧模型在同一 Prompt 下的表现。目的是在模型升级前发现"Prompt 失效"风险，提前重调 Prompt 或做兼容层。

Prompt 与模型强耦合，模型换版本是"高风险变更"。专项测试集专门验证"同一 Prompt 在新模型上是否仍有效"，避免升级后线上崩。

• 非质量维度的内容
• 延迟/成本/安全的指标化
• 指标体系完整性

除回答质量外，评估还应包含：1) 延迟维度：TTFT（首 token 时间）、TPOT（每 token 间隔）、总耗时、P95/P99；2) 成本维度：Token 用量（输入/输出）、缓存命中率、每请求成本、成本预算达标；3) 安全维度：有害内容拦截率、注入拦截率、敏感信息泄露率、合规通过率；4) 可用性：错误率、成功率、超时率。这些"非质量"维度决定系统能否运行、是否划算、是否安全，必须纳入评估门槛，与质量指标共同构成完整画像。

一个"答案很好但慢、贵、不安全"的系统不可用。延迟、成本、安全是硬约束，必须与质量指标一起评估并设门槛。

• 公开基准的局限
• 企业任务评估的必要性
• 基准与业务 gap

公开基准（MT-Bench、Chatbot Arena）衡量的是"通用对话能力"与"人类泛化偏好"，与具体企业任务有较大 gap：1) 任务分布不同：企业任务高度定制（特定数据、Schema、工具、业务规则），公开基准的题目不覆盖；2) 评估维度不同：公开基准偏通用质量，企业更关注任务成功率、工具调用、格式、安全、合规；3) 基准分数高不代表业务可用：通用能力强的模型在特定业务上可能表现差。因此公开基准只能作为"模型初筛参考"，企业必须构建贴近自身业务与数据的评估集。

公开基准是"通用能力雷达图"，企业评估是"业务实战考试"。两者目的不同，不能互相替代，公开基准只做初筛。

• 契约测试的概念
• Provider 契约字段
• 客户端-Provider 对齐

契约测试确保客户端与 Provider 的接口约定一致，对齐字段：1) 能力契约：模型支持的 modalities、工具调用、流式、函数能力；2) 参数契约：请求参数（temperature、max_tokens、tools 等）的 Schema 与取值；3) 错误码契约：错误类型（超时、限流、配额、无效请求）及其语义；4) 流事件契约：SSE 事件类型、字段结构、顺序（delta、tool_call、finish）；5) usage 契约：input/output tokens、cache_read/write 等计费字段结构。契约测试用 Schema 校验（Pact/JSON Schema）在 CI 中验证客户端请求与 Provider 响应符合预期，发现字段不匹配、协议漂移。

Provider 与客户端版本不同步会造成契约漂移。契约测试把"接口约定"固化为可自动校验的 Schema，确保字段、错误码、流事件、usage 对齐。

• A/B 测试的统计方法
• 样本量与显著性
• 护栏指标与停止规则

避免"A/B 看起来变好但实际是噪声/假象"：1) 样本量：用功效分析（power analysis）预先计算所需样本量，保证统计学功效足够；2) 显著性：用 p 值/置信区间，做多重比较校正（BH 校正），避免凑巧显著；3) 护栏指标：监控次要业务指标（成本、延迟、用户点踩），防止主指标变好但护栏恶化；4) 停止规则：预先设定评估时长与最小样本，避免"看结果随时停"导致的 p-hacking；5) 分桶稳定性：防止用户重复进入不同组；6) 默认值：先验证分桶无显著差异（AA test）。只有在显著性达标、护栏未恶化、时长充足时才判"变好"。

A/B 误判来自样本不足、显著性不严谨、过早停止、忽略护栏。预计算样本量、显著性校正、护栏监控、固定停止规则是防误判四件套。

• badcase 回流机制
• 防止过拟合
• 评测集动态更新

badcase 回流：线上用户负反馈、投诉、客服接管、人工修正的样本定期采集，去重、脱敏、标注后回流到评测集，作为回归样本。防止过拟合：1) 回流样本要"去重与去偏"，避免同一类 badcase 大量重复导致权重失衡；2) 区分"测试集"与"调优集"：用于调模型的样本与用于评估的黄金集分开，避免在测试集上调参；3) 控制回流比例，保持样本多样性；4) 对回流样本做漂移检测，防止全是对付新模型的反例；5) 定期评估评测集与真实流量分布的一致性。评审集保持在"真实分布 + 覆盖风险"的平衡。

回流让评测集紧跟线上真实问题，但过度回流会过拟合。关键是"测试集与调优集分离 + 去重 + 比例控制 + 分布一致性检查"。