FDE W6D2 学习手册 · LLMOps 版本管理
W6 Day2 · A 级(必须掌握,面试核心)· 4h · 学完能讲透"为什么 LLM 应用要像代码一样多版本管理,以及一键离线回归怎么实现、错误 Case 怎么沉淀成评测集"
本日定位:W6D1 讲了"评什么",Day2 讲"怎么让评测可持续、可回滚、可审计"。LLM 应用的 Prompt/模型/Embedding/评测集每天都在变,没有版本管理就会"昨天还好好的今天崩了还查不出原因"。
学完能回答:① 为什么要 Prompt/模型/Embedding/评测集多版本管理(可回滚/可对比/可审计);② 一键离线回归怎么实现、出什么 A/B 报告;③ Trace/Token 成本/错误 Case 怎么保存复盘;④ 错误 Case 怎么沉淀成评测集形成飞轮。
使用方法:通读原理 → 重点看「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W6D2-评测题.md》。选中不熟的词可标注(左下★重要 / 右下📌待查)。
一、为什么 LLM 应用需要版本管理(而传统应用已有 Git)
传统代码有 Git,但 LLM 应用多了几类"非代码但决定行为"的资产,它们变化频繁且难以用 Git diff 看懂:
| 资产 | 为什么难管 | 变化频率 |
| Prompt | 自然语言,效果靠评测才知道,看 diff 看不出好坏 | 高(周级) |
| 模型配置 | model/temperature/top_p/超时,改了行为就变 | 中 |
| Embedding 模型/版本 | 换版本后向量空间变,检索结果全变 | 低但影响大 |
| 评测集 | 随业务/条款演进,是"标尺"本身 | 中 |
核心诉求就三个词:可回滚(新 Prompt 翻车能秒回旧版)、可对比(改一版跑全量看指标 diff)、可审计(哪天谁改了什么、线上效果如何,能追溯)。这和企业"变更管理"一脉相承,只是对象多了 Prompt 这种软资产。
LLM 应用除了代码还有 Prompt/模型配置/Embedding/评测集四类"行为资产",它们变化快且看 diff 看不出效果。版本管理为的是可回滚、可对比、可审计——和传统变更管理一脉相承,只是多了软资产。
① 别以为"Prompt 又不是代码,不用版本化"——Prompt 是生产行为的决定因素,没版本化就会"改崩了无法回滚"。② 评测集本身也要版本化:你用 v1 评测集说 v2 Prompt 变好,可能只是评测集变了,要锁定对照。③ Git 不够——Prompt 的"效果"需要评测数据关联,纯 Git 看不到指标。
二、Prompt 版本
每个 Prompt 应有唯一版本号(如 prompt:v12),并存:内容、创建人、创建时间、关联评测结果、上线状态。
2.1 Prompt 版本最佳实践
- 模板与变量分离:系统提示写模板,运行时填变量(用户问题、检索片段),模板进版本管理。
- 变更要有"为什么":每条版本记录关联一个改进目标(如"降低拒答率")。
- 灰度 + 回归:新 Prompt 先离线全量回归通过,再小流量灰度,再全量。
2.2 特药理赔示例
系统提示从 v11「请严格按知识库回答」改为 v12「请严格按知识库回答;知识库无把握时必须输出 should_refuse=true 并转人工」,这个改动必须打版本,因为直接影响拒答与高风险漏判指标。
Prompt 版本要"内容 + 元数据 + 评测快照"三位一体。上线前用一键回归(见 s6)跑全量评测集,指标不退化才允许灰度。回滚时不仅回 Prompt 文本,还要能回滚到对应的"已知好"状态。
Prompt 版本 = 内容 + 创建人/时间 + 关联评测结果 + 上线状态。模板与变量分离,变更要写"为什么改"。新版本先离线回归再灰度。特药场景里"加 should_refuse 指令"这种改动必须打版本。
① Prompt 文本回滚了,但没回滚关联的配置/评测快照,等于半回滚,容易出诡异问题。② 把 Prompt 硬编码在代码里、靠 Ctrl+Z 回滚是灾难——必须集中管理。③ 同一 Prompt 不同变量组合效果不同,回归要覆盖典型变量。
三、模型配置版本
模型配置指 model / temperature / top_p / max_tokens / 超时 / 重试 等。换模型或调参都算配置变更。
| 变更 | 风险 | 管控 |
| 换模型(如 Qwen→DeepSeek) | 能力/格式/成本全变 | 必须全量回归 + 成本对比 |
| 调 temperature | 稳定性变化 | 回归 + 抽样人工 |
| 改 max_tokens | 截断/成本 | 回归边界 case |
保险场景对"确定性"要求高,模型配置版本要和 Prompt 版本绑定成"一次发布单元"。例如配置 model=qwen-plus, T=0.1 作为一个 pinned 版本,保证每次跑评测和生产用的是同一组参数,否则指标不可比。
模型配置版本 = model/temperature/top_p/max_tokens/超时/重试。换模型风险最大,必须全量回归+成本对比。特药场景把它和 Prompt 绑成"发布单元",固定参数保证评测与生产一致、指标可比。
① 生产用 A 模型、评测用 B 模型,得出的"通过"毫无意义——评测必须 pin 住配置版本。② 不同模型对 JSON/结构化输出支持不同,换模型要重测 schema 兼容性。③ 成本随模型/参数剧烈变化,回归报告必含成本对比。
四、Embedding 版本
Embedding 模型版本决定向量空间。换版本后旧向量全部失效,必须重建索引,否则检索结果错乱。
换 Embedding 版本 → 向量空间漂移 → 旧索引不可用 → 必须重嵌 + 重建向量库 → 重跑 RAG 评测
4.1 关键风险
- 混合版本灾难:库里一半旧向量一半新向量,检索时余弦相似度无意义。
- ACL/来源未同步:重建索引时若文档治理(W3)没同步,会重新摄入脏数据。
保险知识库用 Embedding 做特药条款检索。Embedding 版本变更是"高影响低频率"操作,必须:① 全量重嵌 + 重建索引;② 跑 W3 的 RAG Eval 50 case 验证召回不退化;③ 和 Prompt/模型版本一起纳入发布单元。绝不能"悄悄换 embedding 不重测"。
Embedding 版本决定向量空间,换了旧向量全失效,必须全量重嵌+重建索引+重跑 RAG 评测。最怕"库里新旧向量混用",相似度直接失真。它是高影响低频率变更,要和 Prompt/模型绑成发布单元。
① 换 Embedding 不重建索引 = 检索结果错乱,且很难排查(因为"看起来在跑")。② 新旧向量绝不能混库。③ 重建索引时别忘了同步文档治理(W3 的来源校验/ACL),否则脏数据重新进库。
五、评测集版本(标尺本身也要版本化)
评测集是"标尺"。如果标尺在变,你测出的"变好"可能是假象。
| 做法 | 说明 |
| 评测集打版本 | 如 evalset:v3,记录 case 数、覆盖维度、构造日期 |
| 发布单元绑定评测集版本 | 某次 Prompt 回归用 evalset:v3,结果快照关联 v3 |
| 变更评测集要记录原因 | "新增 5 条超适应症对抗样本" |
对比两次 Prompt 效果,必须"同一评测集版本"才有意义。如果评测集也升级了(加了更难 case),完成率下降可能是标尺变严而非 Prompt 变差——要能区分。错误 Case 沉淀(见 s9)本质是"评测集版本的演进"。
评测集是标尺,必须打版本。两次对比要用同一评测集版本,否则"变好"可能是标尺变了。评测集升级导致完成率下降,要能区分是"标尺变严"还是"Prompt 变差"。错误 Case 沉淀就是评测集版本的迭代。
① 用不同版本评测集比出的"提升"是无效结论。② 评测集只能"加难"不能"偷偷减 case"来刷分——那是作弊。③ 评测集版本和 Prompt 版本要能双向追溯。
六、一键离线回归:架构与实现
"一键回归"= 给定新版本(Prompt/配置),自动跑全量评测集,产出与上一版的指标对比报告。
# 一键回归伪代码
def regression(new_prompt_v, base_prompt_v, evalset_v):
new = run_all(new_prompt_v, evalset_v) # 全量跑新版本
base = load_snapshot(base_prompt_v, evalset_v) # 读基线快照
report = diff(new.metrics, base.metrics) # 生成 A/B 对比
if report.regressed(): block_release() # 指标退化则拦截
else: approve_gray() # 否则进灰度
save_snapshot(new_prompt_v, new.metrics)
6.1 关键工程点
- 可复现:固定 model/temperature/评测集版本,结果才能比。
- 并发跑:30+50+各 Tool case 全量可能慢,要批处理 + 限流(防 API 限流/烧钱)。
- 基线是快照:上一版指标存库,回归直接 diff,不重跑也能比(省成本)。
- 拦截门禁:任何核心指标退化(如漏判率升高、完成率降)自动阻断发布。
一键回归是"质量门禁"。特药理赔场景里,新 Prompt 若让高风险漏判率从 0 变 0.5%,门禁应直接拦截,不准发。它把 W6D1 的指标设计落成了"可自动执行的发布卡点"。
一键回归 = 给定新版本自动跑全量评测集、产出与基线指标 diff 的报告。要点:可复现(锁版本)、基线是存的快照(省成本)、指标退化自动拦截发布。它是把评测指标落成"质量门禁"。
① 回归时 model/评测集没锁版本,diff 不可信。② 全量跑很贵很慢,要批处理+限流,否则烧钱或被 API 拒。③ 只比总分不比分层,退化藏在某子指标里发现不了——门禁要看分层指标。
七、A/B 报告:指标对比看什么
回归产出的 A/B 报告要让人一眼看出"该不该发"。
| 维度 | 看什么 | 决策含义 |
| 任务完成率 | Δ 值、是否退化 | 核心功能好坏 |
| 高风险漏判率 | 是否从 0 变 >0 | 一票否决 |
| 单任务成本 P95 | token/工具成本变化 | 经济性 |
| 各分层指标 | Smoke/功能/边界/对抗各自 Δ | 定位退化在哪层 |
| 回归样本 | 哪些 case 从对变错 | 定性复盘 |
报告要给"决策者"看,不只给算法看。特药场景的 A/B 报告里,高风险漏判率和成本必须置顶——业务方最关心"会不会赔错钱、要花多少钱"。用颜色标红退化项,一眼可视。
A/B 报告看:任务完成率 Δ、高风险漏判率是否变 0→正、单任务成本 P95、各分层 Δ、以及哪些 case 从对变错。安全与成本指标置顶,退化项标红。报告给业务决策者看,不只算法。
① 报告只给总分不给分层,决策者看不出"哪类 case 退化了"。② 漏判率这种小数字变化(0→0.5%)容易被平均掩盖,要单独置顶显示。③ 只报提升不报退化样本清单,无法复盘根因。
八、Trace、Token 成本、错误 Case 保存与复盘
每次运行(评测 or 生产)都要落"Trace"——完整记录输入、每步 tool_call、中间状态、输出、token、耗时、成本。
8.1 为什么存 Trace
- 复盘:某 case 错了,能还原"它当时调了什么、看到什么、怎么决策"。
- 成本归因:哪类任务 token 烧最多,定位优化点。
- 审计:监管要求能追溯某笔理赔的决策链路。
- 飞轮燃料:错误 Trace 是沉淀评测集的来源(见 s9)。
8.2 错误 Case 怎么存
把"跑错/跑偏/成本高"的运行自动打标,存入"错误 Case 池",附:输入、期望、实际、根因标签(OCR/规则/编排/模型)。
用 Langfuse(langfuse.com)天然支持 Trace 记录、token 成本统计、会话回放。保险场景 Trace 还承载合规审计——某笔拒赔如果被投诉,要能调出完整决策链路自证合规。
每次运行落 Trace(输入/tool_call/中间态/输出/token/成本/耗时),用于复盘、成本归因、合规审计、以及喂给错误 Case 池。Langfuse 可天然记录 Trace 与成本并做回放。错误 Case 自动打标入池。
① 不存 Trace = 出错只能重跑猜原因,不可复盘。② Trace 含用户隐私(理赔材料),要脱敏+权限控制,别裸存。③ 错误 Case 池若不治理会无限膨胀,要定期归档/提炼进评测集。
九、错误 Case 沉淀为评测集(飞轮)
这是 LLMOps 最值钱的"飞轮":生产/评测中暴露的错误,变成新的评测 case,下次改动自动被守。
线上/评测错误 → 打标入错误池 → 专家审核提炼 → 加入评测集新版本 → 下次回归自动守护 → 新错误继续补
9.1 沉淀流程
- 采集:错误 Trace 自动进错误池(或人工上报)。
- 审核:专家确认"确实是该测的失败模式",标注期望输出/风险标签。
- 提炼:去重、泛化(不要只存这一条,存一类),写入 evalset 新版本。
- 守护:后续每次一键回归自动覆盖该 case,防止回归。
特药场景:一次线上"超适应症用药被错误批准"的事故,被提炼成 3 条对抗样本(不同药品+不同诊断组合)加入评测集。此后任何 Prompt 改动若再犯,回归立刻标红。这就是"错误不犯第二次"的工程化保证。
错误 Case 飞轮:错误 Trace → 入错误池 → 专家审核提炼(去重泛化)→ 加入评测集新版本 → 下次回归自动守护。特药场景一次"超适应症被错批"的事故,可提炼成多条对抗样本,保证此类错误不再犯。
① 把单条错误直接塞进评测集不泛化——要提炼成"一类",否则只防住那一恰好输入。② 错误池不审核就全收,会混入噪声/误标,污染评测集。③ 飞轮要有人维护,否则池子膨胀、评测集变慢变脏。
十、可回滚 / 可对比 / 可审计(达标线①基础)
| 能力 | 怎么做 | 保险场景价值 |
| 可回滚 | 版本化 + 一键切回上一已知好版本 | 新 Prompt 翻车,5 分钟恢复,避免持续错赔 |
| 可对比 | 基线快照 + 一键回归 diff | 每次改动用数据说话,不靠拍脑袋 |
| 可审计 | 版本+Trace+评测快照全留痕 | 监管查某笔理赔决策,能追溯当时用的 Prompt/模型/结果 |
三者是"发布工程成熟度"的标志。没有可回滚,一次坏改动就是事故;没有可对比,优化无从证明;没有可审计,金融业务过不了合规。FDE 面试会把这三点当"工程素养"硬指标。
可回滚=版本化+一键切回;可对比=基线快照+一键回归 diff;可审计=版本+Trace+评测快照全留痕。三者是 LLM 应用发布成熟度的标志,金融场景缺任何一个都过不了合规或会出事故。
① "能回滚"不等于"回滚过"——要演练回滚流程,否则真出事手忙脚乱。② 审计留痕若不含"当时用的评测集版本",追溯不完整。③ 三者要自动化,靠人工记文档必漏。
十一、工程落地:结合 Langfuse
Langfuse(langfuse.com)是开源 LLMOps 平台,覆盖本日多个诉求:
| 本日诉求 | Langfuse 能力 |
| Trace 记录 | SDK 自动记录每步生成/工具调用,支持回放 |
| Token 成本 | 按 trace 统计 token 与花费,看趋势 |
| 版本与回归 | prompt 版本管理 + 评测数据集 + 对比(数据集运行对比) |
| 错误复盘 | 按标签筛选失败 trace,导出为评测 case |
落地建议:① 用 Langfuse 的 Prompt 管理做 Prompt 版本;② 用 Datasets 功能存评测集并跑版本对比;③ 把生产错误 trace 标 error 标签,定期导出进 Datasets 形成飞轮;④ 成本看板对接财务做预算管控。
不要自研一套 Trace/版本系统,除非有强定制需求。Langfuse 这类平台把"版本+Trace+评测+对比"打通,省下大量重复造轮子。但注意:Prompt 内容、Trace 里的理赔材料属敏感数据,私有化部署或开启脱敏。
Langfuse 覆盖本日多数诉求:Prompt 版本管理、Datasets 存评测集并做版本对比、Trace 回放、Token 成本统计、错误 trace 导出成评测 case。建议直接用它而非自研,但敏感数据要私有化/脱敏。
① 用 SaaS 版 Langfuse 却把理赔材料明文传上去 = 数据合规事故,金融业务必须私有化或脱敏。② 平台只是工具,版本规范/飞轮流程还得自己建,别以为接了平台就自动合规。③ 不要同时用多个平台各管一点,数据割裂。
十二、面试达标线①:为什么需要多版本管理(可回滚/可对比/可审计)
| 诉求 | 为什么必须 | 反例(没有会怎样) |
| 可回滚 | Prompt/模型改动常翻车,需秒回已知好版本 | 坏改动持续生效,持续错赔 |
| 可对比 | 改动效果要靠数据证明,而非感觉 | "我觉得变好"无法说服业务/审计 |
| 可审计 | 金融合规要追溯每次决策用的版本与结果 | 监管检查时无据可查,违规 |
核心是三类行为资产(Prompt/模型配置/Embedding/评测集)变化快且看 diff 看不出效果,所以必须版本化。版本化带来可回滚(翻车秒恢复)、可对比(一键回归 diff)、可审计(金融合规追溯)。这三点也是发布工程成熟度标志。
十三、面试达标线②:一键回归怎么实现 + 错误 Case 怎么沉淀成评测集
一键回归 = 锁定版本(新Prompt+模型配置+同一评测集) → 批跑全量 → 与基线快照 diff → 分层指标门禁 → 通过进灰度
错误沉淀 = 错误Trace → 错误池 → 专家审核泛化 → 评测集新版本 → 回归自动守护
- 一键回归实现:① 把新 Prompt/配置 + 固定评测集版本作为入参;② 批处理跑全量(限流防烧钱);③ 读上一版指标快照做 diff;④ 分层指标(含漏判率、成本 P95)设门禁,退化则拦截;⑤ 通过则存新快照、进灰度。
- 错误 Case 沉淀:① 错误/高成本 Trace 自动打标入池;② 专家审核确认失败模式、标注期望与风险标签;③ 去重泛化提炼成"一类"case,写进评测集新版本;④ 后续每次回归自动守护,防回归。
一键回归靠"锁版本+批跑+基线快照 diff+分层门禁"实现,核心是结果可复现、退化可拦截。错误 Case 沉淀靠"错误池→专家审核泛化→进评测集→回归守护"的飞轮,保证同类错误不犯第二次。两者合起来就是可持续的 LLMOps。
十四、W6D2 自测清单
- 能说出 LLM 应用比传统应用多出的四类"行为资产"(Prompt/模型配置/Embedding/评测集)及版本化三诉求(回滚/对比/审计)。
- 能解释 Prompt 版本为什么"内容+元数据+评测快照"三位一体,模板与变量为何分离。
- 能说明模型配置版本为什么要和 Prompt 绑成"发布单元",评测必须 pin 住配置。
- 能讲清 Embedding 换版本为什么必须全量重嵌+重建索引,混合版本为何灾难。
- 能解释评测集本身为什么要版本化,以及"标尺变了导致变好"的假象怎么避免。
- 能画出一键回归的流程,说出可复现、基线快照、分层门禁三个关键点。
- 能说明 A/B 报告要看哪些维度,为什么漏判率/成本要置顶、分层 Δ 不能省。
- 能解释为什么每次运行要存 Trace,以及 Trace 在复盘/成本/审计/飞轮中的作用。
- 能描述错误 Case 飞轮:错误 Trace→错误池→专家审核泛化→进评测集→回归守护。
- 能区分可回滚/可对比/可审计,并联系保险合规说清价值。
- 能说出 Langfuse 在本日的角色(Prompt 版本/Datasets 对比/Trace/成本/错误导出)。
- 能讲清"错误要泛化成一类再进评测集",以及敏感数据要私有化/脱敏。
十五、高频面试题速记卡
Q:LLM 应用为什么不能只靠 Git 做版本管理?
除了代码还有 Prompt/模型配置/Embedding/评测集四类"行为资产",变化快且看 diff 看不出效果,需要关联评测数据。版本化要可回滚/可对比/可审计。
Q:一键回归的核心是什么?
锁版本(新 Prompt+配置+同一评测集)跑全量,和基线快照 diff,分层指标设门禁,退化拦截、通过进灰度。核心是结果可复现。
Q:换 Embedding 模型为什么危险?
向量空间变,旧向量失效,必须全量重嵌+重建索引;新旧混库会让相似度失真。属高影响低频率变更,要重跑 RAG 评测。
Q:评测集为什么要版本化?
它是标尺。两次对比须用同一评测集版本,否则"变好"可能是标尺变严。评测集升级导致完成率降,要能区分标尺变严还是 Prompt 变差。
Q:错误 Case 怎么变成评测集?
错误 Trace 入池→专家审核确认失败模式→去重泛化成"一类"→写进评测集新版本→后续回归自动守护,防再犯。
Q:A/B 报告里什么指标要置顶?
高风险漏判率(一票否决)和单任务成本 P95,以及各分层 Δ。退化项标红,让决策者一眼看出该不该发。
Q:Trace 为什么要存?
用于复盘(还原决策)、成本归因、合规审计(金融追溯决策链路)、以及喂给错误 Case 池形成飞轮。不存就不可复盘。
Q:可回滚/可对比/可审计分别解决什么?
回滚=翻车秒恢复;对比=改动用数据证明;审计=金融合规追溯。三者是发布成熟度标志,缺一不可。
Q:为什么错误要"泛化"再进评测集?
只存单条只能防那一个恰好输入;泛化成"一类"才能真防该类失败模式。否则飞轮变成噪声库。
Q:用 Langfuse 的 SaaS 版存理赔材料有什么风险?
明文传敏感理赔数据=数据合规事故。金融业务必须私有化部署或开启脱敏,且版本规范/飞轮流程还得自己建。
FDE W6D2 学习手册 · LLMOps 版本管理(面试级)· 配合《FDE-W6D2-评测题.md》自测
📌 待查★ 重要