7天从零跑通AI大模型：Transformer到Agent实战路径

先说结论：7天从零学会AI大模型这件事，把“学会”拆开看是成立的，把“学精”放进去就不成立。Transformer、预训练、微调、提示工程、RAG、Agent 这六个词，七天时间足够让一个会写 Python 的人把整条链路各跑通一遍，知道每一环解决什么问题、输入输出长什么样、哪一步最容易出问题；但七天不足以让你训出一个能打的基座模型，也不足以让你在真实业务数据上把 RAG 的召回率调到满意。这个判断很重要，因为大部分人卡住不是因为某个概念太难，而是因为一开始的目标定错了——把“跑通”当成“掌握”，跑到第三天发现微调效果不如预期就开始怀疑自己。

下面这套安排更适合这样一类读者：有基本编程能力，能看懂 Python 函数和命令行，知道什么是 HTTP 接口，但对注意力机制、LoRA、向量检索这些名词只有模糊印象。如果你是纯小白但又愿意动手敲代码，也能跟上，只是前两天会慢一些。真正值得关注的不是标题里的年份标签，而是这六个环节之间依赖关系和先后顺序——顺序错了，你会发现每天都在重新理解前一天的东西。

1. 先把“7天学会AI大模型”拆成一个能执行的目标

1.1 七天能做到什么，哪些预期要提前打折

我必须先把预期校准，否则后面每一步都会走得很别扭。

七天里能达成的，大致是这三件事：第一，能把 Transformer 的核心计算——注意力——用代码写出来并跑通，理解张量形状怎么变化；第二，能基于开源模型做一次轻量微调，知道数据格式、训练参数、显存占用之间的关系；第三，能搭一条完整的 RAG 问答链路和一个小型 Agent，知道每一环在什么地方会断。

七天里不太可能达成的，也得说清楚：你不可能从零预训练一个可用的语言模型。预训练是一个和算力强绑定的工程，个人环境基本不具备条件，这个话题的正确学法是“理解它在做什么、成本结构是什么”，而不是“亲手做一遍”。同样，你也不太可能一次就把微调调到业务可用，因为微调效果很大程度上取决于数据质量，而数据清洗往往比训练本身更花时间。

标题里那种“从底层原理到企业级项目实战”的表述，我的理解是：底层原理指的是张量和梯度这一层，企业级实战指的是有异常处理、有日志、有失败重试的那一套工程约束。中间那段“从原理直接跳到企业级”的落差，才是七天里真正需要花时间补的部分。

所以我把每天的目标定成“可验证的小结果”，而不是“学完某个章节”。判断标准很直接：当天结束时，你能不能对着终端或浏览器说出“这条链路跑通了，输入是什么，输出是什么，日志在哪”。说不出来，就说明当天还停在看资料的阶段。

1.2 这条路径适合谁，什么情况下应该换路子

有三类人特别适合按这个节奏走。

第一类是想转型但没方向的开发者。你可能做后端、做前端、做数据，日常工作和大模型没有直接交集，但需要知道这套东西能干什么、边界在哪。七天跑完之后，你至少能和算法同学对上话，知道他们说的“召回不行”和“上下文超了”分别指什么。

第二类是产品和技术管理岗。你不需要亲手写训练脚本，但需要判断一个需求是“提示词改改就行”还是“得做微调”，是“接个接口”还是“得搭 RAG”。这类人可以在代码环节少花时间，把精力放在第 5、6 两天的链路理解上。

第三类是学生和自学者。有时间、有机器、愿意折腾，这套路径给出的顺序能省掉大量“先学哪个”的犹豫。

不适合的情况也要说。如果你完全没有编程基础，七天会非常赶，建议拉到三周，把 Python 和基础线性代数补一补再进来。如果你的机器只有集成显卡、内存 8G 以内，微调和本地模型推理会非常吃力，这种情况更适合把第五、六天提前，因为 RAG 和 Agent 对本地算力的要求低得多，用接口型的模型服务就能跑通。

还有一个现实问题：不要为了“七天”这个数字硬赶进度。我见过太多人第三天卡在注意力实现上就放弃了，其实完全可以先跳过手写实现，用现成库跑通再说。学习路径是给人用的，不是用来考核的。

1.3 七天的时间怎么分配，才不至于每天都在切换概念

时间分配上，我建议按“2 + 2 + 1 + 1 + 1”来切，而不是平均分。

