RAG、Agent与模型优化：大模型落地应用的三条核心技术路线

一个成熟的模型应用往往不是靠一个动作成交的。大部分团队一开始都会被“模型什么都会”这句话带偏等真上线才发现同一个模型放到不同场景里表现可以千差万别。问内部文档它可能答得像模像样却全是编的让它在系统里自动查单、下单它又经常“手滑”真到了算成本的时候调用量一大按Token计费的账单能让你怀疑人生。“查资料”“会做事”“省成本”这三件事在大模型工程里其实是三条不同的技术线。“查资料”靠的是检索增强生成也就是RAG本质是给模型接上外部知识库“会做事”靠的是函数调用和Agent编排让模型把手伸进业务系统里操作“省成本”靠的是量化、蒸馏和开源模型本地部署把推理资源压到最低。这篇文章我会把三条线各自靠什么原理、怎么落地、选型时注意什么一层层拆开讲最后给出一套可以直接抄作业的组合方案。1. 查资料RAG给模型装上的“外部硬盘”1.1 为什么模型自己“记不住”资料很多人第一次看到大模型能对答如流会下意识以为模型是一本百科全书。但模型记住的知识本质上是“参数化记忆”——训练过程中把海量文本压缩成了几十亿甚至上千亿个参数。你问它常识、方法、公开知识它确实能说得头头是道因为这类内容在训练语料里反复出现权重里已经刻进去了。但一旦进入实际业务场景问题就来了。第一训练语料有截止日期新政策、新产品、刚发布的制度它一概不知。第二也是更致命的公司内部的合同、规程、售后记录、项目复盘这些私域文档根本不会出现在任何公开训练集里模型自然连“见过”都谈不上。第三参数的容量是有限的它不可能把自己没见过的东西凭空记下来。那模型遇到没见过的信息会怎样它不会坦诚说“我不知道”而是会用它最擅长的方式处理——把看起来合理的词串出来。一个语言模型最擅长的就是预测下一个词所以它会一本正经地编一份看似合理的合同条款或者销售数据这就是我们常说的幻觉。所以私域知识类问题不能靠“问模型”必须给模型接一条检索链路让它先查资料、再回答。这正是RAG存在的理由把外部知识做成可检索的数据库在模型回答前先把相关资料捞出来塞进上下文里让它参考。1.2 RAG标准链路从文档到答案的八步我最早做RAG时以为就是把文档切成小段喂进向量库然后查一下拼进Prompt就行。真做起来才发现链路里有八个环节每一步出错都会让最终回答效果断崖式下跌。第一步文档解析。PDF、Word、HTML、扫描件都有各自的坑。PDF里如果带表格直接按纯文本抽出来经常是乱的扫描件需要OCR这一步识别不准后面全白搭。我现在的习惯是先按文档类型走不同解析器解析完做人工抽查不要一股脑入库。第二步清洗与结构化。去掉页眉页脚、目录、重复章节把标题层级保留下来。标题信息非常重要因为后面分块和召回都要用到结构信息比如“2024年第三季度销售数据”这个标题本身就是一个很好的检索字段。第三步分块Chunking。这一步决定了后续召回的下限。分块太大会混入无关内容向量表示会变得模糊分块太小又可能把完整的知识切碎导致语义断裂。我常用的策略是按标题层级切块把每个小标题下的段落作为一个Chunk长度控制在256到512个Token之间块与块之间保留10%到20%的重叠避免关键句被拦腰截断。第四步向量化。把每个文本块通过Embedding模型转成向量。中文场景我目前用得比较多的是bge-m3系列对中文长文本的语义理解比较稳也可以用来生成查询向量。如果对英文内容多可以换多语言模型。第五步向量入库。把向量写入向量数据库。选项很多从轻量的Chroma、pgvector到生产级的Milvus、Qdrant。小项目或者原型阶段pgvector就够用了运维负担小数据量上了几百万再考虑独立向量库。第六步召回。用户提问后把问题向量化到向量库做相似度搜索取回TopK个最相关的Chunk。这一步我用得比较多的是HNSW索引检索速度很快但也要记得设置合理的TopK范围太少会漏太多会噪声大。第七步重排Rerank。向量召回是初筛它只看语义相似度不够精确。我会先召回Top50再用一个Rerank模型精排筛出Top5到Top8作为最终上下文。这一步对效果提升非常明显千万别省。第八步注入与生成。把精排后的内容按固定模板拼进Prompt并明确告诉模型“只能依据参考内容回答不能凭空发挥”。生成模型再基于这些材料组织答案必要时要求它给出引用来源。1.3 决定效果上限的是“检索质量”不是回答问题那个模型许多团队会陷入一个误区回答得不好第一反应是换更大的模型。但RAG场景里回答质量的上限在检索端不在生成端。我做过一次对照实验同样用7B小模型做问答检索质量优化前后回答的准确率从大概六成直接提到九成以上。模型没换效果却天差地别问题就出在“该召回的内容没召回来”。检索质量主要取决于三件事。第一件分块是否合理。如果一份合同被按固定500字机械切块一条完整条款可能被切进两个Chunk召回了上半段丢了下半段模型自然答不完整。这时候把分块策略改成按条款边界切效果立竿见影。第二件元数据过滤有没有做。给每个Chunk打上来源、部门、时间、文档类型这些标签。比如用户问“2024年Q3销售报表”如果不过滤时间向量库很可能把2023年、2022年的相似内容一起召回干扰模型判断。加了时间过滤后召回准确率会非常明显地提升。第三件混合检索要不要上。向量检索擅长语义匹配但缺点是专有名词、产品编号、合同号这类关键词一旦出现向量召回很容易被带偏。比较稳的做法是“向量召回加BM25关键词召回再做结果融合”最后统一交给Rerank精排。这样既能命中同义表达又能精确匹配编号和术语。检索方式擅长场景弱点纯向量召回同义改写、语义相近专有名词/编号可能失准BM25关键词召回精确术语、编号匹配对同义表达无感知向量BM25融合重排两种场景都覆盖链路复杂耗时略高2. 会做事从聊天到调用工具的Agent链路2.1 Function Calling是怎么工作的RAG解决的是“模型知道什么”的问题但很多业务需求是“模型做点什么”。比如用户说“帮我查一下订单状态如果已发货就推送物流消息”这时候模型不能只输出一句“好的”它得真的去调订单查询接口、逐条判断、再调消息推送接口。模型自己当然不会直接调接口。它做的是“输出工具调用意图”——通过训练学会了在特定情况下生成一个结构化的JSON片段描述它想调用哪个函数、传什么参数。应用层拿到这个JSON后再真正执行对应的函数代码把执行结果返回给模型模型再基于结果继续生成回复。实际开发时函数定义的格式在应用侧写好作为工具描述传给模型。比如要做一个天气查询工具定义大致是{ type: function, function: { name: get_weather, description: 查询指定城市的当前天气和未来三天预报, parameters: { type: object, properties: { city: { type: string, description: 城市名称如北京、上海 } }, required: [city] } } }模型读完工具描述后如果判断当前问题需要查天气就会在回复中输出类似这样的内容而不是直接去执行{name: get_weather, arguments: {\city\:\北京\}}应用层解析这个输出调用真正的天气API再把“北京今天晴最高温度12度”这样的结果回填给模型。模型据此组织成最终的自然语言回答。为什么不干脆让模型自己写代码执行因为模型生成的代码不稳定直接执行等于把一个不可控程序放进生产环境安全和正确性都没法保证。而函数调用把“决策”和“执行”分离模型只负责判断调用哪个工具、传什么参数真正执行的是你在代码里反复测试过的函数。这个设计非常重要我建议所有做Agent应用的人都把这个边界守住。2.2 多步任务靠Agent循环一次函数调用只能完成一个动作但真实业务很少只有一步。用户说“帮我整理一下本周所有待办把今天该做的标出来并且给相关负责人发一封催办邮件”这就涉及查待办、分类、查人员、发邮件四个动作而且还有依赖关系。这种多步任务需要的是Agent循环。目前工业界最常用的是ReAct模式模型先思考然后决定执行什么动作执行完看到观察结果再继续思考循环往复直到任务完成。流程可以概括为思考Thought→ 动作Action→ 观察Observation→ 再思考。我举个例子。用户要求“查一下最近一周的主机CPU使用率如果超过80%请生成一份关注清单”。Agent会先调用“查询监控数据”工具拿到一堆指标数据发现有三台机器超过阈值于是调用“生成清单”工具把三台主机的信息整理成文档最后再调用“发送通知”工具推送给指定负责人。整个过程模型需要根据每一步的结果动态调整下一步动作而不是脚本提前写死的。但工程上绝对不能把Agent循环做成“无限循环”。我在实际项目里会强制做几层约束最大迭代轮数要设上限比如20轮每个工具调用要有超时时间工具白名单严格限定不允许模型调用业务之外的接口涉及发送消息、修改数据这类敏感操作要加人工确认节点。这些约束在演示时看着多余但生产环境里能避免90%的“Agent发疯”事故。2.3 本地模型做Agent选型和量化都要注意做Agent不一定要用云端大模型很多场景因为数据合规或成本原因需要本地模型来承担工具调用。但这里有个现实问题开源模型的工具调用能力参差不齐选型不对整个链路就崩了。我踩过的坑是拿一个早期版本的聊天模型硬套Function Calling结果它经常不按格式输出要么把参数名改了要么把JSON输出成Markdown代码块。应用层解析直接报错Agent循环里全是异常重试。后来我把开源模型筛了一遍稳定能跑工具调用的主要看几个系列Qwen2.5系列、GLM-4系列、Llama 3.1系列都对函数调用做了专门对齐格式规范。中文场景Qwen2.5-7B和GLM-4-9B都是性价比比较高的选择如果要求更强推理能力可以把Qwen2.5-14B甚至更大的模型拿来做本地推理。另一个坑是量化等级。做纯问答时Q4量化可能还能接受但做工具调用时量化等级过低会导致输出的JSON格式漂移。我的建议是凡是涉及工具调用和Agent链路的模型量化等级至少从Q5_K_M起步条件允许直接用Q8_0。别为了省那一点显存牺牲格式稳定性。后面章节我会详细讲量化和成本的关系。3. 省成本量化、蒸馏、本地部署三条路线3.1 成本花在哪推理端的账要会算模型应用的账大头在推理端不是训练端。很多团队一说降本就打算去重新训练一个模型这是误区。训练是一次性投入推理是每次调用都要付钱随着业务量上涨推理成本的滚雪球速度非常恐怖。推理成本到底高在哪三个方面。第一模型参数占用的存储和带宽参数越大每次前向传播的计算量越大。第二上下文越长KV Cache占的显存和带宽越多。第三并发请求越多需要的GPU资源就越多服务端的排队和延迟也会抬升成本。我经常用JVM内存模型来给团队做类比。JVM运行时不是只有堆内存还要区分栈、方法区、直接内存大模型推理时也不只是“把模型权重加载进显存”就完事还要算上KV Cache、临时激活值、调度缓冲。很多人想省钱只盯着模型权重大小结果上下文从4K调到32K以后显存莫名其妙就爆了就是因为KV Cache部分被忽略了。上下文越长KV Cache占据的显存几乎线性增长这个账必须提前算。3.2 量化把模型“压扁”再塞进小显存量化是目前最直接的省成本手段。它的原理很简单模型参数原本用FP1616位浮点数存储每个参数占2字节量化后改成INT8甚至INT4每个参数只占1字节或0.5字节。参数变小模型占用显存变小推理速度变快成本自然降下来。本地部署大模型目前最常用的是GGUF格式配合llama.cpp系列推理框架。GGUF支持多种量化等级不同等级在体积、速度、效果之间做取舍。以7B模型为例各量化等级的大致情况如下量化等级7B模型权重体积建议显存质量损失FP16约13GB16GB以上基线Q8_0约7.2GB10GB以上非常小Q5_K_M约5.2GB8GB以上可接受Q4_K_M约4.1GB6GB以上有一定损失Q2_K约2.8GB4GB以上明显我的经验是通用对话和内容生成场景Q5_K_M和Q4_K_M是比较划算的选择肉眼感受不到太大差别但涉及工具调用、代码生成、数学推理这类对格式和逻辑要求高的场景最好用Q8_0甚至原版FP16。量化省下来的成本可能最后要花在更多次重试和调试上。实际操作非常简单。本地装好Ollama之后拉取一个已经量化好的模型就行ollama pull qwen2.5:7b-instruct-q4_K_M模型下载完成之后直接通过兼容OpenAI的接口调用即可。这套流程把本地模型部署的门槛降到很低也是很多中小团队选它的原因。3.3 蒸馏小模型继承大模型的“作业”量化的思路是把大模型“压缩”蒸馏的思路则是“再造一个小模型并让它学大模型的本事”。知识蒸馏的做法是用大模型比如能力很强的商用闭源模型生成大量高质量的输入输出对然后拿这些数据去微调一个小尺寸开源模型。举个例子我想做一个客服意图分类模型。与其让我手写几百条规则不如让大模型按照我的分类体系生成一万条示例对话再把这些数据拿去微调一个7B模型。最终效果是这个7B模型在“客服意图分类”这个垂直任务上的准确率可能超过同等尺寸的通用模型而推理成本只有大模型的零头。但别神化蒸馏。小模型的结构决定了它的上限复杂推理、长链条规划、抽象归纳这些能力小模型再怎么学也追不上大模型。蒸馏更适合“把某个窄领域任务做到够用”不适合指望它全面替代超大模型。我通常会把蒸馏用在意图识别、信息抽取、格式改写这类单一、重复、规则相对稳定的任务上。3.4 本地部署免费模型不是零成本开源模型加本地部署看起来API费用直接归零很多老板一听就觉得“省钱了”。但真正算总账本地部署的成本结构完全不一样。硬件采购或租赁费用跑不掉。一个7B量化模型配合长上下文运行建议准备16GB以上显存或者直接上64GB内存靠CPU推理也行但性能会差很多14B级别32GB显存是相对宽裕的配置再往上跑70B级别就得组多卡或上大显存服务器了。其次是运维成本环境部署、模型升级、监控告警、故障恢复都得有人盯。最后是模型升级成本开源模型版本迭代很快每半年到一年可能就要重新评估、重新适配。那本地部署到底省在哪边际成本。API模式是按Token付费调用量越大费用越高。本地部署是一次性投入加电力成本上线后推理次数再高边际成本也几乎是零。所以我的判断是并发量高、调用频繁、数据敏感的项目适合本地部署调用量不稳定、需要快速实验的场景反而用API更灵活。4. 三件事合体一套可复用的落地架构4.1 分层架构参考只谈单项技术没有意义实际应用里RAG、Agent、模型优化三个能力要组合成一个完整系统。我在项目里通常分成四层来设计。数据层负责接入各种数据源包括企业内部文档、数据库、业务系统API、日志流。这一层要做大量脏活累活比如文档格式转换、接口鉴权、数据清洗但它是上层能力的基础。能力层封装各类模型能力包括Embedding模型、Rerank模型、主对话模型、工具执行器。RAG的检索链路和Agent的函数调用都挂在这一层对外提供统一接口上层不需要关心底层是本地模型还是API模型。调度层负责意图判断和任务编排。用户的请求进来先判断是走RAG问答还是需要调用工具或者两者结合。Agent循环、路由策略、安全校验也都在这层做。应用层是面对用户的入口可能是问答机器人、运维助手、客服工作台。这层只跟调度层交互保持轻量方便快速迭代。这个分层的好处是每一层都可以独立替换。想换一个更好的Embedding模型只改能力层想从API模型切到本地模型只改调度层配置。我在实际项目中经常只改一层就能明显提升整体效果。4.2 不同预算下的组合方案为了节约试错时间我把不同预算下的推荐组合整理成了一个表格方便直接对照参考。预算级别主模型选择检索方案工具能力适用场景低预算本地7B-14B量化模型bge-m3向量检索 BM25混合 Rerank仅限2-3个简单工具人工确认内部知识库问答数据不出内网中预算本地14B模型 按量调用云端大模型同上增加自动路由中等复杂度Agent需超时和重试客服辅助流程自动化初阶高预算私有化部署大参数模型集群大规模向量库全链路监控多工具并行、复杂任务规划金融、医疗等对安全和效果要求都很高的场景低预算方案是我最推荐的起步方式。先用本地小模型把整个链路跑通数据库、工具接口、前端交互都验证了再根据瓶颈决定要不要加预算。很多项目一上来就上云大模型花了大钱最后发现数据采集和工具对接才是真正卡住的地方。4.3 我建议的分工原则做组合方案时我有一条核心原则把三种能力拆开分配不要指望一个模型全干。“查资料”会更倾向于本地化。私域数据通常有合规要求不能随便出内网本地Embedding加本地量化模型既能保证数据安全又能保证检索质量。“会做事”会更重视稳定性工具调用链路一旦崩了会给业务造成实际损失所以宁可选用格式稳定、经过充分验证的模型也不要为了省钱选一个输出容易漂移的小模型。“省成本”则优先压推理端从量化、蒸馏、路由三个方向同时下手而不是动不动就重训模型。另外我强烈建议在系统里加一个简单的路由层。问题简单时用小模型处理问题是高难度推理时再调度大模型。我做过一个线上系统大概有60%到70%的请求是小模型能搞定的路由机制直接让总成本降了一半以上。这个优化点很多人一开始都意识不到。5. 常见问题与排查技巧实录5.1 回答被截断输出Token上限的坑实际运行里最常遇到的故障就是回答写到一半停住了或者接口直接报“已达到输出Token上限”。很多新手的第一个反应是加大模型参数但其实问题往往出在请求侧的max_tokens设置上。我处理过的一个案例一个长文档总结任务模型已经把内容组织好了但max_tokens只设了512结果输出到一半被切断而且切得很不是地方看起来就像模型“不会回答”。把max_tokens调到1024甚至2048之后问题立刻解决。但这里有个隐藏问题模型是会把“已有输出保留在对话中”的被截断后如果直接让模型“继续”它可能会重新组织语言而不是接着后半段写导致内容重叠。更稳的做法是把长文生成任务拆解成多段分段生成再拼接或者让模型先输出一个结构化大纲再逐段扩写。不要依赖“继续”这种补救手段。5.2 RAG召不回、召回不准怎么办RAG最常见的故障是“用户问题明明在文档里有模型却回答不知道”。我排查这个问题的顺序很固定先单独测试向量召回把TopK结果直接打印出来看相关度。如果TopK结果相关度就很低那问题大概率出在Embedding或者分块上。检查分块是不是把完整信息切碎了或者查询语句里的专业术语没有在向量语义层面和文档匹配上。这时候上混合检索加上BM25关键词召回通常能救回来。如果召回结果相关度很高但最终回答还是不对那问题在生成端。检查注入Prompt的模板是不是没有明确告诉模型“只能依据参考内容回答”或者召回的内容太多把关键信息淹没在噪声里。精排时把TopK从50缩到5到8往往有奇效。5.3 Agent死循环、工具调用格式错乱Agent应用跑一段时间最让人头疼的问题就是模型的循环退化。现象是同一个工具被反复调用参数也不变每一次观察结果都一样但模型就是停不下来。这种情况先在工程层做兜底最大迭代轮数、工具调用超时、结果去重判断。如果工具返回的结果跟上一次完全相同就直接打断循环让模型换策略。另一个常见原因是量化等级太低导致工具输出JSON格式漂移应用层解析失败后反复重试。遇到这种情况先用量化等级高一点的模型做对比测试如果马上恢复正常那就不是模型智商问题是量化把格式稳定性压坏了。5.4 量化后的模型“变笨”了量化确实会在某些能力上打折。我实测过同样一个14B模型Q4量化后在做简单问答时几乎感觉不到差别但在做代码生成和复杂推理时错误率会明显上升。因此不要一刀切选择最低量化等级。生产环境建议给不同任务配置不同量化等级路由层根据任务类型把请求分发到不同等级的模型实例上。低难度意图识别用Q4中等难度的问答和抽取用Q5涉及代码和工具调用的请求用Q8或原版。这套组合比单一量化等级更省成本也更稳。另一个建议是在本地建立一份20到50条的业务回归问题集每次切换模型、升级版本或者调整量化等级后都跑一遍这份回归集。很多模型综合评测榜单上的高分放到你的业务场景里未必好用。跑完自己业务集比看什么榜单都靠谱。回到开头那个问题模型查资料、会做事、还省成本分别靠什么一句话回答就是查资料靠RAG把外部知识接进来会做事靠Function Calling和Agent把工具交到模型手里省成本靠量化、蒸馏和本地部署把推理开销压下来。这三条线可以独立使用也可以组合成一个完整系统。我个人经历里最深的经验是别把模型当成什么都懂、什么都会、还便宜的全能选手把它当成一个需要给资料、给工具、控制成本的“聪明新员工”反而能把它的价值发挥到最大。