什么是模型验证？

模型验证并不只是询问“模型能否生成答案？”，而是要评估模型的设计、假设、数据、实施方式、输出、局限性以及持续运行的行为是否足够可靠，能够支持人们据此做出的决策。

模型验证使企业能够通过主动评估模型履行其职责的表现，降低模型风险，即模型产生不准确、有偏倚、不稳定、不安全或被误用的结果的风险。

对于简单的验证，模型开发人员可以在开发过程中，仅使用验证集评估候选模型。验证集是 ML 工程师和数据科学家用来检查模型学习效果的一组示例。

然而，在模型风险管理层面，模型验证的范围要广泛得多。通常，企业级模型验证是对整个模型生命周期进行的独立评估。ML 模型由非模型创建者的人员进行审查，审查范围涵盖模型的构建、上线、使用、监控、变更以及最终停用。

成功的验证过程可以确定五件事。

1. ML 模型具有明确的目的、明确的群体、范围和决策上下文。
2. 模型的概念方法（底层的输入到输出映射方法、逻辑和假设）对于该用途而言是合理的。
3. 模型使用的数据和模型的实施都是准确且受控的。
4. 该模型在相关数据上表现良好，包括在开发过程中未曾接触过的数据。
5. 组织了解模型的局限性，并在性能下降时采取行动。

模型验证流程的严谨程度通常与模型的用途相匹配。低影响的内部预测工具无需像用于审批抵押贷款或检测银行欺诈交易的模型那样接受深入审查。

需要特别注意的是，模型验证并非一次性的审批环节。模型即使在最初表现良好，也可能在发布后发生漂移并出现性能下降，因此，持续进行 ML 模型验证通常已融入企业的人工智能 (AI) 治理实践中。

根据 NIST AI 风险管理框架，模型信任的支柱包括有效性和可靠性、安全性、安全防护和弹性、问责制和透明度、可解释性和可诠释性、隐私增强，以及公平性和偏倚管理。

机器学习模型验证有助于建立和维护模型信任（即对模型将按照预期正常运行所抱有的有充分依据的信心）。企业会根据 ML 模型的输出做出决策，因此，模型信任不仅仅是声誉层面的目标，也是安全、有效且可扩展地使用 AI 的基础。事实上，模型信任目标通常会为模型验证实践提供指导。

此外，不能仅仅因为模型的开发人员称其为“负责任的 AI”，就认定该模型值得信赖。模型必须能够可靠地执行任务、保护人员和数据、抵御误用，并且能够被理解和治理。这种程度的信任必须通过可验证的控制措施，以及在 AI 模型验证过程中持续收集的证据来赢得。

理解模型信任各支柱的一种广泛采用的方法是参考美国国家标准与技术研究院 (NIST) AI 风险管理框架。该框架确定了值得信赖的 AI 的七项相互依存的特征。

可信赖的模型必须适用于其任务，并且能够在预期条件下长期保持可靠。有效性关注的是模型是否确实在衡量、预测、分类或生成其所声称要衡量、预测、分类或生成的内容。

可靠性关注的是，当模型接收到相似的输入时，能否持续、可靠地执行，包括来自不同用户、环境、数据源和时间段的输入。

安全性支柱关注模型是否可能对人员、财产、组织或社会造成危害，即使模型在技术层面按照设计正常运行。

模型可能既准确又不安全。例如，客服聊天机器人可能能够正确检索账户信息，但如果它可以被操纵而泄露敏感数据，那么它仍然不适合部署。安全性要求团队在部署前识别可预见的危害，并通过系统设计主动加以应对。

安全性保护模型、其数据、接口以及周围的应用程序免受恶意访问或操纵。对于现代 AI 系统而言，攻击面远不止模型权重，还包括训练数据、检索源、提示、应用程序编程接口 (API)、插件、用户身份、部署基础设施、日志以及模型供应链。安全控制必须能够管理整个攻击面。

