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

• 明明原文没提到的东西，它非要脑补加上（幻觉）。

• 明明在角落里的关键信息，它视而不见（遗漏）。

• 你要的是 JSON 格式，它非要在结尾加一句“希望能帮到您！”。

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

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

---

1. 根本矛盾：“畅所欲言” vs “字字珠玑”

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

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

• 严格忠于原文（Evidence-based）：原文没说就不能写。

• 结构化输出（Schema-constrained）：必须严丝合缝地填入 JSON 或表格。

• 不重不漏（Precision & Recall）：不能多也不能少。 这是典型的“会计”工作。

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

---

2. 工业实战中的两大“翻车”现场

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

场景一：过度热情的“脑补怪” (The Redundancy Trap)

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

• 工业案例 —— 智能招聘系统（简历解析）： 你微调了一个模型来提取候选人的“技能标签”。

  • 原文： “候选人熟悉 Python 开发，使用过 Flask 框架。”

  • 模型提取结果： ``

  • 翻车原因： 模型在训练数据里见过太多“Python 程序员懂 Django 和 SQL”的搭配，于是它利用世界知识进行了“脑补”。

  • 后果： 你的系统把一个根本不懂数据库的候选人推给了面试官，浪费了所有人时间。

  • 学术解释： 这就是 SCIR 论文中提到的“冗余检测”痛点，模型倾向于生成它认为“应该存在”而非“确实存在”的内容 。

场景二：丢三落四的“马虎眼” (The Missing Trap)

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

• 工业案例 —— 金融合规审查（合同抽取）： 你需要从一份 50 页的投资协议中提取“风险条款”。

  • 原文： 在正文显眼处大谈收益，仅在第 48 页的脚注里写了一行：“如遇不可抗力，本金可能无法全额兑付。”

  • 模型提取结果： 提取了所有收益条款，唯独漏掉了这一条风险提示。

  • 翻车原因： 大模型在对齐训练中往往学习的是“大概率模式”。在大多数文本中，重要信息都在段首或正文，脚注往往是无关紧要的。模型学习到了这个“统计捷径”，从而导致了关键信息的遗漏** 。

---

3. 为什么传统微调（Fine-Tuning）救不了你？

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

• 只教“什么是对的”，不教“什么是错的”： 传统的微调数据集（如 OneKE 使用的数据）都是“正样本”——即 (Input, Correct Output) 。 这就像教小孩子做数学题，你只给他看标准答案，却从来不告诉他：“你这步算错了是因为进位忘了。” 结果就是，模型记住了答案的格式，但并没有学会“自我反思”。一旦遇到没见过的新题型，它依然会犯同样的逻辑错误。

• 甚至学坏了（Bias Learning）： 更糟糕的是，人工标注的数据集本身往往包含噪音。比如标注员在疲劳时漏标了一个实体。模型在微调时，会敏锐地捕捉到这种错误模式，并将其视为“规则”的一部分。SCIR 论文指出，传统微调无法消除这种标注盲点（Annotation Blind Spots），甚至会放大它 。

---

4. 破局思路：从“填鸭式教学”到“错题集训练”

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

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

1. 制造“错题集”： SCIR 的核心贡献之一是构建了一个 MBSC 数据集 。它的做法很反直觉：它不是让模型学正确答案，而是专门收集 GPT-4 等大模型犯错的例子（比如它哪里多提了、哪里漏提了）。

2. 训练“纠错官”： 利用这些错题，训练一个专门的检测模块（Critic）。这个模块不负责生成，只负责“挑刺”：

   • “你提取的‘Django’原文里有吗？（检测冗余）”

   • “第 48 页脚注那个条款你是不是漏了？（检测缺失）”

3. 闭环反馈： 通过这种“生成 -> 挑刺 -> 再生成”的闭环，不需要修改大模型的参数，就能强制让它对齐我们的需求。

总结

工业界的“偏好对齐”不仅仅是调参的问题，它是生成式 AI 本性与结构化业务需求之间的博弈。

下次当你发现你的模型又在“胡编乱造”或“粗心大意”时，请记住：它可能不是还没学会，而是它太想“表现自己”了。这时候，也许你需要的不是更多的数据，而是一套像 SCIR 这样带有“负反馈机制”的纠错工作流。