有效的大模型

主题

第5章 如何让大模型"耳聪目明" ​

大模型难道是“近视眼”和“聋子”吗？我站在时间的维度看，确实是这样。这不是大模型本身的错，这是大模型的诞生机制所决定的。因为大模型的训练周期还是比较长的，在大模型训练的过程中，我们的外部世界在发生惊人的变迁。所以给大模型增加一双更明亮的“眼睛”，添加一对灵敏的“耳朵”是大模型成长并且成熟的过程中的历史必然。那么大模型的“眼睛”和“耳朵”究竟是什么模样呢？本章将解开这个谜底。

5.1 大模型准确性验证：对比实验与"时间冻结" ​

在上一章，我们理解了大模型技术栈的完整骨架——从 Transformer 理论、模型文件到推理引擎。一个自然的问题随之而来：既然模型文件已经开源，推理引擎也如此成熟，那只需把模型"跑起来"，是不是就算用好了？

答案是否定的。 如果你只是启动了一个本地模型、打开 Web 终端开始对话，你很快就会发现一个尴尬的事实——你面前的这个模型，活像一个知识止于某一个具体日期、对当下世界一无所知的"书呆子"。

先不急着解释，让我们亲眼看看问题在哪里。

5.1.1 两个实验：亲眼看清大模型的"知识边界" ​

最好的教学是不说教，直接做实验。我们准备两组实验对象，让结果自己说话。

第一组：本地模型。 你在第 3 章通过 vLLM 或 Ollama 部署的模型——比如 Qwen2.5 或 Llama 3。它运行在你自己的机器上，没有网络连接，全靠本地模型文件回答一切问题。

第二组：云端服务。 DeepSeek、ChatGPT 或 Kimi 提供的在线 API，由厂商托管的完整服务栈，背后藏着搜索增强、实时索引等一整套你在本地看不见的机制。

带着同样的问题去问它们，答案的差距会让你大吃一惊。

实验一：实时新闻测试

向两组模型提出同一个问题：

"今天早晨全球科技圈最重大的新闻是什么？"

本地模型的表现有两种典型模式。要么一本正经地胡说八道——它根据训练数据中的新闻语言风格，"编造"出一条看似合理、实则完全虚构的新闻标题；要么它坦诚地承认自己的局限，告诉你"我的知识截止于 2025 年 12 月，无法获取今天的信息"。

云端服务的表现则截然不同。以 2026 年 6 月的 DeepSeek 为例——当你问它"今天 NVIDIA 有什么新动作"，它能准确告诉你几小时前 B300 芯片的发布会要点，附带时间线和引用来源。不是因为它比你更聪明，而是厂商在背后做了一整套实时检索和上下文注入的工程。

同一个问题、同一个模型架构、差别仅在于"谁在运营"——为什么会出现这么大的鸿沟？

实验二：私有化/专业领域测试

换个问题方向，这次考验的是模型对"非公开知识"的掌握能力：

"根据我们公司最新的《2026 年 Q1 财务审批流程》，出差标准有哪些变化？"

这一次的局面更残酷——两组模型全军覆没。 本地模型从未见过你公司的内部文档，它的训练语料里没有、也绝不可能有你的企业内部规章。云端服务同理——如果不开启文档上传或知识库功能，厂商没有、也不应该有你的私有数据。

但这里有一个微妙的差别值得注意：同样是无知，云端和本地的"无知原因"是不同的。 本地模型被实验一打败，是因为训练数据的时间缺口；被实验二打败，是因为训练数据的范围局限——它只学过公开互联网上的语料，没有你公司的私有数据。而云端模型在实验二中暴露的，则是权限隔离——技术上有能力帮你找答案，但没有你的授权。

顺便提一句：如果你在 DeepSeek 或 Kimi 的 Web 端手动上传了公司制度文件，那么在这次对话中模型确实能参考你的私有数据。但这恰恰是下一节要讲的内容——你只是给了模型一份"临时参考资料"，而不是让它"学会"了你的制度。关上对话框，模型就回到出厂状态。

5.1.2 一个常见的归因谬误 ​

看到上述实验结果，很多人的第一反应是："本地模型答不上来，是因为我用的模型太小了——云端那个可是万亿参数级别的大模型。"

这个归因不能说是全错。模型体量确实影响性能：更小的参数意味着更少的"记忆容量"，在召回细粒度知识时相对吃亏。但如果把它当成唯一原因，就会导向一个错误结论——"只要我买得起足够大的显卡集群，模型就能知道今天早晨的新闻。"

事实并非如此。 即便你拥有上千万美元的预算，自建了一套与 DeepSeek-V3 同等体量的本地推理集群，它仍然无法回答"今天早晨的新闻"。不是参数不够多、不是算力跟不上——是无论多大的模型，它的知识都有一个明确的"时间断点"：训练完成的那一天。

5.1.3 训练周期：被"冻结"的模型记忆 ​

大模型的"知识盲区"，源自一个几乎无法绕过的技术现实——训练周期带来的"时间冻结"（knowledge cutoff）。理解它，只需要抓住三个关键事实。

事实一：训练即"封帧"

我们在第 4 章讨论过，大模型的知识全部以数值形式存储于那些 Linear 层的权重矩阵中。整个预训练（Pre-training）过程，本质上是通过数万亿 token 的语料，反复调整这成百上千亿个参数，直到模型能够高概率地预测出"给定上文，下一个 token 该是什么"。

但训练一旦完成，这些参数就被写入模型文件（.safetensors 或 .gguf），锁定了。就像摄影中的封帧——按下快门的一瞬间，镜头捕捉到的画面就是最终结果。GPT-4o 训练完成于某一日，DeepSeek-V3 的参数固化为文件于某一刻。从那一刻起，世界仍在变化、新知仍在产生，但模型中的权重不再更新。

在重新训练之前，这本"百科全书"里不会增加一个字。2025 年 12 月的模型不知道 2026 年 1 月的新闻——不是能力问题，是信息流在时间轴上被切断了。

事实二：重训的代价决定了"为什么不随时更新"

"那重新训练一次不就行了吗？"这个问题问到点上了。

理论上可以。但训练一个 DeepSeek-V3 级别的模型，需要消耗约 2000—5000 张 H800 级别的 GPU 持续运行 2—3 个月。仅算力成本一项，就可以达到千万美元级别——这还不算数据清洗、工程研发、模型评测所消耗的人力和时间。

这就导致一个无法回避的矛盾：模型的更新周期以"月"甚至"年"为单位，而世界的信息产出速度以"天"为单位。 这两个节奏之间存在一个结构性的 gap，不是多买显卡能解决的——因为重新训练不仅仅是算力问题，还有数据收集周期、实验迭代周期、安全对齐和红队测试的周期。即便资金无限，从决定重训到模型真正上线，中间也隔着数月。

事实三：微调能"补课"，但绝非无代价

有动手经历的读者可能会想："不是还有微调吗？不能通过微调快速给模型补充新知识？"

答案是：可以，但有严格的边界。微调就像考试周的高强度补习——目标明确时效果显著，但它面临两个根本性制约。

首先是灾难性遗忘（catastrophic forgetting）。模型在学习新知识的同时，会不可避免地在某些维度上冲淡原有能力。用大量新闻数据微调一个通用模型，模型可能变得更擅长复述日期和事件，但在数学推导、代码生成等任务上的表现却悄然下滑。新知识换旧能力——这个代价像"跷跷板"，你永远不可能只占一头。

