概述
示例包括不受支持的声明、遗漏案例、数据泄露、不安全的工具操作以及输入更改时的故障。对故障模式进行分类有助于团队测试和解决原因，而不是将每个错误都视为同一问题。
主要要点
- 准确描述触发因素和后果。
- 单独的模型、数据和工作流程故障。
- 将缓解措施与观察到的原因相匹配。
深入探讨
从预期的行为及其界限开始。错误的类别、虚构的引文和重复的付款请求需要不同的响应。记录每次故障的触发因素、观察到的结果、受影响的组件和实际后果。区分模型错误和系统错误。当工具使用错误的帐户执行、过时的文档提供过时的策略或重试重复已完成的操作时，模型可能会正确解释请求。当输出可以改变外部状态时，端到端验证至关重要。分别测试普通变异性和故意滥用。格式更改、方言、丢失数据、长文档和冲突的指令可能会在没有对手的情况下暴露弱点。安全测试添加了攻击者尝试重定向行为或访问信息的情况。选择与原因匹配的控制措施：输入合同、证据检查、权限限制、交易标识符、弃权或人工审查。保留失败案例进行回归测试并记录残余不确定性。捕获一个示例的缓解措施不应被描述为消除一整类故障。
04工作示例
与成功声明分开执行
想象一下，一个助手说在其存储工具超时后保存了一个文件。
检查目标以确定文件是否存在及其内容是否与请求匹配。
如果结果未知，请报告该状态并在重试之前使用安全的协调步骤。将超时情况添加到回归套件中。
它显示了什么
这个假设的例子测试的是可观察的完成情况，而不是助手的描述。
现实世界的实施
测试重试不会重复已完成的操作。
检查摘要器是否保留否定和不确定性。
付诸实践
为什么这很重要
- 更清晰的判决. 它可以帮助您将清晰的技术声明与营销语言分开。
- 成本与预算. 在花费金钱或时间之前，您可以提出更好的实施问题。
- 团队与工作流程. 具有共同理解的团队可以做出更好的产品、政策和学习决策。
留意
- 不同的团队可能会以不同的方式使用同一术语，因此请尽早定义范围。
- 基准测试可能看起来很强大，但实际性能却参差不齐。
- 忽视数据质量和评估计划通常会产生脆弱的结果。
后续步骤
- 从您需要的结果的简单语言定义开始。
- 在测试之前选择一种成功指标和一种失败条件。
- 使用代表性数据运行小型试点，而不是完善的演示集。
- 记录人工智能故障模式在哪些方面有帮助以及在哪些方面更简单的方法更好。
资料来源与延伸阅读
- NIST人工智能风险管理框架1.0
不断探索
常见问题
修复一个失败的例子就证明故障模式已经消除了吗？
不。测试有意义的变化和根本原因。一次成功的重播是有限的证据。