这个分配背后的逻辑是：前四天是“理解 + 动手”，中间一天是“控制输入输出”，后两天是“组装”。第五天的提示工程看着简单，但它其实是第六、七天的地基——RAG 的生成环节、Agent 的决策环节，本质都是提示词在起作用。如果第五天没有建立起“提示词是可以被系统性验证的”这个意识，后面两天会变成到处试咒语。

另外提醒一句，第 3 天安排的预训练内容刻意压缩了，因为它更适合“读懂”而不是“做通”。很多教程把它放在很重的位置，导致新手以为必须自己预训练才算学会大模型，这是误解。理解预训练的目标函数和数据规模量级，比亲手跑一遍更有价值。

2. 第一天到第二天：把 Transformer 从结构图变成能跑的张量

2.1 先搞清注意力到底在算什么，别急着背结构图

大部分人学 Transformer 的第一个坑，是一上来就去看那张“编码器-解码器堆叠”的大图，记住了一堆名词，但不知道任何一个矩阵乘法的意义。这个顺序是反的。

正确的切入点是注意力就是一个加权求和。你手里有一组查询向量，一组键向量，一组值向量。查询和键做点积，得到“相关程度”；相关程度归一化后变成权重；权重乘上值向量再求和，就是输出。整套机制要解决的问题是：处理当前这个词的时候，应该参考上下文里的哪些词、参考多少。

理解这一点之后，多头注意力就不神秘了——无非是把这个过程并行做几次，每次用不同的投影矩阵，让模型同时关注不同类型的关系，最后拼接起来。残差连接和层归一化也不是玄学，它们解决的是深层网络训练中的梯度传播和数值稳定性问题。

位置编码则是另一个常见困惑点。注意力本身对顺序是不敏感的，打乱词序结果一样，所以必须额外注入位置信息。具体用哪种编码方式，不同模型选择不同，落地时以你用的模型实现为准就行，不必在第一天就纠结细节。

我建议第一天只做一件事：把单头注意力的公式对应到代码上，确保你能说出每一步的输入形状和输出形状。这是后面所有内容的地基。

2.2 用几十行代码跑通一个最小注意力模块

下面这段是示例代码，用来说明形状流转，不是某个框架的官方实现。实际落地时以你所用框架的接口为准。

python复制import torch
import torch.nn.functional as F

def scaled_dot_product_attention(q, k, v, mask=None):
    # q: (batch, heads, seq_len, dim)
    # k: (batch, heads, seq_len, dim)
    # v: (batch, heads, seq_len, dim)
    d_k = q.size(-1)
    scores = torch.matmul(q, k.transpose(-2, -1)) / (d_k ** 0.5)
    if mask is not None:
        scores = scores.masked_fill(mask == 0, float("-inf"))
    weights = F.softmax(scores, dim=-1)
    return torch.matmul(weights, v), weights

batch, heads, seq_len, dim = 2, 8, 16, 64
q = torch.randn(batch, heads, seq_len, dim)
k = torch.randn(batch, heads, seq_len, dim)
v = torch.randn(batch, heads, seq_len, dim)

out, attn = scaled_dot_product_attention(q, k, v)
print(out.shape)   # (2, 8, 16, 64)
print(attn.shape)  # (2, 8, 16, 16)

跑通之后，重点看两个地方。第一个是 attn 的形状，(batch, heads, seq_len, seq_len)，最后两维就是“每个位置对其他位置的关注权重”，可以打印出来看每行加起来是不是 1。第二个是除以 d_k ** 0.5 这一步，很多人写代码时漏掉，结果就是数值爆炸、softmax 之后几乎变成 one-hot，训练直接不收敛。

这里最容易忽略的是掩码。生成式模型在训练时需要防止看到后面的词，如果不加因果掩码，模型在训练集上表现很好，推理时却完全不对。这个现象在第二天验证时特别容易出现。

注意：不要一上来就追求手写完整模型。先把注意力这一个模块跑对，比抄一份完整实现然后什么都跑不起来要有价值得多。

2.3 环境和显存不够时的降级方案

环境上，最省事的组合是一个装好 PyTorch 的 Python 环境，CPU 也能跑上面这段代码，只是速度慢。如果要用 GPU，重点是确认驱动、框架版本和显卡算力是否匹配，版本不匹配时报错信息往往很隐晦，看起来像“找不到设备”，实际是编译版本问题。

显存紧张时，有几个降级方向可以按顺序试：

• 把 batch 和 heads 降下来，先用 1 到 2 跑通形状
• 把 seq_len 从几百降到几十，验证逻辑而不是验证性能
• 用 CPU 跑小张量，确认数值正确后再上 GPU 看速度
• 开启混合精度或梯度累积，缓解显存压力

