YuRonan

目前OpenPerf已经通过《计算机学报》的一审，但需要大改，由于里面涉及实验室大量之前的工作，所以还要麻烦部分同学和王老师一起提供一些内容，从而顺利的完成修改，辛苦大家，一共16条意见，我把我不是很确定如何回复的列出来 **意见1. 文章对基准本身的介绍存在不清楚的地方。例如，一共包含多少项目？每个 任务的输入和输出是什么？输入的数据规模如何？数据的标签如何而来？** 这个由于当时碍于篇幅的原因，在第4章我们没有对那9个任务做太多详细的介绍，而是列举了3个典型的例子详细介绍，现在审稿人要求补充数据集的规模，所以每一小节可能都要做一些说明 4.2 开源自动化机器人识别与分类 - 这一小节的数据说明麻烦毕博给出一些说明，@bifenglin 4.4 开源软件供应链风险预测 - 这一小节同样麻烦毕博 4.5 开源项目影响力排序 这个任务的描述和6.1.2影响力指数基准的理解实在太像了，我不太确定要怎么判断此任务和影响力指数基准任务的区别。 4.6 开源归档项目预测 麻烦小雅 4.7开源网络指标预测 此任务感觉和毕博在opensoda上的任务有些类似，毕博可以确定一下 **意见3. 第4.2章提到的软件机器人是什么？可以做什么事情？发表的论文有哪些？这里的Biman账户和BodeGha账户具体说明意思？为什么要识别这些账户？Github上没有对这些账户的记录吗？** 这部分内容还是要麻烦毕博给出解释了 **意见4：文中第3.1章节，对于“基准测试体系的溯源性和校准”的解释很抽象，能否举例说明？** 此问题有两个审稿人都提出来了，这部分我想着就从openrank影响力基准讲解，OpenPerf 中的影响力、活跃度 等指数类基准，通过“开源项目 影响力排序”等任务进行定义并产出最终数据，同时将排名靠前(例如 Top100)的对象作为标杆集，类似这样的实例去讲解溯源性和校准，这个麻烦...

经过两周左右的整理，我已经完成了所有意见的回复，添了近一万多字，下面列出提到的几个主要问题的回复 **意见4：文中第3.1章节，对于“基准测试体系的溯源性和校准”的解释很抽象，能否举例说明？** 以阿里巴巴开源开发者贡献激励榜为例，该应用旨在通过精准地评价个人在项目中的影响力从而进一步形成对开发者的激励，鼓励更多开发者参与到项目的开发中。若将影响力排名前3的开发者视为开发者标杆，对其溯源发现评价的主要依据为影响力指数基准，影响力指数基准通过计算开发者在协作网络中的贡献度而来，而最终的排序结果则通过开源影响力排序任务产出最终数据，自上而下对标杆类基准完成溯源。同时，可以通过开源影响力排序任务来判定影响力指数的合理性，对每次给出的排序结果进行一次次校准，使其逐步合理；而影响力指数计算的最终结果会直接涉及到标杆类基准最终的判定，通过不断优化调整影响力指数的计算方式则可以校准标杆类基准最后的结果，使其更加符合实际情况。OpenPerf基准测试体系的设计初衷是希望涵盖开源生态下的大多数基准测试任务，目标相对宏大。当前课题组已对三类基准分别给出一定的测试结果，在未来会针对该体系进一步优化，对不同子类下的基准测试展开详细定义，完善整个体系下的基准测试结果。 **意见9：数据科学任务类基准中各任务选择的依据是什么？测试任务的设计是否能够覆盖所有的开源场景** 在OpenPerf体系的引导下，结合数据科学任务的多种问题类型、数据类型、研究领域以及开源领域的主要应用场景，实验室成员完成了开源场景下较为典型的9个数据科学任务类基准。当前我们设计了9个数据科学类基准任务，并未覆盖所有的开源场景，因为开源领域的任务是可扩展的，研究者们可以根据自己的研究方向结合开源的场景提出新的任务，但我们设计的体系是可以覆盖整个开源场景的，在未来会补充更多基准测试的任务。已在本文未来工作中描述。 **意见13：请具体说明图2中“支撑”、“导出”、“探索”这几个箭头的具体含义，并说明基准测试任务是如何构建的。**  我们对基准测试任务的构建流程进行了详细的描述，内容如下： OpenPerf通过最底层的数据科学知识体系，结合具体的数据领域、研究领域以及多种通用任务类型，同时结合上层具体的业务场景，共同探索开源领域的基准空间。开源领域业务场景包含开源生态战略、企业开源治理、开源软件开发以及开源社区运营，不同场景下包含详细的业务，以上场景均从开源领域的各个方面支撑开源软件生态健康的可持续发展。同时为了保持开源软件生态健康的可持续发展，又可以导出开源软件生态的具体业务场景，再根据详细的业务场景探索具体任务的基准空间。在开源领域知识体系和具体业务场景驱动下，确定基准框架中的具体任务、任务类型、数据集、评价标准以及模型设计，则完成一个基准测试任务的构建。 **意见14：本文标题夸大实际贡献。正如本文第7章所述，OpenPerf主要聚焦于数据科学相关的任务，并非整个开源社区所有任务，因此标题中应明确本文范围是“数据科学相关”。此外，标题中提及开源生态“可持续发展”，但纵观全文，审稿人并未发现对开源生态“可持续发展”的定义、说明或讨论，即本文没有回答什么是开源生态“可持续发展”，满足什么条件可以使开源生态“可持续发展”，所提出的方法如何使开源生态“可持续发展”。若无此类讨论，审稿人建议避免使用该类无实际意义的词汇** 开源生态的可持续发展是指开源软件可以在长期内能够持续健康地发展和维护的状态。一个具有可持续发展的开源生态能够吸引、培养和维护社区参与者，同时保持项目的稳定性、可靠性和活跃性。为了使开源生态可持续健康的发展，当前关于开源生态的研究已经取得了部分成效，但由此所带来的一个重要问题就是缺乏相关的基准、 标注与评价规范，造成了一个“有数据无基准”的局面。一个开源项目处于怎样的发展位置、一个社区的健康成熟度达到了怎样的水平、企业开源程序办公能力处于行业什么位置、开发者贡献度、项目影响力等基础数据与评价，都是数据使用方迫切需要的开源领域知识。而这些都需要多方来共同开展研究与实践来形成一套与指标、数据相匹配的基准。 同时，我们也在6.3-6.5节中，以三个行业具体的应用为例，增加了关于OpenPerf如何使开源生态可持续发展的描述。以6.3节为例，蚂蚁集团 OSPO 开源治理大屏使用了 OpenPerf 中的影响力、活跃度、风险度等指数类基准，而这些指数类基准又通过“开源软件供应链风险预测”、“开源社区异常行为检测”等任务进行定义并产出最终数据。OpenPerf基准服务从宏观的角度分析集团下多个开源项目的发展现状，有效地量化不同项目的活跃度与影响力，为项目的可持续发展提供一定的参考。 看大家和王老师 @will-ww 这边有没有一些修改意见，争取下周提交修改稿。

