AI 学习笔记：AI学习模式 Transformer、RAG、Skill、MCP

摘要

最近在学习大模型相关知识时，发现有几个概念特别容易混：AI 学习模式、Transformer、RAG、Skill、MCP。刚开始看资料时，感觉它们都和"大模型能力增强"有关，但越看越容易混在一起。这篇文章我就把这几个概念重新梳理一遍，整篇会尽量用通俗一点的方式去讲，不绕概念，适合刚开始接触大模型和AI工程化的同学阅读。

一、先说结论：这几个概念其实是分层的

我一开始最容易踩坑的地方，就是把这些概念放在同一个层面理解。后来理顺后发现，它们其实根本不是一层的东西。

可以先看这个总表：

层级	概念	本质	解决的问题
底层方法	AI学习模式	AI怎么从数据中学习能力	模型为什么能学会任务
模型架构	Transformer	大模型的核心骨架	为什么模型能处理长文本、支持大规模训练
知识增强	RAG	给模型外挂知识库	解决幻觉、知识过时、私有知识接入
执行动作	Skill	给模型接工具	解决"只会回答，不会动手"
工程治理	MCP	工具接入和管理标准	解决多模型、多工具、权限和复用问题

一句话记忆就是：

学习模式 决定 AI 怎么学，Transformer 决定 AI 用什么架构学，RAG 解决回答准不准，Skill 解决能不能做，MCP 解决这些工具怎么统一管理。

如果先把这层关系记住，后面就不容易乱了。

二、人工智能的学习模式：AI到底是怎么学会东西的

这个部分其实是最底层的。

很多人一上来就看 RAG、Agent、提示词，学着学着会发现自己知道很多名词，但底层逻辑不扎实。说白了，还是得先搞明白：

AI 的能力到底是怎么来的？

主流学习模式大概可以分成 6 类。

1. 监督学习：有人带着做题

监督学习最好理解，就是训练数据里有"题目"和"标准答案"。

模型通过不断学习输入和输出之间的对应关系，慢慢掌握规律。

例子

比如给模型很多已经打好标签的 SQL：

正常 SQL
慢 SQL

模型学久了，就知道一条新的 SQL 更像哪一类。

常见应用

图像分类
垃圾邮件识别
语音识别
大模型中的 SFT（监督微调）

2. 无监督学习：不给答案，自己归纳

无监督学习就是不给标准答案，让模型自己在数据里找规律。

例子

比如给模型很多运维日志，不告诉它哪些是异常，哪些是正常，它可能会自己把相似的日志聚在一起，把某些少见的模式识别成异常类。

常见应用

聚类
异常检测
用户分群
降维

3. 自监督学习：自己给自己出题

这个概念刚开始看名字会有点绕，但其实是大模型里非常关键的一种学习方式。

它的核心思路是：

不需要人工标注，直接利用原始数据本身生成训练任务。

例子

比如一句话：

复制代码

MySQL 慢查询日志阈值是 ____ 秒

把中间挖空，让模型去预测。

或者给一句话前半部分，让模型猜后半部分。

这类任务不需要人工去一条一条标答案，所以特别适合大规模训练。

为什么大模型离不开它

因为互联网数据太多了，靠人工标注根本不现实。

大模型之所以能学到通用语言能力，很大程度上就是靠自监督学习。

常见应用

GPT 预训练
BERT 预训练
通用语言建模

4. 强化学习：在试错中学会更优解

强化学习就是不断尝试、不断反馈。

做得好就奖励，做得不好就惩罚，最后模型会学会一套"收益最大化"的策略。

例子

这个最经典的例子就是下棋。

每下一步，系统根据输赢给反馈，模型慢慢就能学会更优的落子方式。

在大模型中的作用

大模型后期的对齐阶段经常会用到强化学习，比如 RLHF。

它的目的不是让模型更"懂知识"，而是让模型回答得更符合人类习惯、更安全。

