[论文解读] An Empirical Study of Self-Admitted Technical Debt in Machine Learning Software
本研究通过分析318个机器学习(ML)和非ML开源项目,调查了机器学习软件中的自承认技术债(SATD)。研究发现,ML项目的技术债中位数率是非ML项目的两倍,技术债引入更早,且与数据预处理和模型生成相关的债务模式具有显著特征,长期存在的债务通常出现在低复杂度、多文件变更的代码中。
The emergence of open-source ML libraries such as TensorFlow and Google Auto ML has enabled developers to harness state-of-the-art ML algorithms with minimal overhead. However, during this accelerated ML development process, said developers may often make sub-optimal design and implementation decisions, leading to the introduction of technical debt that, if not addressed promptly, can have a significant impact on the quality of the ML-based software. Developers frequently acknowledge these sub-optimal design and development choices through code comments during software development. These comments, which often highlight areas requiring additional work or refinement in the future, are known as self-admitted technical debt (SATD). This paper aims to investigate SATD in ML code by analyzing 318 open-source ML projects across five domains, along with 318 non-ML projects. We detected SATD in source code comments throughout the different project snapshots, conducted a manual analysis of the identified SATD sample to comprehend the nature of technical debt in the ML code, and performed a survival analysis of the SATD to understand the evolution of such debts. We observed: i) Machine learning projects have a median percentage of SATD that is twice the median percentage of SATD in non-machine learning projects. ii) ML pipeline components for data preprocessing and model generation logic are more susceptible to debt than model validation and deployment components. iii) SATDs appear in ML projects earlier in the development process compared to non-ML projects. iv) Long-lasting SATDs are typically introduced during extensive code changes that span multiple files exhibiting low complexity.
研究动机与目标
- 调查机器学习(ML)软件中自承认技术债(SATD)的普遍性及其特征,与非ML软件进行对比。
- 理解技术债在ML流水线不同组件(如数据预处理、模型训练和部署)中的性质与分布特征。
- 分析ML项目中技术债的时间动态,包括引入与解决速率,并识别导致长期债务的影响因素。
- 通过识别ML特有的债务类别(如“测试不足”和“配置”债务)来扩展现有SATD分类体系。
- 利用生存分析与机器学习可解释性方法,探索软件度量与ML代码中SATD持续时间之间的关系。
提出的方法
- 收集并分析了318个开源ML与非ML项目,聚焦源代码注释,使用基于关键词的启发式方法检测SATD。
- 对代表性SATD注释样本进行人工分析,以开发并完善ML特有技术债类别的分类体系。
- 应用Kaplan-Meier估计器进行生存分析,以建模SATD的解决时间,同时考虑右删失数据以估算债务生命周期。
- 采用统计建模与特征重要性分析(如SHAP)识别ML项目中与长期SATD相关的代码级特征。
- 测量包含SATD的文件的软件度量(如代码复杂度、文件大小、变更频率),以关联债务持久性。
- 通过版本控制历史的时间序列分析,比较ML与非ML项目中SATD的引入与移除速率。
实验结果
研究问题
- RQ1RQ1:ML代码中的SATD普遍性与非ML代码相比如何?
- RQ2RQ2:ML代码中SATD的主导类型与类别是什么?与传统软件有何不同?
- RQ3RQ3:SATD在ML流水线的哪些组件(如数据预处理、模型训练)中最为普遍?
- RQ4RQ4:ML项目中SATD的引入与解决速度与非ML项目相比如何?
- RQ5RQ5:ML项目中与长期SATD相关的代码级特征有哪些?
主要发现
- ML项目的中位SATD占比是非ML项目的两倍,非ML代码中2%含有SATD。
- SATD在数据预处理和模型生成组件中最普遍,而验证与部署组件的债务率较低。
- ML项目中的SATD引入速度是非ML项目的140倍,表明开发过程中技术债迅速累积。
- ML项目中的SATD解决速度是非ML项目的3.7倍,表明债务条目周转率极高。
- ML代码中长期存在的SATD通常出现在涉及多文件、低代码复杂度的大规模变更期间。
- 循环复杂度较低的文件更可能包含长期存在的SATD,表明小型文件常被忽视,是高风险区域。
更好的研究,从现在开始
从阅读论文到最终审阅,大幅缩短您的研究时间。
无需绑定信用卡
本解读由 AI 生成,并经人工编辑审核。