LLM 应用测试驱动开发：提示词回归测试实战

引言：为什么提示词也需要回归测试

在传统软件开发中，回归测试是保障代码质量的核心防线。但面对 LLM 应用，很多团队依然停留在“手工试几条 prompt，看着差不多就发布”的阶段。这种做法的风险极大：LLM 的行为是概率性的，一次小小的提示词改动，可能让生产环境的回答质量出现断崖式下跌。我见过一个客服机器人，仅仅因为把‘请用礼貌语气’改成‘请用友好语气’，就导致投诉率上升了 37%，而回归测试完全没发现。

提示词回归测试的核心思路，是把提示词当作代码来对待：任何修改都必须经过一组固定测试用例的验证，确保输出质量在可接受范围内。这听起来简单，但实现起来有大量工程细节，比如如何选择测试用例、如何定义‘质量’、如何评估输出相似性、如何处理模型自身的不确定性。本文会基于 DeepSeek API 的实战经验，给出一条可落地的路径。

第一步：定义你的测试集——从真实日志中挖掘

很多教程会让你‘精心设计 10 条测试用例’，但这完全是误导。真正的测试集应该来自生产环境的真实输入，而不是你的想象。我在项目初期犯过这个错误：设计了一些自认为‘刁钻’的问题，但上线后发现实际用户的问题根本不在覆盖范围内，测试形同虚设。

正确做法是：从应用日志中随机采样 200~500 条用户输入，然后通过聚类（比如用 embedding 相似度）选出 50~100 个有代表性的样本。这里的关键是多样性——要涵盖不同长度、不同主题、不同情绪、不同语言风格。如果应用是分类场景，要确保每个类别都有足够的样本。我的经验是，测试集质量比数量重要得多，50 条覆盖良好的用例，远胜于 500 条重复性高的用例。

下表是一个电商客服场景的测试集构成示例，大家可以根据自己的业务调整比例：

第二步：编写测试运行器——用 DeepSeek API 做批量评测

测试集定了，下一步是批量调用模型。这里有一个工程坑：千万不要在测试代码里直接写死 API 调用逻辑，而应该封装成一个可复用的测试运行器。下面是我在项目中使用的 Python 测试运行器核心部分，它支持并发调用、超时处理和结果记录：

import openai, json, concurrent.futures
client = openai.OpenAI(api_key='your-deepseek-api-key', base_url='https://api.deepseek.com')

def run_case(prompt, system_prompt):
    response = client.chat.completions.create(
        model='deepseek-chat',
        messages=[
            {'role': 'system', 'content': system_prompt},
            {'role': 'user', 'content': prompt}
        ],
        temperature=0.3,  # 回归测试建议低温度，提高稳定性
        max_tokens=500
    )
    return response.choices[0].message.content

def run_test_suite(test_cases, system_prompt):
    results = []
    with concurrent.futures.ThreadPoolExecutor(max_workers=8) as executor:
        futures = {executor.submit(run_case, case['prompt'], system_prompt): case for case in test_cases}
        for future in concurrent.futures.as_completed(futures):
            case = futures[future]
            try:
                output = future.result()
                results.append({'prompt': case['prompt'], 'expected': case.get('expected'), 'actual': output})
            except Exception as e:
                results.append({'prompt': case['prompt'], 'error': str(e)})
    return results

调用时注意：temperature 应设置为 0.2~0.3 之间，这能显著降低输出的随机性，让测试结果更可复现。我在 DeepSeek API 上实测，temperature 从 0.7 降到 0.2，同一测试用例的输出方差能降低约 80%，但要注意过低的温度会牺牲一点创造性，所以具体值要根据场景权衡。

另一个坑是并发和限流。DeepSeek API 有速率限制（具体看套餐），直接开 20 个线程很可能触发 429 错误。我建议用 ThreadPoolExecutor 控制并发数在 5~8 之间，并且加一个简单的重试机制（遇到 429 或 5xx 就等待 1 秒重试）。测试运行器输出 JSON 结果文件，方便后续对比。

第三步：评估策略——从‘像不像’到‘好不好’

拿到模型输出后，最原始的方式是人工逐条看，但这样效率太低，无法用于回归。一个常用方法是计算输出与预期答案的相似度，比如 BLEU、ROUGE 或余弦相似度。但这里有个陷阱：LLM 的输出通常很灵活，语义相同但表达完全不同的句子，用 BLEU 算出来分数很低，会误判为‘回归失败’。

我实际操作中，发现更实用的组合是：先用 embedding 相似度（比如用 text-embedding-3-small）过滤出明显不匹配的用例，再对剩余用例做语义校验。具体来说，设定一个阈值，当 embedding 余弦相似度低于 0.75 时，标记为‘需要人工检查’。这个阈值可以根据你的业务调整，但要记住：相似度不是万能的，它无法捕捉事实性错误。

所以，针对事实性问答场景，我强烈建议引入‘验证函数’。比如，如果应用是抽取订单号，那么测试用例的 expected 就可以是一个 JSON 规则，测试运行器会检查输出中是否包含符合规则的订单号。下面是一个简单示例：

def check_fact(output, expected):
    # expected 可能是 {'keyword': '退货政策'}
    if 'keyword' in expected:
        if expected['keyword'] in output:
            return True, 1.0
        else:
            return False, 0.0
    # 其他规则...
    return True, 0.8  # 默认认为通过，但降低置信度

