5.1 全书方法论回顾与低成本微调的能力边界：什么能解、什么解不了

5.1 全书方法论回顾与低成本微调的能力边界：什么能解、什么解不了

写这一节的时候，我特意把整本教程翻了一遍，想理清楚一件事——读者读完这本讲 LoRA 和 QLoRA 微调 GLM-5.2 的教程，到底带走的是什么。如果只带走了"怎么写 LoRA 配置"，那这本教程是失败的；如果带走了"遇到新模型新任务时，怎么判断该用什么适配方案的思考框架"，那才达到目的。

所以这一节我不重复具体的配置参数，而是把全书的方法论收拢成一个判断框架，然后诚实地聊聊 LoRA/QLoRA 这套低成本微调方案的能力边界——什么任务它能解、什么任务它解不了。承认局限比夸大能力重要，因为用错场景比不用更糟。

方法论回顾：从"要不要微调"到"形成自己的框架"

我把整本书的判断逻辑串成一条线。这条线不是"四步走"的流程图，是每次面对新任务时我自己的实际思考路径。

第一个判断点：要不要微调。这是最容易被跳过的一步，但也是最关键的。很多人一上来就考虑微调，但其实应该先问——这个任务真的需要微调吗？我自己判断的标准是：先尝试 in-context learning（few-shot 示例）和 prompt engineering，如果效果不够好，再考虑微调。因为 ICL 的成本几乎为零（不训练，只改 prompt），微调的成本是确定的工程投入。把"是否需要微调"这一步做扎实，能省掉大量不必要的训练。

我帮团队评估过很多"想微调"的需求，至少一半最后发现用 ICL + 好 prompt 就够了。一个真实案例：某团队想微调 GLM-5.2 做客服意图分类，数据集几百条。我看了一眼他们的 prompt，发现 prompt 写得非常粗糙（没有任务说明、没有示例、没有输出格式约束）。我让他们先把 prompt 重写好、加 few-shot 示例，准确率从 60% 提到 85%，根本不需要微调。这种"prompt 没调好就想微调"的陷阱，是新手最常掉进去的。

第二个判断点：微调的话，用 LoRA 还是全参数。如果确定要微调，下一个判断是 LoRA（含 QLoRA）够不够，还是必须上全参数微调。这个判断的核心是——任务的复杂度有多高、有没有足够的算力和数据。

我的判断标准大概是这样：任务是"调整模型行为"（语气、格式、风格）→ LoRA 够用。任务是"注入领域知识"（医学、法律专业知识）→ LoRA 可能不够，需要全参数微调或者 RAG。任务是"显著改变能力"（教模型一门新语言、新的推理模式）→ LoRA 几乎肯定不够。数据量小（< 几千条）→ LoRA 更稳，全参数容易过拟合。数据量大（> 几十万条）且有算力 → 全参数收益可能更大。

第三个判断点：用 LoRA 的话，QLoRA 还是普通 LoRA。如果 LoRA 够用，再判断显存够不够跑普通 LoRA（FP16/BF16 训练）。够的话用普通 LoRA（更稳、精度更好），不够的话上 QLoRA（4-bit 量化基座 + LoRA）。这个判断主要是显存约束驱动的，前面章节详细讲过算账方法。

第四个判断点：配置怎么调。LoRA 的关键超参——rank（r）、alpha、target_modules、learning rate——前面章节给了具体调优方法。这里的方法论是：先从保守配置起步（r=8、alpha=16、target_modules = 所有线性层），跑通后再根据 loss 曲线和验证集表现逐步调优。

第五个判断点：评估与上线。微调完不评估就上线是大忌。评估要看业务指标（不是 loss），要对比微调前后的输出质量，要在真实业务场景验证。上线要监控，发现回归及时回滚。

这五个判断点串起来，就是我面对任何微调任务时的思考框架。它不是机械的流程，是反复迭代的——评估后发现效果不够，可能要回到第一步重新判断"要不要换方案"。

LoRA 的能力边界：它能解什么

讲完框架，重点聊聊 LoRA 的能力边界。这是我最想强调的部分，因为 LoRA 这几年被吹得有点过，很多人把它当万能解。

LoRA 能解的问题，本质是"低维度的行为调整"。LoRA 的原理是假设权重更新矩阵是低秩的（rank 远小于权重矩阵的维度），所以用两个小矩阵的乘积来近似。这个假设成立的话，LoRA 就有效。具体到任务上，LoRA 能比较好地解决：

• 风格和语气调整：让模型说话更正式/更口语化、更简洁/更详细。这类调整本质是低维度的（风格维度有限），LoRA 表现很好。
• 输出格式控制：让模型严格按 JSON、按表格、按特定模板输出。格式约束是相对简单的行为调整。
• 任务路由和意图识别：分类、聚类这类任务，模型本身能力够，只需要小幅调整就能精准。
• 特定场景的指令遵循：让模型更好地遵循特定场景的指令（比如客服场景的应答策略）。

这些任务的共同特征是——不需要注入大量新知识，只需要调整模型已有能力的"调用方式"。LoRA 在这种场景下效果好、训练快、成本低，是性价比最高的方案。