韧性是指模型在出现问题时继续安全运行、适当恢复或平稳失效的能力。这意味着需要验证模型能否应对非恶意的中断以及网络攻击。在高影响场景中，安全失效往往比单纯保持可用更为重要。

问责制意味着明确指定的负责人应对模型的设计、部署、结果和修复负责。如果缺乏问责制，一旦出现问题，企业就可能以“这是 AI 的决定”为由推卸责任。

透明度意味着，与系统、其输出、局限性和治理相关的所有信息都应向需要这些信息的人员提供。透明度并不要求企业披露专有源代码或敏感的安全细节，而是要提供足够准确且有用的信息，使利益相关者能够全面了解系统的各个方面。

可解释性和可诠释性有助于人们了解模型的工作原理，以及其输出在实际决策中的含义。简单来说，可解释性回答的是“哪些因素或过程导致了这一输出？”，而可诠释性回答的是“这一输出意味着什么，以及人员应如何使用这一输出？”

当决策具有重大影响、存在争议、受到监管或难以撤销时，这一支柱尤为重要（例如，信用风险建模）。

隐私与安全性密切相关，但两者的概念有所不同。安全性防止未经授权的人员访问数据，而隐私有助于确保数据得到适当的收集、使用、存储和共享。

即使模型并非专门用于处理个人数据，也可能带来隐私风险。模型训练集可能包含敏感信息，而日志可能会保留原本只应临时存储的用户数据。模型验证实践有助于企业确保 AI 工具既安全又符合隐私规则。

公平性要求组织识别、衡量、减少和监控有害偏倚。这并不意味着每个人都必须始终获得相同的输出。相反，不同的处理方式或结果必须具有合理依据、符合法律规定、与任务相关，并且不受可避免或有害偏倚的驱动。

模型验证通常包括一系列不同的检查和验证技术。

概念合理性评估模型的底层逻辑和设计。它评估模型所采用的方法、输入、假设、定性判断和设计选择是否适合模型旨在支持的决策。合理性检查包括：

• 评估模型的方法，了解模型如何将数据转化为输出。

• 检查特征和输入，确认每个重要特征都具有相关性、可用性并且符合法律规定。

• 挑战假设，用于文档记录和监控。

• 识别局限性和缺失因素，了解模型所不知道的信息，以及模型在哪些情况下会变得不那么可靠。

• 评估可诠释性和使用的适当性，确定模型为何生成这些输出，以及模型可能在哪些情况下失效。

数据验证有助于团队确定用于构建、调整、测试和运行模型的数据是否可信。数据验证包括：

• 评估数据质量。数据质量检查旨在确保数据记录准确、完整、相关、具有代表性、标签正确、合法获取、受到保护且相互隔离。

• 建立来源和沿袭关系。验证审查应能够将每个数据集和特征追溯至可识别的来源。

• 确认与任务的相关性。确认相关性意味着检查模型中的每个数据元素是否反映了与模型用途具有实际关联的信息。

• 验证标签和真实情况。标签验证可确保标签生成的输出准确、适当，并以一致定义的方式表示目标结果。标签验证还可以确定参考标准，即用于判断何为真实情况的最佳可用依据。

结果分析有两个主要目的。首先，它确定模型的输出是否与其所预测的现实情况相符。其次，它评估使用这些输出是否确实能够帮助企业实现预期目标，同时不会造成不可接受的危害、成本或风险。结果分析可能要求团队：

• 将预测结果与实际结果进行比较。结果分析会等待、收集或确定模型的“真实情况”，并将其与模型的输出进行比较。

• 使用回测。回测会将模型应用于历史案例，仅使用当时可获得的信息，然后将模型的预测结果与实际发生的情况进行比较。

• 检查召回率和预测错误。有问题的模型可能产生假阳性和假阴性。结果分析会衡量这两类错误，评估其后果，并确定其是否超过组织的风险阈值。