5. 小样本 / 零样本学习：没专门训练，也能做新任务

这是大模型特别厉害的一点。

以前很多任务都得重新训练模型，但现在很多任务只需要给模型一个描述，甚至给几个例子，它就能直接做。

例子

你给模型看几个"慢 SQL 分析案例"，它可能就能模仿这个模式去分析新的 SQL。

常见应用

提示词工程
快速适配新场景
低成本验证任务效果

6. 迁移学习：学会一个，再迁到另一个

迁移学习本质上就是"先学通用能力，再学具体任务"。

例子

模型先通过大规模文本学会语言理解，再迁移到"SQL 审核""日志分析""故障分类"等更具体的任务上。

常见应用

预训练模型微调
行业垂直模型适配
小数据场景建模

Tips：大模型训练不是只用一种学习模式

这个地方特别容易误解。

真实的大模型训练流程，往往是多种学习模式组合起来的：

复制代码

预训练：自监督学习
指令微调：监督学习
对齐优化：强化学习
落地应用：Few-shot + RAG + Skill

所以它们不是互相替代，而是各自负责不同阶段。

三、Transformer：为什么它成了大模型时代的底层基石

如果说前面讲的是"怎么学"，那 Transformer 讲的就是：

模型到底是用什么结构学的，为什么它能突然这么强。

1. Transformer 出现之前，老模型难在哪

在 Transformer 之前，处理文本序列的主流模型主要是：

RNN
LSTM
GRU

这些模型当年确实很重要，但问题也很明显。

问题一：训练效率低

它们处理文本是按顺序一个词一个词来的。

必须先算完前一个，才能继续后一个，不太适合 GPU 并行。

问题二：长文本容易"忘前面"

文本一长，模型就容易记不住开头的重要信息。

比如一大段日志，读到后面的时候，前面的报错上下文可能已经弱化很多了。

2. Transformer 最大的突破是什么

Transformer 最核心的突破，就是引入了 自注意力机制（Self-Attention）。

它带来了两个特别关键的变化：

所有 token 可以并行处理
任意两个位置的 token 都能直接建立联系

这两个点一结合，模型训练速度和长文本理解能力都上来了。

这也是为什么现在大模型几乎都建立在 Transformer 之上。

3. 自注意力机制到底怎么理解

这个概念第一次看确实容易抽象，我当时也觉得很像"数学课"。

后来我发现，把它理解成"读文章时自动抓重点"就顺很多。

比如这条 SQL：

复制代码

SELECT * FROM user WHERE id = 100 AND status = 1;

当模型处理 id 这个词时，它不会只看前后两个词，而是会回头看整句话里跟 id 相关的部分，比如：

WHERE
100
user

这些内容对理解 id 更重要，所以权重会更高。

也就是说，自注意力的本质就是：

模型会自动判断，当前这个词最应该关注整段文本里的哪些词。

4. Q、K、V 到底是什么

这个部分很多文章一上来就甩公式，其实对入门来说没必要先把自己看晕。

先用最简单的方式理解：

名称	可以怎么理解	作用
Q（Query）	当前词想找什么	发起查询
K（Key）	每个词的特征标签	用来匹配
V（Value）	每个词实际携带的信息	用来生成结果

简单流程就是：

当前词拿自己的 Q 去和所有词的 K 做匹配
算出相关程度
分配不同权重
对所有词的 V 做加权汇总
得到当前词更完整的上下文表示

说白了就是：

Q 负责问，K 负责比，V 负责给内容。

5. 多头注意力：从多个角度一起看

单个注意力有时候不够全面，所以 Transformer 里还有一个重要机制叫 多头注意力（Multi-Head Attention）。

可以把它理解成：

同一段内容，不只让一个"观察员"去看，而是让多个"观察员"从不同角度一起看。

比如分析 SQL 时：

一个头看语法结构
一个头看字段关系
一个头看过滤条件
一个头看潜在性能风险

