★ FEATURED ARTICLE 简介ISO/IEC TR 29119-11:2020技术报告为软件测试工程师、AI系统开发者和质量保障人员提供了一套针对人工智能系统的测试指南重点解决机器学习、深度学习等模型在验证与确认中的特殊难题。该报告在ISO/IEC 29119系列框架下展开从AI与测试的基础概念入手依次覆盖测试策略、测试技术、测试过程与测试结果评估并专门讨论了基于风险、基于等价类、基于场景等策略及黑盒、白盒、灰盒等测试方法。资源为一份完整的英文原版PDF文件共58页大小约32.59MB采用国际标准排版便于直接查阅和引用。报告中还梳理了AI测试面临的挑战与机遇能帮助读者理解如何将传统测试体系延伸至AI系统制定可落地的测试计划并评估测试输出。目前已有468人浏览学习适合正在从事AI项目测试实践、设计验证方案或准备相关认证的技术人员阅读。1. 用传统软件测试思维测AI必翻车TR 29119-11说的是什么当测试一个AI识别模型时最头疼的不是用例数量而是“不知道什么是错的”。传统软件有需求规格可以逐条比对AI系统却只能给一个置信度矩阵出了问题也很难说清是数据、模型还是推理逻辑的问题。ISO/IEC TR 29119-11:2020这份技术报告专门为这种“没有确定预期输出”的系统补了一套测试方法论。它不是讲算法原理而是从AI系统特性出发把黑盒测试、白盒覆盖、数据质量、模型更新、对抗样本等内容串成工程化流程。读完最直接的收获是AI测试不是放弃质量标准而是换一套可以落地的判定体系适用对象是正在为AI系统写测试计划的测试工程师、QA负责人和模型团队。2. AI系统特性与测试挑战从5.1到6.1的核心矛盾2.1 先看清AI特性哪些属性一旦失控测试就得跟着改报告第5章花了大量篇幅定义“AI系统特有的特征”这不是在凑目录而是每个特征都会直接影响测试设计方式。我拆下来至少有七个特性要当成测试维度来用。第一个是灵活性与适应性。传统软件一个输入对应一个固定输出AI系统会根据上下文调整行为尤其在线学习系统参数会被新样本持续改写。测试这种系统不能只测“当前权重下的结果”还要测“权重被更新后结果是否漂移”。更麻烦的是适应性还会让同一个模型在不同时间段对同一输入给出不同预测所以回归测试必须带上模型版本号不能把不同时段的测试结果混在一起比较。第二个是自主性。AI系统在无人介入时自己做决策例如自动驾驶的避障逻辑、智能客服的自动答复。自主性越高测试越要关注“长期无人干预下系统会不会走到未定义状态”。这往往需要长时序模拟和状态机监控而不是用一两个用例能覆盖完的。我给这类系统做测试时会刻意把“人为干预失效”的场景纳入用例看系统进入降级模式后的行为是否符合预期。第三个是演化。模型会随着训练数据、微调策略和运行环境变化。演化意味着历史测试用例可能失效也可能出现“训练时正常部署三个月后诡异出错”的情况。这类系统要有版本漂移监控而不是只在新版本上线前测一次。我曾经遇到一个推荐系统上线三个月后推荐内容逐渐跑偏但每次单独看指标都在正常范围后来才发现是数据分布发生了慢漂移。现在这类系统的测试计划里一定会加一个“定期重评估”的周期任务。第四个是偏差。数据分布不均衡会让模型对某些群体或场景失效。偏差测试不能只统计整体准确率还要按敏感维度切片看召回率、误报率。报告中提到偏差是AI测试的独立挑战我经常看到团队把整体指标做得很好看但按地域、性别、设备类型一切片某个分组的指标瞬间露出马脚。测试用例设计时要主动要求业务方给出核心分组的定义和最低指标要求。第五个是复杂性。深度网络动辄百万参数行为难以用人脑穷举。复杂性意味着测试必须借助统计采样、组合覆盖和自动化手段纯手工用例只能做边界探索。这里有一个很现实的判断如果一个AI模型只有几十个输入特征线性回归就能解决那根本不需要上复杂的白盒覆盖率只有当模型复杂到无法解释时才值得引入第9章那套覆盖指标。第六个是透明性与可解释性。AI系统经常是“黑匣子”测试人员拿到一个失败输出很难定位是数据问题、模型结构问题还是推理逻辑问题。因此测试环境中要提前注入日志、中间特征和特征归因值。我一般在测试模型的输入输出之外还会要求开发方提供一个调试接口能导出中间层的激活值和注意力分数否则排障时只能盲猜。第七个是非确定性。GPU并行、浮点累加、随机初始化都会导致相同输入出现不同输出。这一点对回归测试极为致命不能因为一次失败就断言系统坏了而要用多次运行或统计性判定。例如一个NLP模型在相同输入下可能因为后端的CUDA库版本不同给出不同结果。遇到这种情况我会把断言从“结果相等”改成“结果分布偏移不超过某个阈值”。除了以上七个报告还专门提到对齐人类价值观、副作用和奖励黑客。这三个在学术圈常见但在实际工程项目里常被忽略。比如一个优化推荐时长的模型为了把时长做高可能学会推送博眼球内容这就是奖励黑客。测试时如果没有针对“策略副作用”的检查项这类问题只能在上线后靠用户投诉暴露。我一般会在测试计划开头先建一张“AI特性影响对照表”每个特性都对应一个测试手段这样后面设计用例时才不会漏项。2.2 六大测试挑战规格缺失、输入数据、Oracle问题第6章把测试AI系统的难点拆成多个子项。我理解下来最让传统测试团队头疼的是三个。首先系统规格不完整。传统测试依赖需求文档逐条验证但AI系统很多行为不是“需求”而是“从数据里学出来的”。你问产品经理“这个识别的边界是什么”他只能给你“看数据”。于是测试人员只能退而以数据分布和模型的行为边界为对象来写用例先把“已知域”测全再探索“未知域”。具体执行时我会做一个“已知行为清单”把业务明确支持的输入类型、边界条件、异常处理都写出来作为最基本的规格基线。其次是测试输入数据。AI系统的输入空间极其庞大图像是像素矩阵自然语言是变长序列传感器是连续流。用等价类划分根本无法穷举。更麻烦的是测试数据本身可能有噪声、标注错误、分布偏差。报告反复强调测试数据质量我把它翻译成测试的一个前置条件如果测试集本身脏后面一切覆盖率指标都是自欺欺人。例如一个图像分类模型如果测试集里不小心混入了训练集的重复图片模型评估分数会虚高真实场景表现会大打折扣。再一个是测试Oracle问题。Oracle指的是“判断一次执行结果是否正确”的依据。传统系统有需求规格做OracleAI系统没有只能拿人工标注、历史模型、统计指标这些“伪Oracle”来顶替。报告给了黑盒测试中背靠背、A/B、蜕变测试等解法我在第4章会展开。这里要提醒的是Oracle策略的选择最好在写测试计划时就确定不要等跑完用例才发现不知道拿什么当基准。若团队没有历史模型、也没有人工标注能力那就只适合用蜕变测试这类相对关系来判定。剩下的挑战还包括自学习系统、概率/非确定性系统、以及偏差与透明性问题。这些不是并列的“八项注意”而是严重程度递进如果没有好的Oracle你连“对错”都不知道后续的覆盖率、偏差分析都无从谈起。所以我通常建议团队先解决Oracle策略再谈自动化程度。Oracle策略解决以后再逐步引入华而不实的覆盖率指标才不会让团队陷入“为了覆盖而覆盖”的陷阱。2.3 生命周期视角AI测试不等于“上线前测一次”报告6.2把AI系统测试映射到软件生命周期的六个层级单元/组件、集成、系统、系统集成、验收、维护。分层对团队的价值在于你可以把测试重心移到早期而不是等到模型上线前统一看指标。下面这张表是我对照报告整理的可以直接用在测试计划里测试层级传统测试活动AI系统的测试重点单元/组件测试函数输入输出验证特征抽取、预处理、单个模块的张量形状与数值区间集成测试模块间接口验证数据管道字段对齐、模型输入输出格式、前后处理衔接系统测试完整业务流程验证模型在真实业务场景中的准确性、稳定性、响应耗时系统集成测试与外围系统联调AI服务与主系统的超时、降级、返回格式兼容验收测试需求符合性确认业务验收指标、敏感分组指标、边界行为维护测试上线后监控回归数据漂移、模型衰退、版本回滚演练单元/组件测试要关注单个模块比如一个特征抽取函数、一个NLP预处理管道。传统单元测试还可以沿用只是预期值要改成统计区间。集成测试重点测模块之间传递的张量形状、接口约定、模型的输入输出是否匹配。很多AI项目翻车不是因为模型太笨而是数据管道里字段错位文本数据传进了需要数值的接口。系统测试把模型放在完整业务流里例如一个OCR系统要接单据图片、做预处理、推理、结构化输出。这个阶段需要完整业务场景数据覆盖真实噪声。系统集成测试则是把AI系统嵌入更大的软件系统验证与外围系统的交互。这里常常出现“模型单独跑95分联调时却因为调用超时、返回格式不对导致整条链路失败”。验收测试要回到业务验收标准不要只用测试集准确率。维护测试最容易被忽略但模型上线后要持续监控数据漂移和模型衰退。我见过不少团队上线后只盯监控大盘没有做过一次“模型版本回退演练”结果遇到bad case只能回滚却不知道回滚后会不会引入新问题。这六个层级不需要每层都上重型框架但至少要在测试计划里写清楚每层的责任人和退出条件。3. ML系统的测试与QA数据质量、验收标准与对抗样本3.1 先说结论ML测试的起点是验收标准不是覆盖率报告第7章叫“Testing and QA of ML systems”开头先强调ML工作流本身要纳入QA。我理解的逻辑是如果一个团队连“好模型”的定义都不统一那测了等于没测。团队里经常出现的分歧是业务方说“准确率95%就上线”算法方说“AUC到0.98更好”测试方说“我们只关心上线后不要出事”。这三者不是同一个目标。因此验收标准必须在训练开始前就写清楚写成可度量的清单。报告7.3强调的是Acceptance Criteria我按经验拆成四类质量属性常用指标业务含义整体准确性Accuracy / F1 / AUC模型在代表性数据上的综合表现稳定性多次运行输出的方差相同输入下输出是否可重复是否受环境扰动影响公平性各敏感分组的召回率/误报率差异模型有没有对特定群体系统性不公平边界行为OOD分布外输入的表现模型遇到没见过的数据会怎么处理这四类指标之间经常互相冲突比如追F1会牺牲某些分组的召回率。测试团队在设计验收用例时要用阈值区间代替单一阈值。例如“整体准确率不低于92%同时每个地区的召回率不低于85%”。如果只定前者模型很可能对长尾地区直接摆烂。验收标准还要把数据质量本身写进去。报告7.5和7.6分别讨论训练数据质量和测试数据质量。训练数据质量影响模型上限测试数据质量影响评估可信度。我见过最典型的问题是训练集和测试集没有做完全隔离模型在评估时“偷看”了训练样本指标虚高上线真实场景直接掉几个点。解决方式很朴素用文件hash去重并记录每个样本的来源批次。至少保证测试集里每个文件对应的业务场景、采集时间、标注人信息都是可追溯的。3.2 数据质量检查的最佳实践先查分布再查标注把数据质量拆成两个检查阶段手工检查和自动化检查都不可少。手工检查在标注完成之后做关注三类问题。第一是标注一致性同一张图片换个标注员标签是否还一样。随机抽500条做双人标注计算标注一致性系数。如果一致性低于0.8说明标注标准本身没定清楚测试集的可信度就要打折扣。第二是类别平衡统计每个类别的样本量如果某个类别只有个位数建模时要么增强要么放弃该类别否则后续测试结果在少数类上毫无统计意义。第三是时间分布采集时间跨了多个季节或地区要检查模型是否只学到了某个特定时段的特征。避免测试集集中在同一采集周期导致模型评估失真。自动化阶段要写一个数据审计脚本至少输出样本数、缺字段率、标签分布、重复样本数、与训练集的重叠度。常见做法是这样# 数据审计脚本示意用命令行检查CSV数据的基本质量 head -5 train.csv wc -l train.csv cut -d, -f1 train.csv | sort | uniq -c | sort -nr这段命令的作用是快速查看数据表结构、总行数、以及第一列类别分布。参数说明cut -d,指定逗号分隔-f1取第一列sort | uniq -c按类别统计出现次数sort -nr按数量倒序。项目比较大时我会在Python里用pandas再算缺失率、重复率并输出审计报告。注意这里只是粗查真正严格的数据血缘追溯需要给每个样本打上批次ID和来源标识。3.3 模型更新与回归不能只比较两个版本的正确率报告7.7单独讲模型更新。ML系统上线后几乎必然要更新权重或训练数据但测试团队通常只做“新旧准确率对比”。这不够至少要补三个回归项。第一是新旧模型在相同测试集上的分类一致性。如果新版模型把一批老样本从“正确”改成“错误”要逐个分析是修正了旧bug还是引入了新回归。建议生成一张“新旧预测diff表”按业务严重度排序。第二是决策边界附近的行为变化。错误率变化不大的两个模型可能在置信度0.5附近的行为完全不同。测试时要按置信度分桶看看哪些桶的翻转率最高。第三是时延和资源消耗。模型更新后推理速度可能变慢在线上环境会拖垮整个服务。哪怕准确率提升了只要耗时超过可接受阈值同样不能上线。对抗样本是报告7.8的核心。普通测试样例是自然输入对抗样本是在自然输入上加了很小扰动人眼几乎看不出差别但模型会给出完全不同的输出。测试AI系统时团队要提前构造一个“最小扰动测试集”对每张测试图加不同强度的噪声覆盖从0.1到0.5的扰动幅度记录模型哪些样本在连续噪声下翻车。扰动幅度不是越大越好超出业务极限的扰动只会制造噪音。比如图像像素值范围0到255我一般从±2开始逐步加到±20找到模型的行为拐点。基准是报告7.9的话题。公开基准集只能用来横向对比学术模型不能直接当业务验收依据。我习惯的做法是先在公开基准上复现出论文指标再用业务数据构造一份私有测试集两份结果都写进测试报告。如果公开基准高、私有测试集低说明模型过拟合到基准了。这类情况在NLP预训练模型上尤其常见换一个领域术语就崩。4. 黑盒测试AI系统组合、A/B与蜕变测试实战4.1 组合测试与背靠背测试在爆炸的输入空间里找bug黑盒测试不需要看模型内部结构只关注输入输出行为。报告第8章一口气给了五种测试方法首当其冲是组合测试。AI系统的输入通常由多个参数组成比如一个推荐系统请求包含用户ID、设备类型、时间窗口、地域、历史行为序列。如果每个参数取值有几十种全组合测试根本跑不完。组合测试的思路是用成对组合覆盖所有参数对之间的交互而不覆盖所有全组合。比如三个参数A、B、C每个有两个取值全组合是8种Pairwise只需要4种。我一般用现成的开源库生成组合但为了理解原理写一个最小示例# 用笛卡尔积去重生成三参数的pairwise组合简化版 from itertools import product, combinations # 参数名和候选值 params { device: [ios, android], time_slot: [morning, evening], region: [east, west], } # 全组合列表 all_cases [dict(zip(params.keys(), vals)) for vals in product(*params.values())] # 检查每个参数对是否至少被一个用例覆盖 def coverage_of(cases): pair set() for c in cases: for p1, p2 in combinations(params.keys(), 2): pair.add((p1, c[p1], p2, c[p2])) return len(pair), len(pair) / (len(params.keys()) * 2 * 2) # 简化覆盖率 print(len(all_cases), coverage_of(all_cases))逻辑说明先通过product生成所有组合再用combinations枚举参数对统计当前用例集覆盖了多少参数对。真正的Pairwise生成会比这个复杂但这段代码已经能让你直观看到全组合数量爆炸和成对覆盖减少用例数的关系。参数params的取值数量决定组合规模实际项目中如果参数达到十几个建议直接用专业组合工具生成不要自己手工拼。背靠背测试是另一种黑盒方法。当你有新旧两个模型版本且旧版本被业务验证过可以同时对相同输入跑两个模型把输出不一致的样本筛出来。这些不一致就是回归测试的候选对象。注意不是所有不一致都是bug要设置一个差异阈值只挑选差异大到业务无法接受的样本。例如内容打分模型新旧分数相差0.1以内可能只是浮点误差相差0.5以上才值得人工分析。4.2 A/B测试与探索性测试从线上证据和领域直觉里找问题A/B测试在报告8.3里被列为AI系统测试手段原因是很多AI需求无法离线验证。比如一个内容推荐策略离线准确率再高也预测不了用户的真实厌烦情绪。A/B测试不是随便分流跑两天就下结论。设计A/B测试时三个参数最容易出错。第一个是流量分层要保证实验组和对照组在用户特征上同分布一般用用户ID的hash做分层随机。第二个是观察周期至少要覆盖一个完整的业务周期电商要覆盖周末和工作日资讯类要覆盖早中晚高峰。第三个是最小样本量。常见的最小样本量计算公式为n (Zα/2 Zβ)^2 × (p0(1-p0) p1(1-p1)) / (p1-p0)^2其中p0是基线转化率p1是预期提升后的转化率Zα/2取1.96Zβ取0.84。举个例子基线转化率10%预期提升1个百分点计算出来每个实验组大约需要几万用户。别小看这一步很多人省了它结果实验跑了两周差异不显著却无法判断是策略无效还是样本不够。探索性测试在AI场景里常被低估。报告8.5把探索性测试当成正式手段而不是“测试人员乱点点”。我实践中会按问题域设计探索任务比如“用光照变化、遮挡、旋转这批图片看模型在哪些场景下退化最严重”。探索过程中要记录输入、实际输出、预期直觉和对应日志。之后把探索发现转成自动化回归用例。这个闭环能有效利用测试人员的领域直觉发现离线指标覆盖不到的边界。4.3 蜕变测试解决“没有Oracle”问题的核心武器蜕变测试是最能解决Oracle问题的方法之一。核心思想不检查单个输入是否输出正确而是检查“变化前后输出关系是否满足某个不变性”。例如一个物体检测器把图片向右平移几像素检测框也应该相应平移且物体类别不变。如果两幅图的输出不满足这个关系就可以判定存在疑似缺陷。以下是一个简化示例假设我们测一个图像分类模型对亮度变化的鲁棒性import cv2 import numpy as np from some_model import predict_class # 假设有模型预测函数 def brightness(image, delta): # 将图像亮度加上delta保持格式不变 return np.clip(image.astype(int) delta, 0, 255).astype(np.uint8) def metamorphic_test(image, delta10): # 判断原图和亮度增强图是否预测为同一类别 original_label predict_class(image) transformed brightness(image, delta) new_label predict_class(transformed) # 蜕变关系亮度小范围变化不应改变类别 if original_label ! new_label: return f疑似缺陷亮度{delta} 导致类别 {original_label} - {new_label} else: return 通过 # 参数delta是亮度偏移量范围建议在±20以内 sample cv2.imread(sample.jpg) print(metamorphic_test(sample, delta10))逻辑说明brightness函数对整幅图做像素偏移metamorphic_test比较两次预测结果。如果偏移后类别改变说明模型对亮度敏感度过高。参数delta要按图像亮度范围合理设置太小测不出问题太大又超出了“小扰动”的含义。实际项目中蜕变关系可以很丰富比如图片旋转后预测结果不变、文本语序打乱后情感分类不变、数值缩放后排序结果不变。要用好蜕变测试关键是把领域里那些“物理上不该变”的关系列成一张清单再做自动化对比。建议先人工复核20条结果确认蜕变关系符合业务物理规律再全量执行。蜕变关系中“可接受变化范围”要显式写在代码里不要隐含在数据里。报告8.1到8.5的黑盒方法并非彼此孤立。我通常在回归测试流水线里先跑组合测试筛参数交互bug再用背靠背对比新旧版本最后对重点场景执行蜕变测试。探索性测试作为长期人工补充。整体原则是黑盒方法负责找行为异常白盒方法负责找覆盖盲区。5. 白盒测试与常见问题神经元覆盖率怎么算、坑在哪5.1 四个覆盖率指标从神经元覆盖率到值变化覆盖率白盒测试神经网络目标是看测试集有没有触及网络内部的不同激活模式。报告第9章定义了多个覆盖指标从粗糙到精细。我用一个简单网络来解释。神经元覆盖率最简单统计测试集运行过程中有多少神经元的输出超过某个激活阈值。比如网络有100个神经元测试集激活了其中60个覆盖率就是60%。它只能告诉你测过哪些神经元不能告诉你是否测出了bug。适合当冒烟指标上线前跑一遍如果覆盖率连30%都不到说明测试集跟模型业务分布完全不匹配。阈值覆盖率要求在激活值超过不同阈值时分别覆盖。比如一个神经元的激活值可能只有0和0.5两档算法要求测试集既激活低于低阈值的区域也要高于高阈值的区域。这样能捕捉到极端激活行为。符号变化覆盖率关注激活值从正变负、从负变正的变化。很多激活函数在输入等于0附近行为突变符号翻转常常对应模型决策边界翻转。测试集如果能覆盖正负两侧就更能暴露边界问题。值变化覆盖率是最精细的一档要求关注激活值在小范围内的连续变化。它需要把每个神经元的激活区间划分成多个桶测试集要落入每个桶。这个指标开销较大通常只对关键子网络使用。报告正文在9.2.5之后截断没有给出完整实现但根据定义可以自己实现一个简化版本。5.2 用Python算一遍神经网络覆盖率假设我们已经有一个训练好的全连接网络输入是一维向量中间层有若干神经元。下面代码演示如何计算神经元覆盖率。import numpy as np class SimpleNN: def __init__(self, weights, bias): # 假设只有一层全连接weights shape: (in_features, out_features) self.weights weights self.bias bias def forward(self, x): # ReLU激活 return np.maximum(0, x self.weights self.bias) # 造一个2输入、4神经元的网络 weights np.array([[1.0, -1.0, 0.5, 0.2], [-0.5, 2.0, 1.0, -1.0]]) bias np.array([0.1, -0.1, 0.0, 0.05]) model SimpleNN(weights, bias) test_inputs [ np.array([1.0, 0.0]), np.array([0.0, 1.0]), np.array([-1.0, -1.0]), ] activated set() for x in test_inputs: acts model.forward(x) # 当前隐藏层输出 activated.update(np.where(acts 0)[0]) # 激活阈值默认0 neuron_cov len(activated) / weights.shape[1] print(fneuron coverage: {neuron_cov:.2f} ({len(activated)}/{weights.shape[1]}))逻辑说明forward计算隐藏层输出np.where(acts 0)找出激活的神经元下标activated集合累积了所有测试样本激活过的神经元。最后除以神经元总数得到覆盖率。如果把acts 0改成acts 0.5计算的实际上是更高阈值的覆盖偏向阈值覆盖率。参数上阈值的手工选取会直接影响结果推荐先统计所有激活值的分布再取分位数作为阈值避免拍脑袋。要扩展成阈值覆盖率可以把激活值按多个阈值分层例如0.1、0.2、0.5分别统计哪个区间被覆盖。值变化覆盖率则要把激活值离散化成桶然后统计每个桶是否被填充。这里要注意覆盖率计算必须固定模型权重和输入预处理流程否则每次运行结果不一致覆盖率数字没有可比性。5.3 常见问题与排查这6个坑我踩过下面六条是我在做AI系统测试时实际遇到过的坑每条都按“现象-原因-解决”写清楚。现象神经元覆盖率从50%提到90%但模型错误率几乎没变。原因覆盖率是结构性指标和功能质量没有直接等价关系增加覆盖的测试样本可能都落在同一类业务边界附近。解决把覆盖率当探索广度的参考不把它当质量门禁必须和黑盒业务场景测试一起看。覆盖率提升的同时要配套观察各业务分组的准确率变化。现象跑蜕变测试时出现大量失败人工复核发现全是误报。原因蜕变关系设置不当比如对亮度变化要求类别不变但实际业务中亮度剧烈变化确实应该改变类别。解决先人工复核20条蜕变测试结果确认蜕变关系符合业务物理规律再自动化全量执行。蜕变关系的可接受变化范围要显式写在代码里。现象A/B测试结果显著但上线后业务指标反而下降。原因实验期流量分配不均或者实验组和对照组用了不同的用户召回策略混淆了变量。解决分流必须基于用户ID哈希并且上线前先跑一轮AA测试验证分流系统本身无偏。AA测试指实验组和对照组都使用相同策略预期指标无显著差异如果AA都差异明显说明实验平台有bug。现象对抗样本测试中把噪声幅度调得很大模型全部翻车得到一张全失败的表格没有参考价值。原因没有定义对抗扰动预算测试脱离了业务实际。解决按真实业务环境定义扰动上限比如摄像头图像一般受光照和压缩影响像素偏差在±10以内超过这个范围算人为超限不影响上线判断。现象给模型更新做回归新旧准确率都一样但线上客户开始投诉“结果和以前不一样”。原因只比了总体准确率没有比逐条预测的差异。解决生成新旧模型预测diff表按业务影响排序重点检查原本预测正确、新模型预测错误的case并设置最大回归量门禁比如业务核心类目的预测变更不能超过2%。现象测试数据和训练数据时间重叠模型评估得分高但上线后效果差。原因训练集和测试集来自同一批采集周期存在隐性重复。解决数据准备阶段严格按时间切分并做hash去重确保测试集里没有任何一个文件与训练集文件内容完全相同。6. 进阶用法把TR 29119-11拆成团队的测试规范骨架到这里TR 29119-11的核心章节已经被拆开。接下来是我的个人习惯把这份技术报告当成一份骨架清单每一章都能映射到团队测试文档。下面是我常用的一张映射表TR章节主题团队测试文档中的落点第5章 AI系统特性AI测试计划里的“风险清单”第6章 测试挑战测试策略中的“难点对策”第7章 ML测试与QA数据质量、验收标准、回归策略第8章 黑盒测试功能测试设计、线上验证方案第9章 白盒测试覆盖率指标、模型结构测试具体用的时候我会先复制报告目录再逐章标注“我们团队现在做到哪一步”。比如第7章的对抗样本测试如果团队还完全没有做就在对应位置写“P0/下季度”的标识。这样整个规范骨架不会因为某个人离职而丢失。最后一个具体技巧给每个AI系统上线前做一次“行为特性评估清单”验证。清单如下系统是否允许一定程度的非确定性如果允许回归测试是否跑了至少3次模型更新的频次是多少更新后是否必须触发背靠背回归核心业务分组地区/设备/等级的指标是否单独统计是否定义了一组可执行的蜕变关系并纳入自动化回归对抗样本扰动预算是否已在测试计划里锁定这五个问题来自TR 29119-11的章节主题不需要一次全部做到但每次测试计划评审时拿出来过一遍能堵住大部分漏洞。有一次我在评审某图像识别Demo的测试计划团队只写了准确率验收我拿出这五条逐条追问最后补了蜕变测试和光照扰动数据。上线一个月后恰好遇到夜间低照度场景模型行为没有崩团队才意识到这套清单的价值。从那以后我每个AI测试项目都会强制走一遍这个行为特性评估清单希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