• 检查校准情况。校准用于评估模型给出的概率是否与实际观察到的频率相符。如果模型为 1,000 笔交易中的每一笔都给出 70% 的欺诈概率，那么最终应有约 700 笔交易被确认存在欺诈行为。如果最终只有 250 笔或有 850 笔被确认存在欺诈行为，则说明模型对风险的估计不准确。

• 评估业务和运营影响。结果分析会检查模型是否有助于实现其部署所要达成的实际目标。

验证模型的稳健性和敏感性有助于确保模型在条件不理想、异常或遭到蓄意攻击时，仍能继续保持可靠的行为。

敏感性本身并不是坏事。某些输入本就应该对模型的输出产生显著影响。例如，特权账户最近发生的变更合理地改变了该账户的网络安全风险评分。问题在于不合理的敏感性，即微小、无关或常规的变化对模型行为产生过大的影响。

团队可以通过以下方式挑战模型：

• 有噪声且不完整的输入。稳健性检查会模拟数据缺失和输入错误等情况，以了解杂乱数据如何影响模型的性能和响应。这有助于防止欠拟合（模型未能从训练数据中充分学习，因此无法识别模式）和过拟合（模型过度记忆训练数据，包括其中的噪声）。

• 条件变化。机器学习模型需要能够应对分布偏移（新政策、服务中断、概念漂移），即生产环境中的数据不再与开发数据相似。审查人员可能会使用较晚时间段的数据、新环境以及有意构造的分布外案例，以评估模型性能是否下降到不可接受的水平。

• 边缘案例和不确定性。边缘案例通常会暴露模型中隐藏的假设。检查模型如何响应此类场景，可以帮助团队了解模型是否能够识别不确定性并采取适当的备用措施。

• 对抗性输入。对抗性输入验证用于评估是否有人能够通过蓄意操纵模型，使其生成错误、不安全、未经授权或误导性的输出。

• 模型漂移。团队可以使用漂移模拟，有意构造生产数据、用户行为或输入与结果之间关系发生变化的场景，然后观察模型是否能够平稳应对性能下降，以及控制措施是否能够正确响应。

基准测试和挑战测试通过将模型与可信的替代方案进行比较，评估模型是否真正创造了价值。组织可以通过这些实践了解模型的表现是否显著优于更简单的方法、之前的模型、人工流程或独立开发的挑战模型（专门构建或选定用于验证候选模型行为的模型）。

• 基准（例如之前投入生产的模型或挑战模型）是用于评估 ML 模型的参考标准。主要模型不必在每项性能指标上都优于所有替代方案。团队只需了解其中的权衡取舍，以便为所选择的模型提供合理依据。

• 挑战测试是指通过尝试证明模型不适合其预期用途来评估模型适用性的更广泛实践。除了测试模型预期能够良好运行的情况外，挑战测试还会检查最有可能出现的故障场景。

安全性、安全防护和隐私检查用于评估模型可能带来的各种风险，但许多薄弱环节存在于 ML 模型周围的集成中，而不是模型本身。

例如，模型可能具有严格的内部策略，禁止泄露机密信息，但如果应用程序的检索系统未能执行文档权限控制，仍可能暴露私人文档。同样，模型可能能够抵御基本的越狱攻击，但围绕该模型构建的智能体仍可能执行不安全的操作，因为检索到的网页中包含了间接的提示注入。

因此，有效的验证要求团队评估模型及其周围的整个生态系统。

文档记录和可复现性使验证成为一套可审计的证据，而不是对模型“有效”的非正式声明。

文档记录贯穿 ML 模型的整个生命周期，从最初的业务案例，到开发、验证、部署、监控、重大变更以及最终停用。文档记录包括记录模型的沿袭关系并维护清晰的版本控制，使审查人员能够了解模型随时间推移发生的变化。

可复现性有助于确保合格的独立审查人员能够使用记录在案的材料，重复模型开发或验证流程，并获得大致相同的结果。

模型验证、模型测试和模型监控是相关的质量保证实践，但它们针对机器学习模型生命周期中的不同阶段，回答不同的问题：

