我看到很多模型都支持很长上下文，是不是可以把所有产品文档、历史聊天、用户资料一次塞进去，省掉 RAG？

]]>https://localaihub.com/topic/80/长上下文不是资料越多越好RSS for NodeWed, 03 Jun 2026 18:50:44 GMTMon, 04 May 2026 19:01:00 GMT60对，最好把“引用了哪段资料”显示给内部审核。长上下文错了也要能追。

]]>https://localaihub.com/post/483https://localaihub.com/post/483Tue, 05 May 2026 11:18:00 GMT明白，长上下文当能力上限，不当架构方案。我们先保留 RAG，只把单份大文档问答走长上下文。

]]>https://localaihub.com/post/482https://localaihub.com/post/482Tue, 05 May 2026 09:49:00 GMT可以做两层：检索 Top 8，压缩成可引用事实，再让长上下文模型综合。这样不浪费窗口。

]]>https://localaihub.com/post/481https://localaihub.com/post/481Tue, 05 May 2026 08:11:00 GMT系统提示和安全边界不能被业务上下文挤掉。预算应该先给指令、工具协议、用户当前问题，再给证据。

]]>https://localaihub.com/post/480https://localaihub.com/post/480Tue, 05 May 2026 06:48:00 GMT我见过一个误区：把 RAG 检索到的 20 段再加全量聊天记录，最后 token 爆掉，只能截断系统提示，灾难。

]]>https://localaihub.com/post/479https://localaihub.com/post/479Tue, 05 May 2026 06:32:00 GMT单文档推理、跨章节对照、要保留原文语境时。多文档知识库、频繁更新、权限过滤，RAG 更稳。

]]>https://localaihub.com/post/478https://localaihub.com/post/478Tue, 05 May 2026 05:19:00 GMT那长上下文什么时候比 RAG 好？

]]>https://localaihub.com/post/477https://localaihub.com/post/477Tue, 05 May 2026 04:15:00 GMT做历史摘要时要保留状态，不是保留所有原话。比如“当前诉求=开票，已确认抬头，未确认税号”。

]]>https://localaihub.com/post/476https://localaihub.com/post/476Tue, 05 May 2026 01:56:00 GMT我更怕历史聊天。用户前面说“不要发票”，后面又说“要发票”，全塞进去模型可能两边都引用。

]]>https://localaihub.com/post/475https://localaihub.com/post/475Mon, 04 May 2026 23:40:00 GMT是优势，但优势是能处理更长输入，不是免疫信息噪声。长材料里有过期政策，模型也会认真引用。

]]>https://localaihub.com/post/474https://localaihub.com/post/474Mon, 04 May 2026 22:21:00 GMT但 Kimi 这类长上下文不是优势吗？

]]>https://localaihub.com/post/473https://localaihub.com/post/473Mon, 04 May 2026 21:45:00 GMT长上下文适合“少量长材料”的精读，比如合同、会议纪要、单份手册。知识库长期问答还是要检索和结构化。

]]>https://localaihub.com/post/472https://localaihub.com/post/472Mon, 04 May 2026 21:02:00 GMT我们试过把 180 页 PDF 直接塞给长上下文模型，问第一章还行，问中间表格就开始编。

]]>https://localaihub.com/post/471https://localaihub.com/post/471Mon, 04 May 2026 20:24:00 GMT理论上能塞，不等于应该塞。长上下文贵、慢，而且模型不一定从后半段稳定拿到关键句。

]]>https://localaihub.com/post/470https://localaihub.com/post/470Mon, 04 May 2026 19:14:00 GMT