第二天的任务是把这个模块扩展到完整结构：词嵌入、位置编码、多层堆叠、输出投影。验证方式很简单——写一个循环，把每一层的输入输出形状打印出来。如果某一层形状对不上，报错会直接指到那一行，比看结构图有效得多。

判断自己第二天是否达标的标准是：给你一个 token 序列，你能说出它经过每一层之后形状怎么变、参数量大概在哪一层的矩阵里。说不出来，说明还在背图，没到理解。

3. 第三天到第四天：预训练和微调完全是两件事

3.1 预训练在做什么，为什么个人环境不建议从零做

预训练的目标函数其实很朴素：给模型一段文本，遮住一部分或者让它预测下一个词，用预测结果和真实结果的差异去更新参数。重复几万亿个 token，模型就学会了语言的统计规律。

问题在于规模。这活儿的成本结构和普通开发完全不同——它主要是算力和数据工程的成本，不是代码能力的成本。你需要处理海量文本的去重、清洗、配比，需要分布式训练框架，需要能扛住长时间运行的容错机制。任何一环出问题，几天的工作就白跑。个人环境做这件事，投入产出比极低。

所以第三天的正确学法是把预训练当成一个“理解对象”来看：弄清它的目标函数是什么、数据规模大概在什么量级、为什么需要那么多数据、训练不稳定的表现是什么样。这些知识在你后面做微调和评估时都会用到，因为你会遇到“这个能力到底是预训练带来的还是微调带来的”这类判断。

顺带说一句，第三天可以花点时间看数据格式。预训练数据通常是纯文本或经过分词的 token 序列，微调数据则是有结构的输入输出对。这个差别直接决定你第四天要准备什么。

3.2 微调的数据准备比调参更花时间

第四天开始做微调，第一件事不是选模型，是准备数据。

微调数据的基本形态是“指令 + 输入 + 期望输出”的三元组，转成 JSON 或 JSONL 存放。看起来简单，实际坑最多：

这里的关键判断是：微调效果不好，八成先怀疑数据，而不是先调学习率。我一般会先抽 20 条样本人工看一遍，确认输入输出确实对应、答案确实正确、格式确实一致。这一步花二十分钟，能省掉后面几小时的无效调参。

数据量上，如果你只是想让模型学会一种固定的输出格式或语气，几百到几千条高质量样本通常就能看到变化；如果是想注入大量领域知识，微调不是最优解，这时候应该考虑第五、六天的提示工程和 RAG。

3.3 轻量微调的参数该怎么看

全量微调对显存的要求很高，参数量稍大一点就跑不动。实际落地时更常用的是参数高效微调，比如 LoRA 这类方法：冻结原模型参数，只训练一小部分附加的低秩矩阵。

几个关键参数的含义：

• 秩（rank）：控制附加矩阵的容量。调大能表达更复杂的变化，但显存和训练时间上升，也更容易过拟合小数据集。
• 缩放系数：影响附加部分对原模型的影响强度，太大容易破坏原有能力。
• 学习率：轻量微调常用比全量微调更大的学习率，但具体值强依赖数据和模型，没有通用答案。
• 训练轮数：小数据集上通常 1 到 3 轮就够，轮数多了会明显过拟合，表现为训练损失持续下降但验证效果变差。

判断微调是否成功的标准不能只看训练损失。更实际的做法是准备一小批“没参与训练”的测试样本，训练前后各跑一遍，对比输出差异。如果只在训练集上变好，那说明是记住了而不是学会了。

还有一个容易忽略的点：微调会改变模型原有的通用能力。数据集太窄、训练太久，模型可能变得只会说这一种话。所以落地时最好保留一份原始模型的输出作为对照。

4. 第五天：提示工程不是写咒语，是控制输入输出边界

4.1 结构化提示的四个组成部分

很多人对提示工程的理解停留在“换个说法试试”，这导致整个过程不可复现。更靠谱的做法是把提示当成一个有结构的配置。

一个可维护的提示通常包含四块：角色与任务说明、输入数据的边界标记、输出的格式要求、以及异常情况的处理约定。示例结构如下，这是格式示意，不是某个平台的专用语法：

text复制# 任务
根据给定的资料回答问题，不要使用资料之外的知识。

# 输入
资料：
<<<
{context}
>>>
问题：
<<<
{question}
>>>

# 输出要求
1. 只输出答案本身，不要解释推理过程
2. 如果资料中找不到答案，输出：资料中未提及
3. 答案不超过 100 字

