揭秘大模型微调中的【偏好对齐】陷阱-编程阁

在 AI 落地应用中，我们经常遇到一种令人抓狂的现象：你花大价钱微调了一个行业大模型，让它处理信息提取（Information Extraction, IE）任务，比如从合同中提取条款或从病历中提取诊断结果。然而，模型总是表现得像个“自作聪明”的实习生：

这在学术界被称为“偏好对齐困难”（Difficulty in Aligning Model Preferences）。简单来说，就是大模型原本的“天性”与我们要求的“严谨”发生了冲突。

今天，我们就来扒一扒这个工业界最隐蔽的痛点，以及为什么传统的微调（Fine-tuning）很难彻底解决它。

要理解这个问题，首先要明白 LLM（大语言模型）的“出厂设置”。 LLM 本质上是一个生成式模型，它的核心训练目标是预测下一个 token。它的天性是流畅、丰富、利用世界知识进行续写。这就像是一个“艺术家”，擅长发散思维。

而信息提取（IE）任务要求什么？

所谓的“偏好对齐困难”，就是当我们试图通过微调把一个“艺术家”改造成“会计”时，由于它骨子里的创作欲望（预训练偏好）太强，导致它经常“破功”。

这种对齐困难在工业界主要表现为两个极端的错误模式：冗余（Redundancy）和缺失（Missing）。

这是 LLM 最常见的毛病。由于它在预训练中学了太多的“世界知识”，它往往分不清“原文信息”和“它脑子里的知识”。

工业案例 —— 智能招聘系统（简历解析）：你微调了一个模型来提取候选人的“技能标签”。
- 原文：“候选人熟悉 Python 开发，使用过 Flask 框架。”
- 模型提取结果：``
- 翻车原因：模型在训练数据里见过太多“Python 程序员懂 Django 和 SQL”的搭配，于是它利用世界知识进行了“脑补”。
- 后果：你的系统把一个根本不懂数据库的候选人推给了面试官，浪费了所有人时间。
- 学术解释：这就是 SCIR 论文中提到的“冗余检测”痛点，模型倾向于生成它认为“应该存在”而非“确实存在”的内容。

当面对长文本或复杂结构时，LLM 往往会表现出“注意力涣散”，倾向于只提取最显眼的信息，而忽略边缘情况。

工业案例 —— 金融合规审查（合同抽取）：你需要从一份 50 页的投资协议中提取“风险条款”。
- 原文：在正文显眼处大谈收益，仅在第 48 页的脚注里写了一行：“如遇不可抗力，本金可能无法全额兑付。”
- 模型提取结果：提取了所有收益条款，唯独漏掉了这一条风险提示。
- 翻车原因：大模型在对齐训练中往往学习的是“大概率模式”。在大多数文本中，重要信息都在段首或正文，脚注往往是无关紧要的。模型学习到了这个“统计捷径”，从而导致了关键信息的遗漏** 。

你可能会问：“模型不听话，我多给它喂点数据（SFT）不就行了吗？” 遗憾的是，传统的指令微调（Instruction Tuning）存在一个致命的**“静态陷阱”**。

只教“什么是对的”，不教“什么是错的”：传统的微调数据集（如 OneKE 使用的数据）都是“正样本”——即(Input, Correct Output)。这就像教小孩子做数学题，你只给他看标准答案，却从来不告诉他：“你这步算错了是因为进位忘了。” 结果就是，模型记住了答案的格式，但并没有学会“自我反思”。一旦遇到没见过的新题型，它依然会犯同样的逻辑错误。
甚至学坏了（Bias Learning）：更糟糕的是，人工标注的数据集本身往往包含噪音。比如标注员在疲劳时漏标了一个实体。模型在微调时，会敏锐地捕捉到这种错误模式，并将其视为“规则”的一部分。SCIR 论文指出，传统微调无法消除这种标注盲点（Annotation Blind Spots），甚至会放大它。

既然单纯的“喂数据”解决不了偏好对齐，最新的研究方向开始转向**“基于错误的学习”（Error-Driven Learning）**。

最新的SCIR 框架提供了一个绝佳的思路：与其强行改变“艺术家”的大脑，不如给他配一个苛刻的“质检员”。

制造“错题集”：SCIR 的核心贡献之一是构建了一个MBSC 数据集。它的做法很反直觉：它不是让模型学正确答案，而是专门收集 GPT-4 等大模型犯错的例子（比如它哪里多提了、哪里漏提了）。
训练“纠错官”：利用这些错题，训练一个专门的检测模块（Critic）。这个模块不负责生成，只负责“挑刺”：
- “你提取的‘Django’原文里有吗？（检测冗余）”
- “第 48 页脚注那个条款你是不是漏了？（检测缺失）”
闭环反馈：通过这种“生成 -> 挑刺 -> 再生成”的闭环，不需要修改大模型的参数，就能强制让它对齐我们的需求。