最后再把这些信息合起来，理解会更完整。

6. 标准 Transformer 架构：Encoder + Decoder

原始 Transformer 论文里，模型结构是 Encoder-Decoder。

Encoder 干什么

负责"理解输入"。

Decoder 干什么

负责"生成输出"。

另外还有两个基础部分：

Embedding：把词变成向量
位置编码：告诉模型词的顺序

因为 Transformer 自身不带顺序感知，所以必须额外加上位置信息。

7. 为什么现在主流大模型大多是 Decoder-only

这个点很重要。

现在常见的大语言模型，比如：

GPT
LLaMA
通义千问
ChatGLM

大多不是完整的 Encoder-Decoder，而是 Decoder-only 结构。

为什么这样设计

因为它特别适合做"下一个 token 预测"，而这正是文本生成的核心。

它的特点

保留 Decoder
使用掩码注意力，防止偷看未来信息
更适合大规模预训练
对开放式生成任务更强

Transformer 为什么这么重要

归根结底，是因为它同时具备这几个优势：

能高效并行训练
能处理长距离依赖
适用范围很广，不只是 NLP
很适合扩展参数规模和训练规模

所以可以说，没有 Transformer，就没有后面这波大模型的爆发。

Tips：Transformer 不等于大模型

这个点一定要分清。

Transformer 是一种神经网络架构
大模型是基于这种架构训练出来的大规模参数模型

两者关系更像：

Transformer 是骨架，大模型是成品。

四、RAG：解决大模型"知道得不准、记得不新"

大模型很强，但它有个很现实的问题：

它可能会答得很像真的，但其实不一定对。

这就是大家常说的"幻觉"。

而 RAG，就是解决这个问题的核心方法之一。

1. RAG 到底是什么

RAG 全称是：

Retrieval-Augmented Generation

中文一般翻译成：检索增强生成

它最核心的逻辑特别简单：

先查资料，再组织答案。

也就是说，不让模型只凭自己"记忆"回答，而是先去外部知识库里找相关内容，再根据找到的内容生成回答。

2. RAG 主要解决哪几个问题

① 幻觉问题

模型不知道的时候，也可能硬答。

RAG 的作用就是尽量让它"按资料说话"。

② 知识过时

模型训练数据有时间截止，之后的新知识它并不知道。

但 RAG 的知识库可以持续更新。

③ 私有知识接入

企业文档、内部规范、历史故障案例这些内容，不能随便拿去重新训练模型。

RAG 则可以在不改模型参数的前提下，把这些私有知识接进来。

④ 成本更低

相比微调，RAG 一般更轻、更快，也更适合先做业务验证。

3. 一个标准 RAG 的基本流程

RAG 常见流程一般是下面这几步：

第一步：文档切块

把 PDF、Word、手册、案例文档切成一个个语义相对完整的小块。

第二步：向量化

用 Embedding 模型把文本块转成向量。

第三步：入向量库

把这些向量存进向量数据库里。

第四步：用户提问时做检索

把用户的问题也转成向量，再去知识库里找最相近的内容。

第五步：把检索结果交给大模型生成回答

模型不再"裸答"，而是结合参考内容作答。

4. 举个很典型的例子

假设我们做了一个 MySQL 运维知识库，里面有：

MySQL 官方文档
公司内部部署规范
历史慢查询故障案例
SQL 优化经验

用户现在问：

"3307 端口实例的慢查询日志标准配置是什么？有没有类似故障案例？"

没有 RAG

模型可能只会给你一个通用答案，而且不一定真符合你的业务环境。

有 RAG

系统会先查你自己的知识库，找到相关配置文档和故障案例，再组织出更准确的回答。

这时候模型说的就不是"印象流"，而是"有依据的内容"。

5. 一个简化版 RAG 示例

复制代码

query = "3307 实例慢查询日志标准配置是什么？"

docs = vector_db.search(query, top_k=3)