# 示例
输入：... 输出：...

四个部分里，最容易被省略的是异常处理约定。如果不告诉模型“找不到就说找不到”，它大概率会编一个看起来合理的答案。这在演示时无所谓，在真实业务里是致命的。

另一个关键是分隔符。用明确的三引号或尖括号把资料和问题隔开，能显著降低模型把资料里的句子当成指令执行的概率。这不是玄学，是把“数据”和“指令”在文本层面区分开。

4.2 怎么判断一个提示是真的变好了

判断标准必须提前定，否则你会在几个版本之间反复横跳。

我的做法是准备一个固定的小测试集，20 到 50 条就够，覆盖三类情况：正常能回答的、资料里没有答案的、资料里有干扰信息的。然后每个提示版本都跑一遍，记录三个数：答对的数量、该拒答时是否拒答、输出格式是否合规。

这三个指标比“感觉回答更好了”有用得多。尤其是第二项，很多提示在正常问题上表现很好，但一遇到没有答案的问题就开始编，而这种问题在真实场景里占比不低。

温度这类参数也要一起记录。同样的提示，温度高时更发散，温度低时更稳定但可能更死板。做对比实验时，参数要保持一致，否则你不知道变化来自提示还是来自采样。

注意：如果换了提示之后效果反而变差，先确认是不是输出被截断了。格式要求写得越长，模型越容易在输出到一半时停下。

第五天结束时，你应该有一份“提示版本 + 测试集 + 结果记录”的东西。这份东西在第六、七天的 RAG 和 Agent 里会直接复用。

5. 第六天：RAG 的难点在切分和检索，不在生成

5.1 文档切分的粒度直接决定检索上限

RAG 的直觉很简单：把资料存起来，提问时先搜出相关片段，再让模型基于片段回答。真正难的是“搜得准”。

而搜得准的前提是切得对。切分粒度太粗，一个片段里混了好几个主题，检索出来一半内容无关，还会挤占上下文；切分太细，一句话被拆成几段，检索到了也拼不回完整意思。

常见的切分策略和适用场景：

我更倾向按结构切，然后用重叠兜底。原因是结构化的切分保留了文档本身的语义边界，比按字数硬切出来的片段更完整。重叠部分的作用是防止答案刚好落在切割点上。

切分时还要给每个片段带上元信息，至少包括来源文档名和片段序号。这在后面排查“为什么答错了”时非常关键——你能直接定位到是哪一段资料被检索出来误导了模型。

5.2 一条完整的 RAG 链路要验证哪几个点

链路通常是：文档解析 → 切分 → 向量化 → 存入向量库 → 用户提问 → 问题向量化 → 检索 top-k → 拼接上下文 → 生成回答。

每一环都有独立的失败模式，所以要分开验证，不能只看最终答案对不对。

• 解析环节：确认表格、列表、代码块有没有被正确处理。PDF 里的多栏排版特别容易解析错乱。
• 切分环节：随机抽几个片段看内容是否完整，有没有在半句话处断开。
• 向量化环节：确认同一段文本两次向量化的结果一致，不同文本的向量确实有区分度。
• 检索环节：拿一个你确定答案在某段资料里的问题，看 top-k 里有没有命中那一段。这一步是排查的核心。
• 生成环节：把检索到的片段和最终答案对照，看模型有没有超出资料范围。

我一般会先跳过生成环节，单独测检索。因为如果检索出来的片段根本不含答案，那后面怎么调提示都没用。这个顺序能帮你快速定位问题在哪一层。

还有一个实际约束：上下文长度是有限的。top-k 设得太大，塞进去的无关内容多了，反而降低准确率，还增加耗时。通常 3 到 5 个片段起步，看效果再调。

5.3 召回不准时的排查顺序

遇到“答非所问”，按这个顺序查：

1. 先看检索结果：把 top-k 片段打印出来，人工读一遍。如果里面没有答案，问题在检索侧，不在生成侧。
2. 再看切分：答案所在的那段资料是不是被切碎了，或者被切到了两个片段里。
3. 再看解析：原始文档里的那段内容是不是根本没被正确提取出来。
4. 然后看问题表述：用户的问法和资料里的说法差异太大时，向量相似度会很低。这时候可以试试把问题改写或扩展。
5. 最后才看生成：确认片段里有答案但模型答错，才去调提示。

这个顺序的价值在于避免“一上来就改提示词”。生成环节背了很多不该背的锅，实际上大部分 RAG 效果问题出在前面的数据处理。

