企业 AI 模型工程与 Agent 架构实践指南

从后训练、LoRA、推理蒸馏、RAG 到企业智能体系统

版本：1.0 定位：企业 AI 技术知识库、模型工程入门与方案架构参考 适用读者：AI 产品负责人、解决方案架构师、算法工程师、应用开发者及希望使用消费级显卡开展模型实验的技术人员

本文系统整理大模型微调、后训练、CoT 数据、LoRA、RAG、Agent、模型部署和评估等概念。重点不是罗列术语，而是解释每项技术解决什么问题、不能解决什么问题、如何组合，以及如何在企业场景中形成可落地的技术体系。

文中案例均为通用示例，不绑定具体公司或产品。

RAG 的本质：参数化记忆与外部记忆
为什么企业知识通常不应训练进模型
企业 RAG 的完整数据链路
文档解析、Chunk 和上下文组织
Embedding 模型与多语言检索
向量检索、BM25、Hybrid Search 与 RRF
Reranker 与两阶段检索
Metadata、权限和知识时效
GraphRAG、Agentic RAG 与查询分解
RAG 常见失败原因与评估

第六篇　训练、部署与评估实践

RTX 5070 Ti 12GB 能做什么
本地训练工具选择
从数据到 LoRA 的完整实验流程
模型部署：Ollama、llama.cpp、vLLM 与 SGLang
结构化输出、约束解码与服务治理
评估体系：不要只看 Loss
数据飞轮与持续改进
企业 AI 分阶段落地路线
必须掌握的概念清单

第一篇　建立正确的大模型认知

1. 企业 AI 的本质：知识、能力与执行

讨论企业 AI 时，最容易混淆的是三件事：

模型知道什么；
模型会做什么；
模型能够在系统中执行什么。

这三件事分别对应知识、能力和执行。

1.1 知识：模型是否能获得正确事实

例如用户询问：

某产品 2026 年 7 月生效的售后政策是什么？

这是一个知识问题。答案可能存在于政策文件、产品数据库或业务系统中，而且会随时间变化。最适合的技术通常是：

RAG；
数据库查询；
搜索；
API；
知识图谱。

知识问题的关键指标不是“说得像不像”，而是：

是否使用正确版本；
是否具备来源；
是否考虑权限；
是否及时更新；
是否避免将过期信息与当前信息混合。

1.2 能力：模型是否掌握稳定的处理方法

例如输入一条评论：

车内空间不错，已经试驾过，但还想对比一下冬季续航和贷款方案。

系统希望输出：

{
  "purchase_stage": "A3",
  "intent": "product_comparison",
  "topics": ["空间", "试驾", "冬季续航", "金融方案"],
  "recommended_action": "提供冬季续航实测与金融方案对比，并安排二次跟进"
}

这里真正要训练的是：

如何识别购买阶段；
如何映射企业标签；
如何生成下一步动作；
如何保持固定结构；
如何处理边界案例。

这类稳定的工作方法适合：

SFT；
LoRA / QLoRA；
偏好优化；
规则与模型组合；
结构化输出约束。

1.3 执行：模型是否可以完成业务动作

如果系统需要进一步：

查询该客户在 CRM 中的历史；
获取已试驾车型；
检索最新金融政策；
生成跟进建议；
创建销售任务；
记录本次处理结果；

这已经不只是生成文本，而是 Agent 与工具执行问题，需要：

Tool Calling；
工作流编排；
鉴权；
状态管理；
审批；
重试与回滚；
操作日志。

因此，一个实用的企业 AI 系统可以抽象为：

模型能力 = 理解、判断、生成
外部知识 = 文档、数据库、搜索、实时数据
Agent Runtime = 规划、路由、工具调用、状态和审计

一个常用判断口诀是：

RAG 解决“知道什么”，微调解决“怎么做”，Agent 解决“做下去”。

这不是绝对边界，但适合作为企业项目的首要架构原则。

2. 大模型的主要类型

Hugging Face 上的“模型”并不都是同一种东西。理解模型类型，才能判断它适合训练、推理、检索还是排序。

2.1 Base Model：基础模型

Base Model 是完成预训练、但未充分进行指令对齐的模型。它擅长续写文本，而不一定稳定遵循聊天指令。

典型特点：

适合继续预训练；
适合构建自定义后训练路线；
对系统提示的遵循可能弱于 Instruct 模型；
可能输出延续文本，而不是直接回答。

基础模型更接近“语言建模底座”。

2.2 Instruct / Chat Model：指令或对话模型

这是在 Base Model 上完成 SFT 和对齐后的模型。

它通常学会了：

区分 system、user、assistant 角色；
回答用户问题；
遵循格式；
拒绝部分请求；
使用工具调用格式；
保持对话风格。

大多数应用开发应从 Instruct 模型开始，而不是 Base Model。

2.3 Reasoning Model：推理模型

推理模型经过推理数据蒸馏、偏好优化或强化学习训练，目标是提升：

数学；
代码；
多步逻辑；
规划；
可验证任务。

它的特点可能包括：

生成更长的中间推理文本；
测试时使用更多 Token；
在复杂任务上强于同规模普通 Instruct 模型；
在简单分类、抽取任务上未必更划算；
可能出现“过度思考”，导致延迟和成本上升。

因此 Reasoning Model 不是所有企业任务的默认选择。对固定分类、JSON 抽取、路由等任务，经过良好 SFT 的小型 Instruct 模型往往更高效。

2.4 Embedding Model：向量表征模型

Embedding 模型不是聊天模型。它负责将文本、图片或其他内容映射成向量，使语义相似内容在向量空间中接近。

主要用于：

语义搜索；
聚类；
去重；
推荐；
RAG 召回；
相似度计算。

RAG 中的 Embedding 模型和最终生成答案的 LLM 通常是两个独立模型。

2.5 Reranker：重排序模型

Reranker 通常接收一对输入：

(query, document)

然后输出该文档与查询的相关性分数。

它与 Embedding 模型的区别是：

Embedding 模型可提前计算文档向量，适合大规模快速召回；
Reranker 同时读取 query 和 document，精度更高但计算更慢；
常见做法是先召回 50～200 条，再用 Reranker 选择最相关的 5～15 条。

2.6 Reward Model / Judge Model：奖励或评审模型

这类模型用于评价另一个模型的输出，例如：

两个回答哪个更好；
是否遵守格式；
是否包含事实错误；
推理步骤是否合理；
工具调用是否成功。

奖励模型可用于 RLHF，也可作为离线评测器。但要注意，评审模型本身也会偏置和犯错，不能用一个模型评分代替所有人工或规则验证。

2.7 VLM 与多模态模型

VLM 能同时处理图片和文字，部分模型还支持音频、视频和屏幕界面。

企业场景包括：

PDF 图表理解；
商品图片审核；
维修图片识别；
单据和表格分析；
UI 操作 Agent；
视频内容理解。

多模态模型的训练与部署通常比纯文本模型更复杂，且图像分辨率、视觉 Token 数量会显著影响显存和延迟。

3. 从预训练到后训练的完整链路

现代开源模型通常不是完成一次训练就结束，而是经历多阶段加工。

预训练
  ↓
领域继续预训练（可选）
  ↓
SFT 指令微调
  ↓
偏好优化
  ↓
推理强化或工具训练（可选）
  ↓
蒸馏、量化和部署优化

3.1 Pre-training：预训练

预训练使用大规模文本，通过“预测下一个 Token”学习语言和知识。

模型在这一阶段学习：

语法；
语言风格；
常识；
领域概念；
代码模式；
一部分推理结构。

预训练成本最高，通常需要：

海量 Token；
大规模 GPU 集群；
数据治理；
分布式训练；
长期实验。

对于个人和多数企业，从零预训练 1B 以上通用模型通常没有成本优势。更合理的是复用成熟的 Base 或 Instruct 模型。

3.2 Continued Pre-training：继续预训练

继续预训练是在已有基础模型上继续使用领域文本进行语言模型训练，也称：

Domain-Adaptive Pretraining（DAPT）；
Continual Pretraining；
Continued Pretraining。

它适合解决：

模型不熟悉专业术语；
领域文体与通用文本差异大；
需要提升模型对某类原始文本的理解和生成能力；
有规模较大的无标注领域语料。

例如法律模型可能使用：

法律条文；
判决文书；
合同；
法学论文。

继续预训练并不自动让模型学会“回答法律问题”。通常还要经过 SFT，教模型如何在法律任务中输出答案。

3.3 SFT：监督式指令微调

SFT 使用“输入—理想输出”样本，让模型学习任务行为。它解决：

指令遵循；
格式；
标签体系；
专业表达；
工具调用示例；
固定工作流程。

这是个人和企业最常用的后训练方法。

3.4 Preference Alignment：偏好对齐

SFT 能让模型模仿答案，但未必能区分“合格回答”和“优秀回答”。偏好数据通常提供：

Prompt；
Chosen；
Rejected。

模型学习在同一个问题下更偏向 Chosen。

常见方法包括：

DPO；
ORPO；
SimPO；
KTO；
IPO；
CPO 等。

3.5 Reinforcement Learning：强化学习

强化学习不只模仿固定答案，而是根据 Reward 优化生成策略。

早期典型路线是 RLHF：

SFT；
收集人类偏好；
训练 Reward Model；
用 PPO 优化策略。

较新的推理训练大量采用可验证奖励：

数学答案是否正确；
代码测试是否通过；
SQL 执行结果是否匹配；
JSON 是否满足 Schema；
工具调用是否完成目标。

这类方法通常称为 RLVR。

3.6 Distillation：蒸馏

蒸馏使用强模型产生高质量输出，训练较小模型模仿其能力。

蒸馏可以传递：

答案；
风格；
任务策略；
工具调用轨迹；
推理过程；
多轮对话模式。

但蒸馏效果受制于：

教师输出质量；
任务覆盖；
过滤方法；
学生模型容量；
训练目标；
数据合法性和许可条件。

4. 参数、Token、上下文和显存

4.1 参数量不等于文件大小，也不等于显存占用

一个模型有 2B 参数，若使用 BF16，每个参数大约 2 字节，仅权重理论值约为：

2,000,000,000 × 2 bytes ≈ 4 GB

但训练还需要：

梯度；
优化器状态；
激活值；
临时张量；
CUDA 内核工作区；
量化元数据；
LoRA 参数；
评估或缓存。

因此“模型能推理”不代表“模型能全参数训练”。

4.2 推理显存的主要组成

模型权重
+ KV Cache
+ 激活与临时缓冲
+ 框架开销

KV Cache 与以下因素有关：

上下文长度；
batch size；
并发数；
层数；
hidden size；
KV head 数量；
KV Cache 精度。

因此部署时 4K 上下文能跑，不代表 32K 上下文仍能保持相同并发。

4.3 训练显存的主要组成

模型权重
+ 可训练参数梯度
+ 优化器状态
+ 前向激活
+ 反向传播缓存
+ 临时缓冲

全参数 AdamW 训练中，优化器状态可能占据大量显存。LoRA 的关键价值是冻结大部分权重，显著减少梯度和优化器状态。

4.4 Tokenizer 的重要性

模型并不直接读取“字”或“单词”，而是读取 Token。

同一句话在不同模型中的 Token 数可能不同，尤其是：

中文；
泰语；
日语；
代码；
数字与型号；
行业缩写。

Tokenizer 效率影响：

上下文可容纳的信息；
推理成本；
训练成本；
多语言效果；
结构化字符串的稳定性。

选择多语言小模型时，不只要看 Benchmark，还应测试真实业务语料的 Token 长度。

4.5 Context Window 不是长期记忆

上下文窗口只是模型本次推理可以看到的 Token 范围。它不是：

永久记忆；
数据库；
企业知识库；
无限容量。

即使模型支持很长上下文，也会遇到：

首尾信息偏置；
中间内容被忽视；
成本和延迟上升；
噪声干扰；
事实冲突；
召回不精准。

长上下文和 RAG 是互补关系，而不是替代关系。

5. Prompt、RAG、微调、继续预训练和 Agent 如何选择

下面是一个实用决策框架。

5.1 先用 Prompt 的情况

适合：

任务简单；
使用频率低；
不要求严格一致；
模型本身已有能力；
只是需要明确格式或角色。

例子：

将下面文字改写成正式商务语气。

如果通过少量示例和结构化提示已经稳定，不必急于微调。

5.2 使用 RAG 的情况

适合：

知识会变化；
需要引用来源；
文档数量大；
不同用户权限不同；
需要按版本、地区或时间查询；
知识来自数据库和业务系统。

例子：

根据当前生效的售后政策回答，并列出条款来源。

5.3 使用 SFT / LoRA 的情况

适合：

需要固定任务能力；
提示词越来越长；
模型经常不遵循格式；
需要学习内部标签；
需要稳定的工具调用；
有大量重复任务；
想让小模型替代昂贵大模型。

例子：

将评论稳定映射到 30 个标准意图和 6 个购买阶段。

5.4 使用偏好优化的情况

适合：

多个答案都“基本正确”，但有明显质量层次；
很难为所有问题写唯一标准答案；
需要专家风格；
需要减少冗余、空话或不恰当建议。

例子：

同一客户情况，两个跟进方案都可执行，但专家认为其中一个优先级更合理。

5.5 使用继续预训练的情况

适合：

领域语料规模较大；
专业语言与通用语言差异明显；
模型基础领域能力不足；
有稳定、合法、清洗后的无标注语料；
可以承担训练和评估成本。

不适合把每月变化的价格表、政策和用户数据通过继续预训练“硬记”进模型。

5.6 使用 Agent 的情况

适合：

任务包含多个步骤；
需要访问外部系统；
需要根据中间结果决定下一步；
需要状态、权限、审批和审计；
结果不只是文本，而是实际业务动作。

5.7 组合案例

以“企业知识客服”为例：

Prompt
  定义回答语气和引用规范

RAG
  查询产品文档、政策、FAQ

SFT / LoRA
  学习意图分类、回答结构和升级规则

Tool Calling
  查询订单、库存或服务状态

Agent Workflow
  判断是否自动处理、转人工或创建工单

如果一个系统的问题主要是“找不到正确文档”，先优化 RAG，不要先训练模型。

如果检索结果正确，但模型经常输出错误格式或不能按业务规则处理，再考虑 SFT。

如果模型能做任务，但不能访问实时系统，则需要 Tool Calling 与 Agent Runtime。

第二篇　大模型后训练体系

6. SFT：模型任务能力的起点

SFT（Supervised Fine-Tuning，监督式微调）可以理解为“用示范教模型工作”。

训练样本告诉模型：

什么输入对应什么输出；
怎样组织答案；
哪些字段必须出现；
遇到模糊情况如何处理；
什么语气、长度和粒度符合要求；
如何生成工具调用参数。

Hugging Face TRL 提供 SFTTrainer，可直接训练完整模型或通过 PEFT 训练 Adapter。SFT 仍然使用语言模型的 Token 预测目标，但训练数据经过了任务化组织。

6.1 SFT 训练的不是“数据库”

假设有一份 300 页产品手册。将手册中的事实改造成问答后进行 SFT，模型可能在测试中记住部分答案，但存在几个问题：

不能保证完整记忆；
不能保证精确复述；
文件更新后不能立即同步；
无法稳定提供原始出处；
相似条款可能相互干扰；
训练后很难删除单条知识。

因此，SFT 更适合训练“如何使用知识”，而不是“永久存储所有知识”。

例如不要只训练：

问：A 产品的质保期是多少？
答：三年。

更值得训练的是：

输入：
用户问题 + 检索到的有效政策片段

输出：
先确认产品型号和生效时间，再基于资料回答，并给出来源。

这使模型学会基于证据回答，具体知识仍由 RAG 提供。

6.2 SFT 可以解决的典型问题

固定结构化输出

{
  "intent": "complaint",
  "severity": "high",
  "topics": ["交付", "服务"],
  "next_action": "create_ticket"
}

