陆陆续续有不少学员和同行问我：学完大模型的基础概念之后，下一步到底该学什么？我的答案很直接——去看那些真正在做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的完整流程与各环节定位
RAG（Retrieval-Augmented Generation，检索增强生成）这个名字听起来很高深，但它背后的思路其实很朴素：让模型在回答问题之前，先去一个知识库里检索相关内容，再把检索到的内容拼进提示词，最后生成答案。整个过程可以拆成几个环节：文档导入、文本清洗、分块（chunking）、向量化（Embedding）、向量存储、查询检索、重排序（Rerank）、上下文注入、模型生成。
我见过很多初学的朋友把RAG等同于"向量数据库加一个大模型API"，这是一个典型的简化认知。向量数据库只是存储和检索的工具，真正的效果差距往往出在导入之后的分块、检索之后的重排序上。整条链路里，任何一个环节做得粗糙，最终回答质量都会大打折扣。所以做RAG项目，别急着调大模型的prompt，先把前置链路打磨好。
在真实项目里，还有一个被很多人忽略的环节：文档格式解析。我做过一个电网行业的项目，原始资料全是PDF扫描件和Word排版混乱的文档，不做解析直接去分块，结果向量库里全是乱码和页眉。后来不得不先接OCR服务做文字识别，再按段落结构重新组织。这一步听起来枯燥，但对最终效果影响极大。
2.2 分块策略：直接决定检索命中率
先讲分块。文档导入后，你不能直接整篇扔给模型——一方面上下文窗口有限，另一方面大段文本向量化之后，相似度检索的精度会下降。所以要把文档拆成一个个小块（chunk）。分块大小是有讲究的，块太大，检索到的内容里无关信息太多，稀释了关键答案；块太小，一个完整语义被切开，检索时容易漏掉核心信息。
我这里用一组实验数据来说明：同样一套技术文档，chunk_size=200的时候，检索命中率（hit rate）大概在62%左右；调到500，hit rate能到75%；再调到1000，反而回落到68%。原因就是块太大之后，召回的相关片段里混进了大量噪声，导致最终注入上下文的有效信息密度下降。所以"越大越好"或"越小越好"都是错的，要在具体数据集上做实验。
我在项目中常用的做法是：针对技术文档和制度文档，chunk_size选400~700个token，overlap（重叠）设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秩（r=16）、alpha=32、dropout=0.05；学习率2e-4，batch_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（秩） | 16 | 16 | 秩越高，可学习的容量越大，但并非越大越好 |
| alpha | 32 | 32 | 缩放系数，一般取r的2倍 |
| learning_rate | 2e-4 | 2e-4 | QLoRA可略高，但超过5e-4易发散 |
| epochs | 2~3 | 2~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和微调的理解，会比刷十篇名词科普有用得多。这条路走下去，你踩过的每一个坑，都会变成别人眼中"这个人是真干过"的底气。
