智能客服SFT和DPO的运用场景

目录

两个问题都非常有价值，直接回答：

问题 1：真实电商场景，大部分问答应该走 RAG，SFT 主要做意图分类？

你的判断基本正确，但更准确的说法是两者分工不同。

真实电商客服系统的架构通常是这样的：

用户输入
    ↓
意图识别（分类器 or LLM）
    ↓
        ├─ 意图=查订单状态    → 调接口，走 RAG 把实时数据注入 prompt
        ├─ 意图=查物流        → 调接口，走 RAG
        ├─ 意图=退款进度      → 调接口，走 RAG
        ├─ 意图=投诉/情绪     → 走 LLM 生成（需要有温度的回答）
        ├─ 意图=政策咨询      → 走知识库 RAG（退换货政策、活动规则）
        └─ 意图=闲聊/复杂     → 走 LLM 生成

SFT 在这里教的核心能力有三件事，不只是意图分类：

SFT 教的能力 说明 这个项目里的体现
风格/人设对齐 学会"小智"的口吻，专业友好简洁，不说废话 所有回答的语气风格
槽位提取与追问 用户没给订单号时，知道主动要 "请提供一下订单号"
RAG 结果的组织能力 拿到接口返回的数据后，怎么用自然语言包装成友好回复 订单状态/物流查询的回答模板

本项目的数据是简化版——直接把"查询结果"硬编码进了回答里（比如 "订单 SO202581971316 还未发货"），真实生产中这个信息来自接口调用，模型只负责把结果"说好"。SFT 教的是"如何把实时数据转化为自然语言"这个能力。

问题 2：SFT 和 DPO 的数据看起来没本质区别，到底有什么区别？

表面上看确实很像，但训练目标完全不同，这是根本区别。

看数据的角度

随机拿同一个场景对比一下：

SFT 数据（退款慢）：
  user:      "退款10天了还没到账，什么情况？"
  assistant: "理解您着急的心情！退款已提交银行...如超过7个工作日联系我..."

DPO 数据（退款慢）：
  prompt:   "申请退款10天了还没处理"
  chosen:   "10天确实太久，我马上帮您升级处理，标记紧急工单..."
  rejected: "退款需要时间，请耐心等待。"

SFT 数据只告诉模型"遇到这种问题，要这样回答"——一个答案，没有对比。

DPO 数据告诉模型"这两个回答，左边的比右边的好"——两个答案，有对比。

训练目标的本质区别

SFT 的目标：
  最大化"正确回答"的生成概率
  → 模型学会"应该说什么"

DPO 的目标：
  最大化 chosen 和 rejected 的概率差距
  → 模型学会"什么叫更好"

SFT 之后，模型可能会生成"技术上正确但态度冷漠"的回答——因为它只学了"什么是对的答案"，没有学"为什么这个比那个好"。

DPO 之后，模型在相同场景下会更主动、更有温度、更愿意给方案——因为它看过大量对比，知道"退款需要时间请等等"是差回答。

什么情况下只用 SFT，什么情况下加 DPO

场景 建议
模型完全不懂这个领域（冷启动） 先做 SFT，教会基本知识和格式
模型知识够了，但语气/风格不对 SFT 微调风格即可
模型回答"正确但不好"——敷衍、冷漠、被动 加 DPO，教"什么叫更好"
有大量真实用户反馈数据（点赞/踩） 直接构造 DPO 偏好对，价值极高
模型有安全/价值观问题 必须用 DPO/RLHF，SFT 不够用

一句话总结：SFT 是"教技能"，DPO 是"建价值观"。这个项目先用 SFT 教模型当客服，再用 DPO 教它什么叫"好客服"。两步缺一不可——没有 SFT 打底，DPO 的 chosen 里有大量模型根本不懂的领域知识，学不进去；没有 DPO，模型回答虽然正确，但用户体验会明显差一截。

总结

能力 能否用 DPO 替代 SFT 条件
风格/人设对齐 ✅ 能，但有条件 基座模型要够强（32B+），小模型不行
槽位提取与追问 ⚠️ 很难 DPO 不擅长教"全新行为"，只擅长优化已有行为
RAG 结果组织能力 ❌ 不能 格式映射必须靠 SFT 示范，DPO 解决不了

一句话：SFT 是"从无到有"，DPO 是"从有到优"。用 DPO 替代 SFT，相当于让一个没上过学的人直接参加优秀毕业生评比——连基础都没有，评比就没有意义了。

posted @ 2026-04-04 15:43  向着朝阳  阅读(5)  评论(0)    收藏  举报