说实话，RAG这个技术，你要是早些时候问我，我会说它特重要，哈哈，那时候感觉不懂 RAG，就不算真的懂 Agent。

但Zui近一年，情况悄悄变了大家开始越来越少提及 RAG 了你有没有这种感觉？咱就是说这事儿挺有意思的。

传统的 RAG 依赖将文本切块，然后通过向量数据库进行相似度匹配，这种方法它Yi无法满足企业级复杂知识应用的需求：

痛点一：难以连点成线 – 多跳推理的瓶颈。

问题描述：用户的复杂查询往往需要答案通过遍历不同信息片段的共享属性才Neng提供综合见解。

例如：询问所有参与了 A 客户项目的团队成员，他们是否在 B 公司的战略报告中被提及？

传统 RAG 的不足：向量检索是基于局部语义相似度的匹配，它擅长找到 A 或 B 的文档，但无法执行多跳遍历来连接两个实体间的复杂路径。

现在呢，直接把所有 tool 的描述全部发给 LLM，让它自己判断用哪个，多花了一点 token，但省掉了整套向量检索的基础设施。

多花一点 LLM token 的费用，远比维护一套 RAG 服务的费用和复杂度要低得多。

你想啊，对于个人开发者，这笔账hen好算：Neng用 tool 解决的，为什么要搭一套 RAG pipeline？

这就导致 toC 的 Agent 产品，天然排斥 RAG，天然偏向 skill/tool。

这个问题，其实跟 RAG 没直接关系，但我觉得Ke以扯一扯。

你有没有想过为什么有些网站的内容不被百度收录？原因可Neng有hen多，比如网站结构、内容质量、robots.txt 配置等等，你得确保你的网站对搜索引擎友好。

还有啊，内容是不是原创，是不是有价值，这些dou是影响收录的因素，不对不对，应该是还有其他因素，比如外链、用户行为等等。

RAG 去哪儿了？它消失了吗？还是说我们的认知需要geng新？

其实RAG 并没有消失，它还在那里只是不再被频繁提及。

toB 的场景中，企业有海量的私有数据，有精确检索的需求，有合规审计的要求，这些特征全部指向 RAG。

但目前还没有出现一个现象级的 toB Agent 明星产品，所以 toB Agent 还在蓄力，还没到爆发的时候。

Zui近kan到一个叫 A-RAG 的技术，据说在 HotpotQA 等数据集上，准确率比传统方法提升了 10-20 个百分点，而且 token 用量geng少！

这说明 RAG 还是有hen大改进空间的，说不定哪天又会重新火起来你懂的。

RAG 提及变少，不代表它没用，而是因为 LLM 越来越强，它Neng直接"内化"的事情越来越多，中间那层"预处理"的必要性就越来越低。

不过比如 toB 应用中，RAG 仍然有它的价值。

所以啊，技术的发展总是这样，不断迭代，不断优化，我们得保持关注，说不定哪天又会有新的突破，哈哈！