# FDE W6D2 评测题 · LLMOps 版本管理

> 配套《FDE-W6D2-LLMOps版本管理-学习手册.html》使用。共 13 题，分 L1 基础 / L2 进阶 / L3 深度 / L4 场景。
> 候选人背景：36 岁，Java + 大数据 + 医疗保险方向；示例围绕特药理赔 Agent / 保险知识库。
> 建议：先独立完成，再展开参考答案；用"评分维度"自检是否答到面试级深度。

---

## L1 基础（概念识别，4 题）

### Q1. 为什么 LLM 应用不能只靠 Git 做版本管理？它比传统应用多了哪几类要管的资产？
- **考察点**：识别 LLM 应用特有的"行为资产"。
- **评分维度**：① 是否点出四类资产（Prompt/模型配置/Embedding/评测集）；② 是否说明它们"变化快、看 diff 看不出效果"；③ 是否引出版本化三诉求（回滚/对比/审计）。
<details>
<summary>参考答案</summary>

传统代码有 Git，但 LLM 应用还有四类决定行为的"软资产"：Prompt（自然语言，效果靠评测才知道）、模型配置（model/temperature 等）、Embedding 版本（换版本向量空间变）、评测集（标尺本身）。它们变化频繁、Git diff 看不出好坏，所以要额外版本化，目标是可回滚、可对比、可审计。
</details>

### Q2. LLM 应用版本管理要达成哪三个核心诉求？各自解决什么问题？
- **考察点**：回滚/对比/审计的定义与价值。
- **评分维度**：① 是否准确说出三个词；② 每个是否对应到"解决什么"；③ 是否联系金融/保险场景。
<details>
<summary>参考答案</summary>

可回滚（坏改动秒回已知好版本，避免持续错赔）、可对比（改动效果靠数据证明而非感觉，说服业务/审计）、可审计（金融合规要追溯每次决策用的版本与结果）。三者是发布工程成熟度标志，保险场景缺任何一个都会出事故或违规。
</details>

### Q3. 什么是"一键离线回归"？它产出的核心是什么？
- **考察点**：回归概念。
- **评分维度**：① 是否说出"给定新版本自动跑全量评测集"；② 是否点出"与基线指标 diff"；③ 是否提到"分层指标门禁"。
<details>
<summary>参考答案</summary>

一键回归 = 给定新 Prompt/配置版本，自动跑全量评测集，产出与上一版的指标对比（A/B）报告，并对分层指标设门禁：任何核心指标退化（如漏判率升高、完成率降）自动拦截发布。核心是结果可复现、退化可拦截。
</details>

### Q4. Embedding 模型换版本为什么是"高影响低频率"操作？
- **考察点**：Embedding 版本风险。
- **评分维度**：① 是否说明向量空间变、旧向量失效；② 是否强调全量重嵌+重建索引；③ 是否点出"新旧混库"灾难。
<details>
<summary>参考答案</summary>

Embedding 决定向量空间，换版本后旧向量全部失效，必须全量重嵌+重建索引，否则检索结果错乱。最怕"库里新旧向量混用"，余弦相似度直接失真。属高影响低频率变更，要重跑 RAG 评测并与 Prompt/模型绑成发布单元。
</details>

---

## L2 进阶（机制理解，4 题）

### Q5. Prompt 版本为什么要是"内容 + 元数据 + 评测快照"三位一体？模板与变量为什么要分离？
- **考察点**：Prompt 版本工程实践。
- **评分维度**：① 是否解释元数据（谁/何时/为什么改）；② 是否说明评测快照用于回滚时整体恢复；③ 模板变量分离的理由（变量不影响版本、易测试）。
<details>
<summary>参考答案</summary>

元数据记录创建人/时间/改进目标，便于审计与追溯；评测快照关联该版本的指标结果，回滚时不仅回文本还要回"已知好状态"。模板与变量分离：系统提示写成模板，运行时填用户问题/检索片段，模板进版本管理、变量不参与版本，这样回归可覆盖典型变量组合而不污染源。
</details>