其次是速度问题。即便是最高效的微调方法（如 LoRA），也需要数小时到数天的训练时间。对于"今天早晨的新闻"这类分钟级时效性信息，微调的速度永远追不上世界变化的速度。

微调的真正用武之地，不在于追赶瞬息万变的新闻——那从一开始就用错了方向。它的价值在于将稳定、高价值、慢变化的领域知识"内化"给模型，这将在 5.3 节展开讨论。

5.1.4 问题面前的选择 ​

三个事实讲完，大模型的"知识困境"已经很清晰了：

  • 它的参数权重锁死了一个时间切片。
  • 重训和微调都无法以分钟级速度追赶世界变化。
  • 内部私有数据更是完全不在它的训练语料范围内。

但真正重要的问题不是"模型有这个缺陷"——所有技术都有缺陷——而是你知道了这个缺陷之后，怎么突破它。

所以，让我们从最快、最直接的方法开始。接下来的一节（5.2），我们将详细拆解"提示词嵌入"——在每一次调用时把最新知识临时递到模型眼前，这也是解决实时、私有数据需求的最短路径。在这条路走到尽头之后，我们再转向另一条：微调（5.3），把稳定的专业领域知识刻进模型大脑。两条路径各有性格、各有边界，5.3 节将做一次系统的权衡对比，帮助你在具体场景中做出选择。

5.2 大模型获取新知识的路径1：提示词嵌入 (Prompt Injection) ​

上一节我们看到了大模型的"时间冻结"困境——模型一旦训练完成，知识就被"封帧"在权重文件产出那一刻。它不了解今天的新闻，没读过你公司的内部文档，也不知道上个月刚发布的那份行业标准。

但这不意味着毫无办法。在不重新训练模型的前提下，让大模型"知道"训练截止日期之后的信息，最直接的方式就是：把参考资料直接塞进提示词里。

这正是本章要讲的第一条知识注入路径：提示词嵌入（Prompt Injection，技术社区也称"提示词注入"）。

它的核心理念简单到让人意外：与其费力让模型去"记住"新知识，不如在每次提问时，把相关的参考资料翻到那一页，直接递到它手边。模型不需要"学会"这些信息——它只需要在这一轮回答中"看见"它们。

这条路径分两个典型场景：你在 Web 端使用模型时经历的"幕后 RAG"，和你调用 API 时必须亲手完成的"上下文构造"。前者你只看到结果，后者你需要亲手建造。先讲前者。

5.2.1 文本块嵌入：给大模型发"参考资料" ​

很多读者第一次接触大模型，是通过网页版——打开 DeepSeek 或 Kimi 的页面，在对话框里输入问题，就能得到让人惊讶的答案。你问"今天有什么大新闻"，它能说出几小时前发生的事；你问"某某上市公司的最新季报"，它也能列出精确的数字。

大多数人的第一反应是：这个模型也太博学了。

但真相并非如此。本节讲的就是 Web 端这个"博学"体验背后的技术机制——RAG。

Web 端背后的"看不见的手" ​

你在 Web 端感受到的"博学"，并不是模型天生具备的能力。厂商在后台默默做了一件事：在你输入问题后、模型开始回答前，系统会先根据你的问题，自动从互联网或知识库中抓取相关内容，然后把这些文字片段"塞"进你看不见的提示词里。

这项技术的正式名称叫 RAG（Retrieval-Augmented Generation，检索增强生成）。它的工作流程拆成三步：

  1. 检索（Retrieval）：系统收到你的问题后，不是直接发给模型，而是先去搜索。搜索范围可能是公开网页（通过搜索引擎）、内部知识库（通过向量相似度匹配），或你上传的文件。
  2. 增强（Augmented）：搜到的相关文字片段，被插入到发给模型的提示词中。通常放在"系统提示"和"用户问题"之间，作为背景资料。
  3. 生成（Generation）：模型看到这段被"增强"过的提示词后，像往常一样生成回答。只不过这一次，它面前多了几页参考资料。

整个过程对你完全透明。你看到的是一个"什么都知道"的模型，但实际上，模型并没有真正"学会"任何新知识。它只是在这一轮回答中，临时参考了被悄悄夹进来的那几段文字。 关上对话框，模型就会把这些信息"忘"得一干二净。

为什么说这是"临时"的？ ​

理解这一点很重要。RAG 注入的知识有三个关键特征：

  • 无状态：知识只在当前对话中有效。刷新页面、重开一个对话框，模型就回到了"出厂状态"。
  • 不写回权重：RAG 不会修改模型的任何参数。知识是作为提示词的一部分"借"给模型的，用完即还。
  • 受窗口限制：能塞进提示词的知识量受限于模型的上下文窗口（Context Window）。窗口虽然越来越大——从早期的 4K tokens 到 2026 年主流模型的 128K-1M tokens——但终究有上限。你不能塞进整个维基百科。

把这些特征放在一起，就能理解 RAG 的本质了：它是一种"即时查阅"而非"长期记忆"。 就像开卷考试——手里有参考资料，但不能带出考场。

一个重要的思维转变 ​

对很多工程师来说，接受"模型不需要记住所有东西"这个观念，是一个关键的思维转变。

在传统软件开发中，如果你的系统"不知道"某个信息，你会考虑加一个数据库、写一个缓存层、或更新配置文件。但在大模型的世界里，有一个更简单的选项：直接把信息贴在提示词里发给它。

你不需要让它"学习"，你只需要让它"看到"。这个看似简陋的做法，实际上是目前最广泛使用、性价比最高的知识注入方式。我们将在 5.4 节专门讨论一个关键决策——什么情况下"贴给模型"就够了，什么情况下才需要"教会模型"。

5.2.2 对话嵌入：让 API"开口说话" ​

如果你只在 Web 端使用大模型，可能会觉得"模型什么都知道"是理所当然的。但当你开始调用 API 开发自己的应用时，你会撞上一个令人困惑的现象：同样的模型，在 API 里突然变得"健忘"了。

你问它"公司新制度是什么"，它不光答不上来——它连"有个公司"这回事都不知道。

API 的"裸机"本质 ​

原因很简单：Web 端给你的体验是"精装修"的，包含了一整套 RAG 流水线。而 API 给你的是"毛坯房"——一个纯粹的模型推理接口。

当你调用 API 时，没有人在背后帮你搜索信息、不会自动嵌入上下文。你发给模型的，就只有你自己构造的那些文字。模型也不会主动联网查询——它只处理你给它的输入，生成一个回复，然后等待下一次调用。

换句话说，API 暴露了模型的真实能力边界。 如果你想让模型"知道"某条信息，你必须亲手把它写进发过去的消息里。

这个过程，就是提示词嵌入在 API 层面的实践：手动构造上下文（Context）。

Context 是怎么"塞"进去的？ ​

在 API 调用中，知识以 messages 列表的形式传递给模型。这个列表像一个对话脚本，每一行都有固定的"角色"（Role），告诉模型这句话是从哪里来的。典型的消息结构包含三种角色：

System Prompt（系统提示）

这是消息列表里的第一条，通常承担两个职责：

  • 设定角色：告诉模型"你是谁"。例如："你是一个熟悉中国民航安全法规的专家。"
  • 注入全局知识：把不随对话变化的基础知识放在这里。例如公司的通用规范、领域的核心概念。

System Prompt 在整个对话中持续生效。它像一位坐在你旁边的顾问，全程知道你"是什么身份、该按什么规则说话"。

Context Blocks（上下文块）

