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

[murongxdb]

看了一下大家的回复，使用 RAG 大都是建立在海量文本的情况下，而且貌似坑比较多，一般通用 Agent 大概率用不到 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 确实没必要