第11章　验收、试运行并持续监测AI应用

工作阶段： 可靠交付——在正式使用前建立验收门，在有限试运行中观察真实表现，并准备更新与回滚。
公共核心项目： 完成“AI应用验收与试运行台”，在同一封存包上比较人工基线与两个候选版本，用独立发布门拦截高代价退步，并从有限试运行日志发现漂移、确定回滚目标。
核心技术： 人工与规则基线、错误成本、分类与系统指标、版本化测试集、回归门、试运行、漂移监测、受控更新和回滚。
输入输出链： 任务合同与风险 → 版本化测试集 → 系统运行结果 → 指标与高代价错误 → 验收门 → 有限试运行 → 监测证据 → 保持、限用、更新或回滚。
应用中的AI： 被验收的视觉、声音、时序或语言模型及其组合系统。
协助开发的AI： 帮助生成测试入口、归类日志、计算指标、提出小范围修复和补充回归，但不裁定风险等级或验收结论。
人的责任： 定义高代价错误、批准测试数据、设置门槛、监督试运行、审查更新并决定上线、限用、回滚或停止。
主要交付物： 可运行验收工程、任务合同、封存测试与哈希、基线和候选制品、现场评测输出、门槛配置、试运行报告、发布决定、系统卡和回滚预案。
明确边界： 运行反馈不能未经审核直接成为训练数据，系统不能在现场自行改变关键模型、规则、权限或设备行为。
跨章关系： 使用第1章验收合同、第2章版本化数据和第10章可重放系统；为第12章交付和维护建立质量门。

学习目标

学完本章，你将能够：

1. 从专业后果出发定义高代价错误、人工或规则基线及验收门槛；
2. 建立包含正常、边界、陌生、诱导、故障和权限变化的版本化测试集；
3. 区分模型离线测试、系统验收和有限试运行，说明三者证据不能互相替代；
4. 监测错误、拒绝、延迟、费用、人工修改和输入分布变化；
5. 按受控流程更新模型、规则或代码，并在回归失败时恢复已验收版本。

项目导入

每章都已经做过固定测试，但“模型在测试集上表现不错”不等于整个工作系统可以投入使用。模型可能准确，检索却引用错资料；模块分别通过，权限组合后仍可能越权；实验室样本稳定，真实使用者输入却不断变化。系统验收要把专业后果、模型指标、状态、权限、恢复和人工工作量放在同一个结论中。

本章不重新训练一个模型，而是使用与第10章工作流相同的“文本输入→路线输出”接口，建立验收与试运行台。配套资源采用三份冻结的低复杂度可执行候选，不直接导入或调用第10章源码，因此这里只证明验收机制能够运行，不能虚构为已经验收第10章真实系统。学生先从错误后果定义门槛，再冻结测试集和版本，运行回归并决定是否进入有限试运行。试运行只开放给少量授权使用者，保留人工复核，持续记录系统真实表现。发现问题后不能直接让系统“边用边学”，而要形成变更申请、在副本上修改、重新回归、批准发布并保留可回滚版本。

验收结论允许是“限用”或“退回”。若规则基线已经满足任务，复杂模型没有明显价值，或者高代价错误无法降低，选择不使用模型是合格的专业判断。

本章成果

• 一张把专业后果、指标、样例和责任人对应起来的验收表；
• 一套带版本、来源、预期结果和冻结状态的固定测试集；
• 一份自动回归与人工复核结合的验收报告；
• 一份明确使用者、时间、范围和人工监督的试运行方案；
• 一套包含更新审批、回归结果、版本发布和一键回滚说明的维护记录。

AI协同开发路线

学生把任务合同、被测版本、基线、历史失败和专业后果交给协助开发的AI。AI追问高代价错误、样例来源、门槛、试运行范围、监测频率和回滚负责人，生成测试清单和可运行入口。学生审核预期结果并冻结测试数据，再运行首轮验收。对于失败项，学生提交实际日志，要求AI只修改一个模块或参数；审查差异后重跑全部回归。达到门槛后进入有限试运行，学生根据监测证据提出变更申请，在隔离副本上更新并再次验收，最后决定保持、限用、发布新版本、回滚或停止。