注意：如果检索结果在测试时很好，上线后变差，先确认新文档有没有走完整的解析和切分流程，而不是直接怀疑模型。

6. 第七天：Agent 和所谓企业级项目，最容易高估的部分

6.1 Agent 的本质是循环调用加工具约束

Agent 听起来复杂，拆开看就是一个循环：模型判断当前该做什么，选择调用哪个工具，拿到工具返回结果，再判断下一步，直到任务完成或达到轮数上限。

关键在于工具的定义要足够清晰。一个工具需要说明它叫什么、干什么用、需要哪些参数、参数是什么类型、什么时候该用。用结构化的方式描述，模型才可能稳定地选对。

json复制{
  "name": "search_docs",
  "description": "在内部文档库中检索资料，适用于查询制度、流程、规范类问题",
  "parameters": {
    "query": {"type": "string", "description": "检索关键词，尽量简洁"},
    "top_k": {"type": "integer", "description": "返回条数，默认 3"}
  }
}

描述写得含糊是 Agent 最常见的失败原因。“查询信息”这种描述会让模型在不该调用的时候调用，或者该调用的时候不调用。写清楚适用场景和不适用场景，比多加几个工具更有用。

轮数上限也必须设。没有上限的循环在工具反复返回无用结果时会一直转下去，既费时间也费成本。

6.2 从能跑的 Demo 到能用的系统，中间差的是失败处理

第七天最容易产生的错觉是：Demo 跑通了，就觉得项目成了。实际上 Demo 和企业级之间隔着一整套工程约束。

至少要补上这几块：

• 超时控制：每一次模型调用和工具调用都要有超时，不能无限等。
• 重试策略：网络抖动、接口限流导致的失败要能重试，但要有次数上限和退避。
• 日志记录：每次请求的输入、检索到的片段、模型输出、耗时都要落盘。出了问题能复盘。
• 降级方案：模型服务不可用时，是返回兜底答案还是明确报错，要提前定。
• 输出校验：模型返回的内容要按约定格式解析，解析失败要有处理路径，不能直接崩。

这些听起来都是普通工程问题，但在大模型场景里更容易被忽略，因为大家注意力都在“效果好不好”上。实际运行中，效果问题往往只影响一部分请求，工程问题会让整个服务不可用。

6.3 项目验收该看什么指标

验收标准要提前定，而且要能量化。

平均耗时这个指标特别容易骗人。少量慢请求会被大量快请求稀释掉，用户感受到的是那些慢的。所以看分位数比看平均值更接近真实体验。

另外，拒答能力这项一定要单独测。一个总是编答案的系统，在演示时显得很聪明，在真实使用中会造成更大麻烦。

7. 跑完这七天之后，我建议保留的几个习惯

7.1 每个环节都留一份最小可复现样例

七天跑完，你手上会有一堆零散的脚本和配置。这时候最值得做的一件事，是把每一环的最小样例整理出来：一个能跑通注意力的脚本、一份格式正确的微调数据样本、一个能复现的提示版本、一条能查出正确片段的检索请求、一个带工具调用的小流程。

这些东西的价值在于，以后遇到问题时你能快速判断“是这一环坏了还是整体坏了”。没有这些样例，排查就只能从头再来一遍。

样例不用写得漂亮，能跑就行。但每个样例旁边要写一句注释，说明输入是什么、预期输出是什么、跑不通时先看哪里。

7.2 遇到报错时的固定排查顺序

最后留一套我自己常用的排查顺序，遇到问题按这个走，比乱试快得多。

1. 先确认现象：是报错、卡住、没输出，还是输出不对。这四类的排查方向完全不同。
2. 再看输入：文件路径、编码、格式、字段名、长度。大模型相关的问题里，输入格式错误占比很高。
3. 再看环境：依赖版本、显卡驱动、显存占用、端口占用、网络连通性。
4. 再看参数：批量大小、序列长度、温度、top-k、超时时间、轮数上限。
5. 最后才怀疑模型本身：版本兼容、能力边界、已知限制。

这个顺序背后的逻辑是：越靠前的环节越容易出错，也越容易验证。很多人一遇到效果不好就去换模型，实际上问题常常出在第二第三层。

七天能给你的，是一张完整的地图和几个亲手跑通的点。地图让你知道每一块在什么位置、之间怎么连；点让你知道真实跑起来是什么手感。剩下的深度，得靠后面在具体任务里一点点磨。我个人更建议把这次跑通的结果整理成自己的样例库，下次接到需求时，先翻一遍这些样例，判断该用提示工程、RAG 还是微调，比重新学一遍要快得多。