Page 114 - 《软件学报》2025年第4期

1520 软件学报 2025 年第 36 卷第 4 期

就在 2023 年 11 月, OpenAI 的开发者大会 [199] 提出了支持 128k 上下文长度 (300 页长度) 的 GPT4-Turbo 模型, 该
模型在很大程度上解决了该领域的主要挑战. 因此我们发现, 目前这些领域很大程度上依赖于模型, 模型的快速迭
代既为当前的研究和实验带来了压力, 也为解决领域内的挑战带来了机遇. 此外, 目前很多研究尝试对开源大模型
进行训练和微调以获得更优的效果, 然而考虑到缩放定律 (scaling law), 即模型的参数规模越大往往性能越强, 主
流开源模型的规模也在逐渐增大. 因此, 在未来尝试对开源模型在软件工程下游任务上进行优化的工作中, 研究者
可能需要对比分析不同模型的效果. 然而由于主流开源模型的参数量庞大, 其实验往往需要占用大量 GPU 计算资
源并耗费大量的时间, 这可能成为基于开源模型工作的关键挑战之一.

6.6 工业实践与落地
对于使用大模型的技术, 面对复杂的任务和需求, 在工业实践与落地方面仍非常有挑战. 我们将在以下几个方
面进行更深入的探讨.
(1) 选择 API 还是 GPU, 尚需讨论
开发人员使用大模型时, 不可避免地涉及公司内部代码数据与模型的交互, 因此, 公司面临核心代码数据泄漏
行的思路和方案. 例如使用大模型自动对待测方法生成单元测试
导致资产损失的风险. 对于规模小, 还在起步阶段的公司, 通过使用目前已经产品化的闭源模型 (如 ChatGPT、
CodeX、GPT-4 等), 可以以极其低廉的价格调用目前最优的模型. 然而任何公司都存在安全风险, 例如 OpenAI 公
司于 2023 年 3 月曾出现泄漏用户对话标题的事件 [200] . 因此, 对于业务复杂, 规模庞大的公司来说, 创建自己的大
模型技术团队并使用本地运行的私有模型就成为必然的选择. 虽然目前业界主流的开源模型性能依旧不如最新的
闭源商业模型, 但是在公司内部, 开发者可以针对公司的代码和任务需求对模型进行训练和微调, 以获得更佳的效
果. 例如在自动修复领域, Jiang 等人 [189] 的研究表明模型在经过缺陷任务数据集微调后性能提升了 31%–1267%,
Xia 等人提出的 FitRepair 技术 [24] 将模型在缺陷项目上进行微调以学习缺陷项目的上下文信息, 进而更好地在项目
上下文帮助下对缺陷进行修复.
(2) 实现完全自动化, 尚需深入研究
目前大多工作都强调其技术实现了完全的自动化, 例如目前的缺陷自动修复技术中的 ChatRepair [57] 和测试用
例生成技术 CHATTESTER [47] . 然而这些基于大模型的工具实际的表现效果和真正工业场景的落地仍有很远的距
离. 在 Defects4J 数据集上, ChatRepair 需要多达 20 轮的迭代才可达到比较满意的修复效果, 然而在实际的工业场
景中, 让规模巨大的软件迭代运行 20 次测试的时间成本和算力成本非常高昂, 近乎不可能. 此外, CHATTESTER
生成的测试用例也仅有 3 成可以通过执行. 并且这些技术最终生成补丁和测试用例的有效性还必须依赖于人工核
验其功能性和完整性. 那么, 对于目前基于大模型的技术而言, 想要完全自动化地完成某一任务仍有非常遥远的距
离. 在可预见的未来一段时间, 基于大模型的工业实践落地项目仍需要开发人员的协助和参与, 在实际中更多可能
是大模型提升开发人员的效率, 开发人员保障模型输出内容的有效性和安全性.
(3) 将复杂任务拆解为简单的重复任务是可行方案
随着大模型能力的快速发展, 研究者越来越迫切地希望模型能处理复杂的下游任务. 但是在实际中, 模型生成
内容具有随机性, 很容易生成一些似是而非的回答或解决方案, 因此无法满足工业场景下对安全性, 稳定性的要
求. 然而, 大模型相较于传统技术非常突出的优点是其生成内容的可读性比较好, 容易被开发者接受. 此外, 大模型
处理简单重复任务的效率和正确率比较优异. 因此, 在工业场景下完全依赖大模型处理复杂任务目前还尚有一段
距离, 但是将复杂任务进行拆分, 使用大模型生成具有初步结构和格式的解决方案以缓解开发者的压力, 是完全可
[136]
, 使用大模型对软件缺陷生成初步的修复模板
代码 [24] , 或者自动根据漏洞报告生成测试用例 [22] . 总的来说, 目前完全信任大模型让其完成复杂任务可能并非明
智之举, 但是可以将复杂任务拆分为重复的简单任务交予大模型处理以帮助开发者提高效率.

7 总 结

本文针对深度学习库缺陷检测、GUI 自动化测试、测试用例自动生成和软件缺陷自动修复这 4 个领域的文