1. 大模型技术全景的认知框架1.1 从热搜词看技术演进脉络把大模型、预训练、Agent、LLM、微调这几个词摆在一起其实已经勾勒出了一条完整的技术链路。预训练是地基微调是装修Agent是住进去之后能自己干活的管家而LLM则是这整栋楼的统称。很多人学大模型容易陷入一个误区一上来就扎进LoRA怎么调、Qwen怎么部署结果调通了却说不清楚模型到底在干什么。我见过太多人卡在能跑通代码但讲不清原理的阶段面试或者做技术方案汇报时露怯。这条链路的内在逻辑是预训练解决通识问题微调解决专业问题Agent解决行动问题。预训练阶段模型在海量文本上学习语言的统计规律相当于一个人从小学读到大学什么都学一点微调阶段用特定领域数据继续训练相当于读了个硕士博士专精某个方向Agent则是给这个毕业生配上手脚和工具箱让它能查资料、调API、操作软件真正把知识变成行动。理解这个框架的意义在于当你在实际项目中遇到问题时能快速定位是哪个环节出了毛病。模型回答泛泛而谈可能是预训练知识够但微调没到位。模型能回答但不会用工具那是Agent层没搭好。模型在特定任务上胡言乱语大概率是微调数据质量有问题。这种分层思维能帮你省下大量盲目试错的时间。1.2 不同角色的学习路径差异我接触过各种背景想学大模型的人发现一个规律不要试图一次性吃透所有环节而是根据自己的目标倒推需要掌握什么。如果你是应用开发者重点应该放在Agent开发和提示词工程上。预训练和微调的底层细节可以暂时跳过知道概念即可。你需要的是理解LLM的输入输出特性、上下文窗口限制、Token计费逻辑然后学会用LangChain、LlamaIndex这类框架搭建Agent。这条路径上手快一两周就能做出能用的东西。如果你是算法工程师微调是核心技能。你需要理解LoRA、QLoRA、Adapter这些参数高效微调方法的原理和适用场景知道什么数据配比能出什么效果能诊断loss曲线异常。这条路径需要一定的深度学习基础但不需要从头训练模型。如果你是研究者或者想深入底层预训练和模型架构是必修课。Transformer的注意力机制、位置编码、归一化策略、混合专家模型的路由逻辑这些都需要啃论文加动手实验。这条路径周期最长但天花板也最高。我个人的建议是先花两天时间把整条链路的概念过一遍然后选一个方向深扎。最怕的是每个环节都浅尝辄止最后什么都做不出来。2. 预训练大模型的知识底座2.1 预训练到底在做什么预训练的本质是让模型学会预测下一个Token。给定一段文本模型不断预测下一个词是什么预测错了就调整参数预测对了就强化。这个过程重复几万亿次之后模型就掌握了语言的语法、事实知识、甚至一定的推理能力。为什么预测下一个词这么简单的任务能学到这么多东西因为要准确预测下一个词模型必须理解上下文。比如中国的首都是___模型要知道北京苹果公司的CEO是___模型要知道库克。这些知识不是显式教给模型的而是从海量文本中自动提取的。预训练的数据量级是惊人的。以LLaMA系列为例训练数据达到数万亿Token涵盖网页、书籍、论文、代码等多种来源。数据处理流程包括去重、质量过滤、敏感内容剔除、Token化等步骤。数据质量直接决定模型能力上限这也是为什么各家大厂在数据清洗上投入巨大。训练成本同样惊人。一个百亿参数模型在千卡集群上训练数周是常态电费就是天文数字。所以绝大多数团队不会从零预训练而是基于开源模型做继续预训练或微调。2.2 预训练模型的选择策略面对Hugging Face上成千上万的预训练模型怎么选我总结了一个决策树考量维度选择建议理由中文任务为主Qwen、Baichuan、ChatGLM中文语料占比高原生支持好英文任务为主LLaMA、Mistral、Gemma英文能力最强社区生态丰富多模态需求Qwen-VL、LLaVA、InternVL支持图文理解视觉编码器成熟端侧部署Phi、TinyLlama、Qwen-1.8B参数量小量化后可在消费级硬件运行代码生成CodeLLaMA、DeepSeek-Coder代码语料训练充分补全能力强选模型不能只看榜单分数。Open LLM Leaderboard上的排名有参考价值但实际表现要看你的具体任务。我见过榜单排名很高的模型在特定领域问答上不如小模型的情况。最靠谱的方法是拿你的真实数据做小规模评测跑个几百条测试用例看准确率、响应速度、输出格式稳定性。还有一个容易被忽略的点模型的Tokenizer会影响中文处理效果。有些英文模型的中文Tokenizer词表很小一个中文字被拆成多个Token导致上下文窗口浪费、推理速度慢、语义丢失。选中文模型时一定要看词表大小和中文Token占比。2.3 继续预训练与领域适配当你手头有大量领域文本比如医疗病历、法律文书、金融研报想让模型更懂这个领域继续预训练是一个选择。做法是在领域语料上以较小的学习率继续训练让模型调整参数分布。继续预训练的关键参数学习率通常设为原始预训练的1/10到1/100比如1e-5到1e-6。太大容易灾难性遗忘太小则学不到新知识。数据配比领域数据和通用数据的比例建议在1:1到1:10之间。纯领域数据会导致通用能力下降。训练步数不是越多越好。通常1-3个Epoch就够了过多会过拟合。序列长度根据领域文本特点设置。法律文书可能很长需要4096甚至8192对话数据可以短一些。踩过的坑有一次用纯医疗数据继续预训练结果模型连今天天气怎么样都回答不好了。后来混入30%通用数据通用能力保住了医疗问答也提升了。这个配比需要反复实验。继续预训练的成本比微调高一个数量级但效果也更根本。如果你的领域和通用领域差异极大比如古文、代码、数学证明继续预训练值得投入。如果只是想让模型学会特定任务的输出格式直接微调更划算。3. 微调让通用模型变成领域专家3.1 全量微调与参数高效微调的选择微调分两条路全量微调和参数高效微调。全量微调更新所有参数效果最好但成本最高。一个7B模型全量微调需要多张A100显存占用超过100GB。参数高效微调只更新一小部分参数比如LoRA只训练低秩矩阵显存占用降到十几GB单卡就能跑。LoRA的原理可以用一个类比解释假设原始权重是一个大矩阵全量微调是把这个矩阵每个元素都改一遍LoRA是认为微调带来的变化可以用两个小矩阵相乘来近似只训练这两个小矩阵。这样参数量从几十亿降到几百万但效果能接近全量微调。QLoRA更进一步把原始模型量化到4-bit再在上面加LoRA。这样7B模型微调只需要6GB显存消费级显卡就能跑。代价是训练速度慢一些精度损失一点点但性价比极高。微调方式显存需求训练速度效果适用场景全量微调极高快最好数据充足、算力充足LoRA中等中等接近全量大多数场景首选QLoRA低慢略低于LoRA消费级硬件Adapter低中等中等多任务切换Prefix Tuning低快中等生成任务3.2 LoRA微调实战以Qwen为例下面是一套可直接复现的LoRA微调流程。环境准备pip install transformers datasets peft accelerate bitsandbytes pip install modelscope # 国内下载模型方便数据准备是关键。指令微调数据通常构造成JSON格式[ { instruction: 判断以下文本的情感倾向, input: 这家餐厅的服务态度太差了等了一个小时都没上菜, output: 负面 } ]数据质量比数量重要。我试过用500条精心标注的数据超过5000条噪声数据的效果。标注时要确保指令清晰无歧义、输入输出格式统一、覆盖各种边界情况、没有重复样本。训练脚本核心参数from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, # 秩越大容量越强但参数越多 lora_alpha32, # 缩放因子通常设为r的2-4倍 target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_LM ) training_args TrainingArguments( per_device_train_batch_size4, gradient_accumulation_steps4, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategyepoch, fp16True, )参数选择经验r值简单任务4-8够用复杂任务可以到16-32。再大收益递减。target_modules至少包含q_proj和v_proj。加上k_proj和o_proj效果更好但参数翻倍。学习率LoRA通常用1e-4到3e-4比全量微调大一个数量级。Epoch数1-3个Epoch。超过3个容易过拟合表现为训练loss持续下降但验证loss上升。3.3 微调效果评估与迭代微调完了怎么判断好不好不能只看训练loss。我通常从三个维度评估自动指标对于分类任务看准确率、F1对于生成任务看BLEU、ROUGE。但这些指标和人类感受有差距只能做参考。人工评估随机抽100条测试样本人工判断输出是否合理。重点看格式是否正确、内容是否准确、有没有胡编乱造、语气是否合适。对抗测试故意输入边界情况看模型是否稳定。比如输入空字符串、超长文本、包含特殊符号、和训练数据分布差异大的样本。一个常见问题微调后模型变得只会做微调任务通用对话能力下降。这叫灾难性遗忘。解决办法是在微调数据中混入10%-20%的通用指令数据或者降低学习率、减少训练步数。如果效果不达标排查顺序是数据质量→数据量→超参数→模型选择。大多数时候问题出在数据上而不是模型或参数。4. Agent让大模型从会说到会做4.1 Agent的核心组件与工作原理Agent这个词听起来玄乎拆开看就是大模型工具记忆规划。大模型是大脑工具是手脚记忆是笔记本规划是做事的方法论。一个典型的Agent工作循环感知接收用户输入理解意图规划拆解任务决定先做什么后做什么行动调用工具执行具体操作观察获取工具返回结果反思判断是否完成目标没完成则回到步骤2举个例子用户说帮我查一下明天北京的天气如果下雨就提醒我带伞。Agent的思考过程是先调用天气API查北京明天天气→得到结果中雨→判断条件下雨成立→生成提醒明天北京有中雨记得带伞。这个过程中大模型负责理解意图和生成决策工具负责获取实时信息记忆负责保存上下文规划负责拆解步骤。四者缺一不可。4.2 主流Agent框架对比与选型框架特点适用场景上手难度LangChain生态最全组件丰富快速原型、复杂流程中等LlamaIndex专注RAG和检索知识库问答低AutoGen多Agent协作复杂任务分解中等CrewAI角色扮演式协作模拟团队工作流低Dify低代码平台非技术人员搭建极低选框架的原则是能用简单方案解决就不要上复杂框架。我见过有人用LangChain搭了一个Agent结果发现核心逻辑就是一个if-else加一次API调用。过度工程化是Agent开发中最常见的坑。对于大多数场景我的建议是先用原生API加简单函数调用实现遇到瓶颈再引入框架。这样你对每个环节都有掌控力调试也方便。4.3 从零搭建一个Agent的实操以论文助手Agent为例功能是用户给一个研究主题Agent自动搜索相关论文、总结要点、生成综述。工具定义tools [ { name: search_papers, description: 根据关键词搜索学术论文返回标题和摘要, parameters: { query: {type: string, description: 搜索关键词} } }, { name: summarize, description: 对给定文本进行摘要, parameters: { text: {type: string, description: 待摘要文本} } } ]Agent主循环def agent_loop(user_input, max_steps10): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_input}) for step in range(max_steps): response llm.chat(messages, toolstools) if response.tool_calls: for tool_call in response.tool_calls: result execute_tool(tool_call) messages.append({role: tool, content: result}) else: return response.content return 达到最大步数限制关键设计点最大步数限制防止Agent陷入死循环。通常10-20步足够。工具描述要清晰大模型根据描述决定调用哪个工具。描述模糊会导致错误调用。错误处理工具调用失败时把错误信息返回给模型让它决定重试还是换方法。上下文管理步数多了上下文会超长需要做摘要或截断。实测经验Agent的稳定性比单次对话差很多。单次对话准确率90%的模型在10步Agent任务中成功率可能只有30%。因为每一步的小错误会累积。解决办法是增加验证步骤每步执行后让模型确认结果是否合理。4.4 Agent的并发与性能优化当Agent从demo走向生产并发是绕不开的坎。一个Agent请求可能包含多次LLM调用和工具调用响应时间从几秒到几十秒不等。如果每个请求都同步处理服务器很快就被打满。优化思路分三层请求层用异步IO处理并发请求。Python的asyncio配合aiohttp可以轻松支撑几百并发。关键是所有IO操作都要异步化包括LLM API调用、数据库查询、外部工具调用。缓存层很多Agent请求是重复的。比如多个用户问同一个问题或者Agent在循环中重复调用同一个工具。加一层语义缓存相似问题直接返回缓存结果能大幅降低LLM调用次数。模型层不是所有步骤都需要大模型。简单的意图分类、参数提取可以用小模型甚至规则引擎。只在关键决策点调用大模型。这样既省成本又提速度。优化手段效果实现难度异步IO并发提升5-10倍中等语义缓存重复请求降80%中等小模型分流成本降50%低流式输出首字延迟降90%低批处理吞吐提升3倍高5. 提示词工程与上下文工程5.1 提示词工程的核心原则提示词工程不是玄学有明确的原则可循。我总结为四条明确角色告诉模型你是一个资深律师比帮我分析合同效果好得多。角色设定会激活模型在该领域的知识。提供示例Few-shot比Zero-shot稳定。给2-3个输入输出示例模型就能模仿格式和风格。示例要覆盖典型情况和边界情况。分步思考复杂任务让模型一步一步思考。这能显著提升推理准确率。原理是给模型更多计算步骤相当于让它打草稿。约束输出明确指定输出格式。比如以JSON格式返回包含name、age、city三个字段。这样后续程序处理方便。一个反直觉的发现提示词不是越长越好。过长的提示词会稀释关键信息模型可能抓不住重点。我试过把提示词从500字精简到200字效果反而提升。关键是信息密度不是长度。5.2 上下文工程比提示词更重要的能力提示词工程关注怎么说上下文工程关注给模型看什么。在实际应用中后者往往更重要。上下文工程的核心问题是在有限的上下文窗口内放哪些信息能最大化模型表现。这涉及信息的检索、排序、压缩、拼接。以RAG检索增强生成为例流程是用户提问→检索相关文档→把文档和问题一起给模型→模型生成回答。这里每个环节都有优化空间检索用向量检索还是关键词检索混合检索通常更好。检索多少条太多会超上下文太少可能漏关键信息。通常5-10条。排序检索回来的文档按相关性排序最相关的放最前面。模型对开头和结尾的信息更敏感。压缩长文档只保留和问题相关的段落。可以用小模型做抽取式摘要。拼接文档之间加分隔符标注来源。格式清晰能帮助模型定位信息。一个实用技巧在上下文末尾重复一遍核心问题。模型对最近的内容注意力更强这样能防止它忘了要回答什么。5.3 提示词与上下文的协同优化提示词和上下文不是孤立的。好的提示词会指导模型如何利用上下文。比如你是一个客服助手。根据以下知识库内容回答用户问题。 如果知识库中没有相关信息直接说这个问题我需要转接人工客服不要编造。 知识库 {context} 用户问题{question}这个提示词做了三件事设定角色、给出知识库、规定不知道时的行为。三者配合才能产出可靠回答。优化是一个迭代过程。我的做法是先写一版提示词跑100条测试用例看哪些错了分析错误原因针对性修改提示词或调整上下文策略再跑测试。循环几轮后效果会明显提升。6. 常见问题与排查技巧实录6.1 微调与Agent开发中的典型问题问题现象可能原因排查方法解决方案微调后loss不下降学习率太小/数据有问题检查数据格式、打印几条样本调大学习率、清洗数据微调后通用能力下降灾难性遗忘测试通用问答混入通用数据、降低学习率模型输出重复解码策略问题检查temperature和repetition_penalty调高temperature、加惩罚Agent死循环工具返回不明确打印每步的输入输出加最大步数、优化工具描述Agent调用错误工具工具描述模糊检查工具description写清楚工具功能和参数RAG回答不准确检索质量差检查检索结果相关性优化检索策略、加rerank推理速度慢模型太大/未量化测显存占用和延迟量化、换小模型、加缓存6.2 独家避坑经验数据标注的坑标注人员理解不一致会导致数据矛盾。解决办法是先标100条开会对齐标准再批量标注。标注指南要具体到每个边界情况怎么处理。显存溢出的坑QLoRA微调时如果序列长度设太长比如4096即使4-bit量化也可能OOM。解决办法是先用512长度跑通再逐步增加。或者用梯度检查点换显存。Agent工具调用的坑工具返回结果太长会撑爆上下文。比如搜索返回10篇论文全文。解决办法是工具内部先做摘要只返回关键信息。模型选择的坑不要盲目追求大参数。7B模型微调后在小任务上可能超过70B零样本。关键是匹配任务复杂度和数据量。评估的坑自动指标高不代表实际好用。一定要人工看输出。我见过BLEU很高但回答完全不可用的案例。6.3 性能优化速查当系统变慢时按以下顺序排查LLM调用次数一个请求调了几次LLM能合并吗上下文长度是不是塞了太多无关信息工具延迟哪个工具最慢能缓存吗并发瓶颈是IO密集还是CPU密集异步了吗模型大小能用小模型吗能量化吗这套排查流程帮我解决过很多线上问题。大多数性能问题不是模型本身慢而是架构设计不合理。7. 技术选型的决策逻辑7.1 从需求倒推技术栈技术选型没有标准答案只有适不适合。我的决策框架是第一步明确任务类型。是分类、生成、问答还是Agent分类任务小模型微调就够生成任务需要大模型Agent需要模型工具规划。第二步评估数据情况。有多少标注数据数据质量如何数据少就用提示词工程Few-shot数据多就微调。第三步确定延迟要求。实时对话要求首字延迟1秒可以用小模型或流式输出离线批处理可以用大模型慢慢跑。第四步算成本账。API调用按Token计费自部署按GPU小时计费。高频调用自部署划算低频调用API划算。7.2 不同规模团队的选择建议个人开发者优先用API省去部署运维。需要微调时用QLoRA消费级显卡。Agent用LangChain快速搭建。小团队3-10人可以自部署7B-14B模型用vLLM做推理加速。微调用LoRA。Agent自研核心逻辑外围用开源框架。中大团队自部署70B级别模型做继续预训练和全量微调。Agent平台化支持多业务接入。建立数据飞轮持续迭代。一个反直觉的建议不要过早追求自研模型。用API提示词工程能解决80%的问题。剩下20%再考虑微调。自研模型的门槛比想象中高数据、算力、人才缺一不可。7.3 技术演进与个人学习节奏大模型领域变化极快今天的最优解明天可能就过时了。但底层原理相对稳定Transformer架构、注意力机制、梯度下降、强化学习。把底层学扎实上层工具怎么变都能快速适应。我的学习节奏是每周花2小时看新论文和开源项目保持对前沿的敏感每月做一个小项目把新学的东西落地每季度复盘一次更新自己的技术栈。不要焦虑跟不上。这个领域足够大每个人都能找到自己的位置。有人擅长底层训练有人擅长应用开发有人擅长产品设计。找到自己的差异化优势比盲目追新更重要。最后分享一个我常用的学习方法费曼技巧。学完一个概念后试着用最简单的话讲给不懂的人听。如果讲不清楚说明自己没真懂。我写这篇综述的过程也是对自己知识体系的一次梳理。很多之前模糊的地方在写的过程中变清晰了。输出是最好的输入这话在大模型学习上同样成立。 大模型技术全景：从预训练、微调到Agent的完整链路与实战指南
1. 大模型技术全景的认知框架1.1 从热搜词看技术演进脉络把大模型、预训练、Agent、LLM、微调这几个词摆在一起其实已经勾勒出了一条完整的技术链路。预训练是地基微调是装修Agent是住进去之后能自己干活的管家而LLM则是这整栋楼的统称。很多人学大模型容易陷入一个误区一上来就扎进LoRA怎么调、Qwen怎么部署结果调通了却说不清楚模型到底在干什么。我见过太多人卡在能跑通代码但讲不清原理的阶段面试或者做技术方案汇报时露怯。这条链路的内在逻辑是预训练解决通识问题微调解决专业问题Agent解决行动问题。预训练阶段模型在海量文本上学习语言的统计规律相当于一个人从小学读到大学什么都学一点微调阶段用特定领域数据继续训练相当于读了个硕士博士专精某个方向Agent则是给这个毕业生配上手脚和工具箱让它能查资料、调API、操作软件真正把知识变成行动。理解这个框架的意义在于当你在实际项目中遇到问题时能快速定位是哪个环节出了毛病。模型回答泛泛而谈可能是预训练知识够但微调没到位。模型能回答但不会用工具那是Agent层没搭好。模型在特定任务上胡言乱语大概率是微调数据质量有问题。这种分层思维能帮你省下大量盲目试错的时间。1.2 不同角色的学习路径差异我接触过各种背景想学大模型的人发现一个规律不要试图一次性吃透所有环节而是根据自己的目标倒推需要掌握什么。如果你是应用开发者重点应该放在Agent开发和提示词工程上。预训练和微调的底层细节可以暂时跳过知道概念即可。你需要的是理解LLM的输入输出特性、上下文窗口限制、Token计费逻辑然后学会用LangChain、LlamaIndex这类框架搭建Agent。这条路径上手快一两周就能做出能用的东西。如果你是算法工程师微调是核心技能。你需要理解LoRA、QLoRA、Adapter这些参数高效微调方法的原理和适用场景知道什么数据配比能出什么效果能诊断loss曲线异常。这条路径需要一定的深度学习基础但不需要从头训练模型。如果你是研究者或者想深入底层预训练和模型架构是必修课。Transformer的注意力机制、位置编码、归一化策略、混合专家模型的路由逻辑这些都需要啃论文加动手实验。这条路径周期最长但天花板也最高。我个人的建议是先花两天时间把整条链路的概念过一遍然后选一个方向深扎。最怕的是每个环节都浅尝辄止最后什么都做不出来。2. 预训练大模型的知识底座2.1 预训练到底在做什么预训练的本质是让模型学会预测下一个Token。给定一段文本模型不断预测下一个词是什么预测错了就调整参数预测对了就强化。这个过程重复几万亿次之后模型就掌握了语言的语法、事实知识、甚至一定的推理能力。为什么预测下一个词这么简单的任务能学到这么多东西因为要准确预测下一个词模型必须理解上下文。比如中国的首都是___模型要知道北京苹果公司的CEO是___模型要知道库克。这些知识不是显式教给模型的而是从海量文本中自动提取的。预训练的数据量级是惊人的。以LLaMA系列为例训练数据达到数万亿Token涵盖网页、书籍、论文、代码等多种来源。数据处理流程包括去重、质量过滤、敏感内容剔除、Token化等步骤。数据质量直接决定模型能力上限这也是为什么各家大厂在数据清洗上投入巨大。训练成本同样惊人。一个百亿参数模型在千卡集群上训练数周是常态电费就是天文数字。所以绝大多数团队不会从零预训练而是基于开源模型做继续预训练或微调。2.2 预训练模型的选择策略面对Hugging Face上成千上万的预训练模型怎么选我总结了一个决策树考量维度选择建议理由中文任务为主Qwen、Baichuan、ChatGLM中文语料占比高原生支持好英文任务为主LLaMA、Mistral、Gemma英文能力最强社区生态丰富多模态需求Qwen-VL、LLaVA、InternVL支持图文理解视觉编码器成熟端侧部署Phi、TinyLlama、Qwen-1.8B参数量小量化后可在消费级硬件运行代码生成CodeLLaMA、DeepSeek-Coder代码语料训练充分补全能力强选模型不能只看榜单分数。Open LLM Leaderboard上的排名有参考价值但实际表现要看你的具体任务。我见过榜单排名很高的模型在特定领域问答上不如小模型的情况。最靠谱的方法是拿你的真实数据做小规模评测跑个几百条测试用例看准确率、响应速度、输出格式稳定性。还有一个容易被忽略的点模型的Tokenizer会影响中文处理效果。有些英文模型的中文Tokenizer词表很小一个中文字被拆成多个Token导致上下文窗口浪费、推理速度慢、语义丢失。选中文模型时一定要看词表大小和中文Token占比。2.3 继续预训练与领域适配当你手头有大量领域文本比如医疗病历、法律文书、金融研报想让模型更懂这个领域继续预训练是一个选择。做法是在领域语料上以较小的学习率继续训练让模型调整参数分布。继续预训练的关键参数学习率通常设为原始预训练的1/10到1/100比如1e-5到1e-6。太大容易灾难性遗忘太小则学不到新知识。数据配比领域数据和通用数据的比例建议在1:1到1:10之间。纯领域数据会导致通用能力下降。训练步数不是越多越好。通常1-3个Epoch就够了过多会过拟合。序列长度根据领域文本特点设置。法律文书可能很长需要4096甚至8192对话数据可以短一些。踩过的坑有一次用纯医疗数据继续预训练结果模型连今天天气怎么样都回答不好了。后来混入30%通用数据通用能力保住了医疗问答也提升了。这个配比需要反复实验。继续预训练的成本比微调高一个数量级但效果也更根本。如果你的领域和通用领域差异极大比如古文、代码、数学证明继续预训练值得投入。如果只是想让模型学会特定任务的输出格式直接微调更划算。3. 微调让通用模型变成领域专家3.1 全量微调与参数高效微调的选择微调分两条路全量微调和参数高效微调。全量微调更新所有参数效果最好但成本最高。一个7B模型全量微调需要多张A100显存占用超过100GB。参数高效微调只更新一小部分参数比如LoRA只训练低秩矩阵显存占用降到十几GB单卡就能跑。LoRA的原理可以用一个类比解释假设原始权重是一个大矩阵全量微调是把这个矩阵每个元素都改一遍LoRA是认为微调带来的变化可以用两个小矩阵相乘来近似只训练这两个小矩阵。这样参数量从几十亿降到几百万但效果能接近全量微调。QLoRA更进一步把原始模型量化到4-bit再在上面加LoRA。这样7B模型微调只需要6GB显存消费级显卡就能跑。代价是训练速度慢一些精度损失一点点但性价比极高。微调方式显存需求训练速度效果适用场景全量微调极高快最好数据充足、算力充足LoRA中等中等接近全量大多数场景首选QLoRA低慢略低于LoRA消费级硬件Adapter低中等中等多任务切换Prefix Tuning低快中等生成任务3.2 LoRA微调实战以Qwen为例下面是一套可直接复现的LoRA微调流程。环境准备pip install transformers datasets peft accelerate bitsandbytes pip install modelscope # 国内下载模型方便数据准备是关键。指令微调数据通常构造成JSON格式[ { instruction: 判断以下文本的情感倾向, input: 这家餐厅的服务态度太差了等了一个小时都没上菜, output: 负面 } ]数据质量比数量重要。我试过用500条精心标注的数据超过5000条噪声数据的效果。标注时要确保指令清晰无歧义、输入输出格式统一、覆盖各种边界情况、没有重复样本。训练脚本核心参数from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, # 秩越大容量越强但参数越多 lora_alpha32, # 缩放因子通常设为r的2-4倍 target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_LM ) training_args TrainingArguments( per_device_train_batch_size4, gradient_accumulation_steps4, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategyepoch, fp16True, )参数选择经验r值简单任务4-8够用复杂任务可以到16-32。再大收益递减。target_modules至少包含q_proj和v_proj。加上k_proj和o_proj效果更好但参数翻倍。学习率LoRA通常用1e-4到3e-4比全量微调大一个数量级。Epoch数1-3个Epoch。超过3个容易过拟合表现为训练loss持续下降但验证loss上升。3.3 微调效果评估与迭代微调完了怎么判断好不好不能只看训练loss。我通常从三个维度评估自动指标对于分类任务看准确率、F1对于生成任务看BLEU、ROUGE。但这些指标和人类感受有差距只能做参考。人工评估随机抽100条测试样本人工判断输出是否合理。重点看格式是否正确、内容是否准确、有没有胡编乱造、语气是否合适。对抗测试故意输入边界情况看模型是否稳定。比如输入空字符串、超长文本、包含特殊符号、和训练数据分布差异大的样本。一个常见问题微调后模型变得只会做微调任务通用对话能力下降。这叫灾难性遗忘。解决办法是在微调数据中混入10%-20%的通用指令数据或者降低学习率、减少训练步数。如果效果不达标排查顺序是数据质量→数据量→超参数→模型选择。大多数时候问题出在数据上而不是模型或参数。4. Agent让大模型从会说到会做4.1 Agent的核心组件与工作原理Agent这个词听起来玄乎拆开看就是大模型工具记忆规划。大模型是大脑工具是手脚记忆是笔记本规划是做事的方法论。一个典型的Agent工作循环感知接收用户输入理解意图规划拆解任务决定先做什么后做什么行动调用工具执行具体操作观察获取工具返回结果反思判断是否完成目标没完成则回到步骤2举个例子用户说帮我查一下明天北京的天气如果下雨就提醒我带伞。Agent的思考过程是先调用天气API查北京明天天气→得到结果中雨→判断条件下雨成立→生成提醒明天北京有中雨记得带伞。这个过程中大模型负责理解意图和生成决策工具负责获取实时信息记忆负责保存上下文规划负责拆解步骤。四者缺一不可。4.2 主流Agent框架对比与选型框架特点适用场景上手难度LangChain生态最全组件丰富快速原型、复杂流程中等LlamaIndex专注RAG和检索知识库问答低AutoGen多Agent协作复杂任务分解中等CrewAI角色扮演式协作模拟团队工作流低Dify低代码平台非技术人员搭建极低选框架的原则是能用简单方案解决就不要上复杂框架。我见过有人用LangChain搭了一个Agent结果发现核心逻辑就是一个if-else加一次API调用。过度工程化是Agent开发中最常见的坑。对于大多数场景我的建议是先用原生API加简单函数调用实现遇到瓶颈再引入框架。这样你对每个环节都有掌控力调试也方便。4.3 从零搭建一个Agent的实操以论文助手Agent为例功能是用户给一个研究主题Agent自动搜索相关论文、总结要点、生成综述。工具定义tools [ { name: search_papers, description: 根据关键词搜索学术论文返回标题和摘要, parameters: { query: {type: string, description: 搜索关键词} } }, { name: summarize, description: 对给定文本进行摘要, parameters: { text: {type: string, description: 待摘要文本} } } ]Agent主循环def agent_loop(user_input, max_steps10): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_input}) for step in range(max_steps): response llm.chat(messages, toolstools) if response.tool_calls: for tool_call in response.tool_calls: result execute_tool(tool_call) messages.append({role: tool, content: result}) else: return response.content return 达到最大步数限制关键设计点最大步数限制防止Agent陷入死循环。通常10-20步足够。工具描述要清晰大模型根据描述决定调用哪个工具。描述模糊会导致错误调用。错误处理工具调用失败时把错误信息返回给模型让它决定重试还是换方法。上下文管理步数多了上下文会超长需要做摘要或截断。实测经验Agent的稳定性比单次对话差很多。单次对话准确率90%的模型在10步Agent任务中成功率可能只有30%。因为每一步的小错误会累积。解决办法是增加验证步骤每步执行后让模型确认结果是否合理。4.4 Agent的并发与性能优化当Agent从demo走向生产并发是绕不开的坎。一个Agent请求可能包含多次LLM调用和工具调用响应时间从几秒到几十秒不等。如果每个请求都同步处理服务器很快就被打满。优化思路分三层请求层用异步IO处理并发请求。Python的asyncio配合aiohttp可以轻松支撑几百并发。关键是所有IO操作都要异步化包括LLM API调用、数据库查询、外部工具调用。缓存层很多Agent请求是重复的。比如多个用户问同一个问题或者Agent在循环中重复调用同一个工具。加一层语义缓存相似问题直接返回缓存结果能大幅降低LLM调用次数。模型层不是所有步骤都需要大模型。简单的意图分类、参数提取可以用小模型甚至规则引擎。只在关键决策点调用大模型。这样既省成本又提速度。优化手段效果实现难度异步IO并发提升5-10倍中等语义缓存重复请求降80%中等小模型分流成本降50%低流式输出首字延迟降90%低批处理吞吐提升3倍高5. 提示词工程与上下文工程5.1 提示词工程的核心原则提示词工程不是玄学有明确的原则可循。我总结为四条明确角色告诉模型你是一个资深律师比帮我分析合同效果好得多。角色设定会激活模型在该领域的知识。提供示例Few-shot比Zero-shot稳定。给2-3个输入输出示例模型就能模仿格式和风格。示例要覆盖典型情况和边界情况。分步思考复杂任务让模型一步一步思考。这能显著提升推理准确率。原理是给模型更多计算步骤相当于让它打草稿。约束输出明确指定输出格式。比如以JSON格式返回包含name、age、city三个字段。这样后续程序处理方便。一个反直觉的发现提示词不是越长越好。过长的提示词会稀释关键信息模型可能抓不住重点。我试过把提示词从500字精简到200字效果反而提升。关键是信息密度不是长度。5.2 上下文工程比提示词更重要的能力提示词工程关注怎么说上下文工程关注给模型看什么。在实际应用中后者往往更重要。上下文工程的核心问题是在有限的上下文窗口内放哪些信息能最大化模型表现。这涉及信息的检索、排序、压缩、拼接。以RAG检索增强生成为例流程是用户提问→检索相关文档→把文档和问题一起给模型→模型生成回答。这里每个环节都有优化空间检索用向量检索还是关键词检索混合检索通常更好。检索多少条太多会超上下文太少可能漏关键信息。通常5-10条。排序检索回来的文档按相关性排序最相关的放最前面。模型对开头和结尾的信息更敏感。压缩长文档只保留和问题相关的段落。可以用小模型做抽取式摘要。拼接文档之间加分隔符标注来源。格式清晰能帮助模型定位信息。一个实用技巧在上下文末尾重复一遍核心问题。模型对最近的内容注意力更强这样能防止它忘了要回答什么。5.3 提示词与上下文的协同优化提示词和上下文不是孤立的。好的提示词会指导模型如何利用上下文。比如你是一个客服助手。根据以下知识库内容回答用户问题。 如果知识库中没有相关信息直接说这个问题我需要转接人工客服不要编造。 知识库 {context} 用户问题{question}这个提示词做了三件事设定角色、给出知识库、规定不知道时的行为。三者配合才能产出可靠回答。优化是一个迭代过程。我的做法是先写一版提示词跑100条测试用例看哪些错了分析错误原因针对性修改提示词或调整上下文策略再跑测试。循环几轮后效果会明显提升。6. 常见问题与排查技巧实录6.1 微调与Agent开发中的典型问题问题现象可能原因排查方法解决方案微调后loss不下降学习率太小/数据有问题检查数据格式、打印几条样本调大学习率、清洗数据微调后通用能力下降灾难性遗忘测试通用问答混入通用数据、降低学习率模型输出重复解码策略问题检查temperature和repetition_penalty调高temperature、加惩罚Agent死循环工具返回不明确打印每步的输入输出加最大步数、优化工具描述Agent调用错误工具工具描述模糊检查工具description写清楚工具功能和参数RAG回答不准确检索质量差检查检索结果相关性优化检索策略、加rerank推理速度慢模型太大/未量化测显存占用和延迟量化、换小模型、加缓存6.2 独家避坑经验数据标注的坑标注人员理解不一致会导致数据矛盾。解决办法是先标100条开会对齐标准再批量标注。标注指南要具体到每个边界情况怎么处理。显存溢出的坑QLoRA微调时如果序列长度设太长比如4096即使4-bit量化也可能OOM。解决办法是先用512长度跑通再逐步增加。或者用梯度检查点换显存。Agent工具调用的坑工具返回结果太长会撑爆上下文。比如搜索返回10篇论文全文。解决办法是工具内部先做摘要只返回关键信息。模型选择的坑不要盲目追求大参数。7B模型微调后在小任务上可能超过70B零样本。关键是匹配任务复杂度和数据量。评估的坑自动指标高不代表实际好用。一定要人工看输出。我见过BLEU很高但回答完全不可用的案例。6.3 性能优化速查当系统变慢时按以下顺序排查LLM调用次数一个请求调了几次LLM能合并吗上下文长度是不是塞了太多无关信息工具延迟哪个工具最慢能缓存吗并发瓶颈是IO密集还是CPU密集异步了吗模型大小能用小模型吗能量化吗这套排查流程帮我解决过很多线上问题。大多数性能问题不是模型本身慢而是架构设计不合理。7. 技术选型的决策逻辑7.1 从需求倒推技术栈技术选型没有标准答案只有适不适合。我的决策框架是第一步明确任务类型。是分类、生成、问答还是Agent分类任务小模型微调就够生成任务需要大模型Agent需要模型工具规划。第二步评估数据情况。有多少标注数据数据质量如何数据少就用提示词工程Few-shot数据多就微调。第三步确定延迟要求。实时对话要求首字延迟1秒可以用小模型或流式输出离线批处理可以用大模型慢慢跑。第四步算成本账。API调用按Token计费自部署按GPU小时计费。高频调用自部署划算低频调用API划算。7.2 不同规模团队的选择建议个人开发者优先用API省去部署运维。需要微调时用QLoRA消费级显卡。Agent用LangChain快速搭建。小团队3-10人可以自部署7B-14B模型用vLLM做推理加速。微调用LoRA。Agent自研核心逻辑外围用开源框架。中大团队自部署70B级别模型做继续预训练和全量微调。Agent平台化支持多业务接入。建立数据飞轮持续迭代。一个反直觉的建议不要过早追求自研模型。用API提示词工程能解决80%的问题。剩下20%再考虑微调。自研模型的门槛比想象中高数据、算力、人才缺一不可。7.3 技术演进与个人学习节奏大模型领域变化极快今天的最优解明天可能就过时了。但底层原理相对稳定Transformer架构、注意力机制、梯度下降、强化学习。把底层学扎实上层工具怎么变都能快速适应。我的学习节奏是每周花2小时看新论文和开源项目保持对前沿的敏感每月做一个小项目把新学的东西落地每季度复盘一次更新自己的技术栈。不要焦虑跟不上。这个领域足够大每个人都能找到自己的位置。有人擅长底层训练有人擅长应用开发有人擅长产品设计。找到自己的差异化优势比盲目追新更重要。最后分享一个我常用的学习方法费曼技巧。学完一个概念后试着用最简单的话讲给不懂的人听。如果讲不清楚说明自己没真懂。我写这篇综述的过程也是对自己知识体系的一次梳理。很多之前模糊的地方在写的过程中变清晰了。输出是最好的输入这话在大模型学习上同样成立。