这是提示词嵌入的主战场。在用户消息之前插入的、承载动态知识的文本块，就是 Context Block。它们通常这样组织：

  • 从知识库中检索到的相关文档片段
  • 用户上传的文件内容
  • 本次任务需要的参考资料

Context Block 和 System Prompt 的区别是：System Prompt 是"持久的设定"，在整个对话中不变；Context Block 是"临时的资料"，每条消息都可以不同。

User Message（用户消息）

这是当前的问题本身。它和 Context Block 的关系是：资料归资料，问题归问题。 一个好的 API 调用，应该把参考资料和用户的原始问题清晰地分开，让模型知道哪部分是"背景"，哪部分是"任务"。

一个真实场景：公司制度的 API 调用 ​

回到前面那个例子。假设你的公司更新了出差审批流程，你希望模型能正确回答员工关于新制度的咨询。在 API 模式下，你需要这样做：

第一步，不要把制度文档"喂"给模型训练——那需要数小时甚至数天，还得小心灾难性遗忘。

第二步，构建一个 messages 数组，把制度文档的摘要作为 Context Block 嵌入：

json
{
  "messages": [
    {
      "role": "system",
      "content": "你是公司内部助手，负责解答员工关于公司制度的咨询。请严格依据参考资料作答。"
    },
    {
      "role": "user",
      "content": "【参考资料】以下是最新出差审批制度摘要：\n\n1. 出差申请需提前 3 个工作日提交。\n2. 预算超过 5000 元需部门总监审批。\n3. 差旅标准按城市等级分 ABC 三档……\n\n【用户问题】我下周二要去北京出差，预算大约 6000 元，需要什么审批？"
    }
  ]
}

模型收到这段消息后，它"看到"了参考资料中的规则，然后依据规则回答："您的预算超过 5000 元，需要部门总监审批……"

注意：模型并没有"学会"你的出差制度。 它只是在这一次调用中，参考了你塞进去的文字。下次调用时，你需要重新嵌入这些资料。

提示词嵌入的"三秒法则" ​

到这里，我们可以总结出提示词嵌入的核心优势——我把它称为"三秒法则"：

  • 第一秒：快到极致。 不需要训练、不需要数据处理、不需要 GPU 集群。改一行提示词就生效。
  • 第二秒：便宜到忽略不计。 嵌入知识只增加输入 token，不涉及任何额外计算资源。相比微调动辄几十上百美元的费用，嵌入知识几乎免费。
  • 第三秒：灵活到随心所欲。 你想什么时候换知识就什么时候换。早上嵌入 A 制度，下午嵌入 B 制度。不需要任何部署流程。

但"三秒法则"也道出了它的本质局限：它快，是因为它只是"看一眼"，不是"学会了"。 每次调用都要重新传递这些知识；知识越多，占用的 token 越贵；模型也无法从多段嵌入的知识中举一反三——它只是在回答时"引用"而已。

本节小结 ​

提示词嵌入是大模型获取新知识的第一条路径，也是最快、最便宜、最灵活的方式。它的核心思想朴素而有效：不训练，只传递。 把参考资料作为文本块嵌进提示词，让模型在回答时"看见"这些信息。

这条路径覆盖了两个核心场景：

  • Web 端的 RAG：厂商在后台自动完成检索和嵌入，给用户"模型什么都知道"的体验。
  • API 端的手动 Context：开发者自己在 messages 中构造上下文，决定模型能"看到"什么。

这条路径的局限同样明确：知识只是"临时参考"，不会留存到模型权重中。对于需要模型真正学会的领域知识，我们需要另一条路径——模型微调（Fine-tuning）。

不过，在进入微调之前，还有一件基础的事情需要搞清楚：系统提示和用户消息之间遵循的是怎样的底层协议？messages 列表的四种 role 分别代表什么？不同厂商的模型之间是否是同一套对话语言？下一节，我们将详细解读承载提示词嵌入的底层协议——OpenAI Chat Completions 规范。

5.2.3 统一语言：OpenAI 协议与知识传输 ​

前面两节，我们拆解了文本嵌入和对话构造这两种知识注入方式。文本嵌入教会你"怎么把知识打包"，对话构造教会你"怎么把知识放到对话的什么位置"。现在只剩最后一个问题：这些打包好的 messages 列表，通过什么管道提交给模型？

答案是 OpenAI Chat Completions 协议。到了 2026 年，不管底层跑的是 DeepSeek、Claude 还是 Qwen，你提交请求的格式几乎都一样。这节就把这套协议的骨架讲清楚——它定义了哪些角色、知识可以放在哪些位置，以及一个完整可运行的代码示例。

为什么需要一个统一协议？ ​

2010 年代的深度学习生态，模型部署的体验可以用一个字形容——"散"。PyTorch 的推理代码没法直接用于 TensorFlow 模型，每个框架有自己的数据格式、自己的序列化方式。你换一个模型，前面的工程几乎要重来。

大模型时代走上了一条不同的路。2023 年 3 月，OpenAI 在发布 GPT-3.5-turbo 时同步推出了 Chat Completions API 的标准格式。这套协议设计刻意做得很"薄"——只定义请求和响应的外壳，不绑定任何特定模型实现。核心约定只有一句话：每次调用，你给一个 messages 列表，模型还你一个回复。

这层薄协议带来了一个实打实的好处：你写一次 API 调用代码，换个 URL 就能用另一家模型。 具体来说：

  • 你给 DeepSeek 写的调用代码，把 URL 换成 Qwen 的就能跑。
  • 你测试用的 OpenAI 格式示例，切到 Claude 一样跑通。
  • 开源推理引擎（vLLM、Ollama）原生实现了这套协议，本地模型部署后直接对接。

OpenAI 协议，成了大模型生态中的"USB 接口"。 不论你插的是哪家的设备，协议层不变。

协议的骨架：messages 列表 ​

理解这套协议，核心就是看懂 messages 的结构。一个典型的 Chat Completions 请求长这样：

json
{
  "model": "deepseek-v4",
  "messages": [
    {"role": "system", "content": "你是一个读过《变电站运行规程》的专家。"},
    {"role": "user", "content": "主变差动保护动作后，标准处置流程是什么？"}
  ]
}

逐字段拆开：

  • model：指定调用哪个模型。各厂商的模型名略有不同（deepseek-v4、qwen-max、claude-sonnet-4-20250514），但请求的壳子一模一样。
  • messages：一个有序的对话记录列表。每条消息有两个必需字段：
    • role：发言人身份。协议定义了四种角色：
      • "system" — 系统设定，定义模型的角色和行为边界。通常放在消息列表最前面。
      • "user" — 你的输入。包括问题、嵌入的知识文本、指令，都放在这个角色里。
      • "assistant" — 模型的回复。多轮对话中，你需要把模型的历史回复也放回 messages 里，否则模型就"不记得"上轮说了什么。
      • "tool" — 工具调用返回的结果。进阶内容，本书第 7 章展开。
    • content：消息正文，承载全部要传递的信息。

知识传输放在哪里？ ​

回到本章主题——知识如何从外部传入模型。在 OpenAI 协议中，有三个位置可以承载知识，但它们的用途不同：

位置一：system 消息——注入全局知识 ​

适合放不会频繁变化的基础信息，整个对话期间持续生效：

json
{"role": "system", "content": "你是一个熟悉中国《数据安全法》的法律顾问。该法的核心原则包括：数据分级分类管理、重要数据出境安全评估……"}

因为 Token 窗口有限，system 里不要塞太多东西——"稳定不变"的放这里，"频繁变化"的放到 Context Block 里去。

位置二：user 消息——嵌入任务知识 ​

