长上下文不是资料越多越好

[不想写周报]

理论上能塞，不等于应该塞。长上下文贵、慢，而且模型不一定从后半段稳定拿到关键句。

[小满]

我们试过把 180 页 PDF 直接塞给长上下文模型，问第一章还行，问中间表格就开始编。

[nora]

长上下文适合“少量长材料”的精读，比如合同、会议纪要、单份手册。知识库长期问答还是要检索和结构化。

[小傅]

但 Kimi 这类长上下文不是优势吗？

[leaf_1997]

是优势，但优势是能处理更长输入，不是免疫信息噪声。长材料里有过期政策，模型也会认真引用。

[阿宁]

我更怕历史聊天。用户前面说“不要发票”，后面又说“要发票”，全塞进去模型可能两边都引用。

[index_0]

做历史摘要时要保留状态，不是保留所有原话。比如“当前诉求=开票，已确认抬头，未确认税号”。

[小周]

那长上下文什么时候比 RAG 好？

[zeroOne]

单文档推理、跨章节对照、要保留原文语境时。多文档知识库、频繁更新、权限过滤，RAG 更稳。

[郭同学]

我见过一个误区：把 RAG 检索到的 20 段再加全量聊天记录，最后 token 爆掉，只能截断系统提示，灾难。

[林小北]

系统提示和安全边界不能被业务上下文挤掉。预算应该先给指令、工具协议、用户当前问题，再给证据。

[会飞的杯子]

可以做两层：检索 Top 8，压缩成可引用事实，再让长上下文模型综合。这样不浪费窗口。

[半截薯条]

明白，长上下文当能力上限，不当架构方案。我们先保留 RAG，只把单份大文档问答走长上下文。

[小满]

对，最好把“引用了哪段资料”显示给内部审核。长上下文错了也要能追。