### Q6. 评测集本身为什么要版本化？"标尺变了导致变好"的假象怎么避免？
- **考察点**：评测集版本化。
- **评分维度**：① 是否把评测集比作"标尺"；② 是否说明两次对比须同版本才有意义；③ 是否给出"评测集升级导致完成率降时，要能区分标尺变严 vs Prompt 变差"。
<details>
<summary>参考答案</summary>

评测集是标尺，若标尺在变，"变好"可能是假象。两次 Prompt 对比必须用同一评测集版本。若评测集也升级（加更难 case）导致完成率下降，要能区分是"标尺变严"还是"Prompt 变差"——靠评测集版本记录与双向追溯。评测集只能加难不能偷减 case 刷分。
</details>

### Q7. A/B 回归报告里，哪些指标必须"置顶"？为什么分层 Δ 不能省？
- **考察点**：报告设计。
- **评分维度**：① 是否置顶高风险漏判率（一票否决）和单任务成本 P95；② 是否说明分层 Δ 用于定位退化层；③ 是否提到"退化样本清单"用于复盘。
<details>
<summary>参考答案</summary>

高风险漏判率（一票否决，0→正必须醒目）和单任务成本 P95（经济性）置顶；各分层（Smoke/功能/边界/对抗）Δ 不能省，因为总分可能"平均"掉某子指标退化——分层才能定位退化在哪类 case。还要附"从对变错"的样本清单供定性复盘。
</details>

### Q8. 为什么每次运行（评测/生产）都要存 Trace？Trace 至少承载哪四种作用？
- **考察点**：Trace 价值。
- **评分维度**：① 是否列出复盘/成本归因/合规审计/飞轮燃料；② 是否点出保险合规追溯决策链路；③ 是否提敏感数据脱敏。
<details>
<summary>参考答案</summary>

Trace 记录完整输入/tool_call/中间态/输出/token/成本/耗时，承载：① 复盘（还原当时决策）；② 成本归因（哪类任务烧最多）；③ 合规审计（监管追溯某笔理赔决策链路）；④ 飞轮燃料（错误 Trace 进错误池）。保险场景含用户隐私，Trace 须脱敏+权限控制。
</details>

---

## L3 深度（设计/辨析，3 题）

### Q9. 一键回归要可复现，具体要"锁"住哪些东西？如果没锁会怎样？
- **考察点**：回归可复现性细节。
- **评分维度**：① 是否列出锁 Prompt 版本、模型配置版本、评测集版本；② 是否说明不锁则 diff 不可信；③ 是否提到批处理+限流（防烧钱/限流）。
<details>
<summary>参考答案</summary>

要锁：新 Prompt 版本 + 模型配置版本（model/temperature 等）+ 同一评测集版本，三者固定结果才可比。没锁的后果：生产用 A 模型、评测用 B 模型，"通过"无意义；评测集偷偷变了，diff 是假象。另外全量跑要批处理+限流，否则烧钱或被 API 拒。
</details>

### Q10. 错误 Case 怎么"沉淀"成评测集？为什么说要"泛化"而不是"存单条"？
- **考察点**：飞轮机制深度。
- **评分维度**：① 是否描述 错误Trace→错误池→专家审核→进评测集 全流程；② 是否强调"去重泛化成一类"；③ 是否点出"防回归/不犯第二次"是目的。
<details>
<summary>参考答案</summary>

流程：错误/高成本 Trace 自动打标入错误池 → 专家审核确认是真实失败模式、标注期望与风险标签 → 去重泛化提炼成"一类"case → 写进评测集新版本 → 后续每次回归自动守护。要泛化是因为只存单条只能防那一个恰好输入，泛化成"一类"才真防该类失败模式，否则飞轮变噪声库。
</details>

### Q11. 模型配置版本为什么要和 Prompt 绑成"发布单元"？举特药理赔例子说明。
- **考察点**：发布单元概念。
- **评分维度**：① 是否说明"保证评测与生产用同一组参数"；② 是否点出换模型要全量回归+成本对比；③ 特药场景示例是否贴切（如 T=0.1 固定保证拒答/结构化稳定）。
<details>
<summary>参考答案</summary>

把 model/temperature/top_p 等和 Prompt 绑成 pinned 发布单元，保证每次评测和生产用同一组参数，否则指标不可比。换模型风险最大（能力/格式/成本全变），必须全量回归+成本对比。特药场景例：固定 `model=qwen-plus, T=0.1` 保证拒答指令与 JSON 结构化稳定，评测和生产必须同参数。
</details>

