后训练技术正处在一个奇特的阶段：它已经成为大模型产品化的主战场，但整个领域还没有一张统一的地图。很多团队在做微调、做对齐、做检索增强，却说不清楚自己用的技术在整个后训练体系里处于什么位置，也说不清楚这些技术选择在合规审计、模型备案、供应链评估时意味着什么。
这篇文章想解决一个问题：如何把“后训练自适应技术”这个庞大而混乱的领域，拆成六个可判断、可沟通、可治理的维度。我会给出一个完整的六维分类法，把 LoRA、SFT、RLHF、DPO、RAG、推理时控制这些散落的术语放进同一个坐标系里，并且说明这套分类法如何直接用于 AI 治理场景——包括模型卡登记、风险评估、审计追踪和供应链选型。
这不是一篇纯理论文章。每个维度我都会给出可操作的判断标准、最小代码示例和治理建议。读完之后，你应该能对自己正在用的后训练技术做一次“六维体检”，也能在团队讨论技术选型或合规评估时，用同一套语言和别人对齐。
1. 为什么需要一张后训练技术地图
大模型开发流程里，预训练只是第一步。真正决定一个模型能否在具体业务里稳定可用、安全可控的，是后面的自适应环节。但现在的问题是，这个环节的技术名词太多、太碎，而且彼此之间的边界正在模糊。
过去我们习惯把微调分成全量微调和参数高效微调，把对齐方法分成基于人类反馈的强化学习和直接偏好优化，把知识增强归给检索增强生成。在实际项目里，这些技术经常混合使用，团队内部沟通时各说各话：算法工程师说“我们做了 LoRA”，业务方问“那这个模型到底能不能用于客服场景”，安全合规的人问“这个模型上线前做了什么对齐、评估和备份”。三者之间没有一张共同的地图，讨论就很难收敛。
六维分类法提供的正是这张地图。它不关心具体某一个算法的内部细节，而是从六个关键属性去描述一种后训练方案：数据依赖程度、参数更新范围、优化信号类型、控制时机、知识载体和可治理性。任何一个后训练技术，都可以在这六个维度上找到自己的坐标。这样，团队可以用同一种结构化语言来描述技术选择、评估风险和审计流程。
更实际的好处是：当模型出现问题时，这张地图能帮助快速定位问题来源。比如模型输出不稳定，可能和参数更新维度有关；回答事实性错误，可能和知识载体维度有关；输出有害内容，可能和优化信号维度有关。按照维度排查，比漫无目的地调参数要有效得多。
2. 六维分类法总览
六维分类法的设计目标，是让每一种后训练自适应技术都可以被描述成一个六元组。每个维度是一个连续谱系，不是非黑即白的离散类别，但为了方便工程沟通，我会在每个维度上划分出几个典型区间。
| 维度 | 核心问题 | 典型区间 | 代表技术 |
|---|---|---|---|
| 数据依赖 | 需要多少人工标注或反馈数据 | 零样本、少样本、全量监督 | In-Context Learning、SFT、专家标注微调 |
| 参数更新 | 模型权重在多大范围内被修改 | 无参数、参数高效、全量微调 | RAG、LoRA/Adapter、Full Fine-tuning |
| 优化信号 | 用什么目标信号来引导模型变化 | 模仿信号、偏好信号、能力信号 | SFT、RLHF/DPO、工具使用强化训练 |
| 控制时机 | 调整发生在训练阶段还是推理阶段 | 训练时控制、推理时控制 | RLHF、解码约束、测试时适应 |
| 知识载体 | 新知识存储在参数内部还是外部 | 参数化知识、非参数化知识 | 继续预训练、RAG |
| 可治理性 | 变更是否可审计、可验证、可回滚 | 弱治理、中等治理、强治理 | 黑盒提示、带评估和回滚的微调流水线 |
这张表是全文的主心骨。接下来每一节展开一个维度，讲清楚判断标准、实际工程含义，以及它在 AI 治理语境下为什么重要。
需要说明的是，这六个维度不是完全正交的。在实际技术方案中，参数更新方式会影响可治理性，知识载体的选择也会影响数据依赖。六维分类法的价值不在于把技术硬分成六个互不相交的抽屉，而在于提供一套完整的观察视角，避免只从单一维度做判断。
3. 维度一：数据依赖
3.1 从零标注到全量监督的谱系
数据依赖维度回答的问题是：这项后训练技术需要什么样的人工监督数据，以及需要多少。
谱系的一端是零样本方法。典型代表是上下文学习，也就是把示例直接写进 Prompt，模型不更新任何参数，也不依赖离线标注数据。零样本方法成本最低、速度最快，但能力上限受限于模型的上下文窗口和已有知识。
谱系的中间是少样本方法。典型代表是少量示例微调，比如用几十条到几百条对话记录做轻量级 SFT。少样本方法在数据获取成本和质量控制之间取得了一个平衡点，是目前很多中小团队切入后训练的起点。
谱系的另一端是全量监督。典型代表是大型 SFT 数据集上的全量微调，以及依赖大规模人工反馈数据的 RLHF。全量监督方法能带来最彻底的行为改变，但数据工程成本极高，而且数据质量直接决定效果上限，标注偏差会在训练中被放大。
3.2 数据依赖与 AI 治理的关联
从治理角度看，数据依赖维度直接决定了训练数据的可审计性。零样本方法几乎不存在数据合规风险，因为训练阶段根本不引入新数据；全量监督方法则需要回答一系列问题：标注数据从哪来、是否包含个人信息、标注协议是否合规、数据版本是否可追溯。
实际项目中一个容易被低估的成本是数据清洗。很多团队以为微调就是把数据整理成 JSON 丢给训练脚本，真正跑起来才发现重复样本、格式错误、标签不一致会消耗大量调试时间。我倾向于把数据依赖维度的治理动作拆成三层：原始数据来源记录、清洗后的数据集版本登记、训练数据与最终行为变化的对应关系分析。这三样东西，在审计时都是硬通货。
4. 维度二：参数更新
4.1 无参数、参数高效与全量微调
参数更新维度回答的问题是：为了让模型适应新任务，我们对模型权重做了多大改动。
最轻的一档是无参数更新。典型实现是检索增强生成：模型权重完全不变，通过外部检索将相关知识拼进 Prompt。无参数方法几乎不改变模型本身的分布，因此行为可预测性最高，出现“权重损坏”这类问题的概率极低。
中间一档是参数高效微调。典型代表是 LoRA、Prefix Tuning、Adapter。这类方法只训练一小部分新增参数，冻结原始权重，训练成本大幅下降，而且可以针对多个下游任务保留多套增量权重，便于切换和回退。LoRA 是当前工程实践里使用最广泛的参数高效方法之一，HuggingFace PEFT 库提供了比较成熟的实现。
最重的一档是全量微调。所有模型权重都会更新，模型的内部分布可能发生全局性改变。全量微调的表达能力强，但训练成本高，而且很容易破坏预训练阶段已经具备的通用能力，也就是通常所说的灾难性遗忘。
4.2 参数更新维度的最小实践示例
下面是一个基于 PEFT 做 LoRA 微调的最小配置示例。这里的重点是展示参数高效微调与全量微调在工程配置上的差异，实际运行需要结合具体数据集和底座模型。
# 文件路径：examples/lora_config.py from peft import LoraConfig, TaskType, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer # 1. 定义 LoRA 配置 lora_config = LoraConfig( task_type=TaskType.CAUSAL_LM, r=8, lora_alpha=16, target_modules=["q_proj", "v_proj"], lora_dropout=0.05, bias="none", ) # 2. 加载底座模型（以 Qwen 为例，版本以实际项目为准） model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") # 3. 将模型包装为 PEFT 模型 peft_model = get_peft_model(model, lora_config) # 4. 查看可训练参数量 peft_model.print_trainable_parameters()# 文件路径：examples/lora_config.yaml # 也可以使用 YAML 配置驱动训练脚本 task_type: causal_lm r: 8 lora_alpha: 16 target_modules: - q_proj - v_proj lora_dropout: 0.05 bias: none# 文件路径：examples/train_lora.sh # 使用 transformers 的 Trainer 训练 LoRA 模型 python examples/train_lora.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --lora_config examples/lora_config.yaml \ --train_data_path data/chat_samples.jsonl \ --output_dir output/lora-checkpoint \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 2e-4这段代码的关键点在target_modules和r的设置。LoRA 只对注意力层的 q_proj 和 v_proj 注入低秩矩阵，所以训练参数量通常只有全量参数的 1% 左右。print_trainable_parameters()会输出具体数字，这是验证参数高效微调是否生效的最直接方法。
4.3 参数更新维度的治理含义
参数更新维度对 AI 治理最直接的贡献，是提供了“回滚能力”的判断依据。无参数方法和参数高效微调天然支持多版本切换：底座模型不变，外面挂不同增量权重，出问题时换回旧权重即可。全量微调则很难做到细粒度回滚，因为你无法仅凭一个 checkpoint 判断某个具体行为变化是从哪一批训练数据来的。
在供应链审计场景中，参数更新维度也是评估第三方模型服务的重要指标。如果某个模型服务商声称做了模型定制，但无法说明更新发生在哪个参数层级，那么它的可回滚性和可验证性就要被打上问号。
5. 维度三：优化信号
5.1 模仿、偏好与能力信号
优化信号维度回答的问题是：模型在自适应过程中，靠什么信号来调整行为。
第一类信号是模仿信号。模型被要求直接模仿人类提供的标准答案，典型技术是 SFT。模仿信号的优点是直接、稳定，缺点是上限受限于标注数据的质量。如果标注答案本身就是平庸的，模型学到的也就是平庸的输出。
第二类信号是偏好信号。模型不再模仿单一答案，而是学习对比多候选答案之间的优劣。典型技术是 RLHF 和 DPO。偏好信号能利用“哪个更好”这种相对判断，比绝对标注更符合人类评价的直觉。RLHF 需要训练奖励模型，流程复杂；DPO 则直接使用偏好对构造损失函数，工程上更简洁。
第三类信号是能力信号。模型通过环境反馈来提升特定能力，典型场景是工具调用、代码执行的强化训练。比如智能体框架中，模型调用工具后获得的成功或失败结果就是一种能力信号。这类信号的难点在于环境反馈可能不稳定，需要设计合理的奖励规则。
5.2 DPO 损失的最小实现
DPO 相比 RLHF 的最大优势，是把偏好对齐转化为一个简单的监督损失，不需要单独训练奖励模型。下面是一个简化版 DPO 损失实现，帮助理解优化信号如何在训练中起作用。
# 文件路径：examples/dpo_loss.py import torch import torch.nn.functional as F def dpo_loss(policy_logps, ref_logps, beta=0.1): """ 简化版 DPO 损失。 policy_logps: 当前策略模型对偏好对中 chosen 和 rejected 的 log 概率 ref_logps: 参考模型（通常是 SFT 模型）对同一个偏好对的 log 概率 排列约定: [chosen_logps, rejected_logps] """ chosen_policy, rejected_policy = policy_logps chosen_ref, rejected_ref = ref_logps # 计算当前策略相对参考模型的 log 概率差 policy_ratio = chosen_policy - rejected_policy ref_ratio = chosen_ref - rejected_ref # DPO 核心：让 chosen 相对 rejected 的差距尽量大于参考模型 logits = policy_ratio - ref_ratio loss = -F.logsigmoid(beta * logits) return loss这段代码中，beta控制对齐强度。beta越大，模型越倾向于拉大 chosen 和 rejected 之间的距离，但过大会导致模型在偏好对上学过头，损失通用能力。实际项目中，beta通常需要在小验证集上做几次实验才能确定。
5.3 优化信号与治理风险
从治理角度看，优化信号决定了模型行为偏移的方向。模仿信号的风险是“标注即偏见”，偏好信号的风险是“偏好数据中的系统性偏差被放大”，能力信号的风险是“环境奖励被钻空子”——模型可能找到一种在评估指标上高分、但实际体验很差的策略。
审计时要特别关注优化信号的数据来源。对于偏好信号，至少要记录三件事：偏好对是怎么构造的、标注者的背景和分歧情况、以及偏好数据在训练集和验证集上的分布。这些信息在 AI 治理报告中是核心组成部分。
6. 维度四：控制时机
6.1 训练时控制与推理时控制
控制时机维度回答的问题是：自适应行为是在模型训练阶段固化下来的，还是在使用阶段动态施加的。
训练时控制的典型代表是 SFT、RLHF、DPO。模型行为改变是持久化的，一旦训练完成，行为变化就写进权重里。训练时控制的优点是稳定、不需要在推理链路中增加额外逻辑，缺点是修改成本高，每次行为调整都需要重新训练和评估。
推理时控制的典型代表包括解码参数调整、Logit 偏置、分类器引导、测试时适应。模型权重不改变，通过在生成过程中施加约束来改变输出。推理时控制的最大优点是可以动态调整，比如在低风险场景放开约束，在高风险场景收紧约束。
6.2 推理时控制的代码示例
下面是一个通过 Logit 偏置实现推理时控制的简单示例，思路是不修改模型权重，在解码阶段压制或增强某些 token 的概率。
# 文件路径：examples/inference_time_control.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") def generate_with_logit_bias(prompt, bias_token_ids, bias_value=2.0, max_new_tokens=64): inputs = tokenizer(prompt, return_tensors="pt") # 构造 logits_processor from transformers import LogitsProcessor class BiasLogitsProcessor(LogitsProcessor): def __call__(self, input_ids, scores): for token_id in bias_token_ids: scores[:, token_id] += bias_value return scores outputs = model.generate( **inputs, max_new_tokens=max_new_tokens, logits_processor=[BiasLogitsProcessor()], ) return tokenizer.decode(outputs[0], skip_special_tokens=True) # 示例：增强特定 token 的生成概率 result = generate_with_logit_bias( "请给出产品的安全建议：", bias_token_ids=[12215, 8975], # 实际 token id 需根据 tokenizer 查询 bias_value=2.0, ) print(result)这里真正体现推理时控制价值的地方，是“不改变模型权重就能调整行为”这一点。在治理实践中，这意味着你可以在不重新走一遍训练和评估流程的情况下，对线上模型施加临时约束。但代价是，推理时控制依赖解码阶段的逻辑，会增加响应延迟，而且控制效果没有训练时控制那么彻底。
6.3 治理场景下的控制时机选择
高风险场景中，最稳妥的治理策略往往是“训练时控制定底线，推理时控制做动态调节”。训练时控制保证模型的主要行为符合预期，推理时控制在特定时期或特定用户群体上追加约束，比如敏感话题收紧、新政策上线时快速响应。
7. 维度五：知识载体
7.1 参数化知识与非参数化知识
知识载体维度回答的问题是：模型新的知识存在哪里。
参数化知识的代表是继续预训练和全量微调。知识被编码进模型的权重参数中，优点是推理时不需要额外检索，响应速度快；缺点是知识更新成本高，改知识等于重新训练，而且知识的具体存储位置不可解释，出了问题很难定位。
非参数化知识的代表是 RAG。知识存储在外部向量数据库或文档系统中，使用时通过检索把相关知识拼进 Prompt。非参数化知识的最大优势是知识可更新、可追溯，每一条知识都能找到原始来源；劣势是检索质量直接决定生成质量，检索不到就答不好。
7.2 一个最小 RAG 检索示例
下面这个示例演示了非参数化知识的基本流程：先把文档切片并向量化，再根据用户问题检索最相关的片段。
# 文件路径：examples/rag_retrieval.py from sentence_transformers import SentenceTransformer import numpy as np # 1. 加载 embedding 模型（版本以实际项目为准） embedder = SentenceTransformer("BAAI/bge-small-zh-v1.5") # 2. 构造文档切片 documents = [ "模型微调前必须完成数据清洗和去重。", "生产环境部署前需要做安全评估。", "用户反馈数据用于训练前需要脱敏。" ] # 3. 文档向量化 doc_embeddings = embedder.encode(documents, normalize_embeddings=True) # 4. 检索：计算用户问题与文档的相似度 query = "微调前需要做什么准备？" query_embedding = embedder.encode(query, normalize_embeddings=True) scores = np.dot(doc_embeddings, query_embedding) best_idx = int(np.argmax(scores)) print(f"最相关的文档片段：{documents[best_idx]}") print(f"相似度分数：{scores[best_idx]:.4f}")这个示例是 RAG 流程的检索部分。实际项目中，还需要将检索结果拼进 Prompt，再交给大模型生成最终答案。这里的关键教训是：RAG 的效果上限取决于检索质量，而不是生成模型的能力。
7.3 知识源可追溯性是治理刚需
从治理角度讲，非参数化知识天然具备一个巨大优势：知识可追溯。模型回答引用的内容可以回溯到具体文档、具体版本、具体来源。这在金融、医疗、法律等强合规场景中几乎是刚需。参数化知识则很难做到这一点，即使模型输出的内容是正确的，你也无法证明它依据的是哪些训练材料。
8. 维度六：可治理性
8.1 可审计、可验证、可回滚
可治理性维度不是某一个具体技术，而是对前五个维度的一层“元评价”。它回答的问题是：当这套后训练方案出现问题时，我们能否快速发现、准确定位、安全回退。
一个后训练方案的可治理性，可以从三个问题来评估：
第一，可审计性。训练数据、处理流程、模型权重、评估结果是否保留完整记录？如果一条训练数据最终导致了模型行为变化，能不能找到证据链？
第二，可验证性。模型变更后，是否有一组稳定的评估用例来验证行为变化是预期的？评估集是否覆盖了安全、公平、事实性等多个维度？
第三，可回滚性。新方案出现问题时，能否快速回到上一个稳定状态？回滚的代价有多大？
8.2 可治理性的分级标准
| 治理级别 | 可审计性 | 可验证性 | 可回滚性 | 典型场景 |
|---|---|---|---|---|
| 弱治理 | 无记录或记录零散 | 仅测评少量示例 | 无回滚机制 | 临时实验、个人项目 |
| 中等治理 | 有训练日志和评估报告 | 有标准化评测集 | 可通过备份回滚 | 内部工具模型 |
| 强治理 | 全链路可追溯 | 自动化评测流水线 | 多版本灰度切换 | 金融、医疗等高合规场景 |
在 AI 治理语境下，模型上线之前的后训练方案选择，需要提前考虑可治理性。很多团队是在出问题之后才意识到可治理性的重要，但到那时，补记录的成本已经很高了。
9. 六维分类法在 AI 治理中的应用框架
9.1 用模型卡承载六维信息
六维分类法最直接的落地方式，是把每一个模型的六维坐标写进模型卡。下面是一个简化的模型卡示例。
# 模型卡：客服问答模型 v2.3 ## 后训练技术六维描述 - 数据依赖：少样本（3000 条人工标注对话） - 参数更新：参数高效（LoRA，r=8） - 优化信号：模仿信号为主，辅以少量偏好信号（DPO） - 控制时机：训练时控制为主，推理时增加了敏感词 Logit 偏置 - 知识载体：非参数化知识（RAG，知识库版本 2025-01-15） - 可治理性：中等治理，有评估报告和权重备份，无自动化灰度切换 ## 评估结果 - 意图识别准确率：91.2% - 有害内容拦截率：99.1% - 幻觉率：3.4% ## 风险说明 - 知识库更新存在 1 天延迟 - DPO 偏好数据来自众包标注，存在轻微的性别倾向偏差这种模型卡的价值在于，任何读到它的人，即使没有参与训练过程，也能快速理解这个模型的后训练方案、风险点和治理边界。
9.2 高风险场景下的治理清单
在医疗、金融等高风险场景中，团队可以用六维分类法生成一份治理检查清单：
- 数据依赖维度：训练数据的来源链路是否清晰？是否包含个人信息？
- 参数更新维度：模型是增量更新还是全量更新？回滚机制是否已测试？
- 优化信号维度：偏好数据的标注协议是否完整？分歧率是否记录？
- 控制时机维度：训练时控制和推理时控制分别覆盖了哪些风险？
- 知识载体维度：知识来源是否有版本和责任人？能否追溯到原始文档？
- 可治理性维度：是否有评估流水线？评估集能否覆盖核心风险？
每一个问题都要有具体负责人和记录，而不是泛泛而谈。
10. 常见问题与排查思路
在实际使用这套分类法的过程中，团队经常会遇到一些典型问题。下面整理成排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 微调后模型通用能力明显下降 | 参数更新维度选择过重，全量微调导致灾难性遗忘 | 对比微调前后在通用评测集上的得分 | 改用 LoRA 等参数高效方法，或增加通用能力数据比例 |
| 模型输出事实性错误但风格很好 | 知识载体维度可能过度依赖参数化知识，缺乏外部检索 | 检查模型回答能否回溯到知识源 | 引入 RAG，让关键事实来自可追溯的外部知识库 |
| DPO 训练后模型过于激进，回答风格单一 | 优化信号维度中 beta 参数过大，偏好对齐过度 | 检查偏好对差异的分布，评估模型在验证集上的多样性 | 降低 beta，增加多样性指标进评测集 |
| 敏感场景下模型行为无法快速调整 | 控制时机维度只做了训练时控制，缺少推理时控制机制 | 检查推理链路是否支持 Logit 偏置或分类器引导 | 在推理阶段加入可配置的约束处理器 |
| 审计时无法说清训练数据来源 | 数据依赖维度的记录缺失 | 检查训练数据是否登记了版本、来源、清洗流程 | 建立数据版本管理，从下一次微调开始强制登记 |
| 模型出问题后无法快速回滚 | 可治理性维度中回滚机制未设计 | 检查是否保存了多个 checkpoint 和增量权重 | 使用参数高效微调，保留多个安全版本，测试切换流程 |
11. 工程建议与最佳实践
11.1 建立六维坐标的评审机制
建议在每一个后训练任务立项时，先填写一份六维坐标表，而不是直接开始写训练脚本。这个习惯可以帮团队在动手前想清楚：到底需要多少数据、更新多少参数、用什么信号、在哪个时机控制、知识放哪里、出问题怎么回滚。很多时候，填完这张表，就会发现项目其实不需要全量微调，用 LoRA 加 RAG 就能达到目标。
11.2 把治理动作嵌入训练流水线
可治理性不是事后补充的工作，而是应该在训练流水线中自动完成的动作。具体来说，每跑一次微调，至少提交以下产物：
- 训练数据版本号和清洗记录
- 模型权重文件和 LoRA 增量权重
- 评估报告，包含安全、事实性、通用能力指标
- 从训练数据到行为变化的简要对齐说明
这些产物在出问题时是排查依据，在接受审计时是合规证明。建议把这些步骤写进 CI/CD 流水线，而不是靠人工整理。
11.3 慎用全量微调，优先考虑增量组合方案
从工程实践和治理两个角度看，全量微调都不是最优选择。工程上，它成本高、周期长、容易遗忘；治理上，它可解释性差、可回滚性弱。更稳妥的组合方案是：LoRA 做核心能力微调，DPO 做对齐优化，RAG 负责知识更新，推理时控制做动态约束。这套组合在成本、效果和可治理性之间的平衡通常更好。
11.4 给读者的行动建议
如果你准备在项目里引入这套分类法，建议从一次小规模的“后训练方案盘点”开始。把你目前正在使用或计划使用的后训练技术，按照六个维度各写一行描述，然后和团队过一遍。你会发现，原本说不清楚的分歧会迅速收敛。接下来再针对每一个维度，建立对应的记录和验证方式，逐步形成团队内部的后训练技术地图。