这是提示词嵌入的主阵地。在用户消息正文中，用明确的标记把"参考资料"和"问题"分开：

json
{"role": "user", "content": "【参考资料】……（检索到的知识文本）……\n\n【用户问题】我现在想部署一个本地模型来处理财务数据，有什么推荐方案？"}

"参考-问题"分离写法有两个好处：模型能准确区分背景和任务；后续想更换参考资料，只改上半段就行，不用重构整个消息。

注意：前两个位置是"知识注入"——system 放全局知识，user 放局部知识。下一个位置性质不同。

位置三：assistant 消息——维持对话记忆 ​

模型本身没有跨调用的"记忆"。在多轮对话中，由 messages 列表来"记住之前说了什么"。每轮对话结束后，把模型的回复（role: "assistant"）追加到 messages 列表末尾，下一轮调用时携带整个历史。

但对话越长，messages 列表越长，越早的内容可能被上下文窗口截断。多轮对话的记忆管理是工程上需要额外处理的问题，已超出提示词嵌入的讨论范围。

一个完整示例 ​

下面是一个可直接运行的 API 调用——向 DeepSeek API 发送带有知识嵌入的请求（依赖：pip install requests，并先 export DEEPSEEK_API_KEY=<你的 key>）：

python
import os

import requests

response = requests.post(
    "https://api.deepseek.com/v1/chat/completions",
    headers={
        # Key 从环境变量读取，绝不硬编码
        "Authorization": f"Bearer {os.environ['DEEPSEEK_API_KEY']}",
        "Content-Type": "application/json"
    },
    json={
        "model": "deepseek-v4",
        "messages": [
            {
                "role": "system",
                "content": (
                    "你是内部 IT 顾问，熟悉公司技术栈和企业级部署方案。"
                    "公司当前基础架构：Kubernetes 集群（48 核 GPU 资源池）、"
                    "已部署 Ollama 和 vLLM 推理服务。"
                )
            },
            {
                "role": "user",
                "content": (
                    "【参考资料】公司2026年Q2技术规划：优先采用 DeepSeek-V3 和 Qwen2.5 "
                    "作为主力模型，限制外部 API 调用依赖。\n\n"
                    "【用户问题】财务部提了一个需求：希望在内部部署一个能分析财务报表的"
                    "本地模型，要求数据不出公司。我们的基础设施能支持吗？"
                )
            }
        ]
    }
)

print(response.json()["choices"][0]["message"]["content"])

这个例子展示了典型的知识嵌入模式：system 里放公司技术栈背景（持久性知识），user 里放 Q2 技术规划（本次任务参考资料）和用户的实际问题。模型依据这些输入，生成有针对性的回答。

协议不止于 OpenAI ​

最后需要说明一点：虽然这套协议以"OpenAI"命名，但它的影响力早已超出了 OpenAI 一家公司。到了 2026 年，DeepSeek、Qwen、Claude、Gemini 等主流模型厂商的 API，全部兼容 OpenAI Chat Completions 格式。甚至你在本地用 Ollama 或 vLLM 部署的模型，暴露的也是同一套 HTTP 接口。

这意味着，学会看懂这套协议，你就拥有了和所有主流大模型"对话"的通用语言。 不管模型怎么换、技术怎么迭代，这张对话的"桌子"不会变。

5.3 大模型获取新知识的路径 2：模型微调（Fine-tuning） ​

提示词嵌入给了大模型一份"参考资料"，但资料终究是外挂的。每当你向模型提问，系统就要把相关文档塞进上下文窗口——Token 哗哗地烧，响应速度被拖慢，而且模型并没有真正"学会"这些知识。它只是在每次调用时被临时告知。

如果你想让模型真正掌握一家公司的 API 规范、看懂一套内部数据库的 Schema、理解某个垂直行业的专业术语体系——就像让一个刚入职的工程师在三个月内成长为能独当一面的核心骨干——你需要的是模型微调（Fine-tuning）。

如果说提示词嵌入是给大模型发一份"临时参考资料"，模型微调就是让大模型通过一次"考前冲刺"，将专业知识内化为自己的长期记忆。

在 Claude Code、OpenClaw 这类智能体工具大行其道的 2026 年，微调是这些工具能够真正落地的底层保障。没有针对特定领域（编程语言、企业内部流程、行业知识库）的微调，这些工具在处理复杂任务时往往会力不从心——表面看起来什么都能做，实际深入任何一个垂直场景都会露馅。

5.3.1 微调的本质：给大脑增加"专业字典" ​

要理解微调，先要理解预训练和微调之间的分工。

大模型的全量预训练耗时数月、耗资千万——这是"通识教育"阶段。模型在海量通用文本上学习了语法、常识、逻辑推理等基础能力。但通识教育不教你家公司的 JIRA 系统怎么用，也不教你的客户画像数据库取数规则。

微调的定位是"专业培训"：在保持模型通用能力大体不变的前提下，用少量但高度针对性的数据，给模型增加一个"专业字典"。

这里有一个物理层面的关键事实：与提示词嵌入不同，微调会真实地改变模型权重文件的内容。我们在第 4 章看到了模型权重就是那些 Linear 层的矩阵参数——微调的过程中，这些矩阵里的数值会依据你提供的训练数据发生细微但确定的偏移（改动范围越大，灾难性遗忘风险越高，详见 5.3.3）。模型在磁盘上的 .safetensors 文件会被更新。这也是为什么微调后的模型可以成为一个"新模型"独立分发——它把专业知识写进了"基因"里。

物理变化带来的直接后果是：微调需要 GPU 算力。虽然 2026 年的技术栈已经支持了部分 CPU 微调（如 llama.cpp 的微调模式），但在生产级的效率要求下，GPU 依然是微调的标配。好消息是，随着 LoRA 和 QLoRA 技术的成熟（详见 5.3.3 节），即使是消费级显卡也能完成相当体量的微调任务。

资源要求的另一个维度是数据。与预训练需要的海量文本不同，微调对数据量的要求大幅降低。在 QLoRA/LoRA 方法下、基座模型已有良好通用能力的前提下，几百到几千条高质量对话数据就足以让模型锁定一个垂直领域的风格和知识模式。

微调是"投入 GPU 算力，换取模型能力的永久性提升"——与提示词嵌入的"零算力，临时生效"形成互补。

从"临时记忆"到"长期记忆" ​

这里做一个类比，帮助理解两种知识注入路径的根本区别：

维度提示词嵌入（Prompt + RAG）模型微调（Fine-tuning）
知识存储位置上下文窗口（临时）模型权重（永久）
生效方式每次调用重新注入训练完成后持续生效
资源消耗Token 成本 + 检索延迟GPU 算力 + 训练时间
更新速度即时（改向量库即可）缓慢（需重新微调）
适用场景频繁更新的知识、大规模文档相对稳定的专业技能、格式与风格

两者不是互斥的，而是互补的。接下来的 5.4 节将专门讨论在什么情况下你应该选择提示词，什么情况下应该启动微调。

5.3.2 模型微调的两大方法：SFT 与 RLHF ​

根据目标的不同，微调技术分为两大流派。理解它们的区别，是你正确启动一个微调项目的前提。

SFT（监督微调）：教模型"学知识" ​

Supervised Fine-Tuning（SFT） 是最直接、应用最广泛的微调方式。它的逻辑非常朴素：

你给模型准备好"输入 → 正确输出"的训练对，模型通过反向传播学习"在这个场景下，输入 X 应该输出 Y"。

