软件工程研究中的机器学习实践：挑战、最佳实践与跨学科融合

1. 项目概述当软件工程研究者遇上机器学习作为一名在软件工程领域摸爬滚打了十多年的研究者我亲眼见证了机器学习ML从实验室里的新奇玩具逐渐演变为我们工具箱里不可或缺的“瑞士军刀”。无论是预测代码缺陷、自动化测试用例生成还是智能代码补全ML的应用正在深刻改变我们构建、分析和维护软件的方式。然而这把“军刀”虽好用起来却并不总是得心应手。我们这些软件工程SE背景出身的人在面对ML时常常有种“隔行如隔山”的疏离感。我们熟悉设计模式、软件架构和敏捷流程但对梯度下降、过拟合、特征工程这些ML的核心概念却可能感到陌生甚至棘手。这种疏离感并非个例。近年来一个被称为“ML4SE”Machine Learning for Software Engineering的交叉领域蓬勃发展旨在利用ML技术解决SE的传统问题。与此同时其反向领域“SE4ML”Software Engineering for Machine Learning也备受关注即如何运用成熟的软件工程实践来构建更可靠、更易维护的ML系统。尽管这两个方向都前景广阔但一个核心矛盾日益凸显软件工程研究者作为ML技术的重要应用者和推动者他们的声音、他们的实践、他们面临的独特困境在现有的“最佳实践”讨论中往往被边缘化了。现有的ML最佳实践指南大多由数据科学家或ML工程师撰写其背景、目标和约束条件与SE研究项目大相径庭。我们做研究要的是可复现性、严谨的评估和理论贡献而工业界可能更关注模型的在线A/B测试效果和迭代速度。这种错位导致了许多“水土不服”的情况一篇论文里宣称效果显著的ML模型其数据预处理步骤可能语焉不详一个复杂的神经网络架构其超参数调优过程可能被一笔带过让后来者难以复现或深入理解。更不用说在评审同行的ML4SE论文或者在为计算机科学专业的学生设计ML课程时我们常常缺乏一个清晰的、基于SE视角的评估框架和教学重点。因此我决定发起并主导了一项系统性的实证研究。我们不再满足于零散的个案经验而是希望通过大规模调研真正走进软件工程研究者的世界去倾听、去记录、去分析他们是如何在实践中应用ML的。我们想知道他们到底在用哪些ML实践他们认为什么才是“最佳实践”他们在实践中踩过哪些坑作为评审者和教育者他们又认为哪些方面至关重要这项研究正是为了填补这一认知鸿沟为ML与SE更健康、更高效的融合提供一份来自一线的“田野调查报告”。2. 研究设计与方法如何系统倾听研究者的声音要回答上述问题不能仅凭直觉或个人经验需要一个严谨、系统且可复现的研究方法。我们的目标是捕捉一个多元化的图景而非单一机构的回声。为此我们设计了一个混合方法研究结合了文献分析、问卷调查和深度访谈从三个维度收集数据。2.1 研究对象与数据来源构建一个立体的研究样本我们聚焦于三类核心研究对象确保视角的全面性已发表的SE研究论文这是ML实践被“书面化”和“规范化”的最终产物。我们选取了2011年至2022年间在软件工程领域三大顶级A*会议ICSE, FSE, ASE上发表的、标题或摘要中包含“机器学习”的论文。通过自动与人工双重过滤如剔除少于10页的短文、教程、仅提及但未使用ML的论文我们从初始的1398篇论文中最终通过分层抽样得到了117篇用于深度人工编码的分析样本。SE论文的作者他们是实践的“执行者”和“报告者”。我们从上述过滤后的论文全集中提取了第一作者和通讯作者的邮箱向769位研究者发送了调查问卷核心问题是“您在软件工程研究论文中使用了哪些机器学习最佳实践您使用这些实践的频率如何[总是、经常、有时、从不]”最终我们收到了58份有效回复。活跃的ML4SE研究者他们是领域的“思想领袖”和“深度实践者”。我们通过目的性抽样联系了38位在该领域有影响力的学者包括教授和资深工业界研究员其中19位完成了背景问卷调查并最终对14位进行了半结构化的深度访谈时长均在60分钟以上。注意这种三角验证的数据源设计至关重要。论文代表了“宣称的实践”作者调查反映了“自我认知的实践”而深度访谈则能挖掘“背后的逻辑、挑战与隐性知识”。三者结合才能逼近真实的全貌。2.2 核心变量与编码框架定义我们观察的“透镜”为了系统分析收集到的数据我们定义了七组核心变量它们就像不同的镜头帮助我们聚焦于研究问题的不同方面变量ID变量名称描述应用对象论文/作者/研究者Var1实践在ML流程中实际应用或使用的方法。✓ ✓ ✓Var1.1输入执行方法所需的输入如数据类型、格式。✓ ✓ ✓Var1.2技术所应用的具体方法或算法如随机森林、SVM。✓ ✓ ✓Var1.3目的/输出应用该技术的原因及预期产出。✓ ✓ ✓Var2ML流程阶段实践所关联的ML生命周期阶段基于Amershi等人的经典流程。✓ ✓ ✓Var3SE任务使用ML解决的软件工程任务如缺陷预测、代码摘要。✓ — ✓Var4质量属性ML系统应具备的属性如可解释性、公平性、鲁棒性。— — ✓Var5ML挑战开发和研究ML时面临的困难与挑战。— — ✓Var6评审者视角评审ML4SE研究时应考虑的重要方面。— — ✓Var7教育者视角在SE背景下教授ML时应考虑的工具与方面。— — ✓这个框架是我们分析的基石。例如当分析一篇论文时我们会用Var1-Var3来解构其中描述的ML实践而在访谈中我们会用Var4-Var7来探索研究者更深层的思考。2.3 数据收集与分析流程从原始文本到深刻见解我们的分析遵循定性研究中的扎根理论原则主要包含开放式编码和轴心编码两个步骤。人工编码对于117篇论文由两名编码员独立阅读并提取所有相关变量信息再由第三名编码员进行核对与合并确保信度。对于58份调查回复和14份访谈转录稿同样由两名研究员进行独立的开放式编码提炼初始概念。轴心编码与归类在获得大量初始代码后我们进行多轮讨论将语义相近的代码归类到更高层级的类别中。例如关于“数据划分”的代码“使用80/20划分”、“采用k折交叉验证”、“按时间顺序分割”最终被归入“评估策略”这一类别。定性分析基于编码后的类别和代码我们进行定量统计如频次计算和定性分析如引用典型陈述来系统地回答我们的四个研究问题。这个过程是劳动密集型的我们总共从三个数据源中提取了4107个初始代码经过归并后得到3057个有效代码最终凝聚成能够揭示模式的核心类别。所有数据和代码均已开源以确保研究的可复现性。3. 核心发现软件工程研究者的ML实践图景通过对数据的深入分析幅关于软件工程研究者如何应用机器学习的生动图景逐渐清晰。这些发现不仅揭示了当前的普遍做法也暴露了认知与实践之间的差距。3.1 RQ1研究者们使用并宣称了哪些ML实践这是最基础也最令人惊讶的问题。我们发现实践可以从三个层面来看论文中报告的、作者宣称的以及研究者深度访谈中透露的。3.1.1 论文中报告的实践重技术轻过程在分析的117篇顶级会议论文中ML实践的描述呈现出高度的“技术中心化”特征。超过85%的篇幅和代码都聚焦于Var1.2技术和Var1.3目的/输出。研究者们热衷于描述他们采用了哪种新颖的神经网络架构如Transformer、GNN使用了何种先进的算法以及最终在某个指标如F1-score、Accuracy上提升了多少百分比。然而Var1.1输入和Var2ML流程阶段中的关键细节却常常缺失或模糊。例如数据披露不完整仅有约35%的论文提供了可供复现的数据集链接或详细的数据构建过程。许多论文仅用“我们收集了GitHub上X个项目的代码”一笔带过但具体的过滤规则、去重方法、数据清洗步骤无从得知。特征工程黑盒化特征是如何从原始代码或日志中提取的特征选择的标准是什么这些对于理解模型为何有效至关重要的信息在超过60%的论文中描述不足。实验设置模糊超参数是如何设置的是网格搜索还是随机搜索训练/验证/测试集的具体划分比例和依据是什么许多论文的“实验设置”部分过于简略导致复现困难。实操心得在撰写ML4SE论文时务必把“可复现性”作为第一要务。一个实用的技巧是在论文中增设“数据与资源可用性”小节或提供一个详细的附录。不仅要说明你用了什么模型更要像写实验手册一样交代清楚数据的“前世今生”和实验的“每个旋钮”。评审者包括我本人越来越看重这一点。3.1.2 作者宣称的最佳实践认知的集中与发散来自58位论文作者的调查回复揭示了他们对“最佳实践”的认知。回复非常简短平均每条实践描述仅约45个字符但指向性明确。高频出现的“最佳实践”包括交叉验证被超过70%的受访者提及被视为评估模型泛化能力的黄金标准。超参数调优约65%的受访者提到强调使用网格搜索、随机搜索或贝叶斯优化来寻找最优参数。使用标准数据集/基准约50%的受访者认为在公开基准如Defects4J for bug prediction上进行比较是关键。特征标准化/归一化被认为是预处理中的基础必备步骤。有趣的是这些被“宣称”的最佳实践大多集中在模型训练与评估阶段Var2而对于数据收集、标注、版本管理等前期阶段以及模型部署、监控、持续学习等后期阶段提及率极低。这反映出一个普遍心态SE研究者更关注ML流程中与“算法性能”直接相关的环节。3.1.3 深度访谈中的实践全景理想与现实的沟壑与调查的简短回答不同14位资深研究者的深度访谈为我们打开了更广阔的视野。他们谈论的实践远远超出了算法本身。全流程意识开始萌芽多位访谈者强调一个严谨的ML4SE研究必须考虑完整的数据流水线。例如一位研究者提到“我们团队现在会为每个项目建立数据谱系图记录每个数据版本的来源、变换和处理脚本。这虽然增加了开销但在回答评审人质疑或自己后续分析时价值巨大。”对“技术债”的担忧几位来自工业界实验室的研究者指出学术研究中快速搭建的、只为跑通实验的ML代码存在严重的“技术债”。它们通常缺乏模块化设计、单元测试和文档一旦需要扩展或移交就变成“黑盒遗产代码”。他们开始倡导在研究中引入简单的SE最佳实践如代码重构和接口设计。实践因任务而异访谈清晰表明不存在“一刀切”的最佳实践。用于代码补全的模型如基于Transformer其最佳实践如大规模预训练、特定领域微调与用于缺陷预测的模型如基于静态代码度量截然不同。后者更强调特征的可解释性和与软件度量理论的结合。3.2 RQ2研究者在应用ML时面临哪些挑战如果说实践描绘了“我们怎么做”那么挑战则揭示了“为什么这么难”。访谈中揭示的挑战是多层次且深刻的远不止“调参难”这么简单。3.2.1 数据层面的根本性挑战这是被提及最多、也最棘手的挑战群。获取与构建高质量数据的成本高昂SE数据如代码、提交历史、issue报告虽然量大但“脏”。构建一个用于缺陷预测的干净数据集需要大量的人工或启发式规则进行标注且标注一致性难以保证。“我们花了三个月时间清理和标注数据但论文里可能只用一段话描述这个过程。”一位研究者无奈地表示。数据的代表性与偏见大多数研究依赖于开源软件如GitHub数据。这引入了严重的选择偏差成功的、活跃的项目被过度代表而企业级私有代码、遗留系统数据则几乎缺失。在此数据上训练的模型其结论能否推广到更广泛的软件世界这是一个悬而未决的问题。数据隐私与合规性当研究涉及企业数据时隐私和知识产权问题成为巨大障碍严重限制了数据的可获得性和研究的可复现性。3.2.2 方法与评估的挑战评估指标与真实价值的脱节SE社区普遍使用Accuracy、Precision、Recall、F1-score等指标。但多位访谈者尖锐指出这些指标往往无法反映一个ML工具对开发者生产力的真实提升。例如一个缺陷预测模型可能有很高的召回率但它推荐给开发者的可疑代码行太多反而增加了审查负担。“我们需要更好的、与开发者体验直接挂钩的评估体系。”一位资深教授强调。复现性与比较的困境即使论文提供了代码和数据由于依赖库版本、硬件环境、随机种子等细微差异完全复现结果仍非常困难。这导致不同研究之间的公平比较几乎不可能阻碍了领域的累积性进步。“黑盒”模型的可解释性需求深度学习模型性能强大但可解释性差。在SE的许多关键场景如安全漏洞检测、代码审查辅助开发者需要知道模型“为什么”做出某个判断而不仅仅是判断结果。如何让复杂的ML模型变得可解释、可信任是一个重大挑战。3.2.3 能力与跨学科协作的挑战知识鸿沟传统的SE研究者缺乏深入的ML统计学和优化理论背景而ML专家又往往不熟悉软件系统的复杂性和领域知识。这种鸿沟导致沟通成本高容易产生“用锤子找钉子”式的应用——生搬硬套ML模型而忽略了SE问题的本质。工具链的割裂SE研究者熟悉的IDE、版本控制、CI/CD工具与ML研究者常用的Jupyter Notebook、MLflow、TensorBoard等工具之间存在巨大的工作流隔阂。如何将ML实验无缝集成到软件开发生命周期中仍缺乏成熟的最佳实践和工具支持。4. 超越研究评审与教育的视角研究的最终目的不仅是发现问题更是为了改善社区的生态。因此我们从“守门人”评审者和“播种者”教育者的视角进一步探讨了如何构建更健康的ML4SE环境。4.1 RQ3评审ML4SE研究时应考量哪些重要方面基于访谈我们提炼出评审者最关注的几个维度这实际上也为如何撰写一篇高质量的ML4SE论文提供了指南。动机与问题定义的清晰性这项研究要解决的SE问题是否被清晰、有力地定义了使用ML的必要性和合理性是否得到了充分论证是“为ML而ML”还是ML确实是解决该问题的最佳或必要工具评审者会首先审视这一点。数据与实验的透明性与严谨性这是评审的重中之重。具体包括数据可复现性数据集是否公开或明确描述了获取与构建过程数据划分是否合理如时间敏感数据是否按时间划分实验设计是否进行了充分的消融实验以证明每个组件的贡献基线对比方法是否选择得当且实现了其报告的性能统计显著性检验性能提升是否经过了适当的统计检验如Wilcoxon signed-rank test而非仅仅比较平均值威胁效度分析是否坦诚地讨论了研究的局限性如数据偏差、泛化能力威胁贡献的实质性论文的贡献是提出了一个新颖的ML模型还是深入揭示了ML应用于某个SE任务时的新规律前者需要模型有足够的创新性和性能优势后者则需要深刻的洞察和扎实的分析。单纯将现有ML模型应用到另一个SE数据集上而不提供新的领域见解价值有限。对SE社区的启示这项工作的发现对软件工程实践或研究有何更广泛的启示是否提出了新的工具、方法或理论能够被其他研究者或开发者所采用给投稿者的建议在撰写论文时不妨假设一位苛刻的评审者会追问每一个细节。提前在“实验设置”、“数据”等章节回答这些潜在问题。设立一个“可复现性清单”并在附录中提供能极大增加论文的说服力。4.2 RQ4从SE视角出发教授ML时应考虑哪些方面如何为未来的软件工程师和研究者教授ML访谈中的教育者们给出了极具启发性的建议。从SE问题出发而非从ML算法出发传统的ML课程常以“监督学习、无监督学习、强化学习”等算法分类开篇。但对于SE学生更好的起点是具体的SE问题“我们如何自动检测代码中的坏味道”、“如何从用户评论中自动分类需求”。以问题驱动自然地引入所需的ML概念和技术能让学生立刻看到学习的价值。强调数据工程与特征工程对于SE背景的学生数据往往不是现成的表格而是代码、文本、图或序列。课程必须花大量时间讲解如何从这些复杂的、非结构化的SE数据中提取、清洗、构建特征。这部分的重要性不亚于模型本身。融入软件工程最佳实践教授学生如何为ML项目编写整洁、模块化的代码如何使用版本控制不仅控制代码还要控制数据和模型如何设计实验脚本以保证结果可复现。将ML项目当作一个软件工程项目来管理。注重实践与工具链理论固然重要但动手能力是关键。课程应包含大量使用真实SE数据集如Maven库、GitHub仓库的实践项目。同时介绍现代MLOps工具链如DVC做数据版本控制MLflow跟踪实验让学生体验工业界的工作流程。培养批判性思维与伦理意识引导学生批判性地思考模型的局限性、评估指标的缺陷、数据中可能存在的偏见以及ML系统部署后可能带来的社会影响如自动化编程工具对就业的潜在影响。这是培养负责任的研究者和工程师不可或缺的一环。一位受访教授分享了他的课程设计“我的‘ML for Software Engineering’课程第一个大作业不是训练模型而是让学生选择一个SE任务如bug定位然后去爬取、清理、标注一个属于自己的小型数据集。这个过程让他们痛苦但也让他们真正理解了数据的价值和质量的重要性这是后续一切的基础。”5. 总结与展望迈向更成熟的ML与SE融合这项研究为我们呈现了软件工程研究者应用机器学习的真实生态一个充满机遇但也遍布挑战的交叉领域。我们看到社区在模型技术上快速跟进但在数据透明性、实验严谨性和工程化实践上仍有很长的路要走。我们听到了研究者们对高质量数据的渴望、对更好评估标准的呼唤以及对跨学科知识融合的需求。这些发现不仅仅是学术上的观察更是行动的号角。对于研究者个体而言它是一份自查清单我的工作是否足够透明、严谨、可复现对于论文评审者和会议程序委员会而言它提供了强化评审标准的依据。对于教育工作者而言它指明了课程改革的方向——培养既懂软件工程原理又掌握机器学习技能同时还具备严谨科学思维和工程素养的新一代人才。ML与SE的融合已不可逆转。未来的趋势将不再是简单地将ML模型“应用”于SE问题而是更深层次的“融合”开发专为SE数据如抽象语法树、控制流图设计的神经架构构建贯穿软件全生命周期的、可解释、可信任的AI辅助工具建立一套得到社区公认的、针对ML4SE研究的基准、评估协议和最佳实践指南。这条路需要软件工程研究者、机器学习专家、数据科学家和教育工作者共同努力。作为身处其中的一员我的体会是保持开放的学习心态尊重数据与实验的严谨性并始终牢记我们最终的目标不是追求更高的指标数字而是构建更好、更可靠、对人类更有益的软件。这份来自一线的“田野报告”希望能为所有同行在这条融合之路上点亮一盏微灯提供一份切实的参考。