内部分类体系

通用模型可能知道“购买意向”，但不知道企业自定义的 A1～A5 阶段定义。SFT 可以让模型学习这些标签的边界。

工具调用格式

{
  "name": "query_order",
  "arguments": {
    "order_id": "A10293"
  }
}

专业分析方法

输入一段市场数据，输出：

数据事实；
异常点；
可能原因；
需要补充的证据；
可执行建议；
风险和限制。

统一品牌或组织表达

SFT 可以减少模板化空话，强化固定术语、段落结构和表达风格。但风格数据不应覆盖事实准确性和任务能力。

6.3 SFT 的局限

SFT 本质是模仿训练。它可能出现：

学会表面格式，但没有学会真正判断；
记住训练样本措辞，对新分布泛化差；
数据中的错误被复制；
类别不平衡导致少数类失效；
长答案占据大量训练 Token，却没有增加任务信息；
训练集表现很好，真实业务效果不升反降。

因此，SFT 的重点不是“跑通训练”，而是定义任务、设计数据和建立评测。

7. SFT 数据工程与样本设计

7.1 先定义任务，不要先收集数据

一个常见错误是先收集几十万条聊天记录，再思考怎样训练。更合理的顺序是：

业务目标
→ 决策边界
→ 输入和输出 Schema
→ 标签定义
→ 正反例
→ 边界案例
→ 数据采集和标注
→ 训练与评估

例如“判断购买意向”需要先定义：

A2 与 A3 如何区分；
询价是否一定是 A4；
已购买后的咨询属于 A5 还是售后意图；
同时出现投诉和复购意向如何标注；
缺少证据时是否输出 unknown；
是否允许多标签。

没有明确标注规则时，模型只会学习标注人员之间的不一致。

7.2 常见数据格式

Alpaca / Instruction 格式

{
  "instruction": "判断评论的购买阶段并给出理由",
  "input": "已经试驾过两次，准备周末谈最终价格。",
  "output": "{\"stage\":\"A4\",\"reason\":\"已完成多次试驾且准备进行价格谈判\"}"
}

适合单轮任务，结构简单。

Chat / Messages 格式

{
  "messages": [
    {
      "role": "system",
      "content": "你是用户意图分析助手，只输出合法 JSON。"
    },
    {
      "role": "user",
      "content": "已经试驾过两次，准备周末谈最终价格。"
    },
    {
      "role": "assistant",
      "content": "{\"stage\":\"A4\",\"reason\":\"已完成多次试驾且准备进行价格谈判\"}"
    }
  ]
}

更适合现代 Chat Model，能够保留角色和多轮上下文。

Prompt-Completion 格式

{
  "prompt": "评论：已经试驾过两次，准备周末谈最终价格。\n分析：",
  "completion": "{\"stage\":\"A4\"}"
}

适合补全式任务。

Tool Calling 轨迹格式

{
  "messages": [
    {"role": "user", "content": "查询订单 A10293 的物流状态"},
    {
      "role": "assistant",
      "tool_calls": [
        {
          "name": "query_order",
          "arguments": {"order_id": "A10293"}
        }
      ]
    },
    {
      "role": "tool",
      "name": "query_order",
      "content": "{\"status\":\"in_transit\",\"eta\":\"2026-07-19\"}"
    },
    {
      "role": "assistant",
      "content": "订单正在运输中，预计 2026 年 7 月 19 日送达。"
    }
  ]
}

不同训练框架对字段格式要求不同，必须确认对应模型的 Chat Template 和工具调用模板。

7.3 训练答案是否应包含推理过程

需要区分三类输出：

最终答案；
面向用户的简要理由；
长篇内部推理轨迹。

企业任务通常不需要每次输出长 CoT。更推荐：

{
  "stage": "A3",
  "evidence": [
    "正在比较两种车型",
    "询问冬季续航"
  ],
  "confidence": 0.83
}

这种“可审计理由”比自由展开的长篇思维链更短、更稳定、更容易评估。

如果训练长 CoT，模型可能学会：

输出大量重复推理；
在简单任务上过度消耗 Token；
将不可靠的自我解释当成事实；
暴露不必要的内部判断细节。

因此，CoT 数据应主要用于复杂推理能力，而不是所有任务的默认输出。

7.4 数据质量维度

高质量训练样本应满足：

正确性

答案、标签和工具参数必须正确。

一致性

相同输入应遵循相同决策规则。

覆盖度

覆盖正常案例、少数类、边界案例、异常输入和对抗输入。

多样性

不能只替换同一模板中的名词。需要包含不同措辞、长度、平台语言和上下文。

信息密度

每个 Token 都应尽可能携带任务信息。冗长但重复的输出会浪费训练预算。

可评估性

输出应能通过规则、人工或程序判断是否正确。

7.5 真实数据与合成数据如何组合

一种实用比例不是固定数字，而是功能分工：

真实数据覆盖真实分布；
专家标注确定任务标准；
合成数据补足稀缺类别；
对抗数据暴露模型弱点；
负样本帮助模型学会不做什么；
历史错误案例用于定向修复。

典型流程：

真实业务样本
→ 去除敏感信息
→ 专家标注少量黄金集
→ 强模型生成扩充样本
→ 规则和模型过滤
→ 人工抽检
→ 训练
→ 从错误中回采新样本

合成数据不能只靠教师模型一次生成。最好增加：

多教师交叉生成；
答案验证；
去重；
难度分层；
风格清洗；
标签到文本的一致性检查。

7.6 数据泄漏与评测污染

训练集、验证集和测试集不能只是随机切分同一批模板数据。否则相似样本可能同时出现在训练和测试中。

更严格的切分方法包括：

按时间切分；
按用户或账号切分；
按产品类别切分；
按原始文档切分；
按问题模板簇切分。

例如同一条评论的改写版本必须放在同一数据集分区。

7.7 样本数量没有统一答案

可参考以下经验范围：

100～500 条：验证格式和流程；
1,000～5,000 条：明确任务的第一版模型；
5,000～30,000 条：覆盖较复杂边界；
数十万条：通用指令、长尾任务或推理蒸馏；
更大规模：需要更严格的数据治理和训练策略。

一个 1B～2B 模型不一定能吸收所有复杂业务规则。模型容量、任务复杂度和数据质量必须匹配。

8. CoT、Reasoning 与推理蒸馏

8.1 CoT 是什么

CoT（Chain of Thought）指在最终答案之前生成或学习中间推理步骤。

普通样本：

问题：某商品单价 12 元，购买 8 件，总价多少？
答案：96 元。

CoT 样本：

问题：某商品单价 12 元，购买 8 件，总价多少？
分析：总价等于单价乘以数量，即 12 × 8 = 96。
答案：96 元。

CoT 的价值在于把一个困难映射拆成多个较容易的 Token 预测步骤。

8.2 Reasoning Model 不等于“真的像人一样思考”

语言模型生成的推理文本仍然是模型输出。它可能：

先得到答案再编写解释；
中间步骤看似合理但结论错误；
中间步骤错误但碰巧得到正确答案；
在提示变化后产生不同解释；
将训练中学到的推理模板套到不适合的问题上。

因此，推理文本不能天然视为可信证据。对高风险任务，应使用：

外部验证器；
规则；
工具；
数据库；
多重检查；
人工审批。

8.3 隐藏思维链和公开推理文本

商业模型通常不会公开其完整内部推理过程。Hugging Face 上标注“Claude CoT”或“GPT reasoning”的数据，通常是以下之一：

教师模型按提示输出的解释；
可见的 reasoning trace；
根据最终答案重新构造的推理；
多轮自我修正文本；
第三方收集的 API 输出。

它们不等同于模型内部未公开的隐藏推理状态。

8.4 推理蒸馏的基本流程

问题池
→ 强教师模型生成多条推理轨迹
→ 验证最终答案
→ 过滤格式和质量
→ 去重与难度控制
→ 学生模型 SFT
→ 使用测试时扩展或偏好优化

关键不是教师“写得长”，而是：

最终结果正确；
推理对解决问题有帮助；
数据覆盖不同方法；
学生模型能够承载；
推理长度与部署成本合理。

8.5 Outcome Reward 与 Process Reward

Outcome Reward

只看最终答案是否正确。

优点：

容易自动验证；
成本低；
不限制模型探索路径。

缺点：

无法判断中间过程；
可能奖励碰巧正确的答案。

Process Reward

评价中间步骤是否合理。

优点：

能更细粒度指导推理；
可发现错误发生的位置。

缺点：

标注成本高；
中间步骤的“正确性”有时难定义；
奖励模型可能偏向固定写法。

企业任务经常更适合“最终业务约束 + 关键步骤规则”混合奖励，而不是逐句评价长推理。

8.6 Test-Time Scaling

推理能力不仅来自训练，也来自推理时投入更多计算，例如：

生成多个候选答案；
多数投票；
Best-of-N；
自我一致性；
搜索不同推理路径；
使用验证器选择；
设置思考 Token 预算。

这意味着“模型能力”并非单一静态数字。相同模型在不同推理预算下可有不同效果和成本。

9. 较新的开源推理数据集

以下数据集主要兴起于 2025 年前后，适合研究推理蒸馏。数据集状态可能更新，使用前应重新查看 Dataset Card、License、字段和提交版本。

9.1 OpenR1-Math-220k

仓库：

open-r1/OpenR1-Math-220k

主要特点：

约 22 万个数学问题；
每个问题包含 2～4 条由 DeepSeek-R1 生成的推理轨迹；
问题来源于 NuminaMath 1.5；
多数样本使用 Math Verify 验证；
每个问题至少包含一条最终答案正确的轨迹；
适合数学推理 SFT 和验证研究。

适合：

数学模型；
推理格式研究；
Verifier 流程；
小模型数学能力蒸馏。

不适合直接作为：

企业知识问答数据；
营销分析数据；
客服任务数据；
通用多领域 Agent 数据。

风险：

数学推理风格可能使模型在普通任务上过度展开；
多条轨迹并不保证每一步都严格正确；
长序列会显著增加训练显存和时间。

9.2 OpenThoughts-114k

仓库：

open-thoughts/OpenThoughts-114k

主要特点：

约 11.4 万条开放合成推理样本；
覆盖数学、科学、代码和谜题；
比纯数学数据更通用；
包含较长推理轨迹。

使用时要注意：

不同子集的可验证程度不同；
原始数据的元数据可能不够丰富；
某些数学过滤版本会根据 Math Verify 保留可验证样本；
平均推理长度可能很长，需统计真实 Token 分布。

对 12GB 显存，不建议直接使用全部长样本。可以：

先按领域过滤；
限制最大长度；
保留 5,000～20,000 条；
使用 curriculum，从较短轨迹开始；
测试普通任务是否退化。

9.3 Bespoke-Stratos-17k

常见仓库名称为：

bespokelabs/Bespoke-Stratos-17k

它的价值在于“小而相对精选”，常用于 DeepSeek-R1 风格推理蒸馏实验。

适合：

跑通 Reasoning SFT；
小规模消融实验；
比较普通 SFT 与 CoT SFT；
消费级显卡上的数据子集实验。

但“17k”不意味着全部样本都适合目标模型。仍需检查：

长度；
领域；
最终答案；
License；
重复；
格式；
是否含不需要的系统提示。

9.4 s1K

仓库：

simplescaling/s1K

特点：

1,000 个高质量、困难、多样的问题；
使用 Gemini Thinking 蒸馏推理轨迹和答案；
用于 s1 的简单测试时扩展研究；
体现“少量精选数据 + 测试时预算控制”的思路。

s1K 的研究启示是：

推理能力提升不一定只靠海量数据，样本选择、难度、轨迹质量和测试时策略同样关键。

它更适合作为研究或基线，不应被理解为“1,000 条数据就能把任何小模型变成通用推理模型”。

9.5 Mixture-of-Thoughts

Open-R1 项目在 2025 年公布了约 35 万条经过策划和验证的推理轨迹混合数据，覆盖数学、代码和科学任务。

这类混合数据的意义是：

避免模型只学数学格式；
增加跨领域推理模式；
使用可验证任务减少纯主观评审；
构建更接近通用 Reasoning SFT 的数据分布。

9.6 GSM8K、MATH 等经典数据

虽然更早，但仍有价值：

GSM8K

小学应用题；
训练和评测简单算术推理；
难度较低；
容易出现 Benchmark 饱和或数据污染。

MATH

数学竞赛题；
难度更高；
有详细解答；
适合测试数学推理泛化。

代码数据

代码推理应优先选择：

有单元测试；
有可执行环境；
有明确输入输出；
License 清晰；
能进行沙箱验证的数据。

9.7 如何为企业场景构建自己的 Reasoning 数据

企业业务不应照搬数学 CoT。更实用的格式是“证据—判断—动作”。

例如：

{
  "input": {
    "comment": "已经试驾，准备比较两家的贷款利率。",
    "history": ["浏览金融方案", "下载配置表"]
  },
  "analysis": {
    "evidence": [
      "已经完成试驾",
      "主动比较贷款利率",
      "历史上浏览金融方案"
    ],
    "stage": "A4",
    "risk": "仍在比较竞品"
  },
  "output": {
    "recommended_action": "提供月供对比并安排销售跟进"
  }
}

这种数据保留了可审计的判断依据，但避免自由散漫的长 CoT。

9.8 开源推理数据的选择清单

使用前检查：

数据集是谁生成的；
教师模型是什么；
是否有最终答案验证；
是一题一轨迹还是多轨迹；
平均和 P95 Token 长度；
领域占比；
系统提示是否统一；
是否包含模型拒答或异常文本；
License 是否允许训练和发布；
是否与评测集重叠；
是否适合学生模型容量；
是否需要保留 <think> 标签；
部署时是否希望模型输出推理文本。

10. 偏好优化：DPO、ORPO、SimPO 与 KTO

10.1 为什么 SFT 之后还需要偏好优化

SFT 只能告诉模型“这里有一个示范答案”，但无法直接表达：

A 和 B 都能用，但 A 更专业；
B 太啰嗦；
A 的风险提示更完整；
B 虽然格式正确，但建议不可执行。

偏好数据使用成对比较：

{
  "prompt": "根据客户情况生成跟进建议",
  "chosen": "先提供两种金融方案的月供对比，再确认决策时间。",
  "rejected": "建议销售继续保持联系并耐心跟进。"
}

Chosen 比 Rejected 更具体、可执行。

10.2 DPO

DPO（Direct Preference Optimization）直接优化模型，使 Chosen 的相对概率高于 Rejected，同时通过参考模型或隐式约束避免模型偏离过远。

特点：

不必先训练显式 Reward Model；
比完整 PPO 路线简单；
可与 PEFT / LoRA 结合；
对数据对质量非常敏感。

DPO 数据中的 Rejected 不应全是明显垃圾。更有价值的是“困难负样本”：

事实大致正确但缺少关键约束；
建议合理但优先级错误；
格式合法但不符合业务标准；
过度承诺；
没有引用证据；
使用了过期政策。

10.3 ORPO

ORPO 将监督学习目标和偏好目标结合在一个训练阶段中，目的是减少“先 SFT 再偏好优化”的复杂性。

适合：

数据已经包含 Chosen / Rejected；
希望一次训练同时学习答案和偏好；
资源有限、流程简化的实验。

但一次训练并不必然优于分阶段训练。对于复杂企业模型，分开训练更容易诊断问题。

10.4 SimPO

SimPO 使用更简单的偏好优化形式，以模型输出的平均对数概率等构造偏好目标，减少对参考模型的依赖。

其价值在于：

实现相对简单；
降低部分训练开销；
在某些研究设置中表现良好。

实际采用前需要根据当前框架实现、模型和数据进行验证，不应只因为算法更新就替换稳定的 DPO 流程。

10.5 KTO

