在前面的章节中，我们依次讨论了：

• Pre-training（预训练）
• Mid-training（持续预训练）
• Fine-tuning（监督微调）
• RL（强化学习）
• Evaluation（评测体系）
• Agent（智能体）

这些阶段看似独立，但最终都服务于同一个目标：

让模型真正为用户创造价值。

很多团队认为：

训练完成 = 项目完成

而在真实工业环境中：

训练完成 = 项目刚刚开始

因为从研究原型（Research Prototype）到生产系统（Production System）之间，还存在一条漫长且复杂的道路。

真正困难的部分往往不是训练，而是：

部署（Deployment）
监控（Monitoring）
评估（Evaluation）
迭代（Iteration）
运维（Operations）

训练阶段解决的是：

模型能不能工作

生产阶段解决的是：

模型能不能持续稳定地工作

因此，大模型工程本质上不是一次性的训练任务，而是一个持续迭代的系统工程。

从模型到产品

用户实际接触到的 AI 产品，通常不是单独一个模型，而是一套完整系统。

flowchart LR

User

--> App

App

--> Agent

Agent

--> RAG

Agent

--> Tools

Agent

--> LLM

RAG --> KnowledgeBase

Tools --> ExternalSystems

LLM --> Response

用户看到的可能只是：

一个回答

但系统内部往往经历了：

知识检索
工具调用
数据库查询
任务规划
模型推理
结果验证
内容生成

因此当模型进入生产环境后，团队关注的重点会逐渐从：

训练模型

转变为：

运营模型

大模型生产闭环

现代 LLM 系统通常是一个持续迭代循环。

flowchart TD

A[模型训练]

--> B[上线部署]

B --> C[用户使用]

C --> D[日志收集]

D --> E[评估分析]

E --> F[数据构建]

F --> G[SFT/RL训练]

G --> H[模型发布]

H --> B

与传统软件相比，大模型系统最大的特点之一是：

用户反馈本身就是训练数据。

因此模型不会停止学习，而是在生产环境中持续进化。

为什么生产数据最有价值

很多团队花费大量资源收集互联网数据。

但上线后会发现：

最有价值的数据来自真实用户。

例如：

用户：

帮我写一份机器学习工程师简历

模型输出：

质量一般

用户修改：

得到最终满意版本

系统实际上获得了一条高价值样本：

Prompt

↓

模型回答

↓

用户修改

↓

理想回答

相比互联网数据，这类数据：

更贴近业务场景

更反映真实需求

天然包含反馈信号

因此许多领先团队真正的核心资产并不是模型，而是：

持续产生高质量数据的能力。

什么是 Agent

传统 LLM：

Question

↓

Answer

一次输入。

一次输出。

Agent 则不同：

Question

↓

Planning

↓

Tool Use

↓

Observation

↓

Reasoning

↓

Answer

Agent 不只是回答问题，而是主动完成任务。

例如：

查询天气

规划旅行

分析财务数据

自动生成报告

调用外部系统

Agent 的核心组成

现代 Agent 通常包含以下模块：

flowchart LR

User

--> Planning

Planning --> ToolUse

ToolUse --> Observation

Observation --> Planning

Planning --> Memory

Memory --> Planning

Planning --> Response

核心能力包括：

1. Planning（任务规划）
2. Tool Use（工具调用）
3. Memory（长期记忆）
4. Coordination（多任务协调）
5. Reflection（自我修正）

Function Calling

Agent 最基础的能力之一：

Function Calling

例如：

用户：

北京天气怎么样？

模型生成：

{
  "tool":"weather",
  "city":"北京"
}

调用：

weather("北京")

返回：

26℃

最终回答：

北京当前温度约26℃

这里模型本身并不知道天气。

它只是学会了：

什么时候调用工具

调用哪个工具

如何填写参数

Tool Use 训练

训练样本通常如下：

{
  "user":"北京天气",
  "assistant":"<tool_call>weather('北京')</tool_call>"
}

通过 SFT 训练后，模型逐渐学会：

工具选择

参数构造

调用格式

结果整合

最终形成可靠的工具使用能力。

RL for Tool Use

