从技术名词堆积到知识图谱：如何建立自己的大模型技术体系

前言

刚开始接触大模型领域时，很容易遇到这样一种情况：

Transformer、RoPE、RMSNorm、GQA、MoE、Pre-training、SFT、LoRA、RLHF、DPO、GRPO、KV Cache、量化、RAG、Agent、MCP......

每个名词单独搜索，似乎都能找到大量资料；每一个概念单独学习，好像也都能够理解。但学得越多，反而越容易产生一个问题：

这些技术之间到底是什么关系？它们在整个大模型技术体系中分别处于什么位置？

例如：

RoPE 和 GRPO 显然都是大模型技术，但二者有什么关系？
Tokenization 到底属于数据处理还是模型的一部分？
KV Cache 为什么经常和推理优化、部署一起出现？
量化和剪枝属于模型技术还是部署技术？
Context Length Extension 到底是一项具体技术，还是一种能力目标？
RAG、Agent 和模型内部的 Transformer 又是什么关系？

如果只是按照"遇到一个概念，就学习一个概念"的方式进行，最终很容易形成大量孤立的知识点：

复制代码

RoPE        GRPO        KV Cache

LoRA        GQA         Quantization

RAG         Agent       MoE

因此，在深入具体技术之前，我更希望首先建立一张大模型技术地图。以后每接触一个新的概念，不是简单地在笔记里增加一个新的标题，而是首先思考：

它在整个大模型技术体系中处于什么位置？为什么会出现？解决什么问题？和已经学过的哪些技术存在关系？

随着学习不断深入，这张地图可以不断增加新的节点和连接，最终形成属于自己的大模型技术知识图谱。

为什么简单的"大模型技术树"并不够？

最开始，一个非常自然的想法是将大模型技术简单划分为：

复制代码

大模型技术
│
├── Data
├── Model
├── Training
├── Inference
├── System
└── Application

这种划分非常直观，但仔细思考会发现一个问题：这些一级节点的划分依据并不完全一致。

例如：

复制代码

Data          → 按研究对象划分
Model         → 按模型结构划分
Training      → 按模型生命周期划分
Inference     → 按模型执行阶段划分
Systems       → 按计算系统问题划分
Application   → 按最终使用方式划分

它们虽然能够把大部分技术"装进去"，但并不是严格处于同一个分类维度。尤其当遇到一些跨领域技术时，这种问题会更加明显。例如 Long Context（长上下文） 。如果把它放进 Architecture，那么长上下文训练怎么办？如果放进 Training，那么 RoPE Scaling、KV Cache Optimization 又怎么办？再比如 Multimodal（多模态）。它既涉及 Vision Encoder、Projector 等模型架构，又涉及多模态数据、多模态预训练和 SFT。

这说明：

大模型技术本身并不适合被强制压缩成一棵严格互斥的树。

更合理的方式，是从不同的观察维度建立多个相互连接的坐标系。

从"一棵树"转向"三个观察维度"

这里尝试使用三个相互补充的视角组织大模型知识：

复制代码

                    LLM Knowledge Graph
                            │
          ┌─────────────────┼─────────────────┐
          ↓                 ↓                 ↓
   Core Technology       Capability      LLM-based Systems
      核心技术              能力目标            上层系统
          │                 │                 │
     它是什么技术？      它解决什么问题？      如何组合 LLM？

三个维度分别回答三个问题：

Core Technology

这项技术主要作用在大模型的什么位置？

例如：

RoPE → Architecture
GRPO → Training
KV Cache → Inference
Quantization → Systems

Capability

这项技术最终试图获得或增强什么能力？

例如：

Long Context
Reasoning
Multimodal
Coding
Tool Use

LLM-based Systems

如何将 LLM 与外部知识、工具和软件组件组合起来完成复杂任务？

例如：

RAG
Agent
Memory
MCP
Workflow

这三个维度不是互相排斥的分类，而是从不同角度观察同一个技术节点。

LLM Core Technology------技术本身作用在哪里？

首先考虑大模型本身涉及哪些核心技术问题。可以建立如下主干：

复制代码

LLM Core Technology
│
├── Data
│
├── Architecture
│
├── Training
│
├── Adaptation
│
├── Inference
│
└── Systems

它们大致回答：

技术域	主要问题
Data	模型学习什么？
Architecture	模型内部如何设计？
Training	模型参数如何学习？
Adaptation	已有模型如何适配新的任务？
Inference	训练好的模型如何产生输出？
Systems	如何利用真实计算资源高效训练和运行模型？

下面分别展开。

Data：模型学习什么？

任何大模型首先都建立在数据之上。随着模型规模不断增加，"准备数据"本身已经形成了一整套技术体系：

复制代码

