type
status
date
slug
summary
tags
category
icon
password
comment
2025.4.1 今天开始需要把之前做的模棱两可的实验系统化做出来 然后论文开始撰写了，这个文章记录一下实验及结果 2025.4.22 论文投稿至arXiv 2025.5.30 论文投稿至ASE2025
实验规划
注意：使用一套prompt，只不过添加不同的信息进去
- 让大模型对代码的功能进行分析
- 单位时间内消耗token数目，异味代码显著高于干净代码
结论：大模型在处理异味代码的过程中会消耗更多token
思路：如何增强大模型对异味代码的处理效率
- 模拟实际开发场景：先对clean code和smelly code分别进行提取User Story再生成代码的过程
- 对clean code和smelly code抽取User Story再生成新代码
- 记录输入token、输出token、总token、代码行数
- 记录生成每一部分的内容所需时间
- 计算单位时间内处理的token
- 抽取一些token异常的例子观察
结论：大模型在处理异味代码的过程中单位时间内会消耗比干净代码更多token
思路：如何增强大模型对异味代码的处理效率
- 对于smelly code进行处理(baseline)：
- 先对原代码进行重构，保存生成的代码，然后计算生成代码的复杂度、token消耗
- 然后再次进行抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 交叉验证User Story的等效性
- 再次对比smelly code和这一次生成的新代码的单位复杂度上token消耗
- 异味类型对token影响(探索大模型对于哪些异味比较敏感/不敏感)
- 对于每种异味使用50条数据
- 先直接进行抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 再进行重构以后抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 交叉验证前后User Story的等效性
- 计算每种异味前后token增长率，计算每种异味的均值
- 测试对模型提示"这段代码存在[异味类型]"是否会影响生成效率
- 对比显式提示异味 vs 仅提供原始代码的效果差异
- 在prompt中加入显示提醒异味，然后进行抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 交叉验证User Story的等效性
- 对比1中的结果和本步骤的结果，从而探索知识蒸馏对模型的影响
- 对于smelly code做如下操作(探索减少token的方式)：
- 在不添加任何信息情况下抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间（第1步）
- 在添加代码相关信息情况下抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间 context awareness
- 在添加角色限制情况下抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间 responsibility tunning(3个)
- Developers / Software Engineers
- QA Engineers / Automation Testers
- DevOps Engineers
- 在添加生成字符数限制情况下抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间 cost sensitive
- 在添加代码相关信息、角色限制和生成字符数情况下抽取User Story并生成新代码，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 交叉验证和原来第1步中smelly code的User Story的等效性
- 对比以上过程单位复杂度上消耗token的平均值
- 整个流程User Story对代码生成的复杂度的影响
- 存在User Story比较简短，但是代码过长或复杂度过高的状况出现
- 可能是模型自动脑补一些信息进去
- 在5过程中，逐步观察生成代码复杂度变化
验证： 1. Control Flow Graph / Data Flow 分析：比较控制流图、数据流图，甚至做一部分2. 如果目标场景里，有一些“关键性逻辑”或“关键节点”（如数据库操作、网络调用、关键算法等），只要这个核心调用逻辑不变，就视为功能等价；否则就不合格。 3. 让模型同时生成新的 docstring，描述自己实现了哪些功能、处理了哪些边界情况。然后比对是否与原 docstring 要求一致。 4. codeXGLUE指标验证
实验流程
PS：数据集获取
- 利用codeXGLUE中Text-To-Code的dataset，提取其中的java代码，利用tree_sitter进行异味代码提取，共十种类型的异味代码，均来源于工程项目complicated_regex_expression.jsonl、parameter_list_too_long.jsonl、binary_operator_in_name.jsonl、cyclomatic_complexity.jsonl、loops.jsonl、primitive_obsession.jsonl、complicated_boolean_expression.jsonl、func_name.jsonl、mutation_too_much.jsonl、too_long.jsonl，没有异味的代码提取为baseline.jsonl
- smelly_code.jsonl来源于十个异味代码数据集中每一个提取30条组成，共300条，clean_code.jsonl来源于baseline.jsonl提取300条
一、观察类实验
- 利用deepseek-r1推理模型对clean_code.jsonl和smelly_code.jsonl中每一条数据中的”code”字段进行多方面分析：
功能正确性、可读性、健壮性、可维护性、可扩展性、安全性
- 记录全过程时间以及token消耗，并计算单位时间内token消耗作为评价指标
- 结果是smelly_code单位时间内消耗token要比clean_code更多
- 结论：大模型理解分析异味代码要消耗更多token，处理效率低
二、探究性实验
1. 对于下面实验采用的链路为
- Natural Language + code —— To —— Requirements —— To ——Generated code
- 以下简称“链路处理”
- 代码等效性评价（主要为了确保功能一致性）：
- 利用codeBLEU进行评价
- 交叉验证：利用qwen-2.5-max大模型提取code和generated_code的docstring，描述自己实现了哪些功能、处理了哪些边界情况，然后利用
paraphrase-MiniLM-L6-v2进行语义相似性比对
- baseline（smelly code消除bad smell后作为baseline)
- 对于smelly code先利用deepseek-r1进行重构消除异味，记为rf_code
- 然后对于rf_code采用链路处理
- 记录全过程消耗的token数目，并计算其Halstead复杂度以及圈复杂度
- 计算单位Halstead复杂度token消耗数目以及单位代码行数token消耗数目作为评价指标
- 代码等效性评价，比较rf_code和code
- 对比原始代码
- 使用smelly code中的code进行链路处理
- 记录全过程消耗的token数目，并计算其Halstead复杂度以及圈复杂度
- 计算单位Halstead复杂度token消耗数目以及单位代码行数token消耗数目作为评价指标
- 对比和baseline的指标
- 代码等效性评价，比较rf_code和code
- 结论：重构后的代码在功能评分达到75%的水平下token消耗降低了50%
- 异味类型的影响
- 采集从10个smelly code数据集中每个抽取50条形成smelly code，共500条
- 分别进行直接链路处理和重构后链路处理
- 分别记录全过程消耗的token数目，并计算其Halstead复杂度以及圈复杂度
- 分别计算单位Halstead复杂度token消耗数目以及单位代码行数token消耗数目作为评价指标
- 分别代码等效性评价
- 直接链路处理组：代码等效性评价，对比code和generated_code
- 重构链路处理组：代码等效性评价，对比code和rf_code、code和generated_code、rf_code和generated_code
- 结论：设计类和结构类异味对于token消耗影响比命名类异味要大
- 显示提示异味类型
- 对比显式提示异味 vs 仅提供原始代码的效果差异
- 在prompt中加入显示提醒异味，然后进行链路处理
- 分别记录全过程消耗的token数目，并计算其Halstead复杂度以及圈复杂度
- 分别计算单位Halstead复杂度token消耗数目以及单位代码行数token消耗数目作为评价指标
- 分别进行代码等效性评价：对比code和generated_code
- 对比baseline中的结果和本步骤的结果，从而探索知识蒸馏对模型的影响
- 结论：在功能评分达到75%的水平下token消耗降低24.5%
- 探索减少token的方式：
- 在不添加任何信息情况下链路处理，并计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 在添加代码相关信息情况下链路处理，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间 context awareness
- 添加code context：path、repo
- 添加code function：docstring、func_name
- 在添加角色限制情况下链路处理，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间 responsibility tunning(3个)
- Software Engineers
- QA Engineers
- DevOps Engineers
- 在添加生成字符数限制情况下链路处理，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间 cost sensitive
- absolute limitation
- relative limitation
- 在组合上面三种手段，进行链路处理，计算新代码的复杂度、token消耗以及生成每一部分内容所需时间
- 代码等效性评价：code和generated_code
- 对比以上过程单位复杂度上消耗token的平均值
- 结论：采取上面的手段后在保证功能性评分75%水平下token消耗有2%～25%不同程度降低，证明手段有效
- 单位时间 token 消耗量
名称：Time-Scaled Token Consumption
说明：该指标衡量模型在单位时间内消耗的 token 数量，是评估模型推理效率的关键指标。
- 单位复杂度下 token 消耗量
名称：Complexity-Normalized Token Consumption
说明：该指标基于代码的 Halstead 或圈复杂度，衡量在单位复杂度下的 token 消耗情况，用于分析模型在处理不同复杂度代码时的推理负担。
- 单位代码行数上 token 消耗量
名称：Line-Scaled Token Consumption
说明：该指标衡量每行代码的平均 token 消耗，是评估模型在不同代码规模下推理效率的标准化度量。
- 重构前后 token 差异量
名称：Token Consumption Delta After Refactoring
说明：该指标表示代码重构前后 token 消耗量的差异，帮助量化重构优化对模型推理效率的提升。
2025.4.21 论文第一稿完成！
2025.4.22 论文投至arXiv
- 作者:Samuel Hu
- 链接:http://www.hjw-aihub.cn/research/my-paper-1
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
