AI智能体开发测试实战：从四大挑战到最佳实践
在开发环境中有效测试AI智能体是确保其可靠性的关键环节，但这一过程充满挑战。即使是提示词版本、智能体编排或模型选择上的微小调整，也可能带来巨大且难以预料的影响。本文将分享一套经过实践检验的测试策略与四大核心经验。
图片由作者提供。
为何测试智能体如此困难
验证AI智能体是否按预期工作并非易事，主要面临三大核心挑战：
输出的非确定性
智能体的本质是非确定性的。相同的输入可能产生截然不同的输出。当无法预知确切的预期结果时，如何进行测试？显然，为严格定义的输出编写测试用例是行不通的。
输出的非结构化
智能体系统的第二个（也是较少被讨论的）挑战在于，其输出通常是非结构化的。毕竟，这类系统的基石是大语言模型。为结构化数据定义测试要容易得多，例如，某个ID字段不应为空或必须为整数。但如何定义一大段文本的质量呢？
成本与规模
LLM即评委是评估AI智能体质量或可靠性的最常见方法。然而，这是一项昂贵的工作负载，每次用户交互（轨迹）可能包含数百次内部交互（跨度）。
因此，重新思考智能体测试策略变得至关重要。下文将分享关键的实践经验，包括一个被证明对确保大规模可靠性至关重要的新概念。
图片由作者提供
智能体测试实践：三维度评估
目前有两个服务于超过30,000名用户的智能体在生产环境中运行。“故障排查智能体”负责梳理数百个信号以确定数据可靠性事件的根本原因，而“监控智能体”则提供智能的数据质量监控建议。
对于故障排查智能体，测试主要围绕三个维度展开：语义距离、事实依据性和工具使用。以下是具体的测试方法。
语义距离
在适当的情况下，会采用确定性测试，因为它们清晰、可解释且成本效益高。例如，部署测试以确保某个子智能体的输出是JSON格式、不超过特定长度，或者确保防护机制被正确调用，都相对容易。
然而，有时确定性测试无法胜任。例如，曾尝试将预期输出和实际输出都嵌入为向量，并使用余弦相似度测试。这被认为是一种评估观察到的输出与预期输出之间语义距离（含义是否相似）的更廉价、更快速的方法。
但实践发现，存在太多用词相似但含义不同的情况。
因此，目前的方案是向作为评委的LLM提供当前配置下的预期输出，并要求其以0-1的评分标准，评估新输出与预期输出的相似度。
事实依据性
对于事实依据性，测试旨在确保关键上下文在需要时出现，同时，当关键上下文缺失或问题超出范围时，智能体能够拒绝回答。
这一点很重要，因为LLM倾向于取悦用户，在没有良好上下文基础时会“幻觉”出答案。
h3 id=”toolusage”>工具使用
对于工具使用，由LLM作为评委来评估智能体在预定义场景下是否按预期执行，具体包括：
- 未预期使用工具，且确实未调用任何工具
- 预期使用工具，且使用了允许的工具
- 没有遗漏任何必需的工具
- 没有使用任何未经许可的工具
真正的难点不在于部署这些测试，而在于如何应用它们。以下是根据一些痛苦试错经验总结出的当前设置。
智能体测试最佳实践
必须牢记，不仅智能体是非确定性的，LLM评估本身也是非确定性的！这些最佳实践主要是为了应对这些固有的缺陷而设计的。
软性失败
由于非确定性测试的固有特性，硬性阈值可能会带来大量噪音。因此，引入了“软性失败”这一概念。
评估返回一个0-1之间的分数。低于0.5被视为硬性失败，高于0.8则视为通过。分数在0.5到0.8之间则属于软性失败。
对于软性失败，变更仍然可以合并。但是，如果软性失败的数量超过某个阈值，则构成硬性失败，流程将被中止。
在当前配置中，如果33%的测试结果为软性失败，或者软性失败总数超过2个，则视为硬性失败，阻止变更合并。
重新评估软性失败
软性失败可能是潜在问题的预警信号，但在某些情况下也可能是误报。大约10%的软性失败是LLM幻觉的结果。当出现软性失败时，评估会自动重新运行。如果重新运行后测试通过，则假定原始结果是不正确的。
提供解释
当测试失败时，需要理解失败的原因。现在要求每个作为评委的LLM不仅要提供分数，还要解释评分理由。虽然不完美，但这有助于建立对评估的信任，并常常能加速调试过程。
移除不稳定的测试
必须对测试本身进行测试。特别是对于LLM即评委的评估，提示词的构建方式会对结果产生很大影响。会多次运行测试，如果结果之间的差异过大，则会修改提示词或移除不稳定的测试。
生产环境监控
智能体测试是新颖且具有挑战性的，但与监控生产环境中的智能体行为和输出相比，这只是“小巫见大巫”。生产环境的输入更加杂乱，没有预期的输出来作为基线，而且一切都在更大的规模上进行。
更不用说风险要高得多！系统可靠性问题很快就会演变成业务问题。
这是当前的重点工作。正在利用智能体可观测性工具来应对这些挑战，并将在未来的文章中分享新的经验。
故障排查智能体已成为有史以来发布的最具影响力的功能之一。开发可靠的智能体是一段定义职业生涯的旅程，很高兴能与大家分享。
