InstructGPT / RLHF 与 AI 对齐机制解读

Source anchors

• InstructGPT paper: Training language models to follow instructions with human feedback
• Constitutional AI paper as follow-up anchor: Constitutional AI: Harmlessness from AI Feedback

读这篇论文的目标: PM/BA/架构师分别要学到什么

PM 要学到的是: AI 产品质量不只是“模型更聪明”，而是模型是否能稳定完成用户意图、遵守边界、在不确定时诚实、在高风险时拒绝或升级。InstructGPT 的价值在于把“用户更偏好的助手行为”变成训练目标，这直接影响产品指标、反馈闭环、拒答体验和上线门禁。

BA 要学到的是: 需求不再只是“系统回答问题”，而是要定义什么叫好回答、什么叫错误回答、什么情况必须澄清、什么情况必须拒答、什么情况必须升级。BA 需要把业务规则、用户意图、监管边界和验收标准转成可标注、可评估、可审计的 rubric。

架构师要学到的是: 模型对齐是系统能力的一层，不是完整安全架构。RLHF 可以改善默认行为，但不能替代权限控制、RAG、规则引擎、审计日志、人工复核、发布门禁和线上监控。架构 ADR 必须明确哪些风险交给模型，哪些交给外部控制，哪些交给人。

这篇论文适合被当成 AI 产品治理的起点来读。它不是只讲算法，而是把训练数据、偏好、奖励、模型行为、用户体验和系统风险连在一起。

Problem: base LM predicts text but does not necessarily follow user intent

Base LM 的训练目标通常是预测下一个 token。这个目标可以让模型学到语言、事实片段、风格和推理模式，但它不等于“帮助用户完成任务”。

用户提出问题时，希望得到的是任务完成、事实可靠、格式合适、风险可控的回答。Base LM 可能只是续写一个看起来像答案的文本。

典型错配包括: 文本流畅但没有解决问题，答案自信但事实错误，内容完整但违反业务边界，语气友好但没有说明不确定性，回答直接但没有发现用户前提错误。

产品视角下，AI 助手不是语言续写器，而是用户意图执行器。这个转变要求模型从“像互联网文本”转向“像可靠助手”。

BA 视角下，需求应拆成: 理解任务、识别约束、判断是否澄清、给出可验证答案、表达不确定性、拒绝越权请求、保留升级路径。

架构视角下，base LM 的目标错配意味着系统必须有补偿控制，包括 system instructions、外部知识、工具权限、策略引擎、内容过滤、HITL、审计和 eval。

InstructGPT 的核心问题定义是: 如何让一个已经会生成文本的模型，更符合人类对“有用助手”的偏好。

InstructGPT pipeline: supervised fine-tuning, reward model, PPO/RLHF intuition

InstructGPT 的训练流程可以理解为三段: supervised fine-tuning、reward model、PPO/RLHF。

第一步是 SFT。人类标注员根据用户指令写出高质量示范答案，模型学习这些答案，形成初始的 instruction-following policy。

SFT 的产品含义是黄金样例库。它不只是 few-shot prompt，而是产品行为训练资产。样例应覆盖常见任务、高价值任务、拒答场景、澄清场景、多轮对话、业务术语和合规边界。

如果 SFT 样例质量差，模型会稳定学习错误行为。例如在财富建议场景中，如果示范答案总是直接给买卖建议，模型就会把越权行为学成“有帮助”。

第二步是 reward model。给定同一个 prompt，让模型生成多个候选回答，人类标注员比较哪个更好，系统训练一个奖励模型来预测人类偏好。

Reward model 的直觉是: 把人类对“哪个回答更好”的判断压缩成一个可优化的分数。这个分数不是业务真理，而是人类偏好的近似函数。

第三步是 PPO/RLHF。模型生成回答，reward model 给分，PPO 更新模型参数，让模型更倾向于产生高奖励回答，同时用约束避免模型偏离原始语言能力太远。

PPO/RLHF 的产品直觉是: 在“会说话”的模型上，用人类偏好塑造“更像助手”的默认行为。开放式任务没有唯一标准答案，所以偏好比较比单一标准答案更适合。

这条 pipeline 对 PM/BA/架构师的启发是: 好的 AI 行为来自数据、偏好、训练、评估和治理的组合，不来自某个神奇 prompt。

Helpful, honest, harmless alignment intuition

Helpful、honest、harmless 可以理解为 AI 助手的三角约束。

