很好奇 RAG 真的是现代 ai agent 所需要的吗，还有 langchian 这种框架，没有看到太多知名开源项目用到了

[murongxdb]

看了一下大家的回复，使用 RAG 大都是建立在海量文本的情况下，而且貌似坑比较多，一般通用 Agent 大概率用不到 RAG

看了一下大家的回复，两极分化，看好 RAG 和不看好 RAG 各占一半

[ZimaBlueee]

知识库类的需求还是要的吧，不然还有什么替代呢

[murongxdb]

@ZimaBlueee 感觉知识库算不上符合 harness 规范的现代 agent

[ktyang]

我们尝试了一下效果并不是很好，反正现在不用了，也可能是我们自己菜。

[murongxdb]

@ktyang 是指的 RAG 还是 langchain 这种

[YanSeven]

同样好奇，尤其是好奇 langchain 的实际落地情况。

[Jiahim]

最近也在思考这个问题，探讨一下，在数据量不大的情况下，rag 可能并没有效果那么好，反倒成为一个额外的工作量。
现在如果是传统的文本切片做 rag ，其实当数据量大之后，一方面不一定准确，另一方面如果数据有变化后，所有相关的文本其实会面临过时且难以修改的问题。
现在大一点的项目可能会用基于知识图谱的 Rag ，这个可能在未来的落地后更可靠些。它可以维护住事物之间的关系，也能确保更新后是彼此正确的。

[hqmJoker]

我感觉还是有的（但没有真实数据），应该是用的大部分都是企业级产品，或者企业内部用的，消费者日常接触不到所以感受不深

就像我之前觉得 Angular 在国内基本没有企业会用吧（又长又臭的），但是实际是入职的三家公司有两家都是用的 Angular （虽然体量还是比 Vue 少多了，但是也有点刷新了我的看法）

“幸存者偏差”真的哪里都存在，就像你现在感觉没啥人 RAG 、langchian ，但当你接触到那个圈子之后，就会发现身边的人、企业全部都在用这些东西，为啥市面上还有人没听过？

[ZimaBlueee]

@murongxdb #2 像法律条文这种海量文件场景，不搞 RAG 怎么定位相关文件呢

[mjawp]

RAG 就是是一套固定 SOP 的 workflow 。

[juvenile1024]

longchain 还是太简陋了，用的更多的应该是 longgraph

[murongxdb]

@Jiahim 之前看过一个文章，说是 anthropic 公司做 claudecode CLI 的时候，初版就是用的 RAG 做文本的检索，但是后来他们发现 RAG 做起来很麻烦而且收益不是很大，就换成了 grep 命令检索文本，结果效果出奇的好，我目前能想到唯一能用到 RAG 的地方就是大文本的知识库系统，但是大文本的知识库系统跟现代的和 herness engineering 没太大关系

[murongxdb]

@hqmJoker 确实有“幸存者偏差”，但是阅读过很多优秀的 agent 开源项目，很少很少使用 langchain 的，是因为 langchain 这类框架不够好，还是根本没有用的必要

[skyemin]

阿里的 agentscope 咋样

[Jiahim]

@murongxdb #11
在程序员编码语境下的 RAG 可能确实价值并不大，但是如果是业务系统语境在的 AI Agent 可能还是有的，比如类似 chatbi 的系统，里面的 Agent 如果要生成报表生成 SQL ，需要知道各种隐性知识之间的关系，此时基于知识图谱的 RAG 作为 AI Agent 的隐性知识来源，就显得有价值了。

[Hstar]

先说 RAG, 当有数据的量级大到难以注入给 Agent 的文件系统时, 甚至量大到连数据索引都可能会超 100K token 时, RAG 才有必要. 大部分情况下直接把引用内容挂到 Agent 的文件系统里, 加三五行对文件结构的介绍, 让 AI 用 ls 和 grep 去使用, 效果就很好了.
再说 langchain, 我觉得定位于一个新 Agent 产品的 bootstrap 还是不错的. 迭代下去总会发现有不能满足的需求, 还有多余的功能. 在 AI 加持下参考基于 langchain 的项目代码, 再从头撸一个也不费什么事.

[murongxdb]

@ZimaBlueee #8 我感觉这种海量的场景，就直接针对场景训练模型吧

[murongxdb]

@Jiahim #14 这种场景，除了 RAG 还有没有更好的方案

[murongxdb]

@Hstar 海量数据情况下，RAG 的性能够不够

[Jiahim]

@murongxdb #17 应该说没有银弹，就是一直在更新，现在是多种检索方案去配合，简单的切片 RAG 、知识图谱、传统的 SQL 查询都会用到，还有一些模型识别 top N 等等。

[Chihaya0824]

