长上下文模型出来以后，RAG 还有必要吗？

[小风扇]

简单不等于可靠。长上下文解决“放得下”，没解决“找得准”和“证据可控”。

[小树]

但 RAG 调参很烦，切块、向量库、rerank 都是坑。

[林小北]

是坑，所以要看场景。10 页项目说明直接塞上下文可以；几千份制度不行。

[nora]

Lost in the Middle 那篇提醒过，长上下文里信息位置也会影响模型使用。不是塞进去就等于读懂。

[阿航]

长上下文成本也要算。每次把大文档塞进去，延迟和费用都上去。

[MingK]

还有权限。你不能为了省 RAG，把用户无权看的文档也一起塞给模型。

[半糖]

我反而觉得长上下文能减少切块复杂度。先检索章节，再给大段上下文。

[小路灯]

这个我同意。RAG 和长上下文不是二选一，可以检索少量大块。

[rootless]

最怕把长上下文当垃圾桶。日志、历史聊天、文档全塞，最后不知道模型依据什么答。

[米饭]

我们做会议纪要问答，单会 2 小时转写直接塞效果不错。跨项目知识库还是 RAG。

[小键盘]

所以边界是资料规模、更新频率、权限和引用要求？

[小风扇]

对，还有成本和可解释。企业里“为什么这么答”比“能不能答”更重要。

[林小北]

别把技术路线变宗教。短资料长上下文，长期知识 RAG，关键事实结构化。

[nora]

这句比较准。生产系统通常是混合，不是单一招式。