大模型这个词这两年已经被说烂了但真正能把从预训练到Agent这条链路讲清楚的人其实不多。我见过太多人一上来就冲着微调去拿着LoRA脚本跑了一遍发现效果不对回头才发现连基座模型是怎么来的、数据是怎么配比的都没搞明白。这篇东西是我自己从预训练一路踩到Agent落地之后梳理出来的完整图景不打算写成教科书而是按照一个从业者真正会关心的顺序来拆模型怎么从零练出来、怎么让它听话、怎么让它能干活、以及每一步实际动手时最容易翻车的地方在哪。不管你是刚入门想搞清楚全貌还是已经做过微调但觉得知识是碎的这篇应该都能帮你把链条接上。1. 预训练大模型能力的真正来源1.1 预训练到底在做什么很多人把预训练理解成喂数据让模型学知识这个说法不算错但太粗糙。预训练的本质是让模型学会在给定上下文的情况下预测下一个token的概率分布。听起来简单但当你把互联网级别的文本丢进去模型为了把这个预测做好被迫学会了语法、事实、推理模式、代码结构、甚至一些世界常识。这就是所谓的涌现能力——没有专门教它但它为了降低预测误差自己学会了。预训练的数据规模通常用token数衡量。以主流开源模型为例7B级别的模型往往要吃掉1T到2T的token而更大的模型会到10T以上。这个量级是什么概念一本《三体》三部曲大概100万汉字粗算约150万token1T token相当于六十多万套三体全集。数据来源一般包括网页抓取、书籍、代码仓库、论文、百科等配比是各家核心机密之一。数据清洗在预训练里的重要性怎么强调都不过分。原始网页数据里充斥着导航栏、广告、重复内容、乱码如果不做去重和质量过滤模型会学到大量垃圾模式。常见的处理链路包括URL过滤、文本提取、语言识别、去重精确去重模糊去重、质量打分用一个小模型给文本打困惑度分低质量的丢掉。这一步做得好不好直接决定基座模型的下限。1.2 预训练的核心架构选择现在主流的大模型几乎都是Decoder-only的Transformer架构。这个选择不是偶然的。Encoder-only比如BERT系列擅长理解类任务Encoder-Decoder比如T5擅长序列到序列的任务而Decoder-only在规模化之后展现出了最好的通用性和涌现能力而且推理时实现简单、易于做KV Cache优化。具体到架构细节有几个关键点值得关注位置编码从绝对位置编码到RoPE旋转位置编码再到各种长度外推方案。RoPE之所以成为主流是因为它通过旋转矩阵把相对位置信息编码进注意力计算天然支持一定的长度外推配合NTK-aware插值或者YaRN等方法可以把上下文窗口从4K扩展到128K甚至更长。注意力机制标准多头注意力在长序列下计算量是O(n²)所以有了各种优化——MQAMulti-Query Attention、GQAGrouped-Query Attention、FlashAttention等。GQA现在是主流选择它在推理速度和效果之间取得了比较好的平衡。归一化从Post-LN到Pre-LN再到RMSNorm趋势是越来越简单且训练更稳定。RMSNorm去掉了均值中心化只做均方根归一化计算更省且效果不差。激活函数SwiGLU基本取代了ReLU和GELU在FFN层里表现更好。这些架构选择不是拍脑袋定的每一个背后都有大量的消融实验支撑。你在读论文的时候可以重点关注它们的ablation study部分那才是真正有价值的信息。1.3 预训练的实际工程挑战真正做过预训练的人都知道架构设计可能只占20%的精力剩下80%全在工程上。几个绕不开的问题并行策略。一个7B模型用fp16存储就要14GB加上优化器状态Adam的话是模型参数的2倍、梯度、激活值单卡根本放不下。所以需要组合使用数据并行、张量并行、流水线并行。数据并行每张卡存完整模型副本、喂不同数据张量并行把单个矩阵运算切到多卡流水线并行把不同层放到不同卡上。实际配置要根据模型大小、卡的数量和互联带宽来定。训练稳定性。大规模训练最怕loss spike就是loss突然飙升甚至变成NaN。常见原因包括学习率过大、数据里混入了异常样本、梯度爆炸等。应对手段有梯度裁剪、学习率warmup、在检测到spike时回滚到之前的checkpoint并跳过当前数据批次。我自己的经验是warmup步数不要省宁可多花几千步慢慢把学习率升上去也比中途炸了重来划算。显存优化。除了并行还有ZeRO系列把优化器状态、梯度、参数分片存储、激活重计算用计算换显存前向时不存激活值反向时重新算、混合精度训练用bf16做前向反向fp32做参数更新等手段。这些技术组合起来才能让大模型训练在有限硬件上跑起来。提示如果你只是想在自己的数据上做领域适配不要从零预训练。从开源基座模型出发做继续预训练continue pre-training或者直接微调成本差着好几个数量级。2. 微调让基座模型变成你的专属助手2.1 全量微调与参数高效微调的分水岭预训练出来的基座模型是个什么都懂一点但什么都不精的状态它不会按照你的指令格式回答问题也不了解你的垂直领域。微调就是解决这个问题的。全量微调就是拿基座模型的所有参数在你的数据上继续训练。效果上限最高但代价也最大——一个7B模型全量微调至少需要几张A100而且容易过拟合数据量不够的话效果反而会退化。更麻烦的是灾难性遗忘模型在你的领域数据上训过头之后通用能力会明显下降。参数高效微调PEFT是现在的主流选择。核心思路是冻结大部分预训练参数只训练一小部分新增的或选定的参数。最常用的几种方法核心思路可训练参数占比适用场景LoRA在权重矩阵旁加低秩分解矩阵0.1%-1%通用首选效果稳定QLoRALoRA 4bit量化基座0.1%-1%显存极度受限Prefix Tuning在每层前面加可学习前缀0.1%生成任务Adapter在层间插入小模块1%-5%多任务切换P-Tuning v2可学习prompt embedding0.1%NLU任务LoRA之所以成为事实标准是因为它的设计非常优雅对于原始权重矩阵W不直接改它而是学一个低秩增量ΔW BA其中B和A是远小于原矩阵维度的低秩矩阵。推理时可以把BA乘回去合并到W里不增加任何推理延迟。这个特性让它在工程上极其友好。2.2 LoRA微调的实操细节拿Qwen系列做LoRA微调举例几个关键参数的选择逻辑rank秩控制低秩矩阵的维度越大表达能力越强但参数越多。经验值是简单任务风格迁移、格式对齐用8-16复杂任务领域知识注入、推理能力提升用32-64。我一般从16起步效果不够再加。alpha缩放因子实际增量是ΔW (alpha/r) * BA。通常设成rank的1-2倍。alpha/r这个比例决定了增量更新的幅度比例太大容易训崩太小则学不动。target_modules决定把LoRA加在哪些层上。最常见的是加在注意力的q_proj、k_proj、v_proj、o_proj上。有实验表明同时加在注意力和FFN层上效果更好但参数会多一些。如果显存紧张只加q_proj和v_proj也能work。学习率LoRA的学习率通常比全量微调大一个数量级常见范围是1e-4到3e-4。因为可训练参数少需要更大的步长才能有效更新。数据格式这是最容易被忽视但影响巨大的环节。指令微调的数据一般组织成对话格式用chat template包起来。不同模型的template不一样用错了模型学到的就是错误的格式。比如Qwen的ChatML格式是|im_start|user\n...|im_end|Llama系列用的是[INST]...[/INST]。一定要用模型自带的tokenizer的apply_chat_template方法不要自己手写。# LoRA微调核心配置示例 from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 输出类似: trainable params: 20M || all params: 7B || trainable%: 0.28%2.3 微调数据质量和数量哪个更重要我的答案是质量远比数量重要。1000条精心构造的高质量指令数据效果往往好过10万条从网上随便爬的脏数据。原因很简单——微调是在教模型怎么做事不是在教它知道什么。知识注入靠继续预训练行为对齐靠指令微调。高质量微调数据的几个特征多样性任务类型要覆盖你实际使用场景的各种情况不要全是同一类问题。准确性答案必须是对的。模型会忠实地学习你给它的模式包括错误。格式一致性如果你希望模型输出特定格式比如JSON训练数据里就必须严格是这个格式。难度梯度从简单到复杂都要有让模型逐步学习。数据构造的常见方式包括人工标注质量最高但贵、用更强的模型蒸馏GPT-4生成、人工审核、从现有数据集中筛选和改写。实际项目中往往是组合使用。注意微调数据里如果混入了测试集的样本评估结果会严重虚高。做数据划分的时候一定要严格去重最好用不同的数据来源做训练和测试。3. 对齐与提示工程从能用到好用3.1 RLHF与DPO的路线之争微调之后的模型已经能按照指令格式回答了但它的回答可能不够有帮助、不够安全、或者风格不对。对齐阶段就是解决这个问题的。传统的RLHF基于人类反馈的强化学习分三步先训练一个奖励模型让人类对模型的多个输出排序用这些排序数据训练一个打分模型然后用PPO算法优化策略模型让它的输出获得更高的奖励分。这套流程效果好但极其复杂——要同时维护策略模型、参考模型、奖励模型、价值模型四个模型训练不稳定调参难度大。DPO直接偏好优化是这两年的热门替代方案。它跳过奖励模型直接用偏好数据chosen/rejected对优化策略模型。数学上它证明了最优策略和奖励函数之间存在解析关系所以可以绕过显式奖励建模。实现简单、训练稳定效果在很多场景下不输RLHF。实际选型建议资源有限、追求稳定就选DPO如果对效果有极致要求且有工程能力维护RLHF管线可以上PPO。现在还有一些DPO的变体比如IPO、KTO、ORPO各有侧重但核心思想类似。3.2 提示词工程与上下文工程模型对齐好了接下来是怎么用好它。提示词工程Prompt Engineering这个词已经被说烂了但真正有效的技巧其实就那么几条明确角色和任务。不要只说帮我写个总结要说你是一个技术文档编辑请把下面这段技术说明改写成面向非技术读者的通俗版本控制在200字以内。角色设定会激活模型在预训练中对应领域的模式。给例子Few-shot。对于格式要求严格的任务给1-3个输入输出示例比任何描述都管用。模型会从例子里推断出你想要的模式。分步思考Chain-of-Thought。对于推理类任务让模型一步一步想能显著提升准确率。这个技巧的本质是让模型把中间推理过程展开成token相当于给它更多的计算空间。上下文工程是提示词工程的延伸。当模型支持长上下文之后问题从怎么写prompt变成了怎么组织整个上下文窗口里的信息。关键原则重要的信息放在开头和结尾中间容易丢失这就是所谓的lost in the middle现象用清晰的分隔符区分不同部分把指令放在最后。3.3 评估怎么知道模型到底行不行这一步太多人跳过了。模型训完随便试几个case觉得还行就上线结果真实场景里各种翻车。评估要分层次做自动指标困惑度PPL、BLEU、ROUGE这些传统指标对生成式模型参考价值有限但可以作为快速筛查。LLM as Judge用更强的模型比如GPT-4级别给输出打分。要注意位置偏差模型倾向于给第一个选项高分和长度偏差倾向于给长回答高分可以通过交换顺序多次评估来缓解。人工评估最可靠但最贵。设计好评测维度准确性、完整性、流畅度、安全性让标注人员独立打分。公开榜单Open LLM Leaderboard、C-Eval、CMMLU等可以作为参考但要注意数据污染问题——很多模型在训练时见过测试集。我自己的做法是先构造一个50-100条的领域测试集覆盖核心场景和边界情况每次改动都跑一遍。这个测试集要持续维护发现bad case就加进去。这比任何榜单都更能反映模型在你实际场景下的表现。4. Agent让大模型真正干活4.1 Agent的本质是什么如果说微调和对齐是让模型会说话那Agent就是让模型会做事。一个Agent的核心循环是感知环境 → 规划下一步 → 执行动作 → 观察结果 → 继续规划直到任务完成。用更技术化的语言描述Agent LLM 工具 记忆 规划。LLM是大脑负责理解和决策工具是手脚让它能查资料、调API、操作软件记忆让它能记住之前发生了什么规划让它能把复杂任务拆成可执行的步骤。这和单纯的对话模型有本质区别。对话模型是你问我答Agent是你给我目标我自己想办法达成。比如你说帮我查一下北京明天天气如果下雨就提醒我带伞对话模型只能告诉你它不知道实时天气而Agent会调用天气API、判断结果、然后给出结论。4.2 Agent的核心组件拆解工具调用Function Calling / Tool Use是Agent的基础能力。模型需要能理解有哪些工具可用、每个工具需要什么参数、什么时候该调用哪个工具。实现上通常是把工具定义成JSON Schema模型输出结构化的调用请求外部系统执行后把结果返回给模型。# 工具定义的典型结构 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名}, date: {type: string, description: 日期格式YYYY-MM-DD} }, required: [city] } } } ]记忆系统分短期和长期。短期记忆就是当前对话的上下文受限于上下文窗口长度。长期记忆需要外部存储——把重要信息向量化存到向量数据库需要时检索出来。这里的关键是什么该记、什么该忘、什么时候检索策略设计得好不好直接决定Agent的实用性。规划能力是Agent最核心也最难的部分。简单任务一步就能完成复杂任务需要拆解。常见的规划模式有ReAct交替进行推理Reasoning和行动Acting每一步都先想再做的。Plan-and-Execute先制定完整计划再逐步执行。适合步骤明确的流程化任务。Reflection执行后反思结果如果不对就调整重来。适合需要试错的场景。多Agent协作是进阶玩法。让多个各有专长的Agent分工合作比如一个负责拆解任务、一个负责写代码、一个负责审查。好处是每个Agent的prompt可以更聚焦坏处是通信开销大、容易陷入循环。4.3 Agent开发中的真实坑并发问题。单用户测试的时候Agent跑得好好的一上并发就各种问题。工具调用有速率限制、共享状态会冲突、上下文管理会混乱。解决方案包括给每个会话独立的上下文空间、对工具调用做队列和限流、用异步IO处理等待。错误处理。工具调用失败是常态——API超时、返回格式不对、参数错误。Agent必须能识别失败并决定是重试、换方案还是放弃。很多Agent demo看起来惊艳一到生产环境就崩就是因为没做好错误处理。成本控制。Agent一次任务可能调用十几次LLMtoken消耗是普通对话的几十倍。优化手段包括用小模型做简单决策、缓存重复的工具调用结果、设置最大步数限制防止无限循环。评估困难。对话模型可以用BLEU、ROUGE评估Agent怎么评一个任务完成了没有、完成得好不好、有没有更优解这些很难自动判断。实践中通常用任务成功率作为核心指标配合人工抽查执行轨迹。提示Agent开发不要一上来就追求全自动。先从人在回路Human-in-the-loop开始让Agent执行关键步骤前需要人确认跑稳了再逐步放开。5. 部署与选型把模型真正跑起来5.1 推理框架怎么选模型训好了怎么高效地跑起来是另一个问题。主流推理框架各有侧重框架核心优势适用场景vLLMPagedAttention吞吐量高高并发在线服务TGIHuggingFace生态易用快速原型和中小规模llama.cppCPU/消费级GPU可跑量化支持好本地部署、边缘设备TensorRT-LLMNVIDIA深度优化延迟低对延迟敏感的生产环境Ollama开箱即用管理方便个人开发、本地实验选型的核心考量是你的瓶颈是吞吐还是延迟你的硬件是什么你的并发量多大高并发选vLLM低延迟选TensorRT-LLM本地玩选Ollama或llama.cpp。量化是部署绕不开的话题。把fp16的模型量化到int8或int4显存占用能降一半到四分之三代价是精度损失。常用的量化方案有GPTQ、AWQ、GGUF等。经验是int8量化基本无损int4量化在大多数任务上损失可接受但推理类任务要谨慎。5.2 模型选型的决策框架面对一堆开源模型怎么选我的决策顺序是先看任务类型。中文任务优先考虑Qwen、GLM、Baichuan等中文优化过的模型代码任务看DeepSeek-Coder、CodeLlama多模态看Qwen-VL、InternVL。再看规模约束。显存有多少、延迟要求多高决定了你能用多大的模型。7B模型int4量化后大概4-5GB显存13B大概8GB70B需要40GB以上。然后看许可证。商用的话要确认license是否允许有些模型只允许研究用途。最后看社区活跃度。文档全不全、issue响应快不快、有没有人踩过坑这些直接影响你的开发效率。不要迷信榜单排名。Open LLM Leaderboard上的分数和实际使用体验经常对不上因为榜单测的是通用能力而你的场景是特定的。最好的模型是你在自己测试集上跑分最高的那个。5.3 从Demo到生产的距离一个模型在notebook里跑通和它在生产环境稳定服务中间隔着十万八千里。几个必须解决的问题服务化。用FastAPI或者Triton Inference Server把模型包装成HTTP服务处理好请求队列、批处理、超时。监控。记录每个请求的延迟、token数、成功率设置告警阈值。模型服务的性能会随着负载变化没有监控就是盲人摸象。版本管理。模型更新、prompt调整、参数变更都要有版本记录出问题能快速回滚。安全防护。输入过滤防止prompt注入、输出审核防止有害内容、速率限制防止滥用。这些在demo阶段可以不管生产环境一个都不能少。6. 一条完整的技术链路复盘把整条链路串起来看预训练决定了模型的能力上限微调决定了它在特定任务上的表现对齐决定了它的行为是否符合预期Agent让它从会说变成会做部署决定了它能不能稳定服务。每个环节都有它的必要性但也有它的成本。实际项目中不是每个环节都要做——大多数团队直接从开源基座模型开始跳过预训练如果通用模型已经够用微调也可以跳过Agent也不是所有场景都需要简单的对话场景用prompt工程就够了。我自己的经验是先想清楚你要解决什么问题再倒推需要哪些环节。不要因为某个技术火就硬往上套。见过太多团队花大力气微调了一个模型结果发现用GPT-4加好的prompt效果更好——不是说微调没价值而是要先算清楚投入产出比。另外一个很实际的建议把评估体系建在前面。没有评估就没有迭代方向你会陷入感觉好像好了一点的玄学调优。哪怕一开始只有20条测试用例也比没有强。随着项目推进不断补充这个测试集会成为你最宝贵的资产。最后说一个容易被忽视的点数据飞轮。上线之后用户的实际使用数据输入、输出、反馈是最宝贵的训练素材。设计好数据收集和标注流程让模型能持续从真实场景中学习这比一次性的大规模微调更有长期价值。我见过做得好的团队模型每个月都在肉眼可见地变好靠的就是这个飞轮转起来了。 
长河君 · 2026/11/2 7:42:19 · 阅读 1.2k 从预训练到Agent：大模型全链路技术解析与工程实践
大模型这个词这两年已经被说烂了但真正能把从预训练到Agent这条链路讲清楚的人其实不多。我见过太多人一上来就冲着微调去拿着LoRA脚本跑了一遍发现效果不对回头才发现连基座模型是怎么来的、数据是怎么配比的都没搞明白。这篇东西是我自己从预训练一路踩到Agent落地之后梳理出来的完整图景不打算写成教科书而是按照一个从业者真正会关心的顺序来拆模型怎么从零练出来、怎么让它听话、怎么让它能干活、以及每一步实际动手时最容易翻车的地方在哪。不管你是刚入门想搞清楚全貌还是已经做过微调但觉得知识是碎的这篇应该都能帮你把链条接上。1. 预训练大模型能力的真正来源1.1 预训练到底在做什么很多人把预训练理解成喂数据让模型学知识这个说法不算错但太粗糙。预训练的本质是让模型学会在给定上下文的情况下预测下一个token的概率分布。听起来简单但当你把互联网级别的文本丢进去模型为了把这个预测做好被迫学会了语法、事实、推理模式、代码结构、甚至一些世界常识。这就是所谓的涌现能力——没有专门教它但它为了降低预测误差自己学会了。预训练的数据规模通常用token数衡量。以主流开源模型为例7B级别的模型往往要吃掉1T到2T的token而更大的模型会到10T以上。这个量级是什么概念一本《三体》三部曲大概100万汉字粗算约150万token1T token相当于六十多万套三体全集。数据来源一般包括网页抓取、书籍、代码仓库、论文、百科等配比是各家核心机密之一。数据清洗在预训练里的重要性怎么强调都不过分。原始网页数据里充斥着导航栏、广告、重复内容、乱码如果不做去重和质量过滤模型会学到大量垃圾模式。常见的处理链路包括URL过滤、文本提取、语言识别、去重精确去重模糊去重、质量打分用一个小模型给文本打困惑度分低质量的丢掉。这一步做得好不好直接决定基座模型的下限。1.2 预训练的核心架构选择现在主流的大模型几乎都是Decoder-only的Transformer架构。这个选择不是偶然的。Encoder-only比如BERT系列擅长理解类任务Encoder-Decoder比如T5擅长序列到序列的任务而Decoder-only在规模化之后展现出了最好的通用性和涌现能力而且推理时实现简单、易于做KV Cache优化。具体到架构细节有几个关键点值得关注位置编码从绝对位置编码到RoPE旋转位置编码再到各种长度外推方案。RoPE之所以成为主流是因为它通过旋转矩阵把相对位置信息编码进注意力计算天然支持一定的长度外推配合NTK-aware插值或者YaRN等方法可以把上下文窗口从4K扩展到128K甚至更长。注意力机制标准多头注意力在长序列下计算量是O(n²)所以有了各种优化——MQAMulti-Query Attention、GQAGrouped-Query Attention、FlashAttention等。GQA现在是主流选择它在推理速度和效果之间取得了比较好的平衡。归一化从Post-LN到Pre-LN再到RMSNorm趋势是越来越简单且训练更稳定。RMSNorm去掉了均值中心化只做均方根归一化计算更省且效果不差。激活函数SwiGLU基本取代了ReLU和GELU在FFN层里表现更好。这些架构选择不是拍脑袋定的每一个背后都有大量的消融实验支撑。你在读论文的时候可以重点关注它们的ablation study部分那才是真正有价值的信息。1.3 预训练的实际工程挑战真正做过预训练的人都知道架构设计可能只占20%的精力剩下80%全在工程上。几个绕不开的问题并行策略。一个7B模型用fp16存储就要14GB加上优化器状态Adam的话是模型参数的2倍、梯度、激活值单卡根本放不下。所以需要组合使用数据并行、张量并行、流水线并行。数据并行每张卡存完整模型副本、喂不同数据张量并行把单个矩阵运算切到多卡流水线并行把不同层放到不同卡上。实际配置要根据模型大小、卡的数量和互联带宽来定。训练稳定性。大规模训练最怕loss spike就是loss突然飙升甚至变成NaN。常见原因包括学习率过大、数据里混入了异常样本、梯度爆炸等。应对手段有梯度裁剪、学习率warmup、在检测到spike时回滚到之前的checkpoint并跳过当前数据批次。我自己的经验是warmup步数不要省宁可多花几千步慢慢把学习率升上去也比中途炸了重来划算。显存优化。除了并行还有ZeRO系列把优化器状态、梯度、参数分片存储、激活重计算用计算换显存前向时不存激活值反向时重新算、混合精度训练用bf16做前向反向fp32做参数更新等手段。这些技术组合起来才能让大模型训练在有限硬件上跑起来。提示如果你只是想在自己的数据上做领域适配不要从零预训练。从开源基座模型出发做继续预训练continue pre-training或者直接微调成本差着好几个数量级。2. 微调让基座模型变成你的专属助手2.1 全量微调与参数高效微调的分水岭预训练出来的基座模型是个什么都懂一点但什么都不精的状态它不会按照你的指令格式回答问题也不了解你的垂直领域。微调就是解决这个问题的。全量微调就是拿基座模型的所有参数在你的数据上继续训练。效果上限最高但代价也最大——一个7B模型全量微调至少需要几张A100而且容易过拟合数据量不够的话效果反而会退化。更麻烦的是灾难性遗忘模型在你的领域数据上训过头之后通用能力会明显下降。参数高效微调PEFT是现在的主流选择。核心思路是冻结大部分预训练参数只训练一小部分新增的或选定的参数。最常用的几种方法核心思路可训练参数占比适用场景LoRA在权重矩阵旁加低秩分解矩阵0.1%-1%通用首选效果稳定QLoRALoRA 4bit量化基座0.1%-1%显存极度受限Prefix Tuning在每层前面加可学习前缀0.1%生成任务Adapter在层间插入小模块1%-5%多任务切换P-Tuning v2可学习prompt embedding0.1%NLU任务LoRA之所以成为事实标准是因为它的设计非常优雅对于原始权重矩阵W不直接改它而是学一个低秩增量ΔW BA其中B和A是远小于原矩阵维度的低秩矩阵。推理时可以把BA乘回去合并到W里不增加任何推理延迟。这个特性让它在工程上极其友好。2.2 LoRA微调的实操细节拿Qwen系列做LoRA微调举例几个关键参数的选择逻辑rank秩控制低秩矩阵的维度越大表达能力越强但参数越多。经验值是简单任务风格迁移、格式对齐用8-16复杂任务领域知识注入、推理能力提升用32-64。我一般从16起步效果不够再加。alpha缩放因子实际增量是ΔW (alpha/r) * BA。通常设成rank的1-2倍。alpha/r这个比例决定了增量更新的幅度比例太大容易训崩太小则学不动。target_modules决定把LoRA加在哪些层上。最常见的是加在注意力的q_proj、k_proj、v_proj、o_proj上。有实验表明同时加在注意力和FFN层上效果更好但参数会多一些。如果显存紧张只加q_proj和v_proj也能work。学习率LoRA的学习率通常比全量微调大一个数量级常见范围是1e-4到3e-4。因为可训练参数少需要更大的步长才能有效更新。数据格式这是最容易被忽视但影响巨大的环节。指令微调的数据一般组织成对话格式用chat template包起来。不同模型的template不一样用错了模型学到的就是错误的格式。比如Qwen的ChatML格式是|im_start|user\n...|im_end|Llama系列用的是[INST]...[/INST]。一定要用模型自带的tokenizer的apply_chat_template方法不要自己手写。# LoRA微调核心配置示例 from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 输出类似: trainable params: 20M || all params: 7B || trainable%: 0.28%2.3 微调数据质量和数量哪个更重要我的答案是质量远比数量重要。1000条精心构造的高质量指令数据效果往往好过10万条从网上随便爬的脏数据。原因很简单——微调是在教模型怎么做事不是在教它知道什么。知识注入靠继续预训练行为对齐靠指令微调。高质量微调数据的几个特征多样性任务类型要覆盖你实际使用场景的各种情况不要全是同一类问题。准确性答案必须是对的。模型会忠实地学习你给它的模式包括错误。格式一致性如果你希望模型输出特定格式比如JSON训练数据里就必须严格是这个格式。难度梯度从简单到复杂都要有让模型逐步学习。数据构造的常见方式包括人工标注质量最高但贵、用更强的模型蒸馏GPT-4生成、人工审核、从现有数据集中筛选和改写。实际项目中往往是组合使用。注意微调数据里如果混入了测试集的样本评估结果会严重虚高。做数据划分的时候一定要严格去重最好用不同的数据来源做训练和测试。3. 对齐与提示工程从能用到好用3.1 RLHF与DPO的路线之争微调之后的模型已经能按照指令格式回答了但它的回答可能不够有帮助、不够安全、或者风格不对。对齐阶段就是解决这个问题的。传统的RLHF基于人类反馈的强化学习分三步先训练一个奖励模型让人类对模型的多个输出排序用这些排序数据训练一个打分模型然后用PPO算法优化策略模型让它的输出获得更高的奖励分。这套流程效果好但极其复杂——要同时维护策略模型、参考模型、奖励模型、价值模型四个模型训练不稳定调参难度大。DPO直接偏好优化是这两年的热门替代方案。它跳过奖励模型直接用偏好数据chosen/rejected对优化策略模型。数学上它证明了最优策略和奖励函数之间存在解析关系所以可以绕过显式奖励建模。实现简单、训练稳定效果在很多场景下不输RLHF。实际选型建议资源有限、追求稳定就选DPO如果对效果有极致要求且有工程能力维护RLHF管线可以上PPO。现在还有一些DPO的变体比如IPO、KTO、ORPO各有侧重但核心思想类似。3.2 提示词工程与上下文工程模型对齐好了接下来是怎么用好它。提示词工程Prompt Engineering这个词已经被说烂了但真正有效的技巧其实就那么几条明确角色和任务。不要只说帮我写个总结要说你是一个技术文档编辑请把下面这段技术说明改写成面向非技术读者的通俗版本控制在200字以内。角色设定会激活模型在预训练中对应领域的模式。给例子Few-shot。对于格式要求严格的任务给1-3个输入输出示例比任何描述都管用。模型会从例子里推断出你想要的模式。分步思考Chain-of-Thought。对于推理类任务让模型一步一步想能显著提升准确率。这个技巧的本质是让模型把中间推理过程展开成token相当于给它更多的计算空间。上下文工程是提示词工程的延伸。当模型支持长上下文之后问题从怎么写prompt变成了怎么组织整个上下文窗口里的信息。关键原则重要的信息放在开头和结尾中间容易丢失这就是所谓的lost in the middle现象用清晰的分隔符区分不同部分把指令放在最后。3.3 评估怎么知道模型到底行不行这一步太多人跳过了。模型训完随便试几个case觉得还行就上线结果真实场景里各种翻车。评估要分层次做自动指标困惑度PPL、BLEU、ROUGE这些传统指标对生成式模型参考价值有限但可以作为快速筛查。LLM as Judge用更强的模型比如GPT-4级别给输出打分。要注意位置偏差模型倾向于给第一个选项高分和长度偏差倾向于给长回答高分可以通过交换顺序多次评估来缓解。人工评估最可靠但最贵。设计好评测维度准确性、完整性、流畅度、安全性让标注人员独立打分。公开榜单Open LLM Leaderboard、C-Eval、CMMLU等可以作为参考但要注意数据污染问题——很多模型在训练时见过测试集。我自己的做法是先构造一个50-100条的领域测试集覆盖核心场景和边界情况每次改动都跑一遍。这个测试集要持续维护发现bad case就加进去。这比任何榜单都更能反映模型在你实际场景下的表现。4. Agent让大模型真正干活4.1 Agent的本质是什么如果说微调和对齐是让模型会说话那Agent就是让模型会做事。一个Agent的核心循环是感知环境 → 规划下一步 → 执行动作 → 观察结果 → 继续规划直到任务完成。用更技术化的语言描述Agent LLM 工具 记忆 规划。LLM是大脑负责理解和决策工具是手脚让它能查资料、调API、操作软件记忆让它能记住之前发生了什么规划让它能把复杂任务拆成可执行的步骤。这和单纯的对话模型有本质区别。对话模型是你问我答Agent是你给我目标我自己想办法达成。比如你说帮我查一下北京明天天气如果下雨就提醒我带伞对话模型只能告诉你它不知道实时天气而Agent会调用天气API、判断结果、然后给出结论。4.2 Agent的核心组件拆解工具调用Function Calling / Tool Use是Agent的基础能力。模型需要能理解有哪些工具可用、每个工具需要什么参数、什么时候该调用哪个工具。实现上通常是把工具定义成JSON Schema模型输出结构化的调用请求外部系统执行后把结果返回给模型。# 工具定义的典型结构 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名}, date: {type: string, description: 日期格式YYYY-MM-DD} }, required: [city] } } } ]记忆系统分短期和长期。短期记忆就是当前对话的上下文受限于上下文窗口长度。长期记忆需要外部存储——把重要信息向量化存到向量数据库需要时检索出来。这里的关键是什么该记、什么该忘、什么时候检索策略设计得好不好直接决定Agent的实用性。规划能力是Agent最核心也最难的部分。简单任务一步就能完成复杂任务需要拆解。常见的规划模式有ReAct交替进行推理Reasoning和行动Acting每一步都先想再做的。Plan-and-Execute先制定完整计划再逐步执行。适合步骤明确的流程化任务。Reflection执行后反思结果如果不对就调整重来。适合需要试错的场景。多Agent协作是进阶玩法。让多个各有专长的Agent分工合作比如一个负责拆解任务、一个负责写代码、一个负责审查。好处是每个Agent的prompt可以更聚焦坏处是通信开销大、容易陷入循环。4.3 Agent开发中的真实坑并发问题。单用户测试的时候Agent跑得好好的一上并发就各种问题。工具调用有速率限制、共享状态会冲突、上下文管理会混乱。解决方案包括给每个会话独立的上下文空间、对工具调用做队列和限流、用异步IO处理等待。错误处理。工具调用失败是常态——API超时、返回格式不对、参数错误。Agent必须能识别失败并决定是重试、换方案还是放弃。很多Agent demo看起来惊艳一到生产环境就崩就是因为没做好错误处理。成本控制。Agent一次任务可能调用十几次LLMtoken消耗是普通对话的几十倍。优化手段包括用小模型做简单决策、缓存重复的工具调用结果、设置最大步数限制防止无限循环。评估困难。对话模型可以用BLEU、ROUGE评估Agent怎么评一个任务完成了没有、完成得好不好、有没有更优解这些很难自动判断。实践中通常用任务成功率作为核心指标配合人工抽查执行轨迹。提示Agent开发不要一上来就追求全自动。先从人在回路Human-in-the-loop开始让Agent执行关键步骤前需要人确认跑稳了再逐步放开。5. 部署与选型把模型真正跑起来5.1 推理框架怎么选模型训好了怎么高效地跑起来是另一个问题。主流推理框架各有侧重框架核心优势适用场景vLLMPagedAttention吞吐量高高并发在线服务TGIHuggingFace生态易用快速原型和中小规模llama.cppCPU/消费级GPU可跑量化支持好本地部署、边缘设备TensorRT-LLMNVIDIA深度优化延迟低对延迟敏感的生产环境Ollama开箱即用管理方便个人开发、本地实验选型的核心考量是你的瓶颈是吞吐还是延迟你的硬件是什么你的并发量多大高并发选vLLM低延迟选TensorRT-LLM本地玩选Ollama或llama.cpp。量化是部署绕不开的话题。把fp16的模型量化到int8或int4显存占用能降一半到四分之三代价是精度损失。常用的量化方案有GPTQ、AWQ、GGUF等。经验是int8量化基本无损int4量化在大多数任务上损失可接受但推理类任务要谨慎。5.2 模型选型的决策框架面对一堆开源模型怎么选我的决策顺序是先看任务类型。中文任务优先考虑Qwen、GLM、Baichuan等中文优化过的模型代码任务看DeepSeek-Coder、CodeLlama多模态看Qwen-VL、InternVL。再看规模约束。显存有多少、延迟要求多高决定了你能用多大的模型。7B模型int4量化后大概4-5GB显存13B大概8GB70B需要40GB以上。然后看许可证。商用的话要确认license是否允许有些模型只允许研究用途。最后看社区活跃度。文档全不全、issue响应快不快、有没有人踩过坑这些直接影响你的开发效率。不要迷信榜单排名。Open LLM Leaderboard上的分数和实际使用体验经常对不上因为榜单测的是通用能力而你的场景是特定的。最好的模型是你在自己测试集上跑分最高的那个。5.3 从Demo到生产的距离一个模型在notebook里跑通和它在生产环境稳定服务中间隔着十万八千里。几个必须解决的问题服务化。用FastAPI或者Triton Inference Server把模型包装成HTTP服务处理好请求队列、批处理、超时。监控。记录每个请求的延迟、token数、成功率设置告警阈值。模型服务的性能会随着负载变化没有监控就是盲人摸象。版本管理。模型更新、prompt调整、参数变更都要有版本记录出问题能快速回滚。安全防护。输入过滤防止prompt注入、输出审核防止有害内容、速率限制防止滥用。这些在demo阶段可以不管生产环境一个都不能少。6. 一条完整的技术链路复盘把整条链路串起来看预训练决定了模型的能力上限微调决定了它在特定任务上的表现对齐决定了它的行为是否符合预期Agent让它从会说变成会做部署决定了它能不能稳定服务。每个环节都有它的必要性但也有它的成本。实际项目中不是每个环节都要做——大多数团队直接从开源基座模型开始跳过预训练如果通用模型已经够用微调也可以跳过Agent也不是所有场景都需要简单的对话场景用prompt工程就够了。我自己的经验是先想清楚你要解决什么问题再倒推需要哪些环节。不要因为某个技术火就硬往上套。见过太多团队花大力气微调了一个模型结果发现用GPT-4加好的prompt效果更好——不是说微调没价值而是要先算清楚投入产出比。另外一个很实际的建议把评估体系建在前面。没有评估就没有迭代方向你会陷入感觉好像好了一点的玄学调优。哪怕一开始只有20条测试用例也比没有强。随着项目推进不断补充这个测试集会成为你最宝贵的资产。最后说一个容易被忽视的点数据飞轮。上线之后用户的实际使用数据输入、输出、反馈是最宝贵的训练素材。设计好数据收集和标注流程让模型能持续从真实场景中学习这比一次性的大规模微调更有长期价值。我见过做得好的团队模型每个月都在肉眼可见地变好靠的就是这个飞轮转起来了。