W6D2 学习手册 1.为何版本化2.Prompt版3.模型配置版4.Embedding版5.评测集版 6.一键回归7.AB报告8.Trace成本9.错误沉淀10.回滚对比审 11.Langfuse达标①达标②自测速记

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 版本最佳实践

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 关键风险

保险知识库用 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 关键工程点

一键回归是"质量门禁"。特药理赔场景里,新 Prompt 若让高风险漏判率从 0 变 0.5%,门禁应直接拦截,不准发。它把 W6D1 的指标设计落成了"可自动执行的发布卡点"。
一键回归 = 给定新版本自动跑全量评测集、产出与基线指标 diff 的报告。要点:可复现(锁版本)、基线是存的快照(省成本)、指标退化自动拦截发布。它是把评测指标落成"质量门禁"。
① 回归时 model/评测集没锁版本,diff 不可信。② 全量跑很贵很慢,要批处理+限流,否则烧钱或被 API 拒。③ 只比总分不比分层,退化藏在某子指标里发现不了——门禁要看分层指标。

七、A/B 报告:指标对比看什么

回归产出的 A/B 报告要让人一眼看出"该不该发"。

维度看什么决策含义
任务完成率Δ 值、是否退化核心功能好坏
高风险漏判率是否从 0 变 >0一票否决
单任务成本 P95token/工具成本变化经济性
各分层指标Smoke/功能/边界/对抗各自 Δ定位退化在哪层
回归样本哪些 case 从对变错定性复盘
报告要给"决策者"看,不只给算法看。特药场景的 A/B 报告里,高风险漏判率和成本必须置顶——业务方最关心"会不会赔错钱、要花多少钱"。用颜色标红退化项,一眼可视。
A/B 报告看:任务完成率 Δ、高风险漏判率是否变 0→正、单任务成本 P95、各分层 Δ、以及哪些 case 从对变错。安全与成本指标置顶,退化项标红。报告给业务决策者看,不只算法。
① 报告只给总分不给分层,决策者看不出"哪类 case 退化了"。② 漏判率这种小数字变化(0→0.5%)容易被平均掩盖,要单独置顶显示。③ 只报提升不报退化样本清单,无法复盘根因。

八、Trace、Token 成本、错误 Case 保存与复盘

每次运行(评测 or 生产)都要落"Trace"——完整记录输入、每步 tool_call、中间状态、输出、token、耗时、成本。

8.1 为什么存 Trace

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 沉淀流程

  1. 采集:错误 Trace 自动进错误池(或人工上报)。
  2. 审核:专家确认"确实是该测的失败模式",标注期望输出/风险标签。
  3. 提炼:去重、泛化(不要只存这一条,存一类),写入 evalset 新版本。
  4. 守护:后续每次一键回归自动覆盖该 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 → 错误池 → 专家审核泛化 → 评测集新版本 → 回归自动守护
  1. 一键回归实现:① 把新 Prompt/配置 + 固定评测集版本作为入参;② 批处理跑全量(限流防烧钱);③ 读上一版指标快照做 diff;④ 分层指标(含漏判率、成本 P95)设门禁,退化则拦截;⑤ 通过则存新快照、进灰度。
  2. 错误 Case 沉淀:① 错误/高成本 Trace 自动打标入池;② 专家审核确认失败模式、标注期望与风险标签;③ 去重泛化提炼成"一类"case,写进评测集新版本;④ 后续每次回归自动守护,防回归。
一键回归靠"锁版本+批跑+基线快照 diff+分层门禁"实现,核心是结果可复现、退化可拦截。错误 Case 沉淀靠"错误池→专家审核泛化→进评测集→回归守护"的飞轮,保证同类错误不犯第二次。两者合起来就是可持续的 LLMOps。

十四、W6D2 自测清单

十五、高频面试题速记卡

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》自测
📌 待查★ 重要