Data
│
├── Data Acquisition
├── Data Cleaning
├── Deduplication
├── Data Filtering
├── Data Mixture
├── Data Sampling
├── Synthetic Data
│
└── Data Representation
    └── Tokenization

Data 研究的核心问题可以概括为：

应该让模型学习什么数据，以及如何把原始数据变成适合模型学习的数据？

例如：

如何去除重复文本？
如何过滤低质量内容？
代码、数学、自然语言数据应该如何配比？
是否需要使用合成数据？
原始文本如何转换为 Token？

Tokenization 应该放在哪里？

Tokenization 是一个很典型的边界案例。其基本过程是：

复制代码

Raw Text
   ↓
Tokenizer
   ↓
Token
   ↓
Token ID
   ↓
Embedding
   ↓
Transformer

因此，Tokenization 可以主要放在：

复制代码

Data
└── Data Representation
    └── Tokenization

但它同时与模型架构中的 Embedding 存在直接关系：

复制代码

Tokenization
     │
     └──────→ Vocabulary Size
                    │
                    ↓
             Embedding Layer
                    │
                    ↓
               Architecture

这说明技术知识图谱中，一个节点可以拥有主要归属，同时与其他技术域建立横向连接。

Architecture：模型内部如何设计？

Architecture 研究的是：

大模型本身应该具有怎样的计算结构？

现代 LLM 大多建立在 Transformer 及其大量变体之上，因此可以继续展开：

复制代码

Architecture
│
└── Transformer
    │
    ├── Attention
    │   ├── MHA
    │   ├── MQA
    │   └── GQA
    │
    ├── Position Representation
    │   ├── Absolute Position
    │   ├── RoPE
    │   └── ALiBi
    │
    ├── FFN
    │
    ├── Normalization
    │   ├── LayerNorm
    │   └── RMSNorm
    │
    ├── Activation
    │   ├── GELU
    │   └── SwiGLU
    │
    └── Dense / MoE

这样，当第一次遇到 RoPE 时，就不再只记录：

RoPE 是一种旋转位置编码。

而是首先建立它的技术坐标：

复制代码

LLM
 ↓
Architecture
 ↓
Transformer
 ↓
Position Representation
 ↓
RoPE

以后继续学习：

复制代码

RoPE
 ↓
RoPE Scaling
 ↓
Position Interpolation
NTK-aware Scaling
YaRN
...

新的知识就会自然地生长在已有节点上。

Training：模型如何学习？

有了数据和模型结构之后，需要通过训练得到模型参数。Training 关注：

如何利用数据和优化算法，使模型学习到需要的能力？

可以大致划分为：

复制代码

Training
│
├── Pre-training
│
└── Post-training
    │
    ├── SFT
    │
    ├── Preference Optimization
    │   └── DPO
    │
    └── Reinforcement Learning
        ├── PPO
        └── GRPO

这时候就可以非常清楚地区分：

复制代码

RoPE
→ Architecture
→ 改变模型的位置表示方式

GRPO
→ Training
→ 改变模型后训练阶段的优化方式

二者虽然都属于"大模型技术"，但解决的是完全不同的问题。在已有学习资料中，DPO 被放在 Policy Model 与 Reference Model 的训练流程中进行介绍，而 PPO、DPO、GRPO 也被作为不同后训练方法进行比较，因此这些概念放入 Training / Post-training 这一分支是比较自然的。

Adaptation：已有模型如何适配新的需求？

现实中并不是每一次都需要从零训练一个模型。更多情况下，我们已经拥有一个预训练模型，希望让它以较低成本适应特定领域或任务。于是产生：

复制代码

Adaptation
│
├── Full Fine-tuning
│
└── PEFT
    │
    ├── LoRA
    ├── QLoRA
    ├── Adapter
    └── Prefix / Prompt Tuning

例如 LoRA 的主要技术坐标可以表示为：

复制代码

LLM
 ↓
Adaptation
 ↓
PEFT
 ↓
LoRA

需要注意的是，Adaptation 与 Post-training 存在明显交叉。因此，这里将 Adaptation 单独列出更多是为了突出"如何高效适配已有模型"这一独立研究问题，而不是认为它与 Training 存在绝对边界。

Inference：模型训练好了，不就是直接 Forward 吗？

这是一个很值得思考的问题。对于普通分类模型：

复制代码

Input
  ↓
Model
  ↓
Output

模型结构和参数确定以后，一次 Forward 通常就可以得到结果。但自回归 LLM 有一点不同。模型的一次 Forward 通常得到的是：

下一个 Token 的概率分布。

完整文本需要不断重复：

复制代码

Prompt
   ↓
LLM Forward
   ↓
Next-token Distribution
   ↓
选择 Token
   ↓
加入上下文
   ↓
