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

刘书宁 等: 基于代码变更语义分析的缺陷隔离方法                                                        2157


                 这种依赖关系通常用于追踪代码中的结构性变更, 例如方法参数的调整影响了方法的调用, 从而指导合并变更代
                 码块.
                    在  DISAC  的初步分解与合并策略中, 我们合并具有以上两种强依赖关系的变更代码块, 避免在后续过程中打
                 破变更的完整性, 从而保持代码的一致性和可编译性.
                  2.3.2    基于大语言模型的拆解

                    给定预合并后的代码变更集合           H 和   H 中的依赖关系  D. DISAC  提出一种基于智能体的变更语义拆解方法, 将            H
                                                                                                      [29]
                 进一步拆解为多个仅包含单一开发活动的子提交集                 C. DISAC  中的智能体系统基于阿里通义大模型           Qwen-turbo ,
                 共包含   4  个角色.
                    ● 决策器. 负责根据输入的       H 和   D 对   H 进一步拆解, 指导大语言模型拆解为子提交集         C = {c 1 ,c 2 ,...,c n }, c i = {h m ,
                 h n ,...,h k }, 并传入评估消息生成器进一步处理与评估.
                    ● 监测器   (优化器). 监测器的核心功能是负责监控输入令牌               (token) 的长度, 由于大语言模型的输入存在长度
                 限制, 为增强方法的适用性, 在将提示输入到决策模型前, 监测器判断                     token  的长度是否超出限制. 如果监测到
                 token  超出限制, 监测器将选择变更代码块        h i  生成变更摘要  , 并令  h i = s i , 即用生成的变更摘要代替原始的变更代
                                                              s i
                 码元素, 从而有效减少       token  长度. 为了达成这一目标, DISAC     制定了如下的     hunk  选择机制指导监测器的操作:
                 (1) 整个文件的增加或删除. 在       git diff 中, 整个文件的增加和删除通常会将该文件所有代码的增删作为一个变更
                 块, DISAC  将其总结为路径变更的摘要, 从而压缩数据量. (2) 整个类的添加或者删除. 当整个类被添加或删除时,
                 DISAC  保留类中各方法的签名, 并生成每个方法的描述, 以替代完整的类代码. (3) 整个方法的添加或者删除. 对
                 于长方法的添加或者删除, DISAC         保留方法签名后, 将具体代码实现转换为方法的描述. (4) 相似更改. 对于涉及
                                                                    h i  中, DISAC  将对其生成变更摘要.
                 相同变量名的重构类更改, 这些更改在预合并过程中已合并为一个
                    监测器会逐步应用上述选择机制, 替代和反馈相关代码元素, 直到                     token  长度符合限制要求. 若通过以上策略
                                                                           h i  直接赋予功能添加的语义, 再将这些
                 仍无法满足需求, 监测器将采用退步策略——将               H  中所有类或方法添加的
                 元素仅根据依赖关系进行拆解. 最后           H  中剩余部分按照交由智能体继续拆分.
                    ● 上下文收集器. 上下文收集器的主要职责是为决策模型提供代码变更的上下文信息, 在代码变更的上下文
                 信息不足时, 补充必要的代码元素信息. 上下文收集器提供了两种可调用的方法: get_deleration_method、get_
                 comment, 分别用于获取特定代码变更所在方法的完整代码, 以及所在类或方法在代码中的注释等描述信息. 这两
                 种方法为决策模型提供了更全面的上下文, 从而帮助其更好地理解代码变更的背景和影响. 上下文收集器的使用
                 由大语言模型根据实际需求自行决策使用, 确保在必要时补充上下文信息.
                    ● 评估消息生成器. 负责对决策模型的拆解结果生成相应描述, 并对这些描述的变化进行评估. 该生成器对                                C
                 中的  c i  生成提交日志  . 对拆分后的每个提交生成具有特定格式的描述作为提交日志. 之后将所有的提交日志返
                                  l i
                 回给决策模型, 并提示其检查是否存在包含多个开发活动的提交日志需要进一步拆分, 或者是否有相似提交日志
                 l i 、 l j  对应的  、 c j  可以合并, 决策模型进一步修改拆分的子提交集. 此外, 评估消息生成器通过对生成的描述文
                           c i
                 本变化的评估, 判断输出是否趋于收敛. 若           k = 3 步内输出没有明显变化, 则终止流程以防止无限迭代; 同时, DISAC
                 设定了最大迭代步骤       h = 10, 当达到此上限时, 模型迭代也将被强制终止. 这一机制有效地平衡了迭代精度与效率,
                 确保评估过程在合理时间内完成, 同时避免了过度迭代带来的资源浪费.
                    为了限制模型的输出以及方便模型理解任务, DISAC                通过构建标准提示       (Prompt) [30] , 为决策模型输入设计提
                 示. DISAC  共有  4  个  Prompt 类别, 包括提交变更分解、变更摘要生成、评估消息生成和评估消息反馈, 下面给出
                 用于本任务的     Prompt, 每个提示均包括任务背景、格式规约、输入信息等内容, {{…}}内的文本是占位符, 在运行
                 时将被替换为     JSON  格式的输入   [31] .
                    ● 提交变更分解. (1) 任务背景: 明确了拆解变更集的任务. (2) 格式规约: 规定了输出为拆解后的多个子提交.
                 (3) 输入信息: 包括具体变更代码和依赖关系. 其           Prompt 模板见图  2.
                    ● 变更摘要生成. (1) 任务背景: 明确了为代码变更生成摘要的任务. (2) 格式规约: 针对不同类型的代码变更,
                 根据选择机制用不同的方式生成摘要. (3) 输入信息: 为具体变更代码信息. 其                   Prompt 模板见图   3.
   273   274   275   276   277   278   279   280   281   282   283