问题与目标
效果不好不等于应该微调。知识没有进入上下文、工具返回错误、输出格式不稳定和模型不理解行业语言,背后的修复手段完全不同。本篇建立一个决策框架,先定位问题发生在哪一层,再决定是否改变模型参数。
核心概念

| 方法 | 主要改变 | 适合解决 | 不适合解决 |
|---|---|---|---|
| Prompt | 单次请求的指令与示例 | 表达、格式、简单策略 | 持续更新的大量事实 |
| RAG | 运行时上下文 | 私有知识、可引用事实、频繁更新内容 | 稳定行为习惯和模型能力 |
| 继续预训练 | 模型对领域语料的统计表示 | 大量行业语言和领域表达 | 少量标注任务 |
| SFT | 指令到回答的行为映射 | 固定任务、风格、格式、工具调用示范 | 自动保证事实最新 |
| 偏好对齐 | 多个合理回答之间的选择倾向 | 安全、风格、推理策略、可验证奖励 | 修复错误工具与权限系统 |
改变参数的成本不只是一张 GPU。还包括数据许可、基线、评估、模型版本、训练复现、部署显存和后续回归。
可运行实现
下面用确定性规则生成一份“下一步实验建议”。它不能代替实验,但能防止一开始就把所有问题归因于模型。
python
def choose_method(case: dict) -> dict:
if case["external_tool_wrong"]:
return {"method": "fix_application", "reason": "错误来自工具或业务链路"}
if case["facts_change_often"] or case["needs_citation"]:
return {"method": "rag", "reason": "知识需要更新或引用"}
if case["few_examples_work"]:
return {"method": "prompt", "reason": "上下文示例已经能约束行为"}
if case["domain_corpus_size"] >= 100_000 and case["unknown_terms"]:
return {"method": "continued_pretraining", "reason": "需要吸收大量领域语言"}
if case["labeled_examples"] >= 500 and case["stable_task"]:
return {"method": "sft", "reason": "存在稳定任务和可评估示范"}
return {"method": "collect_evidence", "reason": "数据和问题证据不足"}
case = {
"external_tool_wrong": False,
"facts_change_often": True,
"needs_citation": True,
"few_examples_work": False,
"domain_corpus_size": 0,
"unknown_terms": False,
"labeled_examples": 2000,
"stable_task": True,
}
print(choose_method(case))
输入表示故障手册频繁更新且答案必须引用来源。即使有两千条标注数据,结果仍优先推荐 RAG,因为微调后的参数不能充当可审计知识库。
真正立项前应保存同一测试集上的 Prompt 基线、RAG 基线和目标指标。只有较轻方案达不到要求,且失败模式稳定,才升级到训练。
常见问题与排查
想用微调注入最新知识
训练样本无法提供实时更新和精确引用。频繁变化的事实优先放入数据库、知识库或工具。
Prompt 很长,所以一定要微调
先分析长 Prompt 中哪些是知识、示例和规则。知识适合检索,硬规则适合代码,重复行为示范才可能适合 SFT。
训练 Loss 降低就算成功
Loss 只说明训练目标变化。必须在独立任务集上比较正确率、格式、事实性、延迟和成本。
微调可以修复权限问题
模型行为不是安全边界。认证、授权、审批和幂等仍由应用层实现。
小结
选择技术的关键是定位要改变的层:上下文、外部知识、任务行为还是偏好。微调是有数据、有指标、有部署能力之后的工程决策,不是效果不佳时的默认按钮。
许可协议:CC BY-NC 4.0
更新于 1 小时前
觉得文章有帮助?点个赞吧!
0 条评论


