为了让 AI 学会使用系统，微调这个思路，逻辑上是最干净的。
RAG 是在推理时临时拼上下文，本体是在系统外维护一套结构化描述，这两种方式都有一种"补丁"的感觉，核心模型不懂你的业务，你在外面加了一层让它懂。微调不一样，它直接修改模型的权重，让业务知识成为模型本身的一部分。用完就是会，不用每次推理都带着额外的文档。而且有一个真实的先例支撑这个直觉：模型为什么会写 Python？不是因为推理时有人给它传了 Python 手册，而是训练数据里有大量 Python 代码，模型在预训练阶段把这个语言的语法、惯用法、标准库的用法全部内化了。既然预训练能做到这件事，为什么针对特定业务系统的微调不能做到同样的事？
这个类比在表面上是成立的，但展开之后，两件事的成本结构差异相当大。
微调到底在做什么
先把"微调"说清楚，因为这个词在不同语境下指的不是同一件事。
一种是指令微调（Instruction Fine-tuning），目标是让模型学会以特定风格或格式回答问题，比如总是用 JSON 输出、总是用某种语气回应。这类微调的训练数据量不需要很大，几百到几千条样本通常够用，成本相对可控。另一种是领域知识注入，目标是让模型"记住"大量领域特定的事实或规则，比如你们公司的 ERP 里有哪些表、字段叫什么、服务端命令的参数是什么。这类微调需要的数据量大得多，而且这才是"把业务系统知识烧入模型"这个想法真正在说的事。
两种微调的成本曲线完全不同。很多团队在讨论微调方案时，心里想的是第一种的成本，实际面对的是第二种的要求。
训练数据从哪来
做领域微调，首先要解决训练数据的问题。
模型学会 Python，是因为 GitHub 上有数十亿行公开的 Python 代码，这些代码覆盖了各种场景、各种写法、各种库的使用方式。多样性和规模保证了泛化能力。
你的 ERP 系统有多少"示范性的调用记录"？
现实是，大多数企业系统的 API 调用日志里充斥着脏数据：测试请求、错误调用、边界条件下的异常响应。能直接作为正样本的高质量调用记录，数量往往远不够用。这意味着需要人工构造训练数据——写出正确的任务描述，写出对应的正确调用序列，覆盖各种参数组合，覆盖各种异常处理路径。一个小型的业务系统，服务端命令三四十个，每个命令要覆盖的场景和参数组合如果认真枚举，几百条样本很快就不够了。而且这个工作没有办法外包或自动化，它需要同时理解业务逻辑和模型训练的人来做，这两种能力在同一个人身上并不常见。
系统在变，模型却不会自动跟
假设数据问题解决了，训练跑完了，模型在测试集上表现也不错。三个月之后，业务系统上了新功能，加了几张表，改了几个服务端命令的参数。这时候模型里烧的是旧的知识。旧知识不是简单地"不够用"，而是会主动干扰。模型会以旧的参数结构去调用已经改变的接口，比什么都不知道更危险，因为它看起来是对的。要修复这个问题，需要重新收集训练数据，重新跑微调，重新评估，重新部署。这个周期在工程上是几周到几个月的事。
另一个“幸福的烦恼”是活字格这类低代码平台的特点，那就是迭代很快。业务需求变了，开发者下午就能改完上线。系统的发版频率可能是周级别的。如果每次系统变更都触发一次微调流程，维护成本会变成一个持续的开销，而不是一次性的投入。
RAG 和本体在这件事上有一个天然的优势，它们存在于模型外部，更新只需要修改文档或结构描述，不需要重训模型。系统改了字段，更新本体文件，几分钟内生效。微调做不到这一点。
泛化的幻觉
微调另一个容易被忽视的问题是：模型记住了训练数据，不等于它真的理解了业务逻辑。
这个问题在 NLP 领域有大量文献记录，常被称为"数据集捷径"（dataset shortcuts）或"虚假相关"（spurious correlations）。模型在训练集上表现优秀，往往是因为它学到了训练数据里的表面模式，而不是背后的逻辑规则。当测试样本的表述方式稍微变化，或者出现训练时没见过的参数组合，准确率就会下降。具体到业务系统，一个微调过的模型可能能正确处理"查询 A 仓库的库存"，但当用户问"帮我看看西安工厂的货还剩多少"，模型可能就不知道"西安工厂"对应的是数据库里的哪个仓库代码。这个映射关系不在训练数据里，模型没有办法从微调得到的知识里推导出来。
本体的处理方式不同：业务系统的代码和业务名称的对应关系被显式地写在实体定义里，AI 查找这个映射是一个确定性的操作，不依赖模型有没有"见过"这个写法。
什么情况下微调是值得的
说到这里，微调不是没有价值，而是它的价值点在别处。
如果你的需求是让模型以特定风格输出（比如总是用公司内部的术语体系）、或者适应特定的输入格式（比如从扫描件里提取结构化信息）、或者在某个垂直领域建立语感（医疗文书、法律条文的语言风格）——这类对"模型表达方式"的改造，微调是合适的工具，数据量要求合理，效果稳定。但如果目标是"让 AI 知道怎么正确调用我们公司的业务系统"，微调面对的是一个持续变化的目标，维护成本会随着系统迭代线性增长，而且解决的是一个本质上适合用结构化方案处理的问题。
判断框架大致是这样：如果你的知识变化慢（比如法律条文、医疗指南），规模足够大，而且有一个专门的团队能持续维护训练数据和模型，微调值得认真评估。如果你的知识附着在一个频繁迭代的业务系统上，团队规模有限，那微调的维护成本很可能会超过它带来的收益。
企业业务系统通常属于后者。
本文是"企业AI落地"系列的第7篇。从下一篇开始，进入解法部分：本体论是什么，它的概念从哪里来，在 AI 场景里怎么用。
