案例分析：通过安全微调降低模型幻觉

有一阵我特别怕模型一本正经地胡说。明明业务场景很窄，它却能把没见过的细节编得像真的一样，读着顺，核对就崩。后来我才慢慢接受一件事：单靠提示词拦幻觉，往往只是把问题往后推；真要稳一点，还是得把“安全微调”嵌进发现、定位、修复、复测那条闭环里。

我习惯先从数据侧找原因。训练和微调用的样本如果只覆盖了少数场景，模型一遇到边界输入就容易脑补；标注口径要是不统一，尤其是违规、价值观这类标签前后打架，噪声会直接写进行为里。来源也得能追溯——内部日志、公开集、合作方数据分清楚，第三方还要过安全扫描，不然你根本不知道幻觉是“学偏了”还是“被灌了脏东西”。

定位清楚之后，我才会动模型。源数据有问题就清洗、补多样化样本；模型本身爱跑偏，就做安全微调，或者再加一层专用安全小模型做约束。别指望一次调完就万事大吉：推理侧还得有实时哨兵盯输入、中间过程和输出，置信度低、重复度怪、语义飘太远就告警，必要时回滚到安全模式。完整请求响应日志也要留着，不然复盘只能靠猜。

修复后我会按内容安全、对抗安全、模型后门、供应链安全等维度重新扫一遍，对抗提示里故意塞敏感属性，看它会不会系统性跑偏。统计不同属性上的正负向比例，一旦偏差明显就回到整改，而不是“差不多能上线”。只有基线过了，我才愿意把它推进生产；模型每次迭代，也尽量把这套审计左移到发布流程里，而不是上线后再救火。

说白了，安全微调不是神奇补丁，而是整条治理链上的一环。你越早把幻觉当成可定位、可修复、可复测的工程问题，而不是玄学，后面睡得越踏实。