我自己做过一个典型的 LoRA 项目——给 GLM-5.2 微调客服对话风格，数据几千条对话，r=16，训练两小时，效果非常显著（客服满意度从 70% 提到 88%）。这种任务就是 LoRA 的甜区。

LoRA 解不了的：要诚实承认的局限

但 LoRA 有它解不了的问题，下面几类是我在实际项目中反复验证过的"LoRA 失效场景"：

需要注入大量领域知识的任务。LoRA 是低秩更新，参数量有限（几百万到几千万），存不下大量新知识。如果你的任务是"让模型回答医学专业问题"，而 GLM-5.2 本身医学知识不足，LoRA 微调几乎无解——你硬塞也塞不进去，反而会破坏模型原有能力。这种场景应该用 RAG（检索增强生成），让模型在推理时检索外部知识库，而不是把知识塞进权重。我自己测过，"知识注入"类任务用 RAG 比用 LoRA 准确率高 30-50%。

需要显著改变模型能力的任务。比如教一门 GLM-5.2 完全不会的语言、教一种新的推理模式、教一个完全陌生的领域。这类任务要求模型学到根本性的新东西，低秩近似无法承载这种深度变化。全参数微调（如果有算力和数据）或者干脆换一个本身就有这种能力的模型，是更现实的选择。

对模型推理能力有显著要求的任务。LoRA 微调有时会"破坏"模型原有的推理能力——训练数据偏向某个任务后，模型在其他任务（特别是需要泛化推理的任务）上表现下降。这是我反复踩过的坑：微调后业务指标上去了，但模型整体推理能力掉了一截，这种隐性回归很难发现，但上线后会被用户感知到。

数据量极小的任务。几十条、几百条数据，LoRA 也能跑，但泛化性很差，过拟合严重。这种场景更应该用 ICL 或者 RAG，而不是 LoRA。

需要严格的可解释性和可控性的任务。LoRA 微调后的模型是"黑盒调整"，你很难精确解释它学到了什么、为什么在某些输入上表现变了。如果你的业务需要严格的可解释性（比如金融、医疗的某些场景），规则系统 + RAG 比微调更适合。

一个判断框架：什么时候用 LoRA、什么时候换方案

把"能解"和"解不了"综合起来，我给一个更可操作的判断框架。当面对一个新任务时，按这个顺序问自己：

第一步：任务是"调行为"还是"塞知识"？ 调行为 → LoRA 可能可以。塞知识 → 考虑 RAG。

第二步：模型本身有相关能力吗？ 有 → LoRA 能把它"激活"或"调整"。没有 → LoRA 解不了，换模型或上 RAG。

第三步：数据量够吗？ 至少几千条带标签数据 → LoRA 可行。数据少 → 先 ICL 或 RAG。

第四步：能接受黑盒调整吗？ 能接受 → LoRA 可以。需要严格可控 → 规则 + RAG。

第五步：算力够吗？ 显存够 FP16 → 普通 LoRA。只够 INT4 → QLoRA。算力极其有限 → ICL 或 API 调用。

这五步走完，方案空间就被收敛到一个相对明确的范围。剩下的就是执行——具体怎么调 LoRA 的超参、怎么准备数据、怎么评估，前面四章已经讲透了。

反复出现的几个误区

最后列几个我在帮人评估时反复看到的误区：

误区一：一上来就想微调。很多需求其实不需要微调，prompt + ICL 就够。先穷尽非训练方案，再考虑微调。

误区二：用 loss 评估微调效果。loss 下降不等于业务效果提升。必须用业务相关指标评估。

误区三：微调完不对比基座。不对比就不知道 LoRA 带来的实际收益（可能是正也可能是负）。每次微调都要和原始 GLM-5.2 在同一组测试集上对比。

误区四：迷信 rank 越大越好。rank 大不一定好，反而可能过拟合和显存爆炸。从 r=8 起步，按需调。

误区五：忽视评估集的代表性。评估集不代表业务分布，微调效果就是假的。评估集必须覆盖业务真实场景。

误区六：微调一次就用一辈子。业务在变、模型在升级（GLM-5.2 之后会有新版本）、数据在积累，LoRA 适配器需要定期重训。

收尾

判断框架和能力边界这两个东西，是这一节最想交付给你的。具体 LoRA 的参数会随框架版本变（PEFT、TRL 的 API 在迭代），GLM-5.2 会被新一代模型替代，但"先判断要不要微调、再判断用什么方案、最后用业务指标验证"这套方法论不会变。

下一节我会聊 LoRA/QLoRA 之后的低成本低参数适配技术——量化训练协同、稀疏化、LongLoRA、新硬件下的微调范式。但提醒一句，进阶方向的前提是把当下的 LoRA/QLoRA 用熟用对。如果基础场景都判断不准，追前沿是徒劳。

从今天起，GLM-5.2 对你而言不再是一个"只能调用"的黑盒，而是一个"可以低成本改造"的基座。但"可以改造"不等于"什么都能改造"——知道边界在哪，比知道怎么用更重要。