[Paper] 大语言模型在长上下文代码问答中的鲁棒性与推理保真度

Source: arXiv - 2602.17183v1

概述

本文研究了当今大型语言模型（LLM）在处理 长上下文 时（例如数千行源文件、混合语言项目或遗留代码库）对代码推理的能力。通过系统性地修改输入（打乱答案选项、去除多选格式以及加入无关的“干扰”代码），作者揭示了标准基准常常忽视的隐藏脆弱性。他们扩展后的基准现在包括 Python、Java，甚至 COBOL，为依赖 LLM 进行代码审查、调试或自动化辅助的开发者提供了更贴近实际的衡量标准。

关键贡献

• 长上下文鲁棒性研究：首次系统评估 LLM 在代码问答时，当上下文扩展到数千个 token 的情况。
• 受控消融实验：三种压力测试场景——选项顺序打乱的多项选择、开放式回答，以及带有对抗干扰项的“稻草堆中的针”上下文。
• 数据集扩展：在现有 LongCodeBench Python 套件基础上新增 1,200 多条 Java 和 800 多条 COBOL 问答对，覆盖现代和传统语言。
• 实证发现：在上述消融条件下，展示了最先进模型（GPT‑4、Claude、LLaMA‑2）的性能显著下降（最高约 30 % 的绝对下降）。
• 基准发布：公开发布了扩展数据集和评估脚本，以鼓励社区进行更严格的长上下文测试。

方法论

1. 数据集准备

   • 从 LongCodeBench Python 基准（≈2 k 问答对）开始。
   • 精选额外的 Java 和 COBOL 任务，每个任务配有简短的自然语言问题和一组四个多项选择答案。
   • 对于每个任务，上下文包括完整的源文件（通常 >4 k 令牌）以及任何必需的导入或构建脚本。

2. 消融设计

   • 随机选项：随机重新排列四个答案选项，以打破模型可能学习到的位置偏差。
   • 开放式：移除多项选择列表，模型必须自行生成答案字符串。
   • 大海捞针：插入无关代码片段（例如死函数、无关语言模块），增加上下文长度并充当干扰项。

3. 模型套件

   • 评估 GPT‑4（Chat）、Claude‑2、LLaMA‑2‑70B 和一个开源 CodeLlama 模型，全部使用一致的“根据下面的代码回答问题”模板进行提示。

4. 指标

   • 多项选择的准确率，开放式的精确匹配，以及在存在干扰项时对正确答案进行惩罚的鲁棒性得分。

结果与发现

• 仅仅打乱顺序 就导致了 15‑20 % 的绝对下降，表明模型在很大程度上依赖答案位置线索。
• 开放式 生成进一步降低了性能，暴露出在自由形式代码推理方面的困难。
• 干扰代码 导致了最明显的下降；即使是最强的模型（GPT‑4）也在一半的案例中错过了正确答案。
• 这种退化在所有语言中都保持一致，说明问题不仅限于 Python，也同样影响传统的（COBOL）和主流的（Java）代码库。

实际影响

• 工具可靠性：IDE 插件或 CI 集成的 LLM 助手在呈现多选建议时，当答案列表被重新排序或隐藏时，可能看起来比实际更准确。
• 安全与审计：在代码审查自动化中，无关的代码片段（例如生成的文件、第三方库）可能误导模型，导致遗漏错误或产生误报。
• 提示工程：开发者应避免依赖位置暗示；显式标记（例如 “选项 A：…”）和验证步骤变得至关重要。
• 遗留系统支持：COBOL 的包含表明，LLM 尚未准备好在没有额外微调或检索增强管道的情况下进行大规模现代化项目。
• 基准评估标准：评估用于代码辅助的 LLM 的公司应采用扩展的 LongCodeBench 套件（或类似的 “压力测试” 设置），而不是仅使用短上下文、干净代码的基准。

局限性与未来工作

• 干扰因素的规模: 研究使用了固定数量的无关代码片段；真实世界的代码库可能包含数量级更多的噪声。
• 提示的一致性: 所有模型都使用相同的提示模板；探索针对模型的特定提示可能减轻一些脆弱性。
• 未探索微调: 作者评估了即用型模型；未来工作可以评估领域特定的微调或检索增强生成是否提升鲁棒性。
• 缺少用户研究: 论文侧重于自动化指标；后续的用户研究可以阐明这些失败如何转化为开发者生产力的损失。

作者

• Kishan Maharaj
• Nandakishore Menon
• Ashita Saxena
• Srikanth Tamilselvam

论文信息

• arXiv ID: 2602.17183v1
• 分类: cs.SE, cs.AI
• 发表时间: 2026年2月19日
• PDF: 下载 PDF