上线后持续 LoRA 微调闭环
目录
上线后持续 LoRA 微调闭环：
问题发现 → 收集 → 训练 → 上线 → 观测 → 基线演进
我会先给纯流程图，再给每一段的关键判断点（防止被追问）。
一、上线后持续微调的整体流程图（文本版）
【生产运行中】
│
▼
【问题暴露】
（用户投诉 / 点踩 / 重复追问 /
转人工 / 质检 Reject / Risk）
│
▼
【问题样本收集】
- 抽样质检
- 高风险权重采样
- 自动规则捕获
│
▼
【问题标注 & 分类】
- Business Acceptance: Accept / Risk / Reject
- 问题标签（problem_type）
- 风险等级
- first_seen_version
│
▼
【进入问题样本池】
(problem_sample_pool)
│
▼
【LoRA 训练数据构建】
= 稳定基线样本
+ 候选基线样本
+ 当前周期问题样本
│
▼
【LoRA 微调训练】
- 小 rank
- 少 epoch
- 版本化输出（model_vX）
│
▼
【灰度上线】
- 小流量 / 指定用户
- 与上一版本并行
│
▼
【线上观测 & 对照分析】
- 问题标签发生率
- Risk / Reject 变化
- 副作用指标
│
▼
【问题是否稳定解决？】
│
┌────┴────┐
│ │
否 是
│ │
▼ ▼
【保留为问题样本】 【人工复核关键样本】
- 继续参与后续训练 - 行为是否正确
- 或降权处理 - 是否可复用
│
▼
【晋升为候选基线样本】
│
▼
【合并进基线样本池】
（分级：secondary / core）
│
▼
【进入下一轮微调周期】
二、流程中每一段的「关键判断点」（面试加分）
1️⃣ 问题暴露 ≠ 随机噪声
不是所有异常都值得进 LoRA。
常见有效问题来源：
- 质检 Reject / Risk
- 重复追问 ≥ N 次
- 投诉 / 退款 / 纠纷
- 突然转人工
- 高价值用户负反馈
2️⃣ 问题必须“被标签化”
否则无法判断是否被学会。
问题标签示例：
- wrong_objection_handling
- wrong_CTA_timing
- missing_knowledge
- over_promise
- policy_boundary_risk
这是后续评估是否解决的唯一锚点。
3️⃣ LoRA 训练不是“全新数据集”
你前面理解得非常对：
LoRA 数据集 =
稳定基线样本（长期保留）
+ 候选基线样本（验证中）
+ 当前周期问题样本（短期）
并且：
- 基线样本权重大
- 问题样本权重可控
- 防止行为漂移
4️⃣ 上线后不是只看“总体指标”
关键是对照某一类问题标签：
problem_rate(problem_type, model_vX)
vs
problem_rate(problem_type, model_vX-1)
同时检查：
- 是否引入新 Risk
- 是否影响 CTA / 转化
- 是否异常转人工
5️⃣ 合并进基线 ≠ 自动动作
这是非常重要的一点：
指标只是“候选信号”，最终要人工确认。
合并前必须确认：
- 行为长期正确
- 不依赖临时策略
- 不只是一次性修复
6️⃣ 基线是“分级演进的”
合并路径不是一步到位：
problem_sample
→ candidate_baseline
→ secondary_baseline
→ core_baseline
这保证了：
- 基线稳定
- 可回滚
- 可治理
三、你在面试中可以用的“一句话总结”
上线后的 LoRA 微调是一个闭环流程：
通过质检和用户行为发现问题样本，进行结构化标注后参与微调；
新版本灰度上线后，通过问题标签的对照指标和副作用监控验证效果，
只有被稳定学会、且行为可长期复用的问题样本，才会被分级合并进基线，用于下一轮训练。
如果你愿意，下一步我可以帮你：
- 把这套流程压缩成 30 秒 / 1 分钟面试版
- 或直接给你一个 「问题样本状态机 + 字段设计表」
- 或画一个 BI 指标 → 基线晋升判定表
你选一个继续。
浙公网安备 33010602011771号