回归测试（Regression Testing）

回归测试（Regression Testing）

概念解释

回归测试（Regression Testing）是一种质量保障手段：每次对 Agent 做了任何改动（改 Prompt、换模型、调参数），都拿出一批之前验证过能正确处理的测试用例重新跑一遍，看看新的改动有没有把原来好用的功能搞坏。

传统软件的回归测试已经很成熟，但 AI Agent 的回归测试面临三个独有的难题。第一，LLM 的输出是非确定性的——同样的输入不会每次给出一模一样的答案。第二，Prompt 的修改会产生隐性副作用——改进了 A 功能的 Prompt 可能悄悄削弱了 B 功能。第三，模型供应商会静默更新 API——你的代码一行没改，但模型行为已经变了。这三个问题叠在一起，导致 Agent 系统特别容易出现"改着改着就坏了"的情况。

回归测试的核心思路是：不要求每次输出完全一样，而是维护一个"黄金数据集"（Golden Dataset），里面存着历史上验证过的、被信任的测试用例。每次变更后，用新版本在这些用例上跑，和旧版本的表现做对比。如果某些指标明显下滑，就拦住，不让发布。

关键结构

结构 1：黄金数据集（Golden Dataset）

黄金数据集不是随便采样的测试数据，而是经过人工审核、业务认可、定期维护的"标准答案库"。每条用例包含四个要素：输入（用户问题或指令）、期望行为（参考答案或行为描述）、评判标准（怎么判定 Agent 的输出达标）、元数据（创建时间、版本号、标签）。

一个实用的分层策略：核心功能测试占 60%（Agent 的主要职责场景），边界条件测试占 20%（难题、歧义、特殊输入），回归防护测试占 20%（曾经出过 bug 的场景）。

数据来源包括：用户反馈中的高频问题、客服团队积累的问法集、质量审计中发现的失败案例、新功能发布时的验收测试集。规模上，200-500 条高质量用例足以覆盖大多数场景。

结构 2：基准线（Baseline）

基准线是一份性能指标的快照。用当前线上版本在黄金数据集上跑一遍，把各维度的指标（准确率、延迟、成本等）记录下来。这份快照就是后续所有变更的对标参考。

基准线不是一成不变的。当新版本确认表现更优并安全上线后，基准线就会更新为新版本的指标。通过保留历史基准线，可以追踪系统质量的长期趋势。

结构 3：评估指标

AI Agent 的回归测试不能用传统的"精确匹配"来判断对错，需要更灵活的评估方式：

• 语义相似度：用 BERTScore 等指标衡量输出和参考答案在语义上是否一致，即使措辞不同也能正确评分
• LLM-as-Judge：用另一个 LLM 来评判输出是否满足预设标准，适合开放式任务
• 契约检查：不匹配完整输出，只断言关键属性——输出结构是否正确、必需字段是否存在、禁止内容是否出现
• 分片指标：按主题、任务类型、用户群体分组统计，先发现哪个分片出了问题

结构 4：质量门禁（Quality Gate）

质量门禁是发布流程中的一道关卡。它的核心是两类阈值：

• 绝对阈值：如"准确率必须 >= 90%"
• 相对阈值：如"准确率相比基准线下降不能超过 5%"

只有同时满足绝对阈值和相对阈值，变更才能通过门禁进入发布。这个机制集成在 CI/CD 流水线中，代码合并或模型更新时自动触发。

核心原理

原理说明

回归测试的工作机制分为五步：

1. 构建黄金数据集：从历史成功案例、用户反馈、质量审计中精选测试用例，每条包含输入、期望行为和评判标准
2. 建立基准线：用当前线上版本在黄金数据集上跑一遍，记录各维度指标作为参考
3. 实施变更：开发者修改 Prompt、升级模型版本或调整参数
4. 对比评估：新版本在同一批黄金数据集上运行，采集指标与基准线对比。由于 LLM 输出有随机性，每条用例通常跑 3-5 次取平均值
5. 质量决策：指标下滑超过阈值则拒绝发布并回滚，通过则发布新版本并更新基准线

这套机制的关键在于"对比"而非"绝对判断"——不是要求每次输出完全正确，而是确保新版本不比旧版本差。

Mermaid 图解

图中的核心流转点在"质量门禁"节点。它是整条流程的分叉点：通过则进入正向循环（发布 -> 更新基准线 -> 下一轮迭代），不通过则进入修复循环（分析原因 -> 重新调整 -> 再次评估）。这两个循环保证了系统质量只会向上走，不会悄悄退化。

下面这张时序图展示了回归测试在 CI/CD 流水线中的实际触发过程：

运行示例

以下是一个最小化的回归测试框架示例，展示核心机制：构建测试集、运行评估、对比基准线。

# 基于 deepeval==2.5.1 验证（截至 2026-03）
from dataclasses import dataclass, field
from typing import List, Dict

@dataclass
class GoldenCase:
    """黄金数据集中的一条测试用例"""
    input: str           # 用户输入
    expected: str        # 期望行为描述
    tags: List[str] = field(default_factory=list)  # 分类标签

@dataclass
class BaselineSnapshot:
    """基准线快照：记录某个版本的性能指标"""
    version: str
    scores: Dict[str, float]  # {"accuracy": 0.85, "relevancy": 0.90, ...}