再次 Forward
   ↓
......

因此又产生了一系列生成阶段特有的技术：

复制代码

Inference
│
├── Autoregressive Generation
│
├── Prefill
├── Decode
│
├── Decoding / Sampling
│   ├── Greedy
│   ├── Beam Search
│   ├── Temperature
│   ├── Top-K
│   └── Top-P
│
└── KV Cache

已有学习资料中也分别介绍了 Greedy、Beam Search、Top-K、Top-P 等采样策略，并进一步讨论 KV Cache、Prefill、Decode 等推理过程。因此 Inference 关注的并不是"模型还能不能 Forward"，而是：

一个训练好的自回归模型如何形成最终的生成过程。

Systems：模型"能跑"不等于模型"能部署"

假设现在已经训练好了一个大模型。理论上它已经能够进行推理。但真正部署到 GPU、NPU 或其他硬件环境时，很快就会出现新的问题：

复制代码

模型参数太多
    ↓
显存放不下

请求数量太多
    ↓
吞吐量不足

KV Cache 太大
    ↓
显存不足

多张 GPU
    ↓
模型如何划分？

实际业务
    ↓
延迟 / 成本 / 功耗要求

这时候研究对象已经从模型算法本身转向：

如何利用真实计算资源高效地训练、运行和服务大模型？

因此形成 LLM Systems：

复制代码

Systems
│
├── Training Systems
│   ├── Data Parallel
│   ├── Tensor Parallel
│   ├── Pipeline Parallel
│   └── Expert Parallel
│
└── Inference Systems
    │
    ├── Model Compression
    │   ├── Quantization
    │   ├── Pruning
    │   └── Distillation
    │
    ├── Memory Management
    │   └── KV Cache Optimization
    │
    ├── Batching
    ├── Scheduling
    ├── Distributed Inference
    │
    └── Deployment & Serving
        ├── vLLM
        ├── SGLang
        └── TensorRT-LLM

因此，Deployment 并不能完全代替 Systems。更准确的关系是：

复制代码

                     LLM Systems
                          │
              ┌───────────┴───────────┐
              ↓                       ↓
       Training Systems        Inference Systems
                                      │
                                      ↓
                            Deployment & Serving

一个典型案例：量化应该放在哪里？

假设已经训练好了一个 BF16 模型，但目标设备显存不足：

复制代码

BF16 Model
    ↓
显存 / 算力受限
    ↓
Quantization
    ↓
INT8 / INT4 / FP8 ...
    ↓
降低存储和计算成本
    ↓
Deployment

从主要使用目的来看，可以将其放在：

复制代码

Systems
└── Inference Systems
    └── Model Compression
        └── Quantization

但是进一步学习后又会发现：

复制代码

Quantization
│
├── PTQ
│   └── Post-Training Quantization
│
└── QAT
    └── Quantization-Aware Training

QAT 显然又和 Training 产生了联系。因此，知识图谱不应该强制规定：

"Quantization 只能属于 Systems。"

更合理的做法是：

确定主要技术坐标，同时保留与其他技术节点的关联。

Capability------技术最终在增强什么？

到这里还会遇到另外一类概念：

Long Context
Reasoning
Multimodal
Coding
Tool Use

这些概念和 RoPE、GRPO、KV Cache 并不处于同一个分类维度。

例如 Long Context 描述的首先是：

希望模型能够处理更长的上下文。

这是一个能力目标，而不是一种具体实现技术。因此可以单独建立：

复制代码

LLM Capability
│
├── Knowledge
├── Reasoning
├── Long Context
├── Multimodal
├── Coding
├── Tool Use
└── Agentic Capability

Context Length Extension 为什么不应该强行塞进 Architecture？

这是一个非常典型的例子，实现 Long Context 可能涉及：

复制代码

                        Long Context
                             │
          ┌──────────────────┼──────────────────┐
          ↓                  ↓                  ↓
     Architecture         Training            Systems
          │                  │                  │
     RoPE Scaling      Long-context Data     KV Cache
       YaRN            Context Training      Memory Optimization
 Attention Design                           Efficient Serving

因此：

Context Length Extension 是目标。

而：

RoPE Scaling 是架构层实现技术；
长序列训练是 Training 技术；
KV Cache / Memory Optimization 是 Systems 技术。

例如 RoPE 的主归属仍然是：

复制代码

Architecture
→ Transformer
→ Position Representation
→ RoPE

同时建立横向关系：

复制代码

RoPE / RoPE Scaling ─────→ Long Context

这比简单写：

复制代码

Long Context
└── RoPE

更能体现技术之间的真实关系。

Multimodal 也是同样的道理

Multimodal 不只是某一种模型结构。一个视觉语言模型可能同时涉及：