KTO 可使用非成对的“好 / 坏”反馈，而不要求同一 Prompt 下严格提供 Chosen 与 Rejected 配对。

这对企业反馈数据可能更方便，因为真实系统中常见的是：

用户点赞某次回答；
专家标记某次回答不可用；
销售采纳或拒绝建议；
工具调用成功或失败。

但行为反馈可能受很多外部因素影响。例如“没有采纳建议”不一定代表建议错误，也可能是用户没有时间。因此需要谨慎定义标签。

10.6 偏好优化的常见问题

Chosen 与 Rejected 长度差异过大，模型只学会偏好长度；
Rejected 过于低质，任务太容易；
偏好标准不一致；
数据只覆盖少数风格；
优化过度导致模型失去多样性；
模型学会讨好评审器，而非提高真实业务效果；
参考模型、beta 等参数设置不当。

11. 强化学习：RLHF、RLVR、PPO 与 GRPO

11.1 RLHF 的经典流程

预训练模型
→ SFT
→ 收集人类偏好
→ 训练 Reward Model
→ 使用 PPO 优化策略模型

PPO 需要管理：

Policy Model；
Reference Model；
Reward Model；
Value Model 或 Value Head；
Rollout；
KL 约束；
Advantage；
大量显存和训练稳定性问题。

对个人单卡而言，完整 RLHF 通常不是优先路线。

11.2 RLVR

RLVR（Reinforcement Learning with Verifiable Rewards）使用程序、环境或明确规则验证结果。

适合：

数学；
代码；
SQL；
格式；
工具调用；
游戏和模拟环境；
可确定成功与否的工作流。

企业场景中的可验证奖励例子：

JSON Schema 合法：+0.1
选择正确工具：+0.2
参数完整：+0.2
API 执行成功：+0.2
最终状态符合目标：+0.3

奖励不应只看最终文本“像不像”。最好与真实执行结果连接。

11.3 GRPO

GRPO（Group Relative Policy Optimization）对同一 Prompt 生成一组候选输出，使用组内相对奖励计算优势，避免依赖单独训练的大型 Value Model。

简化理解：

同一问题生成 8 个答案
→ 分别评分
→ 计算每个答案相对于组平均值的优势
→ 增强高分路径，抑制低分路径

Hugging Face TRL 已提供 GRPOTrainer。

GRPO 仍然需要：

多次生成 Rollout；
Reward Function；
Reference / KL 控制策略；
较高计算量；
稳定的长度与采样设置。

即使是 1B 模型，单卡 GRPO 也可能比普通 QLoRA SFT 重很多，因为同一问题需要生成多个候选。

11.4 Reward Hacking

当奖励设计不完整时，模型会找到“得高分但不真正解决任务”的捷径。

例子：

奖励 JSON 合法，模型输出空字段的合法 JSON；
奖励答案包含关键词，模型堆砌关键词；
奖励短答案，模型省略必要信息；
奖励工具成功调用，模型反复调用容易成功的工具；
奖励用户点击，模型使用夸张措辞诱导点击。

解决方法：

多维奖励；
负奖励；
随机审计；
对抗测试；
真实业务指标；
限制工具权限；
奖励模型与程序验证组合。

11.5 什么时候不应做 RL

如果问题来自：

标签定义不清；
SFT 数据质量差；
RAG 检索错误；
工具接口不稳定；
Prompt Schema 混乱；
没有可靠 Reward；

此时做 RL 只会放大系统缺陷。

推荐顺序：

先建立可靠基线
→ 完成 SFT
→ 建立可复现评测
→ 收集失败案例
→ 再考虑偏好优化或 RL

12. 继续预训练与领域模型

12.1 继续预训练和 SFT 的区别

继续预训练通常使用原始领域文本，仍以预测下一个 Token 为目标。

SFT 使用任务化样本，例如问题、输入和理想答案。

例如拥有大量维修手册：

继续预训练数据

当环境温度低于某范围时，电池内阻可能上升……

模型学习领域语言、概念共现和文体。

SFT 数据

用户：低温为什么会影响续航？
助手：根据电池工作原理，低温会影响……

模型学习如何回答用户。

二者通常是：

领域继续预训练
→ 领域 SFT
→ 偏好优化或工具训练

而不是互相替代。

12.2 继续预训练适合哪些场景

适合：

有数亿到数十亿 Token 的稳定领域语料；
基础模型对领域术语理解明显不足；
需要领域文本生成、阅读理解或专业表达；
企业有能力处理数据清洗、混合比例和遗忘问题；
目标不仅是回答少量文档问答。

不适合：

只有几百份文档；
知识频繁更新；
需要准确引用；
数据中包含大量重复模板；
没有领域 Benchmark；
只是想让模型输出固定 JSON。

12.3 灾难性遗忘与语料混合

如果只用单一领域文本持续训练，模型可能降低：

通用语言能力；
指令遵循；
多语言能力；
常识；
安全边界。

常见缓解方法：

混入一定比例通用语料；
使用较低学习率；
控制训练步数；
冻结部分参数；
使用 LoRA 做继续预训练实验；
在训练前后进行通用与领域双重评测。

12.4 知识注入不是可靠数据库

即使继续预训练使模型更熟悉领域，也不能保证：

精确记住每条事实；
按最新版本回答；
删除过时知识；
给出原始出处；
遵守文档权限。

因此，领域模型和 RAG 经常组合：

领域模型
负责理解行业语言和推理

RAG
负责提供当前、可引用、权限可控的事实

第三篇　LoRA 与消费级显卡模型工程

13. LoRA 的数学直觉和实际作用

LoRA（Low-Rank Adaptation）是一种参数高效微调方法。Hugging Face PEFT 文档将其描述为：用两个更小的低秩矩阵表示对原权重矩阵的更新，从而显著减少需要训练的参数。

13.1 从完整权重更新到低秩更新

一个线性层原始权重为：

W ∈ R^(d_out × d_in)

完整微调直接更新 W。

LoRA 冻结 W，并学习：

ΔW = B × A

其中：

A ∈ R^(r × d_in)
B ∈ R^(d_out × r)

r 远小于 d_in 和 d_out。

推理时：

y = Wx + scale × BAx

如果一个 4096 × 4096 的矩阵有约 1,678 万参数，使用 r=8 时：

A：8 × 4096
B：4096 × 8
合计：65,536 参数

这只是原矩阵参数量的一小部分。

13.2 为什么低秩更新能够有效

经验上，大模型适应下游任务时需要的有效变化往往集中在较低维子空间中。LoRA 不必重新学习全部语言能力，只需调整部分行为方向。

可以把它理解为：

基础模型保存通用语言和知识能力；
LoRA 学习“这个任务下哪些方向更重要”；
Adapter 是对基础模型行为的差分修改。

LoRA 适合学习：

输出格式；
标签边界；
特定任务映射；
风格；
工具调用；
领域表达；
部分推理习惯。

它不等于可靠地把大量企业事实压缩成一个小文件。

13.3 LoRA 通常插入哪些模块

常见 Transformer 模块：

q_proj
k_proj
v_proj
o_proj
gate_proj
up_proj
down_proj

只训练 q_proj 和 v_proj：

参数少；
显存较低；
适合先跑通。

训练 all-linear 或注意力与 MLP 的多个投影：

容量更大；
可能提升复杂任务效果；
显存、文件和过拟合风险增加。

不同模型的模块名称不同，不能机械复制配置。

13.4 Rank、Alpha 与 Scaling

Rank `r`

代表低秩空间的容量。

r 太小：可能学不会复杂任务；
r 太大：参数增加，可能过拟合；
小型明确任务可从 8 开始；
复杂多任务可测试 16、32；
不能仅凭“越大越好”选择。

Alpha

LoRA 更新通常按 alpha / r 或变体进行缩放。

Alpha 影响更新幅度，但与：

学习率；
Rank；
初始化；
框架实现；
RS-LoRA 等方法；

共同作用。

Dropout

LoRA Dropout 用于正则化。数据少或容易过拟合时可使用 0.05～0.1；数据充分时也可能设为 0。

13.5 LoRA 不是独立基础模型

Adapter 只保存差分参数。运行时通常需要：

Base Model
+ 对应的 LoRA Adapter
+ 正确 Tokenizer
+ 正确 Chat Template

如果 Base Model 版本不匹配，可能：

无法加载；
输出异常；
模块名称不匹配；
能加载但效果明显下降。

14. QLoRA、量化和显存控制

QLoRA 的核心是：

4-bit 量化的冻结基础模型
+ 可训练 LoRA Adapter
+ 较高精度的计算

Hugging Face Transformers 的 bitsandbytes 文档将 QLoRA 描述为：将基础模型压缩到 4-bit，同时插入一小组可训练的 LoRA 权重。

14.1 为什么量化后仍能训练 LoRA

基础模型权重以 4-bit 存储，前向计算时按需要反量化到 BF16 或 FP16 计算。梯度不更新量化基础权重，只更新 LoRA 参数。

典型配置：

BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
)

NF4

NF4 是面向近似正态分布权重设计的 4-bit 数据类型，常用于 QLoRA。

Double Quantization

进一步量化量化常数，节省额外内存。

Compute Dtype

存储可以是 4-bit，计算通常使用 BF16 或 FP16。新显卡若支持 BF16，一般优先使用 BF16。

14.2 量化不是无损压缩

4-bit 量化可能影响：

输出精度；
数学能力；
少数语言；
极端权重；
微调后的上限；
某些部署内核兼容性。

因此：

QLoRA 适合低成本适配；
不代表所有任务等同 BF16 全参数微调；
最终效果必须实测。

14.3 Gradient Checkpointing

正常训练会保存中间激活用于反向传播。Gradient Checkpointing 只保存部分激活，反向时重新计算，以计算换显存。

效果：

降低激活显存；
增加训练时间；
对长序列非常重要。

14.4 Gradient Accumulation

当显存只能容纳 batch size 1 时，可以累积多个微批次再更新参数：

micro batch size = 1
gradient accumulation = 16
effective batch size ≈ 16

它不显著降低单个样本的激活显存，但可以增大有效 batch。

14.5 Sequence Length 对显存的影响

训练长度往往比 Rank 更容易引发 OOM。

例如从 1024 增加到 4096，并不是简单增加一点内存。注意力和激活成本会显著上升，具体取决于模型架构和 Flash Attention。

处理顺序通常是：

统计数据 Token 长度；
删除不必要的长系统提示；
对极长样本单独处理；
从 512 或 1024 跑通；
再增加到 2048；
不要为极少数长样本让全体训练都使用超长窗口。

14.6 Packing

Packing 将多个短样本拼入一个序列，减少 Padding，提升 GPU 利用率。

适合：

大量短样本；
SFT；
样本边界可正确屏蔽。

风险：

模板或 EOS 处理错误导致样本串联；
多轮样本边界不清；
对某些训练框架配置不当。

15. LoRA 的主要用法

15.1 任务 LoRA

让模型掌握明确任务：

评论分类；
信息抽取；
Text-to-SQL；
文档摘要；
结构化输出；
查询改写；
工具路由。

这种 LoRA 最容易评测，也是消费级显卡最值得做的实验。

15.2 领域 LoRA

让模型适应领域语言和判断方式：

汽车；
法律；
金融；
医疗；
工业设备；
电商运营。

领域 LoRA 应训练“专业任务模式”，而不是简单堆积领域文档。

15.3 风格 LoRA

调整：

品牌语气；
报告风格；
社交媒体文案；
技术写作；
特定人物或团队的表达习惯。

风险是模型可能只学会表面措辞，内容质量没有提升。风格模型应同时使用事实和任务评测。

15.4 工具调用 LoRA

训练模型：

何时调用工具；
选择哪个工具；
参数如何生成；
工具结果如何解释；
什么情况下不应调用。

工具调用训练样本需要包含：

无需工具的问题；
单工具；
多工具；
参数缺失；
工具失败；
权限不足；
结果为空；
需要用户确认的高风险动作。

15.5 安全和合规 LoRA

可以训练：

敏感信息脱敏；
权限边界；
合规回答格式；
高风险请求升级；
不确定时拒绝下结论。

但安全不能只依赖 LoRA。还需要：

输入输出过滤；
规则；
权限；
日志；
人工审批；
沙箱。

15.6 语言或翻译 LoRA

用于强化特定语言对或行业翻译：

中英；
中泰；
中日；
专业术语一致性。

如果基础模型 Tokenizer 对目标语言覆盖很差，LoRA 可能不足，需要更合适的多语言底座或继续预训练。

15.7 推理 LoRA

使用 CoT 数据让小模型学习推理格式和方法。

注意：

模型可能变得啰嗦；
需要更长上下文；
简单任务延迟上升；
业务任务不一定受益；
要比较“最终答案训练”和“推理轨迹训练”。

16. 多 LoRA、动态加载与模型路由

16.1 一个 Base Model 对多个 Adapter

Base Model
├── 评论分析 LoRA
├── 销售建议 LoRA
├── 客服 LoRA
├── Text-to-SQL LoRA
└── 品牌风格 LoRA

优点：

基础权重只存一份；
Adapter 文件小；
迭代快；
不同任务独立版本；
可按请求动态选择。

vLLM 和 SGLang 均提供在基础模型上加载或服务 LoRA Adapter 的能力。SGLang 文档还说明可高效支持多个 LoRA Adapter。

16.2 多 LoRA 不等于任意叠加

同时加载多个 Adapter 可能冲突：

风格 LoRA 覆盖任务格式；
行业 LoRA 降低工具调用；
多个 Adapter 改写相同层；
不同数据分布相互干扰。

更稳妥的方式通常是：

路由

每次请求只选择一个最匹配 Adapter。

合并后重新评测

将需要组合的能力通过联合数据再训练。

Adapter Fusion / Weighted Merge

对多个 Adapter 进行权重组合，但必须系统评测。

16.3 动态 LoRA 服务的企业价值

多租户场景：

同一个基础模型
+ 客户 A Adapter
+ 客户 B Adapter
+ 客户 C Adapter

或者：

同一个基础模型
+ 任务 1 Adapter
+ 任务 2 Adapter

这能减少显存和部署实例，但要考虑：

Adapter 加载延迟；
并发；
Base 兼容；
版本；
权限隔离；
每个 Adapter 的性能监控；
不同 Adapter 的 Prompt 模板。

16.4 Model Routing 不只路由 LoRA

实际系统可能根据任务路由：

简单分类 → 1B 本地模型
复杂分析 → 7B / 14B 模型
图像理解 → VLM
高风险事实 → RAG + 大模型
代码执行 → 代码模型 + 沙箱

路由依据可以包括：

任务类型；
复杂度；
延迟预算；
成本预算；
数据敏感度；
模型置信度；
是否需要多模态；
是否需要外部工具。

17. Hugging Face 模型文件识别

看到 Hugging Face 仓库时，不应只看文件数量。需要结合：

Repository 类型；
文件名；
config.json；
adapter_config.json；
Model Card；
Base Model 元数据；
文件大小；
架构；
量化格式。

17.1 完整 Transformers 模型

常见文件：

config.json
generation_config.json
model.safetensors
或 model-00001-of-000xx.safetensors
model.safetensors.index.json
tokenizer.json
tokenizer_config.json
special_tokens_map.json

如果模型较小，权重可能只有一个 model.safetensors。一个文件不代表“只是 LoRA”。

17.2 PEFT / LoRA Adapter

常见文件：

adapter_config.json
adapter_model.safetensors
README.md

adapter_config.json 通常包含：

base_model_name_or_path
r
lora_alpha
target_modules
peft_type
task_type

Adapter 文件一般比完整模型小很多。

17.3 GGUF 模型

常见文件：

model-Q4_K_M.gguf
model-Q5_K_M.gguf
model-F16.gguf

GGUF 通常用于：

llama.cpp；
Ollama；
LM Studio；
CPU / GPU 混合推理。