针对二审返回的修改说明如下： （1）意见1：文章对基准本身的介绍存在不清楚的地方。 补充意见：对不同任务的描述非常分散，建议用一个表格来列出主要的内容。 对意见（1）的修改说明： 感谢您提出的建议。我们在第4章的开头给出了一个关于基准测试任务的表格，列出了主要的内容，其中包含项目数量、输入、输出、标签来源和评价指标5项关键数据，并在表格下方对表格中的部分内容进行了必要的解释。  开源行为数据补全与预测、开源自动化机器人识别与分类和基于链路预测的开源项目推荐详细内容见第5章。 开发者的个人情绪在软件开发的过程中会影响生产效率、任务质量、工作满意度等，故本文将开源评论文本情绪分类任务作为基准测试任务之一，选取了GitHub star数排名前50的仓库，提取了2022年中这些项目的issue评论，对数据进行了预处理，移除了非英文评论，为了保证数据集的质量，由3名开源生态学研究方向的硕士研究生对长度不超过128的短评论文本进行打标签，得票高的情绪为该条数据的最终结果，在选择文本时尽量选择了带有明显情感词的评论，暂未考虑中性评论，最后产出5000条正向评论以及5000条负向评论数据。 开源软件供应链风险预测任务旨在通过量化软件供应链的各种风险（测试完整度、外部依赖度、团队健康度等9中风险指标），最终得出可维护性评分。通过实证分析的方式验证可维护性评分的有效性。 开源项目影响力排序任务通过对GitHub中2022年全域17万左右活跃项目进行获取，项目与项目之间通过开发者产生关联从而形成一个开源项目网络图，该图中包含了280多万条连边。该任务旨在通过高效的图排序算法对图中含有不同影响力值的开源项目进行排序。 ------------------------------------------------------------------------------------------------------- （2）意见2：第4.3介绍的是情绪分类。这里Github的评论指的具体是什么？ 作者回复：我们选取了Github star数排名前50的仓库，提取了2022年中这些项目的issue评论，对数据进行了预处理，移除了非英文评论 补充意见：评论issue的大部分是开发者自己吗？这样的评论能反应项目的质量吗？ 对意见（2）的修改说明： 感谢您的提问，根据参考文献[1-5]的描述, 开发者的个人情绪在软件开发的过程中会影响生产效率、任务质量、工作满意度等，以下研究多数通过对GitHub存在的issue评论、PR评论以及Commit评论文本等，挖掘开发者在软件开发过程中的情感，尽管GitHub作为一个开放的代码托管平台，任何人都可以在仓库下发表评论，多数研究者认为issue中的大多数评论都来源于开发者，故将其作为研究的一部分。 文章中并未说明issue评论能反应项目的质量，由于开发者的个人情绪在软件开发的过程中会影响生产效率、任务质量、工作满意度等，决策者可以通过平台中的消极评论及时做出反馈，从而使得项目健康的发展。因此本文将开源社区情绪分类作为数据科学类基准测试任务中的一项任务。 [1]Jurado F, Rodriguez P. Sentiment Analysis in monitoring software development...

