为什么重要
通过“理想路径”测试几乎说明不了什么
大多数 AI 系统的测试方式和演示方式如出一辙：用预期语言问一遍几个干净、规规矩矩的问题，且不带任何对抗意图。生产环境却完全不是这样。真实用户会提出自相矛盾的问题、粘贴恶意指令、把系统推出预定范围、在对话中途切换语言，而一个从未在这种压力下被测试过的系统，其故障面是未知的，绝非安全的。红队实验室的使命，就是在受控条件下主动找出这个故障面，抢在它在生产环境中被发现之前。
我们测试的内容
针对系统类型匹配的故障模式
生成式系统与经典系统的失效方式不同，因此攻击面的界定也会相应匹配。
生成式 AI 系统
基于 LLM 的聊天机器人、RAG 系统与自主智能体。
- 幻觉
- 信息泄露
- 指令绕过
- 提示词注入
- 未经授权的工具调用
- 不可逆操作
- 依赖错误信息源
- 偏见
- 不一致性
- 跨语言失效
- 面对矛盾信息时的行为
经典机器学习系统
预测、评分与分类模型。
- 漂移
- 数据泄露
- 鲁棒性
- 数据不平衡
- 校准
- 敏感性
- 在不同人群或场景下的失效
运作方式
从范围界定到修复优先级报告
- 界定目标范围：哪些系统、哪些环境、哪些操作在边界之内或之外
- 针对系统实际的故障面设计攻击场景，而非套用通用检查清单
- 结合人工与工具，对生产系统开展对抗性测试
- 记录每一次尝试、每一次响应，以及每一个边界被守住或被突破的节点
- 按严重程度与业务影响、而非发现数量对结果排序
- 交付一份工程团队可直接据以行动的修复优先级报告
有何不同
交付成果不是一个漏洞数量
按攻击清单对系统逐项测试并不难。真正困难的部分（也是真正的价值所在）在于把“我们发现了 73 个问题”转化为管理层能够据以行动的信息：严重程度排序、每项发现的业务影响，以及修复它究竟需要什么。
发现问题的处理方式与 QAi 的其他环节一致：每个问题都会被转化为具体的风险金额与修复要求，而不是停留在一份未经处理的失败测试用例清单上。
适用对象
- 首次向真实客户上线聊天机器人、RAG 系统或智能体的团队
- 更换了模型、提示词或工具权限、需要了解哪里出了问题的团队
- 单次错误输出就会造成重大后果的受监管或高信任环境
- 此前只测试过“理想路径”的团队
想知道您的系统究竟会在哪里出问题吗？
可单独开展，也可纳入 QAi 健康检查一并进行。