prompt = f"""
请严格根据以下资料回答问题，不允许编造：

参考内容：
{docs}

问题：
{query}
"""

answer = llm.generate(prompt)
print(answer)

虽然这是个伪代码，但思路很清楚：

先检索，再生成。

Tips：RAG 不等于"装个知识库就完了"

这个也是特别容易踩的坑。

RAG 最终效果好不好，不只取决于模型本身，还很看下面这几个点：

文档质量好不好
切块是否合理
检索是否准确
Prompt 约束是否清楚

所以很多时候，RAG 做不好，不是模型不行，而是知识库和检索链路没调好。

五、Skill：让大模型不只是会说，还能做事

如果说 RAG 解决的是：

模型说得准不准

那 Skill 解决的就是：

模型能不能真的动手干活

1. Skill 是什么

Skill 可以理解成：

给大模型外挂的一个"工具能力"。

因为大模型原生最强的是文本生成，但很多事情它本身做不了，比如：

精准计算
读数据库
调监控接口
执行脚本
查系统状态
修改配置文件

这时候就需要给它接外部工具，这些工具能力就可以统称为 Skill。

2. Skill 解决了什么问题

大模型原生很像一个"特别会说的人"，但它不一定能直接去操作外部系统。

比如你问它：

当前服务器 CPU 使用率是多少？
今天慢查询 Top10 是哪些？
某个端口有没有监听？
帮我执行一下这个脚本看看有没有报错？

这些都不是靠"语言能力"能解决的，而是需要实际去查、去执行。

这就是 Skill 的作用。

3. Skill 的基本工作流程

Skill 的逻辑可以总结成一句话：

模型做决策，工具做执行。

完整过程一般是：

用户提出问题
模型判断要不要调用工具
模型生成调用参数
Skill 执行具体动作
返回执行结果
模型把结果整理成自然语言回复

4. 几个很常见的 Skill 场景

场景一：数据库查询

比如用户说：

帮我查一下 3307 实例今天超过 2 秒的慢 SQL，按执行时长排序

这时模型就可以调用 MySQL 查询 Skill。

场景二：日志分析

比如上传一个慢日志文件，让模型分析 Top10 慢 SQL 并给出优化建议。

这时可以调用日志分析 Skill 去解析文件、统计数据、输出结果。

场景三：代码执行

比如模型帮你写了一个 Shell 脚本，但你不确定能不能跑。

这时可以调用代码执行 Skill 先跑一遍，看报错，再继续修。

场景四：系统排查

比如你问：

3307 实例进程还在不在？端口监听了吗？

这时模型可以调用系统命令 Skill 去检查。

5. 一个简单的 Skill 代码示例

复制代码

def query_slow_sql(instance_port: int, threshold: int = 2):
    sql = f"""
    SELECT sql_text, query_time
    FROM slow_log
    WHERE instance_port = {instance_port}
      AND query_time > {threshold}
    ORDER BY query_time DESC
    LIMIT 10;
    """
    return execute_sql(sql)

模型如果判断这个工具适合当前任务，就可以构造参数去调用，比如：

复制代码

{
  "instance_port": 3307,
  "threshold": 2
}

然后拿到结果，再用自然语言整理成最终回答。

Skill 的核心价值

能力	只有模型	模型 + Skill
查实时数据	不行	可以
精准执行命令	不行	可以
操作数据库	不行	可以
调外部 API	不行	可以
完成多步任务	有局限	更强

所以 Skill 的核心意义很明确：

它让模型从"只会回答"变成"可以执行任务"。

六、MCP：它不是工具，而是工具的统一规则

学到 Skill 之后，很多人又会有一个疑问：

既然 Skill 已经能调用工具了，那 MCP 又是干嘛的？

这是一个特别容易混的点。

1. 先说结论：MCP 不是 Skill

一句话理解：

Skill 是具体干活的工具，MCP 是管理这些工具的协议标准。