举个例子。假设你要让模型学会调用你公司的内部 API get_order_detail(order_id)——这个 API 需要传入订单号，返回订单的客户姓名、金额、状态。你可以构造类似这样的 SFT 训练数据：

json
[
  {
    "instruction": "查询订单 ORD-2026-0622 的详细信息",
    "input": "",
    "output": "<tool_call>{\"function\": \"get_order_detail\", \"parameters\": {\"order_id\": \"ORD-2026-0622\"}}</tool_call>"
  },
  {
    "instruction": "帮我看看客户张三最近的订单情况",
    "input": "",
    "output": "我先帮您查询张三的客户 ID... <tool_call>...</tool_call>"
  }
]

准备几千条这样的高质量对话数据，在合适的基座模型上跑几百到几千步的 SFT，模型就可以稳定地学会这套调用模式。SFT 的另一个典型场景是指令遵循微调——让模型按特定格式输出（比如强制使用 Markdown 表格、严格遵守 JSON Schema），这几乎是所有 Agent 工具链依赖的底层能力。

SFT 有一个重要的数据原则：少而精。5 条干净的、准确的、格式一致的训练样本，比 50 条粗糙的样本效果好得多。微调不是"喂得越多越好"——它更像是在给模型做"精准矫正"，而不是重新填鸭。

RLHF（强化学习对齐）：教模型"懂规矩" ​

如果说 SFT 解决的是"知不知道"的问题，RLHF（Reinforcement Learning from Human Feedback） 解决的是"做得好不好"的问题。

SFT 能让模型学会输出 API 调用的正确格式，但无法解决这些问题：

  • 模型回答的语气是否得体？
  • 面对模糊问题时是否主动追问而非瞎猜？
  • 遇到知识盲区时是否诚实承认而非编造？
  • 推理过程是否符合人类期望的逻辑链条？

这些都属于"偏好对齐"的范畴——让模型的输出不仅正确，而且是人类喜欢和认可的输出方式。

RLHF 的经典流程（基于 PPO 算法）需要训练一个独立的"奖励模型"来模拟人类偏好，步骤繁琐且训练不稳定。2025-2026 年，社区涌现出一批更高效的替代方案，它们绕过了对奖励模型的依赖，直接在 SFT 模型之上进行偏好优化。以下介绍两个当前最核心的对齐算法：

DPO（Direct Preference Optimization）：目前社区最成熟、文档最全的直接偏好方法。你准备"好的回答 vs 差的回答"的配对数据，DPO 直接利用这些偏好数据优化模型，不需要训练奖励模型。如果你刚入门且有配对偏好数据，DPO 是首选。

GRPO（Group Relative Policy Optimization）：DeepSeek-R1 采用的算法。它引入组内相对比较机制——对同一个问题生成一组回答，根据组内相对质量评估优劣。GRPO 对推理任务的提升效果显著，特别适合数学推理、代码生成等需要长链推理的场景。如果你有一定调优经验且模型主要用于推理类任务，GRPO 值得尝试。

💡 其他对齐算法：ORPO（将 SFT 和对齐合并在一个阶段完成，追求效率）、KTO（只需好/坏标签无需配对数据，适合只有点赞/点踩数据的场景）、SimPO（以回答长度作为隐式参考）、CPO（在对齐同时保持模型通用能力）等也在快速发展。它们各有适用场景，但工程落地中 DPO 和 GRPO 的覆盖度最广。如果你遇到特殊的偏好数据格式或对齐需求，这些备选方案值得了解。

对齐是锦上添花，不是雪中送炭。 如果你连 SFT 都没做好（模型输出格式不稳定、知识错误率高），直接做 RLHF 只会让问题更隐蔽。先确保 SFT 达到可用的基线，再考虑是否启动对齐。

5.3.3 模型微调的技术路径：PEFT 与 FFT ​

"微调会改变模型的权重"——这句话在 5.3.1 节提过。但接下来的问题是：改多少？全改还是改一点？

这个问题看起来是技术选型，实际上是资源预算问题。你手中的 GPU 显存、训练时间、数据量，直接决定了你能走哪条路。

PEFT（高效参数微调）：用小改实现大效果 ​

PEFT（Parameter-Efficient Fine-Tuning） 的核心哲学是：模型 99% 以上的参数保持不动，只在关键位置插入极少量可训练的"适配器"参数。这意味着——你不需要为拥有 70 亿参数的模型准备能放下 70 亿参数的显存，因为训练过程中只有不到 1% 的参数在参与反向传播。

PEFT 为何有效？直觉如下：预训练模型已经掌握了语言的底层规律——语法、常识、基本逻辑。你想教给模型的，是一层"专业涂层"，而不是把墙壁拆了重建。在已经足够好的基座上，一层薄薄的适配器就足以改变模型的输出分布。

QLoRA：消费级显卡的微调革命

在 PEFT 的诸多技术中，QLoRA（Quantized Low-Rank Adaptation） 是目前开发者的首选，也是整个 PEFT 生态中最具标志性的一项技术。

QLoRA 是两门技术的融合：

  • 量化（Quantization）：将基座模型从 16-bit 浮点数（FP16）压缩为 4-bit 整数（NF4 格式）。一个 7B 模型原本需要约 14GB 显存（FP16），4-bit 量化后只需约 4GB。量化过程中模型固定不动——它只是被"压缩存储"，推理精度损失通常可以忽略不计[6]。
  • LoRA（Low-Rank Adaptation）：在模型的特定线性层上"挂载"一对低秩矩阵（A 和 B，其中 A 的维度是 d×r，B 是 r×d），微调时只训练这两个薄层。第 4 章已经详细介绍了 LoRA 的数学原理和参数配置——这里不重复，而是聚焦于 QLoRA 在微调路径决策中的位置。

两者结合的结果是：一个 7B 模型可以在单张 RTX 4090（24GB 显存）上完成微调。32B 的模型可以在单张 A100（80GB）上微调[7]。2026 年的行情是，一张消费级显卡就能微调绝大多数开源模型。

LoRA 的核心参数速查（与第 4 章呼应）：

参数含义推荐值（中文指令微调）调整策略
r (rank)适配器矩阵的秩8~16数据量大、任务复杂 → 增大到 32；数据少、任务简单 → 保持 8
alpha缩放系数rank × 2alpha/rank 比值越大，适配器对输出影响越大
target_modules挂载 LoRA 的层q_proj, v_proj可扩展到 k_proj, o_proj，但收益递减
dropout正则化0.05~0.1防止过拟合；数据量小 → 可适当增大

FFT（全量参数微调）：极致的代价 ​

FFT（Full Fine-Tuning） 走的是另一条路：模型的所有参数全部参与训练——所有 Linear 层的权重矩阵、所有 Embedding、所有归一化层参数——都在反向传播中更新。

这条路的效果上限确实最高。全量微调不存在适配器的"表达瓶颈"，模型可以彻底重构自己的参数分布来适应新任务。但代价也是明确的：

资源项PEFT（QLoRA）FFT（全量微调）
Qwen2.5-7B 最低显存~8GB（单张 RTX 3060 12GB 或 RTX 4060 Ti 16GB 即可）[7]~60GB（需 2×A100）
训练速度快（只更新 <1% 参数）慢（全参数反向传播）
存储开销适配器<100MB完整模型>14GB
灾难性遗忘风险低（基座冻结）高（需要精心调参）
效果上限接近全量微调 90%+100%（理论最大值）