def run_regression_test(
    golden_dataset: List[GoldenCase],
    baseline: BaselineSnapshot,
    new_scores: Dict[str, float],
    threshold: float = 0.05
) -> Dict:
    """
    回归测试核心逻辑：对比新版本指标与基准线

    参数:
        golden_dataset: 黄金数据集
        baseline: 历史基准线
        new_scores: 新版本在黄金数据集上的评分结果
        threshold: 允许的最大下降幅度（默认 5%）

    返回:
        包含通过/失败判定和详细对比的字典
    """
    regressions = []
    for metric, old_score in baseline.scores.items():
        new_score = new_scores.get(metric, 0)
        drop = old_score - new_score
        if drop > threshold:
            regressions.append({
                "metric": metric,
                "baseline": old_score,
                "current": new_score,
                "drop": round(drop, 4)
            })

    passed = len(regressions) == 0
    return {
        "passed": passed,
        "baseline_version": baseline.version,
        "regressions": regressions,
        "verdict": "PASS - 可以发布" if passed else "FAIL - 存在回归，需要修复"
    }

# --- 使用示例 ---
golden_dataset = [
    GoldenCase("解释什么是 RAG", "应涵盖检索、增强、生成三个环节", ["核心功能"]),
    GoldenCase("RAG 和微调的区别", "应说明各自适用场景和成本差异", ["概念辨析"]),
    GoldenCase("", "应返回友好的错误提示", ["边界场景"]),
]

baseline = BaselineSnapshot(version="v1.2", scores={"accuracy": 0.85, "relevancy": 0.90})
new_scores = {"accuracy": 0.83, "relevancy": 0.91}  # 准确率下降 2%，相关性提升 1%

result = run_regression_test(golden_dataset, baseline, new_scores, threshold=0.05)
print(result)
# {'passed': True, 'baseline_version': 'v1.2', 'regressions': [], 'verdict': 'PASS - 可以发布'}
# 准确率下降 2% < 阈值 5%，所以通过

代码展示了回归测试的核心判断逻辑：逐项对比新旧指标，任一指标下滑超过阈值就判定失败。实际生产中，new_scores 由评估框架（如 DeepEval、Evidently）在黄金数据集上自动计算得出，每条用例会多次运行取平均以消除随机性。

易混概念辨析

核心区别：

• 回归测试：关注"变更是否引入了退化"，发生在发布前，用历史验证过的用例做离线对比
• A/B 测试：关注"哪个版本在真实用户中表现更好"，发生在发布后，用线上流量做在线对比
• Benchmark：关注"模型的通用能力水平"，用标准化公开数据集衡量，不针对特定业务场景

适用边界与局限

适用场景

1. Prompt 迭代优化：修改了 Prompt 想提高某项能力时，回归测试能及时发现"改好了 A 却搞坏了 B"的副作用。例如客服 Agent 把"友好风格"改为"严谨风格"，回归测试发现在"安抚用户情绪"的场景上表现下滑
2. 模型版本升级：从 GPT-4 换到 GPT-4o、从 Claude 3 升到 Claude 4 时，模型行为可能悄悄变化。回归测试作为"体检清单"，逐项检查新模型有没有在某些场景上退步
3. 多 Agent 系统的端到端验证：当系统由多个子 Agent 协作时，修改其中一个子 Agent 可能级联影响整条链路。端到端回归测试能捕捉这种跨组件的退化
4. CI/CD 自动质量卡点：集成到 CI/CD 流水线中，开发者提交 PR 时自动触发，未通过则拦截合并，防止问题流入生产

不适合的场景

1. 全新功能的初始开发：还没有历史基准线和黄金数据集时，回归测试无从对比。此时应先做功能测试和验收测试，积累数据后再建立回归机制
2. 纯创意性任务：对于写诗、编故事等高度开放的任务，"退化"本身难以定义——换个风格可能就是需求而非 bug

局限性

1. 黄金数据集的维护成本高：需要专人持续审核、标注、更新测试用例。在快速迭代的团队中，这可能成为瓶颈。数据集跟不上业务变化会导致测试覆盖失真
2. 无法覆盖未知场景：黄金数据集只能覆盖已知的问题类型。用户在生产中遇到的全新问题，回归测试覆盖不到，需要配合线上监控使用
3. 开放式任务的评估困难：对于没有明确"对错"标准的任务（如文章生成），即使用 LLM-as-Judge 评分也容易出现偏差，阈值设定需要反复调试
4. 统计噪声干扰决策：LLM 输出的随机性导致两个版本的微小差异可能在统计上不显著，但团队却用这些差异做发布决策，有时会导致误判

常见误区

思考题

参考资料

1. Evidently AI - LLM 回归测试教程
2. Confident AI - LLM Testing in 2026: Top Methods and Strategies
3. Langfuse - LLM Testing: A Practical Guide
4. Statsig - Prompt Regression Testing: Preventing Quality Decay
5. promptfoo - Prompt/Agent/RAG 测试框架
6. Braintrust - AI Agent Evaluation: A Practical Framework
7. DeepEval - LLM 评估框架官方文档