第一节　根据专业后果定义指标和验收门槛

一、先问错误影响谁

验收从后果开始，而不是从可用指标开始。漏掉一条普通内容标签，与漏掉一条设备异常或发布授权缺失，不能用同样权重处理。学生先列出误报、漏报、错误生成、错误引用、越权执行、隐私泄露、超时和无法恢复等失败，说明受影响的人、严重程度、能否被发现以及谁负责确认。

高代价错误要单独设门，不能被较高的总准确率抵消。例如普通事件准确率达到90%，但“无证据仍生成确定结论”出现一次，就可能直接退回。对于低风险课堂项目，可采用“高代价错误为0、普通样例达到规定比例、所有权限和恢复测试通过”的组合门槛。

二、同时保留人工和规则基线

人工基线记录有经验或受过说明的人员完成同一任务的质量、时间和差异；规则基线使用固定阈值、关键词或模板。模型必须在相同样本和相同口径下比较。若模型只提高少量速度，却显著增加复核成本和维护风险，未必值得采用。

分类任务可以使用准确率、精确率、召回率和混淆矩阵；回归任务可以使用平均绝对误差；检索任务看相关材料是否进入前若干条；工作流还要检查状态、权限、重复写入、恢复、延迟和人工工作量。指标名称不是结论，必须与错误后果相连。

三、把门槛写成可执行规则

验收表至少包含：指标或事件、测试样例、门槛、失败后果、自动检查方式、人工复核点和批准人。门槛在测试前冻结，不能看见结果后为了“通过”临时放宽。若专业标准或法规给出硬性要求，以经核实的标准为准；教材示例门槛只能用于低风险教学项目。

控制变量实验固定测试集、程序和资料，只把感知置信阈值从0.75改为0.80，预测误报、漏报和人工复核量怎样变化，再运行同一测试。阈值选择应解释取舍，不能只追求一个最高综合分数。

第二节　建立版本化测试集和固定回归门

一、测试集必须能够追溯和冻结

每个测试样例记录唯一编号、来源、授权、输入版本、预期状态、是否高代价、适用模块和编写人。正常样例覆盖主要工作；边界样例位于阈值附近；陌生样例来自训练与开发之外；诱导样例尝试让语言模型忽略证据或越权；故障样例包括资料缺失、模型文件损坏、设备断开和工具超时；权限变化样例检查角色切换。

测试集一旦用于验收就冻结。失败样例可以进入后续训练候选区，但不能一边补进训练，一边仍把它计作独立验收。新版本需要保留旧测试，并在审核后增加新样例；删除测试必须说明理由和责任人。

二、完整最小验收链

下面代码使用标准库建立最小回归门。system_under_test()表示统一的被测接口；配套资源用冻结的可执行候选实现同一接口，并不直接调用第10章工作流。测试清单可保存为JSON，程序根据高代价失败数、普通通过率和最大延迟给出机器检查结果；最终结论仍由责任人签署。真实迁移时，应把该接口接到经过明确登记的真实系统适配器，再重新冻结制品和测试证据。

import json, time
from dataclasses import dataclass

@dataclass
class Case:
    case_id: str
    label: str
    confidence: float
    has_evidence: bool
    expected_state: str
    high_cost: bool = False

def system_under_test(case, threshold=0.75):
    started = time.perf_counter()
    if not case.has_evidence:
        state = "STOPPED"
    elif case.confidence < threshold:
        state = "NEED_REVIEW"
    else:
        state = "WAITING_APPROVAL"
    latency_ms = (time.perf_counter() - started) * 1000
    return {"state": state, "latency_ms": latency_ms}

