关于吹爆DS捞针能力下我对企业级RAG的思考

问题描述：

叠甲:
企业级RAG开发初学者, 还是有很多我不太明白的地方, 不吝赐教!

这两天高强度刷L站发现大家对于DS长上下文能力的赞誉,我现在对我当前在做的企业级RAG产生了巨大的怀疑…
当前我的RAG大量是基于适配短上下文而建立的,写了超级多的分段逻辑/向量化流程等,那现在我怀疑,如果上下文捞针能力足够强,是不是说,我可以只针对文章的总结做向量化查询,然后整篇文档md塞进去,直接让DS去找就合适呢? 这样可以说简化了我大量的前期处理流程.

各位我思路错了, 看我核心问题其实还是RAG录入和查询的问题, 正确的思路看我回复里大佬的帖子, 我觉得解决了我所有的疑问

网友解答：

---

--【壹】--：

长上下文全塞进去，那意味着更烧钱啊，塞进去的大部分都是无关的
厂商：最喜欢这种用户了

---

--【贰】--：

我也是做 RAG 的，只要 token 还贵，实时性要求还高，naive RAG 就还有价值。
用户就问个简单问题，你在那又是调工具又是路由的，成本又高，等待时间又长，最后的结果也不一定比直接答好————况且Agentic RAG 还得考虑 Agent 本身就是一个不完全可控的东西，你也不可能直接拿顶级闭源模型随便给用户用吧？只有“深度研究”这种功能才会考虑这条路线，那又是另外的场景了。graph RAG 这类主要也是把时间成本从线上转嫁出来，在索引的时候就先把关系建立好。
直接塞上下文更是不可能，光付出额外的 token 成本就没法过 “为什么不用 RAG” 的拷问

---

--【叁】--：

再怎么样 ds 上下文也才 1m，能塞多少 rag 文档进提示词呢

---

--【肆】--：

我想起去年qwen新出一个向量模型，一些RAG优化很久的功能还不如一个模型迭代优化

---

--【伍】--：

主要是成本吧，你要是真的塞一本书进去，网页端免费当然不心疼，但是直接进入上下文那都是实打实的token啊!

---

--【陆】--：

我完全可以把文档目录先塞进去做第一轮LLM查询,或者用老方法关键字查询可能都行,因为毕竟我这个场景都是专业文章和术语, 然后第二轮再把具体md再塞进去, 法律法规单篇长度转成md的话其实并不大

---

--【柒】--： 最近对rag的一些想法和实践 开发调优

去年这会儿，大家都在搭rag，从dify, coze到ragflow，但是经常会遇到一个问题，demo好整，但是效果嘛，不好说。现在已经有一些解决方案，比如用easydataset做qa对，用Hyde扩展回答的范围，用RAG去扩展问题的范围。但是还是有一个我认为不能理解的，那就是向量相似度不等于语义相关性。如果不做qa对，仅仅按chunk切分，会导致什么问题呢，三重语义断裂——代词指代丢失、跨句依…

有同样疑问的可以看下这篇, 还得是大佬.

---

--【捌】--：

我的场景主要不是专业问答, 完全可以在后台慢慢跑, 重点是可溯源

---

--【玖】--：

慢慢跑且强调准确性和可溯源，如果也不是很在意成本，可以参考 pageindex 的思路