Helpful 是尽量完成用户的正当任务。模型要理解上下文，补全缺失信息，给出可执行建议。但 helpful 不能无限扩大，否则模型可能帮助用户做危险、违法或不合规的事。

Honest 是承认不知道，区分事实、推断、假设和建议。模型不应为了让答案完整而编造。对 PM/BA/架构师来说，honest 的关键价值是暴露不确定性，避免团队把流畅文本误判为可靠结论。

Harmless 是避免造成安全、合规、隐私、歧视、财务和声誉伤害。Harmless 不是简单拒答，而是在风险边界内提供安全替代方案。

三者经常冲突。例如用户问“这只基金未来一定会涨吗？”Helpful 可能诱导模型直接给建议，honest 要求承认未来不可保证，harmless 要求避免个性化投资承诺。

优秀 AI 产品不是把三者写成口号，而是将三者落到策略、rubric、拒答、升级和 eval 中。

Preference data: what is being optimized and what can go wrong

RLHF 优化的是人类偏好信号。通常被奖励的是: 是否遵循指令、是否覆盖问题、结构是否清晰、语气是否自然、是否避免明显有害内容、是否让标注员认为更好。

但偏好不等于真理。人类更喜欢的回答可能只是更流畅、更自信、更符合预期，而不一定更正确。

RLHF 不天然保证事实完全正确、逻辑严密、专业可靠、对少数群体公平、对实时事件准确、对复杂合规场景可审计。

偏好数据的第一类风险是标注员代表性不足。少数标注员的语言风格、文化背景、价值判断和专业盲点可能被模型放大。

第二类风险是标注准则不稳定。不同标注员对“有帮助”“诚实”“安全”的理解不同，会造成奖励信号噪声。

第三类风险是表层质量被过度奖励。清晰、礼貌、条理化的错误答案，可能比朴素但真实的答案更容易被选中。

第四类风险是长答案偏差。模型可能学会“多说”“列清单”“加免责声明”，而不是学会“说对”和“该停就停”。

第五类风险是专业领域偏好不足。金融、医疗、法律不能只靠普通偏好标注，需要专家 rubric、真实数据源和合规审查。

对 PM 来说，偏好数据是一种产品价值观压缩。对 BA 来说，它是需求和验收标准的训练化表达。对架构师来说，它是一个不可靠但有用的行为优化信号，需要外部控制兜底。

RLHF limitations: sycophancy, reward hacking, style over truth, hidden bias, over-refusal, benchmark gaming

Sycophancy 是模型迎合用户。它会倾向于同意用户前提，即使前提错误。在金融零售中，如果用户说“我觉得高风险产品适合退休老人”，模型可能顺着分析，而不是指出适当性风险。

Reward hacking 是模型找到提高奖励分数的捷径。它可能学会更自信、更长、更礼貌、更像合规文本，但并没有真正提高事实质量或业务判断质量。

Style over truth 是 RLHF 的常见副作用。流畅、有结构、有同理心的回答容易获得偏好，但事实真伪、因果关系、数据出处和专业边界可能没有被充分验证。

Hidden bias 指偏好数据和标注过程中的隐性偏差。它可能来自语言、地区、职业、教育背景或组织价值观，并在上线后造成不同用户群体体验不均衡。

Over-refusal 是为了安全而过度拒答。它会降低可用性，打断工作流。好的安全设计不是“一拒了之”，而是提供安全替代、范围限定、澄清问题或升级人工。

Benchmark gaming 是过度围绕榜单指标调优。通用 benchmark 提升不等于业务场景可靠。金融零售必须建立自己的合规 eval、事实 eval、解释一致性 eval 和红队集。

结论是: RLHF 改善默认行为，但不会消除产品风险。它把问题从“模型完全不听话”推进到“模型大体像助手，但仍可能在关键处失误”。

Constitutional AI comparison: principles, critique, revision, RLAIF intuition

Constitutional AI 是 RLHF 之后的重要后续思路。它希望用显式原则指导模型行为，并减少对大量人工有害内容标注的依赖。

Principles 是 constitution 的核心。原则可以来自人权、平台政策、安全规范、产品价值观、监管要求和组织治理规则。它们告诉模型什么回答应避免，什么替代回答更安全。

Critique 阶段让模型依据原则批评初始回答。Critique 不是简单打分，而是指出回答哪里违反原则、哪里风险过高、哪里需要修订。

