# FDE W6D7 评测题 · LLMOps 灰度 / AB / 回滚 / 漂移（设计）+ 整合
> 配套《FDE-W6D7-LLMOps灰度回滚与整合-学习手册.html》使用。共 13 题，分 L1 基础 / L2 进阶 / L3 深度 / L4 场景四档。
> 评分建议：每题按"考察点达成度"给 0–5 分，见末尾评分汇总表与达标线。
> 场景背景统一为：某保险科技公司，搭建"特药理赔 Agent"，服务多家保险公司（多租户），需要把模型/prompt/知识库变更安全交付到生产并持续运维。
---
## L1 基础（概念识别，能说清"是什么"）
### Q1. 什么是 LLMOps？它和传统 CI/CD 的核心区别是什么？
- **考察点**：LLMOps 定位。
- **评分维度**：能否点出"评估+灰度+监控+回滚替代测过就上线"；是否说明模型输出不确定。
参考答案
LLMOps 是 MLOps 在 LLM/Agent 场景的延伸，关注如何安全、可观测、可回归地把模型/prompt/知识库变更交付到生产并持续运维。和传统 CI/CD 的核心区别：模型输出不确定（同样输入可能不同输出、效果难靠单测保证），所以不能用"测过就上线"，而要用"评估+灰度+监控+回滚"这套组合做工程化保险。
参考答案
五阶段：①版本管理（变更可追溯/可复现，留基线）；②回归测试（门禁防退步）；③灰度发布（小流量验证真实效果）；④监控/漂移（持续盯质量/成本/合规，发现慢性病式退化）；⑤自动回滚（异常切回稳定版快速止血）。回到版本管理形成闭环。每阶段产出喂给下一阶段。
参考答案
不止模型权重。LLM 系统的版本对象包括：prompt 版本（系统提示、few-shot 模板，最高频）、模型版本（基础/微调 tag）、知识库版本（RAG 索引/Chunk 集合）、Agent 配置版本（工具集/参数/审批规则）。核心原则：一切可变项都纳入版本控制，且带元数据和评估基线快照，支持回溯/对比/一键切换。
参考答案
漂移指模型上线后，输入分布或期望输出随时间变化，导致效果悄悄退化。类型：①数据漂移——输入分布变了（新特药品种上市，问题分布变）；②概念漂移——输入到输出的映射关系变了（理赔政策更新，旧答案变错）；③模型漂移——底层模型被供应商静默更新；④提示漂移——prompt 被改导致行为变。漂移是"慢性病"，需持续监控。
参考答案
同源资产（同一套评测数据），用途不同：评估集用于"衡量模型水平"，回归集用于"防止变更引入退步"。回归测试在变更后跑固定回归集，对比新旧指标；回归门禁设定阈值，指标低于阈值则阻断发布，不让坏变更进灰度。回归集要持续补充线上 badcase，且要分层看（如"拒赔类"是否退步），不能只看平均分。
参考答案
策略：①按流量比例（1%→5%→20%→100%）；②按用户分桶（user_id hash 固定分桶）；③按租户/白名单（先放内部/低风险租户，多租户适用）；④金丝雀（极小流量先探，异常即停）。强调 user_id 分桶：同一用户会话内不能来回切版本，否则体验割裂、且 Agent 记忆（W6D6）会混乱；按 user_id hash 保证同一人总在同一版本，体验一致。
参考答案
区别：灰度是"逐步放量验证安全"（关注别炸），A/B 是"两版并行比优劣"（关注谁更好），目标和流程不同。A/B 陷阱：①统计显著性——样本不足时"B 好 1%"可能只是噪声，需足够量；②指标冲突——B 更准但更慢更贵，不能只看单指标，要综合成本/延迟/风险权衡；③指标要含业务侧（通过率/满意度/接管率）。
参考答案
触发：监控告警命中规则（如拒赔准确率 5 分钟跌超 5%、幻觉率超阈值、成本爆、合规告警）。回滚对象：切 prompt/模型/知识库版本（细粒度，比整服务回滚快），依赖 last-known-good 版本和基线（呼应 W6D2）。留现场：回滚后保留 trace/日志供复盘，别直接抹掉——否则无法定位根因、无法改进回归集。明确异常可自动回滚，模糊的需人工确认防误回滚。
参考答案
信号：输出质量（线上评估/LLM-as-judge）、延迟、成本、拒答率、用户反馈、合规告警（W6D5）。不能只看延迟/成本：那是最易量化但非核心的，且"成本正常但答案已烂"完全可能——漂移是慢性病，会悄悄让准确率从 95% 滑到 80% 而不炸。必须持续监控"质量漂移"，用线上评估常态化，而非只靠人工抽查。概念漂移常源于业务变化（政策更新），需和知识库版本同步。
参考答案
发布审批门禁条件：回归通过、安全扫描（W6D5 OWASP）、合规检查、监控基线正常，且相关人确认（研发+业务+合规，保险场景合规必签）。和 W6D5 Human Approval 关系：同属"高风险动作让人确认"的思想，但层面不同——Human Approval 是"Agent 运行时对动作审批"（如拒赔），发布审批是"交付流程对版本审批"。两者一脉相承，都是体系里的"人工确认点"。
参考答案
设计关注流程/边界/取舍/责任划分，产出"发布流程、回滚规则、监控清单"，讲清 why；实作关注具体代码/配置/调参，产出可用系统，讲清 how。边界：设计回答"要什么阶段、怎么衔接、谁负责、异常怎么办"，实作答"具体怎么写、怎么调、怎么测"。注意：设计也要想到落地接口（如回滚对象是什么、怎么秒级切换），否则会飘在概念；但也不能答成"我要写个脚本"——那是实作层。
参考答案
Langfuse（可观测中枢）映射：版本管理（Prompt 版本）、回归/评估（跑评估集出指标）、监控/漂移（trace + 线上评估 + 成本/延迟面板 + 告警）、回滚（版本切换）。OWASP 映射：安全合规维度，发布前安全扫描（LLM Top 10/Agentic）+ 运行时防护（W6D5）。提工具名 + 它在版图的位置，比泛泛说"用平台"专业——体现"每个能力落在体系哪一层"的体系化思维。
参考答案
设计：①版本——prompt/模型/知识库/Agent 配置全版本化，带元数据+评估基线。②回归——跑回归集（历史+线上 badcase），门禁拦截退步（如拒赔准确率跌则阻断）。③灰度——多租户下先放低风险内部租户/试点客户，按 user_id 分桶保证体验一致，1%→5%→20%→100% 放量。④监控——Langfuse trace+线上评估盯质量漂移、成本、合规告警（W6D5），概念漂移（政策更新）联动知识库版本。⑤回滚——监控告警触发切回 last-known-good 版本（细粒度切 prompt/知识库），留现场复盘。合规审批：灰度放大前过回归+安全扫描（OWASP）+合规签字三关。衔接：W6D2 评估集=回归基线；W4 HITL/W6D5 Human Approval=运行时护栏+发布审批对应；W6D5 脱敏/隔离/审计=发布前扫描+运行时合规底座；W6D6 Memory=被监控/回滚保护的对象（记忆漂移、记忆回退）。优先级：最该优先设计**监控+回滚**（安全网）——版本/灰度再好，没有监控发现和回滚止血，坏变更一旦全量就是生产事故；且监控也是驱动闭环复盘的数据源。