• 验证关注的是：“该模型是否适合其预期用途、是否可靠，以及设计是否适当？”

• 测试关注的是：“最终确定的模型是否符合预先定义的技术、业务、安全性和运营验收标准？”

• 监控关注的是：“已部署的模型在真实世界的数据和实际环境中是否能够继续保持良好的表现？”

模型测试贯穿整个开发过程，但正式的测试集评估通常在团队确定主要设计选择和调优决策之后进行。测试通常由未参与模型开发决策的人员执行。对于 train_test_split 技术而言，测试还使用一个独立的测试数据集，该数据集未用于训练、超参数调优、阈值选择或模型选择，从而可信且无偏倚地估计最终确定的模型在真正未见过的数据上的表现。

企业可以选择一系列模型评估方法。

例如，留出集会将一部分数据与训练和模型开发过程分开，然后使用留出的数据评估最终模型在未见过的案例上的表现。团队可以使用 k 折交叉验证，让模型在不同的数据子集上进行训练和测试，共进行 k 次，然后对结果取平均值。或者，为了采用更严格的 k 折交叉验证形式，团队可以进行留一法交叉验证 (LOOCV)，让模型依次在每一个数据点上进行测试。无论采用哪种方法，模型测试的目的都是在 ML 模型部署之前，预测其在真实世界中的质量。

测试侧重于评估质量，而模型监控则侧重于确保经过训练的模型及其周围的生态系统在部署后按照预期运行。监控可以持续进行，也可以按照预定计划实施，通过观察运行中的模型的输入、输出及其运行行为，使风险管理团队能够在变化演变成全面回归问题，甚至更严重的故障之前检测到这些变化。

监控为企业提供了一个针对模型问题行为的预警系统，但不能替代验证。模型验证是一种迭代式评估流程，通常在开发团队构建模型的过程中进行，但团队也可以在模型获批前将验证作为独立流程执行，并在此后定期进行验证。

尽管验证、测试和监控是相互独立的流程，但企业通常需要这三者来优化 ML 模型在整个生命周期内的性能和可靠性。

生成式 AI (gen AI) 和 AI 智能体与其他 ML 系统一样，需要采用核心的验证实践。然而，这些工具可能产生预测模型验证无法完全应对的风险。生成式 AI 系统会生成开放式输出，而智能体可以利用这些输出在相互连接的系统中进行规划和执行操作。

对于标准 ML，通常可以将模型的结果直接与真实标签进行比较。例如，如果欺诈检测模型将一笔交易预测为“欺诈”，而后续调查确认该交易确实存在欺诈行为，则该预测是正确的。如果需求预测模型预测需求量为 1,150 个单位，而实际需求量为 1,600 个单位，团队可以使用均方误差这一回归指标来评估模型预测值与实际值之间的接近程度，从而精确衡量二者之间的差异。

生成式 AI 的输出通常不存在唯一的正确措辞，也可能不存在唯一且完整的“正确答案”。对于某些受约束的任务（如结构化提取、工具选择），仍然可以根据明确的预期输出进行评估。但总的来说，模型的行为在很大程度上取决于运行时上下文，而运行时上下文可能会因交互而发生变化。生成式 AI 还可能产生幻觉，针对提示自信地呈现虚假或错误的信息。

因此，生成式 AI 验证要求团队使用一个评估集，其中包含符合实际情况的提示、经过批准的源材料、预期答案要素和评分标准。评分标准允许模型生成多个可接受的响应，同时要求每个响应都包含特定事实、避免无依据的陈述，并在存在不确定性时披露不确定性。

AI 智能体可以制定计划、授予访问权限、修改记录、发送消息以及启动全新的工作流程（包括新的智能体）。因此，AI 智能体需要进行与生成式 AI 相同的、以输出为重点的检查，但开发人员还需要验证基于这些输出所做出的决策和采取的操作。任何实质性变更——例如更改智能体的基础模型或建立新的检索存储库连接——都应触发重新验证。