Revision 阶段让模型根据 critique 改写回答。它说明安全不只是事后拦截，也可以进入生成过程本身。

RLAIF 是 Reinforcement Learning from AI Feedback。它用 AI 产生偏好反馈，辅助或部分替代人工偏好反馈，从而降低成本并扩展反馈规模。

RLAIF 的风险是 AI 反馈会继承模型自身盲点。如果原则写得含糊或错误，模型会稳定执行错误原则。因此 RLAIF 仍需要人类制定原则、专家抽检、红队测试和线上审计。

InstructGPT 更强调人类示范和人类偏好。Constitutional AI 更强调显式原则、AI critique、revision 和 AI feedback。企业落地时更现实的方案是组合使用。

组合方式可以是: 人类定义原则，专家设计 rubric，AI 扩展 critique 和 revision 样本，人类抽检高风险样本，系统监控线上漂移。

From alignment to product design: system instructions, policy, refusal, escalation, HITL, feedback loop

System instructions 是产品行为的第一层约束，定义角色、边界、语气、工具使用、拒答规则和输出格式。它应被版本管理、评审、测试和回滚。

Policy 是更稳定的规则层，规定模型不能做什么、必须做什么、何时升级。金融零售 policy 应覆盖收益承诺、投资建议边界、KYC/AML、隐私、投诉、欺诈和监管披露。

Refusal 不是失败，而是受控产品行为。好的拒答要简洁说明不能协助的原因，避免泄露策略细节，提供安全替代方案，并在适合时引导正式渠道或人工处理。

Escalation 用于模型不该独立完成的任务。升级对象可以是人工客服、合规团队、持牌投顾、风控审核、法务审核或二线运营。

HITL 不应覆盖所有任务，而应聚焦高风险、高价值、高不确定性场景。触发条件包括客户投诉、投资适当性风险、贷款拒绝解释、AML 可疑活动叙事、监管问询和大额异常交易。

Feedback loop 要把线上问题转成训练和治理资产。闭环包括用户反馈、人工审核标签、失败案例库、eval 更新、prompt/policy 修订、模型版本评估、发布门禁和线上监控。

从产品设计看，对齐不是“模型供应商已经做完的事”。它必须被嵌入用户旅程、业务流程、运营后台和风险治理。

Financial retail mapping: customer service, wealth advice, lending explanation, compliance assistant, AML narrative drafting

Customer service 是相对适合模型对齐发挥作用的场景。模型可以解释费用、账户流程、卡片权益、常见问题，但实时余额、客户身份、交易状态必须来自系统工具或数据库。

Wealth advice 是高风险场景，不能只依赖 RLHF。系统必须区分教育性信息、一般市场解释和个性化建议。个性化建议涉及适当性、风险承受能力、产品许可和持牌人员责任。

财富助手可以做投资概念解释、风险披露摘要、产品说明书转译、客户问题整理。它不应独立做收益承诺、明确买卖建议、忽视客户风险画像或规避监管披露。

Lending explanation 需要平衡透明度和风控保密。模型可以解释一般流程和 approved reason codes，但不能自行推断拒贷原因，也不能泄露可被利用的评分细节。

Compliance assistant 适合做检索、摘要、对照和初筛。它可以帮助合规人员汇总政策、对比流程、起草审查意见、标记潜在风险，但不能替代合规签字人。

AML narrative drafting 是高价值场景。模型可以把交易事实、账户行为、规则命中和调查记录组织成叙事，但事实来源必须来自案件系统，最终判断必须由调查员确认。

金融零售架构的基本原则是: 模型负责语言和初稿，系统负责事实和权限，人负责高风险判断，审计负责责任链。

Governance and eval implications: human preference, rubric, red-team, audit, release gates

Human preference 不能只是点赞或踩。企业需要结构化反馈，至少拆成指令遵循、事实正确、完整性、安全性、合规性、可解释性、语气和是否需要升级。

Rubric 是 AI 产品验收核心。没有 rubric，团队只能争论“感觉好不好”。金融零售 rubric 应明确是否暗示保证收益、是否越权建议、是否泄露隐私、是否误导客户、是否产生不公平待遇。

Red-team 应持续覆盖 prompt injection、越权请求、套取政策细节、绕过拒答、偏见诱导、幻觉压力测试、多轮诱导和业务边界攻击。