GGUF 是完整推理模型格式，可能已经包含合并后的 LoRA 效果。它不是 PEFT Adapter。

17.4 GPTQ / AWQ / EXL2 等量化模型

这类仓库通常包含完整量化权重和量化配置。

用途：

GPU 推理；
减少显存；
提高部分场景吞吐。

必须确认推理框架和 GPU 是否支持对应内核。

17.5 “Fine-tuned Model” 不一定使用 LoRA

作者可能使用：

全参数 SFT；
LoRA 后合并；
QLoRA 后合并；
DPO；
GRPO；
继续预训练；
模型融合；
权重插值；
蒸馏；
量化。

最终发布的仍可能是普通完整权重。

18. Adapter、合并模型和量化模型

18.1 保留 Adapter 发布

优点：

文件小；
便于版本管理；
可以切换；
只需发布差分；
适合内部技能库。

缺点：

用户必须同时获取正确 Base；
部署框架需支持 LoRA；
Base 版本必须一致；
多 Adapter 服务更复杂。

18.2 Merge 后发布

合并计算：

W_merged = W_base + ΔW_lora

优点：

下载即用；
推理框架兼容性更好；
可继续量化为 GGUF / AWQ 等格式。

缺点：

文件变大；
不方便切换 Adapter；
难以从模型中分离原 LoRA；
多任务需要多个完整副本。

18.3 合并时的精度问题

不建议直接把 4-bit 量化训练中的基础权重当作普通高精度权重合并。常见做法：

加载原始 BF16 / FP16 Base；
加载训练得到的 Adapter；
执行 merge；
保存高精度合并模型；
再根据部署需求进行量化。

18.4 Adapter 与量化的顺序

训练：

高精度 Base
→ 4-bit 加载
→ QLoRA 训练
→ Adapter

部署：

方案 A：量化 Base + 动态 Adapter
方案 B：高精度 Base + Adapter Merge + 再量化

选择取决于：

框架支持；
是否多 Adapter；
精度要求；
显存；
发布方式。

19. LoRA 数据、参数和常见失败原因

19.1 推荐的起步参数

针对 1B～2B 小模型和明确任务，可从以下范围开始：

finetuning_type: lora
quantization_bit: 4
lora_rank: 8
lora_alpha: 16
lora_dropout: 0.05
learning_rate: 0.0002
num_train_epochs: 2
per_device_train_batch_size: 1
gradient_accumulation_steps: 8
cutoff_len: 1024
gradient_checkpointing: true

这不是最佳参数，只是低风险起点。

19.2 学习率过高

表现：

Loss 快速下降后异常；
输出重复；
语言能力退化；
格式极端固化；
未见过的输入泛化差。

处理：

从 2e-4 降到 1e-4 或 5e-5；
减少 Epoch；
检查数据重复；
增加验证集。

19.3 过拟合

表现：

训练集完美；
测试集差；
模型复述训练句式；
输入稍变就失败。

处理：

增加数据多样性；
使用更严格的切分；
降低 Rank 或 Epoch；
使用 Dropout；
早停；
删除近重复样本。

19.4 模型没学到

可能原因：

LoRA 只插入过少模块；
Rank 太低；
学习率太低；
训练步数不足；
数据格式未被正确读取；
Completion 被错误 Mask；
Chat Template 不匹配；
任务超过模型容量；
标签本身不一致。

19.5 训练 Loss 下降，但输出仍不合法

原因可能是：

JSON 字符串在数据中本来就不一致；
推理时开启高温度采样；
没有使用约束解码；
Prompt 与训练模板不同；
EOS / special token 错误；
样本中混有 Markdown 代码块；
字段顺序和类型不统一。

解决：

训练数据统一 Schema；
推理 do_sample=False；
使用 JSON Schema / Grammar 约束；
训练与推理使用同一 Chat Template；
增加格式困难样本；
服务端做验证和重试。

19.6 “训练后更笨了”

需要检查：

是否使用错误 Base；
是否把通用任务替换成单一狭窄任务；
是否长时间训练；
是否数据质量差；
是否模型本来就是 Instruct，训练模板却按 Base 处理；
是否将推理模型的思考格式破坏；
是否在 Merge 或量化时产生问题。

19.7 LoRA 评测必须包含 Base 基线

至少比较：

Base + 普通 Prompt
Base + 优化 Prompt / Few-shot
Base + LoRA
Base + LoRA + 约束解码

如果优化 Prompt 已经达到同等效果，LoRA 未必值得增加维护成本。

第四篇　企业 RAG 工程

20. RAG 的本质：参数化记忆与外部记忆

RAG（Retrieval-Augmented Generation，检索增强生成）把模型内部参数与外部知识源结合。

原始 RAG 论文将其描述为：

参数化记忆：预训练语言模型；
非参数化记忆：可检索的外部文档索引。

现代企业 RAG 通常是：

用户问题
→ 查询理解
→ 检索外部知识
→ 重排序和上下文构造
→ LLM 基于证据生成
→ 引用、验证和审计

20.1 模型并没有“调用向量库意识”

RAG 是应用系统完成的，不是模型天然具备的能力。通常由程序：

接收问题；
生成查询或 Embedding；
调用检索系统；
把结果放入 Prompt；
调用 LLM；
验证回答。

如果使用 Agentic RAG，模型可以参与“是否检索、检索什么、是否再次检索”的决策，但检索仍由外部工具执行。

20.2 RAG 不等于向量数据库

完整 RAG 包含：

数据采集；
文档解析；
清洗；
切片；
Metadata；
Embedding；
索引；
Query Rewrite；
Hybrid Retrieval；
Reranking；
Context Compression；
Generation；
Citation；
Evaluation；
权限与更新。

只把 PDF 切成段落放入向量库，属于最基础的 Naive RAG。

20.3 RAG 与长上下文

直接把全部文档塞入长上下文的优点：

实现简单；
不需要复杂检索；
对少量短文档有效。

问题：

成本随 Token 增长；
无关内容干扰；
内容中间部分可能被忽略；
权限控制困难；
大文档仍会超限；
更新时要重复传输；
无法方便进行多用户知识隔离。

RAG 的核心价值不仅是突破上下文长度，而是从大规模知识中选择当前问题最需要的证据。

21. 为什么企业知识通常不应训练进模型

21.1 知识更新

企业知识具有时间属性：

当前价格；
当前政策；
最新版本；
地区差异；
库存；
组织人员；
客户状态。

如果知识写进模型参数，更新流程可能是：

修改数据
→ 重新训练
→ 重新评估
→ 重新发布
→ 灰度切换

RAG 则可以通过更新索引立即生效。

21.2 可追溯性

企业回答往往需要：

来源文档；
页码；
条款；
发布时间；
生效时间；
文档所有者。

参数中的知识无法可靠说明来源。模型即使生成一个看似合理的引用，也可能是幻觉。

21.3 权限

不同用户可访问不同内容：

总部政策；
区域资料；
经销商资料；
员工数据；
客户信息；
合同。

RAG 可以在检索阶段按 ACL 过滤。训练进共享模型后，很难保证参数不会泄露受限信息。

21.4 删除与合规

企业可能需要删除：

用户个人数据；
过期合同；
错误文档；
撤销授权的数据。

从向量库和原文存储删除相对可控，从模型参数中精确删除单条知识非常困难。

21.5 何时可以让模型“内化”部分知识

可以内化：

稳定术语；
通用行业概念；
固定分类规则；
专业表达；
工作方法；
不频繁变化的基础原理。

不建议内化：

最新价格；
用户档案；
订单状态；
每月活动；
当前政策；
需要逐字引用的条款。

22. 企业 RAG 的完整数据链路

一个可维护的 RAG 系统应把离线索引链路与在线查询链路分开。

22.1 离线索引链路

数据源
→ 采集与同步
→ 文档解析
→ 清洗和去重
→ 结构识别
→ Chunk
→ Metadata
→ Embedding
→ 向量与关键词索引
→ 版本和权限登记

数据源可能包括：

PDF；
Word；
PPT；
Excel；
HTML；
Wiki；
数据库；
工单；
FAQ；
API；
对象存储；
邮件；
图片扫描件。

22.2 在线查询链路

用户问题
→ 身份与权限
→ 意图识别
→ 查询改写或分解
→ 多路召回
→ 融合
→ Reranker
→ 上下文组织
→ LLM 生成
→ 引用校验
→ 日志与反馈

22.3 数据同步策略

需要定义：

全量初始化；
增量更新；
删除同步；
版本切换；
失败重试；
重建索引；
Embedding 模型升级；
文档状态；
索引一致性。

例如文档更新后，不应只新增新版本而保留旧版本为同等有效。应通过 Metadata 标记：

{
  "document_id": "policy-2026-07",
  "version": "3.0",
  "valid_from": "2026-07-01",
  "valid_to": null,
  "status": "active",
  "supersedes": "policy-2026-04"
}

23. 文档解析、Chunk 和上下文组织

23.1 解析质量决定上限

如果 PDF 解析后出现：

标题丢失；
表格错位；
页眉页脚混入正文；
多栏顺序错误；
图片说明丢失；
数字与单位分开；
OCR 错误；

后续再好的 Embedding 和模型也无法完全补救。

因此需要针对文档类型选择解析策略：

文本型 PDF

优先提取文本层和布局。

扫描 PDF

使用 OCR，并保留页码和坐标；对关键字段进行质量检查。

PPT

保留：

页标题；
文本框层级；
图表说明；
页码；
演讲备注；
图片描述。

Excel

不要简单把整张表拼成一段文本。可以：

按行生成语义记录；
保留表头；
将数值字段存为结构化 Metadata；
对复杂表格使用 SQL 或 DataFrame 工具。

23.2 Chunk 的目标

Chunk 不是“把文字平均切成 500 字”。好的 Chunk 应满足：

语义完整；
包含回答问题所需证据；
不过长；
保留上下级标题；
可追溯到原文；
适合 Embedding；
适合最终上下文。

23.3 常见 Chunk 策略

固定长度切片

例如每 500 Token，重叠 50 Token。

优点：

简单；
稳定；
易实现。

缺点：

可能切断表格、条款和句子；
不理解文档结构。

递归字符切片

按：

章节
→ 段落
→ 句子
→ 字符

逐级寻找合适边界。

基于 Markdown / HTML 标题

按标题层级切分，并将父标题附加到 Chunk。

语义切片

根据句子 Embedding 的语义变化点切分。

优点：

语义更自然。

缺点：

成本高；
参数敏感；
在结构化政策文档中未必优于标题切分。

表格切片

按：

表名；
表头；
行；
关键字段；

构造可检索记录。

对话和工单切片

按一个完整 Case 或对话线程，而不是固定长度。

23.4 Parent-Child Retrieval

将文档保存为两种粒度：

Child Chunk：较短，适合精准召回；
Parent Chunk：较长，提供完整上下文。

流程：

用 Child 检索
→ 找到最相关片段
→ 返回其 Parent 给 LLM

这解决了：

短 Chunk 好检索但上下文不足；
长 Chunk 上下文完整但召回不准。

23.5 Overlap 不应盲目增加

Overlap 可避免边界信息丢失，但过高会：

重复索引；
召回大量近重复；
浪费上下文；
增加存储；
让 Reranker 得到同一内容的多个版本。

更好的方式是使用标题、父子关系和句子边界，而不是无限增加重叠。

23.6 Context Assembly

最终给 LLM 的上下文需要组织，而不是简单拼接 Top-K。

可以按：

相关度；
文档时间；
权威等级；
章节顺序；
相同文档聚合；
正反证据；
问题子任务；

进行排序。

上下文模板示例：

[来源 1]
文档：售后政策
版本：3.0
生效日期：2026-07-01
页码：12
内容：……

[来源 2]
文档：产品手册
版本：2026款
页码：38
内容：……

24. Embedding 模型与多语言检索

24.1 Embedding 做什么

Embedding 模型将文本映射为向量：

text → [0.12, -0.31, ...]

语义相似文本的向量距离更近。

常用相似度：

Cosine Similarity；
Dot Product；
Euclidean Distance。

必须根据模型文档使用正确的归一化和距离方式。

24.2 Query 与 Document 前缀

部分模型要求为 Query 和 Document 使用不同前缀，例如：

query: 用户问题
passage: 文档内容

如果忽略，效果可能下降。

24.3 多语言 Embedding

多语言企业场景要测试：

同语言检索：中文查中文；
跨语言检索：泰文问题查中文文档；
混合文档；
型号、缩写和数字；
音译；
专业术语。

可选策略：

多语言统一向量空间

使用多语言 Embedding，直接跨语言检索。

Query Translation

将问题翻译成知识库主语言再检索。

多查询检索

同时使用原文和翻译后的查询。

Cross-lingual RAG

检索后将文档统一翻译到生成语言，减少模型处理多语言证据的不一致。

多语言 RAG 论文和实践表明，跨语言检索会受到覆盖度和翻译一致性影响，因此必须使用实际语料评测。

24.4 领域 Embedding 微调

如果通用 Embedding 不能区分行业概念，可以训练或微调检索模型。

训练数据形式：

Positive Pair

Query：冬季续航下降原因
Positive：低温导致电池活性下降并增加热管理能耗……

Hard Negative

Negative：冬季轮胎胎压维护说明……

Hard Negative 与 Query 表面相关，但不是正确证据，对提升检索边界很重要。

24.5 Embedding 升级的代价

更换 Embedding 模型通常需要：

全量重新计算文档向量；
重建索引；
重新评测；
处理新旧索引切换；
验证维度和距离设置。

因此应将 Embedding 模型版本写入索引元数据。

25. 向量检索、BM25、Hybrid Search 与 RRF

25.1 向量搜索的优势和弱点

优势：

理解语义改写；
处理同义表达；
适合自然语言问题。

弱点：

型号和编号可能不准确；
精确词匹配弱；
数字、日期、代码和专有名词容易丢失；
相似主题文档可能超过真正答案。

例如查询：

EV5 2026 Premium 配置

纯语义检索可能返回“新能源车型整体介绍”，而不是准确型号配置。

25.2 BM25

BM25 是经典词法检索算法，擅长：

精确关键词；
型号；
产品名；
人名；
法规编号；
错误码；
日期和术语。

弱点：

不理解同义词；
对自然语言改写不敏感；
跨语言能力弱。

25.3 Hybrid Search

Hybrid Search 将词法检索与语义检索结合。

Query
├── BM25
└── Vector Search
      ↓
结果融合

Elastic 官方资料将 Hybrid Search 描述为将词法 / BM25 与语义搜索合并为一个排名列表，以同时获得精确词匹配和语义理解。

25.4 RRF

RRF（Reciprocal Rank Fusion）根据多个列表中的排名位置进行融合，而不是直接合并不可比较的原始分数。

简化形式：

score(d) = Σ 1 / (k + rank_i(d))

优点：

不要求 BM25 分数与向量分数在同一尺度；
参数少；
是 Hybrid Search 的良好起点。

缺点：

忽略原始分数强弱；
不能自动理解不同召回器的质量差异；
仍需调节候选数量和最终 Top-K。

25.5 多路召回

除 BM25 和 Dense Vector 外，还可以加入：

Sparse Embedding；
标题索引；
Metadata 过滤；
知识图谱；
SQL；
FAQ 精确匹配；
历史问题缓存。

企业检索常用：

精确 ID 查询
+ 关键词搜索
+ 语义搜索
+ 权限和版本过滤

26. Reranker 与两阶段检索

Sentence Transformers 官方文档推荐 Retrieve & Re-Rank 模式：

Bi-Encoder 快速召回；
Cross-Encoder 对 Top 候选进行重排序。

26.1 为什么 Reranker 更准确

Embedding 检索分别编码 Query 和 Document。

Reranker 同时读取：

[Query, Document]

因此能进行更细粒度的 Token 交互，判断：

是否直接回答问题；
是否只是主题相似；
是否包含所需限定条件；
是否匹配具体年份、地区或产品。