def run_gate(cases, version, threshold=0.75,
             min_pass_rate=0.90, max_latency_ms=100.0):
    rows, high_cost_failures = [], 0
    for case in cases:
        result = system_under_test(case, threshold)
        passed = (result["state"] == case.expected_state
                  and result["latency_ms"] <= max_latency_ms)
        if case.high_cost and not passed:
            high_cost_failures += 1
        rows.append({"id": case.case_id, "passed": passed, **result})
    pass_rate = sum(row["passed"] for row in rows) / len(rows)
    gate_passed = high_cost_failures == 0 and pass_rate >= min_pass_rate
    return {"version": version, "threshold": threshold,
            "pass_rate": pass_rate,
            "high_cost_failures": high_cost_failures,
            "gate_passed": gate_passed, "rows": rows}

cases = [
    Case("T-001", "surface_damage", 0.85, True,
         "WAITING_APPROVAL"),
    Case("T-002", "surface_damage", 0.60, True,
         "NEED_REVIEW"),
    Case("T-003", "unknown", 0.95, False,
         "STOPPED", high_cost=True),
]
report = run_gate(cases, version="1.0.0")
print(json.dumps(report, ensure_ascii=False, indent=2))

程序不能用三条样例证明真实系统可靠，它只展示完整结构。正式测试集需要由专业教师、使用者和开发小组共同建立；若迁移到第10章工作流，还要覆盖其全部状态与权限。学生应检查gate_passed为何通过或失败，而不是把布尔值当成无需复核的上线决定。

三、回归门检查整个已承诺范围

每次修改都运行完整门，不能只重测刚修复的样例。模型阈值变化可能改变人工复核量，检索更新可能影响引用，权限修改可能破坏撤销路径。报告应列出版本、代码提交、模型、资料、规则、测试集和运行环境，确保同一结果可以复现。

若自动测试通过但人工发现建议语义误导，验收仍可失败；若自动测试因环境异常失败，不能直接放行，而要记录环境原因并重新运行。机器门是最低条件，不是责任替代。

回归报告还应保存“为什么没有通过”。失败不能只记一个红色标记，要保留实际输出、期望输出、涉及版本、错误层次和处理责任人。相同失败反复出现时，团队才能判断问题来自训练数据、资料、规则、接口还是环境；没有原始证据，AI给出的修复建议也无法核对。

第三节　在有限试运行中监测质量、成本和漂移

一、试运行不是直接上线

试运行要限定使用者、时间、地点、输入类型、模型版本和人工监督。公共项目可以只开放给一个班级的巡检小组，持续一周，所有正式记录由教师或指定责任人确认。试运行前说明退出方式和问题报告渠道，不能因参与课程而默认授权采集个人影像或声音。

离线验收使用封存数据，试运行观察真实工作环境。二者互补：测试集便于重复比较，试运行能发现输入格式、用户行为、网络、设备和工作负荷变化。试运行中发现的新情况先进入待审核样例库，不自动修改模型。

二、监测可回答的问题

监测至少记录输入数量、拒绝或停止比例、人工复核量、最终改动比例、错误类型、响应时间、费用、资料无命中、权限拒绝和输入分布变化。低风险项目不一定需要实时大屏，一份每天生成的结构化报告可能更有效。

漂移表示运行输入或输入与结果的关系发生变化。可先使用可解释基线：比较本周与验收数据的类别比例、数值范围、缺失率和设备来源。比例变化不自动等于模型失效，但会触发抽样复核。若某类输入从5%变成40%，应调查场景变化、采集方式和标签含义，而不是立即重新训练。

三、区分模型问题和工作问题

人工修改率上升可能来自模型质量下降，也可能来自规范更新、资料过期、使用者输入方式变化或权限设计不合理。监测报告按模型、检索、规则、接口、设备、人员和环境分类。协助开发的AI可以聚类日志和提出假设，但学生必须回到原始事件和专业人员反馈验证。

费用和人工时间也属于质量。模型准确但每条都要长时间复核，或者云端费用随输入长度快速上升，都可能使系统不值得使用。试运行结论应为通过、限定范围继续、退回修改或停止，不能只有“上线成功”。

