长上下文任务里，模型表现差在哪？
-
长上下文听起来像万能解法，但实际用下来，它的问题也很明显：能塞进去，不等于模型真的会用好。
常见翻车点有几个：
- 前面给的信息被后面冲淡
- 模型抓住了显眼段落，忽略了关键小字
- 多文档之间的冲突没处理
- 问题问得太泛，它不知道该看哪里
所以长上下文任务里，我不建议直接把几十页材料扔进去让模型“总结一下”。更好的做法是先让它建立目录感：
- 先列文档结构
- 标出和问题相关的章节
- 再围绕这些章节回答
- 最后要求引用依据
如果是企业知识库，长上下文也不一定替代 RAG。长上下文适合一次性读材料，RAG 适合长期、可更新、可检索的知识系统。
我的判断是：长上下文提高了上限，但没有取消信息组织能力。材料越长，越需要你帮模型建立路标。
-
长上下文听起来像万能解法，但实际用下来，它的问题也很明显：能塞进去，不等于模型真的会用好。
常见翻车点有几个：
- 前面给的信息被后面冲淡
- 模型抓住了显眼段落，忽略了关键小字
- 多文档之间的冲突没处理
- 问题问得太泛，它不知道该看哪里
所以长上下文任务里，我不建议直接把几十页材料扔进去让模型“总结一下”。更好的做法是先让它建立目录感：
- 先列文档结构
- 标出和问题相关的章节
- 再围绕这些章节回答
- 最后要求引用依据
如果是企业知识库，长上下文也不一定替代 RAG。长上下文适合一次性读材料，RAG 适合长期、可更新、可检索的知识系统。
我的判断是：长上下文提高了上限，但没有取消信息组织能力。材料越长，越需要你帮模型建立路标。