不懂就问RAG到底是不是RAG最近圈子里聊大模型翻来覆去绕不开三个词RAG、Agent、多模态。但说实话我在一线把项目从零拉到上线发现一个挺有意思的现象——很多人对这三个词的理解停留在PPT层面。有人觉得RAG就是“给模型挂个知识库”有人觉得Agent就是“调API的自动化脚本”还有人觉得多模态就是“能看图能说话”。这些说法对不对方向对但太糙了。真正的工程落地是另一套逻辑。我手头刚做完一个综合类项目正好把这三块全揉进去了。这个项目本身不复杂就是把企业内部一堆散落的文档、图片、表格变成一个能对话、能分析、能自动完成任务的系统。做的时候踩了不少坑也把RAG、Agent、多模态这些东西从理论到代码彻底过了一遍。这篇文章不写PPT就写我怎么拆的怎么搭的以及哪些环节最容易翻车。如果你是刚接触大模型应用开发的同学或者被这三块概念绕晕了的从业者这篇文章应该能帮你把思路理清楚。哪怕你暂时不写代码理解这几个技术背后的设计思路对你选型、排期、跟开发沟通都会有帮助。1. 三大技术到底在解决什么问题先说一个总基调这点要是没想清楚后面全是糊涂账。2023年之前大家聊大模型焦点是“模型本身”。一个模型有多强看它参数多大、训练数据多广、推理能力多好。但到了2024年之后风向变了大家更关心的是“模型能用起来做什么”。于是围绕“用起来”这件事长出了三棵技术树RAG、Agent、多模态。它们分别解决了三个完全不同的痛点这三句话建议刻进脑子里技术核心痛点通俗理解RAG模型的“记忆”不足开卷考试先查资料再作答Agent模型的“行动”不足有个助理想办法、用工具、跑流程多模态模型的“感官”不足看得见图像、听得懂音频、读得了表格这三者不是竞争关系而是互补关系。RAG解决的是“知识从哪来”Agent解决的是“事情怎么做”多模态解决的是“数据长什么样”。打个比方你要做一个企业智能助手。RAG相当于给它配了一个公司内部图书馆员工提问时它先翻书再回答。Agent相当于给它配了一个执行团队你说“帮我整理这个季度的销售报告”它自己去翻报表、找模板、调图表工具、生成文档。多模态相当于给它配了眼睛和耳朵你丢给它一张截图、一个PDF扫描件、一段会议录音它都能理解并提取信息。这三样东西单独拎出来都能写一篇论文但真正干活的时候它们必须协同工作。1.1 为什么不是微调这里必须回答一个很多人会问的问题做知识增强为什么不直接微调模型我理解大家的直觉——模型不知道公司内部规范那就拿公司内部数据去训练它这逻辑听着很通。但实际工程里微调的问题很明显成本高、周期长、更新难。微调一次模型你得准备训练数据、算力资源跑一轮训练可能以周为单位计算。而且模型内部的知识是“固化”的公司制度改了、产品参数变了你得重新训练。RAG的做法就聪明得多模型本身不动知识文档放在外部知识库里用户提问时系统先把相关问题检索出来连同问题一起丢给模型让它“看着资料回答”。文档更新是即时的今天改完明天就能生效成本低到可以忽略这就是它成为主流方案的根本原因。当然RAG也不是银弹。如果某个领域需要模型本身的推理模式发生变化比如让它改变回答风格、学会特定的计算规则那还是得考虑微调。但90%的知识型场景RAG先一步够用了。1.2 Agent和多模态的关系这个点容易被忽视。很多人以为Agent就是纯文本的“智能体”多模态就是另一条线上的事。其实二者结合才有爆发力。一个Agent如果只能处理文字那它就是个“纯文职”。但它如果能看图表、能听录音、能读扫描件那它就是“全能助理”。我做的这个项目里就遇到了典型场景用户上传一张模糊的照片上面有某个设备型号Agent需要识别出型号、查知识库里的维护手册、调出对应参数、然后生成一份处理方案。这一连串动作没有多模态能力做感知、没有RAG做知识支撑、没有Agent做任务编排任何一个环节缺了都玩不转。所以别把这三个技术当成三门课来学它们是一个整体工程的三个支撑点。2. RAG核心逻辑与实操拆解RAG全称是Retrieval-Augmented Generation检索增强生成。名字听着学术原理其实特别简单让模型在回答问题之前先从一个外部资料库里检索相关内容然后拿着这些内容作为参考来生成答案。我常用的比喻是开卷考试。传统模型是闭卷它只能靠训练时学到的知识答题不知道的就是不知道。RAG是开卷考试时先翻书找到跟题目相关的段落再组织语言作答。事实性错误少、回答有依据、知识可以随时更新这三点已经把闭卷秒得体无完肤。2.1 知识拆解从文档到向量RAG的第一步是把原始文档处理成计算机能理解的形式。这一步在工程上叫“知识库构建”核心操作是从文档里提取文本片段然后把片段做向量化。具体流程我直接拆开说收集文档Word、PDF、网页、Markdown、TXT凡是公司需要的知识源都统一收进来。文档清洗去掉页眉页脚、图片水印、冗余的空格和换行这个环节看着不起眼但脏数据对后续检索质量影响极大。文本切分长文档不能直接整个丢进去模型处理不了那么长的检索单元需要切成小块。切分策略是门手艺活后面细说。向量化Embedding把每一小块文本用Embedding模型转成一串数字列表。这串数字就是文本的“语义坐标”语义相近的文本向量距离就近。构建索引把所有向量存进向量数据库建立索引供后续的相似度检索使用。这里面最考验经验的是第3步——切分。切片太大检索精度下降返回的内容太宽泛切片太小上下文信息不完整模型难以理解整体语义。我落地时的经验是优先按文档本身的段落结构切分段落太长再按句子边界二次拆分。同时每条切片要保留元数据比如来源文档名、章节标题、页码将来给模型做引用标注时用得上。具体参数上我常用的切片大小在200到500字左右重叠区间20到50字。提示重叠区间很重要。如果两段文本刚好在一个关键句中间被切断重叠能保证关键信息不会丢失检索时两段都能命中。2.2 检索链路怎么找得准知识库建好了查询链路就成了关键。用户提问后系统要做的事非常清晰把用户的自然语言问题转成向量去向量数据库里做相似度搜索找出最相关的几个文本切片把这些切片内容拼接成上下文。这个过程看起来简单但藏着好几个容易踩的坑。第一个坑是“问题与答案的表述不一致”。用户问“工伤报销额度上限是多少”文档里写的是“员工医疗费用报销比例”字面上完全不像但语义很接近。这是Embedding模型的语义理解本事但如果Embedding模型的选型跟不上——用了个老版本——可能就搜不到或者搜出来一堆不相关的内容。选Embedding模型的时候别光看榜单分数要拿自己行业领域的文档实测。第二个坑是混合检索。纯向量检索会遇到一个问题精确匹配被忽略。比如用户查“A3-210型传感器”如果文档里写的是“A3-210”向量检索可能因为编码差异而“找不到”。所以我现在做项目基本都上混合检索向量检索管语义相似BM25关键词检索管精确匹配两者结果做加权融合。RAG之所以叫“检索增强”这个融合机制就是工程上的灵魂。第三个坑是重排序。第一次检索可能返回20条结果但这20条里可能只有3条是真正有用的得有个环节把“最有用的”排到最前面。这环节叫Rerank。轻量级做法可以用交叉编码器跑一次精细打分把分数高的几条作为最终投喂给模型的上下文。加了这一步之后回答准确率提升非常明显强烈建议别省。2.3 生成环节与引用可溯资料检索回来了最后一棒交给大模型做生成。这里有个细节很多人忽略—上下文窗口。你把检索出来的Top5切片全丢给模型但如果切片很长加上用户问题总量超出了模型上下文窗口那就得做截断或摘要否则直接报错。实操里我通常的做法是先设定一个“可投喂的上下文预算”比如4096个token检索结果从高到低往里灌灌不下的就舍弃。这个预算要根据模型的具体规格来定不能拍脑袋。还要注意引用标注。企业场景里用户问一个制度问题AI回答完不能没凭没据。所以我在检索切片里保留了文档ID、标题、页码这些元数据让模型在生成回答时把引用信息也带出来用户点击引用就能看到原始出处。这不仅是体验问题更是信任问题。没有引用的企业知识问答回答得再漂亮内部员工也不敢信。我做的方案里RAG部分的效果是通过命中率和准确率两个维度评估的。命中率看“应该命中的文档有没有被检索出来”准确率看“检索结果排前面的文档是不是真的相关”。这两个指标建议做RAG的人持续跟踪它比看几个演示案例要有说服力得多。3. Agent编排任务与工具调用的核心场景Agent这个说法在圈子里被用滥了。有的产品就是个聊天框加个知识库非要叫Agent有些自动化脚本套了层LLM也自称Agent。真做落地的时候得把边界划清楚Agent的核心不是“能聊天”而是“能做事”。什么叫能做事你给它一个目标它能自己拆解成步骤、选择工具、执行动作、根据结果调整下一步直到目标完成。这里面最关键的三个能力规划能力、工具调用能力、记忆与反思能力。我项目里有一个具体场景最能说明问题内部员工要做一个“竞品信息整理”的任务。老办法是人工去搜、去抄、去汇总Agent做这件事时过程是这样的理解任务目标收集指定竞品最近三个月的产品动态。拆分步骤先确定关键词再逐个搜索收集结果后去重、整理、生成对比表。调用工具搜索API、网页抓取工具、读取内容并结构化。汇总输出用模板生成一份报告。自查完善对比目标看看哪部分信息缺失补充二次搜索。这一连串动作没有一个人工写死的流程图全靠Agent自己规划。它解决的核心问题是“把灵活的、不确定的、多步骤的任务自动化”。3.1 Agent的两种主流设计模式做Agent工程落地绕不开两种设计模式理解它们对后续排期和选型特别关键。一种是单Agent模式。所有规划、工具调用、记忆管理都在一个Agent内部完成适合任务和目标相对单一的场景。优点是链路简单、开发调试容易缺点是任务复杂后Agent的推理负担重指令一多容易“精神分裂”。另一种是多Agent模式。多个Agent各管一段比如一个负责需求理解一个负责检索信息一个负责生成内容再有一个总控Agent做协调和汇总。适合复杂的端到端任务但工程复杂度翻倍——Agent之间的通信协议、状态同步、异常处理都得考虑。我在项目里并没有追求高大上的多Agent架构而是用一个“规划器执行器”的轻量双层结构。规划器Agent负责把任务拆成子步骤执行器Agent负责执行具体动作。子步骤少的时候一个Agent跑完子步骤复杂时规划器动态调度多个执行器协作。这种设计的好处是代码量可控、逻辑清晰、出现问题能靠日志快速定位。对多数中小规模项目来说这比一上来就铺一个“Agent联邦”靠谱得多。心得不要为了Agent而Agent。任务如果能用传统脚本固定流程解决就用脚本。Agent的优势在于处理“流程不确定、输入不确定、结果需要动态调整”的任务。硬把确定性流程套上Agent只会增加故障点和成本。3.2 提示词即逻辑Agent调优核心Agent的表现很大程度上不是靠改代码而是靠改提示词。我给Agent写提示词的时候最重视两点格式约束和边界约束。格式约束是指让模型的输出严格遵循一个固定结构。比如要求它返回JSON字段固定为“步骤编号”“动作类型”“参数”“描述”。这样程序才能稳定解析Agent的“思维过程”否则模型自由发挥写出来的下一步动作程序读不懂。边界约束是划定Agent的权利边界。比如“你只能执行查询操作不能执行删除操作”、“遇到需要人工确认的操作必须停下来等待批准”。这一步在真实业务里是保命用的。Agent的自主性越强就越需要边界约束否则它在执行中自己决定做了一件超出权限的事后果不堪设想。调优过程中我积累的经验是把提示词当成代码来管理每个版本的提示词记录改动点、测试效果。很多团队在RAG和Agent上调优靠“玄学”改了又测、测了又改最后不知道哪个词起了作用。如果每次变更都做了版本记录调优效率会明显提升。3.3 工具调用Agent的手和脚Agent要执行任务必须能操作外部工具。这就是Function Calling机制。模型根据用户意图输出一个结构化的工具调用请求程序解析确认后执行对应函数再把结果回传给模型。对开发者来说做工具调用有三种路线我根据不同项目分别用过路线原理适用情况JSON模式模型直接输出一个JSON描述要调用哪个函数、传什么参数灵活度高适合自定义工具预定义函数声明在请求里传入函数定义列表模型自动选择适合标准场景可控性好代码解释器让模型生成代码并执行适合计算、数据处理类需求给我最大的教训是工具调用环节不要追求“一步到位”。把大任务拆成一个个小工具每个工具只做一件事做好一件事。比如“搜信息的工具”和“解析网页的工具”分开“生成图表的工具”和“格式化文档的工具”分开。工具粒度越小Agent调度越灵活出错时也越好排查。4. 多模态从看懂到动手多模态技术要解决的问题很直接——让模型“像人一样”感知和理解不同类型的信息。文字、图像、音频、视频、表格、扫描件每种形态都有各自的复杂性。多模态模型的核心就是把不同模态的信息对齐到同一个语义空间里模型既能理解文字描述对应的图像是什么样也能理解图像里包含的文字信息是什么意思。我用一个实际场景说明某项目需要处理一批设备维修记录其中既有手写的维修单扫描件也有设备故障照片还有维修前后的对比文字记录。老路子是人工分拣录入多模态模型做这件事它能直接识别扫描件里的手写文字能看懂故障照片里设备哪个部位异常能把图像中的信息和文字记录做对应关联然后整体输出一份结构化维修档案。这就是多模态在真实场景里的价值。4.1 输入侧识别与理解多模态模型的输入处理是整个链路最基础也最容易出问题的环节。首先是文档解析。PDF扫描件、翻拍的照片、带水印的截图这类数据直接送给模型效果通常不理想要先做预处理。我踩过的坑是有些PDF看着正常页面是扫描图片根本没有文本层。如果直接把整份PDF喂给模型文字提取为零。处理方法是加一个OCR环节先用识别模型把图片里的文字“抠”出来再进入后续流程。这其中的工程细节还有不少讲究。比如倾斜矫正拍照扫出来的文档经常是歪的不做矫正文字识别的准确率会明显下降图像增强对低对比度、阴影遮挡的图片尤其重要先用增强算法把文字区域突出还有分栏处理学术论文、报纸这类双栏排版文档不处理的话OCR结果会串行左右两栏的文字交织在一起。我见过不少新手在这上面栽跟头做出来的文字提取结果颠三倒四后面所有步骤全被带偏。其次是表格结构化识别。大模型处理表格光靠OCR识别文字远远不够还得把文字重新组织成行列关系这个过程叫“表格结构识别”。我做了个实验印象很深刻同样一张带合并单元格的复杂表格纯OCR提取的文字是乱的但加了表格结构识别之后模型直接输出一个干净的Markdown表格内容和原表结构严丝合缝。4.2 输出侧生成与理解多模态模型的输出能力是这两年技术迭代最明显的部分。过去的模型只能给图片写文字描述现在的模型已经能做到“看图作答”甚至“按图生成图文并茂的内容”。举一个我实际调过的例子把一张产品的宣传海报图给模型要求它“总结海报设计的核心卖点并生成三句适合发朋友圈的宣传文案”。模型不仅准确识别了海报里的产品名称、优惠价格还能说清楚海报的视觉风格最后生成的文案也贴合海报调性。这种输出侧的能力在营销素材生产、内容创作辅助场景里非常实用极大减少了从素材到成品之间的繁琐人工环节。输出侧还有一个被低估的能力是“视觉问答之外的推理”。比如给模型一张布局复杂的仪表盘截图问它“哪一个模块的数据与上个月相比呈下降趋势”模型需要先定位图表、再理解图例、再基于图像里的数据趋势做分析判断。这个调用链比单纯问“图片里有什么”复杂得多也是衡量多模态模型真实水平的试金石。4.3 多模态与文档管线的工程整合多模态单独拿出来做演示效果总是震撼的但放到工程管线里就要考虑成本和性能的平衡。多模态模型的调用价格比纯文本模型高出一个量级所以我的策略是“能轻则轻”。图片、PDF这类文件进来先做一个分类鉴别判断里面有没有需要复杂理解的元素。如果只是纯文本页走成本较低的OCR加文本模型通道只有遇到复杂图表、手写体、多栏混排这类高难度内容才调用多模态大模型。另一个工程要点是缓存。同一份文档被多个部门、多个场景频繁查询如果每次都重新过一遍识别流程成本浪费很严重。我把识别后的结构化结果按文档ID缓存起来第二次访问直接读缓存。这个优化在实际运行中帮我省掉了大量重复的算力消耗响应速度也从秒级降到毫秒级体感非常明显。5. 三大技术如何组合一个完整案例复盘单点技术讲完回到我最开始说的那个项目。这部分把我实际做过的完整案例做一个复盘帮大家把三大技术怎么协同落地看清楚。这个模拟项目的背景是某公司需要一个内部智能问答与文档处理系统。员工可以提问公司制度、查项目资料也可以上传文件要求做摘要、提取信息、生成报告。先明确项目目标然后组合三大技术RAG做知识问答的底座Agent做多步任务的编排多模态处理非文本类的输入。5.1 整体架构设计系统架构从顶层往下分四层每一层对应一项明确的职责第一层是用户接入层包含聊天界面和文件上传入口对话框里既能聊文本也能拖入图片、PDF、语音。 第二层是任务编排层这是Agent的所在位置。它负责区分任务类型文本问答任务直接走RAG链路文档处理任务则先调用多模态识别再进入信息提取复杂分析任务则拆成多步骤流程。 第三层是能力层三大技术的能力封装成标准化服务检索服务、问答服务、识别服务、报告生成服务每个服务都可以被上层独立调用。 第四层是数据层存向量索引、原始文档、识别缓存、操作日志提供统一的数据访问。这个架构一点也不复杂但每层之间的接口定义花了我不少心思。我坚持的原则是层与层之间走标准化的“指令输入—结果返回”模式这样任意一层替换技术方案其他层不需要大改。后来RAG从旧的向量数据库迁移到新的方案数据层接口没变整条链路没怎么受影响这种解耦带来的好处是立竿见影的。5.2 用户问题流转全流程用一个具体用户提问来看整条链路的流转问题很典型“请帮我分析这张产品故障图片并查找相近型号的维修手册给出排查建议。”这个问题单靠任何一项技术都答不好但三大技术协同就顺了第一步用户上传故障图片多模态服务启动识别出产品型号和设备状态。识别结果是结构化的信息比如型号A3-210、故障部位指示灯不亮。第二步Agent读取到型号信息后发起RAG检索从维修手册知识库里找出A3-210相近型号的维修章节、常见故障排查流程。第三步Agent把多模态识别结果和RAG检索结果做整合汇总成一份排查建议报告返回给用户报告里还带上引用来源方便用户打开原始手册核实。从用户体验来看这就是一句话的事情但背后的三大技术协同环环相扣缺一不可。这个例子也说明不谈协同、孤立理解三大技术是没法真正应对真实业务场景的。5.3 编排层的决策逻辑编排层是整套系统的大脑它的决策逻辑直接决定了系统会不会“答非所问”或者“答得非常笨”。我实现的时候编排层内部维护一个意图识别模块送入用户的问题和文件后这个模块根据内容走不同的分支。分支规则并不复杂纯文本且含具体实体名词走RAG检索问答文本较长且要求做摘要走摘要生成含图片或PDF先走多模态识别提取多步骤任务进入Agent编排。实际使用中分支规则足以覆盖大多数场景而更细的调度则需要在Agent的提示词里明确——一个关键技巧是给Agent一段完整的“工作说明”告诉它遇到什么情况调用哪个服务、服务返回结果后怎么判断是否继续或是结束。这套编排逻辑我一开始写得很复杂想用规则引擎做完整覆盖后来发现过度设计维护成本远超收益。后来改成“意图分类模型做粗粒度判断规则做细粒度兜底”系统反而稳定了这也算我在这个项目里最深的一个感悟。6. 落地过程中的踩坑与排错经验这一节是干活的部分。说实话理论网上到处都有真把三大技术落地到项目里坑一个接一个。我把印象最深的几个问题整理出来给大家提个醒。6.1 向量检索“答非所问”的排查遇到过最头疼的问题知识库里有答案模型也能答出这个答案但检索环节就是搜不到正确的内容。找了一圈发现原因有两个。一是Embedding模型对专业术语识别差。品牌名、型号名、内部缩写这些词汇在通用Embedding模型里并没有被很好地区分相近型号的向量距离过近检索时频繁混淆。解决办法是换行业微调过的Embedding模型或者干脆加关键词权重。二是切片不合理。长文档里一个核心知识点被切开分到了两条切片里任何一条单独拿出来都和问题对不上。调整切分策略按语义段落切分并增加重叠区问题就解决了。排查思路其实很清晰先看检索的结果列表检索出的是不是相关内容。如果列表不相关问题在Embedding和切分如果列表相关但回答还是错的问题在生成环节的提示词和上下文组织。两头拆别在中间瞎调参数。6.2 Agent循环失控与工具误调Agent跑着跑着开始疯狂循环这是一个特别经典的坑。症状是它在同一个步骤上来回执行或者不断调用同一个工具始终不推进下一步。我见过最离谱的一次Agent要搜索一个关键词结果它把“搜索结果为空”也当成了一次成功执行然后又发起了一模一样的搜索无限循环直到触发我设置的调用次数上限才停下来。那次之后我做了一个重要改进——给Agent的所有工具调用加“最大重试次数”和“终止条件”两个硬约束。解决循环问题还有一个实战技巧日志中记录每次工具调用的输入和输出一个循环能造成的资源浪费非常惊人——每调用一次服务都是钱都是时间。所以排查时看日志基本一眼就能看出循环模式。后来我给Agent增加了状态记录每次进入新步骤时都要求它更新状态如果状态没有变化而动作却在重复就直接终止。6.3 多模态识别结果不准多模态识别不准是用户感知最强的问题。识别出错后续的RAG检索和Agent编排全部受影响差错会被逐级放大。排查下来发现问题绝大多数不在模型本身而在预处理环节。有一类情况是图片质量差——亮度低、遮挡多、角度偏另一类情况是文档排版复杂比如表格合并单元格、目录配图、扫描件阴影。处理方案也很直观图片先做质量增强、倾斜矫正、方向校正再送入模型扫描件先做OCR预处理再按文本块重组复杂表格加表格结构识别模型而不是让大模型硬看图片。这里有一条实践出的判断标准只要多模态识别结果和你肉眼看到的内容有明显出入先怀疑预处理环节不要急于换模型。绝大多数识别质量问题的真凶都在上游。6.4 成本失控与性能优化大模型应用落地成本是绕不开的话题。纯做技术Demo不会太在意成本但正式上线每一分钱都要算清楚。我总结的成本控制三板斧第一尽量用轻量模型。不是所有任务都需要大模型意图分类、实体提取、信息规整这类任务用一个小模型足够没必要每次都调大模型。第二做好缓存。同一个问题问十次如果不需要追求最新数据直接读缓存回答成本为零。第三控制上下文长度。投喂给大模型的上下文越长成本越高我加了一个上下文压缩模块检索到的长文本先压缩成精华摘要再喂给模型。三层叠加整体成本比最初方案下降了将近一半回答质量几乎没有下降。7. 选型经验与未来扩展三大技术落地选型才是决定后续研发效率的隐藏变量。这块我给出一些实用经验供大家参考。模型选型上生成模型选主流高性价比系列。RAG场景单轮问答用中小参数模型即可长上下文需求再说。Agent场景尽量选有原生Function Calling支持的模型这个能力是否原生直接影响开发效率和稳定性。Embedding模型一定拿行业文档实测对比不同模型的检索命中率。向量数据库选择优先看三件事是否支持混合检索是否有完善的过滤机制是否有方便的扩展能力。数据量小的项目用轻量方案即可数据量大再上分布式架构。多模态模型按场景做取舍需要OCR和表格识别的选专业识别方案需要复杂推理的选旗舰多模态模型。另外强烈建议把RAG切分模块、Agent编排模板、多模态预处理流程做成内部通用组件沉淀成工具库。这样后续接新项目时三天就能搭出原型不用从零再来。关于未来扩展有几个方向值得关注。RAG方面融合知识图谱做结构化推理、动态更新知识源是重点方向。Agent方面更强的长程规划能力和多Agent协作框架还在快速演进。多模态方面视频理解、实时语音交互、跨模态生成是明显的趋势。三大技术的边界会越来越模糊最后走向同一件事——让机器更像一个能听、能看、能想、能做的智能体这个趋势已经很清晰了。我把这些坑和经验写下来是希望后来者少走弯路。做RAG别光学检索做Agent别只写提示词做多模态别只跑Demo——把三者串成一条完整的产品链路你才真正知道大模型应用的水有多深、风景有多好。