@murongxdb 你是否在找
https://arxiv.org/html/2605.15184v1
前几天才看见这个 paper

[Hstar]

@murongxdb RAG 只是一个形式, 底层搜索用的 文件 grep 还是 ES 还是 向量数据库 亦或是其他什么东西不就丰俭由人了嘛. 你这问题问得好怪

[ZimaBlueee]

@murongxdb #16 文件每天更新再每天训练？

[murongxdb]

@Hstar #21 我没有做过这种海量文本的场景，所以比较好奇

[WithoutSugarMiao]

楼主是在做什么工作的？ 我们几乎所有的用户都要求我们提供 RAG ，让他们可以通过文档来调整智能体的能力。

而且 langchain 本来也不是需要大规模使用的，AI 开发不是 java 要使用 spring 、python 要用 django ，你就要用这个框架的各种功能，虽然最初确实是这样，不过已经是 22 年、23 年的事了，后来发展到应用 langchain 里的某个模块，比如读个文档啦、分块一下啦之类的，但是大家觉得 langchain 默认的功能不好用，只能做玩具，所有后来这些事情有了单独的处理方式，比如我们公司部署了自己文档处理，开源的也有 minerU 之类的工具，很好用。

再往后发展，到 agent 时代，langchain 自己也做了它们的 agent 框架叫 langgraph ，然后还有什么字节的 deerflow 啊 之类的，这些都是开箱即用的东西，可以快速的搭建出原型。但是我们给用户做智能体的时候，一般是不会完全套用某个框架的（这个和 web 开发区别很大），正常来说都是从 0 开始做的，一方面是这些框架都比较臃肿，而客户的需求是明确的，会有很多功能都用不上；还有一方面是增强对整体的掌控力。

那么如何从 0 开始做呢？其实基本上就是走了 langchain 那一套流程。只是每个功能的细节都是重新做的，都是当前项目定制的。

所以不是没有使用 langchain ，而是 langchain 的功能已经沉淀在历史中了，当前各种智能体框架也好、openclaw 、herness 之类的概念也好，都有 langchain 当年思想的体现。

[pengtao2001]

langchain 只是一个 AI 开发的“零件箱”

[fallimmortal]

我觉的 langchain 和 langgraph 的东西都很简单， 根本没必要 去趟他们的坑， 我之前它的 RctAgent 各种奇怪的问题， 后来自己写了一个也很简单。 所以我的结论是， 在 vibe code 的情况下， 根本没必要使用这些东西， 按照自己的业务需求生成一个合适自己用的 类似的东西 是分分钟的事情。

[teaguexiao]

RAG 对于企业私有知识库场景还是刚需，模型再强也不知道你公司内部的东西。LangChain 这类框架确实过度封装，小项目直接用原生 SDK 配合 structured output 会简单很多。

[murmur]

RAG 适合做知识库，但是不适合解决文档太长模型处理不了的问题

[GeruzoniAnsasu]

RAG 当初浅尝辄止就发现了很多问题，我是感觉这东西完全不可能跟上下一代 agent 的演进速度。

RAG 最大的缺陷是它把原本已经很泛化的「知识」重新覆盖成了高频高音量的噪声，比如假如模型本来能完美学习一本书的所有内容，能用不同语言、不同逻辑重新讲给你，但 RAG embed 进去的话，有效信息会被大量剪裁，最终能吐给你的只有少量关键注意力点和原文文本组合。

而且 RAG 嵌入的信息是「单次」的，我不知道怎么专业地描述这个现象：它能嵌入「知识」，但不能嵌入「知识的知识」和「知识 of 知识的知识」 —— 假设用 RAG 把全国人名都嵌入了，它只能告诉你「王？？」具体是「王 XX 」，但不能获得「王 XX 」有多少人（二次知识）与「王 XX 」族群数量可能与哪些它掌握的其它知识有关（三次知识）。

再加上 function calling 成熟后，显然用专家能力（传统 ES 和正则）去索引文本要比 RAG 简单高校得多，我是想不到 RAG 能玩出什么花。

[GeruzoniAnsasu]

@WithoutSugarMiao 那正好请教一下：

请问你们对比过传统文本数据库+LLM 思考操作索引与直接用 RAG 嵌入两种方式的效果差异吗？我很好奇 RAG 方式在成本或者检索速度之类的方向有没有压倒性优势

[yafeilee]

这是常见误区，我们花了大教训的：

第一代（ 2024-2025 上半）：RAG / 知识库
把用户 codebase 、文档、历史会话全 embedding 进向量库，hybrid 检索 + 重排 + query rewrite 。Agent 流程是"先查上下文，再答"。

实际跑下来的问题：

