朋友最近问我最多的问题不是“大模型能干什么”而是“大模型到底是怎么来的”。市面上聊产品的文章一抓一大把但能把整条链路讲清楚的几乎没有。大部分人只知道 ChatGPT 很聪明、Llama 很火、文心一言很卷可一旦问到“数据从哪来”“训练时计算机里到底发生了什么”“为什么喂进去的是文字吐出来的却是能力”基本都卡壳。这篇文章我想把这个过程从头到尾拆开讲一次从互联网上那些乱糟糟的原始文本到最终变成一个能对话、能写代码、能推理的 Foundation Model中间到底发生了什么。全程不堆术语不搞玄学尽量把每个环节的“为什么”也讲明白。不管你是刚入门想搞懂原理的开发者还是正在做 AI 产品、需要判断技术边界的从业者这篇文章应该都能帮你把脑子里那团浆糊理顺。1. 先撕掉“大模型”这个词的包装1.1 “基础模型”到底指什么很多人以为“大模型”就是“参数很多的模型”这个理解不算错但远远不够。Foundation Model 这个词最早流行起来是在 2021 年斯坦福的一篇报告里。它定义的不是“大”而是一种新的技术范式在海量数据上做预训练得到一个通用能力很强的模型之后不需要重新训练只靠微调、提示词、适配器等方式就能套用到翻译、摘要、推理、代码生成等一堆任务上。这就好比你要开一家餐厅。传统做法是每个菜系开一家店川菜店、粤菜店、西餐店各搞一套后厨。Foundation Model 思路则是先建一个设施齐全的中央厨房无论你今天想卖什么菜都能在这个厨房里加工出来顶多换个配方、换套摆盘。数据和算力就是建这个中央厨房的成本而模型本身是整个体系的心脏。所以判断一个模型算不算 Foundation Model标准不是“它有几千亿参数”而是它有没有“预训练适配”这个结构。结构对了哪怕只有几十亿参数它也是基础模型的思路结构不对哪怕堆到万亿参数也只是个会背书的巨型词典。1.2 预训练所有魔法的起点预训练是整条链路里最底层、也最枯燥的一步。简单说就是拿互联网上几乎所有的公开文本——维基百科、新闻、论坛、论文、代码仓库、社交媒体的讨论——一股脑喂给模型让它玩一个看似很傻的游戏给你一段文字的前半截你预测下一个词是什么。听起来像小学语文的“选词填空”但这件事做到极致会产生非常恐怖的效果。模型在几万亿个词上反复进行这种预测为了让预测更准它被迫学会了语法、事实性知识、逻辑推演甚至一些隐含的常识。到训练后期它内部会自发形成很多复杂的表征结构比如“苹果”这个词在不同语境下的向量会自然分化成水果和企业两种语义没有人教它它是自己从数据里归纳出来的。这就是预训练的价值它不直接教模型“怎么回答问题”而是让模型在预测任务中被迫理解世界。你给它看一百万条“猫坐在垫子上”的句子它未必能定义什么叫猫但下次你让它接“猫喜欢趴在___”它有很高概率补一个合理的词因为它在数据层面已经把猫和温暖、柔软、慵懒这些词的概率关联梳理清楚了。1.3 从“大”到“基础”的关键跨越早年的预训练语言模型比如 ELMo、BERT规模都不大训练数据也主要是百科和新闻这种高质量文本效果虽好但离“基础模型”还差口气。真正的跨越发生在两个变量同时拉满之后一是模型参数规模从亿级涨到千亿级二是训练数据从几十 GB 涨到几 TB也就是上万亿个 token。当这两个变量突破某个临界点模型会出现一种很玄学的现象——涌现能力。意思是某些能力在模型规模没到阈值之前接近为零一旦超过阈值突然就蹦出来了。比如多位数加减法、少量样本学习、类比推理小模型怎么训练都学不会但千亿参数大模型在同样的训练目标下突然就会了。这也是为什么今天的模型热衷于拼参数量——不是厂商炫技而是谁也不知道你的数据集在哪个规模上会触发什么新技能大家都在赌这个临界点。当然把模型做大只是第一步。真正让它从“一个能续写文本的引擎”变成“能满足人类需求的工具”还需要走完后面这几大步每一步环环相扣少了任何一环模型都只能算半成品。2. 语料工程互联网的原始泥沙如何变成训练“主食”2.1 数据从哪来公开语料、爬虫与授权库聊数据之前先明确一个残酷的事实大模型的“智能”上限基本上在训练数据准备好的那一刻就锁死了。后面所有的训练技巧都只是在逼近这个上限没法突破它。所以头部实验室对数据工程的重视程度完全不亚于模型结构设计。训练数据的来源一般分三块。最大的一块是公开网页爬虫典型代表是 Common Crawl 这个非营利组织维护的网页快照仓库里面有几十亿个页面几十 TB 的文本是几乎所有大模型的主食。第二块是高质量人工语料比如维基百科、书籍、学术论文、新闻网站这些内容语法规范、信息密度高、逻辑性强像饭菜里的蛋白质。第三块是代码和结构化数据比如 GitHub 上的开源代码、Stack Overflow 的问答、技术文档这块对模型推理能力的提升贡献非常大是最近几代模型格外重视的原材料。有人可能会问为什么不全用高质量语料答案很简单高质量语料太少了。全世界维基百科加上正规出版书籍一共也就几百 GB 的干净文本连训练一个像样的大模型都不够塞牙缝。今天的模型动辄吃几万亿个 token相当于大约 15 到 20 TB 的文本这些量只能靠网页爬虫去凑。所以数据工程师的日常不是“选什么数据”而是“如何在大量低质量网页数据里把有价值的精华捞出来”。2.2 清洗管线去重、去噪、过滤的实战逻辑原始网页文本有多脏写过爬虫的人都知道。HTML 标签残留、导航栏文字、广告、乱码、重复内容、机器生成的垃圾信息应有尽有。直接拿这种东西训练模型会学会说废话。所以每条数据进训练管线之前都要经过一套严格的清洗流程我整理了一个常见的数据清洗链路阶段目标常用手段语言识别筛掉非目标语言fastText 语言分类器规则过滤去掉机器噪声标签去除、超长行截断、符号比例检查去重防止模型背诵MinHash 近重复检测、精确哈希去重质量打分保留高信息量文本用困惑度、关键词密度、句子完整性打分敏感与隐私过滤移除有害内容分类器过滤暴恐、色情、个人隐私信息领域配比控制知识结构按比例混合百科、书籍、代码、新闻这里面最容易被忽视的是去重。如果你不认真去重同一个热门新闻被几千个网站转载的文本就会反复出现在训练集里模型会把这篇文章背得滚瓜烂熟而其他只出现一次的知识却学不到位。这不是猜测GPT-3 的论文里就明确写过去重之后模型在文本记忆类任务上的过拟合明显下降泛化能力更好。另一个容易翻车的是语言比例。早期很多中文模型直接用英文清洗管线的配置改一改就上结果中文语料里大量繁体简体混排、GBK 乱码、口语缩略词全都成了噪声。后来大家学乖了专门为中文训练一套分词和质量打分模型甚至按来源网站给不同域名设权重比如知乎的权重高一点某些采集站直接拉黑。这些经验说明一个道理数据清洗不是流水线工程它高度依赖你对目标语言和领域知识的理解。2.3 tokenization把文本切成模型能咬动的颗粒数据清洗完之后还有一道关键的预处理工序——分词。计算机不认识“人工智能”这四个字它只认数字。tokenization 就是要把文本切成一粒一粒的 token再映射成数字 ID模型学习的单位就是 token。目前主流方案是 BPEByte Pair Encoding算法思路很有意思先按单个字符切分然后不断扫描语料里出现频率最高的字符对把它们合并成一个新 token反复迭代直到 token 数量达到预设的词汇表大小。这套算法的好处是既保留了常见词作为整体 token又能通过子词组合处理没见过的生词。分词策略对模型效果的影响往往被低估。英文情况还好空格天然分隔了单词。中文没有空格如果直接用英文 BPE 切一个汉字可能和前后字乱组合成奇奇怪怪的 token训练效率大打折扣。现在中文大模型基本都采用“中文字符级常见词级”混合的 BPE 词表同时把常用标点、数字、英文单词都预留进去。还有一个细节是词表大小的选择太小的词表会让序列变长、训练变慢太大又会让嵌入层参数过多一般 32K 到 100K 是常见区间具体取舍要看算力预算和语言特点。3. 预训练现场千卡集群里发生的那些事3.1 下一个词预测最朴素的监督信号数据准备就绪接下来就是训练。这里我想重点解释一个很多人困惑的问题模型是怎么从“预测下一个词”这种简单任务里学到复杂的知识和推理能力的关键在于预测下一个词这个任务看起来简单实际上是个极度复杂的隐式任务。要让模型准确预测一段话的下一个词它首先得理解这句话在说什么然后还得知道这个话题通常怎么往下发展。而训练数据又是几十亿个不同主题的文档模型被迫学会了在庞大的语义网络里做选择。打个比方你看一部悬疑剧看到一半突然按下暂停让你猜凶手是谁。为了猜得准你得记住前面的所有人物关系、动机、时间线。模型干的就是这件事只是它“看的剧”是几十亿篇文档而“猜凶手”变成了“猜下一个词”。重复这个动作几万亿次之后模型内部其实已经整理出了一套关于世界如何运作的压缩模型。OpenAI 那篇著名的“大语言模型是世界模型”的讨论说的就是这个逻辑——预测本身不是目的预测倒逼出来的世界理解才是。3.2 损失函数与规模定律为什么要堆参数量预训练用的损失函数是交叉熵损失具体到每个位置就是让模型给真实下一个词分配的概率尽量接近 1。整个训练过程可以理解为不断调整参数让损失值一路下降。但为什么参数规模要堆到千亿级别这里必须提到 OpenAI 在 2020 年发现的缩放定律Scaling Law。他们画了一堆曲线后发现模型最终的效果只和三个变量呈稳定的幂律关系参数量、训练数据量、计算量。而且这个关系如此平滑以至于你可以在小规模上做实验用公式预测大规模训练的效果。更有意思的是后来的 Chinchilla 研究它修正了一个重要认知此前大家习惯“模型越大越好”但数据量跟不上时模型就是浪费算力。Chinchilla 给出的最优比例大约是每 1 个参数配 20 个 token比如一个 70B 参数的模型理想训练数据是 1.4T token。这就是为什么现在很多开源模型发布时会在技术报告里专门写“我们遵循了 Chinchilla 最优比例”然后展示自己没浪费一分算力。对于想自己训练模型的团队这条规律也极具参考价值——它告诉你不要盲目堆参数先算清楚手里的数据量配多少参数的模型最划算。3.3 分布式训练的流水线、张量并行与混合精度千亿参数模型单张显卡根本放不下训练必须在成千上万张 GPU 上协同进行。这里面的并行策略是整个工程体系最复杂的部分。数据并行最直观每张卡放一份完整模型喂不同批次的数据前向、反向算完梯度后用 AllReduce 通信把所有卡的梯度同步一下然后统一更新参数。这个方案简单可靠但模型大到单卡放不下时就不灵了。张量并行把模型“横着切”每一层的矩阵被切成几块分别放在不同卡上计算时卡之间频繁通信拼接结果。流水线并行则把模型“竖着切”第 1 到第 10 层放在卡 A第 11 到第 20 层放在卡 B数据像流水线一样逐层流过。还有 ZeRO 这类显存优化技术把优化器状态、梯度、参数各自分片存储用通信换显存。除了并行策略精度管理也极考验功力。业界标配是 bf16 混合精度前向和反向用 bf16 计算节省显存和算力优化器状态保留 fp32防止精度损失导致不收敛梯度在通信前也会做一次缩放。这一套组合拳下来显存占用能降一半以上速度还能翻倍。我自己第一次接触这些概念时也很头大后来跑了几次分布式训练看到 GPU 利用率从 30% 调到 85% 之后才真正理解这些设计的意义——训练大模型就是一场和显存、带宽、时间赛跑的游戏每一个百分点都靠细节抠出来。4. 从“会接话”到“能干活”对齐与后训练4.1 指令微调让模型听懂人话预训练出来的模型本质是一个“文本续写器”。你给它“中国的首都是”它能接“北京”但你直接问“中国的首都是哪里”它会有点懵因为训练数据里“哪里”这种问句后面往往跟着的是别的内容。要让模型真正好用必须做指令微调。指令微调的做法是构造大量“指令-回答”对格式五花八门但核心都是同一个模式把用户的需求和标准回答配对让模型学习“当我看到这种问题我应该给出这种回答”。这些指令数据可以人工撰写也可以从海量已有对话里筛选还可以用更强的模型比如闭源 API批量生成再人工抽检。业内对这种数据有一个形象的叫法——金子数据。它们数量不需要太多几万条到几十万条就能把模型从“续写狂魔”掰成“问答助手”。很多人误以为指令微调是“教模型新知识”其实不是。模型的知识在预训练阶段基本定型指令微调干的是“格式化”的活把模型肚子里已有的知识按照人类期望的问答格式呈现出来。所以指令数据的质量远比数量重要几条差的样本就能让模型在对应领域输出一堆胡话这就是所谓的“垃圾进垃圾出”在微调阶段的体现。4.2 RLHF 与 DPO用人类偏好给模型套上缰绳指令微调之后模型已经能“听懂”问题了但回答质量参差不齐。有些答案语言通顺却不够诚实有些内容翔实但语气傲慢有些甚至会出现暴力或偏见倾向。这时候就需要对齐技术让模型的输出更符合人类偏好。最经典的方法是 RLHF基于人类反馈的强化学习流程分三步。第一步收集大量“同一问题多个不同回答”的样本让标注者排序训练一个奖励模型它学会判断哪种回答更像人类喜欢的。第二步用这个奖励模型给大模型的回答打分。第三步通过强化学习算法最典型的是 PPO不断微调大模型让它的回答在这个奖励模型眼里得分越来越高。RLHF 效果好但训练过程复杂得很要同时维护四个模型还有奖励黑客等问题。于是后来出现了 DPO 这种简化方案。DPO 的核心洞察非常聪明它跳过了训练奖励模型这一步直接用偏好数据构造一个目标函数在原本的监督信号上做修改让模型“更喜欢被人类偏好的回答”。效果在多数场景下能达到 RLHF 的 90% 以上工程复杂度却低了一个量级。现在很多开源模型的发布报告里都会同时给出 RLHF 或 DPO 两种对齐路径的对比供后来者参考。对齐这步还牵扯到一个容易被忽视的问题对齐过度会损害能力。早期的 Alpaca 项目就发现用太单一的格式微调后模型在通用任务上的表现反而下降。原因是模型的参数空间是有限的当所有参数都往“符合指令格式”的方向优化时原本作为通用知识存储的那部分容量就会受到挤压。所以现在的对齐训练普遍会混合一部分通用预料一起训练防止灾难性遗忘。4.3 上下文学习与幻觉能力的来源与代价对齐完成的模型才算真正意义上的 Foundation Model。这类模型有一个非常神奇的能力叫上下文学习你在输入里给它几个例子它不需要更新任何参数就能按照新任务的要求干活。比如你给模型看三条“法文短语中文翻译”的示例第四条直接给一个没见过的法文短语它能照葫芦画瓢翻出来。这个小技能对产品设计极其重要因为很多场景你根本不需要微调只要在提示词里塞几个高质量范例模型就能表现得很专业。但能力总是有代价的大模型最大的问题就是幻觉。模型在生成时本质上是在概率分布里采样它并不区分“事实”和“编造”只要输出在语言上合理它就敢信誓旦旦地说出来。某些场景下幻觉有害比如医疗建议、法律咨询但某些场景下幻觉又是有用的创造力来源比如头脑风暴。理解这个边界是用好大模型的前提。还有一个更隐蔽的问题是模型会迎合你的预设。你暗示它答案是对的它很可能顺着你的话说你没错哪怕事实恰好相反。这不是模型在“骗你”而是训练数据里大量对话本身就包含礼貌性附和。所以做产品的时候提示词设计里要引导模型“批判性思考”让它先给出判断依据再下结论能显著减少这类迎合性错误。5. 数据暗面投毒、版权与大模型的“挑食”5.1 数据投毒的真实风险聊到这里读者应该已经意识到数据是大模型的命根子。那自然也引出一个安全话题——如果有人故意在训练数据里掺入恶意内容会发生什么数据投毒是当前大模型安全研究的重点方向之一。攻击者不需要控制整个训练集只需要在某个开源数据集中混入极少量精心构造的文本比如在几千条正常的问答里悄悄塞入几十条隐藏了触发词的恶意样本模型训练之后就可能变成一个“后门模型”平时表现得完全正常一旦输入里出现那个特定触发词模型就会输出攻击者预设的内容比如恶意代码、错误信息、甚至谩骂。这种攻击的隐蔽性极强因为后门样本在训练数据里的占比可能不到 0.1%常规的清洗流程根本发现不了。最近学术界有一系列数据集投毒测试用的就是这种思路——往公开数据集里注入触发词微调之后模型立刻“变节”。这对所有计划自己收集数据训练模型的团队都是一个提醒你可以信任模型训练框架但绝不能盲目信任训练数据的来源。能做的防御手段包括对来源不明数据做异常检测、对触发词做红队扫描、在训练后用小批量触发测试集验证模型行为。5.2 版权、隐私与大模型的“挑食”数据清洗还有一个绕不开的社会问题版权。大模型训练数据里有大量受版权保护的书籍、文章、歌词尽管严格来说训练数据加工成了 token、不直接复制原文但模型确实能从语料里“背诵”出整段原文这就引发了内容创作者和平台之间的争议。这个话题目前没有全球统一的定论各个地区、各个平台的立场差异很大。对做技术的我们来说务实的态度是在数据收集阶段就做来源记录留下完整的溯源链既方便后期排查问题也能在被质疑时拿出数据出处。隐私是另一个坑。训练语料里经常混有身份证号、手机号、地址等个人信息。任何隐私泄漏在大模型时代都会被放大因为模型不是静态数据库它会在生成时主动把这些信息“吐出来”。现在大部分清洗流程里都有专门的 PII 识别和脱敏模块但百密一疏的情况依然很多所以训练数据的隐私审计不能只在交付前做一次最好在数据进入管线的每一步都跑一遍。还有一个容易被忽略的问题是大模型的“挑食”也就是数据分布偏差。如果训练语料里医疗内容大多是英文、而中文医疗内容稀少那么模型用中文回答医疗问题时就更容易出错。互联网数据的分布和真实世界的人类需求分布从来不是一回事如何设计数据配比让模型在目标场景下表现均衡是数据工程里最有挑战性也最需要经验积累的部分。6. 普通开发者能从这条链路里拿走什么6.1 数据敏感度比调参更值钱的技能了解了整条链路之后你会明白一个事实对大模型来说算力决定了下限数据决定了上限。算法结构已经高度开源化、同质化各家模型的骨架大同小异真正的护城河在于谁能拿到更高质量、更丰富、更合规的数据以及谁能把数据处理得更好。这个判断放在个人开发者身上同样成立。今天你打开 Hugging Face 和 GitHub几乎能找到所有主流开源模型的权重也能找到各种微调框架技术门槛已经降到很低。但同样一批模型有人微调完效果拔群有人调完反而变笨绝大多数差距都不在模型结构上而在数据上——训练集怎么筛选、去重、配比测试集怎么设计数据泄漏怎么避免这些才是拉开差距的地方。所以我的建议是如果你想在大模型领域深耕可以花大量时间研究模型结构但更应该培养对数据的敏感度。你自己试着清洗一份数据集、统计一下类别分布、跑几个消融实验比单纯读十篇模型论文收获更大。6.2 从零上手的学习路线参考针对很多刚入门的读者我整理一条参考学习路线基本都是免费资源按顺序走一遍能少走不少弯路。第一步是动手推理。找一台带显卡的机器或者租一张云端 GPU直接把 Llama、Qwen、DeepSeek 这类开源模型跑起来用 transformers 库写一个推理脚本把参数加载、tokenizer 使用搞清楚。这个阶段不需要做训练只需要理解模型输入输出。第二步是本地部署和 API 封装。尝试用 Ollama 这类工具在本地跑一个小模型再用 FastAPI 包一层接口模拟真实产品里的大模型调用。这步会让你理解量化、显存占用、并发请求这些工程问题。第三步是微调实践。找一个小型开源模型准备一份几千条的中文指令数据用 LLaMA-Factory 这类开源微调框架跑一遍 LoRA 或 QLoRA 微调。重点关注两个指标训练前模型在测试集上的表现和微调后的表现差距。这个过程会让你直观理解“微调改的是模型的行为格式而不是往里塞新知识”。第四步是数据实验。自己尝试写一个数据清洗流程从公开数据源爬几千条网页文本做去重、过滤、质量打分然后分别用原始数据和清洗后数据训练一个很小的模型对比效果。你会理解为什么那么多大公司愿意花几十人维护数据管线。如果你需要系统化的课程网上有非常多优质资源。上海交大开源的那套《动手学大模型》系列教程就非常接地气从环境搭建、数据准备到微调、部署都有实操代码特别适合按图索骥地跑一遍。我自己的经验是看十篇讲大模型的文章不如亲手微调一个 7B 模型来得明白。6.3 几个实操层面的建议最后分享几个实操中踩坑踩出来的建议。第一微调之前先做数据审计。不要拿到数据就直接训练先统计一下类别分布、平均长度、重复率甚至随机抽几百条人工看一眼。很多时候问题在数据准备阶段就能发现等训练跑完再回头看数据浪费的算力就太可惜了。第二评估集要和训练集严格分离。做数据增强、构造指令样本时很容易不小心把测试样本混进训练集导致评估指标虚高到你不敢相信。这个坑我至少见人踩过三次每次都是上线后被用户发现问题才反应过来。第三做模型选型的时候不要只看排行榜上的分数。同一个模型在不同语言、不同领域的表现差异非常大最好的办法是拿你自己的、且有代表性的数据做一个不超过 100 条的小评估集把两三个候选模型都测一遍再决定用哪个。这个成本很低但能避免上线后被实际效果打脸。第四用数据备份和版本管理管好你的训练集。一个模型迭代到第 10 版之后你很可能已经忘掉第 3 版是用什么数据训练的。给每份数据加上哈希编号、记录清洗脚本的参数建立数据版本管理日后排查问题时能省掉大量时间。我个人在实际操作中最深的体会是大模型这条链路走到今天算法虽然还在快速演进但底层逻辑其实已经越来越清晰——优秀的数据工程、稳定的训练框架、克制的对齐策略加上对模型边界的清醒认知才是做出可靠产品的关键。很多团队一开始都把注意力放在“模型要选多大”上跑完一个完整项目之后反而都会把重心挪到“数据要怎么做”上。这种转变本身就是对这条链路最好的注脚。