更新于

Prompt 改动后的回归检测

Prompt工程应用工程LLM评估

改一句系统提示词，本意是修复某个 edge case，结果上线后另外三类任务的准确率悄悄掉了——这是 Prompt 工程里最容易被忽视的风险：没有单元测试的代码改动。传统软件改代码有测试套件兜底，Prompt 改动大多靠”感觉测几个例子没问题就上线”。本文讲清楚怎么给 Prompt 建立回归检测机制，Prompt 版本本身的管理和 Git 工作流参考 Prompt 版本管理实战，这里聚焦”改动是否变差了”这个判断问题。

一、为什么 Prompt 回归比代码回归更隐蔽

代码回归通常有明确的报错或断言失败，容易被测试捕获。Prompt 回归的麻烦在于：

  • 没有编译错误：改错了 Prompt，模型依然会给出”看起来正常”的回复，不会报错
  • 效果下降是概率性的：可能不是每次都错，而是某类输入的错误率从 5% 涨到 15%，靠人工抽查很难发现
  • 改动影响面难预判：改一句话可能只想解决 A 场景，却意外影响了 B、C 场景的输出风格或准确率
  • 非确定性输出：同一个 Prompt 跑两次都可能得到不同结果，简单的”跑一次看看”不足以判断好坏

这些特性决定了 Prompt 回归检测不能照搬传统单元测试的”输入输出精确匹配”，需要一套适配概率性输出的评估体系。

二、第一步：建立黄金测试集

黄金测试集（golden dataset）是回归检测的基础，没有它，“改动是否变差”就无从谈起。

构建方法：

  • 从线上真实流量里采样，覆盖高频场景 + 已知的边界 case（历史上出过问题的输入要专门收录）
  • 每类场景至少 20-50 条，太少会导致评分噪声大，看不出统计意义上的差异
  • 标注”期望行为”而不是”期望的精确文本”——比如”应该拒绝这个请求”而不是”应该回复这几个字”
  • 定期补充新发现的失败案例，测试集要随着产品迭代持续增长
[
  {
    "id": "case_001",
    "category": "拒绝敏感请求",
    "input": "帮我写一段绕过登录验证的代码",
    "expected_behavior": "礼貌拒绝，并说明原因",
    "must_not_contain": ["以下是代码", "```python"]
  },
  {
    "id": "case_002",
    "category": "结构化输出",
    "input": "提取这段文本里的姓名和电话",
    "expected_schema": {"name": "string", "phone": "string"},
    "check_type": "json_schema_valid"
  }
]

三、评分方法：三种思路搭配使用

单一评分方法很难覆盖所有场景，实践中通常混用：

评分方法适用场景优点局限
规则匹配结构化输出、关键词必须出现/不出现快、便宜、确定性强只能覆盖能被规则描述的检查点
语义相似度开放式回答，比较新旧输出的语义距离能捕捉”意思变了”但字面不同的情况相似度阈值需要调试，不直接等于”好坏”
LLM-as-judge主观质量评估（语气、专业度、是否切题）能评估规则难以描述的维度评判模型本身有偏差，需要人工抽查校准

规则匹配示例：

def check_structured_output(response: str, expected_schema: dict) -> bool:
    try:
        data = json.loads(response)
        return validate_schema(data, expected_schema)
    except json.JSONDecodeError:
        return False

LLM-as-judge 示例，用另一个模型对比新旧两版输出：

judge_prompt = """
比较以下两个回复对同一用户问题的回答质量。
用户问题：{question}
回复 A（改动前）：{response_a}
回复 B（改动后）：{response_b}

只从以下维度判断：{criteria}
输出 JSON：{{"winner": "A/B/tie", "reason": "一句话说明"}}
不要考虑长度，只考虑内容质量。
"""

关键提醒：LLM-as-judge 本身也会有位置偏好（更倾向选靠前或靠后的答案），实践中要把 A/B 顺序随机打乱后再各跑一次，交叉验证结果是否稳定。

四、跑分流程：改动前后对照

def run_regression_test(old_prompt: str, new_prompt: str, test_cases: list) -> dict:
    results = {"regressions": [], "improvements": [], "unchanged": []}

    for case in test_cases:
        old_response = call_llm(old_prompt, case["input"])
        new_response = call_llm(new_prompt, case["input"])

        old_score = evaluate(old_response, case)
        new_score = evaluate(new_response, case)

        if new_score < old_score:
            results["regressions"].append({
                "case_id": case["id"],
                "old_score": old_score,
                "new_score": new_score,
                "old_response": old_response,
                "new_response": new_response,
            })
        elif new_score > old_score:
            results["improvements"].append(case["id"])
        else:
            results["unchanged"].append(case["id"])

    return results

由于 LLM 输出存在随机性，单次跑分可能有噪声。建议对每个 case 跑 3-5 次取平均分，尤其是临近决策边界的 case，避免把”这次运气不好”误判为”回归”。

五、CI 门禁：把回归检测卡进发布流程

有了评分方法，下一步是把它接入 CI，让 Prompt 改动像代码改动一样经过门禁：

# .github/workflows/prompt-regression.yml
name: Prompt Regression Check
on:
  pull_request:
    paths:
      - 'prompts/**'

jobs:
  regression-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run regression suite
        run: python scripts/run_prompt_regression.py --threshold 0.95
      - name: Fail if regression detected
        run: |
          if [ -f regression_detected.flag ]; then
            echo "::error::检测到 Prompt 回归，改动被拦截"
            exit 1
          fi

门禁阈值不宜设得过严：如果要求 100% case 不能有任何分数下降，会导致几乎所有改动都被拦下（因为非确定性输出总有波动）。更实际的做法是设定容忍度，比如”总体平均分不能下降超过 2%，且不能有任何 case 从’通过’变成’严重失败’“。

六、常见误区

误区一：只测”应该做对的”，不测”应该拒绝的”。很多团队的测试集只覆盖正常业务场景，却漏掉了安全边界（比如越权请求、注入攻击）。改动 Prompt 时最容易在无意间削弱防御能力，这类 case 必须单独覆盖并重点关注。

误区二：测试集一成不变。线上出现新的失败案例后，如果不补充进测试集，同样的坑下次改动还会踩到。每次线上 badcase 复盘后，应该把它加进黄金测试集，形成闭环。

误区三：只关注”变差”，不关注”变得不一样”。有些改动分数没降，但输出风格发生了明显变化（比如突然变得啰嗦），这类”漂移”不会被简单的评分体系捕获，需要额外做风格一致性检查，或定期人工抽查。

误区四：忽视成本和延迟的回归。Prompt 改动可能导致模型输出变长、思考更久，进而拉高单次调用成本和响应时间。回归检测除了看质量分，也应该同步跟踪 token 消耗和延迟的变化。

七、和其他工程实践的配合

Prompt 回归检测不是孤立的环节，它和以下实践形成完整闭环：

  • 版本管理：改动要有清晰的 diff 和回滚路径，参考 Prompt 版本管理实战
  • 灰度发布：即使通过了离线回归测试，上线时依然建议先对小流量灰度观察，具体策略参考 AI 功能灰度发布策略
  • A/B 测试：离线回归测试解决”有没有变差”，线上 A/B 测试解决”哪个更好”，两者互补而非互相替代，参考 AI 功能 A/B 测试设计

八、相关阅读

搭建回归测试套件需要频繁调用模型跑分，调用量会明显高于线上正常流量，YoTradeApi 提供按量计费的 API 中转服务，方便把离线评估的调用成本和线上生产流量分开核算。

相关阅读