成本高，每次更新的 codebase ，需要同步更新向量，实时性无法保证。
准确率有限，例如听起来 90% 的召回率是不是还不错，但是对不起，不仅没有用，还可能有害，我预测，97%的召回率可能才刚刚够用。
多了一个会失败的部件（向量库），增加了很多延迟。
结论：千万不要搞任何 RAG 、知识库分片。如果你要上 Agent ，请直接上 Agent ，外加一个适合 AI 去阅读的网站就可以了。（参考我们自反思 Skill product-help 的实现）


完整 harness 设计经验分享： https://v2ex.com/t/1212780

[wat4me]

感觉在数据量不大的情况下，rag 还没有让工具暴力搜索好用，我之前想着自建 rag ，后面觉得把目录分好，然后写个 Skill 让 AI 自己去搜，比用 embedding 模型去切分用户输入还方便好用些

[spark]

@wat4me 确实没有太大必要，一个有着良好索引、结构的整洁文档库比 RAG 要便捷太多了。LLM 知道如何调用适合的工具去检索。

[et5494]

实际场景下
RAG 就是为了补全“纯私有数据”
我们一个项目，其中大部分时间就是为了补全 KN 和正确召回

[neuthself]

@GeruzoniAnsasu 29L Ontology 就是解决这部分问题的吧

[neuthself]

<阅读过很多优秀的 agent 开源项目
OP 有什么 agent 开源项目推荐阅读的吗

[xyz8899]

我觉得 RAG 的应用场景应该是在法律、医药、生物科技等存在海量内容，并且相关内容并不一定有强关联性的环境。我是在医疗领域的，我自建了 RAG ，一种治疗方案（药品、医疗器械、化学结构）就有几百、上千篇学术论文，而且大都是 PDF 格式的文章，我把他们都向量化了，数据库现在有 90W+条数据（这还只是一个很狭窄的领域），不去管召回率多少，不要想 AI 给你一个完美的答案，通过 RAG 返回的数据能给你思路和想法，已经很好了，然后你再沿着这个思路和想法继续深挖下去足够了。
但是我觉得 RAG 不能用于 code ，我不是计算机课班出生，只是懂一点点编程，但是我认为技术没有好坏关键是在哪个领域适用的问题。

[murongxdb]

@neuthself #36 hermes agent 、openclaw 、codex 、claudecode cli 开源版等，很多很多

[murongxdb]

@yafeilee 之前读过大佬的这篇帖子，受益匪浅

[GeruzoniAnsasu]

还想再发散一点：

现代和下一代的 AGENT ，早已不依赖模型的数理逻辑事实了，它们依赖的是「智能涌现猜想」—— 也同时是 scaling law 描述的事：只要模型持续进化下去（规模、复杂度 ……），模型就能表现出越来越高级的智能。只要这个假设还未证伪，就不需要为模型开发专门数理工具（不再需要「以机器的视角设计工具」），训练模型掌握人类工程工具即可。

而 RAG 是上一代的东西——试图重建模型的底层数学模型并在特定层加入特定的 bias 。不是没用，而是没必要了，模型的泛化能力成长远高于人为干预，最终能把数值调优都吃掉。

人是不需要把文本资料和知识向量化储存的 => 所以 LLM 也不需要。

[diudiuu]

天天有人上传小说或者文章就得用啊

[IsaacYoung]

之前做代码生成 类似一个小的组件库 用 RAG 生成的属性都不全 直接扔 context 效果拔群

[yuanqi]

langchain 确实没必要

[yusf]

你就说用户问 [苹果手机] ，如果没有 rag ，你要不要按照 [iphone] 来进行搜索吧

[v2exgo]

RAG 没啥必要吧，主要是大量使用 RAG 的人或者组织，根本没有办法把他们的资料整理成有用的东西，国内蒸馏国外大模型，本质上也是缺优质高质量 整合的数据，这些数据都是海外 AI 公司自己花钱或者聘请专业人士编辑过的，你不可能通过 github 上那么多垃圾的仓库的代码训练出来 opus-4-7 或者 gpt-5.5 这种玩意。

回到本质，大模型最终依靠的还是高质量的数据+算力。
垃圾数据进，垃圾结果出，这是没办法的事情，
模型是在计算相关性，并不是帮你把所有的信息串联起来，进行思考理解，然后过滤出无效信息，并最终给你得出一个可靠的结论

[suke119]

RAG 和 agent 是一个融合关系 也就是你的 agent 里面可以包含有 RAG ，也可以不包含，rag 就是现代 agent 中的一个子 tool 而已。

[johnnyyeen]

RAG 快被淘汰了吧

[Vipcw95]

除非有更高效的，否则还是得 rag

[irrigate2554]

langchain 屌用没有，之前写一个 Agent 用的 langchain ，后面手搓反而更简单效果更好

[horizon]

