完整题目
设计一个用于训练偏好感知对话系统的场景，描述如何构建数据、选择模型架构以及评估对话质量。
本文目录
一、数据构建
偏好数据收集
- 显式标注：人工对同一prompt的多个response进行排序（A>B>C），用Bradley-Terry模型建模
- 隐式反馈：点击率、停留时长、是否复制/分享，需设计position bias消除机制
- 多维度标注：有用性、安全性、事实性、风格一致性，避免单一分数的信息损失
数据质量控制
- 标注者一致性检验（Kappa系数>0.6）
- 困难样本挖掘：模型置信度接近0.5的pair优先标注
- 领域覆盖：电商场景需覆盖售前咨询、售后、比价等细分场景
二、模型架构
三阶段RLHF流程
- SFT：用高质量对话数据监督微调，建立基础对话能力
- Reward Model：输入(prompt, response)输出标量分数，常用架构在最后一层加回归头
- 损失函数：
-log σ(r_θ(x,y_w) - r_θ(x,y_l)) - 多任务扩展：多维度分数→加权求和或MoE结构
- 损失函数：
- 强化学习：PPO（需KL散度约束防崩溃）或DPO（直接偏好优化，省去RM训练）
个性化扩展
- 用户画像embedding拼接到prompt
- LoRA适配器：不同用户群体/场景维护独立低秩矩阵
三、评估体系
| 维度 | 指标 | 方法 |
|---|---|---|
| 偏好对齐 | 胜率（Win Rate） | GPT-4/人工盲评 |
| 对话质量 | 流畅度、多样性 | perplexity、distinct-n |
| 安全性 | 有害内容率 | 规则+分类器拦截 |
| 业务指标 | 转化率、满意度 | 在线A/B测试 |
关键陷阱：奖励黑客（Reward Hacking）——模型 exploit RM 的漏洞，需持续迭代RM并保留人工抽检。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服助手，用户对同一个商品问了三次，每次回复它都选了“没用”或直接关闭。你怎么设计一套数据收集和训练流程，让模型学会下次给出更符合用户偏好的回答？
层层追问
训练对话模型时，你怎么让模型知道哪个回答更好？……如果人工排序成本太高，还有别的办法吗？……那模型学完之后，怎么验证它真的对齐了用户的偏好？
直球架构
设计一个偏好感知对话系统，从数据构建、模型架构到评估完整方案。数据怎么标注？模型用RLHF还是DPO？你用什么指标判断对话质量好坏？
练习口述回答 · 约4分钟
- 本质是RLHF在对话中的落地
- 数据构建：显式排序+隐式反馈，注意一致性
- 模型架构：SFT+Reward Model+PPO/DPO，选型看场景
- 评估：胜率、安全、业务指标，坑是奖励黑客
- 我的取舍：DPO优先，数据质量是前提
这道题其实问的是怎么把用户偏好塞进对话模型里，本质上是[[RLHF]]在对话场景的落地。我会从数据、模型、评估三条线来讲，最后给个我的判断。
先说数据。偏好数据主要有两种来源：一种是显式标注，让人工对同一个问题的多个回答排序，A好于B好于C，然后用Bradley-Terry模型建模。另一种是隐式反馈，比如点击率、停留时长、用户有没有复制或分享，这些数据量大但偏置也大，需要做position bias消除。实际落地时，我倾向于两种结合，显式标注提供高质量信号，隐式反馈补充规模。但前提是标注者一致性要达标，Kappa系数至少0.6，不然噪声太大。还有个坑：模型在置信度0.5附近的样本最值得标，那些模型已经很确定好坏的pair反而信息量低。举个例子，电商客服场景里，用户问“退款为什么还没到”，不同回答的偏好差异很大，有的用户要快速解决，有的要解释原因，所以标注时得覆盖售前、售后、比价这些细分场景，不然模型容易偏。
再说模型架构。标准流程是[[SFT]]加偏好对齐。SFT先拿高质量对话数据做监督微调，把基础能力建起来。然后训练一个Reward Model，输入是问题和回答，输出一个分数。损失函数就是经典的Bradley-Terry排序损失。最后用[[PPO]]做强化学习，加上KL散度约束防止模型跑偏。但这里有个选择：PPO训练不稳定，还要维护Reward Model，所以很多场景我会直接用[[DPO]]，省掉Reward Model这一步，直接在偏好数据上优化。DPO的好处是简单稳定，但前提是偏好数据质量够高，如果数据噪声大，DPO容易过拟合。个性化扩展的话，可以把用户画像[[embedding]]拼到prompt里，或者用[[LoRA]]给不同用户群体维护独立的适配器，这样不用全量微调。
评估体系分三个层面。先说偏好对齐度，最直接的指标是胜率，让GPT-4或人工盲评两个回答哪个更好。再看对话质量本身，比如流畅度、多样性，用perplexity和distinct-n来监控。还要看业务指标，电商场景就看转化率和满意度，这个得在线A/B测试。这里有个关键陷阱叫奖励黑客，模型会钻Reward Model的漏洞，比如生成特别长但空洞的回答来刷分，所以必须持续迭代Reward Model，并且保留人工抽检。
其实还有一条路线是直接用[[Self-RAG]]，让模型自己判断要不要查文档、要不要反驳自己，这个在需要事实性的场景效果更好，但训练更复杂。
所以整体来说，我更倾向DPO优先，因为工程成本低，但前提是偏好数据质量要过硬。如果数据噪声大，那还是老老实实走PPO加Reward Model。落地时我会特别关注标注一致性检验和奖励黑客监控，这两个点最容易翻车。