26.2 典型参数

初始召回：Top 50～200
Reranker：选择 Top 5～20
最终上下文：根据 Token 预算组织

不是固定值。文档越短、问题越复杂，候选池可能需要更大。

26.3 领域 Reranker

通用 Reranker 可能不理解内部术语。可以使用企业检索日志训练：

Query
Relevant Document
Hard Negative Document

评测指标：

MRR；
Recall@K；
NDCG@K；
Hit Rate；
真实问题答案覆盖率。

26.4 Reranker 不能修复召回缺失

如果正确文档没有进入候选集，Reranker 无法凭空找回。因此要分别评估：

Retriever Recall；
Reranker Precision；
最终回答质量。

27. Metadata、权限和知识时效

27.1 Metadata 的作用

Metadata 不只是展示信息，而是检索控制条件。

常见字段：

{
  "document_id": "manual-EV5-2026",
  "title": "2026款产品手册",
  "document_type": "product_manual",
  "product": "EV5",
  "model_year": 2026,
  "region": "CN",
  "language": "zh",
  "department": "service",
  "version": "2.1",
  "valid_from": "2026-06-01",
  "valid_to": null,
  "status": "active",
  "security_level": "internal",
  "page": 38
}

27.2 权限过滤必须在检索阶段完成

错误做法：

先检索所有文档
→ 再让 LLM 不要泄露

正确做法：

身份和角色
→ 生成权限过滤条件
→ 只召回可访问文档

模型提示不是权限系统。

27.3 时间有效性

同一主题可能存在多个版本。检索应考虑：

当前日期；
文档生效日期；
废止状态；
用户问题指定的历史时间；
地区；
产品版本。

如果用户问“2025 年的政策”，不能只返回当前版本。

27.4 权威级别

知识来源可分：

正式政策；
产品手册；
已审核 FAQ；
培训材料；
内部讨论；
用户生成内容。

发生冲突时，检索和生成应优先使用高权威来源，并明确冲突。

28. GraphRAG、Agentic RAG 与查询分解

28.1 GraphRAG

Microsoft GraphRAG 的标准流程包括：

从原始文本提取实体和关系；
构建知识图谱；
形成社区层级；
为社区生成摘要；
基于图结构和文本进行查询。

它适合：

需要跨多文档关系；
“谁与谁有关”；
事件网络；
组织和人物关系；
全局主题总结；
多跳问题。

不一定适合：

简单 FAQ；
精确条款查询；
数据量很小；
更新极频繁；
对抽取错误极敏感的场景。

GraphRAG 索引成本通常高于普通向量 RAG，因为需要 LLM 提取实体、关系和摘要。

28.2 Local Search 与 Global Search

GraphRAG 常见两类查询：

Local Search

围绕特定实体，结合图关系和原始文本。

Global Search

使用社区摘要回答跨整个语料的宏观问题。

例如：

Local：某客户与哪些项目、联系人和投诉有关？
Global：过去半年客户投诉的主要结构性主题是什么？

28.3 Agentic RAG

Agentic RAG 让模型参与检索过程：

判断是否需要检索
→ 生成查询
→ 查看结果
→ 判断是否充分
→ 改写或分解查询
→ 再次检索
→ 回答

优点：

适合复杂问题；
能进行多跳检索；
可切换搜索、SQL 和知识图谱。

缺点：

延迟高；
成本高；
路径不稳定；
容易重复检索；
需要停止条件；
更难评估。

28.4 查询分解

复杂问题：

对比两个产品过去三年的价格政策、用户投诉和售后变化，并说明差异原因。

可以分解为：

产品 A 三年价格政策；
产品 B 三年价格政策；
产品 A 投诉；
产品 B 投诉；
双方售后政策；
时间线对齐；
综合原因。

查询分解可以提升多跳问题的召回覆盖，但要避免子问题失去原问题约束。

28.5 HyDE 与查询扩展

HyDE 先生成一个假设答案或理想文档，再对其进行 Embedding 检索。

适合：

用户问题极短；
查询与文档措辞差异大。

风险：

假设文本包含错误方向；
导致检索偏移。

也可以使用更保守的多查询改写：

原问题
+ 关键词版
+ 术语扩展版
+ 产品型号版

29. RAG 常见失败原因与评估

29.1 常见失败原因

文档解析失败

正确答案根本没有进入索引。

Chunk 不完整

答案跨两个片段，但只召回其中一个。

检索召回错误

只使用向量搜索，型号、年份或条款号未命中。

版本错误

召回旧政策。

权限错误

召回用户无权访问的文档。

Reranker 选择错误

主题相似文档压过直接证据。

上下文过多

模型被噪声干扰。

Prompt 不要求基于证据

模型用参数知识补全，形成幻觉。

模型引用错误

答案来自来源 1，却错误标记来源 2。

29.2 RAG 应分层评估

解析评估

文本完整率；
表格还原率；
页码正确率；
OCR 错误率。

检索评估

Recall@K；
MRR；
NDCG；
正确证据是否进入候选。

重排序评估

正确证据是否进入最终 Top-K；
Hard Negative 排名。

生成评估

Faithfulness；
Answer Relevance；
Completeness；
Citation Correctness；
不确定时是否拒答。

业务评估

问题解决率；
转人工率；
平均处理时间；
用户采纳率；
错误成本；
合规事件。

29.3 建立黄金问答集

黄金集应包含：

普通问题；
型号和编号；
当前政策；
历史版本；
多文档问题；
无答案问题；
权限问题；
冲突文档；
多语言问题；
表格问题；
需要 SQL 的问题。

每个问题应标记：

标准答案；
必需证据；
可接受来源；
不可接受来源；
权限；
时间条件。

29.4 无答案检测

RAG 不能默认“总能回答”。需要让系统在证据不足时输出：

当前知识库中没有足够证据回答。

可结合：

检索分数阈值；
Reranker 分数；
证据覆盖；
LLM 自检；
规则；
人工升级。

但模型的“置信度数字”通常未经校准，不应单独作为依据。

第五篇　Agent 与工具执行体系

30. Agent 与 Chatbot 的区别

一个普通 Chatbot 的主要循环是：

用户输入
→ 模型生成回答

一个 Agent 的典型循环是：

接收目标
→ 判断当前状态
→ 选择下一步动作
→ 调用工具或工作流
→ 观察执行结果
→ 更新状态
→ 决定继续、重试、询问或结束

Agent 的价值不在于“回答更像人”，而在于：

能够访问外部信息；
能够执行系统动作；
能够根据中间结果调整下一步；
能够跨多个步骤完成目标；
能够保留任务状态；
能够进入审批和审计流程。

30.1 Chatbot 适合什么

FAQ；
文本改写；
简单问答；
文档摘要；
不涉及外部系统的单轮任务。

30.2 Workflow 适合什么

步骤已知；
规则明确；
高可靠；
每一步都可审计；
不需要模型自由决定所有路径。

例如：

上传合同
→ OCR
→ 字段抽取
→ 规则校验
→ 风险分类
→ 人工审批

这里模型只是流程中的一个节点，不需要“自主 Agent”。

30.3 Agent 适合什么

路径取决于中间结果；
工具很多；
问题需要分解；
用户目标不够结构化；
需要在搜索、数据库、代码执行之间切换。

企业系统中通常应优先采用：

确定性 Workflow 为骨架，Agent 决策用于必要的动态节点。

完全自主 Agent 的可控性、成本和安全风险更高。

31. Agent 的核心组件

31.1 Model / Reasoning Core

负责：

理解目标；
生成计划；
选择工具；
解释工具结果；
判断是否结束。

并非所有节点都要调用同一个大模型。可以使用：

小模型路由；
大模型复杂规划；
规则完成确定性判断；
专用模型做分类；
Reranker 做检索排序。

31.2 Tools

工具是 Agent 与外部世界的接口，例如：

Web Search；
数据库查询；
CRM；
工单系统；
文件读取；
计算器；
代码执行；
消息发送；
日历；
审批系统。

工具必须有清晰的：

名称；
描述；
输入 Schema；
输出 Schema；
权限；
超时；
错误码；
幂等性；
副作用等级。

31.3 State

State 保存任务当前状态：

{
  "goal": "分析客户并创建跟进任务",
  "customer_id": "C1024",
  "retrieved_profile": true,
  "intent_stage": "A4",
  "policy_version": "2026-07",
  "approval_required": false,
  "completed_steps": [
    "query_customer",
    "retrieve_policy"
  ]
}

如果没有显式 State，模型只能从不断增长的对话文本中猜测任务状态，稳定性会下降。

31.4 Memory

Memory 用于保留跨步骤或跨会话的信息，后文单独讨论。

31.5 Planner

Planner 把目标拆成任务。例如：

目标：分析某区域销量下降原因并提出行动方案

计划：
查询近 12 个月销量
对比目标和同比
查询渠道、库存和活动
查找异常月份
形成假设
验证假设
输出建议和证据

31.6 Executor

Executor 根据计划执行工具，并将结果写回 State。

31.7 Guardrails

Guardrails 包括：

权限；
输入输出验证；
敏感信息；
危险工具限制；
预算；
最大步数；
超时；
人工确认；
回滚。

31.8 Observability

需要记录：

Prompt；
模型；
Adapter；
Tool Call；
参数；
返回；
Token；
延迟；
错误；
版本；
用户反馈；
最终状态。

没有可观测性，Agent 失败后很难定位是：

模型选择错误；
Prompt 错误；
工具错误；
RAG 错误；
权限错误；
工作流错误。

32. ReAct、Plan-and-Execute 与 Workflow Agent

32.1 ReAct

ReAct 将推理与行动交替：

Reason
→ Act
→ Observe
→ Reason
→ Act

示例：

目标：查询某客户当前订单并给出交付说明

Reason：需要先获取客户订单。
Act：query_orders(customer_id)
Observe：返回两个订单。

Reason：需要确认用户询问的是哪一个订单。
Act：向用户询问订单号。

优点：

灵活；
能根据结果调整；
适合探索型任务。

缺点：

步数不可预测；
可能循环；
Token 成本高；
需要限制；
日志中可能包含大量无用推理文本。

32.2 Plan-and-Execute

先制定计划，再逐步执行。

Planner
→ Plan
→ Executor
→ Replan（必要时）

优点：

结构清晰；
便于展示进度；
适合长任务；
可在执行前审查计划。

缺点：

初始计划可能基于不充分信息；
计划过细会增加开销；
环境变化时需要重规划。

32.3 Workflow Agent

Workflow Agent 使用预定义状态机或有向图：

意图分类
├── 知识问答 → RAG
├── 订单查询 → 订单工具
├── 投诉 → 工单流程
└── 高风险 → 人工

模型在有限节点内决策，可靠性通常高于完全自由 Agent。

32.4 Router Agent

Router 只负责选择：

模型；
Adapter；
工具；
工作流；
知识库。

路由任务适合小模型，因为输出空间有限，并可用准确率评测。

32.5 Reflection

Reflection 是让模型或独立评审器检查结果。

检查问题：

是否完成目标；
是否遗漏步骤；
是否使用证据；
是否存在格式错误；
是否需要重试；
是否应转人工。

风险：

同一个模型可能无法发现自己的错误；
反复反思增加成本；
无停止条件会循环。

更可靠的方案是：

程序校验
+ 独立 Judge
+ 人工抽检

33. Tool Calling 与工具 Schema

33.1 Tool Calling 的本质

模型不是直接执行函数，而是生成结构化调用意图：

{
  "name": "query_customer",
  "arguments": {
    "customer_id": "C1024"
  }
}

应用程序验证参数并调用真实工具。

33.2 好工具的设计原则

单一职责

不应设计一个万能工具：

do_everything(action, payload)

它难以理解、授权和评估。

更好：

query_customer
query_orders
create_followup_task
retrieve_policy

参数明确

避免：

{"query": "查一下客户"}

更好：

{
  "customer_id": "C1024",
  "fields": ["purchase_history", "latest_activity"]
}

输出结构稳定

{
  "success": true,
  "data": {},
  "error_code": null,
  "message": null
}

错误可处理

区分：

参数错误；
未找到；
权限不足；
超时；
服务异常；
需要用户确认。

33.3 工具描述的重要性

模型通过工具名和描述选择工具。描述应明确：

工具做什么；
不做什么；
何时使用；
需要哪些前置条件；
是否有副作用；
是否需要确认。

错误描述会导致工具路由失败，即使模型本身很强。

33.4 幂等性

有副作用的动作必须考虑重复调用：

创建任务；
发送消息；
下单；
修改数据；
删除记录。

可以使用：

idempotency key；
状态检查；
两阶段提交；
用户确认；
操作去重。

33.5 高风险操作

高风险工具应：

模型生成拟执行动作；
程序验证；
展示给用户或审批人；
获得确认；
执行；
记录审计日志。

不要让自然语言模型直接拥有无限制写权限。

33.6 工具调用训练数据

训练工具调用模型时，除了正确案例，还应包含：

不需要工具；
多个工具候选；
缺参数；
参数格式错误；
需要先查询再执行；
工具失败；
空结果；
重试；
用户取消；
权限拒绝；
高风险确认。

34. Memory：短期、长期和业务状态

“Memory”在 Agent 系统中经常被过度使用。需要区分多类记忆。

34.1 Working Memory

当前任务需要的临时信息：

计划；
工具结果；
待处理步骤；
用户补充；
当前中间结论。

任务结束后可归档或删除。

34.2 Conversation Memory

保存当前或历史对话。

不能简单把全部历史永远塞入上下文。需要：

摘要；
最近窗口；
重要事实抽取；
主题分段；
过期策略。

34.3 Semantic Memory

保存稳定事实：

用户偏好接收中文报告
用户负责某区域业务
某客户偏好周五下午沟通

应只保存有长期价值且符合隐私授权的信息。

34.4 Episodic Memory

记录过去事件：

2026-07-10：用户审核并接受了某方案
2026-07-12：某工具调用失败，改为人工处理

可用于：

个性化；
避免重复；
复盘；
相似案例检索。

34.5 Procedural Memory

保存“怎么做”的流程和策略，例如：

投诉处理 SOP；
报告生成步骤；
工具选择规则。

这通常更适合：

工作流；
Skill；
Prompt；
SFT；
工具说明；

而不是随意存入用户长期记忆。

34.6 Memory 写入策略

写入前判断：

是否长期有效；
是否经过用户授权；
是否敏感；
是否已有；
是否可验证；
何时过期；
谁能访问。

错误记忆会导致未来 Agent 持续产生错误判断，因此 Memory 也需要更正和删除能力。

35. MCP：AI 应用连接外部系统的标准

MCP（Model Context Protocol）是连接 AI 应用与外部系统的开放标准。官方规范将 Server 能力主要分为：

Resources：上下文和数据；
Prompts：模板化消息和工作流；
Tools：模型可执行的函数。

35.1 MCP 的价值

传统集成：

每个 AI 应用
×
每个数据源或工具

都需要定制开发。

MCP 试图标准化：

AI Client
↔ MCP Server
↔ 数据、工具和工作流

类似统一接口，而不是某一个具体 Agent 框架。

35.2 MCP 的基本角色

Host

承载 AI 应用，例如桌面助手、IDE 或 Agent 平台。

Client

Host 中连接某个 MCP Server 的协议客户端。

Server

对外暴露 Resources、Prompts 和 Tools。

35.3 Resources

资源可以表示：

文件；
数据库记录；
Schema；
日志；
文档； -上下文数据。

它们更偏“可读取内容”。

35.4 Tools

工具可以：

查询数据库；
调用 API；
执行计算；
写入系统；
发起工作流。

每个 Tool 有名称和输入 Schema。

35.5 Prompts

Prompts 提供可复用的模板或工作流入口，使客户端可以发现并使用预定义任务。

35.6 MCP 不自动解决的问题