@yusf #44
LLM 生成多个关键词搜就行了

[yh7gdiaYW]

@horizon 内网用户可以让他习惯，C 端不行。LLM 生成关键词重复搜会严重拖累速度，而且只能解决同义词，提问的是个用词不标准的自然语言查询就傻了

[seenthewind]

个人心得，RAG 有用。

现在已经 AI 干活，我在旁边发愁各种其他事情，奇怪的是感觉有点降智，遇到事情也想不起来出处，没辙只能上 RAG 了。。。

确实遇到想不起来的事情，RAG 快速搞一轮还是有用的。

最后顺带一嘴，技术方面，RAG 的路线，在语义层面和 LLM 是一条路线，如果可以维护好 RAG ，后续模型的微调和增训都是有利的，只不过目前大部分场景还没开始接触微调和增训。

[pppwww]

@Jiahim 大佬，基于知识图谱的 RAG 这个有没有开源项目推荐，目前也涉及到一些报表生成，SQL 生成上的问题

[ximaoyang]

哎。当然不是了。RAG 都过时了。其实国外有个声音就是 RAG is DEAD 。因为 context engineering 出来之后，大家发现其实逻辑不用放 RAG 里面，也不是每次都要向量搜索。逻辑完全可以放到 context 里面，而且是以一种人类可以阅读的 markdown 方式记录下来。
如果需要跟外部沟通就用 MCP 。
langchain 是最早期的版本。后来出了 langgraph + langsmith 。基本都用 langgraph 了。但是 langgraph 其实也有很多人质疑。因为 claude 源码泄露后，大家发现 claude 根本没用 langgraph 之类的做 ui ，用的是 TAOR ，其实很简单，就是 LLM 回答一遍，然后问自己回答完了吗？还需要调用什么工具？然后重复这个循环就行了。也不用 langgraph 这么复杂。
现在也没什么人用 langgraph 。主要是看起来还是有点抽象。但是我觉得 langgraph 是被低估了，因为简单的 TAOR 有可能会出现无限循环，因为没有特别好的边界控制能力。毕竟 langgraph 再难学，写的也不是你啊。。怕啥。。是 ai 在写。

[snoopygao]

@xyz8899 我的场景是云计算基础设施集成建设，有大量的标准需要遵循，因为文档超多，零散的知识很难一次找到，我觉得使用 RAG 的效果还是不错的

[TerryBlues]

🤔多模态的场景下是不是依然还要用 RAG 呢？

[nofishing]

不需要 RAG ，但是需要数据治理，当做了数据治理后，也就顺便做好了 RAG 。
很多用户（企业或个人）从未管理过数据，一股脑塞到某个向量库里，结合 AI 使用发现 RAG 太棒啦，那是当然了，从 0 到 1 肯定是效果爆炸。
如果没有业务场景和资源来支撑对数据做精细化管理，那就随意尝试各种 RAG 吧，粗放式管理也是管理。一旦有，再随意 RAG 就成了制造污染。
用户真正需要的不是某个多强大的 RAG 框架，而是一套适合自身的数据治理体系。

[cutchop]

grep is all you need

[Jiahim]

@pppwww #53 没有诶，我们企业内部的项目，目前的主流思路就是这样

[0xD800]

Agent 跟 RAG 并无直接关系，RAG 是搜索知识库用的，Agent 是 ReAct 框架的实现及扩展，RAG 是服务于 Agent 的。

[superkite]

@Jiahim 能细说吗，基于知识图谱的 rag 可以解决召回率低的问题吗

[xyz8899]

@pppwww #53
https://github.com/getzep/graphiti


@nofishing #57
认同，数据治理很重要，买旧书训练 AI 的、使用搜索数据训练 AI 的、用推特数据训练 AI 的，现在完全拉开了距离，我的 RAG 库已经更新了 3 版了，现在能入库的数据都是人工清理过的了，感觉和第一版完全不一样。

@0xD800 #60
正确，RAG 只是给 Agent 提供数据

[maolon]

怎么感觉对 RAG 定义都不同大家在各谈各的？
又不是非得加 embedding 然后向量搜索才叫 rag ，通过外部信息搜索最后注入 context 用于增强回答的都算 rag 啊，你用向量是 rag ，你直接 grep 搜文件也是 rag ，你 bm25 搜关键词还是 rag ，你把资料放图里然后搜图依然是 rag ，甚至你把这些步骤交给 agent 来自由选择组装叫 agentic rag
只不过现在很多人觉得这词不够新， 喜欢叫 context engineering

[Chuckle]

我感觉 rag 作为海量数据时，找出和关键词有相关性的内容，给 ai 去读还是有用的，不需要什么准确度，找到了全塞给 ai 自己判断。不然上下文不够