在 2026 年的工程实践中，FFT 主要出现在以下场景：

  • 构建行业基座模型（如金融大模型、医疗大模型），需要对通用基座做彻底的专业化改造
  • 有充足的 GPU 集群预算和全职的算法团队
  • 某些非英语语种中，LoRA 的表达能力不足以应对语言特殊性时，可能需要走 FFT 作为兜底方案

对于本书的目标读者——应用开发工程师——你的默认选择应该是 QLoRA。先拿到 90% 的效果，如果业务确实需要那额外的 10% 且预算宽裕，再考虑 FFT。

5.3.4 微调工具栈：从实验室到流水线 ​

在 2026 年，微调已经不再是算法科学家的专利。一套完整且对新手友好的工具链已经形成，普通工程师只需掌握三个节点，就能完成从数据到部署模型的完整闭环。

第 4 章已经以"微调框架"的视角详细介绍了 LLaMA-Factory、Unsloth 和 ms-swift 的技术细节和使用方法——包括 Web 界面、命令行参数、LoRA 配置三件套。本节不再重复这些内容，而是从微调流水线的角度，把三个工具串联成一整套可以落地的工作流。

流水线全景 ​

数据准备 → 微调训练 → 效果评测 → 部署上线
   ↓          ↓         ↓         ↓
 数据集     LLaMA-   EvalScope   vLLM/
 清洗/     Factory              Ollama
 格式化     ms-swift

节点 1：LLaMA-Factory — 全能微调工具箱 ​

LLaMA-Factory（简称 L-F）是当前国内最热门的一站式微调平台。它在第 4 章获得了详细展开——这里聚焦于它在流水线中的角色：

  • SFT：标准指令微调，你通过 Web 界面选择模型、上传数据集、配置 LoRA 参数，L-F 自动完成训练并在过程中实时展示损失曲线。
  • RLHF/DPO/GRPO：L-F 内置了完整的偏好对齐流程。你只需按 L-F 的数据格式准备偏好数据（好回答/差回答对），就能在同一个平台内完成从 SFT 到 DPO 的完整升级。
  • 模型导出：训练完成后，L-F 可以将 LoRA 适配器与基座模型熔合，导出为 Hugging Face 格式（.safetensors）或 GGUF 格式，直接对接 vLLM 或 Ollama 部署。

选型速查：如果你主要用国产模型（Qwen、DeepSeek 系列）、对国内网络环境有强依赖，ms-swift 可能是更适合的起点（见下节）。其他情况，LLaMA-Factory 的通用性更强——社区资源、踩坑经验、文档覆盖度都更丰富。

节点 2：ms-swift — 国产生态的深度适配 ​

ms-swift 是阿里魔搭（ModelScope）社区推出的微调框架。它在某些场景下比 LLaMA-Factory 更顺手：

  • 国产模型原生适配：对 Qwen、DeepSeek、ChatGLM 系列的对话模板、Tokenizer 配置都已预设，基本不需要手动调整。
  • 多模态优势：ms-swift 原生支持 Qwen-VL 等视觉语言模型的微调，这对于视觉理解、文档分析等场景是不可替代的能力。
  • 国内网络优势：从魔搭社区拉取模型的速度远超 Hugging Face（后者在国内经常限速甚至不可访问）。对于纯国内的开发环境来说，这个网络优势本身可能就是选择 ms-swift 的决定性因素。

节点 3：EvalScope — 微调好不好，不能靠感觉 ​

微调完成后，模型的表现到底提升了多少？有没有因为学习新知识而丧失原有的推理能力？回答这些问题，需要一套量化的评估体系——EvalScope 正是干这件事的。

EvalScope 提供了多维度的评估能力：

  • 知识准确性：微调后模型在目标领域的回答正确率——用你自建的领域测试集衡量
  • 通用能力保持：是否出现"灾难性遗忘"（学了新知识，丢了旧本领）——用 MMLU、C-Eval 等通用基准衡量
  • 推理能力：逻辑推理、数学、代码等核心能力是否退化——用 GSM8K（数学）、HumanEval（代码）等衡量
  • 指令遵循：是否按要求的格式、风格输出——用自定义格式校验脚本衡量
  • 安全性：是否在微调后变得更容易产生有害内容——用 SafetyBench 等安全基准衡量

一个典型的微调后评估命令（依赖：pip install evalscope；LLaMA-Factory 的安装见 4.3 节）：

bash
evalscope eval \
    --model ./models/qwen-finetuned \
    --datasets gsm8k,ceval,general_qa \
    --limit 200 \
    --output-dir ./eval_results

EvalScope 会生成一份包含各维度得分和详细错误案例的报告。这里有一个容易被忽视但极其重要的实操经验：在微调前先跑一遍上述评估，作为基线。只有知道微调前模型在这几个维度上的水平，你才能客观判断微调后到底是提升了还是退步了。

🔑 评估不是终点，是下一轮迭代的起点。 拿到评估报告后，如果某个维度的得分不理想（比如推理能力明显下降），回到数据准备阶段——可能是训练数据过于单一，需要混入一些通用数据来"锚定"模型的原有能力。

完整流水线实战示例 ​

下面是把上述三个节点串起来的一个完整示例——从数据到部署，一条命令流走完：

bash
# Step 1: 准备数据（假设你的训练数据已经整理为 LLaMA-Factory 格式的 JSON）
# data/train.json 包含你的 SFT 对话数据

# Step 2: 使用 LLaMA-Factory 进行 LoRA 微调
llamafactory-cli train \
    --model_name_or_path Qwen/Qwen2.5-7B-Instruct \
    --dataset your_custom_data \
    --template qwen \
    --finetuning_type lora \
    --lora_rank 8 \
    --lora_alpha 16 \
    --output_dir ./output/qwen-lora-ft \
    --per_device_train_batch_size 2 \
    --gradient_accumulation_steps 4 \
    --learning_rate 5e-5 \
    --num_train_epochs 3

# Step 3: 导出模型（将 LoRA 适配器与基座合并）
llamafactory-cli export \
    --model_name_or_path Qwen/Qwen2.5-7B-Instruct \
    --adapter_name_or_path ./output/qwen-lora-ft \
    --template qwen \
    --export_dir ./models/qwen-finetuned

# Step 4: 评估微调效果（与微调前的基线对比）
evalscope eval \
    --model ./models/qwen-finetuned \
    --datasets gsm8k,ceval \
    --output-dir ./eval_results/post_ft

# Step 5: 部署为推理服务
# 方式 A：部署到 vLLM（高性能生产环境）
vllm serve ./models/qwen-finetuned --port 8000

# 方式 B：转换为 GGUF 部署到 Ollama（本地轻量场景）
# python convert_to_gguf.py ./models/qwen-finetuned \
#     --outfile ./models/qwen-finetuned.gguf

实践建议：为什么说微调是 Agent 的保障？

请记住一句话，它可能是你在微调这件事上最高 ROI 的认知投资：

"Prompt 决定了 Agent 的上限，Fine-tuning 决定了 Agent 的下限。"

提示词工程可以做得很精妙——精心设计的 System Prompt、层层嵌套的思维链、复杂的 Multi-Agent 编排——这些让模型在你预设的轨道上"看起来很强"。但当你的 Claude Code 或 OpenClaw 遇到一个完全没见过的东西——比如你公司内部特有的 RPC 协议名、一个只在你们代码库里存在的类名——再长的提示词也无能为力。

这就是"下限"的含义：当所有精巧的提示词编排都失效时，模型还能稳定输出什么？ 如果它的权重里根本没有这些知识，它就只能在幻觉和拒绝之间二选一。

