Page 261 - 《软件学报》2026年第5期
P. 261

2140                                                       软件学报  2026  年第  37  卷第  5  期


                    由此构建实验的参数空间, 该空间包含              1 875  个候选模型与解码参数的组合. 大语言模型公共推理云平台
                 Together AI Platform [39] 支持用户对多种大语言模型调用推理服务, 同时提供了包括           temperature 等一系列的解码参
                 数供用户选择, 本文选择该平台进行代码任务的推理. 为探讨                  CodeLLMTuner 对不同种类代码任务进行代码大模
                 型选择与解码参数调优的能力, 本文选择代码生成、代码摘要与测试用例生成这                          3  项代码任务作为目标任务并为
                 其构建性能空间, 此      3  项任务覆盖了代码任务的不同类型.
                    代码生成任务: 该任务属于“文本-代码”类型的代码任务, 要求代码大模型基于用户所提出的代码需求描述生
                                                 [1]
                 成满足需求的代码. 本文选择         HumanEval 作为  Benchmark, 该数据集中的各项问题均由人工编写, 是代码生成任
                 务性能评估最为常用的数据集, 有一定的权威性. 为验证输出代码是否正确, 当前通常使用                           pass@k 表征模型性能,
                 该方法要求代码大模型为         Benchmark  中的每个任务生成     n  段代码, 计数通过单元测试的代码数量           c, 最终通过公
                 式  (1) 计算每个任务的分数, 其平均值即为代码大模型在              Benchmark  上的性能.

                                                                C k n−c
                                                     pass@k = 1−   .
                                                                 C k
                                                                  n
                    对于  k 的取值, 考虑到模型选择与参数调优目标是在有限的成本下为特定类型的数据集高效地选择更优的模
                 型和参数, 应侧重于代码生成次数较少时的任务场景. 因此本文选择                     pass@1  以衡量模型在首次代码生成时的性
                 能表现, 选择   pass@4  以衡量模型在生成次数较紧凑时的性能表现, 以及选择                 pass@10  以衡量代码生成更多次时
                 模型的性能表现. 而更大的        k 值通常代表了成本极为充裕情境下的表现, 对研究问题的指导意义较为有限且计算
                 成本极高. 因此, 本文省略了更大的         k 值场景下的实验, 而将精力集中在更具现实应用价值的代码生成次数较少的
                 情境下, 即选择    pass@k (k=1、4、10) 作为性能评价指标, 以体现模型在不同代码生成次数下的泛化能力.
                    代码摘要任务: 该任务属于“代码-文本”类型的代码任务, 要求代码大模型基于提供的代码片段输出该片段的
                 注释或解释. 为验证输出摘要是否准确, 目前通常使用                BLEU  分数判断代码大模型输出结果与标准结果的相似程
                 度, 用以表征代码摘要任务的执行质量. CodeXGLUE            [40] 提供了一个包括   23 007  个代码摘要任务的    Benchmark, 该
                 数据集收集自     GitHub  并经过了规则筛选与调整, 本文从中随机选择             1 000  项作为本实验的    Benchmark. 虽然部分
                 代码摘要的工作采用人工审查以更准确地验证自动生成的摘要是否准确反映了代码的功能与逻辑, 然而模型选择
                 与参数调优场景通常需要数十乃至上百个采样点以充分刻画性能分布, 人工审查成本过高, 且参数调优方法大多
                 采用迭代方法进行采样, 人工审查可能引入人为干扰影响算法实现进而影响实验可靠性, 因此本文选择                                  BLEU_1
                 与  BLEU_2  作为性能评价指标以自动化评估推理结果.
                    测试用例生成任务: 该任务属于“代码-代码”类型的代码任务, 要求代码大模型基于提供的代码片段输出该片
                 段对应的测试用例, 该任务通常使用生成测试用例的分支覆盖率和行覆盖率评价代码任务完成质量. 不同程序语
                 言的覆盖率测试方法有所不同, 如对于            Python  语言的测试用例, 当前通常使用        pytest 和  slipcover 库进行测试; 对
                 于  JavaScript 语言, 可采用  Mocha 和  Istanbul 工具进行覆盖率测试. CodaMosa [41] 经过对多个第三方  Python  库的扫
                 描与  MOSA  测试提供了一个用于生成测试用例的             Benchmark, 本文选择针对   Flask  库的  Benchmark  进行实验.
                    本文选择并使用了现有的数据集进行性能评估, 虽然大模型可能已经学习过这些数据集中的部分数据, 实验
                 结果可能会高估模型的性能. 然而, 即使存在数据泄露, CodeLLMTuner 与基线方法的对比仍然具有意义, 因为所
                 有基线方法都是在相同的候选模型上进行参数调优. 此外, 数据泄露是领域内的普遍问题, 相关文献也表明通过使
                 用权威评测集可以在一定程度上减轻其影响.
                  3.2   基线方法
                    考虑到模型选择与参数调优过程需要同时用到                 CPU  与  GPU  资源, 难以使用单独一种资源概括该过程的总成
                 本, 而迭代次数是参数调优算法中衡量成本的常用指标. 因此为便于衡量模型选择与参数调优过程总成本, 本文使
                 用该过程中进行“采样-评估”的迭代次数作为成本的衡量标准. 具体来说, 各基线方法在选择最优模型与参数时,
                 对多少模型与参数组合进行了代码任务推理与性能评测. 这种定义能够反映模型选择与参数调优的计算开销, 同
                 时确保实验的公平性和可复现性. 本节假设代码大模型选择与解码参数调优的总成本为                             I, 模型数量为   |M|.
                    DivBO [25] : 作为  CASH  方法, 该方法将多个代码大模型的解码参数空间重组为一个组合参数空间, 并在其中采
   256   257   258   259   260   261   262   263   264   265   266