RAG过气了吗

看怎么理解吧，说过时的是那种以前模型量小，通过rag来实现提升模型的知识量的。但是rag这个技术本身是不会过时的，在一些私人文档的检索里还是能发光发热的

感觉是 RA 但是不需要 G 了

也不是过时了 就是变成成熟技术了 没有什么好再宣传的 也没有更多想象力了

你看RAG刚火的那阵子 什么无限上下文之类的都来了

但是实际落地 还是外挂知识库

就像现在也没说在聊倒排索引 es/solr之类的了 都是稳定的技术了

不会过期，Agent需要查资料或者上下文需要载入相关的内容的时候就可以考虑接入检索召回。

私域知识库RAG算最简单的解决方案了吧

怎么可能过时，我现在就做了一套团队的文档+代码rag知识库，文档越多，rag价值就越大！

不会啊RAG不是过气了，是效果提升很难，现在大家都在找提升效果的方法

RAG很长一段时间内都不会过时，很难想象一种技术能做到比检索更便宜的获取外部知识。

但是等各个业务部门把自己的RAG pipeline搭好了，相关需求自然也会减小

RAG是成本的妥协说是……

不过 RAG 原理的进化似乎没有跑过小模型 Agent

有些人说 RAG 已经过时了，有些人还在用。佬们，现在主流技术是啥

我个人认为RAG技术并不是过时了，佬友同学表达的【RAG已经过时了】这个看法有些片面。

传统RAG的应用，大概是这样的路线： 分块 -> 向量化 -> 相似度检索 -> 丢给LLM。当前的各种各样模型支持长上下文之后，确实有很多人认为直接将资料作为prompt，而不在需要RAG了。这样做并非不行，但是会带来新的问题：

1. 超长上下文，带来的大量token消耗，token成本直线上升；


2. 高额的token又导致首字延迟的时间变久，时间成本也变得更高，而且对于一些要求实效性的任务，是否能在实效性内给出结果，有时这也是优先级较高的问题。


3. 超长上下文中，内容冗杂，如果没有经过提炼，可能模型的注意力会有偏差。

所以我认为技术的更新，有的时候并不是完全抛弃旧的技术，而是将RAG和长上下文的优势相互融合。

应该没过时吧，只是感觉应用场景有些单一，感觉只有做产品或者内容的知识库会用到

只是几乎成为标准件了，而且模型上下午越来越长了

向量数据库有些地方还能有点用，但是如果是切块的那种传统方式，那确实过时了，还远不如grep