AI系统测试架构

1. 项目背景与挑战 #

在构建承载对话理解、意图识别、任务规划等能力的智能交互系统（AI Agent）时，传统的测试方案在“软硬结合”场景下面临巨大挑战。

痛点分析 #

当测试对象涉及物理设备（如机器人、IoT设备）时，典型的端到端测试流程往往包含：

1. 链路长：LLM处理(秒级) + 网络通信(秒级) + 设备物理执行(分钟级)。
2. 依赖重：强依赖IoT平台及真实设备环境。
3. 稳定性差：受限于设备离线、弱网环境，自动化测试失败率高。
4. 成本高：真机无法支持大规模并发，导致全量回归测试周期以“天”为单位计算。

例如，一个典型的任务执行场景，若包含物理移动和状态切换，单条用例耗时可达3-5分钟。面对数万条级别的全量用例，回归测试几乎成为不可能完成的任务。

2. 核心演进思路 #

为解决上述痛点，我们将测试体系的演进分为两个阶段：

1. 仿真阶段：构建Mock系统，解耦硬件依赖，实现高并发自动化。
2. 评测阶段：针对LLM特性，建立“数据生成-自动评测”闭环。

优化效果对比 #

3. Mock仿真平台设计 #

Mock系统并非简单的接口模拟，而是一个完整的设备行为仿真平台，其核心职责是拦截下发给物理设备的指令，并根据预设逻辑返回模拟状态。

3.1 核心能力 #

1. 状态与行为模拟：
   • 通过预设数据（如Protocol Buffers/JSON）模拟设备状态（如“空闲”、“工作中”）。
   • 智能判断请求类型：查询类请求返回预设状态，控制类请求返回成功响应。
2. 零侵入接入：
   • 利用Header透传机制（如 X-Mock-URL），在网关层或服务层将流量路由至Mock服务，业务代码无感知。
3. 高并发支持：
   • 通过虚拟化设备ID（Device ID），在单次测试中生成成百上千个虚拟设备，突破物理设备数量限制。

3.2 全链路追踪 (Trace ID) #

引入全局唯一的 Trace ID 贯穿测试全生命周期：

• 生成：测试发起时生成Trace ID。
• 透传：Trace ID 随 HTTP/MQTT 请求流转。
• 回溯：测试结束后，通过 Trace ID 拉取所有 Request/Response 日志，用于生成报告和问题定位。

4. LLM 评测体系构建 #

随着Mock系统解决了“执行慢”的问题，测试重心转移到了LLM输出质量的验证上。面对LLM输出的非确定性、语义多样性，传统的字符串匹配断言已失效。

4.1 痛点：评测数据构建 #

• 规模不足：手工编写用例效率低，难以跟上版本迭代。
• 分布失真：人工编写多为“书面语”，缺乏真实用户的口语化、情绪化表达。
• 无标准答案：开放式闲聊场景缺乏 Ground Truth。

4.2 解决方案：LLM生成测试用例 #

利用更强大的模型（如DeepSeek V3、GPT-4等）自动生成多样化测试用例：

• 多样性保障：构建“话题池 x 用户画像 x 表达风格”的组合矩阵（例如：60个场景 x 8种角色 x 8种风格）。
• 规模化生成：低成本快速生成数千条覆盖长尾场景（方言、模糊意图）的真实感语料。
• RAG增强：针对知识库问答，自动调用检索接口获取参考信息。

4.3 解决方案：LLM-as-a-Judge #

引入“大模型裁判”机制，替代人工进行多维度评分。

5. 系统架构设计 #

平台采用典型的分层架构，确保职责单一与高扩展性：

• 接入层 (API)：处理路由、鉴权与文档生成。
• 控制层 (Controller)：参数校验、业务编排。
• 服务层 (Service)：核心业务逻辑，包括MQTT消息解析、Mock数据匹配、并发控制。
• 仓储层 (Repository)：数据持久化与查询。

数据流转核心：

1. 预置阶段：测试执行器将模拟状态写入数据库（关联Trace ID）。
2. 执行阶段：LLM服务请求被Mock系统拦截，系统根据Trace ID和Topic查找并返回预置数据。

6. 未来展望 #

随着知识库规模的扩大，评测体系将向更深层次演进：

1. RAG深度评测：引入 RAGAS 等框架，量化评估检索相关性（Context Relevance）和答案忠实度（Faithfulness）。
2. 复杂推理评测：自动生成跨文档推理问题，评估系统的综合理解能力。
3. 反馈闭环：对“不合格”用例进行自动归因分析（如：检索失败 vs 生成错误），直接为研发提供修复线索。