上周五下午四点，我正在改一个没什么人看的内部文档，突然被拉进一个紧急群聊。群里测试组的老K连发三条语音，语气像丢了孩子：“完了完了，大模型接口调用量上周冲到日均500万了，我们那200条手工用例还在SVN里躺着，一条条复制粘贴到Postman跑，已经连续加了三天班了。”
我盯着屏幕愣了两秒。不是因为500万，而是因为“200条手工用例”和“SVN”这两个词同时出现在2024年的聊天记录里。
问题到底卡在哪
先别急着说“我们也这样”。看一下实际场景就明白了。
大模型应用的测试，跟传统后端接口测试有个本质区别：输出不确定，但行为必须稳定。
你用Postman调一次/chat接口，输入“介绍一下北京”，大模型返回一段描述天安门的文字。你把这段文字复制到Excel里，打了个√。第二天同样的请求，它可能先说烤鸭，再说故宫——内容变了，但功能没错。你的“断言”怎么写？直接比较字符串？显然不行。
所以很多团队的“测试用例”根本不是自动化脚本，而是一堆手动执行的“对话模板+人工肉眼判断”。每换一个模型版本，就把这堆模板从头到尾点一遍，看回答“大差不差”就放过。
这种模式在每天几百次调用时勉强能忍。但当公司做了个Agent应用爆了，日调用量从5000飙升到500万，问题就炸了：
模型一周迭代两次，每次回归要人工看300条对话
线上出现badcase，无法快速转化为自动化用例
新来的实习生花了两周才学会“怎么正确地点开那200个模板”
我们踩过的坑
我所在的小组去年也遇到这个坎。当时我做的是一个RAG问答系统，调用量三个月涨了80倍。测试组三个人，每天的工作就是打开一个内部聊天页面，对着一个预置的问题列表逐条提问，然后凭经验判断答案质量。
有个问题我记得很清楚：“公司年会的报销流程是什么？”——答案是固定的，因为知识库里就那一份文档。但模型有时会自己发挥，把去年的流程也扯进来。我们用最笨的办法：把标准答案的关键词写在旁边，肉眼核对。
直到某天线上被用户投诉，说答案里出现了“根据2022年通知”，而那个通知已经作废了。测试组复查后发现，那条用例他们跑过，但当时“看着差不多就过了”。
就是因为这个事，我们才开始认真改流程。
解决方案：从搬运工到自动化
废话不多说，直接上我们现在的做法。不是最优解，但亲测能把测试效率从“3人日”变成“5分钟”。
第一步：用例结构化存储
别再往Excel里写中文了。用一个JSONL文件存用例，每行一个：
{"id": "case_001", "query": "公司请假流程是什么？", "expect": {"keywords": ["审批", "HR系统", "3天以上"]}, "type": "keyword"}
{"id": "case_002", "query": "帮我写一封申请报销的邮件", "expect": {"contains": ["报销", "附件", "财务部"]}, "type": "keyword"}
{"id": "case_003", "query": "昨天上海的温度", "expect": {"logic": "should_be_number_range", "min": -10, "max": 45}, "type": "range"}
关键点：断言规则要和数据在一起。每条用例知道自己是校验关键词还是数值范围，还是更复杂的语义相似度。
第二步：写一个测试执行器
别再用Postman了。一个简单的Python脚本就能搞定：
import json
import requests
from sentence_transformers import SentenceTransformer, util
加载用例
with open('test_cases.jsonl', 'r') as f:
cases = [json.loads(line) for line in f]
初始化语义模型（用于模糊断言）
sim_model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')
def run_test(case):
resp = requests.post('https://your-llm-endpoint/chat', json={'prompt': case['query']})
answer = resp.json()['answer']
if case['type'] == 'keyword':
for kw in case['expect']['keywords']:
assert kw in answer, f"缺失关键词: {kw}"
elif case['type'] == 'range':
# 提取数字（简化版）
numbers = [int(s) for s in answer.split() if s.isdigit()]
assert numbers, "没有找到数字"
assert case['expect']['min'] <= numbers[0] <= case['expect']['max']
elif case['type'] == 'similarity':
# 语义相似度断言
sim = util.pytorch_cos_sim(sim_model.encode(case['expect']['ref_answer']),
sim_model.encode(answer))
assert sim > case['expect']['threshold'], f"语义相似度太低: {sim}"
print(f"✓ {case['id']} 通过")
for case in cases:
run_test(case)
这个脚本跑一遍200条用例，加上网络耗时，大概40秒。关键是——完全自动化，任何人一键运行。
第三步：接入CI，每次模型更新自动回归
把上面那个脚本扔进GitHub Actions或者Jenkins，设置触发条件：每次模型服务有新镜像推送到registry，自动跑全量测试用例，结果发到钉钉/飞书群。
我们现在的流程是：
算法组发版新模型
CI触发，跑1500条用例（积累到现在）
5分钟后群里收到报告：“通过1487条，失败13条，详情见附件”
算法组开始查为什么那13条变了
整个过程不需要测试组任何人动手。测试组现在的精力放在两件事上：补充用例（把线上badcase转成用例），以及调整断言阈值（因为模型变强了，旧的关键词匹配可能过于严格）。
一些具体的技巧
技巧1：用“影子模式”生成用例
线上真实请求是宝藏。我们写了一个服务，随机采样5%的真实用户对话，连同模型当时的回答一起保存下来。然后人工审核这些对话，挑出其中“答案明显正确”的，直接转成测试用例。三个月攒了800多条高质量用例，人工成本远低于自己编。
技巧2：断言要分层
硬性规则（必须包含某些关键词、不能出现敏感词）——用规则断言
软性质量（答案是否相关、是否完整）——用语义相似度，但阈值不要设太高，0.7左右就够
事实准确性（比如日期、数字）——用正则提取+逻辑判断，不要依赖语义
技巧3：容忍模型的“合理变化”
一条用例失败了，先别急着改代码。我们遇到过一个case：问“公司几点上班”，旧模型回答“9点”，新模型回答“上午9:00（弹性工作制，最晚10点）”。关键词匹配会失败，但事实上新答案更好。这时候不是修bug，而是升级断言规则。
效果怎么样
我们这套东西跑了半年，测试组从3个人缩减到1.5个人（那0.5是兼着做别的），回归测试时间从6小时变成5分钟。更重要的是，线上投诉率下降了70%——因为每次模型更新前，那些“看着差不多”的边界问题都会被自动化用例挡下来。
所以回到标题：调用量暴涨1000倍不是问题，问题是你的测试手段还停留在手工搬运时代。别等线上出大事了才想起来改。
哦对了，那个发语音的老K，现在每天准时六点下班。前两天还发朋友圈晒新买的Switch卡带。
