回归测试

建议将Agent评估体系纳入回归测试流程，每次模型或提示词更新后快速验证是否出现性能退化

检索和生成必须分开测试，通过建立小型评估集，先单独检查检索器有没有召回正确证据，再去评估模型措辞。

行为回归测试借鉴了传统软件工程中的回归测试理念：每当修改提示词时，自动运行一组预定义的测试用例，验证模型在关键行为维度上没有退化

回归测试指在修改代码后重新运行已有的测试用例，确保新改动没有引入新Bug或破坏原有功能

冒烟测试（Smoke Testing）只检查系统能否启动和核心路径能否跑通，而回归测试（Regression Testing）是对所有已有功能进行全面验证，两者不可互相替代

回归测试不仅验证Bug本身是否修复，还需要测试与该Bug相关联的功能是否受到影响

传统回归测试面临核心困境：全量回归耗时过长，而随机选择可能遗漏关键场景

LLM可以辅助生成回归测试的骨架，但开发者必须人工审查用例是否覆盖异常分支、全局状态变化和数据库交互时序

需要回归测试与灰度发布机制来保证模型版本更新后的行为一致性。

重写比例越高，回归测试的覆盖率和断言质量就越关键，因为它是判断重写是否等价的唯一客观依据。

将测试集分为必须通过的核心用例和尽力覆盖的边缘用例，核心用例的任何失败都会阻止发布

Agent 评估的三种具体手段是 LLM as a judge（用模型自动大规模质量检查）、回归测试（捕捉意外副作用）以及将评估嵌入 CI/CD 流水线（变更进入生产前验证）。

模型回归测试通过固定评测集在更换提示词、模型版本或检索配置后重跑，比较通过率是否下降；判定方式包括打分阈值、语义相似度或LLM-as-judge，并对多次采样做统计比较。

设计评测集、幻觉检测、构建回归测试监控模型行为等技能在工程团队里极度稀缺。

综合Reddit讨论，目前没有统一解决方案；实践中的做法包括建立关键政策的回归测试、为文档添加版本元数据、人工抽查结合用户反馈；对于早期项目，建议先聚焦高频问题，手动验证更新效果，再逐步自动化。

对下游开发者而言，小版本迭代意味着接口兼容性通常得以保持，但模型行为仍可能有细微漂移，版本固定与回归测试因此成为接入 API 时的必要实践。

如果一个案例在所有试过的后端上都从未失败，它是冒烟测试而非回归测试，应放到另一个文件中。

检查点频繁更新会导致同一提示词在不同检查点上的输出长度、格式偏好发生漂移，团队应维护面向自身业务的固定任务集做回归测试。

对于 CLI 工具，回归测试应覆盖核心命令的参数解析、输出格式、退出码以及跨平台行为。

在RAG语境下，回归测试是用固定查询集反复验证检索配置变更后系统表现是否下降，包括查询级别的退化、恢复和共同失败分析。