传统 CI/CD 通常围绕代码变化组织。LLM 系统还需要同等重视提示、系统指令、工具目录、索引快照、embedding、检索策略、防护规则和基础模型本身。任何一项变化都可能以不明显的方式影响行为。提示示例或 embedding 模型的小幅变更，也可能显著改变准确性、延迟、安全性或成本。生成式系统对于相同输入也可能返回不同结果，即使 temperature 较低；提供商还可能更新模型或基础设施。因此，需要通过明确任务上的实际测量，判断系统是否满足要求。
评估驱动开发
Evaluation-Driven Development（EDD）将产品与风险要求转化为测试，包括带有预期行为的标准数据集、开放任务的 LLM 评分、检索指标、安全及对抗检查，以及延迟和成本预算。相关变化触发 CI 评估，候选版本只有在足够统计置信度下达到阈值，才能通过合并及部署检查。这需要按变化风险和发布阶段组织离线及在线评估，较早运行快速检查，在暴露给用户前执行更完整的验证。
即使 temperature=0 且固定 seed，服务差异和模型更新仍可能使结果变化。质量检查应评估通过率及置信区间等分布信息。实践练习采用单次样本检查；生产环境还需要对同一案例重复生成，测量波动程度。
需要版本管理和评估的内容
智能体或 RAG 系统中的以下变更都可能触发 CI 评估。
- 提示和系统消息：措辞、示例和工具使用说明。
- 模型及提供商升级：模型名称或路由变化；即使名称不变，也需要通过遥测识别服务行为变化。
- 检索组件：embedding 模型、索引策略、混合搜索、重排、分块和窗口设置，可能影响召回率、精确率及幻觉。
- 工具与智能体结构：新增工具、参数变化和多智能体协调逻辑。
- 防护规则：安全阈值、审核服务、越狱及提示注入规则。
- 数据更新：资料版本、重新提取、重新分块，以及拒绝列表。
- 基础设施设置：影响延迟和成本的缓存、流式输出、批处理及超时。
评估与发布的层次
不同阶段可以执行不同范围的检查。变化从 PR 进入 staging、canary 和生产环境时，逐步增加评估范围。以下是一种分层方式。
第一层：快速 PR 检查
目的是在人工审核前发现明显回归。
- Schema 检查：JSON 和工具调用必须符合规定格式，发现不合法示例时立即报告失败。
- 小型标准数据集：使用 50–200 个覆盖主要意图和容易出错情况的案例，按任务采用精确匹配或语义匹配。
- RAG 组件检查：在小型资料集合中检查上下文召回率、精确率和回答忠实度，例如使用 RAGAS 指标。
- 快速安全检查：扫描输入输出中的高风险类别，使用明确分类和阈值，便于审计。
- 延迟与成本检查：用少量案例进行初步耗时及 token 预算检查。少量样本的 p95 估计仅适合早期筛查，发布前仍需足够样本的性能测试。
第二层：合并前回归测试
目的是确认候选版本相对基线或当前生产版本，没有超出允许范围的退步。
- 更广的标准数据集：使用数百到数千个人工整理或来源于日志的案例，比较候选与参考版本。
- LLM-as-judge：开放任务使用经过校准的评估模型，要求结果达到预先规定的非劣效标准，例如胜率下降不超过 1.5%。应提前明确百分比或百分点的具体定义。
- 安全检查：加入提示注入、不当输出处理和工具滥用测试，严重问题直接阻止合并。
- 考虑波动：每项案例运行 N 次，CI 使用较小 N，staging 使用较大 N，依据置信区间判断。实践示例中的单次检查只展示基础流程。
第三层：Staging 发布前检查
执行耗时较长、不适合每个 PR 的测试。
- 大规模离线评估：使用经过去标识处理的数千到数万条生产输入，包括长尾和多语言分组，并按组与基线比较。
- 吞吐量与并发：采用真实对话长度和工具调用进行负载测试，使用与生产一致的遥测，检查 p95、p99 和错误预算。
- 对抗与安全：使用针对越狱、注入和具体政策的红队案例，高严重性违规应阻止发布。
第四层：逐步发布检查
目的是限制问题影响范围，并在在线信号正常时扩大流量。
- Canary：向少量用户发布，持续检查错误、超时、p95、每次交互成本，以及可行时的在线质量，例如抽样会话的评估模型胜率和用户评分。
- 防护事件：安全触发比例超过预设阈值时，例如政策阻止比例超过 X%，自动恢复到先前版本。
- 在线非劣效：质量变化保持在允许范围内即可，让降低成本或延迟、同时保持质量的改进能够发布。
第五层：部署后持续评估
目的是发现提供商、模型或数据变化，以及缓慢累积的质量回归。
- 定期评估：每晚从生产查询中轮换抽样，进行离线测试，并与前一周的分布比较。
- 变化监控：观察主题、语言、检索质量、token 用量和审核比例。分布超过阈值时告警并调查。
- 可审计性：保存每次发布的数据集版本、提示、模型标识及评估结果。
实践建议
处理生成波动
可以采用以下三种方法。
- 重复并汇集：每个案例运行 k 次，PR 使用较小 k，staging 使用较大 k。根据通过率或平均分及其置信区间判断，结果接近边界时交由人工审核。
- 控制采样和提示：在支持时固定 seed，保持回归提示稳定。提供商返回 system fingerprint 等信息时记录它，变化后触发更完整评估。
- 采用非劣效要求：许多变更只需确保退步没有超出可接受范围。
定义发布检查规则
将规则写成流程自动执行的明确政策。以下数值仅为设计示例，需要根据领域风险、指标版本和数据集校准。
- 安全：PR 测试中关键 OWASP 类违规为零；staging 高严重性违规比例不超过 0.05%。实际高风险操作可能需要更严格要求。
- 结构化输出：PR 数据集中 schema 和工具调用有效率为 100%，staging 至少为 99.9%。
- 封闭答案任务：关键子集精确匹配率至少 90%，整体至少 85%。
- 开放任务：评估模型胜率的 95% 置信区间满足非劣效要求；人工抽查至少 50 项，与评估模型的一致率至少 80%。
- RAG：staging 资料上的忠实度至少 0.75、上下文精确率至少 0.60、上下文召回率至少 0.65，并按领域调整。
- 延迟与成本：p95 请求时间符合 SLO，每轮 token 在预算内，错误率不超过阈值。
- Canary 扩大：运行指标全部达到要求，累计 N 次交互的在线质量满足非劣效；安全事件异常增加时恢复先前版本。
规则应纳入版本管理，并绑定分支保护、必需检查和批准规则，确保实际执行。
评估数据集
- 标准数据集：人工整理、保持稳定，并标注正确性或安全违规。优先覆盖真实用户价值和历史失败。
- 分组：明确区分长问题、代码、多轮澄清、非英语和敏感主题等类别，分别报告，减少平均值掩盖问题的风险。
- 日志回测：将生产追踪去标识化、分层抽样，并加入失败和险些失败的案例。
- 参考答案管理：冻结参考答案，只有经过人工审核才更新，避免持续使用同一个模型重新生成标准答案。
LLM-as-judge
评估模型可以处理开放任务，但需要管理系统性评分倾向和随时间变化的问题。
- 校准与监控：保留小型人工标注集，持续测量模型评分与人类判断的一致程度。
- 多评估者与裁决：采用不同模型或提示进行两次评价，分歧交给第三个模型或人工抽查。
- 记录评估模型：保存模型名称、提示和版本，模型更新后重新校准。
- 成对比较：让模型比较 A/B，通常比没有固定尺度的自由评分更稳定。
RAG 专项检查
RAG 的常见问题包括无关上下文、遗漏证据和编造细节，可以通过组件指标定位。
- 检索质量：上下文精确率衡量检索内容中有多少相关信息，召回率衡量所需证据是否被找到。
- 忠实度与依据：检查回答是否得到检索来源支持，减少无依据主张。
- 相关性与用途：检查回答是否切题并对用户有帮助。
RAGAS 提供常用开源指标实现。可以选择适合领域的部分指标，明确版本、测量方法和阈值。
符合生产情况的延迟与成本检查
在各阶段定义并执行预算。
- 延迟：检查 p95 TTFT 及到最后一个 token 的时间。聊天界面尤其需要关注 TTFT。
- Token 用量：限制每次交互输入与输出 token 总数的平均值和 p95，作为多数托管模型单位成本的参考。
- 吞吐量与并发：staging 使用真实 QPS 和并发度测试，扩缩容后仍未达到容量要求时阻止发布。
将评估接入发布流程
- 开发者修改提示、模型、检索或政策，创建 PR。
- 运行第一层：schema、小型标准数据集、快速安全检查，以及延迟和成本初步测试。必需检查全部通过。
- 运行第二层：更广的数据集和日志回测、RAG 指标、安全测试，以及非劣效评价。
- 在功能开关保护下合并，进入第三层 staging：大规模离线评估、负载测试及深入安全检查。
- 进行第四层 canary，自动分析结果，达到要求后扩大流量，违规时恢复先前版本。
- 进入生产并持续执行第五层：夜间回测和变化监控。
每一步的检查规则都应明确、版本化并自动执行，人工集中处理接近判断边界或风险较高的结果。
常见问题与对应检查
- 单元测试通过，用户仍然不满意：标准数据集可能没有代表真实流量，应从日志回测并按场景分组。
- 更换 embedding 后延迟明显增加：需要在接近生产的并发下检查 p95 和 TTFT，采用与线上监控一致的指标。
- 提供商更新后回答变化：记录模型标识或 fingerprint，定期评估以发现变化。
- 新工具造成政策违规：工具变更应通过对应 OWASP 风险的安全测试，再进入发布流程。
- PR 检查结果不稳定：增加重复运行，并根据分布和非劣效规则判断。