MCP 不是完整的企业安全和 Agent 平台。仍需自行解决：

身份认证；
授权；
Secret；
审计；
数据脱敏；
租户隔离；
工具审批；
速率限制；
事务；
版本管理；
Prompt Injection。

35.7 MCP 与普通 Function Calling 的关系

Function Calling 是模型与应用内部工具调用格式。

MCP 是应用与外部服务之间的标准协议。

可以组合：

模型生成 Tool Call
→ Agent Runtime 选择 MCP Tool
→ MCP Client 调用 Server
→ 返回结果
→ 模型继续处理

36. Multi-Agent 的适用边界

Multi-Agent 指多个 Agent 以不同角色协作，例如：

研究 Agent
→ 分析 Agent
→ 写作 Agent
→ 审核 Agent

36.1 适合场景

任务天然分工；
不同 Agent 需要不同工具；
不同权限；
可以并行；
每个角色有明确输入输出；
需要独立审查。

36.2 不适合场景

单个工作流即可完成；
多 Agent 只是让多个模型“讨论”；
没有明确终止条件；
角色重叠；
成本和延迟敏感；
缺少统一状态；
无法评估每个 Agent 的贡献。

36.3 多 Agent 的常见问题

对话循环；
信息重复；
上下文膨胀；
错误相互强化；
责任不清；
任务被过度拆分；
调试困难。

实际设计时，先问：

是否能用一个有状态 Workflow + 若干专用节点完成？

如果可以，不必为了“Agent 感”而引入多 Agent。

37. 企业 Agent Runtime 架构

一个可落地的 Agent Runtime 可以分为以下层次：

用户与应用入口
        ↓
身份、权限、租户
        ↓
任务路由
        ↓
Workflow / Planner
        ↓
模型网关
        ↓
Tools / MCP / RAG / DB
        ↓
状态、Memory、事件
        ↓
Guardrails、审批、审计
        ↓
评估与反馈

37.1 Application Layer

承载：

对话；
表单；
业务页面；
消息渠道；
API。

37.2 Agent Orchestration

负责：

状态机；
节点编排；
重试；
并行；
超时；
人工节点；
事件。

37.3 Model Gateway

统一管理：

模型供应商；
本地模型；
版本；
Adapter；
路由；
限流；
Token；
缓存；
失败切换。

37.4 Knowledge Layer

包括：

RAG；
Search；
SQL；
Knowledge Graph；
实时 API；
权限过滤。

37.5 Tool Layer

统一工具注册和调用，记录：

Tool 版本；
Schema；
权限；
成功率；
延迟；
副作用。

37.6 Governance

企业 Agent 必须具备：

谁调用；
调用了什么；
使用了哪个模型；
使用了哪些知识；
执行了什么动作；
谁批准；
是否可回滚。

37.7 成本治理

成本不仅是模型 Token，还包括：

Embedding；
Reranker；
向量库；
工具 API；
搜索；
OCR；
推理重试；
Agent 步数；
人工审核。

应该按：

应用；
用户；
租户；
Agent；
Workflow；
Tool；
模型；

分别统计。

第六篇　训练、部署与评估实践

38. RTX 5070 Ti 12GB 能做什么

以下按系统实际可用显存约 12GB规划。型号名称和官方标准配置可能因桌面、移动端或识别方式不同，应以 nvidia-smi 和 PyTorch 检测结果为准。

38.1 可行范围

任务	可行性	建议
0.5B～0.8B LoRA / QLoRA	很轻松	用于环境验证、分类和路由
1B～2B LoRA	可行	BF16 LoRA 或 QLoRA
1B～2B QLoRA	很适合	推荐正式起点
3B～4B QLoRA	可行	batch=1，控制序列长度
7B～8B QLoRA	较紧张	需短上下文、优化框架和严格参数
1B 全参数训练	不推荐	优化器与激活显存压力较大
7B 全参数训练	不可行	需要多卡或大显存
1B GRPO	实验性	Rollout 数量和长度必须很小
3B DPO / QLoRA	可尝试	需要同时考虑参考模型和长度
7B 高并发部署	不适合	单卡并发和上下文受限

38.2 最合适的任务

评论意图分类；
情感和主题识别；
购买阶段判断；
固定 JSON 抽取；
Query Rewrite；
RAG 路由；
工具选择；
Text-to-SQL 的有限 Schema；
翻译术语适配；
内容改写；
短文本摘要。

38.3 不适合把硬件用在什么地方

从零训练通用模型；
百亿参数全参数微调；
超长上下文训练；
大规模 RLHF；
大型多模态全参数训练；
追求通用 Benchmark 排名；
使用数十万条超长 CoT 直接训练。

38.4 系统内存和磁盘

建议：

内存：32GB 起，64GB 更稳妥；
SSD：至少预留 100GB；
模型缓存和多个 Checkpoint 会快速增长；
WSL2 环境下将项目放在 Linux 文件系统中，避免跨 Windows 挂载带来的 I/O 性能问题。

39. 本地训练工具选择

39.1 LLaMA-Factory

适合：

初学者；
中文模型；
Web UI；
SFT、LoRA、QLoRA、DPO 等；
配置化训练；
模型合并和导出。

优点：

模型支持广；
数据格式示例多；
命令行和 UI；
易于跑通完整流程。

需要注意：

版本更新快；
不同模型 Template 必须正确；
配置字段可能随版本变化；
训练前查看当前官方 README 和 examples。

39.2 Unsloth

适合：

单卡；
显存紧张；
希望加快训练；
Notebook 实验；
Qwen 等常见模型。

Qwen 官方文档提供了使用 Unsloth 训练 Qwen3 的指南，并说明其支持 LoRA、QLoRA、全参数训练和多种 RL 方法。

注意：

高度优化实现可能对版本兼容敏感；
安装前确认 GPU 架构、PyTorch 和 Triton；
升级版本后重新运行小规模冒烟测试。

39.3 Hugging Face TRL + PEFT

适合：

希望理解代码；
自定义数据处理；
自定义 Loss；
SFT、DPO、GRPO；
与 Transformers 生态深度集成。

核心组件：

transformers
datasets
peft
trl
accelerate
bitsandbytes

优点：

官方生态；
可控；
便于构建自己的训练代码。

缺点：

需要处理更多细节；
数据模板、Padding、Mask、保存和评估需自行理解。

39.4 Axolotl

适合：

YAML 配置；
单卡到多卡；
SFT、RLHF、Reward Model、PRM；
较复杂训练优化。

Qwen 官方文档提供了 Qwen3 与 Axolotl 的后训练指南。

39.5 MS-SWIFT

适合：

Qwen 生态；
文本和多模态；
SFT、LoRA、QLoRA、DoRA；
DPO、GRPO、PPO、KTO 等；
单卡到分布式。

如果主要实验 Qwen 系列，MS-SWIFT 是值得比较的工具。

39.6 推荐学习顺序

LLaMA-Factory 跑通
→ TRL + PEFT 理解原理
→ Unsloth 优化单卡效率
→ 根据任务考虑 MS-SWIFT / Axolotl

不要一次安装所有框架到同一 Python 环境。建议为每个框架使用独立 Conda 环境。

40. 从数据到 LoRA 的完整实验流程

下面给出一个可执行的最小项目：训练“社媒评论意图与购买阶段分析模型”。

40.1 项目目标

输入：

已经去店里试驾了，销售说本月有优惠，准备周末再谈贷款方案。

输出：

{
  "language": "zh",
  "sentiment": "positive",
  "intent": "purchase_intent",
  "purchase_stage": "A4",
  "topics": ["试驾", "优惠", "金融方案"],
  "recommended_action": "提供贷款月供对比并安排近期跟进"
}

40.2 环境准备

40.3 创建环境

conda create -n llm-ft python=3.11 -y
conda activate llm-ft
pip install -U pip setuptools wheel

PyTorch 安装命令应以当前 PyTorch 官方选择器和显卡支持为准，不要长期复制旧 CUDA Wheel 地址。

40.4 安装 LLaMA-Factory

git clone --depth 1 https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory
pip install -e ".[torch,bitsandbytes]"

检查：

llamafactory-cli version
python -m bitsandbytes

40.5 基础模型选择

建议顺序：

0.6B～0.8B：验证环境；
1.5B～2B：正式实验；
3B～4B：复杂任务；
7B：只在前面稳定后尝试。

底座应满足：

中文和目标语言能力；
License 可接受；
Chat Template 清晰；
框架支持；
Tokenizer 效率；
有 Instruct 版本；
模型卡完整。

40.6 标签定义

language:
zh / en / ja / ko / th / ms / vi / other

sentiment:
positive / neutral / negative / mixed

intent:
product_inquiry
price_inquiry
product_comparison
purchase_intent
after_sales
complaint
usage_experience
recommendation
brand_discussion
irrelevant

purchase_stage:
A1 / A2 / A3 / A4 / A5 / unknown

必须写标注手册，尤其解释 A2、A3 和 A4 的边界。

40.7 数据样本

{
  "messages": [
    {
      "role": "system",
      "content": "分析社交媒体评论。只输出合法JSON，不输出Markdown。"
    },
    {
      "role": "user",
      "content": "已经去店里试驾了，准备周末再谈贷款方案。"
    },
    {
      "role": "assistant",
      "content": "{\"language\":\"zh\",\"sentiment\":\"positive\",\"intent\":\"purchase_intent\",\"purchase_stage\":\"A4\",\"topics\":[\"试驾\",\"金融方案\"],\"recommended_action\":\"提供贷款月供对比并安排近期跟进\"}"
    }
  ]
}

40.8 数据集规模

第一轮：

Train：1,000
Validation：150
Test：200

要求：

Test 不参与任何调参；
训练前先跑 Base；
保留少数类；
按评论来源或时间切分；
删除近重复。

40.9 冒烟训练

先使用 100 条：

model_name_or_path: <BASE_MODEL>
stage: sft
do_train: true
finetuning_type: lora

dataset: comment_smoke
template: <CORRECT_TEMPLATE>
cutoff_len: 512

output_dir: outputs/comment-smoke
per_device_train_batch_size: 1
gradient_accumulation_steps: 4
learning_rate: 0.0002
num_train_epochs: 1

bf16: true
gradient_checkpointing: true
quantization_bit: 4
quantization_method: bitsandbytes

lora_rank: 8
lora_alpha: 16
lora_dropout: 0.05
lora_target: all

logging_steps: 1
save_steps: 20
report_to: none

冒烟训练验收：

模型能加载；
数据能读取；
Loss 正常；
无 OOM；
Adapter 能保存；
Adapter 能推理；
输出语言正常。

40.10 正式训练建议

cutoff_len: 1024
per_device_train_batch_size: 1
gradient_accumulation_steps: 8

learning_rate: 0.0002
num_train_epochs: 2
lr_scheduler_type: cosine
warmup_ratio: 0.05
weight_decay: 0.01

lora_rank: 8
lora_alpha: 16
lora_dropout: 0.05

eval_strategy: steps
eval_steps: 100
save_steps: 100
save_total_limit: 3
load_best_model_at_end: true

40.11 OOM 调整顺序

cutoff_len: 1024 → 768 → 512
确保 batch size 为 1
开启 Gradient Checkpointing
关闭不必要的评估生成
减少 LoRA Target Modules
rank: 16 → 8 → 4
使用更小模型
检查其他程序占用显存
使用支持更高效内核的框架

40.12 训练后推理设置

结构化任务建议：

temperature = 0
do_sample = false
max_new_tokens = 256

并在服务端：

解析 JSON；
验证 Schema；
若失败，进行一次格式修复或重试；
记录失败样本；
不应无限重试。

40.13 评测指标

JSON 合法率
字段完整率
Intent Macro-F1
Stage Macro-F1
Topic Micro-F1
Recommended Action 人工可用率
平均延迟
输出 Token

对比：

Base + Zero-shot
Base + Few-shot
LoRA
LoRA + 约束输出

40.14 第二轮优化

根据错误类型补数据：

A3 / A4 混淆；
多意图；
反问；
隐性投诉；
广告垃圾；
多语言混合；
超短文本；
只有表情；
无证据；
与产品无关。

不要只增加与错误样本完全相同的改写。应补充一组具有相同决策边界但不同表达的样本。

41. 模型部署：Ollama、llama.cpp、vLLM 与 SGLang

41.1 Ollama

适合：

本地快速运行；
简单 API；
桌面开发；
GGUF 模型；
单用户和低并发。

优点：

安装简单；
模型管理方便；
API 易用。

不足：

高吞吐生产能力和精细调优不如专业 Serving Framework；
多 Adapter、复杂并发治理需额外方案。

41.2 llama.cpp

适合：

CPU / GPU 混合；
GGUF；
边缘设备；
桌面；
低资源部署；
多种量化。

优点：

硬件覆盖广；
社区成熟；
可将部分层卸载到 GPU；
适合本地模型。

41.3 vLLM

vLLM 是高吞吐 LLM Serving 框架，支持：

OpenAI-compatible API；
连续批处理；
KV Cache 管理；
多种量化；
LoRA Adapter；
多 GPU；
生产服务。

vLLM 官方文档说明可在基础模型上按请求使用 LoRA Adapter，并支持多种量化方式。

适合：

GPU 服务；
并发；
多请求批处理；
标准 API；
多 LoRA 路由。

41.4 SGLang

SGLang 是面向大语言和多模态模型的高性能推理框架，强调：

低延迟；
高吞吐；
Prefix Caching；
RadixAttention；
LoRA Serving；
量化；
分布式部署；
结构化输出。

SGLang 官方文档说明可以用一个 Base Model 高效服务多个 LoRA Adapter。

41.5 如何选择

场景	推荐
个人桌面快速体验	Ollama / LM Studio
CPU 或混合推理	llama.cpp
单卡生产 API	vLLM / SGLang
多 LoRA 动态服务	vLLM / SGLang
多模态高性能	根据模型比较 vLLM / SGLang
极简本地工具	Ollama
边缘设备	llama.cpp

41.6 量化格式选择

GGUF Q4_K_M

常用于 llama.cpp，质量和体积之间较平衡。

AWQ

面向权重量化，常用于 GPU 推理。

GPTQ

另一类常见后训练量化。

BitsAndBytes 4-bit

方便 Transformers 加载和 QLoRA，不一定是所有生产部署的最佳格式。

FP8

需要确认 GPU 硬件和框架内核支持。不同显卡架构支持不同，不能仅因为显卡“较新”就假定所有 FP8 模式可用。

41.7 训练与部署格式不是一回事

训练时使用：

Transformers + 4-bit bitsandbytes + LoRA

部署时可能转换为：

合并 BF16 → AWQ
合并 BF16 → GGUF
动态 Base + Adapter

每次转换都需要重新评测。

42. 结构化输出、约束解码与服务治理

42.1 Prompt 不能保证合法 JSON

即使 Prompt 写了“只输出 JSON”，模型仍可能：

加 Markdown；
漏引号；
输出枚举外值；
添加解释；
字段缺失；
类型错误。

42.2 约束解码

可使用：

JSON Schema；
Grammar；
Regex；
枚举；
Structured Outputs；
Constrained Decoding。

约束解码在生成阶段限制允许的 Token，使格式更可靠。

42.3 Schema 设计

Schema 不要过度复杂。

错误：

数十层嵌套；
大量可选字段；
同一字段多种类型；
自由文本中再嵌 JSON。

更好：

字段少；
类型固定；
枚举清晰；
使用版本；
必填与可选明确。

42.4 服务治理

API 层应包含：

输入长度；
Rate Limit；
Timeout；
Retry；
Circuit Breaker；
Schema Validation；
敏感信息处理；
模型版本；
Trace ID；
缓存；
降级策略。

42.5 模型不可用时的降级

例如：

本地 LoRA 模型失败
→ Base 模型 + Few-shot
→ 云端模型
→ 规则模板
→ 人工

