大模型知识基础：预训练决定上限，微调与RAG只是补充
很多人问“我应该从哪儿开始做大模型”，多数答案都指向推荐书目、课程链接、GitHub仓库。但以我这些年带团队、做项目、看社区案例的真实体会，真正让一个人和大模型从业者拉开差距的，不是什么新框架、新技巧，而是“知识基础”——它体现在两层：你自己脑子里的基础知识够不够扎实，以及你手里的大模型它自己的知识储备够不够用。这两个基础决定了大模型项目能走多远。这篇文章我会把这两条线彻底掰开讲清楚，顺带解释为什么很多人微调、部署、做Agent搞了半天效果还是不行，根子都出在知识基础上。
1. 为什么“懂原理”比“会用”更值钱——学习大模型的知识地图
1.1 工具流学习法的天花板在哪里
我见过太多人走“工具流学习”路线：今天ChatGPT火了学提示词，明天RAG火了学向量数据库，后天Agent火了学LangChain，大后天微调火了又去学LoRA。每样都浅尝辄止，东西会“用”，但一问“为什么这样设计”就哑火。这种学习方式的致命问题在于：你接触到的所有工具都是别人封装好的“结论”，你不知道结论背后的假设条件，换个环境、换个模型、换个数据规模，结论就全都不成立了，但你完全没有能力做调整。
举个我经常举的例子。很多人都用过量化模型，知道一个7B模型用GPTQ量化到4bit之后显存占用大概能压到4到6GB，于是兴冲冲在自己笔记本上跑起了本地模型。但如果你不知道量化的基本原理——权重从FP16变成INT4之后精度下降、某些敏感层需要保留更高精度，你就无法解释为什么量化的模型在数学推理和代码生成任务上会突然“变笨”。你不知道该用AWQ还是GPTQ，不知道该不该开KV Cache量化，不知道哪些算子会被反量化回FP16导致显存不降反升。这些“知识空白”在demo阶段毫无感觉，一旦你做的产品要面对真实用户，问题就会集中爆炸。
这也是为什么我特别强调：大模型从业者的首要任务不是追逐最新工具，而是建立一套关于“语言模型为什么能生成内容”的底层认知框架。你不需要从零复现一个Transformer，但至少要做到：看到任何一篇模型技术报告，能看懂它在改什么模块、为什么这么改、这是解决什么问题的手段。
1.2 大模型学习路线里绕不开的三层地基
根据大量一线团队的学习和实践经验，我把打基础的过程拆成三层。
第一层是数学地基。我最常被爱好者问的问题是“搞大模型数学要学到什么程度”。我的回答是：线性代数要懂矩阵乘法与向量空间的直觉，概率统计要能理解分布、采样与最大似然的思想，信息论至少要理解熵和交叉熵的含义。你不需要会手工推导所有证明，但你要知道交叉熵作为损失函数，本质上是在度量“模型预测分布”和“真实数据分布”的距离；你要知道Softmax里的温度系数为什么能控制生成多样性，因为它是从玻尔兹曼分布来的；你要知道为什么KV Cache能省算力，本质是用显存换时间，背后的矩阵拼接是线性代数的基础操作。这些东西不去理解，你就只能永远拿着别人的参数调来调去。
第二层是模型机理地基。这块最核心的有：神经网络与反向传播的基本工作原理、注意力机制的计算流程与设计动机、Transformer的整体架构与各模块职责（嵌入层、多头注意力、前馈网络、层归一化、残差连接）、预训练与微调的本质差异、解码器模型的生成过程（从逐步预测下一个token到采样策略）。我面试候选人的时候有一个高频问题：为什么Transformer要用LayerNorm而不用BatchNorm？很多人背过答案说“因为NLP序列长度可变、BatchNorm不好使”，但如果你进一步追问“为什么LayerNorm对长度变化鲁棒”，就很少有人能答上来了。这不是八股，这是你理解为什么后来的模型都改用RMSNorm、为什么有的模型在长上下文场景下做Pre-Norm和Post-Norm的取舍时，能够自己想明白的基础能力。
第三层是数据与工程地基。很多纯算法背景的朋友低估了这部分。你要知道一个模型“学到知识”靠的不是模型本身，而是数据；你要了解tokenizer是怎么把文本切片的，BPE和SentencePiece各自有什么特性，这直接影响模型在中文、代码、多语言上的表现；你要知道Embedding是“知识的索引”还是“知识的压缩”，这种认知偏差会导致你在做RAG时犯严重的方向性错误；你要了解分布式训练里数据并行、张量并行、流水线并行的基本分工，否则你拿到一张分布式训练配置表就只能照着抄。这些属于“模型之外但仍然决定模型效果”的知识，恰好是整个行业里稀缺的能力。
1.3 基础牢不牢，看这三个迹象
我总结过几个判断基础是否牢靠的迹象，分享给大家做自查。
第一条，当看到一个模型报告里出现“Context Window从4K扩展到128K”时，你脑子里是浮现“这很厉害”，还是浮现“这背后用了什么位置编码策略——RoPE的基数调了多少、有没有做YaRN、注意力机制是Full Attention还是Sliding Window”。只有第二种反应，才算入了门。
第二条，当你的模型输出出现重复、空洞、答非所问时，你是直接换提示词试试，还是能快速判断问题可能出在解码参数（temperature、top_p、repetition_penalty）、模型容量、还是prompt本身的任务描述不清晰。能定位出具体环节，才有希望真正解决问题。
第三条，当你想让模型拥有某个领域的能力时，你第一反应是微调、RAG、还是改prompt？如果你只会用其中一个去套所有场景，说明你对三者的边界和原理还没吃透。这件事我在后文“模型的知识储备”部分会重点展开。
2. 模型的知识储备：预训练决定上限，微调只是修补下限
2.1 大模型的知识到底存在哪里
现在聊第二个层面：模型自身的知识基础。很多人把大模型当成一个搜索引擎来用，问什么它都能答，于是默认它什么都知道。这是理解大模型知识体系时最大的误区。实际上，大模型拥有的知识绝大部分不是在推理时“查来的”，而是在预训练阶段被“压进”网络参数的。你在网上看到的每一段文字、每一行代码、每一篇论文，经过tokenizer切成token后，模型做的事情就是把“看到这段文本的前半部分，预测后半部分”这个目标反复优化。在这个过程中，模型为了尽可能降低预测损失，被迫把语言中的语法规则、事实关系、逻辑模式、常识世界模型全部编码进几十亿个参数里。
请记住一句话：预训练参数是大模型的“长期记忆”，上下文窗口是大模型的“工作记忆”，微调无法凭空增加知识，它只是把已有的知识重新组织和定向激活。
我在内部培训时经常用一个比喻：把预训练好的模型想象成一个读过海量书籍、知识量极其庞大但有点“思维定势”的博士生。他的底蕴深不可测，但如果你让他回答一个连书里都没写过的东西，他绝不会老老实实说“我不会”，而是会引经据典、用最符合学术规范的方式编造一个答案，这就是幻觉。你给他做微调，好比告诉他在特定场景下应该用特定方式说话，但并没有给他补上他没读过的那些书。你给他做RAG，好比给他开卷考试，允许他随时查参考资料，但他能不能答好，依然取决于他自己“读过的书”够不够多、理解能力够不够强。
2.2 知识边界的三个硬约束：截止日期、覆盖密度、噪音污染
理解了知识存在参数里之后，你就会明白模型的三个天然硬约束。
第一个硬约束是知识截止日期。预训练语料有截止时间，模型不可能知道这个时间点之后发生的事情。你问2024年某个新发布的产品参数，模型如果“答”上来了，那就是在编。这不是bug，这是预训练机制决定的。很多人例用“外挂知识库”（RAG）来补这个缺口，这个方向是对的，但你得理解它补的是“上下文”，不是“参数”。模型不会因为一次RAG检索就把新知识记住，下次对话它依然不知道。
第二个硬约束是知识覆盖密度不均。模型学过互联网上所有能找到的文本，但互联网的内容分布是高度不均匀的。大众领域（新闻、百科、论坛、小说）语料丰富，模型的知识密度就高；冷门领域（某细分行业的内部规范、小众工具的使用细节、地区性的专业知识）语料稀缺，模型在这些领域的表现就接近于一个只会顺着语言惯性“胡编”的生成器。这也能解释为什么很多垂直行业的大模型落地项目都失败了：你拿一个在通用语料上训练的基座模型，直接去做法律、医疗、客服等需要行业深知识的任务，它看起来什么都能聊，但一涉及真正专业细节就漏洞百出。
第三个硬约束是语料本身的噪音污染。互联网文本并不等于高质量知识。广告、软文、编造的百科条目、互相抄袭的错误博客，模型统统吸收了。这就是为什么模型会在某些问题上义正词严地给出错误答案——它并非逻辑差，而是它的训练数据里“正确答案”本来就占少数，或者正确答案和错误答案搅在一起，模型学到了一个混合分布。这提醒我们：今天大家都在谈“知识抽取”、“知识图谱”、“高质量数据集”，本质都是在和这个硬约束对抗。
2.3 知识断层是幻觉的根本原因，不是模型“不聪明”
基于上面三个约束，我们可以给幻觉一个更本质的解释。模型在生成回答时，是在参数构成的“知识空间”里沿着最有可能的路径前进。当你的问题落在模型知识空间里的高密度区域，它会给出靠谱答案；当你的问题落在低密度甚至空白区域，模型不会停手说“我不会”，它只能沿着语言模式继续前进，把最“像样”的回答编出来。业内把这称为“知识断层”。
于是你会看到很多反直觉的现象。一个通过了各种考试测评的模型，可能在一道非常简单但冷门的常识题上栽跟头；一个在代码生成上表现优秀的模型，可能在解释某段开源代码作者的意图时一本正经地胡说八道。这些都不是“模型不够智能”，而是“该区域的知识密度不够”。
这个概念对做应用的人有什么实际指导意义？非常大。当你发现某个垂直场景模型老胡说八道时，不要第一反应就上微调。要先问一句：模型的基础预训练到底有没有覆盖这个领域的知识？如果覆盖了只是回答风格不对，微调很有效；如果压根没覆盖，微调只是让模型把错误知识背得更流利。判断方法也简单：直接拿一批这个领域的经典问题去测试基座模型（没有任何微调、没有RAG、没有system prompt），如果基座连最基本的概念都说不清，说明该领域知识没有充分进入它的参数，后面做再多包装都是在沙滩上盖楼。
3. 应用落地时的知识缺口：部署基础设施、上下文窗口与领域知识体系
3.1 不懂显存计算，部署本地大模型就是跟着感觉走
搞清楚了知识在参数里，接下来要解决的是“把这些有知识的参数跑起来”的问题。这涉及部署基础设施的知识基础。现在本地部署大模型非常火，很多人照着教程把Ollama、vLLM一套组合拳下来就能跑了，但对背后资源配置一头雾水。
举一个我实测过的例子。你想本地部署一个7B模型，先说一个最简单的估算方法。7B参数，用FP16精度存储，每个参数占2字节，光权重就要14GB显存。这还只是“把模型放进显存”的最低要求。推理时你还需要空间存放KV Cache，它的大小和序列长度、注意力头数直接相关；还需要临时激活值空间存放中间计算结果；如果你的批量大小大于1，激活值还会成倍增长。所以你真要跑一个7B模型并行处理长文档，16GB显卡大概率捉襟见肘，32GB才比较从容。这也是行业里有那么多人折腾NanoVLLM、AirLLM、各种量化方案的原因——本质上都是在削减不同模块的显存开销，来换取“在个人电脑上把模型跑起来”的可能。
这些知识基础没有建立起来的话，你换一个模型、换一张显卡、或者从对话demo改成服务化部署时，就只能回到网上重新搜教程，而且还搜不明白。你无法判断为什么教程里设的batch size是8、为什么max length被限制在2048、为什么量化后要用一个额外的校准数据集。知识基础就是让你从“照做”变成“能自己设计”的那道分水岭。
3.2 上下文工程：给模型一个高质量的工作记忆区
有了能跑的模型，接下来决定输出质量的关键就是上下文工程。这个词被提到得比提示词工程晚一些，但我认为它准确点出了当代大模型应用的核心：在一个有限的上下文窗口里，如何为模型构造最有利于它发挥知识储备的工作记忆区。
先说最基础的事：上下文窗口不是让你塞得越满越好。我见过太多人把RAG检索到的内容不分青红皂白全塞进prompt，结果模型反而答得更差。为什么？因为注意力机制的计算是全局的，模型需要把注意力分散到所有的token上，大量无关信息会稀释模型对关键信息的关注。这和你的工作记忆一模一样的道理：桌子上堆满了资料，你反而找不到最需要的那张纸。上下文工程的核心就是做“信息密度的管理”。你要把最核心的信息放在模型注意力最强的位置——有研究表明，Transformer对序列开头的关注度更高，所以把核心指令放在最前面是有道理的。你要把检索到的片段切成适当的长度，去掉冗余说辞，只保留与问题直接相关的部分，并用清晰的格式把“证据”和“题目”标识出来，模型才能高效地使用这些知识。
再进阶一步是Few-shot示例的选择。很多人在few-shot里随便找几个例子填进去，其实示例的选择本身就是知识基础的体现。示例的分布应该尽量贴近真实推理时可能遇到的问题分布，示例答案的质量决定模型模仿的上限。你用几个错误答案做示例，模型就学会犯同类的错。你把示例设计的太简单，模型在复杂查询上就不知道怎么迁移了。这些都要求你对模型机制有深入理解，而不是把提示词工程理解成“措辞华丽的提问艺术”。
3.3 领域知识体系缺失，私有大模型项目必翻车
部署好模型、设计好上下文框架之后，还有一个决定成败的隐性知识基础：领域知识体系本身。我参与和看过不少企业私有化大模型项目，有一个规律几乎从未失手——凡是只买了模型、没梳理知识体系的项目，最后都变成了昂贵的玩具。
举个制造业客服场景的例子。企业想用开源模型做一个产品售后客服。他们预算是足够的，显卡也买了，甚至还请人做了微调和RAG。但上线后用户反馈极差，模型频繁给出错误的产品规格、错误的售后政策。排查到最后，根本原因是这样的：一是原始产品文档散落在十几个系统里，格式五花八门，很多还相互矛盾；二是知识抽取环节没有做，直接拿PDF切块塞进向量库，模型检索出来的内容本身就不完整；三是没有知识体系的验证闭环，没有一套“标准问题-标准答案”的评估集来量化系统到底答对了多少。这个项目不是输在模型，而是输在知识基础工程。
所以我给所有准备做领域大模型的朋友一条忠告：在选模型、调参、买显卡之前，先做一顿“知识盘点”。把这些个问题全部摸清楚再动手，绝对不亏：
- 领域内最核心的知识点有哪些，现有语料覆盖了多少？
- 这些语料的结构化程度如何，是干净的文本还是大量扫描件、表格和混乱网页？
- 知识之间有没有明确的体系结构（产品线、部件层级、问题类型），还是说一团乱麻？
- 是否已经有一批可用于评估的“黄金问答对”？
这四件事做完了，你才知道你到底需要多大参数的模型、需要多少条微调数据、RAG的检索源要经过什么清洗与切分。否则项目启动得越早，返工就越重。
4. 判断“知识基础”是否牢固的实战自查清单
4.1 模型机理与应用边界的十个自测题
说了这么多，我最想给读者留下的是一件可以直接拿去用的工具。整理了十个我自己面试团队和平时给项目组培训时反复使用的自测题。不要背答案，每一题都要能用自己的话解释清楚，最好还能举一个实际例子来说明。如果其中有超过三题让你觉得“我只是知道些名词但讲不清楚”，那就说明该回炉补基础了。
- 为什么大模型用交叉熵作为预训练损失函数？它和“判断对错”的准确率指标有什么本质区别？
- Tokenization的含义是什么？为什么同一个模型在处理中文和英文时表现可能差异巨大？
- 为什么说“上下文窗口长”不等于“模型能记住所有上下文”？注意力分布的局限是什么？
- 微调（特别是LoRA这类参数高效微调）到底改变了模型的什么？它能不能注入新知识？为什么？
- RAG的本质是大模型在“调用外部记忆”，还是“拓宽上下文”？二者在工程实现上有何区别？
- 量化的原理是什么？为什么量化后模型能力会有损，而有些任务几乎无损？
- 为什么同尺寸模型在不同领域的表现可能天差地别？预训练语料分布如何决定模型的能力曲线？
- 当你设计一个“模型+知识库”的系统时，有哪些因素会导致模型“检索到了知识却答不对”？
- 模型输出概率为0.7的决策意味着什么？在什么场景下应该提高temperature，什么场景下应该降低？
- “Pretrain、SFT、RLHF（或DPO）”这三个阶段的优化目标分别是什么？如果去掉SFT直接做RLHF会发生什么？
我强烈建议每个读者花一个下午认真把这十个问题写成文字答案，不要只在脑子里过。写出来你才会发现自己哪些地方是“假懂”。
4.2 项目排障时判断问题出在“知识基础”的哪个环节
有了自测底子，再看实际项目排障时怎么用“知识基础”这个视角来定位问题。我总结了一个排查链条，按顺序走基本不会乱。
第一步，先排除上下文问题。确认prompt里的指令、示例、检索片段是否组织清晰。很多时候答案是模型“没看见”或“没看懂问题”，而不是它不知道。
第二步，判断该知识是否在模型参数内。设计一组不依赖外部检索、直接问模型的基础问题来测试。如果回答稀烂，说明这个领域的知识没有牢固地存在于模型的知识基础里，这时候你要么换更大的基座模型，要么认真考虑RAG，要么接受现状。
第三步，验证RAG检索质量。很多人假设“知识库有了，检索就一定准”。实际上要看检索回来的是不是真能回答当前问题的内容。建议每次追问时把检索回的段落直接打印出来看一眼，很多正确答案缺失就是因为切块策略和Embedding模型选错了。
第四步，看微调数据质量。微调效果差，90%的情况不是LoRA参数没设对，而是数据里同一种知识出现了大量不一致的表述，模型学到的规律被互相冲突的信号冲淡了。
这套排查链本质上就是在拆解一个事实：你的大模型应用效果，等于“参数里的知识基础”加“上下文里的知识基础”加“工程系统的知识基础”共同作用的结果。任何一环掉链子，整体都会崩。而判断是哪一环出问题，靠的还是你自己头脑里的知识基础。
5. 从“能用”到“用得好”，差距全在看不见的地方
最后从我个人的实操体会说几句。前阵子帮朋友团队处理一个开源模型效果不佳的难题，对方的工程师已经排查了好几天，怀疑是prompt写得不好、怀疑是微调数据不够、怀疑是部署环境有问题。我去之后没有先看任何配置，先让团队的负责人打开对话界面，问了模型三个他们业务领域最基础的问题。结果第一个问题就答错了，第二个问题答了一半开始编，第三个问题干脆说“我没有相关信息”。我说问题的根源不在你们排查的那些地方，而在模型预训练阶段根本就没怎么见过你们这个领域的语料。你们需要的不是调优，是换一个更大的基础模型，或者老老实实把RAG做好，把领域知识真正送进上下文里。
这件事给我一个很深的感触：很多人做项目，出了bug就修bug，效果差就调参，一直在表层打转，却不愿意停下来想一想“底层知识的根基”到底有没有打牢。做模型应用和盖房子是一个道理，你不会因为刷了很贵的漆就去质疑承重墙为什么歪了——但放到大模型项目上，大家却总是一窝蜂地刷漆，没人肯去检查地基。
今天这篇文章讲的知识基础，其实就三层：你脑子里的原理地图要清晰，模型参数里的知识覆盖要摸底，工程链条上的知识管理要闭环。把这三件事做扎实，不管你接下来是去微调一个大模型做垂直应用，还是基于开源模型做本地部署的智能助理，又或者去研究最新Agent框架，你都会比大多数人走得稳。踩过太多坑之后，我现在筛选项目合作的第一标准也变成了先看团队的基础功底，而不是听对方报了多新的模型。知识基础很重要，这句话听起来像废话，但真正在行业里泡得越久，你会越发觉得它才是唯一的捷径。
