陆陆续续有不少学员和同行问我学完大模型的基础概念之后下一步到底该学什么我的答案很直接——去看那些真正在做AI应用落地的人都在用什么技术。翻来覆去绕不开三样东西RAG、Agent、微调。这三个词同时也是市面上主流AI大模型课程包括北大青鸟这类职业培训的核心目录原因很简单它们是当前大模型从能聊天走向能用、好用、创造价值的三条必经之路。这篇文章我就围绕这三个方向把背后的技术链路拆开来讲顺带把我自己在实际项目中踩过的坑和验证过的做法整理出来。无论你是刚入门的新手还是已经会调API、想往深处走的开发者都可以把这份内容当成一份技术拆解笔记来看。1. 先搞清楚为什么是RAG、Agent与微调而不是别的1.1 大模型落地时面对的三个现实问题在做AI应用之前得先承认大模型本身存在三块明显的短板。第一是不懂私有数据。基础模型训练时用的是公开语料你公司的规章制度、产品手册、历史工单、客户聊天记录模型一概不知。如果光靠通用大模型回答业务问题它会一本正经地给你编一个不存在的流程这就是幻觉的典型表现。第二是不能行动。模型本质上是一个文本生成器它能回答订单怎么退款但不会真的去调退款接口把订单退掉。第三是能力不专。通用模型会写诗、会翻译但如果你要一个专门做医疗诊断辅助、法律文书审阅或者工业质检报告的模型它的输出风格和知识密度明显不够用。这三块短板恰好对应RAG、Agent和微调三种技术手段。RAG负责把外部知识接进来让模型知道它原本不知道的事Agent负责把行动能力接进去让模型能调用工具、执行任务微调负责把模型本身的权重改到更适配特定场景让它的输出习惯、语气、知识结构都向你的业务靠拢。理解这个对应关系你再看任何一门大模型应用课程的大纲都会觉得清晰很多。1.2 三者不是替代关系是组合关系很多新人容易有个误解以为学了RAG就不用微调或者做了Agent就不需要RAG。我在实际项目里见过不少团队一上来就信心满满地要微调一个行业大模型结果调完才发现新知识照样不知道幻觉照样有还白白烧了一堆GPU算力。原因很简单——微调改变的是模型的权重和表达习惯它并不能让模型凭空获得一个数据库里的实时信息。实际工程里这三者经常同时出现在同一条技术链路上。我举一个最常见的企业知识库助手场景先用微调让模型具备企业的专业表达习惯比如客服语气、工单格式再用RAG把最新的制度文档和产品资料接进上下文解决知识实时性的问题最后再用Agent去调用OA系统接口完成请假、查余额这类操作。在这个架构里三者职责不同缺一个体验就掉一截。所以我在给别人的学习建议里一直强调一个观点不要把这三项技术分开孤立地学要把它们放在同一条业务问题到技术方案的主线上来理解。这也是为什么很多课程会把三者并列为核心技术模块的原因——它们原本就长在同一个工程项目里拆开讲只是为了降低学习门槛最终一定要合起来用。1.3 三门技术各自的投入产出比把三者放在一起对比一下也能帮你决定先学哪个。技术方向解决的核心问题入门门槛硬件要求适用场景RAG知识缺失、知识实时性低无纯API可跑文档问答、客服知识库、企业搜索Agent模型无法调用工具、无法执行任务中无API接入即可自动化流程、工作流Agent、多步骤任务微调输出风格不匹配、领域能力不足高高需要GPU垂直行业模型、定制化语气、格式固化看这张表你会发现学习成本的顺序和落地价值的顺序刚好是反的RAG最好上手也最容易被业务直接认可Agent需要一点开发功底但一旦跑通能做的事情立刻上一个量级微调门槛最高但它带来的是模型能力的质变——因为你在改模型本身。2. RAG深度拆解知识库问答的完整链路与检索优化实战2.1 RAG的完整流程与各环节定位RAGRetrieval-Augmented Generation检索增强生成这个名字听起来很高深但它背后的思路其实很朴素让模型在回答问题之前先去一个知识库里检索相关内容再把检索到的内容拼进提示词最后生成答案。整个过程可以拆成几个环节文档导入、文本清洗、分块chunking、向量化Embedding、向量存储、查询检索、重排序Rerank、上下文注入、模型生成。我见过很多初学的朋友把RAG等同于向量数据库加一个大模型API这是一个典型的简化认知。向量数据库只是存储和检索的工具真正的效果差距往往出在导入之后的分块、检索之后的重排序上。整条链路里任何一个环节做得粗糙最终回答质量都会大打折扣。所以做RAG项目别急着调大模型的prompt先把前置链路打磨好。在真实项目里还有一个被很多人忽略的环节文档格式解析。我做过一个电网行业的项目原始资料全是PDF扫描件和Word排版混乱的文档不做解析直接去分块结果向量库里全是乱码和页眉。后来不得不先接OCR服务做文字识别再按段落结构重新组织。这一步听起来枯燥但对最终效果影响极大。2.2 分块策略直接决定检索命中率先讲分块。文档导入后你不能直接整篇扔给模型——一方面上下文窗口有限另一方面大段文本向量化之后相似度检索的精度会下降。所以要把文档拆成一个个小块chunk。分块大小是有讲究的块太大检索到的内容里无关信息太多稀释了关键答案块太小一个完整语义被切开检索时容易漏掉核心信息。我这里用一组实验数据来说明同样一套技术文档chunk_size200的时候检索命中率hit rate大概在62%左右调到500hit rate能到75%再调到1000反而回落到68%。原因就是块太大之后召回的相关片段里混进了大量噪声导致最终注入上下文的有效信息密度下降。所以越大越好或越小越好都是错的要在具体数据集上做实验。我在项目中常用的做法是针对技术文档和制度文档chunk_size选400~700个tokenoverlap重叠设50~100。重叠的目的是防止关键句恰好落在两个块的边界上被切开。更进阶一点的做法是语义分块比如用LangChain的RecursiveCharacterTextSplitter或者语义切分器Semantic Chunker按段落、标题、句子边界来切让每个块尽量是一个完整的语义单元。数据清洗也很容易被忽略。原始PDF里经常有页眉页脚、重复段落、扫描错字这些垃圾内容进向量库之后检索时会被捞出来当答案非常影响体验。我的习惯是导入前先做一轮正则清洗把页眉、页码、超链接标记删掉表格数据尽量转成段落文本。2.3 检索优化查询改写、混合检索与重排序检索环节的核心指标是召回质量。直接拿用户的问题去向量库检索经常效果一般因为口语化问题和文档里的书面表达存在语义鸿沟。用户问那个退款流程是不是变了文档里写的是退款业务操作规范2024年修订版如果不做处理检索到的相关度可能很低。所以我在生产环境里通常会加三道优化。第一是查询改写。用户的问题往往简短、口语化我先把问题交给大模型改写成适合检索的书面表达比如把那个退款的流程是不是变了改写成查询退款流程的最新规定再拿改写后的文本去检索命中率立刻不一样。这个操作的成本很低但收益却非常稳定。第二是混合检索。向量检索擅长理解语义比如苹果能匹配到iPhone但关键词检索BM25擅长精确匹配比如产品编号、型号这类的专有名词。把两者的结果做加权融合能覆盖更多场景。我在实际项目里通常给BM25和向量检索各分配一部分权重具体权重需要通过评测集来调。第三是重排序Rerank。第一次检索往往要捞回20~30条候选然后我用一个专门的Rerank模型比如bge-reranker对这20~30条按相关性重新打分只保留前5条进上下文。这一步是RAG回答质量的分水岭——不做Rerank用户的体验经常会像好像相关但答不到点子上做了Rerank之后答案的精准度和可信度会有非常明显的提升。除了这三道优化还有一个常被忽视的细节注入上下文的顺序。把最相关的检索结果放在离用户问题最近的位置模型对它的注意力会更集中。另外如果检索结果和用户问题主题完全无关我宁可让模型明确回答根据当前资料无法回答也不要让它硬编。2.4 模型选型与向量库选择的经验参考关于Embedding模型我常用的是bge-m3中文场景下性价比很高支持8192的输入长度对长文档分块比较友好。OpenAI的text-embedding-3-large效果也很强但如果数据要出网很多企业会有合规顾虑。开源模型的好处是自己部署数据不出内网这一点在政企项目里是硬需求。向量数据库的选择看规模。个人项目和Demo可以用Chroma或FAISS轻量、上手快企业级项目我推荐Milvus或Qdrant支持分布式、权限管理和混合检索。生产环境里如果公司已经有了PostgreSQL直接用pgvector也是一种省事的方案避免多引入一套中间件。需要说明的是以上选型属于常规项目中的推荐组合具体还要根据你的数据量、并发要求、团队维护能力来做权衡。3. Agent深度拆解让大模型从说话变成办事3.1 Agent的核心机制与Tool Calling如果说RAG解决的是知识从哪来那么Agent解决的是事由谁来做。Agent智能体的核心机制是让大模型在一个循环里进行推理和决策模型先分析用户的目标拆解成子任务决定调用哪个工具Tool Calling然后根据工具返回的结果继续推理直到任务完成。我举个最直白的例子。你让模型帮我查一下上个月的销售数据并按周生成一张图表。没有Agent的API调用方案你必须自己写代码去数据库查询、再去生成图表模型全程只负责聊。有了Agent之后模型可以自主决定先调用一个数据库查询工具拿到结果后再调用一个图表生成工具最后把图表文件路径返回给你。模型的角色从一个回答者变成了任务的调度者。Tool Calling是Agent的基石。它本质上是在大模型的推理过程中把调用外部函数作为一种特殊输出格式。模型的输出里会包含函数名和参数我们的程序解析这段输出去执行真实的函数再把结果作为一条新的消息message送回给模型。这个来回就是一个最基本的Agent循环Agent Loop。当前主流的中文开源模型比如Qwen系列都对Tool Calling做了很好的支持这也是我能在本地跑通Agent项目的关键。3.2 规划、记忆与反思Agent的三块核心能力学Agent容易只学到会调工具但一个真正稳定的Agent还依赖另外两块能力。一个是规划能力。简单的单轮工具调用不需要太多规划但复杂任务比如帮我做一份行业调研报告需要模型把大目标拆成若干子任务并安排先后顺序。当前主流的规划模式有ReAct思考-行动-观察的循环和Plan-and-Execute先规划再执行。实践中我更喜欢把复杂任务交给有规划能力的框架比如LangGraph它能把Agent的节点和状态定义成一张清晰的图调试的时候能直观看到模型每一步在做什么定位问题会方便很多。另一个是记忆能力。Agent在跑多轮任务时上下文会不断膨胀如果不做管理很快会顶破上下文窗口。我的做法是把记忆分成两层短期记忆保留在会话上下文里用滑动窗口做裁剪长期记忆则沉淀到向量库比如把历史结果、用户偏好存起来需要时检索回来。这种分层记忆的设计在真实工程里几乎是必需品。反思Reflection是进阶设计。也就是让Agent在生成结果之后先自我检查一遍再输出。比如调研报告类Agent先生成一版草稿再让另一个评审Agent检查逻辑漏洞和数据缺失再返回修改。这个模式的成本会翻倍但在要求高可靠性的场景里非常值。我做过一个自动生成招标响应文档的Agent加入了自查环节之后文档被业务同事挑错的比例下降了接近一半。3.3 Agent框架怎么选从LangChain到LangGraph以及多智能体协作现在Agent相关的框架非常多很容易让人挑花眼。我的建议是先理解原理再选框架。如果你只是在做一个工具调用演示直接用OpenAI的Function Calling或国产模型的tool_calling接口就够了不需要框架。如果要做一个带多步骤、有条件分支、有状态管理的业务Agent用LangGraph比较合适它的可视化调试和状态管理做得成熟。如果做多智能体协作也就是几个Agent分别承担规划、执行、评审等角色可以看看AutoGen、AgentScope、CrewAI这类框架。我在实际项目中踩过的最大的坑是Agent进入死循环。模型反复调用同一个工具每次返回结果都差不多但它就是不结束。最夸张的一次一个任务在测试环境里跑了将近200轮工具调用把当天的成本配额全烧完了。解决思路有两个一是给循环设置最大轮次上限比如最多执行8轮工具调用二是给模型明确的终止条件当目标达成时必须输出结束标记。这些工程约束在框架层面有对应配置但很多人第一次写代码时会忽略。另外要注意Token消耗。Agent每多调用一次工具就要多消耗一轮上下文一个复杂任务跑下来几千甚至上万Token很正常。如果在生产环境跑一定要做成本预估比如设置单次任务的Token预算、限制工具调用的最大次数。我在项目里还会把每一步工具调用的输入输出都写入日志这样排查问题的时候一眼就能看出模型在哪一步开始犯迷糊。4. 微调实战从环境配置到Qwen2.5-7B模型部署的完整链路4.1 微调的适用边界与LoRA/QLoRA原理微调是三项技术里门槛最高、也最容易被滥用的一个。很多人一提到让模型更懂我的业务第一反应就是微调但在多数场景里RAG已经能解决知识缺失的问题再加上提示词工程做约束成本低、改起来快。只有当RAG和提示词都做到位了模型在语气风格、输出格式、领域术语上仍然不达标或者你对模型的私有知识有明确的固化要求时才值得上微调。微调的主流方案是LoRA和QLoRA。LoRA的思路很巧妙不修改整个大模型的权重而是给模型的一些线性层添加低秩矩阵作为旁路训练时只更新这个旁路参数最后把旁路合并回原模型。这样做的好处是7B级别模型的全参微调动辄需要几十G显存而LoRA只需要一张消费级显卡就能跑起来。QLoRA更进一步在LoRA的基础上把底模量化成4bit或8bit加载大幅降低显存占用是单卡玩家最实用的方案。我做微调时选择的基座模型是Qwen2.5-7B原因很实际它在中文场景的表现已经在社区里被验证过很多轮工具调用能力、指令跟随能力对中小型业务够用而且7B的体量在单卡上就能完成训练和推理。更小一点的Qwen3-0.6B也有很多人尝试适合做移动端或极低资源的嵌入式场景但对话和推理能力上限确实会低一些。4.2 环境配置与数据准备我以Qwen2.5-7B为例把完整流程走一遍。硬件上QLoRA方案用一张24G显存的显卡如RTX 4090或A10就够LoRA则建议32G以上显存。软件环境建议Ubuntu Python 3.10或3.11 CUDA 11.8或12.1核心依赖是transformers、peft、accelerate、datasets、bitsandbytes。这些依赖的版本兼容性问题非常常见我的建议是直接用LLaMA Factory这类集成工具它会帮你把依赖版本锁好避免自己搭环境时花掉一整天在装库上。数据准备是微调里最花时间的环节。网上流传着很多从txt文档生成训练集的脚本思路都是把文本按段落切分成问答对一种是用规则写提问-回答对另一种是让大模型阅读文档后自动生成问题和答案。我在实操中更推荐后者效果更好。生成出来的数据格式一般是JSON或JSONL每条包含instruction指令、input输入、output输出三个字段。这里我要多说一句训练数据的数量不是最重要的内容质量才是。网上很多教程让你准备一两万条数据但如果你只有500条高质量、和业务高度相关的样本效果可能比两万条从百科扒来的泛泛数据还好。我在一个金融文本要素抽取项目里用1200条人工清洗过的样本做LoRA微调抽取准确率比用8000条自动生成的数据高了将近10个百分点。所以把时间花在数据清洗上永远不亏。4.3 用LLaMA Factory完成训练、合并与部署训练工具上我推荐LLaMA Factory。它把数据加载、参数配置、训练、预测、导出都封装好了有命令行也有Web界面对新手非常友好。以LoRA微调Qwen2.5-7B为例关键训练参数可以这样起步LoRA秩r16、alpha32、dropout0.05学习率2e-4batch_size按显存调整epoch一般2~3轮。不建议一下把epoch拉太高容易过拟合导致模型只会背答案、不会泛化。训练过程中的监控也很重要。我通常会盯着loss曲线看如果loss在稳步下降最后趋于平缓说明训练正常如果loss突然飙升大概率是学习率太大或者数据里有脏样本。训练完成后LoRA权重需要合并回基础模型。LLaMA Factory里有导出Export功能合并后得到一个完整的模型权重目录。如果要部署到本地的Ollama或llama.cpp里跑推理还需要把模型转换成GGUF格式。这一步在转换的时候注意量化参数消费级机器推荐Q4_K_M或Q5_K_M兼顾速度和效果如果显存足够直接用fp16或bf16跑也行。部署完成后我建议做一个效果对比把微调前后的模型在同样的测试集上各跑一遍对比输出风格、知识准确率和格式符合度。我见过不少项目微调之后模型在某些测试题上感觉变聪明了但一换题目就露馅这种情况通常要考虑是不是测试集和训练集长得太像。真要评估得准备一份训练时没见过的评估集。4.4 微调实验中的关键参数参考参数LoRA推荐值QLoRA推荐值说明r秩1616秩越高可学习的容量越大但并非越大越好alpha3232缩放系数一般取r的2倍learning_rate2e-42e-4QLoRA可略高但超过5e-4易发散epochs2~32~3过多会过拟合batch_size按显存调整通常1~2 gradient_accumulation同时影响显存占用和训练稳定性这些参数不是我拍脑袋写的是社区里大量实践验证过的起点值。实际调试时先从这套起跑再根据loss曲线和验证集表现做微调比从零摸索快得多。5. 三者联动后的工程落地与一条完整的技术学习路线5.1 一个把RAG、Agent、微调组合起来的真实业务场景讲完三项技术很多人还是会问它们到底怎么配合我举一个我在电商客服项目里实际做过的架构你就明白了。先把客服语料和商品文档做数据清洗、分块、向量化存进向量库这是RAG层再收集几千条历史客服问答对用LoRA微调Qwen2.5-7B让模型学会规范的客服话术和礼貌语气这是微调层最后在Agent层给模型配上订单查询、退款处理、物流跟踪、优惠券发放这几个工具函数让它在处理用户请求时先查知识库相关资料再根据用户意图调用对应接口。整个流程下来就是一个微调的领域模型RAG知识库Agent工具调度的闭环。这个架构里三者的分工非常清晰微调定调子RAG补知识Agent干活。任何一个环节单独拿出来都能做成一个Demo但只有组合在一起才是一个能应对真实业务流量的系统。我在这个项目里最深的感受是技术选型不是越高级越好而是让每个环节都做它最擅长的事这样整个系统才稳定。5.2 学习顺序建议先RAG再Agent最后微调根据我自己带人学习和带项目的经验我给出一个明确的学习顺序。第一优先学RAG原因最单纯入门门槛最低工具链成熟一两天就能跑通一个知识库问答Demo能最快建立对大模型应用开发的整体手感。第二学Agent它需要有一点开发能力但也是当前招聘需求量增长最快的方向重点掌握Tool Calling的原理、Agent循环的调试方法以及一个主流框架。第三才学微调因为它对硬件、数据、训练知识的要求都最高如果前面两样都没吃透直接上来调模型很容易被各种细节劝退。之前网上有人问AI大模型运维大专生能学会吗我的回答是方向没错但要有心理准备。学习曲线确实陡Linux命令、Python、Docker、数据库这些基础任何一块薄弱都会在第二到第三个月卡住。但反过来讲这个方向拼的不是学历而是动手能力。一个能独立跑通RAG加Agent加微调全流程的人在就业市场上是很有竞争力的尤其是有实际项目经验做背书的时候。5.3 避开这几个常见误区最后整理几个我反复见到的误区。第一不要一上来就微调。能用RAG解决的知识问题就先用RAG能省下大量训练成本和维护成本。第二不要盲目追大模型。7B级别的开源模型在大多数垂直场景里已经够用部署成本却比几百B的模型低一个数量级选模型不是选最大的而是选刚好够用的。第三不要忽视数据质量。微调效果的上限由数据决定模型只是把数据里隐含的模式固化下来用错误百出的数据调出来的模型只能稳定地输出错误答案。第四不要以为Agent框架能解决一切。框架只是帮你管理状态和流程模型本身的推理能力和工具设计的合理性才是Agent系统能不能稳定跑起来的关键。最后说说我自己跑通这条路时的体感聊到最后我的真实体会是大模型应用开发这个方向看十篇教程都不如自己跑通一个端到端的项目。我第一次跑通RAG的时候光是在数据清洗和分块上就折腾了两天第一次让Agent稳定地完成一个多工具任务改循环终止条件就改了四五次第一次微调出来的模型效果还不如基线排查半天发现是数据里有几百条重复样本。这些都是教程里不会写但只有亲手做才能真正理解的细节。如果看完这篇文章你想立刻动手我给你一个最实惠的起步路径拿几十篇自己的文档搭一个RAG问答再用LLaMA Factory微调一个7B小模型最后让模型学会调用你的计算器或数据库接口。把这三件事各跑一遍你对RAG、Agent和微调的理解会比刷十篇名词科普有用得多。这条路走下去你踩过的每一个坑都会变成别人眼中这个人是真干过的底气。