一次高质量的 SFT 微调，不需要你做复杂的 Prompt 纠缠。你把几十个典型的使用场景、API 调用示例、领域术语映射喂进去，模型就把这些"印"进了权重。从那之后，它面对这些场景时不再需要你耳提面命——知识就在那里，稳定、持久、不消耗 Token。

不要试图用越来越长的提示词去弥补知识的缺口。当提示词解决不了问题的时候，放下键盘，去准备训练数据。

微调不是提示词的替代品，更不是提示词的"升级版"。它们是两个维度的工具：提示词追求灵活度的上限，微调保证稳定性的下限。两者配合使用——以一个经过领域微调的小模型作为底座，配合精准的 Prompt 编排和 RAG 检索作为外部记忆——这才是 2026 年最成熟的 Agent 构建方案。

当然，微调不是银弹——在哪些场景下微调的投入产出比不如人意，我们将在 5.4 节系统分析。

5.4 提示词还是微调 ​

前面几节，我们分别走完了两条路径的全程：RAG（检索增强生成）和 Fine-tuning（模型微调）。这两条路各有各的风景，各有各的坑洼。现在你站在工程实践的十字路口——每一个新项目启动时，都会面临同一个"灵魂拷问"：到底是花精力写复杂的提示词（Prompt + RAG），还是撸起袖子去做模型微调？

这个问题的答案不是"哪个更好"，而是"哪个更适合你的场景"。本章的使命就是给你一面决策天平，让你在具体约束下称出一侧的分量。

5.4.1 四维天平：一个理性的决策框架 ​

脱离场景谈技术选型是没有意义的。为了让决策变得可操作，我们把选择拆解为四个核心维度的权衡。每个维度背后，都对应着一笔你在项目中不得不算的账。

维度一：知识时效性——分钟级还是天级？

这是两条路径差距最大的维度。

Prompt + RAG 的知识时效性极高。 当你把一份新文档写入向量数据库、建立起索引的那一刻起，模型就能检索到它。流程非常简单：文档入向量库 → embedding 向量化 → 检索返回。整个过程可以在分钟内完成。这意味着如果公司的规章制度每周更新一次，你的 RAG 系统每周都能自动跟上变更。

Fine-tuning 的知识时效性则低得多。 微调的本质是"训练"——你要把新知识转化成模型权重的一次更新。每一次知识变更，意味着你要重新准备数据集、重新跑一轮训练、重新验证效果。即使是 LoRA 这样的轻量方案，一轮训练加评估也通常需要数十分钟到数小时；如果涉及全量微调，这个周期可能拉长到数天。

经验法则：如果知识的"半衰期"短于一周，优先走 RAG；如果知识相对稳定（如行业术语体系、固定代码规范），微调的增益才会覆盖其更新成本。

维度二：专业深度——事实检索 vs. 思维习惯与领域理解

很多人认为微调比 RAG "更聪明"——这是一个需要澄清的误解。实际上，它们各有所长，擅长的"专业深度"不在同一个维度上。

RAG 擅长的是"事实性知识"的检索。 比如：合同中的某条款是什么？药品说明书的某禁忌症怎么写？内部运维手册里的某条操作步骤是什么？这类问题的特征是：答案存在明确的文本证据，检索到了就能准确回答。RAG 的强项是把"有据可查"这件事做到极致——你甚至可以在回答中注明引文来源，让用户自己去核验。这种可追溯性在审计和合规场景中非常重要。

Fine-tuning 擅长的是"思维习惯"的塑造与"领域理解"的深化。 这里的思维习惯不是一个比喻——它是模型在权重层面真正学到的东西。比如一个金融风控团队希望模型输出的分析报告遵循某种固定的论证结构（先列事实、再引法规、最后给建议）；比如一个律所希望模型在引用判例时自动使用特定的引用格式和行文节奏。更重要的是，微调还带来了一层 RAG 做不到的能力：对领域"不言自明"的关系的真正理解——当一个期货交易文档提到"锁仓"和"升贴水"时，微调过的模型不是在做近义词替换，而是理解这两个概念在交易语境中的实际含义和相互关系。这些不是你可以写进提示词里的简单规则——它们是一种"语感"，一种内化的表达方式和认知框架。微调能把这些能力烙进模型的概率分布里去。这，就是从"记住"到"习得"的跨越。

核心区别：RAG 帮你"记住"知识，微调帮你"习得"能力。

维度三：算力门槛——推理 vs. 训练

这是一个容易被低估的技术债差距。

Prompt + RAG 只需要推理算力。 你的工作负载是：运行一个推理服务器来处理用户请求，再维护一个向量数据库来做检索。推理可以走市场上任何一家 API 厂商，也可以在自己的 GPU 服务器上跑开源模型。向量数据库的选择空间也非常大——从轻量的 Chroma（适合原型验证）到生产级的 Milvus 或 Qdrant，甚至可以不做向量库直接基于 Elasticsearch 做关键词检索。总体算力成本可控，中小企业也能承担。

Fine-tuning 需要在推理算力之上叠加训练算力。 即使使用 LoRA 这种参数高效微调方案，你仍然需要在显存中同时加载基座模型、LoRA 适配器和训练状态（优化器、梯度等）。以一个 7B 参数模型为例，LoRA 微调通常需要 16-24GB 显存；全量微调则可能需要 4-8 卡集群。而这些 GPU 在整个训练周期（可能数小时到数天）内是被完全占用的。更现实的痛点是：很多团队没有自有 GPU 资源，只能租用云 GPU 实例——这意味着每次微调都是一次额外的预算审批。

经验法则：如果你目前的推理阶段已经踩在算力预算的红线上，微调大概率不适合你。先把 RAG 跑起来，把效果做出来，再考虑用增量预算启动微调。

维度四：数据主权——你能控制自己的知识吗？

这是四个维度中最特殊的一个。前三个维度是"成本-收益"分析，第四个维度涉及到企业合规的硬约束。在某些行业，这个维度的结论可以直接否决前三个维度的分析结果。关于数据主权的详细讨论（包括商用 API 的隐性代价、私有化部署方案和现实中的权衡），参见下一节 5.4.2。

5.4.2 "数据主权"：不可逾越的红线 ​

在金融、政务、军工、医疗等强监管行业，"数据主权"不是一个技术选项，而是一条合规红线。当我们讨论数据主权时，实际在问一个问题：你的核心知识资产存放在哪里？

商用大模型 API 的隐性代价 ​

使用商用的推理 API（无论是 OpenAI、Anthropic 等海外厂商，还是 DeepSeek、阿里百炼等国内平台），意味着你的每一次模型调用，都在把请求内容——可能是客户资料、财务报表、未发布的软件源码、专利文档——通过网络发送到第三方厂商的服务器上。即便厂商在隐私协议中承诺"不将数据用于训练"，但在很多行业监管部门看来，数据离开自有网络这一行为本身就构成了合规风险。欧洲的 GDPR、中国的《数据安全法》和《个人信息保护法》都对企业数据传输有严格的约束。

更微妙的是：你无法审计。你不知道厂商的服务器上发生了什么，不知道请求日志保存了多久，不知道是否有内部员工能访问这些数据。在金融审计场景中，这种"黑盒信任"是难以接受的。

私有化部署：把主权握在自己手里 ​

私有化模型 + 微调是在合规框架内实现"数据不出域"的主要技术路径之一。需要说明的是：私有化部署能让推理请求不出网，但并不自动等于合规——模型权重的来源与供应链、推理日志的留存位置、运维通道（远程登录、监控上报、License 校验）是否出网，都需要单独评估。你可以在一台完全离线的 GPU 服务器上（或者一个受限的内网环境中），用自己的数据微调出一个属于自己的"特种模型"。在这样一个完全离线的部署里，训练和推理都可以全程留在你的物理边界内——训练数据在本地准备，训练过程在本地运行，推理也在本地完成。