SFT 只能模仿工具调用。

RL 可以进一步优化工具使用效率。

例如奖励设计：

工具调用成功 +1

参数正确 +1

结果有效 +1

调用失败 -1

参数错误 -1

无效调用 -1

模型逐渐学习：

减少无意义调用

提高调用成功率

降低执行成本

Training for Planning

更高级的 Agent 需要具备规划能力。

例如：

用户：

帮我规划东京五日游

模型无法直接回答。

需要先拆解任务：

步骤1 查询景点

步骤2 查询酒店

步骤3 查询交通

步骤4 安排行程

步骤5 输出计划

训练数据通常为：

Question

↓

Plan

↓

Execution

↓

Answer

训练流程：

flowchart TD

Task

--> Plan

Plan --> Execute

Execute --> Observe

Observe --> FinalAnswer

Live Agent

生产环境中的 Agent 与普通模型最大的区别：

状态实时更新。

普通 LLM：

知识截止于训练时间

Agent：

实时获取信息

例如：

用户：

今天黄金价格是多少？

模型本身无法知道。

Agent 则会：

flowchart LR

Question

--> Search

--> Context

--> LLM

--> Answer

通过实时查询获取最新结果。

RAG（检索增强生成）

RAG 的核心思想：

外部知识

↓

检索

↓

加入 Context

↓

模型生成

例如：

用户：

最新 OpenAI 新闻

系统流程：

搜索新闻

↓

检索结果

↓

加入 Prompt

↓

生成回答

RAG 解决的问题

RAG 最适合：

最新新闻

企业知识库

内部文档

数据库信息

私有知识

RAG 解决的是：

知识更新

而不是：

能力学习

需要学习新能力时：

SFT

RL

继续训练

通常更加有效。

Serving Architecture（生产推理架构）

一个典型的大模型线上服务架构如下：

flowchart LR

Client

--> Gateway

Gateway

--> Router

Router

--> LLMServing

LLMServing

--> ToolSystem

LLMServing

--> VectorDB

VectorDB

--> KnowledgeBase

主要组件：

API Gateway

负责：

认证

限流

日志

监控

Router

负责：

模型选择

流量分发

A/B测试

灰度发布

LLM Serving

负责：

推理服务

KV Cache

批处理

并发管理

Vector Database

负责：

Embedding存储

语义检索

知识召回

生产数据的重要来源

上线以后最宝贵的数据：

真实用户数据

训练循环：

flowchart TD

Users

--> Logs

--> Filtering

--> TrainingData

--> FineTune

--> Deploy

数据决定模型的上限。

生产环境决定数据的质量。

用户反馈驱动训练

例如：

用户：

答案错误

记录：

Prompt

Bad Output

Correct Output

形成：

SFT数据

Preference数据

RL数据

用户每一次交互都可能成为下一代模型的训练样本。

为什么 AI 系统进步越来越快

传统软件：

发布

↓

用户反馈

↓

人工开发

↓

再次发布

AI 系统：

用户使用

↓

自动收集数据

↓

自动评估

↓

自动构建训练集

↓

自动训练

↓

重新部署

形成持续的数据飞轮。

Data Hygiene（数据卫生）

生产日志不能直接用于训练。

必须进行清洗。

1. Quality Filtering

过滤：

垃圾数据

无意义数据

恶意输入

异常输出

2. De-duplication

去重：

重复问题

重复回答

模板化数据

3. Bias Detection

检查：

性别偏见

地域偏见

文化偏见

政治偏见

4. Privacy Scrubbing

删除：

手机号

邮箱

身份证

住址

银行卡

流程：

flowchart TD

RawLogs

--> QualityFilter

--> Dedup

--> BiasCheck

--> PrivacyScrub

--> TrainingData

LLMOps：大模型工程化

随着模型进入生产环境，工程能力变得越来越重要。

LLMOps 可以理解为：

MLOps

↓

LLMOps

关注：

Prompt管理

模型管理

数据管理

评测管理

发布管理

版本管理

生产环境必须固定：

模型版本

Prompt版本

Tokenizer版本

数据版本

否则：

结果不可复现

自动评测

每次发布前都需要自动验证：