降级策略要根据任务风险设计。高风险任务宁可转人工，也不应使用低可靠备选模型自动执行。

43. 评估体系：不要只看 Loss

训练 Loss 只能说明模型更接近训练数据，不能证明模型在真实任务中更好。

一个完整评估体系至少包含：

模型离线评估
+ 系统组件评估
+ 端到端评估
+ 业务指标
+ 安全与红队

43.1 分类和抽取任务

常用指标：

Accuracy；
Precision；
Recall；
Macro-F1；
Micro-F1；
Exact Match；
Schema Valid Rate；
Field Completeness。

为什么使用 Macro-F1：

如果 80% 样本是普通咨询，Accuracy 很高也可能掩盖投诉、购买意向等少数类失败。Macro-F1 对每个类别平等平均。

43.2 生成任务

生成任务难以只有唯一标准答案，可以使用：

人工评分；
LLM-as-a-Judge；
Pairwise Comparison；
事实一致性；
引用正确率；
风格一致性；
信息完整性；
可执行性；
冗余度。

LLM Judge 应：

使用清晰 Rubric；
随机交换候选顺序，检查位置偏置；
使用多个 Judge；
与人工样本校准；
避免评审模型与被评模型同源偏置；
保留原始评分理由。

43.3 工具调用评估

可评估：

Tool Selection Accuracy；
Argument Exact Match；
参数合法率；
调用成功率；
多步任务完成率；
无需工具时不调用；
高风险工具确认率；
重试次数；
平均步数。

43.4 Agent 评估

Agent 不能只评最终回答，还要评路径：

是否选择正确工作流
是否使用正确工具
是否重复调用
是否越权
是否在预算内完成
是否满足终止条件
是否需要人工介入

常用端到端指标：

Task Success Rate；
Average Steps；
Tool Error Recovery Rate；
Human Intervention Rate；
Cost per Successful Task；
P95 Latency。

43.5 RAG 评估

前文提到应分别评：

Parse；
Retrieve；
Rerank；
Generate；
Citation；
Business Outcome。

如果只评最终答案，无法确定错误来自哪个环节。

43.6 回归测试

每次更换：

Base Model；
LoRA；
Prompt；
Embedding；
Reranker；
Chunk；
Tool Schema；
Serving Framework；

都应运行固定回归集。

回归集应保留历史真实事故，防止修复一个问题又让旧问题复发。

43.7 A/B Test

线上实验可以比较：

旧模型与新模型；
Prompt 与 LoRA；
纯向量与 Hybrid；
不同 Reranker；
小模型与大模型路由；
Agent 与固定 Workflow。

A/B 指标必须提前定义，避免上线后只挑有利数据。

43.8 安全评估

包括：

Prompt Injection；
数据泄露；
越权访问；
工具滥用；
敏感信息；
幻觉引用；
拒答稳定性；
恶意文件；
SQL 注入；
代码执行逃逸；
多轮诱导。

44. 数据飞轮与持续改进

模型上线不是项目结束，而是数据生产开始。

44.1 数据飞轮

用户请求
→ 模型输出
→ 工具执行
→ 用户或业务反馈
→ 失败分类
→ 数据集更新
→ 重新训练 / 更新 Prompt / 更新 RAG
→ 回归评测
→ 灰度上线

44.2 哪些反馈最有价值

用户手工修改模型结果；
专家拒绝建议的原因；
工具调用失败；
人工接管；
RAG 无答案；
错误引用；
高价值少数类；
新政策上线后的问题；
多语言失败；
真实转化或业务结果。

44.3 不要把所有日志直接训练

日志中可能包含：

错误答案；
用户隐私；
Prompt Injection；
重复；
无效闲聊；
过期知识；
模型生成文本；
未授权内容。

必须经过：

筛选
→ 脱敏
→ 去重
→ 标注
→ 版本化
→ 审核

44.4 Active Learning

让模型找出最值得人工标注的样本：

低置信；
多模型分歧；
边界样本；
新分布；
高业务价值；
高频错误；
少数类。

这样比随机标注更有效。

44.5 数据和模型版本关系

每次训练记录：

experiment_id: comment-intent-v3
base_model: <model-name-and-revision>
dataset_version: comments-2026-07-v4
dataset_hash: <hash>
trainer: llamafactory
method: qlora
rank: 8
alpha: 16
learning_rate: 0.0001
epochs: 2
max_length: 1024
seed: 42
code_commit: <git-sha>

同时保存：

Checkpoint；
Adapter；
Tokenizer；
Chat Template；
配置；
指标；
错误样本；
License；
Model Card；
Dataset Card。

45. 企业 AI 分阶段落地路线

45.1 阶段 0：问题定义

先回答：

当前流程哪里慢；
错误成本多少；
是否需要生成式模型；
是否有数据；
如何评估成功；
是否涉及敏感或高风险动作。

不要从“我们要训练模型”开始。

45.2 阶段 1：Prompt 与强模型基线

使用成熟模型和 Prompt 快速验证：

任务可行性；
输入输出；
用户价值；
标签；
评测集。

这一阶段产出：

任务 Schema；
黄金数据集；
Prompt 基线；
失败分类。

45.3 阶段 2：RAG 或工具连接

如果问题依赖企业知识和实时数据，先接入：

文档检索；
SQL；
API；
Search；
Tool Calling。

产出：

权限；
引用；
检索评测；
工具成功率。

45.4 阶段 3：小模型 SFT / LoRA

当任务稳定、调用量大或成本敏感时：

1B～4B Instruct
+ QLoRA
+ 高质量任务数据

目标：

替代部分大模型请求；
提高格式稳定；
降低延迟；
私有化；
固化业务标签。

45.5 阶段 4：偏好优化

在积累足够专家反馈后使用 DPO、KTO 等优化：

建议质量；
风格；
优先级；
风险判断；
冗余。

45.6 阶段 5：Agent Workflow

将模型嵌入确定性工作流：

分类
→ 检索
→ 工具调用
→ 审批
→ 执行
→ 记录

优先实现可观测、可回滚、可人工接管。

45.7 阶段 6：RLVR 和复杂推理

只有当任务有可靠验证器、基础系统稳定时，再尝试：

GRPO；
RLVR；
工具环境训练；
多步任务奖励。

对多数企业项目，RL 并不是前几个阶段的必需项。

46. 必须掌握的概念清单

46.1 模型层

Base / Instruct / Reasoning；
Dense / MoE；
SLM / LLM / VLM；
Tokenizer；
Context Window；
KV Cache；
Quantization；
Chat Template；
Structured Output。

46.2 训练层

Pre-training；
Continued Pre-training；
SFT；
PEFT；
LoRA / QLoRA；
DoRA；
DPO / ORPO / SimPO / KTO；
RLHF / RLVR / PPO / GRPO；
Distillation；
Gradient Checkpointing；
Packing；
Data Collator；
Label Masking。

46.3 RAG 层

Parser；
Chunk；
Embedding；
Dense / Sparse；
BM25；
Hybrid Search；
RRF；
Reranker；
Metadata；
ACL；
Parent-Child；
Query Rewrite；
Query Decomposition；
GraphRAG；
Citation；
Faithfulness。

46.4 Agent 层

Workflow；
ReAct；
Planner；
State；
Memory；
Tool Calling；
MCP；
Human-in-the-loop；
Guardrails；
Observability；
Idempotency；
Approval；
Model Routing。

46.5 工程治理

Model Registry；
Dataset Version；
Experiment Tracking；
Prompt Version；
Eval Set；
Regression；
Canary；
Cost Attribution；
Privacy；
Audit；
Red Teaming。

附录 A：如何理解 Hugging Face 上的热门微调模型

Hugging Face 模型名称经常包含很多词，不能只看“热门”或 Benchmark。

A.1 `Instruct`

表示模型经过指令微调，适合对话和任务。

A.2 `Chat`

强调聊天格式和多轮对话。

A.3 `Distill`

表示学生模型从更强教师模型输出中学习。它可能是：

最终答案蒸馏；
推理轨迹蒸馏；
Logit 蒸馏；
Tool 轨迹蒸馏。

DeepSeek-R1-Distill-Qwen-* 一类名称通常代表使用某底座吸收 R1 风格数据或能力，而不是把 R1 模型简单压缩成同一架构。

A.4 `SFT`

主要经过监督式微调。

A.5 `DPO` / `ORPO` / `GRPO`

表示作者声明使用对应后训练方法。但需要查看：

基于什么 Checkpoint；
使用什么数据；
是否完整发布训练配置；
是否只是名称；
Benchmark 是否可复现。

A.6 `Uncensored`

通常不是模型存在一个“解除限制开关”，而是作者通过：

删除拒答样本；
增加直接回答数据；
使用 DPO 偏好非拒答；
修改 System Prompt；
对齐向量或权重编辑；
模型融合；

降低拒答倾向。

这种模型可能：

更少拒答；
同时降低安全性；
对事实准确性没有必然提升；
可能把“无条件回答”误当作能力；
不适合直接接入有写权限的企业工具。

A.7 `Abliterated`

社区中常指通过权重编辑或方向消除，降低模型中与拒答相关的表示方向。

它不是标准化方法，也不保证：

安全完全移除；
能力不受损；
所有拒答消失；
模型更聪明。

必须查看作者方法和评测。

A.8 `RP` / `Roleplay`

偏向角色扮演、长对话、人物一致性和创作。未必适合：

企业事实问答；
JSON；
Tool Calling；
代码；
分类。

A.9 `Merge`

模型可能由多个模型或 Adapter 通过：

Linear Merge；
SLERP；
TIES；
DARE；
Task Arithmetic；

合并而成。

Merge 可以组合能力，也可能产生不可预测退化。必须查看 Merge 配置和基线。

A.10 `GGUF`、`GPTQ`、`AWQ`、`EXL2`

这些主要描述推理格式或量化，不等于新的训练能力。

A.11 `MFP`

截至本文整理时，MFP 并不是一个像 LoRA、DPO、GRPO 那样在 LLM 后训练领域具有统一定义的主流缩写。它可能是：

某篇论文或项目自定义方法；
某个任务名；
作者内部训练流程缩写；
与其他缩写混淆。

看到 MFP 时必须打开 Model Card 或论文确认全称，不应把它当作统一算法。类似不明确缩写都应按项目上下文判断。

A.12 评估 HF 社区模型的检查清单

Base Model 是什么；
Base 是否允许商用；
数据来源与 License；
训练方法；
是否发布代码和配置；
是否 Merge；
是否量化；
Chat Template；
Context Length；
Benchmark 是否与训练数据污染；
是否有真实任务评测；
是否存在安全风险；
是否支持目标推理框架。

附录 B：三个完整企业案例

B.1 企业知识客服

目标

回答产品、政策和服务问题，并在必要时查询订单或创建工单。

技术组合

意图分类小模型
+ Hybrid RAG
+ Reranker
+ 订单工具
+ 工单 Workflow
+ 人工升级

流程

用户问题
→ 判断知识问答 / 订单 / 投诉
→ 知识问答：RAG
→ 订单：工具查询
→ 投诉：收集信息并创建工单
→ 高风险：人工

微调内容

意图分类；
回答结构；
工具路由；
工单字段抽取。

不训练进模型

最新政策；
订单；
用户信息；
当前库存。

评测

知识正确率；
引用准确率；
订单工具成功率；
投诉建单完整率；
转人工准确率。

B.2 销售线索 Agent

目标

根据用户行为、对话和 CRM 历史判断意向并生成下一步行动。

数据来源

浏览；
评论；
私信；
试驾；
报价；
CRM；
活动；
历史跟进。

技术组合

1B～4B 意图模型
+ CRM 工具
+ 产品政策 RAG
+ 跟进 Workflow
+ 人工确认

LoRA 训练内容

购买阶段；
障碍因素；
下一步动作；
证据字段；
多意图。

Agent 动作

查询客户；
查询产品；
获取政策；
生成任务草稿；
销售确认；
写回 CRM。

风险

将普通兴趣误判为高意向；
使用过期优惠；
未经确认自动联系；
用户隐私；
重复创建任务。

B.3 营销分析 Agent

目标

基于社媒内容、评论、投放和销售数据，发现变化并形成策略建议。

技术组合

内容分类模型
+ 评论意图模型
+ 数据库 / SQL
+ 行业知识 RAG
+ 分析 Workflow
+ 报告生成模型

工作流

确定分析问题
→ 查询数据
→ 计算指标
→ 识别异常
→ 检索相关内容和活动
→ 形成假设
→ 验证假设
→ 输出证据、建议和风险

为什么不能只用 CoT 模型

分析必须依赖真实数据和统计工具。模型推理只能用于：

问题分解；
假设生成；
结果解释；
建议组织。

不能让模型凭语言感觉虚构数据原因。

附录 C：项目交付物模板

一个规范的模型项目应包含：

01_problem_definition.md
02_label_guide.md
03_data_schema.json
04_dataset_card.md
05_train.jsonl
06_validation.jsonl
07_test.jsonl
08_training_config.yaml
09_environment_lock.txt
10_training_logs/
11_adapter/
12_merged_model/
13_evaluation_report.md
14_error_cases.jsonl
15_model_card.md
16_deployment_config/
17_security_review.md
18_release_notes.md

RAG 项目应额外包含：

parser_version
chunk_strategy
embedding_model
index_version
metadata_schema
retrieval_eval
reranker_eval
golden_qa
permission_test
citation_test

Agent 项目应额外包含：

workflow_graph
tool_registry
tool_schemas
permission_matrix
state_schema
retry_policy
approval_policy
trace_samples
agent_eval
rollback_plan

附录 D：技术选择快速决策表

问题表现	优先技术	不应首先做什么
模型不知道当前政策	RAG / API	把政策做成 LoRA
输出格式不稳定	约束解码、SFT	更换更大模型后不评测
内部标签经常分错	SFT / LoRA	只增加 Prompt 长度
答案正确但质量不一致	DPO / 专家 Rubric	直接做 GRPO
不熟悉大量专业语言	领域继续预训练	只用少量 FAQ 继续预训练
检索主题相关但答案不准	Hybrid + Reranker	只增大 Top-K
型号、编号检索失败	BM25 / Metadata	只用 Dense Vector
工具经常选错	Tool SFT、路由评测	让 Agent 自由尝试更多次
多步任务失败	Workflow、State、重试	只增加 CoT 长度
简单任务成本过高	小模型路由 / LoRA	所有请求都用推理大模型
企业知识需要权限	检索阶段 ACL	只在 Prompt 中提醒保密
回答无法证明来源	Citation RAG	让模型自行生成引用
模型训练后退化	数据、模板和基线排查	继续增加 Epoch
需要真实业务执行	Tool Calling + Agent Runtime	把动作写成自然语言建议
没有可靠评测	先建黄金集	先训练或上线

附录 E：术语简表

ACL Access Control List，访问控制列表。RAG 中应在检索前过滤用户无权访问的内容。

Adapter 在基础模型之外保存的可训练差分参数。LoRA Adapter 是最常见形式。

Alignment 让模型行为更符合人类、组织或任务偏好的训练过程。

BF16 BFloat16，适合训练的 16-bit 浮点格式，动态范围大于 FP16。

BM25 经典关键词检索算法，适合型号、编号和精确术语。

Chat Template 将 system、user、assistant 和 Tool 消息转换为模型训练时使用的 Token 格式。

CoT Chain of Thought，思维链或推理轨迹。

DAPT Domain-Adaptive Pretraining，领域自适应继续预训练。

DPO Direct Preference Optimization，直接偏好优化。

Embedding 将文本映射为向量，用于语义检索和相似度。

EOS End of Sequence，序列结束 Token。

FSDP Fully Sharded Data Parallel，大规模分布式训练技术。

GGUF llama.cpp 生态常用的模型推理文件格式。

GRPO Group Relative Policy Optimization，组相对策略优化。

Hard Negative 与 Query 表面相似但不是正确答案的负样本。