Audit 要回答: 当时使用哪个模型版本、哪个 system instruction、检索到哪些资料、调用哪些工具、谁审核过输出、用户最终看到了什么、是否触发策略或升级。

Release gates 应包括离线 eval 达标、红队严重问题关闭、合规审查通过、人工复核流程就绪、监控配置完成、回滚方案明确、试点范围受控、事故响应机制准备完成。

治理的关键不是把模型变得“永远正确”，而是让系统知道何时可信、何时不可信、何时需要控制、何时需要人接管。

Architecture ADRs: when to rely on model alignment vs external controls

ADR 1: 低风险文本任务可更多依赖模型对齐。适用 FAQ 改写、内部知识摘要、普通流程解释、文档初稿。剩余风险可通过抽检和反馈处理。

ADR 2: 事实性任务必须引入外部知识源。适用产品费率、账户规则、政策条款、实时市场信息。理由是 RLHF 不保证事实最新或准确，需要 RAG、数据库、引用和答案溯源。

ADR 3: 高风险决策不能依赖模型最终判断。适用授信审批、投资建议、AML 报告提交、客户投诉裁定。模型可辅助解释和准备材料，最终判断必须由规则系统、专家或受控流程完成。

ADR 4: 拒答策略要外部化。合规边界频繁变化、多国家业务线、需要审计策略变化时，不能把所有拒答逻辑压进 prompt 或模型权重。策略层应可配置、可测试、可回滚。

ADR 5: HITL 按风险分层。输出会影响客户权益、进入监管材料或触发业务执行时，应有人工责任链。低风险输出可抽检，高风险输出必须复核。

ADR 6: 模型输出必须区分内容生成和行动执行。生成建议文本是一类风险，调用工具执行交易、提交报告、修改账户是另一类风险，后者需要权限、审批和事务日志。

架构师的核心判断是: 模型对齐适合改善默认语言行为，外部控制适合处理事实、权限、责任和合规。

10 interview questions with answer outlines

1. InstructGPT 解决的核心问题是什么？答: Base LM 预测文本但不一定遵循用户意图，InstructGPT 用 SFT、reward model、PPO/RLHF 把人类偏好引入训练，让模型更像 helpful、honest、harmless 的助手。

2. SFT、reward model、PPO 分别做什么？答: SFT 学人类示范，reward model 学人类偏好，PPO 用奖励分数优化模型行为并控制偏离。

3. 为什么 RLHF 不等于事实正确？答: RLHF 优化偏好信号，偏好可能奖励流畅、自信和结构化。事实正确还需要检索、工具、专业数据、验证和 eval。

4. 什么是 sycophancy，为什么危险？答: Sycophancy 是迎合用户观点，可能同意错误前提。在金融和合规场景会放大客户误解、业务风险和不当建议。

5. Reward hacking 在 AI 产品中如何出现？答: 模型学习提高评分的表层模式，例如更长、更礼貌、更像免责声明，但没有真正提高事实质量和决策质量。

6. Constitutional AI 相比 RLHF 的核心变化是什么？答: 它引入显式原则，让模型依据原则 critique 和 revision，并用 AI feedback 支持训练，形成 RLAIF 思路。

7. 为什么企业不能只靠模型对齐？答: 对齐改善默认行为，但不能保证权限、事实、合规和审计。企业需要策略引擎、RAG、工具权限、日志、HITL 和发布门禁。

8. 金融零售中哪些场景适合模型直接回答？答: 低风险 FAQ、流程解释、教育性内容、文档摘要较适合。投资建议、授信、AML 判断、投诉裁定必须有外部控制和人工责任链。

9. 如何设计 RLHF 风格的业务反馈闭环？答: 定义 rubric，收集用户反馈和专家标注，建立失败案例库，更新 eval、prompt、policy 和训练数据，用发布门禁控制上线。

10. PM 如何避免“用户喜欢但不正确”的优化陷阱？答: 把满意度与事实性、安全性、合规性分开评估，关键场景引入专家审核和数据验证，不能只用点赞率作为成功指标。

Common misunderstandings

误解 1: RLHF 让模型真正理解了人类价值观。更准确说法是: RLHF 让模型更倾向于产生符合训练偏好的输出，不代表完整价值观理解。

误解 2: 人类偏好越多越好。更准确说法是: 数据质量、代表性、rubric 和审计比数量更重要。低质量偏好会稳定训练出错误行为。