也就是说，MCP 自己不负责查数据库、不负责执行命令，它负责的是：

工具怎么被模型发现
工具怎么统一描述
工具怎么安全调用
多模型之间怎么复用这些工具

2. 用类比理解最直观

生活里的类比

Skill：冰箱、洗衣机、空调
MCP：智能家居协议

电器本身负责干活，但协议负责让这些设备能统一接入系统。

后端里的类比

Skill：一个个微服务
MCP：服务治理框架 + 统一接口标准

所以 MCP 不是替代 Skill，而是让 Skill 更容易管理、更容易复用。

3. Skill 和 MCP 的区别

对比维度	Skill	MCP
本质	单个执行工具	工具接入协议/标准
是否干具体业务	是	否
是否直接执行动作	是	否
主要作用	让模型能做事	让工具更标准化、更可管理
适用规模	小规模也能用	更适合多工具、多模型、企业级场景

4. 为什么会需要 MCP

如果只是自己本地写几个小工具，直接用 Function Call 也没什么问题。

但如果到了真实项目里，问题就来了：

问题一：不同模型工具格式不统一

给 GPT 写的工具，不一定能直接给别的模型用。

问题二：工具越来越多，不好维护

每新增一个工具，都要在不同模型侧重复配置。

问题三：权限和审计难做

谁能调用什么工具、有没有越权、调用记录能不能追踪，这些都很重要。

问题四：企业内网工具接入麻烦

数据库、监控平台、运维系统这些一般都在内网里，不能随便暴露。

MCP 的价值，恰好就是解决这些工程化问题。

Tips：什么时候用 Skill 就够了，什么时候需要 MCP

只用 Skill 就够的场景

自己做学习 Demo
单模型调用
工具数量不多
不涉及复杂权限

更适合上 MCP 的场景

多模型接入
工具体系越来越多
有权限控制和审计要求
有企业内网系统
想做标准化和长期维护

七、这些东西在实际项目里怎么一起工作

学概念最怕一件事：

每个词都懂了，但不知道在项目里它们到底怎么配合。

这里可以看一个完整一点的场景。

场景：做一个智能运维助手

用户提问：

"3307 实例今天出现了大量慢查询，帮我排查原因，给出优化建议，并把结论补充进知识库。"

看起来是一句话，但背后其实可能是几层能力一起配合。

第一步：用 Skill 获取实时数据

先调用各种工具：

拉取慢日志
查实例配置
查监控指标
检查系统状态

这些都属于 Skill 负责的部分。

第二步：用 RAG 检索历史经验和规范

再去知识库里找：

历史类似故障案例
SQL 优化规范
参数配置建议
运维手册

这些属于 RAG 负责的部分。

第三步：模型综合生成分析结论

模型把：

Skill 获取的实时数据
RAG 检索到的知识内容

结合起来，输出一份比较完整的分析报告。

第四步：通过 Skill 更新知识库

如果系统支持写入能力，还可以再调用文档写入类 Skill，把这次排查结论同步回知识库。

第五步：如果工具很多，就交给 MCP 统一管理

当工具越来越多、场景越来越复杂时，就可以用 MCP 来统一管理这些 Skill：

模型自动发现工具
权限控制更清晰
多模型复用更方便
审计和安全更规范

所以它们的关系其实很清楚

可以用一句话总结：

学习模式 决定模型能力从哪里来
Transformer 决定模型底层怎么搭
RAG 决定模型说话更有依据
Skill 决定模型能不能真正做事
MCP 决定这些工具怎么被标准化管理

八、几个特别容易混淆的点

误区 1：Transformer 就是大模型

不是。

Transformer 是模型架构，

大模型是基于这种架构训练出来的大规模模型。

误区 2：RAG 就是微调

不是。

微调：改模型参数
RAG：不改模型参数，外挂知识库

两者都是增强模型能力，但方式完全不同。

误区 3：Skill 和 MCP 没区别

也不是。