正确率

工具调用率

推理能力

安全性

幻觉率

形成持续评测流水线。

灰度发布与回滚

上线新模型时：

不要直接全量替换。

推荐：

90% 老模型

10% 新模型

观察：

满意度

错误率

成本

延迟

若出现问题：

立即回滚

紧急修复怎么办

很多团队第一反应：

重新训练

实际上这是最慢的方法。

优先级：

Prompt 修改

分钟级

RAG 更新

小时级

微调

天级

RL

周级

经验原则：

先修系统

再修模型

经验总结

监控与观测（Observability）

生产环境最重要的部分之一。

如果无法观测：

就无法优化

监控指标

成本

GPU成本

Token成本

API成本

性能

QPS

Latency

TTFT

TPOT

质量

Accuracy

User Satisfaction

Hallucination Rate

Tool Success Rate

监控体系：

flowchart LR

Requests

--> Metrics

Metrics --> Dashboard

Dashboard --> Alerts

A/B Testing

新模型上线前：

不要直接替换旧模型。

流程：

90% 老模型

10% 新模型

比较：

点击率

满意度

任务完成率

错误率

成本

flowchart TD

Traffic

--> ModelA

Traffic

--> ModelB

ModelA --> Metrics

ModelB --> Metrics

Metrics --> Compare

常见训练工具

微调

• Hugging Face PEFT
• LLaMA Factory
• Unsloth

RL

• Hugging Face TRL
• Unsloth
• VeRL

推理框架

• vLLM
• SGLang
• TensorRT-LLM

模型规模如何选择

经验原则：

从小模型开始验证。

例如：

7B
↓
14B
↓
32B
↓
70B

优先验证：

数据

流程

业务价值

最后再扩大模型规模。

显存估算

经验公式：

参数量 × 精度

7B 模型：

量化（Quantization）

常见格式：

FP32

BF16

FP16

INT8

INT4

Q4_K_M

典型流程：

训练

↓

评测

↓

量化

↓

部署

量化的核心目标：

降低显存

提高吞吐

降低成本

知识蒸馏（Distillation）

核心思想：

Teacher

↓

生成高质量数据

↓

Student学习

↓

更小模型

flowchart LR

Teacher

--> SyntheticData

--> Student

目标：

更低成本

更低延迟

接近教师模型效果

多模型路由

不同模型负责不同任务。

flowchart TD

Request

--> Router

Router --> SmallModel

Router --> CodingModel

Router --> ReasoningModel

例如：

简单问答 → 小模型

代码生成 → Coding模型

复杂推理 → Reasoning模型

实现：

成本最优

效果最优

多 LoRA 服务

一个基础模型：

Llama

+
Medical LoRA

+
Law LoRA

+
Coding LoRA

动态加载：

不同领域

不同客户

不同场景

降低部署成本。

推理优化

推理阶段最重要的技术之一：

KV Cache

作用：

避免重复计算历史Token

收益：

降低延迟

提高吞吐

减少计算量

现代推理框架几乎都会深度优化 KV Cache。

生产环境上线检查清单

模型

• 模型版本固定
• Tokenizer固定
• Prompt固定

配置

• 可复现训练配置
• 超参数记录完整
• 数据版本记录完整

发布

• 更新流程
• 回滚流程
• 灰度发布方案
• A/B测试方案

监控

• Token消耗
• GPU利用率
• 延迟监控
• 错误率监控
• 幻觉率监控

数据闭环

• 用户反馈系统
• 日志系统
• 数据清洗系统
• 自动评测系统
• 再训练流程

基础设施

• GPU正常
• 内存正常
• 网络正常
• 存储正常
• 备份正常

总结

从预训练到生产环境，大模型的发展路径并不是一条线性的流程，而是一个持续循环的系统：

数据

↓

训练

↓

评测

↓

部署

↓

用户反馈

↓

数据

↓

再训练

因此，大模型工程的本质并不仅仅是训练出一个强大的模型。

真正优秀的团队，构建的是一个能够持续产生数据、持续优化模型、持续创造价值的闭环系统。

模型只是起点，持续迭代才是真正的竞争力。