---

## L4 场景（综合实战，2 题）

### Q12. 场景题：你上周上线的 v12 Prompt 让"拒答准确率"从 90% 升到 96%，但本周有用户投诉"一笔明显超适应症的特药被错误批准"。你作为 FDE 怎么用版本管理手段定位并止血？
- **考察点**：用版本管理+Trace+飞轮做事故处置。
- **评分维度**：① 是否先"可回滚"切回 v11 止血；② 是否用 Trace 复盘该笔决策链路；③ 是否把该事故提炼进评测集防再犯；④ 是否反思 v12 回归时漏了哪类对抗样本。
<details>
<summary>参考答案</summary>

处置：① **止血**——立即回滚到 v11（可回滚能力），先停住错误批准；② **复盘**——调出该笔理赔的 Trace，还原当时调了什么工具、看到什么、怎么决策，定位是 v12 的某条指令导致漏判；③ **补标尺**——将该事故提炼成多条"超适应症+不同诊断组合"对抗样本，经专家审核后加入评测集新版本；④ **查回归漏洞**——复盘发现 v12 回归时对抗样本覆盖不足、漏判率门禁没拦住（可能当时漏判率样本太少），补强门禁。最终形成"错误不犯第二次"的闭环。
</details>

### Q13. 场景题：团队想"每周一发新 Prompt，直接全量上线，省去回归"。你作为 FDE 如何用 LLMOps 版本管理说服他们必须有一键回归 + 灰度？请给出落地方案。
- **考察点**：发布流程治理 + 工具落地。
- **评分维度**：① 是否指出"直接全量"风险（翻车即持续错赔）；② 是否给出"锁版本一键回归+门禁拦截"；③ 是否设计灰度（小流量→全量）；④ 是否提到 Langfuse 等平台落地 + 敏感数据私有化。
<details>
<summary>参考答案</summary>

说服点：直接全量上线，一旦新 Prompt 翻车就是全量持续错赔（保险场景资损+合规），没有回归等于"盲发"。落地方案：① **锁版本一键回归**——每周一发版前，锁定 Prompt+模型配置+同一评测集跑全量，分层指标（含漏判率、成本 P95）设门禁，退化自动拦截；② **灰度**——回归通过后先小流量（如 5% 理赔单）跑，观察线上 Trace 与成本，再全量；③ **平台**——用 Langfuse 做 Prompt 版本管理+Datasets 对比+Trace 回放，但理赔材料敏感，须私有化部署或脱敏；④ **飞轮**——线上错误 trace 标 error 定期导出进 Datasets。这样既快又稳，不是"省去回归"而是"把回归自动化"。
</details>

---

## 评分汇总表

| 层级 | 题号 | 主题 | 满分建议 | 达标要求 |
|------|------|------|----------|----------|
| L1 基础 | Q1-Q4 | 概念识别 | 各 10 分 | 能说清四类资产、三诉求、回归与 Embedding 风险 |
| L2 进阶 | Q5-Q8 | 机制理解 | 各 15 分 | 能讲 Prompt 三位一体、评测集版本、报告设计、Trace |
| L3 深度 | Q9-Q11 | 设计/辨析 | 各 20 分 | 可复现细节、飞轮泛化、发布单元 |
| L4 场景 | Q12-Q13 | 综合实战 | 各 25 分 | 事故止血闭环、发布治理落地 |

**总分 160 分。** 评分建议：
- **≥130（≈81%）**：面试达标，具备 LLMOps 版本管理设计能力。
- **100-129**：基本达标，需补"飞轮泛化/可复现锁版本"等深度点。
- **<100**：未达标，重读手册 s1-s13。

## 双达标线（来自手册）
- **达标线①**：能讲清为什么需要多版本管理（可回滚 / 可对比 / 可审计），以及四类行为资产为何难管。
- **达标线②**：能讲清一键回归怎么实现（锁版本+批跑+基线快照 diff+分层门禁），以及错误 Case 怎么沉淀成评测集（错误池→审核泛化→进评测集→回归守护）。