FDE W6D7 学习手册 · LLMOps 灰度 / AB / 回滚 / 漂移（设计）+ 整合
W6 Day7 · [A][C] 级（LLMOps 体系设计与整合）· 4h · 学完能讲清"特药理赔 Agent 从版本到回滚的完整 LLMOps 闭环，以及这些为何是'设计'不是'实作'"
本日定位：W6D2 讲了版本管理与评估集，今天把"版本 → 回归 → 灰度 → 监控 → 回滚"串成完整 LLMOps 体系。重点在设计（架构/流程/边界），不是手把手实作代码。理解这套版图，是用工程化语言讲清"如何安全地把模型变更交付到生产"。
学完能回答：① LLMOps 整体版图（版本/回归/灰度/监控/回滚）；② 为什么这些是"设计"不是"实作"、边界在哪、和前面实作部分怎么衔接；③ 灰度/AB/回滚/漂移分别解决什么问题。
使用方法：通读原理 → 重点看「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W6D7-评测题.md》。选中不熟的词可标注（左下★重要 / 右下📌待查）。候选人背景：36 岁，Java + 大数据 + 医疗保险，示例围绕特药理赔 Agent / 保险知识库。
一、LLMOps 整体版图：从版本到回滚的闭环
LLMOps（LLM Operations）是 MLOps 在 LLM/Agent 场景的延伸，关注"如何安全、可观测、可回归地把模型/提示词/知识库变更交付到生产并持续运维"。完整版图：
版本管理 → 回归测试 → 灰度发布 → 线上监控(漂移) → 自动回滚 → (回到版本管理，闭环)
| 阶段 | 解决什么 | 关键产出 |
|---|
| 版本管理 | 变更可追溯、可复现 | prompt/模型/知识库版本、评估基线（W6D2） |
| 回归测试 | 变更不引入退步 | 回归集 + 指标对比报告 |
| 灰度发布 | 小流量验证真实效果 | 金丝雀/分桶、流量切分 |
| 监控/漂移 | 线上持续可观测 | 质量/成本/延迟/漂移告警（Langfuse） |
| 自动回滚 | 出问题快速止血 | 回滚触发规则 + 一键回退 |
LLMOps 的本质是"给不确定的模型变更加工程化保险"。模型不像传统代码——同样输入可能不同输出、效果难靠单测保证，所以必须用"评估+灰度+监控+回滚"这套组合替代传统 CI/CD 的"测过就上线"。这是面试高频体系建设题。
LLMOps 版图：版本→回归→灰度→监控(漂移)→回滚→闭环。它解决"模型变更不确定、单测不够"的问题，用评估+灰度+监控+回滚替代传统 CI/CD 的"测过就上"。五阶段缺一个都可能把坏变更带进生产。
资源：Langfuse（https://langfuse.com）是开源 LLM 可观测/评估平台，覆盖 trace、评估、监控、prompt 版本；OWASP 提供 LLM/Agent 安全风险参考。本日"设计"可映射到这些工具的定位。
二、版本管理回顾（W6D2）：LLMOps 的起点
版本管理是闭环起点。LLM 系统的"版本"不止模型权重，还包括：
- Prompt 版本：系统提示词、few-shot 模板的版本（高频变更）。
- 模型版本：基础模型/微调版本的 tag（如 qwen2.5-72b@20260701）。
- 知识库版本：RAG 索引/Chunk 集合的版本（对应 W3 知识库）。
- Agent 配置版本：工具集、参数、审批规则。
每个版本要能：回溯、对比、一键切换。这正是 W6D2 评估集的"基线"所在——版本变更前后都要跑同一评估集，得到可比指标。
版本管理的工程要点：①所有可变更项纳入版本控制（不只是代码，还有 prompt/知识库）；②变更带元数据（谁、何时、为何）；③保留评估基线快照，回滚时能定位"回哪个版本、基线是多少"。Java 侧可类比配置中心（如 Nacos）的版本与回滚。
版本管理是 LLMOps 起点。版本对象包括 prompt/模型/知识库/Agent 配置（不止权重）。每个版本要能回溯/对比/切换，且变更前后跑同一评估集得可比指标（W6D2 基线）。核心：一切可变项都版本化 + 带元数据 + 留评估基线。
三、回归测试：变更不引入退步
回归测试 = 在变更后跑固定的回归集，对比新旧版本指标，确认没有"这里好了那里坏了"。
- 回归集来源：历史评测集（W6D2）+ 线上 badcase 沉淀 + 边界 case。
- 对比维度：准确率、拒答率、幻觉率、成本、延迟、合规性（W6D5）。
- 门禁（Gate）：回归指标低于阈值则阻断发布，不让坏变更进灰度。
- 示例：新提示词让"拒赔准确率"升了，但"材料缺失识别率"降了 3%——回归门禁拦截，要求修复后再发。
回归测试是"质量门禁"。工程上要自动化（CI 触发跑回归集）、要可解释（哪条 case 退步了、为什么）。它和 W6D2 的评估集是同一套资产，区别：评估集用于"衡量水平"，回归集用于"防退步"。
回归测试=变更后跑固定回归集，对比新旧指标，防"这里好那里坏"。回归集=历史评测集+线上 badcase+边界 case；有门禁，指标低于阈值就阻断发布。它和 W6D2 评估集同源，区别在于评估集"衡量水平"、回归集"防退步"。
① 回归集不能"写完就不动"——线上新 badcase 要持续补充，否则回归集会陈旧、漏掉新风险。② 别只看平均分，要分层看（如"拒赔类"是否退步），整体涨了可能掩盖细分退步。③ 回归通过≠线上没问题，回归集是样本，真实分布更广，所以还要灰度验证。
四、灰度发布（金丝雀 Canary）
灰度 = 变更先放小比例流量/特定用户群，观察真实效果，再逐步放大到全量。
| 策略 | 做法 | 适用 |
|---|
| 按流量比例 | 1% → 5% → 20% → 100% | 通用，风险均匀 |
| 按用户分桶 | 按 user_id hash 固定分桶 | 需用户体验一致（同一人总在同一版本） |
| 按租户/白名单 | 先放内部租户或试点客户 | 多租户（如先放低风险租户验证） |
| 金丝雀 | 极小流量先探，异常即停 | 重大变更首发 |
- 为什么灰度：回归集是样本，线上才是真实分布；灰度用真实流量低成本试错。
- 切流一致性：同一用户会话内不能来回切版本（否则体验割裂、记忆混乱），按 user_id 分桶最稳。
- 示例：理赔 Agent 新版提示词先放 5% 内部测试租户，监控拒赔准确率 24h 无异常再放大。
灰度是"用生产流量做最后验证"。工程要点：①分桶一致性（user_id hash）；②灰度与监控联动（异常自动刹车）；③多租户场景先放低风险租户。这和你做 Java 服务灰度发布（如 Nginx 权重、K8s 金丝雀）思路完全一致，只是对象多了 prompt/模型版本。
灰度=小流量/特定群先放，观察真效再放大。策略：流量比例、用户分桶（user_id hash 保证体验一致）、租户/白名单（多租户先放低风险）、金丝雀（极小流量探路）。为什么灰度：回归集是样本，线上才真实，灰度用真流量低成本试错。
五、A/B 测试：对比两个版本的真实效果
A/B 测试把流量随机分成 A（对照/旧版）和 B（实验/新版），在同一时段跑，统计对比业务指标，判断 B 是否真更好。
- 和灰度的区别：灰度是"逐步放量验证安全"，A/B 是"两版并行比优劣"。灰度关注"别炸"，A/B 关注"谁更好"。
- 指标：不仅准确率，还有业务指标（理赔通过率、用户满意度、人工接管率、成本/次）。
- 显著性：样本要够大才有统计显著，否则"B 好 1%"可能只是噪声。
- 陷阱：指标冲突（B 更准但更贵/更慢），要综合权衡，不能只看单指标。
A/B 测试是"用数据决策"而非"拍脑袋"。工程上要有分流器（保证随机+可归因）、统一埋点、统计显著阈值。对保险场景，A/B 还能验证"新版是否更少误拒（保护客户）同时不增风险"。
A/B=流量随机分 A(旧) B(新)并行跑，比业务指标判优劣。与灰度区别：灰度"别炸"（安全），A/B"谁更好"（优劣）。指标含业务侧（通过率/满意度/接管率/成本）。注意统计显著性和指标冲突权衡。
① A/B 和灰度常被混用——灰度是放量验证安全性，A/B 是对比优劣，目标不同，流程不同。② "B 准确率高一点的"不一定该全量——可能更慢更贵，要综合成本/延迟/风险。③ 样本不足就下结论会误判，需统计显著。
六、自动回滚：出问题快速止血
回滚 = 当线上指标异常（质量跌、错误率升、成本爆、合规告警），自动或一键切回稳定旧版本。
- 触发条件：监控告警（见 s7）命中规则，如"拒赔准确率 5 分钟跌超 5%"或"幻觉率超阈值"。
- 自动 vs 手动：明确、可量化的异常可自动回滚；模糊的需人工确认（避免误回滚）。
- 回滚对象：切 prompt/模型/知识库版本，不一定是整服务——细粒度回滚更快。
- 示例：新版知识库索引导致"材料识别率"骤降，监控触发，自动切回旧索引版本并告警。
监控告警 → 命中回滚规则 → 切回 last-known-good 版本 → 保留现场(trace/日志)供复盘 → 通知人工
回滚是"安全网"。设计要点：①始终保留 last-known-good 版本和基线指标（呼应 s2）；②回滚要快（秒级切版本，不重发版）；③回滚后保留现场供复盘，别直接抹掉。这和 W6D6 记忆回滚（清记忆+回版本）是同一"回退"思想。
回滚=线上异常时切回稳定旧版止血。触发：监控告警命中规则（准确率跌/错误率升/成本爆/合规告警）。明确异常可自动回滚，模糊的需人工。回滚要细粒度（切 prompt/知识库而非整服务）、要快、要留现场复盘。呼应 W6D2 基线与 W6D6 回退。
七、漂移监控（Drift Monitoring）
模型上线后，输入分布或期望输出会随时间变化，导致效果悄悄退化——这叫漂移。监控就是持续盯这些信号。
| 漂移类型 | 含义 | 特药理赔示例 |
|---|
| 数据漂移（Data Drift） | 输入分布变了 | 新特药品种上市，问题分布变 |
| 概念漂移（Concept Drift） | 输入→输出的关系变了 | 理赔政策更新，旧答案变错 |
| 模型漂移（Model Drift） | 模型本身版本/行为变 | 厂商静默更新底层模型 |
| 提示漂移（Prompt Drift） | prompt 被改导致行为变 | 有人改了系统提示未走流程 |
- 监控信号：输出质量（用线上评估/LLM-as-judge）、延迟、成本、拒答率、用户反馈、合规告警（W6D5）。
- 工具：Langfuse 的 trace + 线上评估、成本/延迟面板、漂移告警。
- 联动：漂移告警 → 触发回滚或触发新一轮回归+灰度。
漂移监控是"闭环的眼睛"。LLM 没有"训练完就固定"的好事——政策、病种、模型供应商都会变。设计上要把线上评估（LLM-as-judge 跑样本）常态化，而不是只靠人工抽查。Java 侧类比：业务指标监控（Prometheus/Grafana）的思路平移到 LLM 指标。
漂移=输入/输出分布随时间变化导致效果退化。四类：数据漂移（输入分布变）、概念漂移（映射关系变，如政策更新）、模型漂移（底层模型变）、提示漂移（prompt 被改）。监控信号：质量/延迟/成本/拒答率/反馈/合规告警。工具 Langfuse，告警联动回滚。
① 漂移是"慢性病"——不会瞬间炸，但会悄悄让准确率从 95% 滑到 80%，所以必须持续监控而非上线即不管。② 别只监控延迟/成本（容易量化），更要监控"质量漂移"（用线上评估/LLM-as-judge），否则成本正常但答案已烂。③ 概念漂移往往源于业务变化（政策更新），需和知识库版本同步。
八、发布审批（审批门禁）
在灰度放大/全量发布前，设审批门禁：满足一系列条件 + 相关人确认，才允许推进。
- 准入条件：回归通过、安全扫描（W6D5 OWASP）、合规检查、监控基线正常。
- 审批人：研发负责人 + 业务/合规代表（保险场景合规必签）。
- 与 Human Approval 关系：W6D5 的 Human Approval 是"Agent 运行时对动作审批"，这里是"发布流程对版本审批"——同属"人把关"，但层面不同（运行 vs 交付）。
- 示例：理赔 Agent 新版要全量，需过回归门禁 + 安全扫描 + 合规签字，三关过了才放量。
审批门禁把"质量/安全/合规"固化进交付流程，避免"研发脑热直接全量"。它是 LLMOps 闭环的"人工确认点"，和 W6D5 Human Approval、W6D6 关键记忆审批一脉相承——都是"高风险动作让人确认"。
发布审批=灰度放大/全量前的门禁：回归通过+安全扫描+合规检查+监控正常，且相关人（研发+业务+合规）确认。和 W6D5 Human Approval 同源但层面不同：Human Approval 是"运行时对动作批"，发布审批是"交付流程对版本批"。都是"高风险让人确认"。
九、完整 LLMOps 闭环：五阶段如何串起来
把前面串成一条线，理解"为什么是闭环"：
① 版本管理（prompt/模型/知识库版本化，留基线）
→ ② 回归测试（跑回归集，门禁拦截退步）
→ ③ 灰度发布（小流量验证真实效果）
→ ④ 监控/漂移（线上持续盯质量/成本/合规）
→ ⑤ 自动回滚（异常切回稳定版，留现场复盘）
→ 复盘驱动新版本（回到 ①，闭环）
- 闭环动力：监控发现漂移/线上 badcase → 沉淀进回归集 → 开新版本 → 再走回归/灰度。
- 每阶段产出喂给下一阶段：版本给回归基线、回归给灰度准入、灰度给监控对比、监控给回滚依据。
- 示例：线上发现"新版漏判材料造假"（监控/用户反馈）→ 沉淀 badcase 进回归集 → 修 prompt 开 v3 → 回归过 → 灰度 5% → 监控 OK → 放量。中间若灰度异常 → 自动回滚 v2。
闭环：版本(留基线)→回归(门禁防退步)→灰度(小流量试真效)→监控(持续盯质量/漂移)→回滚(异常切稳定版留现场)→复盘开新版本。动力是"监控/badcase 驱动回归集更新→新版本→再走流程"。每阶段产出喂下阶段，缺一环就断。
十、为什么这些是"设计"不是"实作"：边界在哪
本日定位是设计——讲架构、流程、边界、决策，不写具体 YAML/脚本。区分：
| 维度 | "设计"（本日） | "实作"（前面几天） |
|---|
| 关注 | 流程/边界/取舍/责任划分 | 具体代码/配置/调参 |
| 产出 | 发布流程定义、回滚规则、监控指标清单 | 可用的 RAG/Agent/评估脚本 |
| 例子 | "灰度按租户分桶、异常自动回滚" | W6D2 写评估集、W4 写 HITL 代码 |
| 考察 | 你能设计体系、讲清 why | 你能落地、讲清 how |
- 边界：设计回答"要有什么阶段、各自解决什么、怎么衔接、出问题谁负责"；实作回答"具体怎么写、怎么调、怎么测"。
- 为什么分两层：面试考察的是"体系化思维"——能把零散的 prompt 调优、RAG、评估串成可交付的工程体系，而不是只会写单点代码。
- 衔接：前面实作（W6D2 评估集、W4 HITL、W6D5 安全、W6D6 记忆）都是这个体系里"被管理和被保护的对象"。设计层决定"它们怎么安全地进生产、出问题怎么回退"。
理解"设计 vs 实作"是资深候选人的分水岭。你能写 RAG（实作），也能讲清"RAG 知识库版本如何灰度+监控+回滚"（设计），才是 FDE 想要的"体系 owner"。本日所有内容都应是"可画成架构图、可讲清取舍"的级别。
设计=流程/边界/取舍/责任（产出：发布流程、回滚规则、监控清单）；实作=代码/配置/调参（产出：可用的 RAG/Agent/脚本）。边界：设计讲"要什么阶段、怎么衔接、谁负责"，实作讲"具体怎么写"。前面 W6D2 评估/W4 HITL/W6D5 安全/W6D6 记忆都是被这个体系管理和保护的对象。
① 面试别把"设计"答成"我要写个脚本"——设计层讲架构与决策，不是写代码。② 也别只飘在概念——能结合前面实作（如"灰度验证的就是 W6D2 评估集覆盖的场景"）才显扎实。③ 边界不清会被追问："你说自动回滚，那回滚的具体对象是什么、怎么保证秒级？"——设计也要想到落地接口。
十一、工具在 LLMOps 版图里的位置（Langfuse / OWASP）
| 阶段 | 工具/能力 | 作用 |
|---|
| 版本管理 | 配置中心 / Langfuse Prompt 版本 | prompt/配置版本化、回溯 |
| 回归/评估 | W6D2 评估集 + Langfuse 评估 | 跑回归、出指标报告 |
| 灰度/AB | 网关分流 / 特征分桶 | 流量切分、随机分流 |
| 监控/漂移 | Langfuse trace + 线上评估 + Grafana | 质量/成本/延迟/漂移告警 |
| 回滚 | 版本切换（配置中心/Prompt 版本） | 切回 last-known-good |
| 安全合规 | OWASP LLM Top 10 / Agentic | 发布前安全扫描、运行时防护 |
把工具映射到版图，能体现"我不只是会调模型，我知道每个能力该落在体系哪一层"。Langfuse 覆盖 trace/评估/监控/prompt 版本，是 LLMOps 的核心可观测中枢；OWASP 是安全维度的对照清单。面试提到具体工具名 + 它在版图的位置，比泛泛说"用平台"专业得多。
工具映射版图：版本→配置中心/Langfuse Prompt 版本；回归→W6D2 评估集+Langfuse 评估；灰度/AB→网关分流；监控→Langfuse trace+线上评估+Grafana；回滚→版本切换；安全→OWASP。Langfuse 是可观测中枢，OWASP 是安全对照。提工具名+它在版图的位置最专业。
十二、与前面实作部分的衔接（完整 W6 回顾）
把 W6 整周串起来，看 LLMOps 体系如何"罩住"所有实作：
| 前面实作 | 在本 LLMOps 体系中的角色 |
|---|
| W6D2 版本管理 + 评估集 | 闭环起点：版本化 + 回归基线 |
| W4 HITL / W6D5 Human Approval | 运行时护栏，也是"发布审批"的运行期对应 |
| W6D5 脱敏/隔离/审计 | 发布前安全扫描 + 运行时防护的合规底座 |
| W6D6 Memory 生命周期 | 被监控/回滚保护的对象（记忆漂移、记忆回退） |
| 本日 W6D7 | 把以上串成"版本→回归→灰度→监控→回滚"闭环 |
一句话总结 W6：前几天的点是"做实作"，W6D7 是"把它们织成可交付、可运维、可回退的体系"。FDE 面试想要的是后者——能用工程化语言讲清"我的 Agent 怎么安全地从开发到生产再到持续运维"。
W6 衔接：W6D2 版本/评估=闭环起点；W4 HITL/W6D5 Human Approval=运行时护栏+发布审批对应；W6D5 脱敏隔离审计=发布前扫描+运行时合规底座；W6D6 Memory=被监控/回滚保护的对象；W6D7=把一切织成闭环。前几日是"做实作"，本日是"织成体系"。
十三、面试达标线①：LLMOps 整体版图
版本管理 → 回归测试(门禁) → 灰度发布(分桶/金丝雀) → 监控/漂移(质量/成本/合规) → 自动回滚(切 last-known-good) → 闭环复盘
| 阶段 | 一句话 | 解决 |
|---|
| 版本管理 | prompt/模型/知识库版本化留基线 | 可追溯、可复现、可对比 |
| 回归测试 | 跑回归集，门禁防退步 | 变更不引入退步 |
| 灰度发布 | 小流量/分桶验证真效 | 用真实流量低成本试错 |
| 监控/漂移 | 持续盯质量/成本/合规漂移 | 发现慢性病式退化 |
| 自动回滚 | 异常切回稳定版留现场 | 快速止血 |
核心版图五阶段：版本(留基线)→回归(门禁防退步)→灰度(分桶试真效)→监控(盯质量/漂移)→回滚(切稳定版)。能画成闭环图、讲清每阶段产出喂下阶段，并点出"模型不确定，所以用这套替代传统 CI/CD"即达标。
十四、面试达标线②：设计 vs 实作边界，及与前面实作衔接
- 设计的定义：关注流程/边界/取舍/责任划分，产出"发布流程、回滚规则、监控清单"等，讲清 why。
- 实作的定义：关注具体代码/配置/调参，产出可用系统，讲清 how。
- 边界：设计回答"要什么阶段、怎么衔接、谁负责、异常怎么办"；实作答"具体怎么写、怎么调、怎么测"。设计也要想到落地接口（如回滚对象、秒级切换）。
- 衔接：W6D2 评估集（回归基线）、W4 HITL/W6D5 Human Approval（运行护栏+发布审批对应）、W6D5 脱敏隔离审计（发布前扫描+运行时合规）、W6D6 Memory（被监控/回滚保护）——都是本体系"管理和保护的对象"。
- 价值：能写 RAG 是实作，能讲清"RAG 知识库版本如何灰度+监控+回滚"才是体系 owner，这正是 FDE 想要的。
设计=流程/边界/取舍（讲 why，产出流程/规则/清单）；实作=代码/配置（讲 how，产出系统）。边界：设计讲"要什么阶段、怎么衔接、谁负责"，实作讲"怎么写"。衔接：W6D2 评估是回归基线、W6D5 安全是发布扫描、W6D6 Memory 是被保护对象——本日把它们织成闭环。能写 RAG + 能讲清其灰度回滚 = 体系 owner。
十五、W6D7 自测清单
- 能画出 LLMOps 闭环五阶段（版本→回归→灰度→监控→回滚）并说明每阶段解决什么。
- 能说清版本管理管的不只是模型权重，还有 prompt/知识库/Agent 配置。
- 能区分回归测试和 W6D2 评估集（防退步 vs 衡量水平），并说明回归门禁。
- 能说出灰度发布的 4 种策略，及为什么按 user_id 分桶保证体验一致。
- 能区分灰度（别炸）和 A/B（谁更好），并说明 A/B 的显著性/指标冲突陷阱。
- 能讲清自动回滚的触发条件、自动 vs 手动、回滚对象（细粒度）、留现场复盘。
- 能说出 4 类漂移（数据/概念/模型/提示）及监控信号（质量/成本/合规）。
- 能说明漂移是"慢性病"，必须持续监控质量而非只看延迟成本。
- 能讲清发布审批门禁（回归+安全+合规）及与 W6D5 Human Approval 的层面区别。
- 能讲清"设计 vs 实作"的边界，并说明本日为什么是设计层。
- 能把 Langfuse / OWASP 映射到版图各阶段的位置。
- 能把 W6D2/W4/W6D5/W6D6 实作衔接进本 LLMOps 体系，讲清"被管理和保护的对象"。
- 能讲清两条达标线（整体版图、设计 vs 实作边界与衔接）。
十六、高频面试题速记卡
Q：LLMOps 和传统 MLOps/CI-CD 什么关系？
LLMOps 是 MLOps 在 LLM/Agent 的延伸。因模型输出不确定、单测不够，用"评估+灰度+监控+回滚"替代传统"测过就上线"。
Q：LLMOps 五阶段一句话？
版本(留基线)→回归(门禁防退步)→灰度(分桶试真效)→监控(盯质量/漂移)→回滚(切稳定版)，闭环复盘。
Q：灰度和 A/B 测试区别？
灰度关注"别炸"（安全放量验证），A/B 关注"谁更好"（两版并行比业务指标）。目标和流程都不同。
Q：漂移有哪几种？
数据漂移（输入分布变）、概念漂移（映射关系变，如政策更新）、模型漂移（底层模型变）、提示漂移（prompt 被改）。
Q：自动回滚触发什么、回滚什么？
触发监控告警（准确率跌/错误率升/成本爆/合规告警）。回滚切 prompt/模型/知识库版本（细粒度、秒级），并留现场复盘。
Q：为什么漂移监控不能只看延迟/成本？
那是"易量化但非核心"。更要盯质量漂移（用线上评估/LLM-as-judge），否则成本正常但答案已烂，慢性退化。
Q：发布审批和 W6D5 Human Approval 区别？
Human Approval 是运行时对 Agent 动作审批；发布审批是交付流程对版本审批。同属"人把关"，层面不同（运行 vs 交付）。
Q：本日为什么是"设计"不是"实作"？
设计讲流程/边界/取舍（why，产出流程/规则/清单）；实作讲代码/配置（how，产出系统）。设计也要想到落地接口。
Q：Langfuse 在版图里干什么？
可观测中枢：prompt 版本管理、trace、线上评估、成本/延迟监控、漂移告警，覆盖版本/回归/监控多阶段。
Q：前面几天实作和本日体系怎么衔接？
W6D2 评估=回归基线；W6D5 安全=发布前扫描+运行时合规底座；W6D6 Memory=被监控/回滚保护对象；本日把它们织成闭环。
FDE W6D7 学习手册 · LLMOps 灰度/AB/回滚/漂移（设计）+ 整合（面试级）· 配合《FDE-W6D7-评测题.md》自测
📌 待查★ 重要