山海尽明意1. 从测试视角看LLM系统的三层架构
最近在参与几个AI项目的质量保障工作，发现很多测试同行在面对LLM系统时容易陷入"概念沼泽"——各种新名词层出不穷，但真正需要测试关注的核心点反而被淹没了。经过半年多的实践，我总结出一套从测试视角理解LLM系统的分层方法，帮助团队快速抓住测试重点。
1.1 人类意图层：输入的不确定性管理
这一层对应的是用户与LLM系统的交互界面，核心挑战在于自然语言固有的模糊性。我们团队在测试电商客服机器人时，发现同样的用户需求可能有上百种表达方式：
- "我想退昨天买的衣服"
- "退货流程怎么操作"
- "收到的商品不合适怎么办"
关键测试点：模型对语义等价但表述不同的输入是否能够稳定输出相同业务逻辑的响应。我们建立了包含2000+同义句的测试集，通过余弦相似度评估输出一致性。
常见的测试策略包括：
- 同义替换测试：使用同义词库生成输入变体
- 模糊输入测试：包含错别字、省略语法成分的输入
- 多语言混合测试：中英文混杂的输入场景
1.2 协议约束层：AI系统的"交通规则"
这是测试投入产出比最高的层级，相当于传统系统中的API契约测试。某金融项目曾因JSON Schema定义不完整，导致模型可能返回包含敏感字段的响应：
json复制// 有缺陷的Schema定义
{
"type": "object",
"properties": {
"account_balance": {"type": "number"}
}
}
// 测试发现的违规响应
{
"account_balance": 5000,
"user_id": "123456" // 未在Schema中明确定义
}
必须测试的约束类型包括：
- 字段存在性约束
- 类型校验规则
- 枚举值范围限制
- 嵌套结构深度控制
- 敏感数据过滤规则
我们使用OpenAPI Schema Validator进行自动化校验，集成到CI流水线中。
1.3 智能体执行层：业务规则的守护者
这一层测试最接近传统软件测试，但增加了LLM特有的挑战。在某订票系统测试中，我们发现当用户连续5次提供不完整的出发日期时，Agent没有按设计终止会话：
code复制[测试用例]
1. 用户：我要订机票
2. 系统：请提供出发日期
3. 用户：下个月
4. 系统：需要具体日期
... (重复5次)
[预期] 系统应终止会话并转人工
[实际] 继续追问日期
关键测试维度：
- 工具调用正确性（right tool）
- 调用参数完整性（right parameters）
- 会话终止条件（stop conditions）
- 失败回退机制（fallback）
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LLM测试的四个核心战场
2.1 Function Calling的契约测试
Function Calling是LLM系统中最需要严格测试的部分。我们设计了三层测试方案：
-
参数约束测试（Schema级别）
- 必填字段验证
- 类型校验（字符串/数字/布尔）
- 格式校验（日期/邮箱/URL）
-
业务规则测试（语义级别）
python复制# 测试航班查询功能 def test_flight_search(): # 正常场景 assert search_flights("PEK", "SHA", "2024-07-01") # 边界场景 with pytest.raises(ValidationError): search_flights("PEK", "SHA", "2023-01-01") # 过去日期 -
安全测试
- SQL注入测试
- 路径遍历测试
- 敏感数据泄露测试
2.2 Agent循环的收敛性测试
Agent的循环控制是稳定性风险高发区。我们开发了专门的测试框架模拟长时间对话：
python复制class AgentConvergenceTest:
def test_retry_mechanism(self):
agent = TravelAgent()
# 模拟连续10次无效输入
for _ in range(10):
agent.process("我不知道")
assert agent.state == "ESCALATE_TO_HUMAN"
关键测试指标：
- 最大重试次数控制
- 超时处理机制
- 资源消耗监控（API调用次数）
- 会话状态持久化
2.3 RAG效果的量化评估
检索增强生成(RAG)系统的测试需要特殊方法：
-
召回率测试
- 准备标准问题集
- 检查返回文档的相关性
- 计算命中率（Hit@k）
-
幻觉检测
python复制def test_hallucination(): response = ask_llm("2024年奥运会主办城市是?") assert "巴黎" in response # 正确答案 assert "东京" not in response # 幻觉内容 -
时效性验证
- 知识截止日期检查
- 动态信息更新测试
2.4 系统级的AB测试框架
在生产环境验证LLM效果必须采用科学的AB测试方法：
| 测试维度 | 对照组 | 实验组 | 评估指标 |
|---|---|---|---|
| 响应速度 | 旧模型 | 新模型 | P99延迟 |
| 准确率 | GPT-3.5 | GPT-4 | 人工评估得分 |
| 成本效益 | 全量调用 | 缓存策略 | API调用次数 |
我们使用Feature Flag控制流量分配，确保测试的可控性。
3. 测试工具链的实战选型
3.1 契约测试工具对比
经过多个项目验证，我们的工具选型标准是：
- Pact：适合微服务场景的契约测试
- Schemathesis：针对OpenAPI的模糊测试
- Great Expectations：数据质量验证
bash复制# 示例：用Schemathesis进行压力测试
schemathesis run --checks all http://api.example.com/schema.json
3.2 自动化测试框架
我们改造了传统的测试框架以适应LLM特性：
-
断言增强
python复制# 传统断言 assert response == "巴黎" # LLM增强断言 assert_semantically_equivalent(response, "法国首都") -
测试数据生成
- 使用Faker生成自然语言输入
- 基于Markov链生成连贯文本
-
结果评估
- BLEU分数
- ROUGE指标
- 人工评估接口
3.3 监控体系设计
生产环境监控的三个关键维度：
-
质量看板
- 意图识别准确率
- 工具调用成功率
- 会话完成率
-
性能看板
- 令牌消耗趋势
- API响应时间
- 并发处理能力
-
安全看板
- 敏感词触发次数
- 异常输入频率
- 审核拦截率
4. 典型问题排查手册
4.1 高频问题速查表
| 问题现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 工具调用参数缺失 | Schema定义不完整 | 1. 检查required字段 2. 验证示例数据 3. 监控实际调用日志 |
| Agent陷入死循环 | 终止条件未生效 | 1. 检查max_iterations 2. 验证状态机转换 3. 压力测试会话长度 |
| 响应包含幻觉内容 | 知识库未覆盖 | 1. 检查RAG召回结果 2. 验证温度参数 3. 添加拒答训练数据 |
4.2 性能优化实战案例
在某客服系统优化中，我们发现：
- 问题：简单查询也触发全文检索
- 分析：意图识别阈值设置过低
- 解决：
python复制# 优化后的意图判断逻辑 if query_simplicity_score > 0.9: use_cache() else: use_rag() - 效果：API调用量减少37%，响应速度提升52%
4.3 安全防护经验
三个必须实施的防护措施：
-
输入净化层
python复制def sanitize_input(text): # 移除特殊字符 cleaned = re.sub(r'[<>"\']', '', text) # 截断超长输入 return cleaned[:1000] -
输出过滤层
- 敏感词黑名单
- 内容安全API集成
-
速率限制
- 基于IP的限制
- 基于会话的限制
- 基于用户的限制
经过多个项目的实践验证，这套测试方法体系已经帮助团队将LLM系统的缺陷逃逸率降低了68%。最关键的心得是：不要被AI的特殊性吓住，回归测试本质——验证系统是否按设计运行，是否满足业务需求。