先说个比较现实的背景。过去半年我陆续接触了几家金融机构和准金融机构的AI项目组大家不约而同地在做同一件事把大模型接进风控相关的业务流。有的团队做法规问答、信审知识库有的团队做尽调报告生成、反欺诈线索挖掘用的技术方案要么是RAG检索增强生成要么是Agent智能体还有一部分干脆把两者拼成了一个“混合体”。问题也随之而来到底哪个方案更合适两者在金融风控这种对准确率、响应延迟、可解释性要求都很高的场景里差距到底有多大这篇博客就是一次实战向的拆解我会从架构原理、典型任务表现、评测指标设计、选型决策和踩坑记录这几个角度把RAG和Agent的对比讲透。先说结论RAG和Agent不是同一维度的东西直接拿来做“谁更好”的对比其实有点不公平。RAG是一种增强模型生成能力的检索范式Agent是一种能自主决策、调用工具完成任务的控制框架。但在实际工程落地里大家往往把它们当成两种可选方案来做架构选型纠结的是同一个问题我这条风控业务到底应该用“知识库检索问答”的方式来做还是用“自主智能体编排”的方式来做。这个纠结我能理解因为在某些场景下两者的能力边界确实有重叠但一旦业务复杂度上来差异会非常明显。1. 先想清楚RAG和Agent到底在解决什么问题1.1 从背景聊起为什么金融风控开始用大模型金融风控是一个规则成熟但信息散乱的领域。反欺诈规则、授信政策、合规条款分散在各种制度文档、历史案例和监管文件里信审员做一笔贷款审批要同时查征信报告、财报数据、行业风险信息、历史违约案例信息源不止一个。过去很多机构靠的是专家人工检索——先找到对应制度再逐条比对效率慢、成本高还容易遗漏新条款。大模型最开始在这类场景的价值是“知识问答”把制度文档喂给模型业务人员直接问“个体工商户年收入300万、经营流水中断2个月能否准入某产品”模型给出答复。但直接让大模型用训练时学到的知识回答这种问题大概率会“一本正经地胡说八道”——因为金融制度是动态变化的大模型的训练语料根本追不上最新规则。这时候RAG登场了把检索到的实时制度片段作为上下文让模型“看着文档回答”准确率有了质的提升。再往前走一步风控的不少任务不是“查一个规则然后回答”就能搞定的而是需要多步骤处理。举个例子反欺诈调查员拿到一个可疑交易他需要先查交易流水再查关联账户再看历史案例判断这属于哪类欺诈模式最后写一份分析报告。这个流程如果拆成“检索生成”两步中间任何一次判断错误都会导致最终结果跑偏。Agent在这种多步推理场景里天然更合适它可以自己决定先调用哪个工具、拿到结果后怎么判断、判断完再去查什么形成一个“感知—决策—行动”闭环。所以我的判断是RAG适合“答案已知、关键是找到”的场景Agent适合“答案未知、需要推演”的场景。金融风控里两类场景都有所以才有了这个对比的价值。1.2 RAG的核心原理与适用边界RAG的标准套路是离线阶段把业务文档切片、向量化存入向量数据库在线阶段把用户问题向量化从库里检索TopN相关片段然后把片段拼进Prompt让大模型基于这些片段生成回答。这套流程从技术上已经很成熟了这也是它成为“大模型落地最快方案”的原因。但用熟了之后你会发现RAG的成败主要取决于三个环节切片质量、检索质量、生成约束。切片切得太粗召回结果不够精准切得太细上下文衔接断裂。检索出的TopN如果相关性差模型再强也白搭。生成阶段如果不对“未找到答案”的情况做约束模型还是会编造内容。这几个环节环环相扣任何一个拖后腿整体效果都会大打折扣。在金融风控里RAG的典型场景包括制度问答、合规知识检索、审批政策查询、历史案例匹配。这类任务的特点是“答案本来就存在于某个文档或案例中关键是把对的文档找出来并精确引用”。这种场景下RAG的解释性也很容易做——直接把命中的文档片段展示出来业务人员能立刻核实这一点在风控领域非常加分。RAG的短板也很明显它本质上是“单轮检索生成”如果问题需要先查制度A再根据制度A的结果去查制度BRAG就做不了——因为它的检索是一次性的、静态的没有中间推理状态。要让RAG支持这种多步检索需要外接一个编排层反复调用检索接口而这个编排层其实就是Agent的雏形了。1.3 Agent的核心原理与适用边界Agent的设计核心不是“生成”而是“行动”。一个标准的Agent框架通常包含模型大脑、工具手脚、记忆工作记忆和长期记忆、规划任务拆解四个组成部分。在金融风控场景里Agent接到一个任务后会自己拆解成一个行动计划先查什么、再判断什么、最后产出什么格式的结果。每执行一步它都有可能调用一个外部工具——比如SQL查数接口、征信报告解析接口、法规库检索API、文档生成模板——拿到工具返回结果后再决定下一步动作。这种“自主性”在解决复杂任务时非常有用。典型的例子是贷前尽调传统做法是信审员手动打开多个系统把工商信息、司法涉诉、舆情新闻、财务数据一项项查完汇总成报告。Agent可以把这套流程自动化它先调工商接口核验主体信息发现疑点后自动去涉诉信息库补充查询再结合舆情数据进行交叉验证最后按固定模板生成一份尽调初稿。Agent的优势是能承载复杂流程但代价是复杂度更高。开发成本、调试难度、失败率都显著上升。最难控的是“不可预测性”同一个任务Agent今天可能走A路线明天走B路线如果不做好规划约束和工具的确定性兜底风控这种对流程一致性要求极高的场景很难放心使用。很多人对Agent的理解是“让模型自由发挥”这其实是误区真正可落地的Agent要做大量限制把自由度关进笼子里。2. 金融风控场景下的性能对比四类典型任务实测对比不落在具体任务上没有意义。这半年我整理的对比结果来自多个项目中的实际观察和公开技术分享的汇总不是实验室环境的空谈。我选四类有代表性的风控任务分别说明RAG和Agent在设计思路、实测表现上的差异。2.1 场景一法规制度知识问答与合规助手这个场景是RAG的主场。业务人员问“反洗钱大额交易的报送标准是多少”“私募基金合格投资者的净资产要求”这类问题答案就锁定在某份具体制度文件的某个章节里。用RAG方式系统先把全套法规切片入库检索命中后把相关段落交给大模型改写组织语言同时标注出处。实测下来RAG在这个场景的准确率能做到90%以上按Top5召回命中率结合答案正确率综合评估响应时间1到3秒。Agent也能做这件事但不划算——Agent会“想太多”把简单问题拆成好几个步骤反而增加了中间环节的出错概率。用Agent做纯知识问答等于是用大炮打蚊子。2.2 场景二贷前尽调与多源信息核验贷前尽调是Agent的典型应用场景。一笔企业贷款要做尽职调查需要核验工商信息是否一致、有无异常变更、司法涉诉情况、行政处罚记录、舆情是否有负面消息。这些信息分散在至少5个外部数据源里而且核验逻辑还有优先级如果工商信息异常要先暂停再看司法记录如果涉诉命中要判断案件性质再决定是否触发预警。用RAG做这个场景会很吃力。你没法把这么多来自不同系统的结构化数据“切好片、藏进向量库”因为数据是实时变化的也不是文本格式而是JSON、数据库表、API返回值。强行转成文档做检索数据时效性和结构化程度都跟不上。Agent方案则是天然契合每个外部数据源封装成一个工具Agent按预设流程依次调用根据每次返回结果实时决策下一步动作。实测效果差距非常明显Agent方案能在一个完整流程里自动完成80%以上的数据核验动作人工只需要做最后的审核确认RAG方案在这个场景基本没有实际可用性或者只能退化成“每个数据源单独开发一个检索问答机器人”流程是断的。2.3 场景三疑似欺诈案件调查与报告生成欺诈调查是金融风控里最复杂的任务之一。调查员拿到一个账户需要分析它的交易流水特征、关联账户网络、历史可疑记录、与已知欺诈案例的模式相似度最后输出一份包含疑点分析和建议措施的调查报告。这个场景我用纯RAG和纯Agent都试过。RAG的问题是案件调查的“问题”不是一次性提出的而是随着调查推进动态生长的新问题。比如看到流水发现某账户深夜高频转账你会追问“这个对手方账户是否在其他案例里出现过”——这种追问是对前一步分析结果的进一步深挖RAG的静态检索机制很难承接这种链式追问。Agent则可以维护一个“调查状态”记忆把已经发现的线索记录下来作为下一轮决策的输入。实际体验是Agent在这个场景能连续执行5到8个步骤而不跑偏前提是提前做了完善的步骤约束但对于生成的调查报告目前仍然不能“直接交付”需要人工审核后才能归档。一方面模型偶尔会遗漏细节点另一方面监管要求风控报告必须可追溯、可复核人工这一步短期内不可能完全省掉。2.4 场景四实时异常交易分析与反欺诈决策这算是金融风控里对性能要求最苛刻的场景交易发生在毫秒级风控系统需要在交易完成前完成判断。目前这个场景的主流方案仍然是大数据规则引擎加机器学习模型并不是大模型的强项。RAG和Agent在这个场景的表现都不算理想。RAG的问题在于“检索生成”的耗时太长即便优化到极致也要几百毫秒还经常因为模型幻觉产生错误判断在实际交易链路中不可接受。Agent的问题在于“自主决策”在某些极端情况下可能做出非预期动作这种不确定性在资金交易场景中是无法接受的风险。在当前的技术条件下我倾向于这个场景保持规则引擎和大模型“分层协同”规则引擎做实时拦截RAG/Agent做离线的案件分析和策略优化支持。虽然大模型技术发展很快但“分钟级”和“毫秒级”之间的代差不是靠调整架构就能缩短的。我整理了一张表格把四类场景的适配度做了一个直接对比方便后续选型时参考。场景信息结构流程复杂度时效要求更优方案法规制度问答文本型强结构低秒级RAG贷前多源尽调结构化数据API高分钟级Agent欺诈案件调查混合型动态变化高分钟级到小时级Agent实时异常交易结构化流数据中毫秒级大模型尚不适用3. 评测指标设计与方法论对比不能只看准确率很多团队做技术选型时只盯着一个“准确率”指标看这在风控场景里远远不够。我实际踩过这个坑有一个RAG问答项目离线评测准确率做到95%一上线业务团队就说没法用。后来发现问题不是准确率而是答非所问时给的是“看似合理但实际错误”的答案业务人员根本无法分辨。这方面的教训太深刻了。3.1 性能评测的四层指标体系我在做RAG和Agent对比评测时会把指标体系分成四个维度。第一层是任务完成质量准确率、完整率、错误率这些基本指标都在这一层。评测方式不是只看最终答案对错还要看中间过程的合理性和最终结果的合规性。比如贷前尽调Agent即使最终报告结论正确如果中间漏掉了某个必查的涉诉信息源整体质量就要打折扣。第二层是响应性能主要看端到端延迟和吞吐量。Agent因为多步推理和多次工具调用延迟通常远高于RAG。如果Agent做一个尽调任务要跑5分钟业务部门能不能接受如果10个并发同时触发系统扛不扛得住这些问题比单纯看准确率更能影响落地效果。第三层是稳定性和可解释性。稳定性指面对相似输入系统给出相似输出的概率。RAG的随机性主要来自LLM生成阶段的采样通过降低温度就能控制Agent的不确定性来自规划路径即使生成阶段温度归零不同次运行也可能选择不同工具或不同步骤顺序。可解释性方面RAG可以直接展示检索到的文档来源比如引用了哪个制度、第几章第几条而Agent要追踪完整行动轨迹才能解释它“为什么这么做”。第四层是成本与运维。这里的成本不只是大模型API调用成本还有开发调试成本、向量库存储成本、工具API的维护成本。Agent因为需要在Prompt里塞“工具定义历史轨迹任务指令”token消耗通常是RAG方案的3到10倍如果Agent是自主规划模式还经常出现“过度思考”、调用多余工具的问题。成本这一维度在金融行业尤其敏感预算控制往往比技术理想更重要。提示评测金融风控系统时准确率高绝不等于可用。要同时建立“错误代价评估机制”——答错一个法规条款、漏掉一个风险点对应的损失分别是多少。这种损失量化评估结果往往比技术指标更能说服业务方。3.2 可解释性、审计与合规约束金融行业对模型输出的合规要求是系统给出的每一个决策结论都能追溯到具体的依据。RAG在这方面天然有优势——答案里的每个关键信息点都可以标注来自哪份文档、哪个段落。但要注意还有少量信息是通过大模型自带的推理能力“脑补”出来的这部分如果不做标注仍然有合规风险。我的做法是要求系统在输出关键结论时同步返回“依据证据列表”没有证据支撑的结论不允许出现在最终交付文本中。Agent的可解释性则要看控制粒度。框架类的Agent解决方案每一步行动都有历史轨迹记录能产出完整的“行动计划工具调用日志”从这个角度看可解释性反而不算差。真正的麻烦在于Agent的行动路径不是固定的每次跑可能不一样给审计带来了“流程不可复现”的困扰。我现在做的方案是给Agent预设严格的工作流模板把自由度限制在只有少数几个“决策叉路口”上保证审计人员每次看到的流程主干是一致的。3.3 成本与架构复杂度对比成本对比不光是“谁花的钱多”还要看“钱花在哪里”。RAG的成本构成相对简单向量库存储费文本量级通常是GB级别成本很低、指令Token消耗固定Prompt加检索结果、向量化API调用费。整体来说RAG是可控且容易预估的。Agent的成本构成要复杂得多。开发阶段要定义工具、设计规划逻辑、做多轮调试这部分人力成本往往是RAG方案的数倍运行阶段除了模型Token费用更高之外还有工具API调用费、失败重试的额外开销。更隐蔽的是故障排查成本——Agent跑挂了你可能需要检查整个链条上的每一步定位问题所在的时间远远超过改代码的时间。但这不意味着金融风控里一定要回避Agent。如果业务场景的复杂度确实需要多步自动化Agent带来的效率提升会远超其开发和运行成本。关键在于不要把Agent用在不该用的简单场景上。4. 选型决策什么时候用RAG什么时候用Agent如果你现在正好要做一个金融风控AI项目纠结不知道该选RAG还是Agent我的建议是不要按技术名词来选而是按业务任务特征来分。我总结了一条比较实用的判断路径能帮你快速做出基本判断。4.1 判断标准任务复杂度决定技术选型先问三个问题。问题一这个任务的答案是否已经存在于某个已知的信息源里如果答案是明确的、可检索的那RAG大概率够用。问题二任务完成是否需要调用多个信息源并在这些信息源的结果之间有逻辑判断如果需要那RAG不够要考虑Agent化改造。问题三任务的执行过程是否允许出错后重试如果允许Agent可以上如果不允许比如实时交易决策那现阶段任何大模型方案都要慎重。还有几个信号能辅助判断。决策路径是否固定——如果业务流程完全标准化那就干脆别用Agent的“自主规划”而是用工作流引擎编排LLM做单节点增强如果流程中确实存在需要根据中间结果动态调整下一步的“判断点”这才值得引入Agent。4.2 混合架构以Agent为主控、RAG为工具的落地模式在真实的风控业务里RAG和Agent很多时候不是“二选一”而是“嵌套关系”。成熟的做法是用Agent做流程主控把RAG封装成Agent的一个“查文档工具”再配合外部API工具、数据库查询工具组成一个完整的工具箱。举个例子Agent在做信贷审批辅助时判断“申请人所在行业是否有政策限制”这个环节就可以调用一个RAG子模块——从行业政策库里检索最新政策然后让LLM基于检索结果给出判断。Agent负责决定“什么时候需要查、查到结果后怎么处理”RAG负责把检索和生成做到最好。这种混合架构既保留了Agent处理复杂流程的能力又利用RAG保障了知识引用的准确性。很多人问混合架构是不是会带来更大的复杂度。确实会有但复杂度可控。我的实践心得是在Agent里调用RAG时把RAG当作一个“确定性”的功能模块来看——定义好输入输出格式、设置好超时机制和兜底返回内容不要在Agent的运行逻辑里去动态修改RAG的检索参数。这里需要补充的是“确定性”不是指RAG的答案永远一样而是指它的调用契约和返回结构必须稳定可靠这样Agent才能自如编排。5. 实操经验与常见问题5.1 踩过的坑和总结的心得做这些项目时我踩过不少坑有几个经验对正在做类似方案的人特别有价值。第一个经验是关于评估数据的构建。技术团队很容易陷入“让开发人员自己写测试题”的误区。真正的问题是开发人员对业务的理解和业务专家不一样做出来的评测集和真实场景脱节。我在做风控场景评测时会拉上业务信审团队一起标注评测集一条高质量测试数据通常包含标准问题、期望答案要点、答案依据出处、错误答案示例。这样评测出来的结果业务专家才会认可。第二个经验是关于文档切片的优化。RAG的检索效果对分段质量的依赖超出很多人的预期。我建议处理制度类PDF时先做非结构化解析——根据章节标题、条款编号把文档按逻辑结构拆分而不是直接按固定字数硬切。风控制度中条、款、项的逻辑层级是否完整直接决定了检索命中后答案的完整性。同样长度的制度文档解析得好和解析得差准确率能差到20个百分点以上。需要补充说明的是我这里说的“按逻辑结构拆分”针对的是有清晰层级结构的制度类文档如果遇到连续性较强的研报类文本反而不宜过度细分否则语意会被切断两种文档需要区别对待。第三个经验是关于Agent模式的选择。现在LangGraph这类框架给了两套Agent设计模式一种是Plan-and-Execute先整体规划再执行另一种是ReAct边思考边调用工具。金融风控场景我用的是Plan-and-Execute做顶层流程构建每个子步骤内部用ReAct做局部的工具调用。这种组合兼顾了可解释性和灵活性。如果从一开始就全用ReActAgent会频繁出现“走着走着就跑偏”的情况这在风控流程里是致命的。第四个经验是关于安全兜底。无论RAG还是Agent都必须做“回答边界”限制。RAG要在检索不到答案时明确告诉你“对不起没有检索到相关信息”绝对不能为了让客户满意而硬编答案。Agent要在连续执行错误、或者工具返回结果异常时自动终止任务并转人工处理而不能无限重试。这个兜底逻辑决定了一个系统敢不敢真正上线给业务人员用。5.2 环境准备与快速体验路径如果你在一个金融技术团队里想快速验证RAG和Agent在自身业务场景下的差异不用一开始就投入巨大的工程成本建议按照从轻到重的路径逐步推进。第一步跑通RAG基线系统。用开源的向量库与RAG框架花一个下午搭建一个能检索前提条件的MVP把制度文档丢进去先测50到100条真实业务问题感知RAG在你业务里的基础效果。我习惯给每个业务问题配上“人工标注的正确答案答案出处”这样比较起来更客观。第二步在RAG的Prompt里加上简单轮次记忆模块模拟“多轮追问”的流程看看能不能承接一些顺序依赖的问题。如果效果可以接受其实就不一定非要上Agent了。RAG可以通过加记忆与改写模块来处理部分多步问题不少团队做完这一步就满足了。不过要留意这种“伪多轮”方案的用户意图识别容错率不高问题一旦跨主题就很容易把上下文绕晕。第三步再考虑基于LangGraph搭建一个风控Agent原型只接入两个工具比如“政策法规检索”和“企业信息查询”定义简单的工作流让Agent完成一个“查询政策—根据政策判断企业准入资格”的任务。跑通以后逐步增加工具和数据源的接入。第四步才是验证混合架构。让Agent调用RAG检索工具配合其他API完成一个跨库核验的真实业务场景。到这一步你才能判断“AgentRAG”的混合方案在你的业务里是不是真的能打赢任何单一方案。我经历过很多次“理想很丰满、现实很骨感”的时刻混合架构只是能力上限高并不代表部署了效果就自动变好。整个路径走下来大概需要一两个月但能非常清晰地回答“我在风控场景里到底该用RAG还是Agent”。整个过程也是在为后续的正式开发积累可复用的Prompt模板、工具代码和数据验证集对于银行、保险、支付机构这类对系统建设流程有要求的团队来说这一步沉淀比模型选型本身更重要。5.3 一些常被忽略的实用细节最后补充几个容易被忽视但对体验影响极大的细节。一个是向量库的选择别迷信大厂方案。金融行业私有化部署很常见体积小、配置简单的向量库往往比重型方案更合适。选型时要关注百万级向量下的检索延迟以及是否支持内置的权限管理、私有化部署。另一个是Embedding模型要针对金融语料做微调或领域适配通用Embedding模型在财经术语上召回效果会明显变差。还有一个细节是时间敏感性问题。风控知识库里的政策法规如果频繁更新RAG系统必须有一套文档更新的“重发布”机制否则你今天检索到的可能是半年前被废止的旧条款。系统里要记录每条知识入库时间和最近一次更新校验时间这个问题在Agent查询风控政策时同样存在。所以无论是RAG还是Agent都不能忽略了一个叫“知识新鲜度管理”的环节——这往往决定了系统在上线三个月之后效果是不是还在线。这些细节看起来没有什么技术含量但正是它们决定了系统是一个“演示demo”还是一个“业务系统”的分水岭。我个人的体会是RAG和Agent本身没有好坏之分只有适不适合你的业务场景。在金融风控里简单信息查询就用RAG复杂任务自动化就上Agent两者能结合起来就尽量结合起来。关键是提前把自己业务的评测数据做扎实用数据说话而不是追着热点跑。等你的实测结果出来那一刻选RAG还是选Agent答案会清清楚楚摆在你自己面前。