复制代码

                      Multimodal
                          │
          ┌───────────────┼───────────────┐
          ↓               ↓               ↓
         Data        Architecture       Training
          │               │               │
    Image-Text Data   Vision Encoder   VL Pretraining
                     Projector         Multimodal SFT
                     LLM               Alignment

因此：

Multimodal 更适合作为横向能力/研究主题，而不是和 Architecture、Training 平级的核心技术分类。

这也是为什么研究 Qwen-VL 时，可以同时讨论模型架构、输入输出以及不同训练阶段，而这些内容在总技术图谱中应该分别回到对应技术节点。

LLM-based Systems------如何利用 LLM 与外部组件构建复杂系统？

还有一些技术甚至已经不再主要修改 LLM 本身。

例如：

如何让模型使用企业内部知识？

可以使用 RAG：

复制代码

用户问题
   ↓
Retrieval ─────→ Knowledge Base
   ↓
相关文档
   ↓
Prompt + Context
   ↓
LLM
   ↓
Answer

又例如：

如何让模型调用搜索、数据库、代码执行器等外部工具？

这进一步产生：

复制代码

LLM-based Systems
│
├── RAG
│   ├── Chunking
│   ├── Embedding
│   ├── Retrieval
│   ├── Vector Database
│   └── Reranking
│
├── Agent
│   ├── Planning
│   ├── Memory
│   ├── Tool Use
│   └── Multi-Agent
│
├── Function / Tool Calling
├── MCP
└── Workflow

这些技术研究的已经不是：

Transformer 内部应该怎么设计？

而是：

如何以 LLM 为核心，与外部知识、工具、环境以及软件组件构成一个完整系统？

这也是为什么 RAG 与 RoPE 虽然都属于"大模型领域"，但不应该被简单放在同一级目录中。

从知识树进一步走向知识图谱

到这里可以发现：严格的树状结构仍然存在局限。

例如：

复制代码

GQA
→ Architecture → Attention

但 GQA 同时可能影响：

复制代码

KV Cache Size
→ Inference Efficiency
→ Systems

再比如：

复制代码

RoPE Scaling
→ Architecture

同时又关联：

复制代码

Long Context
→ Capability

因此最终的知识结构更接近：

复制代码

                       Long Context
                            ↑
                            │
Architecture → RoPE → RoPE Scaling
     │
     └── GQA ─────────────→ KV Cache
                              │
                              ↓
                        Inference Systems

也就是说：

树负责确定主要归属，边负责描述技术之间的关系。

这就是从"知识树"进一步走向"知识图谱"。

面对一个陌生技术，应该怎么学习？

基于上面的体系，我更倾向于采用四个步骤：

Step 1：Locate ------ 定位

先不急着研究公式。

首先回答：

它在整个技术体系中的主要位置是什么？

例如：

复制代码

RoPE

Architecture
→ Transformer
→ Position Representation
→ RoPE

Step 2：Understand ------ 理解

然后回答：

它为什么出现？解决什么问题？

例如 RoPE：

复制代码

Transformer
   ↓
需要表示 Token 的相对/位置信息
   ↓
Position Representation
   ↓
RoPE

Step 3：Connect ------ 建立连接

继续寻找它和哪些已有知识相关：

复制代码

RoPE
├── Attention
├── Position Encoding
├── Relative Position
├── Long Context
└── Context Extension

Step 4：Expand ------ 向外扩展

最后继续沿着技术发展：

复制代码

RoPE
 ↓
RoPE Scaling
 ↓
Position Interpolation
NTK-aware Scaling
YaRN
...

于是学习一个概念就不再意味着：

"记住一个新的名词。"

而意味着：

在已有知识网络上增加一个节点和若干条连接。

结语

大模型领域的发展速度非常快，今天可能讨论的是：

复制代码

RoPE
GQA
MoE
RLHF
DPO
GRPO
KV Cache
RAG
Agent

明天还会出现新的模型、新的训练方法和新的系统优化技术。因此，对于刚进入这一领域的学习者来说，也许并不需要一开始就试图"把所有技术学完"。更重要的是先建立一个能够持续扩展的知识坐标系。以后每接触一个新的概念，都尝试回答：

它是什么？

它位于哪里？

它解决什么问题？

它和哪些已有技术存在关系？

然后按照：

复制代码

Locate
  ↓
Understand
  ↓
Connect
  ↓
Expand

不断向外扩展。最终得到的就不再是一堆：

复制代码

RoPE / LoRA / GRPO / KV Cache / RAG / Agent / ...

相互孤立的技术名词，而是一张能够不断生长的大模型技术知识图谱。而这张图本身，也会随着学习不断被修正、补充和完善。

这或许才是建立"大模型技术体系"真正的意义。