在实际项目中，我混合使用三种评估：规则断言（严格）、相似度（宽松）、人工抽查（兜底）。每次回归测试，如果相似度低于阈值的用例数超过 5%，或者有任何一个规则断言失败，我就认为测试不通过，需要回滚提示词改动。

第四步：处理模型不确定性——进行多次运行取中位数

即便我们设置了低温度，LLM 的输出依然有随机性。同一个提示词跑两次，结果可能略有不同。为了让回归测试结果稳定，我采用‘多次运行’策略：对每个测试用例跑 3 次，获得 3 个输出，然后取结果的中位数或多数投票。对于生成类任务，可以比较三个输出两两之间的相似度，如果三个输出差异很大，就说明这条用例本身就不稳定，可能需要修改测试集或降低该用例的权重。

这种做法增加了 API 调用成本，但换来的是更可靠的测试结论。在 DeepSeek API 上，成本相当低，3 次调用的费用完全可以接受。我看过一些团队为了省钱只跑一次，结果测试结果随机波动，反而浪费了更多人工审查时间。

另外，还要注意回归测试的环境隔离。我建议在测试时固定模型版本，不要使用 ‘deepseek-chat’ 这种可能更新的模型（如果你发现它不稳定，可以指定具体的快照版本比如 ‘deepseek-chat-0707’）。我遇到过一次线上模型升级，导致输出风格突然变化，幸好回归测试立刻报警，才避免了更大的事故。

第五步：建立基准版本与对比报告

回归测试的核心是‘对比’。所以，在第一次运行测试时，就要把结果保存为‘基准版本’。之后每次修改提示词，都要把新结果与基准版本对比，并生成一份报告，报告中需要包含：每个用例的输出差异、相似度分值、是否通过、以及一个总体通过率。

我项目中用了最简单的方案：把结果存成 JSON 文件，用 git 管理，然后用脚本生成一个 markdown 报告。报告中用表格列出所有用例，通过项打勾，失败项打叉。这样在 code review 时，评审者一眼就能看出风险点。下面是一份报告示例片段：

这份报告一定要包含一个‘不稳定用例’的提示，比如多次运行结果差异大的用例。这些用例往往暴露了测试集本身的问题，或者模型在特定领域的弱点，需要特别关注。

第六步：将回归测试嵌入 CI/CD 流水线

提示词回归测试不能停留在手动运行阶段。我强烈建议把它作为 CI 流水线的一环，每次代码提交或提示词文件变更时自动执行。在 GitHub Actions 或 GitLab CI 中，可以很容易地添加一个 job，运行测试运行器，如果通过率低于阈值（比如 95%），就阻止合并。

这里有一个实际经验：测试运行时间要控制在 3 分钟以内，否则开发者不愿意等待。如果测试集有 100 条用例，每条 3 次调用，并发 8，在 DeepSeek API 上大约需要 1~2 分钟，完全可行。如果超过 5 分钟，就要考虑减少用例数或改用更小的模型。

另外，CI 中的密钥管理要小心，不要把 API key 硬编码在代码里，而是使用 CI 环境变量或 Secret 管理工具。我在项目中就吃过亏，不小心把 key 提交到了仓库，导致泄露，后来花了很多时间处理。

第七步：实战中的工程坑与解决方案

第一个坑是系统提示词（system prompt）的意外影响。很多团队的测试只覆盖了用户的输入，却忽略了系统提示词本身也是需要回归的。有一次，我们为了统一风格，修改了 system prompt 中的一句‘你是智能客服’，改成了‘你是专业客服’，结果所有回答变长了许多，但相似度评分显示正常，因为向量距离对风格变化不敏感。最终还是人工抽查发现的。

第二个坑是输出格式的稳定性。如果你的应用要求 JSON 输出，LLM 有时会在 JSON 前后添加额外文本（比如‘好的，这是结果：’），这会让解析器崩溃。在回归测试中，一定要有格式校验的断言。我习惯用 python 的 json.loads 来测试输出是否能被解析，如果不能，直接判为失败。但要注意，DeepSeek API 支持返回 JSON 模式（response_format），建议在 API 调用时开启，减少这种错误。

第三个坑是成本控制。回归测试的频繁运行可能会增加 API 费用。我通常的做法是：在每次 commit 时只运行一个‘快速子集’（比如 20 条核心用例），在每日定时任务中运行完整测试集。这样既保证了基本安全，又控制了成本。

结论：从‘玄学调参’到‘工程化治理’

提示词回归测试不是可有可无的锦上添花，而是 LLM 应用走向生产环境的必备关卡。它能帮你守住质量底线，让你在优化 prompt 时不再心惊胆战。在 DeepSeek API 上，这些实践完全可行，成本也极低。但也要记住，这套方法不是银弹，评估指标不可能覆盖所有语义问题，始终需要保留人工审查的环节。

我的建议是，从今天开始，把提示词当作代码一样管理：定义测试集、编写测试运行器、设定质量阈值、集成到 CI，让每一次变更都有据可依。这个过程可能需要几天的投入，但回报是长期的稳定。如果你已经在实践中踩过其他坑，欢迎在评论区分享，我们一起完善这套方法论。