[Paper] 层次评估 Large Language Models of Code 的软件设计能力

Source: arXiv - 2511.20933v1

概览

大型语言模型（LLM）已经成为开发者常用的助手，但它们对核心软件设计原则——尤其是内聚性（模块内部各部分关联紧密程度）和耦合性（模块之间相互依赖程度）——的真实理解程度仍是一个未解之谜。本文系统地、分层地评估了 DeepSeek‑R1 系列（14 B、32 B、70 B 参数），揭示了这些模型的优势、短板以及对实际编码工作流的意义。

关键贡献

• 设计推理基准 – 通过程序化生成的一套“设计不良”代码片段，专门针对内聚性和耦合性违规进行测试。
• 多层级评估协议 – 三种任务模式（验证、引导、开放式生成），逐步降低外部指导，模拟真实开发者交互。
• 噪声鲁棒性分析 – 系统注入干扰代码和注释，以测试模型对无关上下文的抗干扰能力。
• 不对称经验发现 – 结果表明，在嘈杂的开放式条件下，耦合推理会急剧崩溃，而内聚性分析相对稳定——但在没有任何指导的情况下，两者都会下降。
• 追踪级诊断 – 利用模型内部的推理轨迹，发现耦合推理存在“认知捷径”，而内聚性推理虽较为详尽（但仍易出错）。

方法论

1. 合成代码生成 – 作者构建了一个生成器，创建带有刻意设计缺陷的小程序：低内聚（无关函数混在一起）和高耦合（模块间依赖紧密）。
2. 任务层级
   • 验证 – 模型收到代码片段和是/否问题（“该模块是否具有内聚性？”）。
   • 引导 – 模型被提示解释为什么该片段具有内聚或耦合，并获得逐步提示。
   • 开放式生成 – 模型必须在没有任何显式提示的情况下重写或重构代码以改进设计。
3. 上下文噪声 – 随机插入无关函数、注释或变量名作为干扰，模拟开发者常遇到的凌乱文件。
4. 指标 – 分类任务使用标准的精确率/召回率/F1，生成式重构使用 BLEU‑style 分数。
5. 推理轨迹分析 – 解析 LLM 的链式思考输出，观察模型是遵循逻辑的设计分析路径，还是直接猜测。

结果与发现

• 内聚性：即使存在干扰，引导任务的 F1 仍保持在 0.85 以上，下降幅度有限。
• 耦合性：在开放式设置下，噪声出现时 F1 下降超过 50%，表明推理脆弱。
• 模型规模影响：70 B 模型始终优于小模型，但内聚与耦合之间的不对称现象在所有规模上均存在。
• 轨迹分析：耦合推理时，模型常跳过详细的依赖检查（“捷径”），仅凭表面线索猜测；内聚推理则会枚举函数职责，但在缺少指导时仍会漏掉细微违规。

实际意义

• 代码审查助手 – LLM 能可靠地标记明显的内聚问题（例如同文件中出现无关函数），即使在杂乱的代码库中，也可作为第一轮审查工具。
• 自动重构工具 – 现有模型尚不足以在生产代码库中自主完成耦合降低（如抽取服务、解耦模块），仍需人工监督。
• 提示工程 – 提供结构化、逐步的引导显著提升耦合推理的可靠性。团队可在 IDE 插件中嵌入“引导”提示，以增强模型表现。
• 噪声处理 – 真实代码常包含死代码、注释和遗留片段，开发者应在将代码喂给 LLM 前进行预过滤或上下文窗口管理。
• 模型选择 – 更大的模型略有优势，但根本的设计推理差距是架构层面的，而非单纯参数量问题。

局限性与未来工作

• 合成偏差 – 基准依赖生成的代码模式，可能未覆盖真实世界设计异味的全部多样性。
• 单一模型族 – 仅评估了 DeepSeek‑R1 系列；其他 LLM（如 GPT‑4、Claude）可能表现不同。
• 仅限静态分析 – 未考虑运行时耦合行为，限制了对性能关键系统的适用性。
• 未来方向 – 扩展数据集至开源项目，探索多轮交互式调试会话，并结合外部静态分析工具以增强 LLM 推理。

作者

• Mootez Saad
• Boqi Chen
• José Antonio Hernández López
• Dániel Varró
• Tushar Sharma

论文信息

• arXiv ID: 2511.20933v1
• 分类: cs.SE
• 发布日期: 2025 年 11 月 25 日
• PDF: Download PDF