长上下文任务、编程、推理与创意写作是否应使用相同的基准？

为什么不能只用一种基准测试来评估所有长上下文任务？

根本原因在于，当前的大语言模型在处理长文本时表现得出奇地糟糕，且其失败的具体方式因任务类型而异。2024年的一项研究[4]在LooGLE基准测试（包含超过24000个词元的文档）上评估了多个模型，发现大多数大语言模型存在“惊人的长文本能力缺陷”——即便其上下文窗口足以容纳整篇文档，它们仍无法捕捉长距离依赖关系。这意味着，一个模型或许能完美回答简短推理问题，却完全遗漏埋藏在故事两万个词元深处的关键事实。若用同一基准测试来评估编程、推理和创意写作任务，你便会错过这些因任务类型而异的失败表现。

一项2025年关于长代码理解（LongCodeU）的研究[5]发现，当代码长度超过32,000个token时，大语言模型的性能急剧下降，远未达到其声称的12.8万至100万token的上下文窗口能力。最具挑战性的方面是“跨代码单元关系理解”——本质上，这需要将大型代码库中的不同代码片段关联起来。这与总结一部长篇小说或回答科学论文问题等技能截然不同。若用单一基准测试将这些任务混为一谈，就会掩盖一个事实：某个模型可能在长文档问答中表现尚可，但在长代码推理上却糟糕透顶。

当前基准测试揭示了任务类型之间的哪些差异？

每个基准测试都揭示了独特的挑战。就长文本理解这一普遍问题而言，2024年发布的LongBench[1]——首个双语多任务基准测试——在21个数据集上评估了8个大语言模型，结果发现即便是表现最好的商业模型（GPT-3.5-Turbo-16k）在处理较长上下文时也力不从心。诸如检索等上下文压缩技术虽能帮助较弱模型提升表现，但仍落后于具备强大长文本处理能力的模型。这表明“长文本理解”并非单一技能，而是一系列因任务而异的综合能力。

具体到编程领域，2025年的YABLoCo基准测试[2]专注于在大型C/C++代码库（20万至200万行代码）中生成函数体。这与回答关于50页文档的问题截然不同。该基准测试包含调用图和依赖上下文——这些内容与创意写作或推理无关。同样，2025年的LongCodeU基准测试[5]发现，跨代码单元的关系理解是最困难的方面，而这一任务在大多数长文档问答基准测试中根本不存在。

在长上下文推理与信息检索方面，2025年俄语基准测试[3]将任务按复杂度分为四个等级，最长支持128K token，涵盖信息检索、知识抽取与推理。这表明，即便在“长上下文”范畴内，难度也会随上下文长度和任务类型而变化。一个能从128K文档中检索出事实的模型，可能仍无法对同一文档的多个部分进行跨段推理。

那么，基准测试的设计者应该怎么做呢？

大量证据表明，基准测试应针对具体任务。2024年的LooGLE研究[4]明确呼吁增强“真正的长上下文理解能力”，而非仅仅扩大上下文窗口——这需要设计能够测试长距离依赖关系、而非仅考察短程记忆的基准测试。2025年的LongCodeU研究[5]也呼应了这一观点，指出模型声称的上下文窗口（12.8万至100万词元）具有误导性，因为在代码任务中，模型性能远未达到这些极限时便已显著下降。

在实践中，这意味着：使用专门的编码基准（如YABLoCo [2]或LongCodeU [5]）来评估代码生成与理解能力；采用长文档问答基准（如LongBench [1]或LooGLE [4]）来测试阅读理解与推理能力；并针对创意写作设计独立的测试（需评估长文本中的连贯性、情节一致性和风格——这些方面现有基准均未覆盖）。单一基准过于粗糙，无法揭示这些关键差异，且很可能因任务组合不同而高估或低估模型能力。

关于这些来源

该回答基于5篇经同行评审的研究——发表于2024年至2025年，其中5篇为2024年或之后发表，共被引用98次——这些研究是从通过质量筛选的5项研究中选出的最相关成果，而该筛选过程则源于从超过5亿篇论文的数据库中检索到的34篇文献。

本文引用的文献

相关研究问题