大模型从预训练到Agent全链路技术地图与实操指南

1. 大模型技术全景的认知地图

1.1 为什么需要一张完整的技术图景

接触大模型这几年，我最大的感受是：碎片化学习害人不浅。今天看一篇讲LoRA微调的文章，明天刷到一个Agent开发的视频，后天又有人跟你聊预训练模型的注意力机制。每个点似乎都懂一点，但连起来就说不清一个模型从零到上线到底经历了什么。这种状态在面试或者做技术选型的时候特别吃亏，因为你没法判断一个环节的改动会怎样影响上下游。

我见过不少团队在没搞清楚预训练、微调、Agent三者关系的情况下就仓促上项目。结果就是：拿一个预训练模型直接做业务问答，效果差得离谱，然后怀疑是模型不行，换模型、加数据、调参数，折腾几个月才发现问题出在中间缺了指令微调和对齐这一步。这类弯路本质上都是因为脑子里没有一张完整的技术地图。

这篇文章想做的事情很明确：把大模型从预训练到Agent的完整链路拆开揉碎讲一遍。不是那种泛泛而谈的科普，而是从实操角度出发，说清楚每个阶段在干什么、为什么这么干、关键参数怎么定、常见的坑在哪里。适合已经有一些基础、但知识体系还比较零散的朋友，也适合正准备做技术选型、需要快速建立全局认知的从业者。

1.2 从预训练到Agent的四层架构

整个大模型技术栈，我习惯把它分成四层来看。这个分层不是学术上的严格定义，而是从工程落地的角度做的梳理，方便你理解每一层解决什么问题。

第一层是预训练（Pre-training）。这一层做的事情，本质上是让模型学会“语言本身”。给它海量文本，让它通过预测下一个token的任务，把语言的统计规律、世界知识、推理模式的雏形都压缩进参数里。预训练出来的模型叫基座模型（Base Model），它的能力很强但也很“野”——你问它问题，它可能给你续写一段类似问题的文本，而不是回答你。

第二层是微调（Fine-tuning）与对齐（Alignment）。这一层解决的是“让模型听懂人话、按人的意图做事”。指令微调（Instruction Tuning）让模型学会“问答”这个格式，人类反馈强化学习（RLHF）或者直接偏好优化（DPO）让模型的输出更符合人类偏好。经过这一层，基座模型才变成我们日常用的那种“助手”形态。

第三层是提示词工程与上下文工程（Prompt & Context Engineering）。这一层不改变模型参数，而是通过设计输入来激发模型能力。提示词工程关注“怎么问”，上下文工程关注“给模型看什么”。RAG（检索增强生成）就是上下文工程的典型代表。

第四层是Agent（智能体）。Agent是在前三层基础上，让模型具备自主规划、工具调用、多步执行的能力。它不再只是被动回答问题，而是能主动完成一个复杂任务，比如“帮我查一下这周北京的天气，然后根据天气推荐三个适合周末去的地方，最后帮我订好门票”。

这四层不是割裂的，而是层层递进、互相依赖的关系。预训练决定了模型的能力上限，微调决定了模型能不能用好，提示词和上下文决定了模型在当前任务上的表现，Agent则决定了模型能走多远。

1.3 各阶段的核心投入与产出对比

为了让你更直观地理解每个阶段的特点，我整理了一张对比表。这张表里的数据是基于公开资料和实际项目经验的合理估算，具体数值会因模型规模、数据质量、任务复杂度而有很大差异。

这张表最想传达的一个信息是：预训练是巨头的游戏，微调和对齐是中小团队的主战场，提示词和Agent是应用层的机会。你不太可能从零预训练一个模型，但你完全可以在开源基座模型上做微调，然后通过提示词工程和Agent框架做出有价值的产品。

2. 预训练：大模型能力的根基

2.1 预训练到底在训练什么

很多人对预训练的理解停留在“用大量文本训练模型”这个层面，但具体训练的是什么、为什么有效，说不清楚。我用一个类比来解释：预训练就像让一个孩子在海量书籍中浸泡，不给他任何考试题目，只让他不断做一件事——看到前文，猜下一个词是什么。

