这两年只要打开技术社区满屏都是AI Agent和RAG热搜词里也全是“rag是什么”“ai agent入门”“rag实战”这类问题。但说实话我问过身边不少正在做知识库问答、企业搜索、自动化办公流程的朋友大多数人对这两者的理解还停留在“RAG就是向量数据库检索Agent就是能自动调用工具的大模型”这个层面。真到了要动手做项目、要应对评测、要回答面试官追问的时候才发现里面坑比想象中多得多。这篇文章不打算从概念PPT讲起我会直接拆解一个真实项目的思考链路怎么判断该用RAG、怎么把向量化流程做到能上线、Agent什么时候该介入、评估指标到底怎么算才不糊弄人。内容会结合我实际做过的知识库问答项目和一些最近的热门方向比如ontology RAG、graph RAG、agentic RAG来聊希望能帮正在入门或者卡在某个环节的朋友把整条线捋顺。1. 先搞明白这套组合到底解决了什么问题1.1 RAG不是“查资料”而是给大模型加装“可验证的记忆”很多人一上来就纠结“RAG和微调哪个好”这其实是个伪命题。RAG的核心价值不是让模型“记住”更多知识而是把“知识的存储”和“知识的生成”分开管理。模型本身的参数空间是有限的你不可能把几千份企业文档全部塞进权重里就算塞得进去也没法保证它不会在关键时刻一本正经地编造出处。RAG的思路更像给大模型配了一个随时可以翻阅的档案柜回答问题时先查档案再基于查到的内容组织答案。但这里有一个关键点RAG的好坏不取决于模型本身而取决于档案柜的整理方式。同样是拿LangChain搭一套检索问答为什么有人做出来准确率能到90%有人做出来连50%都不到差距基本都出在索引构建的细节上。热词里提到的“rag向量化流程”“如何创建精准的rag”本质上就是在问同一件事怎么把文档变成模型真正能高效利用的检索单元。1.2 Agent解决的是“多步骤任务”不是“单次问答”AI Agent和RAG经常被放在一起讨论是因为它们确实天然互补。RAG管的是“系统该怎么回答”Agent管的是“系统该怎么做”。举个例子用户问“帮我看看最近三个月哪个产品的投诉率最高分析一下原因”纯RAG能做的是把相关文档片段检索出来拼成答案但“先查投诉数据表、再定位产品线、再汇总原因”这一个完整流程需要Agent来规划执行步骤、调用不同工具、最后汇总结果。我见过不少失败的Agent项目失败原因几乎都一样把该用RAG解决的检索问题硬套上Agent多轮规划结果模型在规划上消耗了大量Token还经常把步骤拆错。反过来说只做RAG不做Agent遇到需要联动多个数据源的任务就会显得非常笨拙。所以理解两者边界比学会技术本身更重要这也是面试官最喜欢挖的深层问题。1.3 从热搜词看当前社区的关注重点把热搜词整体扫一遍有几个信号值得注意一是“rag知识库指标有哪些”“rag测评怎么做”这类评估类问题热度很高说明很多人已经过了“能跑通”的阶段开始关心“怎么证明它真的好用”二是“ontology rag”“graph rag”“agentic rag”这些进阶概念频繁出现意味着单纯拼向量相似度的做法已经满足不了复杂业务三是“针对3gpp协议的rag”“银行rag”这种垂直场景词出现说明RAG开始进入对准确性要求非常高的行业。这篇文章后续会重点覆盖这三个方向。2. 向量化流程中那些决定成败的细节2.1 切分策略比Embedding模型选择更影响效果很多新手在做RAG时把大部分精力花在挑选Embedding模型上这其实是个误区。向量模型的差异在同等量级下通常不会特别悬殊真正能拉开差距的是文本切分方式。热词里专门有“rag向量化流程”可见大家对这块的困惑程度不低。先看切分粒度的问题。按固定字符数硬切比如512字符一段看起来简单但很容易把一句话拦腰截断或者把一个完整的业务表格碎片化导致检索出来的片段语义不完整。我比较推荐的做法是结构化切分优先Markdown或HTML文档优先按标题层级切PDF优先按段落边界切代码库优先按函数或类切。这样切出来的每个片段本身就是“一个意思完整表达”检索命中率会明显提高。再看切分之后的“单元粒度”问题。有些场景下需要把多个小片段合并成一个更大的上下文单元。比如一份合同涉及甲方义务、乙方义务、违约责任三个板块如果切成三块分别向量化检索“如果乙方延迟交付该怎么办”时可能只召回违约责任那一块缺少必要的上下文。这时候可以做“父文档召回”先用小子块匹配向量相似度命中后返回其所属的完整父文档作为上下文喂给模型。这是工程上非常实用的技巧。2.2 召回数量、重排序和Dense Vector的配合召回阶段直接返回Top-K个相似片段然后拼给模型这种方案在小规模Demo里能用真实项目里基本跑不通。原因很简单向量相似度高不等于语义相关性高尤其当文档库里存在大量相似表述时排在前面的几个片段很可能讲的是同一件事的不同变体信息冗余会让模型抓不住重点。我的经验是走“召回重排序”的两段式流程。第一段用Dense Vector Search也就是热词里反复出现的dense vector search召回30到50个候选片段保证召回率第二段用交叉编码器类的重排序模型对候选片段做精细化打分取前3到5个作为最终上下文。重排序模型比双塔结构的向量模型更精细代价是速度慢所以只对第一段召回的小候选集跑性能完全扛得住。还要注意一个很多人忽略的细节重排序之后的得分是不能跨查询直接比较的不同查询的得分分布可能差异很大。所以不要试图设定一个全局阈值来决定“多少分以上才输入给模型”而是固定取Top-N个片段更稳妥。2.3 索引更新与数据版本管理RAG系统上线后最容易被忽视的是索引更新问题。文档库不是静态的合同会改版、产品文档会新增、公告会删除如果索引不跟着变模型会一直基于旧内容在回答。增量更新的方法是记录每个文档的哈希值或版本号检测到变化后只对该文档涉及的切分块重新Embedding并更新向量库。这点在银行这类真实业务场景中特别关键。热词里有“银行rag”金融行业对数据一致性和合规审计要求极高如果你不能说明当前模型回答用的到底是哪一版文档审计根本没法定论。所以从设计一开始就要给每个片段打上文档来源、版本号、入库时间标签这样才能在输出答案时附上可靠的引用链路。3. RAG和Agent结合的三种主流形态3.1 最简单的形态RAG作为Agent的工具第一种形态是把“检索增强问答”整体封装成一个工具Agent在规划时决定是否需要调用检索工具检索结果返回后由Agent整合成最终回答。这种方案适合任务本身以对话为主、偶尔需要外部知识的场景。实现上有个很重要的设计点工具的Description要写清楚“什么时候该调用、什么时候不该调用”。LLM的工具调用依赖对工具描述的语义理解如果你的工具描述写得太宽泛Agent会在每个问题上都先检索一遍浪费大量时间和Token写得太狭窄又会在真正需要时漏掉调用。我会在描述里明确说明“当用户询问政策、流程、规格、合同相关内容时使用本工具涉及简单问候或通用常识时不要使用”。3.2 agentic RAG让模型自己决定怎么查热词里的“agentic rag”是今年讨论度很高的方向。它的核心区别是传统RAG不管问题多复杂都只做一次查询而agentic RAG让模型根据问题自动拆解出多个子查询甚至决定查询哪个数据源。举个实际项目里的例子用户问“对比一下A产品和B产品在功耗、价格、开发难度上的差异”传统RAG会拿整个问题去做一次向量检索结果很可能只召回偏A或偏B的片段。agentic RAG的做法是把问题拆成若干个子问题分别检索相关信息再由模型汇总对比。这种方案对复杂问题提升效果非常显著但代价是需要更精细的提示词来约束拆解逻辑同时对Token消耗也更敏感。实现agentic RAG时我建议不要一上来就追求全自动。先用带固定框架的提示词让模型基于“FACT-CHECK和SUBQUERY两种模式”做决策需要事实核实时走检索子流程需要多维度回答时先输出子查询列表再并行查找。跑稳之后再逐步放开自由度。3.3 进一步升级从Graph RAG到Ontology RAGGraph RAG和Ontology RAG本质上都是想解决同一个问题纯向量检索抓不住实体之间的多跳关系。比如“这个漏洞影响了哪些产品线这些产品线的哪些客户群体风险最高”如果文档里没有直接出现完整句子向量检索很难通过语义相似度把这条关系链拉出来。Graph RAG的做法是先构建知识图谱把实体和关系存成节点和边检索时借助图遍历能力找到多跳关联。Ontology RAG则更进一步不只是实体关系还把领域概念体系、属性约束和逻辑关系也构建进来。热词里“ontology rag”单独占了一条说明关注的人已经不少。实际做的时候我建议从轻量起步用LLM从文档中抽取实体关系对存入图数据库比如Neo4j检索时混合使用向量相似度和图遍历结果。不要一开始就想构建一个完美的领域本体那是一个会在评审阶段永远完不成的艺术品。4. 测评不是走形式指标要能指导改进4.1 该看哪些指标检索质量与生成质量要分开评热词里有“rag测评怎么做”“rag知识库指标有哪些”这确实是个特别容易被糊弄过去的环节。我见过太多项目在汇报时说“准确率85%”细问之下发现这个准确率只是“模型自认为答案正确”完全没有量化检索质量。一个可靠的RAG评估体系应该分成两层。第一层是检索质量命中率正确答案有没有进召回列表、MRR第一个正确答案排在第几位、NDCG排序质量。第二层是生成质量忠实度答案是否完全基于检索到的上下文、相关性答案是否在回答用户问题、完整性是否覆盖问题所有方面。两层分开测才能定位问题到底出在检索环节还是生成环节。4.2 评估数据集怎么构建评估数据集的构建质量直接决定测评结果是否可信。最笨但最有效的方法是从真实业务里抓取高频问题然后人工标注参考答案以及命中的文档片段。一个项目准备100到200条高质量测试样本远比自动生成5000条噪声数据有价值。如果预算有限退而求其次的做法是用LLM生成初稿再由人工基于文档修正。要注意的是评估集需要覆盖边界情况单文档可回答的简单问题、跨文档需要整合的复杂问题、完全没出现在知识库中的超纲问题。最后一种尤其重要它测试的是“系统在不知道时能不能诚实说不知道”这是RAG区别于纯生成模型的关键优势。4.3 从指标到改进一个排查实例我做过一个合同问答项目初期忠实度指标只有六十多分症状是模型经常把合同A的条款安到合同B上。先测检索质量发现MRR其实还行说明正确答案基本能召回但Top-1经常不是正确答案。加装重排序模型后忠实度提升了十几个百分点。后来又有新问题涉及金额比较的问题会漏数据。排查后发现是切分时把表格拆乱了金额数字和产品名称被切到了不同片段。改成表格按行切分后问题彻底解决。这个案例想说明的是评估指标体系的意义在于帮你定位问题环节而不是给你一个用来汇报的“好看分数”。5. 从零搭建时的技术选型和避坑经验5.1 框架选择LangChain、Spring AI还是自研热词里有“langchain rag”也有“java rag”“spring ai 2.0 rag实例”说明Java技术栈在RAG项目里的需求非常大。框架选择的逻辑很简单如果是快速验证想法LangChain最方便组件丰富、社区案例多半天就能跑通一个Demo如果是在大型Java企业里做正规项目建议直接用Spring AI 2.0它能让你以Spring生态的方式管理大模型调用、向量库连接和Agent流程团队维护成本低很多。但如果项目涉及到非常定制化的评估流程、特殊的权限体系或者复杂的多数据源联动我不太建议完全依赖重量级框架而是用框架处理基础链路核心逻辑自己封装。框架的好处是快速启动框架的坏处是你得跟着它的抽象走等你想做点超越框架假设的事情时改造成本会很高。5.2 向量数据库选型视角选向量数据库时别光看榜单上的Recall数字更要看运维成本、权限体系和生态成熟度。小项目用开源的Chroma或Qdrant足够数据量到了千万级别以上可以考虑Milvus。企业级项目如果已经有ES基础设施直接在ES里加向量检索能力可能比另起炉灶更划算毕竟运维一套分布式组件的人力成本很高。还要特别提醒合规背景下数据不能出内网的项目一定要确认向量数据库支持纯内网部署和细粒度权限控制热词里的“银行rag”对这一点的要求几乎是一票否决制。5.3 Embedding模型的实践心得选Embedding模型的第一原则不是“排行榜最高”而是“在你的领域数据上表现好”。通用场景用BGE、M3E这类中英文效果都不错的模型能省心不少垂直领域比如3GPP协议这种专业文档如果想追求更高精度可能需要基于领域语料做微调——不过前提是你的标注数据量足够否则微调带来的提升可能非常有限。一个容易被忽略的细节是查询端和文档端可以用不同的Embedding模型或不同的指令前缀。很多模型比如BGE系列会在文档侧加“为这个句子生成表示以用于检索相关文章”的后缀查询侧加“为这个句子生成表示以用于检索相关文章”两侧策略不对称能显著提升检索效果。这个细节不少人不知道实测收益很明显。6. 聊几个新方向Agent能力边界和2026年趋势6.1 AI Coding Agent是不是被过度炒作了热词里出现“ai coding agent 2026年8月 最新进展”说明不少人在关注AI编码Agent。我的真实体会是AI Coding Agent目前在“生成单元测试”“写样板代码”“解释陌生代码库”这些场景下确实能用而且效率翻倍但要让它独立负责一个需要强上下文理解、跨模块设计决策的完整功能开发可靠性还远远不够。它的定位更接近“高级结对编程助手”而不是“替代程序员”。6.2 企业落地RAG/Agent时容易被忽略的“最后一公里”很多RAG项目在评测阶段指标很好看一上生产就崩原因大多出在“最后一公里”权限控制、数据更新、可观测性、成本控制。比如一个知识库里有不同部门的数据如何保证模型不会把A部门的保密数据泄露给B部门的提问者这在纯RAG架构里要靠检索前的权限过滤和检索后的内容再校验双重保障但大多数Demo项目压根没考虑过这个层面的问题。6.3 我对AI Agent 2026年发展趋势的看法我个人判断接下来一到两年几个方向会比较明显的趋势评估优先于模型“哪个模型更强”这个问题的热度会下降“如何科学评估业务效果”会变成更核心的议题超长上下文和RAG互补而非替代模型上下文窗口越来越长但RAG在成本、可溯源、权限控制上的优势不会因此消失两者会走向混合架构标准化协议MCP这类工具调用协议会逐渐成为Agent生态的事实标准工具接入成本会大幅下降可靠性和防幻觉将成为核心卖点在严肃场景金融、医疗、法律里谁能把幻觉率压得更低谁就能拿下市场这些方向其实从热搜词里就能看出端倪大家已经在从“怎么搭一个RAG”转向“怎么把它做到专业可靠”。对刚入门的朋友我的建议是先跟着这篇文章把RAG的向量化流程、检索评估闭环跑一遍再逐步引入Agent行为规划最后再考虑Graph或Ontology这些进阶方向。按这个顺序走你不会被概念绕晕。7. 最后分享几个实操中的小经验和习惯在多个RAG项目落地之后有几个习惯我一直保持对避坑很有帮助。第一个习惯是所有检索结果一律先看“原始命中片段”不要只盯着最终答案。很多时候模型答错了往下一查原因特别简单检索回来的Top-1片段本身就是无关内容或者内容对但排序放得太靠后。这种问题一眼就能定位比反复调整提示词有效得多。第二个习惯是给每个查询打上日志记录检索命中率、重排序得分、模型输出完整内容。哪怕项目还在开发阶段这些日志也是排查问题的金矿。等到上线后如果用户投诉回答质量你有日志就能快速回放当时发生了什么没有日志就只能靠猜。第三个习惯是“先跑通再优化最后抽象”。很多团队卡在第一步太久总希望架构一步到位、评估体系一步建全、Agent规划一步做到完全自主。但AI项目的特点就是不确定性极高你花两周精心设计的Agent规划框架实际跑起来可能发现用户根本不会那样提问。所以先以最快速度跑出一个小闭环用真实数据驱动迭代比任何精心前期的架构设计都更有价值。RAG和AI Agent的组合目前仍然是一个“上限很高、下限很低”的领域。下限低是因为很多人拿一套简单代码就去应付复杂业务问题上限高是因为优化空间巨大——无论检索质量、评估体系还是Agent规划策略都有大量可以深挖的细节。希望这篇文章让你们少走一些弯路。