传统软件的 CI/CD 主要围绕应用代码变更运转；而在 LLM 系统中，提示词、系统指令、工具注册目录、向量索引快照、embedding 模型、检索与重排策略、安全护栏规则以及底层基础模型的任何变动，都可能以隐蔽的方式改变系统行为。哪怕只是微调了一个 Few-shot 示例或更换了 embedding 模型版本，都可能引起回答准确率、延迟、安全性或调用成本的显著波动。此外，即便将 temperature 设为较低值，生成式系统对同一输入仍可能存在输出波动，且上游模型服务商还可能在不通知的情况下更新底层模型或推理基础设施。因此，AI 应用的交付必须建立在针对具体任务的量化评估测量之上。
评估驱动开发
评估驱动开发（EDD）将产品需求与安全风控要求转化为可自动执行的测试套件，涵盖带预期输出的标准标注数据集、开放式任务的 LLM 评判（LLM-as-a-Judge）、检索质量指标、安全与红队对抗检查，以及延迟与 token 成本预算。任何相关变更都会自动触发 CI 评估流水线，候选版本必须在具备足够统计置信度的前提下达到预设阈值，方可获准合并代码与推进部署。
需要注意，即使固定设置 temperature=0 与随机种子（seed），底层硬件并发差异或服务商模型小版本更新仍可能导致输出波动。因此，生产级质量门禁不应仅凭单次采样断言成败，而应评估多次运行的通过率及置信区间等分布指标（课程实践练习以单次样本检查演示基础流程，生产环境则需对同一用例重复采样多次以量化波动范围）。
需要纳入版本管理与触发 CI 评估的变更项
在智能体或 RAG 系统中，以下任意一项发生变更均应触发对应的 CI 评估：
- 提示词与系统消息：指令措辞、Few-shot 示例及工具调用说明的修改。
- 模型及服务商升级：切换模型名称、调整路由策略，或通过遥测监控识别出同名模型的服务端行为漂移。
- 检索链路组件：embedding 模型、向量索引参数、混合搜索权重、重排序模型、分块大小与重叠窗口的调整（直接影响召回率、精确率与幻觉率）。
- 工具与智能体拓扑：新增工具、修改参数 Schema 或调整多智能体委派协调逻辑。
- 安全护栏规则：安全分类阈值、内容审核服务、越狱与提示词注入拦截规则的变更。
- 底层数据更新：语料版本升级、重新解析提取、重新分块及拒答/屏蔽词列表更新。
- 推理与基础设施配置：影响端到端延迟与成本的缓存策略、流式输出配置、批处理参数与各级超时设置。
评估与发布的五个递进层次
随着变更从 Pull Request（PR）逐步推向 Staging（预发环境）、Canary（灰度金丝雀）直至全量生产环境，评估的广度与深度也应逐级递增：
第一层：快速 PR 检查（Fast PR Checks）
目标是在进入人工代码审查前，以秒级/分钟级速度拦截明显的低级回归：
- Schema 与格式校验：验证 JSON 输出与工具调用参数是否 100% 符合预定义 Schema，一旦出现非法格式立即阻断 PR。
- 小规模冒烟测试集：运行 50～200 条覆盖核心高频意图与典型易错边界的黄金用例（按任务性质执行精确匹配或语义匹配）。
- RAG 核心组件速查：在小规模测试语料上快速计算上下文召回率、精确率与回答忠实度（如调用 RAGAS 指标）。
- 快速安全扫描：使用边界清晰的规则或轻量分类器扫描输入输出中的高危违规类别。
- 初步延迟与成本筛查：基于少量样本做耗时与单次 token 预算初筛（小样本下的 p95 估算仅作早期预警，正式发布前仍需开展大样本压测）。
第二层：合并前回归测试（Pre-Merge Regression）
目标是确认候选版本相较于基线（或当前线上生产版本）未出现超出容忍范围的质量退化：
- 中大规模标准数据集：在数百至数千条经人工校对或从线上日志提炼的回归用例上，横向对比候选版本与基线版本。
- 开放任务非劣效评判（LLM-as-a-Judge）：使用经过人类对齐校准的评判模型对比输出质量，要求满足预设的非劣效性（Non-inferiority）标准（例如候选版本的胜率下降不超过
1.5%；团队需提前明确百分比或百分点的计算口径）。 - 专项安全回归：跑通提示词注入、不当输出处理与工具越权调用测试集，一旦出现高危漏洞直接禁止合并。
- 多次采样平抑波动：对每条测试用例重复运行 NNN 次（CI 阶段采用较小的 NNN，Staging 阶段采用较大的 NNN），基于置信区间判定是否通过。
第三层：Staging 发布前完整验证（Pre-Release Staging）
在独立预发环境中运行耗时较长、不适合在每次 PR 提交时高频触发的重型测试：
- 万级生产日志离线回测：使用经过脱敏去标识化处理的数千至数万条真实历史生产查询（需覆盖长尾查询与多语种分组），按细分人群与场景分组对比基线表现。
- 真实并发与容量压测：模拟真实对话长度与工具调用链路开展高并发负载测试，采集与生产环境完全一致的遥测指标，检验 p95、p99 延迟与错误预算（Error Budget）。
- 深度红队对抗测试：运行针对越狱、间接注入与特定行业合规红线的红队攻击用例集，发现任何高严重性违规即刻叫停发布。
第四层：渐进式灰度发布检查（Canary Rollout）
目的是限制问题影响范围，并在在线信号正常时扩大流量。
- 金丝雀实时监控（Canary）：持续比对灰度分组与基线分组的错误率、超时率、p95 延迟、单次交互成本及在线质量信号（如抽样会话的评判模型胜率与用户点踩率）。
- 安全事件自动回滚：一旦安全护栏拦截率异常飙升并突破预设红线（如策略阻断率超过 X%X\%X%），自动将流量切回上一稳定版本。
- 在线非劣效放行：只要在线质量指标保持在非劣效容忍区间内，即可放行那些旨在降低推理成本或缩短延迟的架构优化版本，并逐步放大灰度比例至全量。
第五层：部署后持续评估
防范上游模型服务商静默更新、外部数据源漂移或随时间缓慢累积的质量退化：
- 夜间例行抽样回测：每晚从当天真实生产流量中轮换分层抽样，执行离线深度评估并与前一周的得分分布做对比。
- 线上分布漂移监控：持续跟踪提问主题分布、语种比例、检索相关性得分、token 消耗及安全审核触发率，偏离基准阈值时告警排查。
- 全量发布档案留存（可审计性）：完整归档每次上线对应的评估数据集版本、提示词整数版本、模型标识与评估报告。
工程实践建议与门禁标准
1. 应对生成随机波动的三种手段
可以采用以下三种方法。
- 重复运行取分布：每条测试样本运行 kkk 次（PR 取小 kkk、Staging 取大 kkk），依据通过率或平均分的置信区间做自动裁决；落入边界模糊灰色地带的结果转交人工复核。
- 固定采样参数与记录模型指纹：在接口支持时固定
seed与回归提示词；若模型服务商返回system_fingerprint等底层版本标识，需在日志中记录并在指纹变化时自动触发全量回归评估。 - 采用非劣效要求：许多变更只需确保退步没有超出可接受范围。
2. 制定代码化的发布门禁规则（示例参考值）
将发布标准编写为流水线强制执行的自动化策略（以下具体数值仅为教学参考示例，实际生产需结合业务风险等级、指标版本与数据集特征标定）：
- 安全红线：PR 阶段关键 OWASP 风险违规数为
0；Staging 阶段高危违规占比不超过0.05%（高风险写操作场景需设定更严苛的标准）。 - 结构化输出有效率：PR 核心测试集上 JSON Schema 与工具调用格式合法率达到
100%，Staging 大规模测试集上不低于99.9%。 - 封闭式标准答案任务：核心子集精确匹配率（Exact Match）不低于
90%，全集不低于85%。 - 开放式生成任务：评判模型（Judge）胜率的 95% 置信区间满足非劣效要求；人工盲测抽检至少 50 条样本，且人工评分与评判模型的一致率不低于
80%。 - RAG 核心指标：Staging 语料上的回答忠实度（Faithfulness）不低于
0.75、上下文精确率不低于0.60、上下文召回率不低于0.65（按垂直领域特性微调）。 - 延迟与成本 SLO：p95 端到端耗时与 TTFT 符合 SLO，单轮平均与 p95 token 消耗控制在预算内，错误率低于告警阈值。
- Canary 扩量条件：各项运行指标全部达标，累计满 NNN 次真实交互后的在线质量满足非劣效标准；若安全拦截事件异常激增则自动回滚。
上述门禁规则应纳入 Git 版本管理，并与代码仓库的分支保护策略（Branch Protection）、必过状态检查（Required Status Checks）及审批流绑定。
评估数据集维护：
- 黄金标准集：由人工精校维护并保持相对稳定，重点覆盖高业务价值场景与历史线上故障案例。
- 按细分子集切片报告：将超长提问、代码生成、多轮澄清、小语种与敏感话题划分为独立切片（Slices）分别出具指标报告，防止全局平均分掩盖局部严重退化。
- 日志回测：将生产追踪去标识化、分层抽样，并加入失败和险些失败的案例。
- 脱敏日志回流与冻结参考答案：定期从线上追踪日志中脱敏抽取真实失败或险些失败的样本补充进测试集；标准参考答案一经人工确认即应冻结，严禁在每次升级时用同一个待测模型自动重新生成参考答案。
LLM-as-a-Judge 偏差控制：
评估模型可以处理开放任务，但需要管理系统性评分倾向和随时间变化的问题。
- 保留一份小规模人工标注基准集，持续监控评判模型打分与人类判断的一致率。
- 对重要评测可采用两个不同模型（或不同提示词）双盲评判，出现分歧时交由第三模型或人工裁决。
- 完整记录评判模型的名称、提示词版本与参数，评判模型自身升级后必须重新校准。
- 优先采用成对优劣比较（Pairwise A/B Comparison），通常比缺乏固定标尺的开放式打分更稳定。
RAG 专项检查
RAG 的常见问题包括无关上下文、遗漏证据和编造细节，可以通过组件指标定位。
- 检索质量：上下文精确率衡量检索内容中有多少相关信息，召回率衡量所需证据是否被找到。
- 忠实度与依据：检查回答是否得到检索来源支持，减少无依据主张。
- 相关性与用途：检查回答是否切题并对用户有帮助。
RAGAS 提供常用开源指标实现。可以选择适合领域的部分指标，明确版本、测量方法和阈值。
符合生产情况的延迟与成本检查
在各阶段定义并执行预算。
- 延迟：检查 p95 TTFT 及到最后一个 token 的时间。聊天界面尤其需要关注 TTFT。
- Token 用量：限制每次交互输入与输出 token 总数的平均值和 p95，作为多数托管模型单位成本的参考。
- 吞吐量与并发：staging 使用真实 QPS 和并发度测试，扩缩容后仍未达到容量要求时阻止发布。
将评估接入发布流程
- 开发者修改提示词、模型配置、检索逻辑或安全策略并提交 PR。
- 自动触发第一层（快速 PR 检查）：校验 Schema、跑小规模黄金集、快速安全扫描及初步延迟成本检查，全部通过方可进入评审。
- 自动触发第二层（合并前回归）：跑大规模回归集与日志回测、计算 RAG 指标、执行安全测试与非劣效比对。
- 代码在功能开关（Feature Flag）保护下合并入主干，进入第三层（Staging 验证）：执行万级样本离线评估、高并发负载压测与深度红队测试。
- 开启第四层（Canary 灰度）：小流量上线并自动分析线上指标，达标则逐步放量，触发红线则自动回滚。
- 全量上线并转入第五层（持续监控）：每晚执行抽样回测与分布漂移监控。
每一步的检查规则都应明确、版本化并自动执行，人工集中处理接近判断边界或风险较高的结果。
常见问题与对应检查
- 现有标准测试集未能代表真实线上流量分布；需从生产日志脱敏回流样本，并按业务场景细分切片评估。
- 更换 embedding 模型后，线上响应延迟显著上升
- 上游模型服务商静默更新了模型权重或推理后端；需记录返回的具体模型标识或
system_fingerprint，并通过夜间持续回测及时捕获漂移。 - 工具变更漏跑了安全专项测试；所有新增或修改工具均必须先通过对应 OWASP 风险类别的安全红队测试方可进入发布。
- PR 阶段自动化检查结果忽过忽挂、极不稳定
将离线检查加入课程交付流程
在课程站点与示例工程的 CI 流水线中，使用 Bun 内置测试运行器与 Python fixture 回归测试协同验证：构建静态课程站点产物，并自动校验全部 34 条课程短路径与 68 条历史兼容路径。真实租户环境下的端到端验收在独立授权环境中执行，并将构建产物版本与评估记录分别归档。每当提示词、底层语料、评估数据集或模型配置发生变更时，均需触发对应层级的评估并留存失败样本。
练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。
对接口适配运行离线回归
CI 在构建服务器上安装已锁定版本的 Python 示例依赖，并通过 Bun 测试入口运行两组离线 fixture 回归；在生成课程静态站点产物后，自动校验短路径、兼容重定向入口、全局搜索索引、明暗主题切换与 SVG 图表完整性。CI 全程对所有外部调用均使用本地脱敏 fixture 隔离验证；云平台 RAM 身份、真实接口配额、账单计费、生产部署与真实租户权限则在实际目标环境中另行独立验收。
python3 -m venv .venv
.venv/bin/pip install -r examples/requirements-services.txt
bun install --frozen-lockfile
bun run typecheck
bun run build
bun test
bun run test:dependencies
bun run test:export
bun run test:client
bun run test:http每当外部服务接口发生变更时，需同步更新环境变量模板（.env.example）、请求与响应 fixture、异常错误分支、课程正文代码片段及配套 SVG 架构图；同时将模型名称、服务地域、提示词整数版本、数据集时间戳、语料 hash 与 SDK 版本号分别独立记录归档。