OpenPerf任务拟定（可以做删改） 1. 基于GitHub协作网络的开发者/仓库推荐方法 2. 开源社区命名实体识别数据集的构建及方法实现 3. 开源社区问答数据集的构建及问答模型的实现 4. 基于机器学习的开发者地理位置信息挖掘 5. GitHub仓库多标签分类方法的研究与实现

感觉如果把某一个排行榜单独拿出来当做一个任务的话，要考虑一下工作量的问题，只是在网页上列一个表格的话，感觉有一些太简单了

> 部署**开源领域垂直大模型**，可以做非常多的赋能与创新任务： 最近读了一篇达摩院NLP团队去年8月份发布的[《指令微调的电商领域大模型》](https://arxiv.org/pdf/2308.06966.pdf)，受益匪浅。 在下次轮到我做学术分享时，我会对该论文讲解 该论文将整个电商领域的数据集划分为100多个任务数据集，主要任务划分情况如下：  然后使用指令微调的方式，让模型逐一去学习这些任务，最后实验取得不错的效果 指令微调数据需要包含任务描述、任务指令、输入句子、候选标签（可选）、输出限制（可选）、输出结果 数据集有一部分来自于公开成熟的数据集，因为电商领域本身研究者参与的也很多，故产生了很多标准数据集 还有一部分没有标签的数据通过ChatGPT和人工标注的方式产生 那么放到开源领域我认为我们一下提出100多个任务数据集显然是很难的，可以把现有已经形成的数据集作为训练的一部分，这与我之前一直想制作的问答任务数据集也是相关联的。 同时数据集的制作又于OpenPerf有着关联性，OpenPerf中我们提出的9个任务，也可以选择合适的一部分作为指令微调数据集中的一个任务。如何构建开源领域的垂直大模型也会是我后面主要工作的一个方向。

补充： EcomGPT仓库链接https://github.com/Alibaba-NLP/EcomGPT EcomGPT模型下载地址https://www.modelscope.cn/models/iic/nlp_ecomgpt_multilingual-7B-ecom/summary 该论文目前只开源了12个测试数据集https://github.com/Alibaba-NLP/EcomGPT/tree/main/data/ecom_instruct_v1 可以参考

前期工作： 类比EcomGPT,我会搜索现在网络上关于开源数字生态领域已经**公开的领域任务数据集**，不定时更新该评论，暂时的想法是能形成10个左右领域任务数据集，构成20以上的原子任务数据集，随即展开实验。 分类任务： https://github.com/nlbse2024/issue-report-classification https://github.com/collab-uniba/Senti4SD https://github.com/s2e-lab/BERT-Based-GitHub-Issue-Classification

类似机器人分类任务的数据集，根据毕博的工作，可能要考虑10多个特征才能提高预测准确率，输入的特征内容较多，在大语言模型中(不考虑多模态)，指令输入只能是一段文本，可以将该任务作为基础任务去尝试训练，将其转为问答任务： 例如。在微调阶段，直接输入某某账号是否为机器人账号，模型输出是或者否，也就是说让大模型直接去学习答案。 这样做的话，如果将机器人分类数据集分为训练集和测试集，那么大模型在测试集的表现会很差，因为它只学到了训练集的答案，没有学到测试集的。 那么，参考EcomGPT，将分类任务转为问答任务，如果提问的GitHub账号是模型学习过的，那么，模型可能就会回答正确答案，这样也可以说成是跨任务的泛化能力。 不过，其实我觉得构建问答数据集本身就很灵活，只要保证答案的准确性，多数任务都能转化为问答对的形式。 当然，这只是初步的想法， 后续还要看模型的具体效果。

分享一个关于大模型可实现NLP任务的博客 https://zhuanlan.zhihu.com/p/644170707