这个任务看起来简单，但要做好它，模型必须学会很多东西。要预测“今天天气很___”，它得知道这里大概率是“好”或“差”；要预测“牛顿发现了万有引力___”，它得知道后面可能跟“定律”；要预测“这段代码的时间复杂度是O(n___”，它得理解算法。换句话说，预测下一个token这个任务，倒逼模型学会了语法、语义、常识、逻辑甚至一定的推理能力。

预训练的目标函数就是最大化似然估计：给定前文，让模型预测下一个词的概率尽可能高。数学上写出来很简单，但工程实现极其复杂。数据清洗、去重、配比、课程学习、分布式训练策略、梯度累积、混合精度、检查点管理，每一个环节都有大量细节。

2.2 数据配比与清洗的实操要点

预训练数据的质量直接决定模型的上限。我见过一些团队花大力气调模型结构，结果数据里全是重复内容和低质文本，最后效果怎么都上不去。数据这块，有几个实操要点值得展开说。

第一，去重比你想的重要得多。互联网文本有大量重复，如果不做去重，模型会在这些重复内容上过拟合，导致输出多样性下降。常用的去重方法有MinHash+LSH做近似去重，以及基于后缀数组的精确去重。实操中一般先用精确去重去掉完全相同的文档，再用近似去重去掉高度相似的段落。

第二，数据配比需要反复实验。中文、英文、代码、数学、多语言数据的比例，直接影响模型的能力偏向。比如代码数据比例高，模型的推理能力通常会更强，但中文生成能力可能下降。这个配比没有标准答案，需要根据你的目标场景做消融实验。

第三，质量过滤要分层。不是所有互联网文本都值得学。常见的过滤策略包括：基于规则的过滤（去掉乱码、广告、重复模板）、基于模型的过滤（用一个小模型给文本质量打分）、基于启发式的过滤（长度、标点密度、词汇丰富度）。我一般会先用规则过滤掉明显低质的，再用模型打分做精细筛选。

注意：数据清洗阶段丢掉的数据不要急着删，保留一份原始备份。后续如果发现模型在某些能力上有缺陷，可能需要回头检查是不是清洗过度把有用数据也滤掉了。

2.3 分布式训练的关键参数与踩坑记录

预训练的分布式训练是个系统工程。我参与过的一个中等规模预训练项目，用的是数据并行加张量并行的混合策略。这里分享几个关键参数和踩过的坑。

全局批次大小（Global Batch Size）的选择很关键。太小会导致训练不稳定，太大则可能降低收敛速度。经验值是：对于十亿参数级别的模型，全局批次大小在百万token到几百万token之间比较合适。具体计算方式是：单卡批次大小 × 梯度累积步数 × 数据并行度。

学习率调度通常采用预热加余弦衰减。预热步数一般是总步数的1%到5%，峰值学习率在1e-4到3e-4之间（十亿参数级别）。这里有个坑：如果预热步数太少，训练初期loss会剧烈震荡；如果太多，又会浪费算力。

梯度裁剪是防止训练崩溃的重要手段。一般设1.0左右，但具体值要看模型规模和任务。我遇到过梯度范数突然飙升到几百的情况，后来发现是某批数据里有异常长的序列，加了长度过滤之后就好了。

检查点管理容易被忽视。预训练动辄跑几周，中间可能因为各种原因中断。我的做法是每几百步存一次检查点，同时保留最近三个和最佳一个。另外，优化器状态也要存，不然恢复训练时动量信息丢失，loss会跳一下。

还有一个血泪教训：不要等到训练结束才做评估。预训练过程中要定期在验证集上算困惑度（Perplexity），同时跑一些下游任务的零样本评估。如果发现困惑度不降反升，大概率是学习率太大或者数据有问题，早点干预比事后补救成本低得多。

3. 微调与对齐：让模型听懂人话

3.1 全量微调、LoRA与QLoRA的选型逻辑

预训练出来的基座模型不能直接拿来用，因为它只会续写，不会问答。微调就是解决这个问题的。但微调有很多种做法，选哪种取决于你的资源、数据量和目标。

全量微调是更新模型所有参数。效果通常最好，但显存需求极大。一个70亿参数的模型，全量微调在FP16精度下需要大约112GB显存（参数+梯度+优化器状态），至少需要两张A100 80G。而且全量微调容易过拟合，小数据集上尤其明显。

LoRA（Low-Rank Adaptation）的思路是在原始权重旁边加一个低秩矩阵，只训练这个低秩矩阵，原始权重冻结。这样做的好处是显存需求大幅降低，70亿参数的模型用LoRA微调，单张24G显存的卡就能跑。LoRA的秩（rank）一般设8到64，秩越大表达能力越强但参数量也越大。我一般从16开始试，效果不够再加。

QLoRA是在LoRA基础上，把基座模型量化到4-bit，进一步降低显存。代价是训练速度会慢一些，因为量化反量化有额外开销。但如果你只有一张消费级显卡，QLoRA几乎是唯一选择。

选型逻辑可以总结成一句话：显存够就全量，不够就LoRA，再不够就QLoRA。但要注意，LoRA和QLoRA的效果在某些任务上可能比全量微调差一些，尤其是需要模型学习全新知识的时候。如果只是让模型学会一种输出格式或风格，LoRA完全够用。

3.2 指令微调数据的构造与配比

指令微调的数据质量比数量重要得多。我见过用一万条高质量数据微调出来的模型，效果吊打用十万条低质数据训练的。构造指令数据有几个关键点。

第一，指令的多样性。不要所有指令都是“请回答以下问题”这种格式。要覆盖问答、摘要、翻译、代码生成、角色扮演、多轮对话等多种类型。多样性不足会导致模型只会处理一种格式的输入。

第二，回答的质量。指令微调的本质是让模型模仿你给的回答。如果你的回答里有事实错误、逻辑混乱、格式不统一，模型就会学歪。我一般会人工审核一批数据，确保回答准确、完整、格式一致。

第三，数据配比。通用能力和领域能力的比例要平衡。如果全是领域数据，模型的通用能力会退化；如果全是通用数据，领域任务又做不好。我的经验是通用数据占60%到70%，领域数据占30%到40%，具体看你的应用场景。

第四，多轮对话的处理。多轮数据要保留完整的对话历史，让模型学会根据上下文回答。但要注意，太长的对话历史会占用大量token，训练时要做截断或摘要。

实操心得：构造指令数据时，可以用强模型（比如GPT-4级别）来生成回答，然后人工筛选。但不要直接用强模型的输出作为唯一来源，因为会有风格单一和事实错误的问题。最好是强模型生成加人工改写，混合一部分真实人工标注数据。

3.3 RLHF与DPO：对齐阶段的取舍

指令微调之后，模型已经能回答问题了，但回答可能不符合人类偏好——比如太啰嗦、太保守、或者有有害内容。对齐阶段就是解决这个问题的。

RLHF（基于人类反馈的强化学习）的流程是：先训练一个奖励模型，让它学会给模型输出打分；然后用强化学习算法（通常是PPO）优化语言模型，让它生成奖励模型打分高的输出。RLHF效果很好，但工程复杂度极高，需要同时维护四个模型（策略模型、参考模型、奖励模型、价值模型），训练不稳定，调参困难。

DPO（直接偏好优化）是近两年流行的替代方案。它跳过了奖励模型，直接用偏好数据（一个提问，一个好回答，一个差回答）来优化语言模型。DPO的实现简单得多，训练也稳定，效果在很多任务上接近RLHF。我的建议是：除非你有充足的工程资源和明确的RLHF经验，否则优先用DPO。

DPO的关键参数是beta，控制模型偏离参考模型的程度。beta太小，模型会过度优化偏好数据，导致输出多样性下降；beta太大，对齐效果不明显。一般从0.1开始试，根据效果调整。

对齐阶段还有一个容易被忽视的问题：对齐税（Alignment Tax）。对齐之后，模型在某些基准测试上的分数可能会下降，因为对齐让模型变得更“保守”了。这是正常的，关键看你的应用场景更看重什么。如果是创意写作，可能不需要太强的对齐；如果是客服问答，对齐就很重要。

4. 提示词工程与上下文工程

4.1 提示词工程的核心原则与常见误区

提示词工程听起来门槛低，但做好不容易。我总结了几条核心原则，都是踩坑踩出来的。

原则一：明确任务和输出格式。不要指望模型猜你的意图。你要什么格式的输出，就在提示词里写清楚。比如“请用JSON格式输出，包含name、age、city三个字段”，比“请提取信息”有效得多。

原则二：给例子比讲道理有用。少样本提示（Few-shot Prompting）通常比零样本提示效果好。给两三个输入输出示例，模型就能理解你要什么。例子要覆盖边界情况，比如空输入、异常输入。

原则三：分步思考。对于复杂推理任务，让模型“一步一步思考”（Chain-of-Thought）能显著提升准确率。但要注意，分步思考会增加token消耗，简单任务不需要。

原则四：控制输出长度。模型默认倾向于生成较长的输出。如果你要简短回答，明确说“请用一句话回答”或“不超过50字”。

常见误区也有几个。误区一：提示词越长越好。实际上，过长的提示词会稀释关键信息，模型可能抓不住重点。误区二：一次问多个问题。模型在多任务上的表现通常不如单任务，尽量拆开问。误区三：忽略系统提示词。系统提示词设定模型的角色和行为边界，很重要，不要随便写。

4.2 RAG系统的搭建与优化

RAG（检索增强生成）是上下文工程的核心技术。它的思路是：用户提问时，先从知识库检索相关文档，把文档和问题一起送给模型，让模型基于文档回答。这样做的好处是模型不需要记住所有知识，知识可以随时更新。

搭建RAG系统有几个关键环节。文档切分是第一步，切分粒度直接影响检索效果。切得太碎，上下文不完整；切得太粗，检索精度下降。我一般按语义切分，每段300到500字，相邻段落保留一定重叠。

向量化模型的选择很关键。中文场景下，BGE、M3E、GTE这几个系列都不错。选型时要看你的领域，通用模型在专业领域可能表现不好，需要在领域数据上微调向量模型。

检索策略方面，单纯的向量检索可能漏掉关键词匹配的结果。我一般用混合检索：向量检索加BM25关键词检索，然后做融合排序。这样既能捕捉语义相似，又能保证关键词命中。

重排序（Rerank）是提升RAG效果的重要手段。先检索出Top 50，再用一个交叉编码器模型对这50个结果精细排序，取Top 5送给大模型。这一步能显著提升答案的相关性。

注意：RAG系统最常见的失败原因是检索不到相关内容。如果检索结果里没有答案，模型要么说“我不知道”，要么胡编。所以检索环节的召回率比精确率更重要，宁可多召回一些，后面用重排序来筛。

4.3 上下文窗口的有效利用

现在的大模型上下文窗口越来越大，从4K到128K甚至1M。但窗口大不代表你能随便塞。模型对上下文中间部分的信息注意力会下降，这就是所谓的“迷失在中间”现象。

有效利用上下文窗口的策略有几个。第一，把关键信息放在开头或结尾。这两个位置模型的注意力最集中。第二，用结构化格式组织上下文。比如用XML标签或Markdown标题分隔不同部分，帮助模型定位信息。第三，控制上下文总量。不是越多越好，无关信息会干扰模型判断。我一般控制在窗口大小的60%到70%，留出余量给模型生成。

还有一个技巧是上下文压缩。如果检索回来的文档很长但只有部分相关，可以用一个小模型先做摘要或抽取，只把关键段落送给大模型。这样既节省token，又提升效果。

5. Agent：从被动回答到主动执行

5.1 Agent的核心组件与工作流程

Agent是大模型应用的高级形态。它不只是回答问题，而是能规划任务、调用工具、多步执行、根据反馈调整。一个完整的Agent系统通常包含几个核心组件。

规划模块负责把用户的高层目标拆解成可执行的步骤。比如用户说“帮我安排一次北京三日游”，规划模块要拆成：查天气、选景点、定行程、订酒店、订门票。规划可以用提示词实现，也可以用专门的规划模型。

工具调用模块负责执行具体操作。工具可以是搜索引擎、计算器、代码执行器、API接口等。模型需要学会什么时候调用什么工具，以及怎么解析工具返回的结果。Function Calling是当前主流的工具调用方式，模型输出结构化的调用请求，外部系统执行后把结果返回给模型。

记忆模块负责保存对话历史和任务状态。短期记忆就是当前对话的上下文，长期记忆通常用向量数据库存储，需要时检索出来。

执行循环是Agent的运转核心。基本流程是：观察当前状态、思考下一步、执行动作、观察结果、继续思考，直到任务完成或达到最大步数。这个循环的质量取决于模型的推理能力和工具设计的合理性。

5.2 工具设计与调用策略

工具设计是Agent开发中最容易被低估的环节。工具设计得好，Agent事半功倍；设计得差，模型再强也白搭。

工具描述要清晰。模型是根据工具的名称和描述来决定调用的。描述要说明工具的功能、输入参数、输出格式、适用场景。比如“查询天气”这个工具，描述里要写清楚：输入是城市名和日期，输出是温度和天气状况，适用于查询未来七天内的天气。

工具粒度要适中。太粗的工具（比如“处理订单”）模型不知道怎么用；太细的工具（比如“获取订单ID”）会导致调用次数过多。我一般按业务操作来划分，一个工具对应一个完整的业务动作。

错误处理要完善。工具调用可能失败，网络超时、参数错误、权限不足都可能发生。工具要返回清晰的错误信息，让模型知道发生了什么、能不能重试、怎么调整参数。

调用策略要明确。什么时候该调用工具，什么时候该直接回答，这个边界要在系统提示词里写清楚。我一般会告诉模型：如果问题涉及实时信息或需要计算，必须调用工具；如果是常识问题，可以直接回答。

5.3 多Agent协作与并发处理

单Agent能处理的任务有限，复杂任务需要多Agent协作。常见的多Agent架构有几种。

主管- worker模式：一个主管Agent负责拆解任务和分配，多个worker Agent负责执行具体子任务。主管汇总结果后输出。这种模式适合任务可以清晰拆分的场景。

辩论模式：多个Agent对同一问题给出不同答案，然后互相辩论，最后投票或由裁判Agent裁决。这种模式能提升答案的可靠性，但成本高。

流水线模式：多个Agent按顺序处理，前一个的输出是后一个的输入。适合有明确阶段划分的任务，比如“检索-分析-撰写-审核”。

并发处理是多Agent系统的工程难点。多个Agent同时调用工具或访问共享资源时，需要做并发控制。我一般用消息队列来协调，每个Agent把请求发到队列，由专门的执行器按顺序处理。另外，要给每个Agent设置超时和重试机制，避免一个Agent卡住导致整个系统挂起。

实操心得：多Agent系统不要一上来就搞太复杂。先从单Agent加多工具开始，跑通了再考虑多Agent。很多任务单Agent加好的工具设计就能解决，多Agent反而增加了不确定性和调试难度。

6. 常见问题与排查技巧实录

6.1 微调效果不好的排查思路

微调之后效果不达预期，是最常见的问题。我整理了一个排查清单，按优先级排列。

第一步，检查数据。把训练数据随机抽100条出来，逐条看。指令是否清晰？回答是否准确？格式是否统一？有没有重复？我遇到过很多次，问题根本不在模型，而在数据里有大量低质样本。

第二步，检查过拟合。如果训练loss持续下降但验证loss开始上升，就是过拟合了。解决办法是减少训练轮数、增加数据量、加正则化、或者用LoRA这种参数高效的微调方式。

第三步，检查学习率。学习率太大会导致loss震荡不收敛，太小会导致收敛太慢或陷入局部最优。LoRA的学习率一般比全量微调大一个数量级，因为可训练参数少。

第四步，检查基座模型。有些基座模型本身能力就有限，微调也救不回来。换一个更强的基座模型试试。

第五步，检查评估方式。你的评估集和训练集分布是否一致？评估指标是否合理？我见过用训练集当评估集的，那效果当然好，但没意义。

6.2 Agent调用工具失败的典型场景

Agent调用工具失败，通常有几种表现和对应的原因。

我遇到最多的场景是模型不调用工具，直接凭记忆回答。解决办法是在系统提示词里明确写：“对于实时信息，必须调用工具查询，不得凭记忆回答。”另外，给几个调用工具的示例，模型会更容易学会。

6.3 部署与推理的性能优化

模型部署上线后，性能和成本是绕不开的问题。几个实用的优化手段。

量化是最直接的降本手段。FP16转INT8能省一半显存，转INT4能省四分之三。代价是精度可能下降，需要评估对业务的影响。我一般先用INT8，效果不够再考虑INT4。

批处理能提升吞吐量。把多个请求攒成一批一起推理，GPU利用率更高。但批处理会增加延迟，适合对延迟不敏感的场景。

KV Cache优化对大模型推理很重要。PagedAttention和连续批处理能显著提升显存利用率和吞吐量。vLLM和TGI这两个推理框架都内置了这些优化。

模型蒸馏是另一个思路。用大模型教小模型，让小模型在特定任务上达到接近大模型的效果，但推理成本低得多。适合任务明确、数据充足的场景。

缓存也很关键。相同或相似的请求可以缓存结果，避免重复推理。对于FAQ类应用，缓存命中率能到很高。

6.4 大模型学习路线的个人建议

最后聊一下学习路线。大模型这个领域变化太快，追新是追不完的。我的建议是抓住不变的东西。

基础层：Transformer架构、注意力机制、预训练目标、微调原理。这些是根基，不会过时。花时间把原理搞透，比追各种新模型有价值。

工具层：PyTorch、Hugging Face Transformers、PEFT、vLLM。这些是日常用的工具，熟练使用能大幅提升效率。

实践层：从微调一个小模型开始，走完数据准备、训练、评估、部署的完整流程。然后尝试搭建RAG系统，再尝试做一个简单的Agent。每一步都动手做，不要只看文章。

前沿层：关注几个顶级会议和arXiv上的重要论文，但不要每篇都追。挑和你工作相关的读，读完试着复现关键部分。

我个人最大的体会是：大模型领域，动手比看书重要十倍。很多问题只有亲自跑过才会遇到，很多经验只有踩过坑才能记住。找一个实际的需求，哪怕很小，从头到尾做一遍，收获比看一百篇综述都大。

这个领域还在快速演进，今天的最佳实践明天可能就被推翻。但底层的东西——数据质量决定上限、评估驱动迭代、工程细节决定成败——这些原则不会变。把精力放在这些不变的东西上，比追热点更划算。