监测门槛与验收门槛用途不同。验收门决定一个固定版本是否有资格试运行；监测门用于发现运行条件可能已经变化。例如“无命中率连续三天高于验收期两倍”可以触发抽样检查，但不能自动触发模型更新。责任人需要查看原始事件、资料版本和使用者变化，再决定保持、限用还是提出变更。

第四节　在受控更新、回滚和人工接管中维持系统

一、每次更新都要有变更申请

变更申请说明问题证据、拟修改模块、预期改善、不允许改变的部分、负责人和回滚条件。模型、提示、资料、阈值、代码、权限和设备适配都是不同变更类型。一次只修改可解释范围，先在隔离副本上运行固定回归，再进行有限比较。

数据更新尤其要审查来源、授权、标签和泄漏。运行反馈不是天然正确标签；人工修正可能互相矛盾，也可能包含敏感信息。只有经过专业审核的数据才能进入训练候选，训练完成后仍要用未参与更新的测试集验收。

二、发布前准备回滚

可回滚版本至少包含代码、模型、规则、资料索引、配置、依赖和数据库变更说明。发布记录写明谁批准、何时部署、通过哪套测试和怎样观察。若新版本触发高代价错误、监测指标越界或无法解释的状态变化，责任人可恢复上一已验收版本。

回滚不是删除失败证据。失败日志、变更差异和处置过程应保留，以便分析和再次开发。若数据结构发生不可逆变化，还需提前准备备份和转换撤销方案；公共项目使用本地副本演示，不修改真实业务数据。

发布前应实际演练一次回滚，而不是只写“可以回滚”。团队在副本环境中部署候选版本，运行固定样例，模拟触发高代价错误，再按说明恢复上一版本并核对代码、模型、规则、资料和配置是否一致。演练记录包含执行者、耗时、遗漏步骤和恢复后的回归结果；无法在限定时间恢复的版本不能进入试运行。

三、专业迁移卡

专业迁移卡A：商贸售后试运行。 高代价错误是错误承诺退换条件、金额重复和客户资料泄露；监测增加人工改价次数、重复订单和总处理时间。新规则必须由业务责任人批准，回滚时保留已经人工确认的真实记录。

专业迁移卡B：制造巡检验收。 高代价错误是明显异常漏报和传感器失效后继续给出正常。试运行只做旁路观察，不连接控制系统；监测按设备、负载和班次分组。模型更新须在回放与隔离现场通过，再由设备责任人决定是否继续试用。

专业迁移卡C：设计与媒体内容审核。 高代价错误是事实错误、权利材料缺失和未经确认发布；监测增加人工修改率、素材来源缺失率和误拦截。规范更新先进入独立资料版本，不能让模型根据一次编辑反馈自动改写发布规则。

四、经验学习只在审核后发生

系统可以积累运行经验，但“积累”首先意味着保留可审查的事件、人工修正和结果。只有经过清洗、授权、标签复核、离线训练和固定验收，经验才可能进入新版本。在线系统未经审核自行更新，会使行为、责任和回滚基线难以确定，本书不采用这种路径。

人工接管方案写明谁接收停止事件、怎样查看上下文、能做哪些动作和怎样结束。维护不是让模型永远运行，而是在条件变化时仍能保持受控、可解释和可停止。

五、运行完整验收台并形成发布决定

配套工程位于resources/ch11/project/，项目名称是“AI应用验收与试运行台”。它接收的不是一条临时提示，也不是已经填好的答案表，而是一整套冻结对象：测试样例、人工表单基线与两个候选版本的可执行制品、候选声明、发布门、试运行日志和版本登记表。evaluate.py每次都加载制品，只把样例中的输入文本交给候选，现场产生路线后再与期望结果比较；候选看不到测试编号、分组或期望答案。输出也不是一个孤立分数，而是逐例结果、分组指标、发布或拒绝决定、漂移告警和明确的回滚目标。最终由授权人员批准，程序本身不发布任何模型。

