长上下文模型是真的理解更多，还是仅仅记住更多？
简而言之：它们大多只是记住了更多内容。多项严格基准测试表明，即使模型的上下文窗口足以容纳整篇文档，它往往也无法回答需要跨文档关联信息的问题[3]。在LooGLE基准测试中（该测试使用超过24,000个词元的文档，并设置需要长程依赖关系的问题），大多数大语言模型在捕捉这些依赖关系时表现“糟糕得惊人”[3]。这意味着模型虽能将文本存入记忆，却无法真正理解其中的关联。
另一项研究L-CiteEval测试了模型是否真正基于所提供的长文本进行回答，还是依赖其预训练知识。结果发现，尤其是开源模型“并不如预期般忠实”——它们常常忽略给定上下文，转而依赖自身已有的知识[2]。这不过是记忆，而非理解。
为何这些模型即便拥有足够的内存，仍无法真正理解？
一个关键原因在于，Transformer中的自注意力机制本应捕捉长距离依赖关系，但在处理长上下文时却变得计算效率低下且冗余。研究表明，注意力权重往往是稀疏的——实际上只有少数几个token对预测有实质性贡献，然而所有token却消耗着相同的计算资源[1]。这意味着模型在无关的token上浪费了精力，并可能遗漏真正重要的关联。
此外，模型的训练和评估方式也可能掩盖其理解能力的不足。许多基准测试采用短文本或仅需局部（邻近）信息的任务，这类任务模型通常能轻松应对。但当面对真正需要长程依赖的任务时——例如回答一个需要整合24,000词文档开头与结尾信息的问题——模型的表现便会大幅下降[3]。在任务平均长度为6,711词的LongBench基准测试中，即便表现最佳的商业模型（GPT-3.5-Turbo-16k）在处理较长上下文时仍显吃力[5]。
长上下文究竟在何时真正有用，谁受益最大？
长上下文主要对需要从大量文本中检索特定事实的任务有帮助，而非用于深度推理。例如，模型能够较好地完成单文档问答（在长文章中查找某个事实），但在多文档问答或需要综合文本中相隔较远部分信息的任务上表现不佳[5]。这种优势也并不均衡：像GPT-3.5-Turbo-16k这样的闭源模型在忠实度（即遵循给定上下文的能力）上显著优于开源模型[2]。
像上下文压缩（例如检索）这类技术，可以通过只向较弱模型提供最相关的部分来帮助它们，但即便如此，其表现仍落后于具有更强长上下文理解能力的模型[5]。因此，实际结论是：如果你需要模型在大量信息中精准定位关键内容，长上下文确实有帮助；但如果你需要它理解整体信息的结构与含义，当前模型仍力有未逮。
关于这些来源
该回答基于5篇经同行评审的研究——发表于2024年至2025年间，其中5篇为2024年或之后发表，累计被引用95次——这些研究是从通过质量筛选的5项研究中选出的最具相关性的成果，而后者又源自从超过5亿篇论文的数据库中检索到的59篇文献。
本文引用的文献
Transformer在长上下文建模中的高维诅咒问题
该论文从理论和实证角度表明，Transformer中的注意力机制具有稀疏性——仅有少数token对预测结果有显著贡献——并提出了动态分组注意力（Dynamic Group Attention）以减少冗余，在保持性能的同时降低计算成本。
$\textit{L-CiteEval}$：长上下文模型忠实度评估套件
L-CiteEval 对11个大语言模型在忠实度（即答案是否基于给定的长上下文）方面进行了评估，发现开源模型明显落后于闭源模型，而生成引用虽有所帮助，但并未完全解决忠实度问题。
LooGLE：长上下文语言模型能理解长上下文吗？
LooGLE基准测试（文档长度超过24,000个token，包含1100多个人工验证的问答对）显示，大多数大语言模型的长上下文能力“糟糕得惊人”，即便其上下文窗口足够大，也无法捕捉长距离依赖关系。
视觉语言基础模型的空间理解与长上下文建模
本论文介绍了用于空间理解的GroupViT，以及一种高效的RNN式TTT层用于长上下文建模，结果表明TTT层在表达能力上超越了现有替代方案，同时对于长达一分钟的视频，其效率高于自注意力机制。
LongBench：面向长上下文理解的双语多任务基准测试
LongBench（包含21个数据集，英文平均6711词，中文平均13386字）发现，GPT-3.5-Turbo-16k的表现优于开源模型，但在处理更长上下文时仍存在困难；缩放位置嵌入和微调可提升性能，而检索虽能帮助较弱模型，但不足以使其与强模型匹敌。