最近整理自己一年多来跟大模型相关的学习笔记翻出来一看最值得沉淀下来的不是某个模型的 API 怎么调而是这条技术演进线本身。从统计语言模型到 Transformer再到大规模预训练、RLHF 对齐以及今天满屏都是的多模态和智能体每一步其实都在解释当前工具链里那些“为什么”。这篇内容算是对我笔记的一次系统重写也想给正在入门大模型的读者一份能被复用的理解框架。它适合正在学 AI、准备部署本地大模型、或者被各种新名词绕晕但想真正搞懂大模型原理的人。不管你是开发、产品还是学生按这条发展史主线走一遍后面再接触任何新模型心里会踏实很多。1. 大模型学习笔记的内容整体设计与思路拆解1.1 为什么按发展史学而不是按功能学我见过不少朋友学大模型的方式是今天刷到一个“提示词技巧”就收藏明天看到一个“RAG 架构”就复制粘贴后天又去试微调脚本。结果学了一个月工具收藏夹很大脑子里真正能串起来的东西很少。原因很简单按功能碎片学每块知识都是孤岛你不知道它为什么存在、解决的是哪个阶段的问题。按发展史学就不一样。历史是一张地图每个技术节点都对应一个明确要解决的问题。比如你看到 word2vec 出现就知道它的目的是把词变成向量看到 Transformer 出现就知道它解决了 RNN 难以并行和长距离依赖的问题看到 RLHF 出现就知道 GPT-3 虽然能生成流畅文本但经常说错话需要人类反馈把它“拉回来”。这些因果链条一旦建立你就不会再把技术名词当死记硬背的标签而是当成解决特定问题的工具。我在笔记开头画了一条主线统计语言模型时代 → 神经网络时代 → 词向量与序列模型 → Transformer → 大规模预训练 → 对齐与指令微调 → 多模态与智能体。这条线贯穿了从 n-gram 到 GPT-4o 的全部关键转折。每次有新模型发布我第一反应不是看它刷了多少榜而是先想它属于哪条线是架构创新、训练数据扩展、还是对齐方式的改进这个判断一旦形成你对新东西的吸收速度会快一大截。1.2 发展史里藏着三条并行主线我整理笔记时发现单纯按年份排技术点太扁平了容易漏掉同一时期发生在不同方向上的变化。后来我把历史拆成三条线来看清晰很多架构线从 n-gram、循环神经网络RNN/LSTM到注意力机制Attention再到 Transformer、混合专家模型MoE、多模态融合结构。这条线回答的是“模型怎么算”。训练线从无监督预训练到有监督微调再到基于人类反馈的强化学习RLHF、指令微调以及现在大家常用的 LoRA/QLoRA。这条线回答的是“模型怎么学”。能力线从词向量、上下文建模到涌现能力、上下文窗口持续扩大从 2K 到 128K、甚至 1M 级别再到多模态感知、工具调用、智能体。这条线回答的是“模型能干什么”。用表格把三条线放在一起一眼就能看到大模型发展史其实是并行推进的2017 年 Transformer 解决架构瓶颈2018 年 BERT/GPT 确立预训练微调范式2022 年 ChatGPT 把对齐训练推向大众视野2023 年后多模态和智能体开始爆发。你如果只看某一条线会以为只是某个模型的进步但实际上整个行业是三维立体地在往前走。这三条线也是我后续写这篇笔记的骨架。后面讲到的本地部署、微调、向量比较、上下文长度这些实战话题都能在三条线里找到自己的位置。学习的时候带着这张多维地图遇到具体问题就不会慌。1.3 一份合格的大模型学习笔记该沉淀什么写学习笔记很容易变成抄书。我早期记笔记就是把网上的科普文章复制粘贴后来发现一点用都没有。经过反复调整现在我的笔记只保留四类内容概念卡每个核心概念用“一句话定义 一个类比 一个最小示例”来写。比如“注意力机制”的定义是“让模型在处理每个词时能关注输入中相关的其他词”类比是“做阅读理解时眼睛会重点看题目相关的句子而不是整页平均用力”最小示例就是一行伪代码。时间线把关键论文和产品按年份挂上去每条只写动机、核心创新、局限。比如 2018 年的 BERT 解决了“双向上下文”的问题但它没有生成能力同期 GPT 只有单向但为生成埋下伏笔。实验记录所有跑过的代码、命令行、遇到的报错和解决办法。这部分是真正属于你自己的知识。问题清单记录学习中遇到的“为什么”和“如果不这样会怎样”。比如“为什么预训练要用自监督而不是人工标注”“为什么上下文越长显存消耗越大”“为什么量化会掉精度但大家还在用”。我建议每一位正在学大模型的人都按这四个栏目来组织自己的笔记。知识不是记在脑子里而是组织成一个能随时调用的系统。这篇博文后面所有内容其实都是我从四类笔记里抽取出来的。2. 核心节点细节解析与实操要点2.1 从统计语言模型到词向量第一步是让机器“理解”词大模型的真正起点不是 GPT更早可以追溯到统计语言模型。n-gram 模型的思路很朴素一个词出现的概率只和前 n-1 个词有关。它的问题也很明显——对长距离依赖无能为力而且词表一大数据稀疏得没法看。我刚开始学的时候觉得这些内容太古旧了后来才意识到正因为它太笨才催生了后面所有创新。2013 年的 word2vec 是一个标志性转折。它把每个词映射成一个稠密向量语义相近的词在向量空间里距离也近“国王-男人女人≈女王”这类经典关系就是那时候火的。这个思路影响极其深远今天的模型虽然不再是简单的词嵌入但所有输入文本仍然要先变成 token再查嵌入表得到向量这一步的本质和 word2vec 时代没有区别。如果你没接触过词向量我建议动手跑一个最小示例。用 gensim 库对几 MB 的语料训练一个 word2vec然后看“北京”和“上海”的相似度、和“香蕉”的相似度你会直观感受到语义向量是什么。这件事大概半小时就能做完但它会帮你建立“一切文本最终都是数字”的直觉。后面学向量数据库、RAG、上下文检索时这个基础会反复用到。另外要理解的一点是word2vec 产生的向量是静态的一个词只有一个向量无法处理“苹果”既指水果又指公司这类一词多义。2018 年的 ELMo 用双向 LSTM 生成上下文相关的词向量才首次解决了这个问题。但 ELMo 本质还是 LSTM长距离能力有限真正改变格局的是后来出现的 Transformer。2.2 Transformer为什么 2017 年这篇论文成了分水岭2017 年谷歌团队发表《Attention Is All You Need》提出 Transformer 架构这件事再怎么强调都不过分。在它之前主流的序列模型是 RNN/LSTM这类模型按顺序逐个处理文本天然无法并行训练效率上不去而且随着序列变长早期信息容易被“遗忘”。Transformer 的核心创新是用自注意力机制Self-Attention一次性计算输入序列中任意两个位置之间的关联相当于把整句话摊开放在桌面上让每个词都能直接“看到”所有其他词。自注意力机制带来的两个直接红利很多人没有意识到第一训练可以并行化了因为不再依赖前一个时刻的计算结果这让用超大规模数据训练成为可能第二长距离依赖问题被显式解决了相隔很远的两个词也能直接建立关联这对语义理解是质变。用个生活化类比RNN 就像一个人逐字读长篇小说必须看完上一页才能翻下一页看到第 500 页时早忘了第 10 页的伏笔Transformer 则像把整本书摊开在桌上眼睛可以在任意两页之间来回扫视随时把前后情节关联起来。我当时为了弄清楚 Self-Attention 的细节手算过一个三句话的小例子构造三个词的 Query、Key、Value 矩阵算点积、缩放、Softmax、加权求和。算完之后才发现所谓注意力就是“按相关性加权求和”并没有玄学。如果你也在学 Transformer强烈建议花两小时手推一小步。代码层面PyTorch 里nn.MultiheadAttention或者 Hugging Face 的BertModel都有现成实现但“看十遍源码不如自己推一遍公式”这句话在这个知识点上特别适用。Transformer 之后所有大模型都长一个样一个巨大的 Transformer 堆叠前面接 tokenizer 和 embedding后面接输出层。区别只在于规模、训练数据、预训练目标和后训练方式。所以学大模型发展史必须在 Transformer 这里停住夯实了再往下走。2.3 预训练、涌现能力与上下文长度大模型的“大力出奇迹”Transformer 提供了架构基础但真正让模型表现出智能的是“大规模预训练”这个训练范式。2018 年 BERT 和 GPT 几乎同时证明了同一件事在超大规模文本上做自监督学习模型能学到通用的语言知识之后只需要少量微调就能迁移到下游任务。BERT 偏理解GPT 偏生成两条路线后来走向了融合现在的对话模型基本都是生成式架构。这里有个关键概念必须理解涌现能力。模型规模小的时候能力曲线是平滑提升的但当参数量跨过某个阈值比如百亿级别一些能力会突然出现比如上下文学习In-Context Learning、思维链推理Chain-of-Thought、代码生成。这就像小孩子语言发育词汇量积累到某个点突然能说出完整句子不是每多学一个词就更流利一点而是到了临界点就质变。不过这也不是没有代价。模型规模变大后训练成本爆炸式增长于是行业开始研究扩展定律Scaling Law用公式描述损失、参数量、数据量之间的幂律关系。简单说想降低同样的损失数据量和参数量要按照一定比例共同增长单方面堆参数很快会收益递减。这也是为什么现在各大团队都在拼命卷高质量训练数据甚至用合成数据来补充真实语料。另外上下文的长度是大模型实际使用中感受最明显的一个指标。早期 GPT-3 只能处理 2048 个 token大约相当于一两页中文聊天一长就“失忆”。后来技术进步把窗口推到 32K、128K现在很多模型支持 1M token能一次性读完一整本书。这个进步背后是注意力计算和 KV Cache 的优化不是简单地调个参就行。我的经验是选模型时不要只看最大上下文长度还要看它在长上下文下的实际效果很多模型号称支持百万 token但塞到十万 token 就开始“中间遗忘”。测试方法很简单找一段长文档放到中间问一个只有文档中间才有的细节问题看看模型能不能答出来。2.4 对齐、多模态与智能体大模型从“能用”到“好用”2020 年的 GPT-3 虽然能力惊艳但它有个致命问题生成的文本经常是错误、有毒或是无意义的。它本质上只是一个“续写机器”不是“助手”。ChatGPT 之所以 2022 年底能火遍全球关键在于它把对齐Alignment和指令微调Instruction Tuning真正产品化了。对齐训练的核心是人类反馈强化学习RLHF流程分三步先训练一个奖励模型来评价“哪个回答更好”再让被训练模型生成回答最后用强化学习让模型学会偏向人类喜欢的输出。后来业界发现不用那么复杂的强化学习直接用高质量人工标注的“指令-回答”对做有监督微调SFT也能大幅提升表现这就是目前开源社区普遍采用的做法。换句话说对齐本质上是在解决“价值观”和“说话方式”问题让模型不只会说话还知道什么该说、怎么说。从 2023 年开始多模态大模型接棒成为热点。所谓多模态就是模型不仅能读文字还能看图、听声音、甚至理解视频。实现方式通常是在文本模型外面接一个视觉/音频编码器把图片切块成视觉 token然后和文本 token 一起送进 Transformer。GPT-4V、GPT-4o、Gemini、Qwen-VL 都是这个思路。实际使用中多模态最有价值的地方是 OCR 识别、图表理解、截图问答这些场景比纯文本聊天实用得多。智能体Agent是大模型发展史的当代出口。纯粹聊天能做的事有限但让模型具备调用工具、访问外部 API、自主规划任务的能力后它就从一个“会说话的数据库”变成了“可以干活的数字员工”。2023 到 2025 年间各家都在推 Agent 框架比如规划-执行-反思的循环、工具注册、记忆机制等。我在笔记里专门记了一句智能体不等于单次对话它更像一个带状态的任务执行系统状态管理、容错、权限控制才是真正的难点。这也是为什么很多人说自己搭的 Agent“跑一次能用跑十次就崩”。3. 从学习笔记到实战落地本地部署与大模型微调3.1 用 Ollama 和 LM Studio 搭一个最小实验环境学大模型不能光看文档一定要有一台能跑模型的机器。如果你不是做大规模训练只是学习推理和部署其实一台普通电脑就能完成入门。我的经验是用 Ollama 或者 LM Studio 这类工具做本地部署是成本最低、见效最快的路径。Ollama 的操作逻辑很简单它把模型打包成一个个可拉取的镜像命令格式和 Docker 很像。比如我想在本地跑一个 7B 参数的 Qwen 模型只需要执行ollama pull qwen2.5:7b ollama run qwen2.5:7b然后就能直接在终端里和模型对话。如果你需要 OpenAI 兼容的 HTTP 接口Ollama 默认会监听 11434 端口可以直接用 Python 的openaiSDK 连上去from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服务不需要真实密钥 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 用一句话解释注意力机制}] ) print(resp.choices[0].message.content)这里有个很关键的点不论你之后接的是 GitHub Copilot、Cline、还是自己写的应用只要它支持 OpenAI 格式的接口你都可以把 base_url 换成http://localhost:11434/v1用本地模型替代云端 API。在 Visual Studio 2022 或者 VS Code 里通过 LM Studio 启动一个本地兼容端点后也能让 AI 插件直接使用本地模型来补全代码这个做法对数据敏感、不便上传代码的团队很有价值。选模型时不要盲目追最大参数。我的实践经验是4GB 显存可以流畅跑 7B 量化模型8GB 显存可以跑 14B 量化模型16GB 显存可以考虑 32B 量化模型。如果你的显卡只有 6GB却非要去跑 70B 模型最后只会得到一个慢到没法用的体验。量化的原理简单说就是把权重从 16 位浮点数压缩到 8 位或 4 位整数内存占用大幅下降但精度会有轻微损失。实际测试下来4 位量化比如 Q4_K_M对日常对话和代码补全影响很小反而是能跑起来比跑不动有价值得多。如果你打算下载模型离线使用注意 Hugging Face 和 ModelScope 都提供命令行工具可以先把模型下载到本地再让 Ollama 导入。以 Qwen 为例可以用hf download或直接在 ModelScope 页面下载 GGUF 格式文件再通过 Ollama 的ollama create注册成本地模型。这一步特别适合内网环境或者网络不稳定时使用。3.2 从发展史视角理解微调、API 与上下文限制很多初学者一上来就想微调大模型但实际上 90% 的场景根本用不着微调。理解这句话的前提是搞清楚预训练、微调和提示工程各自在解决什么问题。预训练让模型学会“语言”微调是让模型学会“某一种具体任务”而提示工程是“不改变模型只改变输入引导模型输出”。三者成本递减逻辑上应该优先用提示工程不够再微调。如果你的任务真的需要微调业界目前最主流的方式是 LoRA 或 QLoRA。核心原理是冻结原模型的全部参数只在旁边加一小部分低秩的可训练矩阵训练时只更新这部分参数。这样训练参数量能减少到原来的千分之一甚至更少单张消费级显卡比如 24GB 显存就能微调 7B 或 14B 模型。等训练完把 LoRA 权重和原模型合并部署时仍然是一个正常模型文件。我踩过的一个坑是微调数据不在于多而在于格式对。很多人从公开数据集下载几万条数据直接开跑结果模型越训练越“呆”。正确做法是先准备几百条高质量、格式统一的样本哪怕只有三百条只要覆盖你想要的行为模式效果可能比三万条脏数据好得多。所谓“格式统一”指的是每一条样本都用相同的模板组织系统提示词、用户输入、期望输出。用最简单的 JSON 结构就可以关键是让模型反复看到一致的映射关系。关于免费的大模型 API现在国内外都有不少开放平台提供限免额度但各家模型能力参差。我的建议是先用少量请求做一次横向对比别急着定。评估维度包括响应速度、上下文处理能力、对中文的理解、输出格式稳定性。尤其是上下文长度免费套餐通常会限制得比较短比如 8K如果你的任务要处理长文档就要优先选择支持 32K 或 128K 的模型。我自己的一个判断技巧是拿同一段 5000 字的技术文档问 20 个细节题能全部答对且引用了原文位置的模型长上下文能力才是真的可靠。3.3 向量比较、知识抽取与大模型测评让模型更好用的三件套学习大模型到一定阶段你会发现光会“聊天”远远不够真实业务中三个方向最常用。第一向量比较。大模型本身不直接做精确匹配但你可以把任意文本转换成向量Embedding然后通过计算余弦相似度来比较两个文本的语义相近程度。这是 RAG检索增强生成的基础先把知识库切成小块并向量化存入向量数据库用户提问时把问题向量化检索出最相关的几个片段再拼进提示词里让大模型回答。很多团队用这个方法让私有知识库“活”起来而且不需要微调。第二知识抽取。大模型特别擅长从非结构化文本里抽出结构化信息。比如给出一份合同、一篇新闻或者一段对话让它输出 JSON 格式的“主体、事件、时间、金额”四要素。我用的一个流程是写清晰的抽取规则进系统提示词并要求模型只输出 JSON 不输出解释再用 Python 解析 JSON。如果你的抽取场景很固定也可以使用领域专用框架比如 OneKE 就是面向知识抽取任务设计的模型。注意提示词里一定要限定输出 schema比如{entities: [], relations: []}否则模型会自由发挥解析时很容易报错。第三大模型测评。现在网上各种榜单多到眼花缭乱跑分网站也很多。我自己的看法是跑分只能作为粗筛不能作为选型依据。不同模型在通用问答、数学、代码、中文理解上的表现差异很大必须拿自己的真实任务去做验证。尤其是你要长期使用的场景可以做一个 20~50 题的固定评测集每次换模型时跑一遍对比比任何公开榜单都可靠。这个评测集里面既要有普通问题也要有边界问题——比如“如果我给你的指令和系统预设冲突怎么办”“这段代码里最隐蔽的 bug 是什么”这些才是实际使用中会遇到的硬骨头。4. 常见问题与排查技巧实录4.1 概念混淆速查表学习大模型的过程中我遇到最多的是概念混用。这里整理一张速查表都是我踩过之后才分清楚的概念一句话定义容易混淆点大模型参数量很大、在大规模数据上预训练的深度神经网络模型不特指聊天机器人LLMLarge Language Model大语言模型主要处理文本大模型的下位概念多模态模型不属于纯 LLM多模态大模型能同时处理文本、图像、音频、视频的模型不等于“能识图的 LLM”而是架构上多模态融合基础模型预训练完成的原始模型未经过任务专用微调所有行业模型都在基础模型之上派生微调用新数据调整模型参数以适应特定任务和提示工程不同微调会改变权重上下文长度模型一次能考虑的最多 token 数量不是“记忆容量”超出后需用外部存储如 RAG向量数据库存储向量并支持相似性检索的数据库不存储原始文本原始文本存在外部知识库Agent能调用工具、自主规划和执行任务的 AI 系统单次对话不是 AgentAgent 是流程系统这张表建议打印出来贴在工位上。新概念出来后先往表里找它的位置再判断新旧关系。4.2 本地部署的常见报错与解法本地部署大模型失败的概率不低但绝大多数问题都能通过基础排查解决。显存不足是最常见的一个。现象是加载模型或推理时程序直接崩溃或者报CUDA out of memory。解决办法从易到难排列重启程序清理显存、关闭其他占用显存的应用、换个更小的量化版本、降低上下文长度设置。我试过在 8GB 显存机器上跑 14B 模型硬怼长上下文直接 OOM把上下文降到 4096 就稳定了。本质原因很简单上下文越长KV Cache 占用的显存越多而且是指数级增长的加速版。第二个常见问题是模型输出速度慢到没法接受。如果是纯 CPU 推理7B 模型大约只有每秒 2~4 个 token聊天体验很差。解决方案不是换模型而是确认是否真的用了 GPU 加速。在 Ollama 里可以执行ollama ps查看模型运行在 CPU 还是 GPU 上。如果显示100% CPU说明加速没生效需要检查显卡驱动、CUDA 版本或者安装带 GPU 支持的 Ollama 版本。这一步很多人忽略以为是模型太大造成的。第三个问题是输出乱码、中文异常。多数情况下是提示词里没有指定语言或者 tokenizer 处理特殊字符出问题。我习惯在系统提示词里加一句“始终使用简体中文回答”并且在输入前统一做 UTF-8 编码处理。如果用了特殊符号导致异常可以换一个 GGUF 量化版本再试。4.3 应用开发中的五类坑把大模型接进自己的应用后新问题会从“模型能不能跑”变成“结果稳不稳定”。我重点记录过五类问题输出格式不稳定。让模型输出 JSON它偶尔会夹带解释文字或 markdown 代码块。解法有两个一是提示词里明确“只输出 JSON不要任何其他文字”二是正则提取{}包裹的内容再做 JSON 解析。后者在代码层面更稳妥。上下文超限。输入较长时请求直接被拒报context_length_exceeded。解法是别把所有内容硬塞进提示词先对文档做分段检索再拼接这就是 RAG 的工程意义。幻觉。模型一本正经地胡说八道特别是回答具体数字和事实时。解法是要求模型“如果不确定就回答不知道”并且给模型引用原文片段的能力。最有效的还是让模型基于检索结果回答而不是凭记忆发挥。数据标注问题。很多开源模型的微调数据里本身有标签噪声导致模型对某些指令反应不稳定。我一般把关键任务写成多轮样本让模型先复述要求再执行出错率会低很多。安全问题。大模型可以被提示注入影响也可能在被投毒的数据集上学习到后门行为。实际工程项目里我建议不直接让模型访问外部网络对用户的输入做过滤不在系统提示词里暴露敏感信息所有模型输出都经过一层规则校验再展示。这些坑几乎每个做 AI 应用的人都会遇到。我的心态是大模型只是一个概率生成器不是稳定的数据库所有工程手段都是在降低它的不确定性。4.4 学习路线上的三个反思最后说说我在整个学习过程中最有价值的三个反思。第一先跑通再深挖。很多人卡在原理上一直读论文一直不敢动手。我后来调整为先跑通一个 demo哪怕完全不懂内部机制先建立“原来是这样”的体感再回头补原理速度快得多。这也是我把本地部署放在笔记前部的原因。第二用“最小实验”验证概念。学到一个新概念比如“温度系数”或者“top-p 采样”我都会写一个二十行的脚本把参数从 0.1 调到 1.5观察输出变化。这种小实验只需要几分钟但对理解模型行为帮助极大。第三笔记必须带着“当时的疑问”写。只抄结论的笔记没有任何价值反而是那些记录了我“为什么这个模型效果差”“为什么这个参数是这个值”的片段后来反复读都有新收获。知识不是背出来的是在疑问中连起来的。5. 我看好的几个后续扩展方向5.1 上下文窗口还会继续扩大但会出现“分段记忆”架构未来一到两年模型原生支持的上下文长度还会往上走但单纯靠扩大窗口解决不了所有问题。我看到的一个趋势是“分段记忆 检索”的混合方案模型不是把所有内容都塞进上下文而是维护一个外置记忆层用到什么才检索什么。这个概念已经出现在一些智能体框架的设计里对长文档处理来说可能比无限扩大上下文更实用。5.2 多模态不再只是“看图”而是走向空间与交互多模态大模型最近的进展已经不只是识别图片内容而是结合空间关系、时序信息做更复杂的理解。比如模型能看懂一张机械图纸并给出组装步骤或者根据摄像头画面给出操作建议。这类能力在机器人控制和工业场景里尤其有想象空间。我在笔记里也顺手记过一些类似 space bunny 这样的特定风格图像模型它们虽然只是社区作品但证明了多模态创作的工具链已经越来越平民化了。5.3 小模型、端侧部署和领域微调会成为主流落地方式不是所有场景都需要千亿参数大模型。很多嵌入式设备、手机应用和数据敏感行业需要的其实是参数不大但针对性强的专用模型。现在业界已经有很强的 3B、7B 级别模型配合量化技术在手机和边缘设备上也能跑得很流畅。这也是“嵌入式开发用什么大模型好”这类问题会频繁出现的原因。我的建议是优先看能否用量化小模型解决而不是一上来就上大集群如果小模型效果不够再用云端大模型做兜底。这个“先小后大”的思路会帮你省掉大量不必要的成本。我个人在实际整理这份发展史笔记时最深的体会是历史不是用来背的是用来定位的。每次新技术出现我都会先想它处在三条主线里的哪一条是架构创新、训练方式变革还是应用范式迁移。这样做的好处是不会被营销词汇拖着走。最后再分享一个小技巧在笔记里为每一个新概念建立“概念 → 动机 → 最小示例 → 坑”四行记录长期积累下来你手里的就不是碎片而是一张越来越清晰的技术地图。