工程目录表达了完整过程。data/frozen_tests.json保存封存样例；artifacts/manual_form_v1.json、stable_v1.json和risky_v2.json保存可执行配置，不含outputs答案字段；data/candidate_declarations.json声明名称、版本、制品路径和真实64位SHA-256；gates.json保存测试前约定的门槛；trial_log.jsonl逐条记录时间、候选版本、制品SHA-256、输入来源、场景范围、路线、时延和错误；version_registry.json保存批准状态与同一制品身份。frozen_manifest.json还冻结候选、测试包、门槛、试运行日志、登记表和评测实现。src/candidates.py执行候选，bench.py计算离线指标，monitor.py校验日志归因并检测运行变化，rollback.py选择上一已批准版本。RELEASE_DECISION.md、ROLLBACK_PLAN.md和SYSTEM_CARD.md则把技术结果连接到人的责任。

封存包有8条小样例。正常类包括投影、办公网和滴水三个常见事件，检查候选能否正确进入常规流程；边界类是一条“是否需要登记尚不明确”的输入，预期转人工；陌生类没有已知语义，同样转人工；安全类要求进入紧急或人工安全路径；权限类要求拒绝巡检员直接关闭正式记录；故障类模拟知识模块不可用，必须安全停止。这些样例数量不足以证明真实系统可靠，但完整覆盖了“能做、临界时不猜、遇到未知不猜、模块失败不继续”四种基本能力。

发布门不使用一个总分决定一切。参考门要求普通准确率至少0.80、边界转人工率和陌生转人工率均为1.00、安全召回为1.00、权限违规为0、故障安全停止率为1.00。程序把每项写成独立布尔检查，只有全部为真才给出release=True：

checks = {
    "normal_accuracy": normal_accuracy >= 0.80,
    "boundary_manual_rate": boundary_manual_rate >= 1.00,
    "unknown_manual_rate": unknown_manual_rate >= 1.00,
    "safety_recall": safety_recall >= 1.00,
    "permission_violations": permission_violations <= 0,
    "fault_safe_rate": fault_safe_rate >= 1.00,
}
release = all(checks.values())

为什么安全召回、边界和陌生转人工率要求100%，而普通准确率允许少量错误？因为本项目把这些情况定义为高代价门：一个越权动作或一次故障后继续输出，不能被三个普通样例正确抵消。真实项目的门槛必须根据专业后果重新批准，教材数值不能直接搬到医疗、交通或生产现场。

学生在项目目录运行python acceptance.py。程序检查24项必需文件、14项冻结身份和全部Python语法，运行11个单元测试，再执行完整评估，并把现场结果与正式参考报告逐字段比较。哈希篡改、候选缺失、预填outputs、试运行归因缺失以及混合候选版本都会被故障测试拦截。参考环境的实际结果是：人工表单基线现场执行后精确符合4/8，因为它把普通事件交给人；stable-v1为8/8并通过所有门；risky-v2的三个普通样例都正确，却把边界和陌生输入送入常规流程，还放过安全、权限和故障问题，因此只有3/8并被拒绝。这个对照把“平均表现好”与“有资格试运行”明确分开。

试运行监测使用8条按时间记录的日志。每条还必须说明候选版本、制品SHA-256、输入来源和场景范围；缺少这些字段，即使数值完整也无法把异常归因到具体版本和试运行边界，程序会拒绝计算，同一汇总也不得混合不同候选版本。当前日志都归因到stable-v1、其已登记制品、授权工单入口表单和“工作现场低风险设备巡检旁路观察”范围。程序计算95百分位延迟、错误率和输出类别分布，并用总变差比较参考分布与观察分布。总变差可直观理解为：把两组类别比例变得相同，至少需要移动多大比例的样本；值越大，分布差异越明显。本次实际结果为95百分位延迟610毫秒、错误率12.5%、总变差0.450，分别超过500毫秒、10%和0.20的本次试运行门槛，因此alert=True。告警只表示原假设可能不再成立，需要检查输入、系统和工作方式；它不自动证明模型退化，也不触发在线训练。

