如何测试对话式人工智能：面向质量保证工程师的实用指南

这就引出了一个重要的测试问题：当用户用不同的方式表达同一个意图时，系统能否理解它呢？

一个简单的测试案例可能如下所示：

让我们来看一个具体的例子：

test_cases = [ 
          { "message": "我忘记了密码", 
            "expected(intent": "重置密码", 
          }, 
          { "message": "我该如何更改密码？", 
            "expected(intent": "重置密码", 
          }, 
          { "message": "无法登录我的账户",  
            "expected(intent": "重置密码", 
          }, 
]

for test in test_cases: 
    response = ai_agent.send(test["message"])
    assert response(intent == test["expectedintent"]

在运行这个测试之前，你需要知道预期的意图。这个预期意图通常来源于应用程序中定义的意图类别，或者经过验证的测试数据集。自动化系统并不会去判断哪个选项才是正确的意图，它只是检查人工智能系统是否根据团队预先定义的标准对用户的输入进行了分类：

输入：「无法登录我的账户」

预期意图：重置密码　实际识别意图：重置密码

测试通过

不要只关注那些表述清晰的句子。

真实的用户经常会犯拼写错误，使用缩写词，提供不完整的信息，有时甚至只会输入几个单词。

因此，我还会进行以下测试：

“忘记了密码”

“无法登录”

“需要密码帮助”

“被锁定了”

正是在这些情况下，对话式人工智能的测试才真正变得有趣起来。我们并不是在测试系统是否能够识别某一句预先定义好的句子，而是在测试它是否能够理解用户目标的多种表达方式。

2. 不要对所有响应都使用精确的文本匹配

我最初需要重新考虑的一个习惯就是：逐字比较实际输出与预期输出的文本内容。

假设预期的回答应该是：“您可以通过‘忘记密码’链接来重置密码。”

但人工智能给出的回复却是：“在登录页面选择‘忘记密码’即可开始重置密码。”

从字面上看，这两个回答并不完全相同；但从用户的角度来看，后一个回答也可能是完全正确的。

因此，不应该将预期的结果定义为一句话，而应该明确一个好的回复必须包含哪些要素。

例如，一个合格的回复应该：

• 说明如何开始密码重置流程

• 提供下一步该采取的行动

• 不要要求用户透露自己的密码

• 不要编造与账户相关的信息

• 内容必须与密码恢复相关

现在，即使回答并不完全相同，只要符合这些要求，也可以被视为合格的答案。这一点对我来说是一个很大的改变。

对于确定性应用而言，预期的输出通常是一个具体的值；而对于对话式人工智能来说，预期的结果可能是一组评估标准。

3. 从多个维度评估回复质量

正确性固然重要，但它不应该成为唯一的评估标准。我认为将回复质量分解为几个不同的维度会更有帮助。

1. 准确性：信息是否正确？如果人工智能声称用户可以通过电子邮件重置密码，而实际操作过程中需要联系客服，那么这个回答就是错误的，即使它听起来很合理。

2. 相关性：人工智能是否回答了用户真正想要了解的问题？一个回答可能包含了准确的信息，但却与用户的实际需求无关。

3. 完整性：回复中是否包含了用户继续操作所需的所有信息？

4. 清晰度：用户能否轻松理解这个回答？

5. 实用性：这个回答是否能真正帮助用户实现他们的目标？

一个简单的评分标准可以如下所示：

然后，您可以根据自己的应用需求来确定合适的评分阈值。

评分系统本身并不是最重要的；关键在于明确这些评估标准，而不是仅仅依靠个人的主观判断来评价回答的好坏。

4. 不仅要测试回复内容，还要测试整个对话过程

单轮对话测试确实很有用，但用户在现实中与人工智能交互时，很少会使用完全独立、结构固定的问题来进行交流。

请看以下这个对话示例：

用户：我需要更新我的地址信息。

人工智能会解释整个流程。

然后：

用户：我可以在网上操作吗？

“那个”指的是什么？第二条信息完全取决于第一条信息的内容。

现在想象一下：

用户：我需要更新我的地址。

人工智能：当然可以，我可以帮您办理。

用户：其实，在那之前，你能告诉我下一次付款日期是什么时候吗？

人工智能：您的下一次付款日期是9月15日。

系统能回到最初讨论的主题吗？

这是一种不同类型的测试。

你的多轮对话测试套件应该包括以下场景：

• 后续提问

• 引用之前的对话内容

• 话题转换

• 回到之前的讨论主题

• 用户对回答的修改

• 信息不完整的情况

• 表述模糊的问题

• 重复提出的问题

这对我的测试方式产生了影响——有时候你在测试人工智能的响应能力，而有时候则在测试整个对话过程。

这里有一个例子：

ai_agent.send("我的订单号是A10245")
response = ai_agent.send("货物什么时候能到？")

assert response.order_id == "A10245"

第二条信息中并没有包含订单号。这个测试是为了验证人工智能是否保留了之前对话中的信息，而不会将“货物什么时候能到？”视为一个无关的问题。

5. 测试人工智能能否处理用户的修改请求

人们经常会改变主意或犯错。

例如：

用户：我的账号号码是以4567结尾的。

然后：

用户：抱歉，我是说4576。

接下来会发生什么？

理想情况下，系统应该使用用户提供的正确信息，而不是继续使用原来的错误数据。

其他对话细节也同样适用这一原则。

比如：“我打算去波士顿。”

“我需要6月份的报告。”

这类测试非常有用，因为它们能让我们判断人工智能是否真正能够维持对话的连贯性，还是只是机械地记录信息而并不理解哪些信息是当前有效的。

6. 测试信息的模糊性

用户并不总是会提供足够的信息。

想象一下，如果有人输入：“我想修改一些内容。”

一个质量较差的对话系统可能会随意猜测用户的意图；而一个更好的系统则会询问：“您具体想修改什么？”

这就引出了另一个重要的测试方向：信息澄清行为。

可以故意设计一些表述模糊的句子来进行测试，例如：

• “我该如何更新它？”

• “它无法正常使用。”

• “你们能修改这个问题吗？”

• “我的账户需要帮助。”

然后，需要判断人工智能是否能够识别出这些信息缺失的情况，避免做出不合理的假设，并提出恰当的澄清问题。

有时候，人工智能最好的回应并非答案，而是一个新的问题。

7. 测试答案背后的知识储备

起初，我几乎完全关注人工智能给出的回答本身。后来我才意识到，一个错误的回答并不一定意味着语言模型本身存在问题。

该系统可能会使用知识库、检索系统、文档资料、API或其他企业级数据源来生成答案。

如果这些信息是错误的、不完整的、相互矛盾的或已经过时的，那么即使语言模型的运行方式符合设计要求，人工智能也可能给出错误的回答。

假设官方政策规定顾客有30天的时间退货，但某篇过时的文档却声称顾客有60天的时间退货。

如果人工智能检索到了这篇过时的文档，并自信地回答“60天”，那么这个回答就是错误的。

但是，调查不应该仅仅以“人工智能产生了幻觉”作为结论。测试人员需要查明这些错误信息是从哪里来的。

我会重点调查以下内容：

• 该回答使用了哪些信息来源？

• 这些信息来源是否经过审核确认？

• 这些信息是否是最新的？

• 是否存在多个相互矛盾的信息来源？

• 检索系统是否找到了正确的文档？

• 最终的回答是否准确反映了检索到的信息？

对于那些采用“基于检索的生成技术”来生成答案的系统来说，这一点尤为重要。

8. 检测人工智能是否会产生错误信息

其中一个非常重要的对话式人工智能测试方法其实非常简单：询问一些系统本身并不知道的信息。

假设某个内部支持系统包含了产品A、B和C的相关文档。那么，如果有人问“产品Z的退订政策是什么？”这个系统应该会给出什么回答呢？

显然，产品Z根本不存在。

那么，最糟糕的情况就是系统会自信地编造出一个退订政策来回应这个问题。

根据不同的应用场景，更好的应对方式可能是：

“关于产品Z，我并没有相关信息。”

或者：

“我找不到相关的信息。需要帮您联系客服吗？”

一个有效的错误信息检测测试套件应该包括以下内容：

• 并不存在的产品信息

• 虚假的政策名称

• 系统不支持的功能

• 故意设置错误的假设

• 超出知识范围的问题

• 请求获取系统无法提供的信息

通过这些测试，可以判断人工智能是否能够识别出自己不应该回答的问题。

9. 测试回退行为

任何对话系统最终都会遇到它无法理解的用户请求。但这并不一定意味着系统失败了。

关键的问题是：接下来会发生什么？

想象这样一种场景：

用户：我需要帮助调整我的ZXP设置。

但系统并没有识别出“ZXP”这个词。

一个较差的回退处理方式可能是反复重复“抱歉，我不明白您的意思”。而一个更好的处理方式则是询问：“请您能再详细说明一下您所说的ZXP设置指的是什么吗？”

如果系统仍然无法理解用户的请求，那么它可能需要提供其他的解决途径。

回退行为测试应该涵盖以下内容：

• 用户意图未被识别的情况

• 拼写错误

• 请求信息不完整

• 系统无法处理的主题

• 相互矛盾的请求

• 多次出现误解的情况

同时，还需要测试在多次失败后系统会如何反应。人工智能助手不应该让用户陷入“抱歉，我还不明白您的意思”这样的无限循环中。

10. 测试人工干预机制

有时，人工智能助手应该能够意识到自己已经无法可靠地继续处理当前的对话。这种情况可能发生在用户明确要求与人类客服沟通、请求超出了助手的处理能力范围，或者当前情况需要人类的判断时。在这些情况下，继续尝试回答用户的请求反而可能会带来更糟糕的结果，因此将对话转交给人工客服才是更好的选择。

以下是一些需要考虑的情况：

• 多次出现误解

• 与账户相关的问题

• 用户要求与人类客服沟通

• 涉及敏感信息的工作流程

• 自动化流程无法处理的特殊情况

如果产品设计中包含了人工干预机制，那么就需要对整个切换过程进行测试。

例如：

用户：我想和别人谈谈。

人工智能助手能否识别出这个请求？它能否正确地将对话转交给人类客服？人类客服能否获取到相关的对话记录？用户是否需要重新解释一遍自己的需求？在应该进行人工干预的情况下，人工智能助手还会继续尝试回答用户的请求吗？

即使技术上转移对话的过程是成功的，但如果所有的上下文信息都丢失了，那么用户体验仍然可能会很差。

11. 像测试其他应用程序一样测试集成功能

对话式界面可以让复杂的系统看起来更加简单易用。

用户看到的只是：

“我的订单状态如何？”

但实际上，在处理这个请求的过程中，系统可能需要执行以下操作：

1. 识别用户的意图

2. 验证用户的身份

3. 调用订单处理接口

4. 检索用户的订单信息

5. 解析返回的结果

6. 生成自然语言形式的回复

在这种情况下，传统的测试技巧就显得尤为重要了。

如果接口返回的数据不符合预期，那么系统就无法正确地完成对话处理流程。

{
  "order_id": "A10245",
  "status": "SHIPPED"
}

人工智能不应该对用户说：“您的订单仍在处理中。”

为了测试这些集成功能，请确保进行以下测试：

• API映射是否正确

• 认证失败的情况

• 超时问题

• 空响应情况

• 响应格式错误的问题

• 服务不可用的情况

• 状态码是否正确

• 数据是否不完整

人工智能并不会取代传统的集成测试，而是为其增加了一层额外的测试机制。

12. 构建黄金数据集

在了解人工智能的行为模式时，手动探索性测试确实非常有用，但最终我们还是需要重复性结果。这时，黄金数据集就派上了用场。

黄金数据集是一组经过精心挑选的、具有代表性的测试用例及预期结果，这些数据可以在系统发生变化时重新使用来进行测试。

例如：

对于每一个重要的测试用例，还需要进一步扩展测试内容，包括换种表达方式、边缘情况、负面案例以及多轮对话场景。

每当提示语、知识库、模型、集成功能或对话逻辑发生变化时，都需要重新运行整个数据集进行测试。

这样，你就得到了一个与传统的回归测试非常相似的测试方法。

13. 不要只关注通过率

假设你进行了1000次对话测试，其中950次通过了。95%的通过率听起来确实不错。

但究竟是什么导致了失败呢？是500个普通的常见问题解答吗？还是5个涉及账户安全的严重问题呢？

仅仅看整体通过率并不能反映全部情况。根据具体的应用场景，一些有用的评估指标可能包括：

• 意图识别准确率：系统有多少次正确理解了用户的真实意图？

• 回退处理成功率：系统有多少次未能理解用户的请求？

• 任务完成率：用户有多少次成功完成了预期的操作？

• 升级处理成功率：在需要人工协助的情况下，系统能否顺利引导用户进入下一步流程？

• 信息冲突情况：系统的回答与既定知识有多少次出现矛盾？

• 上下文丢失问题：在多轮对话中，系统有多少次遗漏了重要信息？

• 错误信息提供情况：系统有多少次提供了没有依据的信息？

合适的评估指标需要根据产品本身及其所涉及的风险来确定。用于提供客户服务帮助的FAQ机器人与辅助人们做出财务决策的AI系统，显然不应采用相同的质量评估标准。

14. 制定基于风险的对话测试方案

这是另一条同样适用于人工智能测试的传统质量保障原则。

并非所有AI系统的故障都会产生相同的影响。如果AI系统对“你们的营业时间是什么？”这样的问题给出了尴尬的回答，那当然会让人感到不便；但如果是关于支付流程、账户安全、医疗建议或金融政策等方面的错误信息，其造成的后果可能会严重得多。

因此，我们应该根据风险程度对各种测试场景进行分类。

例如：

我们应该将回归测试的重点放在那些错误操作可能会造成最大危害的场景上。

15. 实用的对话式AI测试策略

如果我现在要开始开展对话式AI的质量保障工作，我会按照以下层次来组织测试流程：

第1层：意图理解测试

系统能否理解用户的需求，即使用户的表达方式存在差异？

第2层：响应质量评估

系统的回答是否准确、相关、完整、清晰且有用？

第3层：对话流程测试

系统能否在多次交互中保持对上下文的理解？

第4层：知识储备与基础能力测试

系统的回答是否基于经过验证的、最新的信息？

第5层：错误处理与异常情况检测

系统在信息不足时，是否会避免给出错误的回答？

第6层：回退机制与问题升级处理

系统在无法理解用户意图时，能否恢复正常运行？必要时能否将任务转交给人类进行处理？

第7层：系统集成测试

API接口、认证机制、数据库以及下游系统是否都能正常运作？

第8层：回归测试

当模型、提示语、知识库或应用程序发生变更后，相关功能是否还能保持稳定？

与仅仅让聊天机器人随机回答问题相比，这样的测试框架能为质量保障团队提供更加有条理的起点。

传统质量保障工程师为AI测试带来了什么

当我刚开始学习对话式人工智能时，我认为自己需要忘掉所有关于传统测试的知识。但现在我不再这么认为了。

我们现有的很多技能其实都可以很好地应用到对话式人工智能的测试中。我们已经知道如何：

• 质疑各种假设

• 探索边缘情况

• 设计负面测试用例

• 追踪跨多个系统的故障问题

• 验证系统之间的集成效果

• 根据风险优先级来安排测试工作

• 构建回归测试套件

• 调查系统中出现的异常行为

真正发生变化的，是对于“预期结果”的定义。

在某些人工智能应用场景中，预期的结果并不是：

输出结果必须完全符合某一个具体标准

而更接近于：

系统给出的响应必须同时满足X、Y、Z这些要求，同时避免出现A和B这两种情况

一旦我明白了这个区别，对话式人工智能的测试方法就变得容易理解多了。

总结

刚开始学习对话式人工智能时，我的第一反应就是去寻找相关的测试用例。

但现在我认为，这样的做法是错误的。应该从用户的角度出发来开始思考：

• 用户想要实现什么目标？

• 他们可能会用哪些不同的方式来表达自己的需求？

• 人工智能系统需要哪些信息才能完成用户的请求？

• 一个有用的回答应该包含哪些内容？

• 系统绝对不能说哪些话？

• 如果人工智能系统不知道某些信息，会怎么样？

• 当对话的方向发生变化时，系统应该如何应对？

• 有哪些证据能让你有足够的信心将这个系统交付给真实用户使用？

这些问题最终就会成为你的测试用例。

与许多质量保证工程师习惯测试的应用程序相比，对话式人工智能的测试结果可能不具有确定性。但这并不意味着它无法被测试。事实上，我们只需要跳出“得到的输出是否完全符合预期”这样的思维模式，转而问：“系统在真实用户可能使用的各种交互方式下，是否表现得正确、安全且有用？”

对我来说，这才是最重要的转变。测试工具在变，界面也在变，甚至对“预期结果”的定义也在变化。但质量保证工作的根本职责却几乎没有改变：那就是在用户发现问题之前，先弄清楚系统可能会出什么故障。