Hybrid Search 结合词法和语义检索。

Inference 模型推理，即使用训练完成的模型生成结果。

KV Cache 推理时缓存注意力 Key / Value，影响长上下文和并发显存。

LoRA Low-Rank Adaptation，低秩适配。

MCP Model Context Protocol，AI 应用连接外部数据与工具的开放标准。

MoE Mixture of Experts，混合专家模型；每个 Token 通常只激活部分专家参数。

ORPO Odds Ratio Preference Optimization，将监督与偏好目标结合的方法。

Packing 将多个短训练样本拼接到同一序列，提高 Token 利用率。

PEFT Parameter-Efficient Fine-Tuning，参数高效微调。

QLoRA 量化基础模型并训练 LoRA Adapter。

RAG Retrieval-Augmented Generation，检索增强生成。

Reranker 对初始检索候选进行精细重排序的模型。

RRF Reciprocal Rank Fusion，按排名融合多路检索结果。

RLHF Reinforcement Learning from Human Feedback，基于人类反馈的强化学习。

RLVR Reinforcement Learning with Verifiable Rewards，基于可验证奖励的强化学习。

SFT Supervised Fine-Tuning，监督式微调。

SLM Small Language Model，小语言模型，通常用于低成本、低延迟或端侧任务。

Tokenizer 将文本转换成 Token ID 的组件。

Tool Calling 模型生成结构化工具调用意图，由外部程序实际执行。

Vector DB 存储和检索向量的数据库或搜索系统。

参考资料与进一步阅读

以下链接以官方文档、项目仓库和原始论文为主。软件版本和数据集内容会更新，实际使用时应查看最新版本、License 和提交记录。

模型训练、PEFT 与后训练

开源训练框架

推理数据集与开放研究

RAG、Embedding 与检索

Agent、工具和 MCP

推理部署

结语

企业 AI 的技术路线不应被简化为“选一个最强模型”。

更完整的体系是：

基础模型
+ 任务后训练
+ 企业知识检索
+ 工具和工作流
+ 权限与治理
+ 评估和数据飞轮

其中：

Base Model 提供通用语言和推理底座；
SFT / LoRA 固化稳定任务能力；
DPO 等方法优化专业偏好；
RLVR 适用于可验证的复杂任务；
RAG 提供当前、可引用、权限可控的知识；
Agent Runtime 将模型连接到业务系统；
评估和数据闭环决定系统能否持续变好。

对拥有 12GB 显存的个人或小团队，最有价值的路线不是追求从零训练通用大模型，而是：

选择可靠的 1B～4B Instruct Base
→ 建立真实任务评测集
→ 使用 QLoRA 训练专用能力
→ 使用 RAG 管理企业知识
→ 使用 Workflow 和 Tool Calling 完成执行
→ 通过反馈持续迭代

这条路线能够以可控成本完整理解并实践现代企业 AI 的核心技术链路。

附录 F：单卡 QLoRA 项目目录与可执行脚本

本附录给出一个更接近真实项目的目录结构。框架字段可能随版本调整，运行前需对照当前 LLaMA-Factory 或 TRL 文档。

F.1 项目目录

comment-intent-model/
├── README.md
├── data/
│   ├── raw/
│   │   └── comments.csv
│   ├── processed/
│   │   └── all.jsonl
│   └── splits/
│       ├── train.json
│       ├── validation.json
│       └── test.json
├── configs/
│   ├── smoke.yaml
│   ├── train_v1.yaml
│   ├── infer_v1.yaml
│   └── merge_v1.yaml
├── scripts/
│   ├── prepare_data.py
│   ├── validate_dataset.py
│   ├── compare_predictions.py
│   └── inspect_tokens.py
├── evaluations/
│   ├── baseline.jsonl
│   ├── lora_v1.jsonl
│   └── report.md
├── outputs/
│   ├── adapter-v1/
│   └── merged-v1/
└── requirements.txt

F.2 原始 CSV

id,text,language,sentiment,intent,purchase_stage,topics,recommended_action
1,最近一直在看混动车，不知道冬天续航掉得厉不厉害。,zh,neutral,product_comparison,A3,续航|能耗,提供冬季续航实测内容
2,已经订车了，销售说月底可以提车。,zh,positive,purchase_intent,A4,交付|销售,确认交付时间并同步准备事项
3,买了一年后空调出现异响。,zh,negative,after_sales,A5,空调|异响,创建售后诊断工单

F.3 数据转换脚本

import json
from pathlib import Path

import pandas as pd
from sklearn.model_selection import train_test_split

ROOT = Path(__file__).resolve().parents[1]
INPUT = ROOT / "data/raw/comments.csv"
OUTPUT = ROOT / "data/splits"
SEED = 42

LANGUAGES = {"zh", "en", "ja", "ko", "th", "ms", "vi", "other"}
SENTIMENTS = {"positive", "neutral", "negative", "mixed"}
INTENTS = {
    "product_inquiry",
    "price_inquiry",
    "product_comparison",
    "purchase_intent",
    "after_sales",
    "complaint",
    "usage_experience",
    "recommendation",
    "brand_discussion",
    "irrelevant",
}
STAGES = {"A1", "A2", "A3", "A4", "A5", "unknown"}


def split_topics(value: str) -> list[str]:
    if pd.isna(value):
        return []
    return [x.strip() for x in str(value).split("|") if x.strip()]


def validate(row: pd.Series) -> None:
    assert row["language"] in LANGUAGES
    assert row["sentiment"] in SENTIMENTS
    assert row["intent"] in INTENTS
    assert row["purchase_stage"] in STAGES
    assert str(row["text"]).strip()
    assert str(row["recommended_action"]).strip()


def convert(row: pd.Series) -> dict:
    validate(row)

    output = {
        "language": row["language"],
        "sentiment": row["sentiment"],
        "intent": row["intent"],
        "purchase_stage": row["purchase_stage"],
        "topics": split_topics(row["topics"]),
        "recommended_action": str(row["recommended_action"]).strip(),
    }

    return {
        "messages": [
            {
                "role": "system",
                "content": (
                    "分析社交媒体评论。"
                    "严格输出合法JSON，不输出Markdown和额外解释。"
                ),
            },
            {
                "role": "user",
                "content": str(row["text"]).strip(),
            },
            {
                "role": "assistant",
                "content": json.dumps(
                    output,
                    ensure_ascii=False,
                    separators=(",", ":"),
                ),
            },
        ]
    }


def save(records: list[dict], filename: str) -> None:
    path = OUTPUT / filename
    path.write_text(
        json.dumps(records, ensure_ascii=False, indent=2),
        encoding="utf-8",
    )


def main() -> None:
    OUTPUT.mkdir(parents=True, exist_ok=True)

    df = pd.read_csv(INPUT)
    df = df.dropna(subset=["text"])
    df["normalized"] = (
        df["text"]
        .astype(str)
        .str.strip()
        .str.replace(r"\s+", " ", regex=True)
    )
    df = df.drop_duplicates(subset=["normalized"])

    records = [convert(row) for _, row in df.iterrows()]

    train, temp = train_test_split(
        records,
        test_size=0.20,
        random_state=SEED,
    )
    validation, test = train_test_split(
        temp,
        test_size=0.50,
        random_state=SEED,
    )

    save(train, "train.json")
    save(validation, "validation.json")
    save(test, "test.json")

    print("train:", len(train))
    print("validation:", len(validation))
    print("test:", len(test))


if __name__ == "__main__":
    main()

真实项目不应只做随机切分。应根据数据来源选择按时间、用户、产品或模板簇切分。上面脚本只是最小示例。

F.4 Token 长度检查脚本

import json
from pathlib import Path

import numpy as np
from transformers import AutoTokenizer

MODEL = "<BASE_MODEL>"
DATA = Path("data/splits/train.json")

tokenizer = AutoTokenizer.from_pretrained(
    MODEL,
    trust_remote_code=True,
)

records = json.loads(DATA.read_text(encoding="utf-8"))
lengths = []

for item in records:
    text = tokenizer.apply_chat_template(
        item["messages"],
        tokenize=False,
        add_generation_prompt=False,
    )
    token_ids = tokenizer(text, add_special_tokens=False)["input_ids"]
    lengths.append(len(token_ids))

for q in [50, 75, 90, 95, 99, 100]:
    print(f"P{q}:", int(np.percentile(lengths, q)))

根据分布选择 cutoff_len，而不是先拍脑袋设为 4096。

F.5 LLaMA-Factory 数据注册示意

在 data/dataset_info.json 中增加：

{
  "comment_train": {
    "file_name": "comment_train.json",
    "formatting": "sharegpt",
    "columns": {
      "messages": "messages"
    },
    "tags": {
      "role_tag": "role",
      "content_tag": "content",
      "user_tag": "user",
      "assistant_tag": "assistant",
      "system_tag": "system"
    }
  }
}

具体字段以当前 LLaMA-Factory 版本示例为准。

F.6 冒烟配置

model_name_or_path: <BASE_MODEL>
trust_remote_code: true

stage: sft
do_train: true
finetuning_type: lora

dataset: comment_smoke
template: <MODEL_TEMPLATE>
cutoff_len: 512
overwrite_cache: true
preprocessing_num_workers: 4

output_dir: outputs/comment-smoke
logging_steps: 1
save_steps: 20
overwrite_output_dir: true

per_device_train_batch_size: 1
gradient_accumulation_steps: 4
learning_rate: 0.0002
num_train_epochs: 1
lr_scheduler_type: cosine
warmup_ratio: 0.05

bf16: true
fp16: false
gradient_checkpointing: true

quantization_bit: 4
quantization_method: bitsandbytes

lora_rank: 8
lora_alpha: 16
lora_dropout: 0.05
lora_target: all

report_to: none

F.7 正式配置

model_name_or_path: <BASE_MODEL>
trust_remote_code: true

stage: sft
do_train: true
finetuning_type: lora

dataset: comment_train
eval_dataset: comment_validation
template: <MODEL_TEMPLATE>
cutoff_len: 1024
overwrite_cache: true
preprocessing_num_workers: 8

output_dir: outputs/comment-adapter-v1
logging_steps: 5
eval_steps: 100
save_steps: 100
save_total_limit: 3
overwrite_output_dir: true
plot_loss: true

per_device_train_batch_size: 1
per_device_eval_batch_size: 1
gradient_accumulation_steps: 8

learning_rate: 0.0002
num_train_epochs: 2
lr_scheduler_type: cosine
warmup_ratio: 0.05
weight_decay: 0.01

bf16: true
fp16: false
gradient_checkpointing: true

quantization_bit: 4
quantization_method: bitsandbytes

lora_rank: 8
lora_alpha: 16
lora_dropout: 0.05
lora_target: all

eval_strategy: steps
load_best_model_at_end: true
metric_for_best_model: eval_loss
greater_is_better: false

seed: 42
report_to: none

F.8 Adapter 推理配置

model_name_or_path: <BASE_MODEL>
adapter_name_or_path: outputs/comment-adapter-v1
template: <MODEL_TEMPLATE>
finetuning_type: lora

quantization_bit: 4
quantization_method: bitsandbytes
trust_remote_code: true

F.9 合并配置

model_name_or_path: <BASE_MODEL>
adapter_name_or_path: outputs/comment-adapter-v1
template: <MODEL_TEMPLATE>
finetuning_type: lora

export_dir: outputs/comment-merged-v1
export_size: 2
export_device: cpu
export_legacy_format: false
trust_remote_code: true

F.10 评测输出记录格式

{
  "sample_id": "test-001",
  "input": "已经试驾，周末准备谈贷款方案。",
  "expected": {
    "intent": "purchase_intent",
    "purchase_stage": "A4"
  },
  "base_output": {
    "intent": "product_comparison",
    "purchase_stage": "A3"
  },
  "lora_output": {
    "intent": "purchase_intent",
    "purchase_stage": "A4"
  },
  "base_valid_json": true,
  "lora_valid_json": true,
  "error_type": null
}

F.11 实验停止条件

第一版模型达到以下条件后，应先进入业务验证，而不是继续盲目训练：

JSON 合法率 ≥ 98%
主要类别 Macro-F1 达到目标
少数类无明显崩溃
Base / Prompt 基线对比有明确提升
真实样本人工可用率达到目标
平均延迟和显存可接受

如果 LoRA 相对优化 Prompt 提升很小，应重新评估：

是否真的需要微调；
标签是否过于主观；
模型容量是否不足；
数据是否没有增加新信息；
任务是否更适合规则或 RAG。

企业 AI 模型工程与 Agent 架构实践指南

从后训练、LoRA、推理蒸馏、RAG 到企业智能体系统

目录

第一篇 建立正确的大模型认知

第二篇 大模型后训练体系

第三篇 LoRA 与消费级显卡模型工程

第四篇 企业 RAG 工程

第五篇 Agent 与工具执行体系

第六篇 训练、部署与评估实践

第一篇 建立正确的大模型认知

1. 企业 AI 的本质：知识、能力与执行

1.1 知识：模型是否能获得正确事实

1.2 能力：模型是否掌握稳定的处理方法

1.3 执行：模型是否可以完成业务动作

2. 大模型的主要类型

2.1 Base Model：基础模型

2.2 Instruct / Chat Model：指令或对话模型

2.3 Reasoning Model：推理模型

2.4 Embedding Model：向量表征模型

2.5 Reranker：重排序模型

2.6 Reward Model / Judge Model：奖励或评审模型

2.7 VLM 与多模态模型

3. 从预训练到后训练的完整链路

3.1 Pre-training：预训练

3.2 Continued Pre-training：继续预训练

3.3 SFT：监督式指令微调

3.4 Preference Alignment：偏好对齐

3.5 Reinforcement Learning：强化学习

3.6 Distillation：蒸馏

4. 参数、Token、上下文和显存

4.1 参数量不等于文件大小，也不等于显存占用

4.2 推理显存的主要组成

4.3 训练显存的主要组成

4.4 Tokenizer 的重要性

4.5 Context Window 不是长期记忆

5. Prompt、RAG、微调、继续预训练和 Agent 如何选择

5.1 先用 Prompt 的情况

5.2 使用 RAG 的情况

5.3 使用 SFT / LoRA 的情况

5.4 使用偏好优化的情况

5.5 使用继续预训练的情况

5.6 使用 Agent 的情况

5.7 组合案例

第二篇 大模型后训练体系

6. SFT：模型任务能力的起点

6.1 SFT 训练的不是“数据库”

6.2 SFT 可以解决的典型问题

固定结构化输出

内部分类体系

工具调用格式

专业分析方法

统一品牌或组织表达

6.3 SFT 的局限

7. SFT 数据工程与样本设计

7.1 先定义任务，不要先收集数据

7.2 常见数据格式

Alpaca / Instruction 格式

Chat / Messages 格式

Prompt-Completion 格式

Tool Calling 轨迹格式

7.3 训练答案是否应包含推理过程

7.4 数据质量维度

正确性

一致性

覆盖度

多样性

信息密度

可评估性

7.5 真实数据与合成数据如何组合

7.6 数据泄漏与评测污染

7.7 样本数量没有统一答案

8. CoT、Reasoning 与推理蒸馏

8.1 CoT 是什么

8.2 Reasoning Model 不等于“真的像人一样思考”

8.3 隐藏思维链和公开推理文本

8.4 推理蒸馏的基本流程

8.5 Outcome Reward 与 Process Reward

Outcome Reward

Process Reward

8.6 Test-Time Scaling

第一篇　建立正确的大模型认知

第二篇　大模型后训练体系

第三篇　LoRA 与消费级显卡模型工程

第四篇　企业 RAG 工程

第五篇　Agent 与工具执行体系

第六篇　训练、部署与评估实践

第一篇　建立正确的大模型认知

第二篇　大模型后训练体系

第三篇　LoRA 与消费级显卡模型工程

Rank `r`