回滚模块读取版本登记表，在当前risky-v2之前寻找最近的approved=true版本，得到stable-v1。登记表中的制品路径与SHA-256必须和候选声明、文件实算结果、正式报告一致，不能只凭相同版本名回滚。回滚计划要求先暂停扩大使用范围，保存失败日志、候选制品摘要和测试包哈希，再恢复旧版本并重跑全部封存测试。哈希使团队能判断“使用的是否还是同一个文件”，但不能证明样例设计本身充分，也不能替代责任人批准。

学生的控制变量实验只改一个普通质量门，例如把普通准确率门从0.80提高到1.00，先预测两个候选的结论，再运行非封存练习数据；不得通过放宽安全、权限或故障门让风险版本通过。AI限定修改可以新增一个“证据冲突”分组及相应指标：学生先写测试和预期，再要求AI只改bench.py与练习数据，审查差异并重跑acceptance.py。封存答案不能放进训练、提示优化或反复试错过程。最终报告必须写“采用、限用或拒绝”的理由，而不能只附一张绿色截图。

本章小结

验收把专业后果变成可执行门槛，把固定测试、人工复核、系统状态和恢复能力放在同一个结论中。总准确率不能掩盖高代价错误，自动门也不能替代责任人批准。

有限试运行用于发现真实环境变化，监测用于发现原有假设是否仍成立。任何更新都要经过变更申请、隔离修改、完整回归、批准发布和回滚准备。运行反馈只能成为待审核经验，不能让系统未经验证自行改变关键行为。

关键术语

• 验收门：系统必须满足后才能进入下一使用阶段的一组质量和安全条件。
• 高代价错误：即使数量较少，也会造成不可接受后果的错误。
• 规则基线：不用复杂模型、以固定规则完成同一任务的比较起点。
• 回归测试：修改后重新运行固定测试，检查旧功能是否被破坏。
• 试运行：在限定范围和人工监督下观察系统真实表现的阶段。
• 数据漂移：运行输入的分布或含义相对验收阶段发生变化。
• 受控更新：经过申请、审查、隔离修改、回归和批准的版本改变。
• 回滚：恢复到上一已验收版本的过程。
• 监测：持续记录质量、成本、延迟、错误和输入变化以发现失效信号。

目标测试

一、单项选择题

1. 验收门首先应依据（　）确定。A．可用图表样式　B．专业错误后果和任务合同　C．模型参数数量　D．开发者偏好
2. 下列做法能保持测试独立性的是（　）。A．把失败测试补进训练后继续称其为独立测试　B．冻结测试集并为更新保留未参与训练的样例　C．测试后再改门槛　D．只保留通过样例
3. 试运行与直接上线的主要区别是（　）。A．不记录日志　B．限定范围、时间、使用者并保留人工监督　C．允许系统随时自我修改　D．不需要回滚
4. 新版本触发高代价错误时，首先应（　）。A．删除失败日志　B．按预案停止或回滚并保留证据　C．扩大使用范围　D．降低验收门

二、判断并改错

5. “总准确率达到95%，即使有一条不可接受的越权写入也可以通过验收。”请判断并改正。
6. “试运行中的人工修正都是真实标签，可以立即用于在线更新模型。”请判断并改正。

三、简答与操作题

7. 为一个专业AI应用列出两类普通错误和一类高代价错误，并分别提出门槛。
8. 设计一个包含正常、边界、陌生、诱导、故障和权限变化的六条测试清单。
9. 说明离线测试、系统验收和有限试运行分别解决什么问题，为什么不能互相替代。
10. 写出一次受控更新从问题证据到发布或回滚的完整步骤，并指出至少两个由人批准的节点。

答案编号：A2-11-01—A2-11-10。完整答案与评分要点统一放入书后“目标测试参考答案”。