更重要的是，微调之后的模型文件是你的知识资产。你可以在组织内部复制、分发、备份这个模型。即便将来切换了基座模型，只要你的训练数据还在，知识就可以迁移。这种"知识可迁移性"是 RAG 无法提供的——RAG 依赖的是外部知识库的持续维护，一旦索引损坏或数据库迁移出问题，知识就可能丢失。

红线法则：如果你的行业规定"数据不得出内网"，RAG 的商用 API 方案就不在可选集内。你需要在本地 RAG + 开源模型推理，和本地微调之间二选一。两种方案都可以在合规框架内实现数据主权要求。

现实中的权衡 ​

当然，私有化部署不是免费的午餐。它意味着你需要自己管理 GPU 硬件、维护模型运行时、处理推理负载均衡。但在数据主权面前，这些运维成本通常被视为"必要的代价"。许多企业的实际做法是：用本地部署的开源模型（如 Qwen、DeepSeek 等）跑 RAG，处理大部分常规查询；同时对最核心的、最需要"领域思维"的任务（如合规审查、风控分析）做私有化微调，让这两个路径在同一个内网环境中协同工作。

5.4.3 Prompt 和微调双轮驱动 ​

有了这四个维度的分析框架，我们来到最终的决策逻辑。在 2026 年的工程实践中，业界的共识已经不再是"Prompt 派"和"微调派"的二选一，而是**"双轮驱动"**——让两条路径各司其职，协同作战。

决策流程：先走 RAG，再按条件启动微调 ​

维护一个向量数据库比维护一条微调流水线的运维负担轻得多。因此，对于大部分业务场景，建议如下：

第一步：从 Prompt + RAG 起步。

如果你的目标是让模型"读懂公司的规章制度"、"根据文档写周报"、"回答内部 FAQ"，那么 RAG 就足够好了。你应该先建立起 RAG 的验证闭环：文档入库 → 检索质量评估 → 生成效果评估 → 反馈优化。这条路的技术栈高度成熟，开源方案丰富，团队上手成本低。多数情况下，一个配置合理的 RAG 系统已经能解决 80% 的问题。

更重要的是，RAG 的验证过程本身就能给你提供关键的"诊断信号"——当你发现 RAG 在某些场景下反复表现不佳时，这些失败案例就是你决定是否启动微调的最佳数据来源。

第二步：当以下四条红线触发时，果断启动微调。

  1. 格式约束严苛，提示词已经力不从心。

    你在提示词里写了 "请输出合法的 JSON，字段包括 name、id、status"，但模型偶尔还是会多一个逗号、少一个引号，或者在嵌套里塞了一个不该出现的字段。你尝试了几十种提示词变体，引入了 Pydantic 校验、正则清洗、重试机制——但线上的错误率始终降不到零。这不是你提示词写得不好，而是格式约束已经超出了提示词的"控制精度"。微调可以在训练数据中直接注入格式样本，让模型在概率层面学到"这类任务就必须输出这种格式"，从根本上降低格式错误率。

  2. 行业黑话太多，RAG 能检索到文档但"读不懂"。

    你给 RAG 喂了内部的技术文档，文档里写道："做空对冲需要同步锁仓，注意交割日的升贴水变化。" 把这句话放进向量库里，模型能检索到，但生成出来的解释让人觉得它根本不懂"锁仓"和"升贴水"在期货交易中的实际含义——它只是在做近义词替换。这种情况下，你需要微调。微调让模型在接触大量领域语料后，真正内化行业术语之间那些"不言自明"的关系。

  3. 为了极致降本，希望用小模型达到大模型效果。

    这是微调最具吸引力的场景之一。你要处理一个高频但领域狭窄的任务——比如客服工单分类、内部邮件路由、标准合同条款审查。如果直接用 GPT-4 级别的 API，每天的调用费用可能上千元。但你想用一个 1.5B 或 7B 的小模型来做这件事。这时候，微调就是你的"降维打击"武器：用几万条领域标注数据训练这个小模型，它在这个特定任务上的表现可以超过没有被微调的 70B 通用模型。而推理成本降低了一个数量级——7B 模型可以在消费级显卡上流畅运行。

  4. Agent 工具链需要"无缝衔接"。

    你正在用 Claude Code 或 OpenClaw 搭建本地的智能 Agent，让它自动调用你公司内部的几十个 API。但基座模型并不了解这些 API 的调用方式、参数格式、错误码含义。你在提示词里写了一整页 API 文档摘要，但 Agent 偶尔还是会调用不存在的端点，或者混淆了 POST 和 GET。微调可以解决这个问题——把你司的 API 文档、调用示例、错误处理逻辑作为微调语料，让模型在权重层面"学会"如何使用你的工具链。关于如何准备这类训练数据，可回顾 5.3.2 节的 SFT 训练数据示例。微调之后的 Agent 不再是"看手册操作"，而是"凭直觉操作"。

终极方案："FT 底座 + RAG 外挂" ​

写到这里的读者可能会问：那到底是选 RAG 还是选微调？答案是：都不要单选，把它们组合起来。

在 2026 年（截至 2026 年 6 月的工程实践），最成熟的技术方案是这样一个架构：

  • 底座层：用一个经过领域微调的小模型（如 Qwen2.5-7B 或 DeepSeek-7B，用你的领域数据做 LoRA 微调）作为"大脑"。这个模型经过微调后，已经内化了你的行业术语、输出格式、工作流程——它知道该怎么"思考"你的业务问题。

  • 记忆层：在底座之上，接入精准的 RAG 检索系统作为"外部记忆"。向量数据库中存储那些高频变更的知识——规章制度、操作手册、知识库文章、最新的市场数据。模型在需要"查阅"时，自动触发检索流程。

这个架构的优雅之处在于，它把两种能力的边界划得很清楚：微调负责"内功"——思维习惯、表达风格、格式规范、领域直觉；RAG 负责"外功"——实时知识检索、事实依据、引文溯源。 微调让你拥有一个"懂行的专家"，RAG 让这个专家能随时"翻看最新的资料"。

更关键的是，这个架构让你在合规框架内完全掌握了数据主权：模型文件在你的内网中，向量数据库在你的内网中，训练数据和推理数据都不出域。你的数字员工既有深度，又有时效，且完全掌握在自己手中。

本章总结 ​

这一章我们走完了一条完整的认知路径：从 RAG 的核心机制（提示词嵌入与上下文构造），到 Fine-tuning 的技术全景（SFT、RLHF、PEFT、FFT），再到最终的决策框架——四维天平加黄金准则。

还记得 5.3 节的那句话吗？"Prompt 决定上限，Fine-tuning 决定下限。" 本章的结论正是这句话的延伸：用 RAG 拓展模型能触及的知识边界（拉高上限），用微调夯实模型的专业根基（守住下限），把两种能力组合起来，就是 2026 年大模型应用落地的最优解。

如果只能记住一件事，请记住这个：

内功（FT）+ 外功（RAG）= 既有深度，又懂时效，上限与下限兼得，且完全掌握在自己手中的有效的方案。

这不是妥协，而是工程智慧的结晶。提示词和微调从来不是对立的，它们是同一个系统中分工不同的两套"记忆机制"。你的任务不是选择一边，而是学会让它们并肩作战。