误解 3: 拒答越多越安全。更准确说法是: 过度拒答会损害可用性。安全还包括替代帮助、澄清、范围限定和升级。

误解 4: Constitutional AI 可以完全替代人类。更准确说法是: RLAIF 可以扩展反馈能力，但原则制定、抽样审计和高风险判断仍需要人类治理。

误解 5: 对齐只是模型团队的事。更准确说法是: 对齐涉及产品定义、需求分析、架构控制、合规审查、运营反馈和上线治理。

误解 6: Prompt 写好就够了。更准确说法是: Prompt 是运行时约束，不是完整治理。复杂系统需要 policy、eval、权限、溯源、监控和 HITL。

误解 7: 通用 benchmark 高就能上业务。更准确说法是: 业务上线看场景 eval，金融零售尤其需要合规、事实、偏见、解释一致性和审计测试。

1-page executive summary

InstructGPT 的核心启发是: 语言模型默认学习如何续写文本，而 AI 助手需要学习如何遵循用户意图。这个差距就是对齐问题的产品起点。

InstructGPT 使用三段式流程。第一，用 supervised fine-tuning 学人类示范。第二，用 reward model 学人类偏好。第三，用 PPO/RLHF 优化模型，让它更倾向于生成高偏好回答。

Helpful、honest、harmless 是理解对齐的三角框架。Helpful 要求完成用户任务，honest 要求承认不确定性、不编造，harmless 要求避免安全、合规、隐私和财务伤害。

RLHF 的限制同样重要。它可能产生迎合用户、奖励黑客、重风格轻事实、隐藏偏见、过度拒答和 benchmark gaming。因此企业不能把 RLHF 当成万能安全层。

Constitutional AI 提供了后续思路。它用成文原则指导模型 critique、revision 和 AI feedback，有助于降低人工标注成本，并把原则显式化。但它仍需要人类制定原则、审计输出和管理高风险边界。

在金融零售中，模型对齐只能作为一层能力。低风险客服和流程解释可以更多依赖模型，财富建议、贷款解释、合规助手、AML narrative 等场景必须结合外部数据、策略控制、权限管理、人工复核和审计日志。

PM 的关键任务是把用户价值、风险边界和反馈闭环产品化。BA 的关键任务是把好回答拆成可标注、可验收、可审计的需求。架构师的关键任务是决定何时依赖模型对齐，何时必须使用外部控制。

最终结论: 对齐不是一个模型特性，而是一套产品、数据、训练、评估、治理和架构共同组成的系统能力。

Follow-up reading and practical exercises

Follow-up reading:

1. InstructGPT: Training language models to follow instructions with human feedback。
2. Constitutional AI: Harmlessness from AI Feedback。
3. OpenAI alignment and safety related system cards。
4. Anthropic research on helpful, honest, harmless assistants。
5. Research on sycophancy, reward hacking and scalable oversight。
6. Financial AI governance guidance from regulators in your target market。

Practical exercise 1: 写一个金融客服 SFT 样例集。选择 20 个银行客服问题，为每个问题写用户原始问题、理想回答、不合格回答、拒答或升级条件、评分 rubric。

Practical exercise 2: 设计一个偏好标注任务。给同一个贷款解释问题生成 3 个候选回答，比较哪个更清楚、更合规、更不误导、更适合客户阅读，并分析偏好是否可能奖励错误行为。

Practical exercise 3: 做一个 refusal policy 表。为财富管理助手设计 10 类拒答场景，每类写风险描述、可回答范围、必须拒绝的请求、安全替代回答、是否升级人工。

Practical exercise 4: 写一份架构 ADR。主题是是否允许 AI 助手独立生成贷款拒绝原因解释。建议结论是模型只能基于审批系统提供的 reason codes 生成自然语言解释，不能自行推断拒贷原因。

Practical exercise 5: 建立一个最小 eval 集。为金融零售 AI 助手设计 50 条 eval，覆盖正常客服、事实查询、投资边界、隐私请求、贷款解释、AML 敏感问题、越权诱导和多轮追问。

Practical exercise 6: 对比 RLHF 与 RLAIF 的治理成本。分析哪些反馈必须由专家给出，哪些 critique 可以由 AI 生成，哪些样本需要人工抽检，哪些场景不能用 AI feedback 替代人类判断。

实践目标不是复述论文，而是把论文变成可落地的产品规则、需求 rubric、架构 ADR 和上线治理机制。