Skill 是具体工具
MCP 是工具接入和管理标准

一个负责干活，一个负责管规则。

误区 4：有了 RAG 就不会幻觉

不一定。

如果检索召回不准、文档质量不好，模型还是可能答偏。

所以 RAG 效果不仅看模型，更看知识库和检索链路。

误区 5：这些概念都属于同一层

这是最常见的误区。

其实它们横跨了：

学习方法
模型架构
知识增强
工具执行
工程治理

把层次分清楚，理解会轻松很多。

九、总结

这篇文章内容比较多，最后我用最短的话再收一遍。

一句话总结

AI学习模式：AI 怎么学会能力
Transformer：大模型为什么能这么强
RAG：让模型回答更准确、更贴近业务知识
Skill：让模型能查、能算、能执行
MCP：让工具体系更标准化、更适合工程落地

最适合记忆的一句话

复制代码

学习模式决定怎么学，
Transformer决定怎么建，
RAG决定说得准不准，
Skill决定能不能做，
MCP决定工具怎么统一管。

我的建议

如果你现在也在学大模型，先把底层顺序理顺：

复制代码

学习模式 -> Transformer -> 大模型原理 -> RAG -> Skill -> MCP

按这个顺序去学，会比东一块西一块地看资料清楚很多。

AI 学习笔记：AI学习模式 Transformer、RAG、Skill、MCP

目录

一、先说结论：这几个概念其实是分层的

二、人工智能的学习模式：AI到底是怎么学会东西的

1. 监督学习：有人带着做题

例子

常见应用

2. 无监督学习：不给答案，自己归纳

例子

常见应用

3. 自监督学习：自己给自己出题

例子

为什么大模型离不开它

常见应用

4. 强化学习：在试错中学会更优解

例子

在大模型中的作用

5. 小样本 / 零样本学习：没专门训练，也能做新任务

例子

常见应用

6. 迁移学习：学会一个，再迁到另一个

例子

常见应用

Tips：大模型训练不是只用一种学习模式

三、Transformer：为什么它成了大模型时代的底层基石

1. Transformer 出现之前，老模型难在哪

问题一：训练效率低

问题二：长文本容易"忘前面"

2. Transformer 最大的突破是什么

3. 自注意力机制到底怎么理解

4. Q、K、V 到底是什么

5. 多头注意力：从多个角度一起看

6. 标准 Transformer 架构：Encoder + Decoder

Encoder 干什么

Decoder 干什么

7. 为什么现在主流大模型大多是 Decoder-only

为什么这样设计

它的特点

Transformer 为什么这么重要

Tips：Transformer 不等于大模型

四、RAG：解决大模型"知道得不准、记得不新"

1. RAG 到底是什么

2. RAG 主要解决哪几个问题

① 幻觉问题

② 知识过时

③ 私有知识接入

④ 成本更低

3. 一个标准 RAG 的基本流程

第一步：文档切块

第二步：向量化

第三步：入向量库

第四步：用户提问时做检索

第五步：把检索结果交给大模型生成回答

4. 举个很典型的例子

没有 RAG

有 RAG

5. 一个简化版 RAG 示例

Tips：RAG 不等于"装个知识库就完了"

五、Skill：让大模型不只是会说，还能做事

1. Skill 是什么

2. Skill 解决了什么问题

3. Skill 的基本工作流程

4. 几个很常见的 Skill 场景

场景一：数据库查询

场景二：日志分析

场景三：代码执行

场景四：系统排查

5. 一个简单的 Skill 代码示例

Skill 的核心价值

六、MCP：它不是工具，而是工具的统一规则

1. 先说结论：MCP 不是 Skill

2. 用类比理解最直观

生活里的类比

后端里的类比

3. Skill 和 MCP 的区别

4. 为什么会需要 MCP

问题一：不同模型工具格式不统一

问题二：工具越来越多，不好维护

问题三：权限和审计难做

问题四：企业内网工具接入麻烦