长上下文模型是不是可以不用 RAG 了

[小鼠标]

现在好多模型都支持很长上下文了，企业知识库是不是可以直接把文档塞进去，不做 RAG？

[阿航]

先别把长上下文当垃圾桶。它解决“能放多少”，没解决“该放什么”和“怎么验证来源”。

[小风扇]

我反对完全不用 RAG。资料多的时候，先检索再喂模型还是必要的，不然成本和延迟都爆。

[小蓝]

但 RAG 也很麻烦。切块、向量、rerank、权限，全是坑。

[陈一]

所以不是 RAG 必须上，是任务决定。几十页临时合同可以长上下文，几万份制度肯定要检索。

[普通网友A]

长上下文不是越长越聪明吗？

[Grace]

不是。长上下文只代表窗口更大，不代表模型会稳定关注每个细节。位置、重复、冲突内容都会影响答案。

[半截薯条]

我们试过把整本手册塞进去，模型会引用旧条款，因为旧条款也在上下文里。

[nora]

这叫上下文污染。不是资料越多越安全，过期资料混进去更危险。

[小吴]

那怎么判断放多少？

[林小北]

先按任务放。用户问报销流程，就不要把入职、采购、绩效都塞进去。

[melo]

我现在做法是：检索召回一批，rerank 留少量，再把文档标题、更新时间、权限一起进上下文。

[小鼠标]

那长上下文主要适合什么？

[陈一]

适合长文总结、合同审阅、代码仓库片段阅读、会议资料综合。前提是资料集合本身可控。

[阿航]

还有一点：长上下文贵。能用 8k 解决的问题，不要硬上 200k。