摘要：软件开发者能力评价和协作关系推荐，是大数据环境下软件智能化开发领域的一个研究热点.通过分析互联网开发者社区和企业内部开发环境，设计出基于模糊综合评价的开发者能力模型.随后，通过挖掘开发者与任务的动态交互行为、静态匹配度以及开发者能力这3个不同维度的特征并结合矩阵分解技术，提出一种能力与行为感知的多特征融合协同过滤开发者推荐方法，最终解决开发者推荐面临的评价矩阵稀疏性和冷启动问题，提升个性化精准推荐效率.从系统层面给出适合大数据环境的多特征融合开发者推荐原型系统实践并对现有开源技术框架的优化改进，实验过程分别基于互联网问答社区StackOverflow和企业内部GitLab环境进行了实验分析.最后，对未来研究可能的问题及思路进行了展望.
关键词：多特征融合；协作推荐；能力评价；行为感知；大数据
作者：谢新强1，2，杨晓春1，王斌1，张霞1，2，纪勇2，黄治纲2：1(东北大学计算机科学与工程学院，辽宁沈阳110004)2(软件架构国家重点实验室(东软集团)，辽宁沈阳110179)
近年来，随着云开发平台技术的不断成熟，软件开发正在从封闭走向开放，开发人员也逐渐从精英走向大众，通过交互分享、群体协作等方式来生产高质低价软件制品的开发模式已经取得了显著成果.开源软件社区、软件众包平台[1]、开发者社区逐渐成为开发人员解决问题的主要途径.上述趋势使得互联网平台/企业内部积累了规模巨大、异构分散、复杂演化且价值稀疏的海量数据资源，包括开发者行为活动和相关软件代码、文档数据等.例如，短短几年时间，软件众包平台Topcoder就吸引了100多万名开发者，每天产生的资源数超过5万项；开发者技术社区StackOverflow上的用户数也达到600万，资源数量超过1300万；软件项目托管平台GitHub上的用户数超过1500万，项目数超过3800万；全球最大的IT社区CSDN上的用户数量也超过3000万，资源数量超过9000万.在这样一个超量信息环境下，信息过载问题日趋严重.面对数百万不同地域、不同经验、不同能力的开发者，想要快速而准确地从中筛选出合适的开发者或开发任务是相当困难的.
在此背景下，面向软件工程领域的开发者能力评价和推荐系统的研究和应用开始受到关注.如何有效地收集、处理和分析互联网上以及企业内部的软件过程数据资源(例如互联网平台上开发者的基本信息、历史活动记录、评价信息、开发者之间或开发者与任务的关联关系信息、企业内部项目信息、源码资源、缺陷跟踪管理信息等)对开发者能力、任务分配以及开发者协作关系进行建模分析和精准推荐，从而有效地解决大数据环境下软件开发者能力评价和筛选所面临的信息过载问题，是本文的主要研究动机和出发点.
本文第1节介绍相关工作.第2节提出基于模糊综合评价的开发者能力评价模型.第3节提出多特征融合的协同过滤开发者推荐方法以及大数据环境下开发者推荐系统实践的技术方案选型.第4节为实验分析.第5节给出结论以及对未来工作的展望.
1相关工作
推荐系统作为解决信息过载问题的有效手段，其概念是由卡内基?梅隆大学的RobertArmstrong在1995年AAAI会议上首次提出，并推出第1个推荐系统的原型WebWatcher.随后，斯坦福大学的Balabanovic等人推出的个性化推荐系统LIRA1为个性化推荐系统的发展奠定了基础[2].随着电子商务、社交网络的异军突起，学术界和产业界对于推荐系统的研究和应用也异常火爆.其中，协同过滤推荐算法(collaborativefiltering，简称CF)是推荐系统领域最经典的和最流行的算法，例如，Amazon电子商务推荐系统、腾讯视频推荐系统、豆瓣音乐推荐系统等都采用了协同过滤推荐方法.协同过滤推荐方法的优点在于不依赖物品内容，推荐结果具有多样性；缺点也非常明显，新用户和新物品的冷启动问题、评价矩阵的数据稀疏问题一直是其无法逾越的瓶颈问题.例如，Netflix百万大赛中提供的音乐数据集的稀疏度是1.2%，而淘宝网的评价矩阵数据稀疏度甚至仅在0.01%左右.对这一问题，学术界和产业界进行过大量的探索，提出了许多有价值的研究思路.比如，文献[3，4]在协同过滤评价矩阵基础上加入了时间因子、物品类型、人口统计学特征；文献[5，6]借助社交媒体、用户共享社区和Tweet上蕴含的Topic获取用户潜在的偏好特征，并融合社会网络、内容相关性、时间、地理位置等因素特征；文献[7，8]利用网页浏览、检索和Tweet上广告点击等用户行为日志数据来改善评价矩阵的数据稀疏问题；文献[9，10]借助不同用户兴趣偏好的地域性和朋友圈分享内容的关联性特征来改善数据稀疏和冷启动问题；文献[11-13]基于OCCF(oneclasscollaborativefiltering)方法对评价矩阵采用“零值注入”的方法来解决评价矩阵的数据稀疏和冷启动问题等.
近10年来，尽管推荐系统在电子商务、社交媒体、新闻广告、搜索引擎等领域的研究和应用已经取得了很大的成功，但对于软件工程领域的资源获取、任务分配、开发者、协作关系等方面的推荐系统(recommendationsystemforsoftwareengineering，简称RSSE)成功案例却非常少[14].一方面由于传统软件开发主要基于开发者本地或者企业内部的封闭环境下进行，这使得对于异构、多源、碎片化分布的软件工程大数据的自动化收集相当困难；另一方面，由于软件开发是知识密集型活动，个体能力差异和社会化生产环节是影响效率的重要因素，但这些因素又都没有一致的度量和评价标准，导致软件开发过程中所涉及的开发者能力评价和任务推荐的工具和系统很难落地[15].以互联网开发模式为例，软件项目主要是通过开源社区或众包平台形式对外发布，而开发者通过自组织协作和竞争的方式获得项目开发机会.研究发现，开发者与项目之间的连接矩阵非常稀疏，只有少数开发者与少数项目之间存在明显评价关系.这导致了现有开发者推荐方法效果极差.为解决这一问题，学术界进行了大量研究，比如，文献[16]基于KNN方法分析缺陷报告中潜在的Topic和开发者特征之间的相似关系来推荐最佳的缺陷修复者；文献[17]提取多个域中的Topic，计算跨域Topic间的相似关系进行跨域协作关系推荐；文献[18]基于Topcoder上历史获胜者、参与者、任务特征信息，提取出开发者与任务的关联关系，实现为特定项目推荐开发者等.文献[16-18]是从静态特征挖掘开发者和Topic的相似关系，实现为特定Topic推荐开发者，但并没有考虑到开发者的动态行为特征，而实际上，由于开发者与Topic的关系矩阵的稀疏问题，使得其预测结果的平均准确度和覆盖率并不高.文献[19]基于开发者历史完成任务和开发者声誉结合的方式，给出开发任务匹配和推荐模型，利用开发者的声誉增强推荐结果的准确度和多样性.其缺点是，基于内容推荐的方式需要对每个任务进行特征抽取，计算过程复杂且推荐结果不够新颖；此外，由于大量新加入或者已加入的开发者由于没有参与过任务，将很难得到被推荐的机会，使得冷启动问题依然存在.文献[20]对StackOverflow上开发者的历史数据分析，并基于LDA主题模型分析和发现用户潜在的兴趣，最终，基于用户兴趣和协作投票机制相结合的方式为StackOverflow推荐问题专家.
综上，现有工作难点和不足主要概括为如下两点.(1)开发者推荐的难点是解决评价矩阵的数据稀疏和冷启动问题，通常，在评价矩阵过于稀疏或冷启动状态下，推荐结果的准确度和覆盖率等方面的效果极差，而该问题目前尚没有很好的解决方法；(2)现有方法的不足在于单纯考虑开发者和任务的评价矩阵，没有考虑开发者的“显式”能力特征，使得推荐结果的可解释性不强；另外，缺乏对开发者“隐式”动态行为特征的挖掘，实际上，开发者与任务之间存在大量的交互行为，这对解决推荐系统评价矩阵数据稀疏和冷启动问题是非常有价值的.
针对现有工作存在的问题和不足，本文提出了一种基于开发者能力与行为多特征融合的推荐方法，其主要贡献包括如下3点.(1)提出了一种基于模糊综合评价的开发者能力评估模型，并给出了开发者能力模型、开发者与任务关联关系的形式化描述；(2)提出了一种基于开发者能力和行为感知的多特征融合开发者推荐方法，并给出了面向大数据环境下的开发者实时推荐系统的开发和实践过程描述；(3)通过对互联网问答社区StackOverflow和IT企业内部GitLab源码管理的真实数据分析，给出了本文方法和系统的有效性证明.表1给出了本文相关符号的定义和说明.
2开发者能力特征模型
开发者能力评价问题是开发者推荐系统需要解决的难点问题.对于开发者能力的建模和评价标准，学术界和产业界至今没有一致的定义.这导致了软件协作开发过程中由于缺少对开发者能力、技术、经验、影响力等特征的合理度量和评价标准，使得对于开发者推荐结果的可信性往往缺乏说服力和可解释性.对于IT企业而言，主要依靠项目经理的主观经验去选择合适的开发者作为任务的执行者.而基于互联网平台的软件开发模式中，网络上分布着上百万的开发者，每个开发者的能力、技术和经验良莠不齐、难以甄别.在这种情况下，很难根据主观经验对每一个开发者度量、评价和筛选.因此，本文开发者推荐首要解决的问题是建立开发者能力度量和评价模型，对开发者能力特征从不同维度特征，以定性分析和定量分析相结合的方式进行的抽象刻画，例如对开发者特征(如技能、学历、经验、活跃度、关注度以及开发者人口统计学特征等)的抽象.
2.1开发者能力模型定义
开发者个体能力的评价问题是一个涉及多学科融合、层次交叠、不断演化的复杂性系统问题，需要综合、全面地考察开发者的技能经验、认知能力、教育背景、社区活跃度和影响力等多个维度的特征.现有研究通常仅对开发者某个维度的特征进行建模和分析，比如单纯地基于评价矩阵、开发者社会关系网络、标签、历史操作记录等，缺少对各因素的综合考虑，导致评价结果容易受单一因素的影响而产生较大的偏差.本文将模糊综合评价的基本思想[21]引入到开发者能力评价的计算过程中，通过分析开发者静态和动态、显式和隐式特征，以定性和定量分析相结合的方式给出开发者能力模型的模糊综合评价方法.模糊综合评价是建立在模糊集合基础之上，运用模糊数学原理对受多种因素影响的事物做出全面、客观评价的一种决策方法.定义1为开发者能力模糊综合评价模型的定义.
定义1(开发者能力模型).设U={u1，u2，…，un}表示开发者集合，有限论域C={c1，c2，…，cn}为开发者的能力特征集合，V={v1，v2，…，vm}为开发者能力特征对应的评分等级集合，W={w1，w2，…，wn}为开发者能力特征对应的权重pagenumber_ebook=136，pagenumber_book=2309集合，且满足vi∈[0，1]，wi∈[0，1]，=1，rij∈[0，1]表示评价特征ci在评价等级vj上的模糊隶属度，则开发者u的能力评价向量定义为
pagenumber_ebook=136，pagenumber_book=2309
根据模糊综合评价方法，开发者能力模型(developercompetencymodel)的形式化描述为
pagenumber_ebook=136，pagenumber_book=2309
其中，dcm(u)∈[0，1]是对开发者能力从多个特征维度的模糊加权综合计算结果.例如，假设开发者u的能力特征为C={c1：“社区活跃度”，c2：“社区贡献度”，c3：“社区影响力”，c4：“项目经验”，c5：“语言能力”}，对应的评分等级V={v1：0.3，v2：0.6，v3：0.9}，能力特征对应的权重W={w1：0.2，w2：0.2，w3：0.3，w4：0.2，w5：0.1}，开发者能力特征对应等级的模糊隶属度矩阵见表2，本文示例中隶属度是基于经验值给出的.
那么，根据公式(1)和公式(2)的定义，开发者能力评价向量X(u)=[0.22，0.22，0.23，0.18，0.15]T，开发者能力模糊评价计算结果为dcm(u)=0.065.定义1基于模糊理论给出了开发者能力向量和模糊综合能力评价的计算结果，充分考虑了可能的影响因素和权重，相对于单纯评价指标而言，其计算结果更具全面性和客观性.
2.2开发者及任务关系
本文将开发者与任务之间的关系划分为开发者-任务静态匹配关系和开发者-任务动态关联关系.开发者-任务匹配关系是基于标签相似性计算获得，是开发者与任务之间静态特征关系的量化.开发者-任务关联关系则是对开发者交互行为形成的与任务之间的关联关系，是对开发者动态特征关系的量化，比如开发者通过访问、提交、评论、下载等交互操作与任务之间建立的关联关系.下面的定义2、定义3分别给出了匹配关系和交互关系的量化，本文称为匹配度和关联度.
我刚要张嘴，李小树的电话又挂断了。我对着“笃、笃、笃”的话筒不好气地嘀咕了一句：“深更半夜的，发什么神经？”
pagenumber_ebook=137，pagenumber_book=2310
其中，md(u，t)∈[0，1]表示开发者与任务的相似匹配程度，当md(u，t)越大，匹配度越高.例如，StackOverflow网站上的一个真实的开发者标签UT={“android”，“html”，“angular”，“css”，“java”}，任务标签为KT={“javascript”，“html”，“angular”，“web-hosting”}，则根据公式(3)的定义，其匹配度为2/7≈0.29.基于标签的相似度计算和推荐算法是目前推荐系统中比较流行的使用方法，但标签自身存在书写规范性或异词同义问题，通常数据预处理阶段需要对标签进行必要的数据清洗或分词处理.
定义3(关联度).假设A={a1，a2，...，an}表示开发者u对任务t的n个交互项集合，v(u，t，ak)表示开发者u对任务t关于交互项ak的执行次数，则开发者u与任务t的关联度(associationdegree)的形式化定义如下：
pagenumber_ebook=137，pagenumber_book=2310
其中，ad(u，t)∈[0，1]，αk∈[0，1]表示任务t的交互项ak的权重因子，且pagenumber_ebook=137，pagenumber_book=2310=1.关联度的定义是对开发者与任务关联关系的定量化分析，是从开发者与任务的动态交互行为分析的角度描述开发者与任务关联关系的强弱程度.其中：任务t可看作开发者执行的目标对象，如互联网技术社区、开源社区、软件众包平台上的开发项目、开发任务、缺陷、帖子、问答、评论等；而动态交互项则可看作是对项目、任务、缺陷、帖子、问答、评论等执行、访问、提交、下载、回答、点赞、分享、‘@’等一系列动作集合.
3多特征融合的开发者推荐方法及实践
为了解决协同过滤开发者推荐系统实践过程中存在的评价矩阵稀疏和冷启动问题，本文提出一种能力与行为多特征融合的协同过滤开发者推荐方法，其基本思想是，通过分析开发者动态行为特征并利用矩阵分解拟合技术对评价矩阵进行增强优化，通过对增强后的评价矩阵、开发者能力特征和开发者-任务相似匹配度特征融合，实现多特征融合的协同过滤开发者推荐方法.实现原理如图1所示.
·序号①是为解决评价矩阵的数据稀疏性问题，首先通过开发者与任务的交互关联关系对稀疏的原始评价矩阵Rinit进行增强优化，生成增强优化后的矩阵Rad.
·其次，如序号②所示，为了通过矩阵分解拟合来预测评价矩阵中的未知项，对Rad进行矩阵分解生成拟合后的评价矩阵Rmf.
·然后，如序号③所示，为提升开发者推荐结果的准确性、相关性、可解释性问题，通过对增强后的开发者评价矩阵、开发者-任务相似匹配关系、开发者能力多个特征进行加权融合来构造多特征融合后的评价矩阵Rmfd，根据融合后的评价Rmfd查询相似任务，构造相似任务集合.
·最后，基于协同过滤推荐算法，生成TOP-K推荐列表.
第3.1节为基于开发者行为感知的评价矩阵增强优化方法，第3.2节为评价矩阵分解优化方法，第3.3节为协同过滤的开发者推荐生成算法，第3.4节为大数据环境下多特征融合推荐系统实践.
3.1基于开发者行为感知的评价矩阵增强方法
令Rinit表示任务-开发者初始评价矩阵，pagenumber_ebook=138，pagenumber_book=2311表示针对任务t，开发者u获得的初始评价值，pagenumber_ebook=138，pagenumber_book=2311描述的是开发者关于任务获得的“显式”评价.由于初始评价矩阵Rinit存在数据稀疏问题，甚至很多开发者或技术社区不存在“显式”的评价矩阵.为了解决这一问题，本节提出基于开发者行为感知的开发者评价矩阵增强方法，其核心思想是，为任务推荐开发者时，不仅考虑开发者与任务的“显式”评价关系，同时综合考虑开发者与任务的“隐式”交互行为关系.对pagenumber_ebook=138，pagenumber_book=2311增强优化的形式化描述如下：
pagenumber_ebook=138，pagenumber_book=2311
其中，σ∈[0，1]为权重因子，pagenumber_ebook=138，pagenumber_book=2311表示增强后评价值，ad(u，t)(见公式(4))为开发者与任务的动态交互关联关系.初始评价矩阵是对开发者“显式”评价特征的描述，而开发者与任务的交互关系则是开发者与任务之间行为特征的刻画，是“隐式”特征的量化.公式(5)通过引入开发者行为特征来增强评价矩阵，能够有效增强评价矩阵中的已知项数量，解决评价矩阵数据稀疏所造成的推荐精确度低及冷启动问题.图2给出了任务-开发者评价矩阵增强的示意图，白色圆点格子表示初始评矩阵中的已知项，灰色圆点格子是加入开发者动态交互行为ad(u，t)对评价矩阵增强后产生的已知项.
3.2基于矩阵分解的评价矩阵优化方法
为了提升推荐系统预测的准确性，同时降低大数据环境下评价矩阵因高维、稀疏所导致的计算复杂性问题，本节基于矩阵分解(maxtrixfactorization，简称MF)技术[3]，对第3.1节增强后的开发者评价矩阵R′进行分解和拟合优化，以便更好地预测出评价矩阵中存在的未知项.矩阵分解方法在解决大数据环境下评价矩阵的数据稀疏、高维等问题方面，相对于SVD、近邻模型和受限波兹曼机等方法，不仅计算简单而且可用性好[8].
如图3所示，其核心思想是，将开发者能力特征和任务特征投影到同一个低维的隐因子空间(latentfactorspace)Γd中，d表示空间维度，假设每个开发者u对应一个隐因子向量Qu∈Γd，每个任务t对应一个隐因子向量Pt∈Γd，则开发者u对于任务t的评价关系近似为pagenumber_ebook=139，pagenumber_book=2312，其中，Qu中每个元素代表开发者u在对应的隐因子上的隶属度.同理，Pt中的每个元素表示任务t在对应隐因子上的隶属度.开发者评价矩阵分解的目的是求解向量pagenumber_ebook=139，pagenumber_book=2312和Qu的内积，假设pagenumber_ebook=139，pagenumber_book=2312表示矩阵分解拟合后的评价值，则pagenumber_ebook=139，pagenumber_book=2312.为求解pagenumber_ebook=139，pagenumber_book=2312，采用最小化平方误差法定义损失函数，假设D为评价矩阵R中的已知项集合，则最小化损失函数定义如下：
pagenumber_ebook=139，pagenumber_book=2312
其中，||?||是对向量求范数；pagenumber_ebook=139，pagenumber_book=2312是正则化因子，目的是防止最小化损失函数求解存在过拟合(overfitting)问题；λ∈[0，1]为实验调节因子.但公式(6)并未考虑实际应用中可能存在的评价偏差，例如有些开发者偏向评价低分(过于苛刻)，有些任务的评价偏高(故意炒作或人为作弊)等.显然，评价矩阵具有一定的主观性，容易受到不确定因素的影响而产生偏差，这种偏差影响了整体评价结果的可信性.针对这一问题，本文提出在公式(6)的基础上进行偏差修正处理，给出带偏置项的矩阵分解方法如下：
pagenumber_ebook=139，pagenumber_book=2312
其中，r为评价矩阵Rad中元素的平均值，bu是开发者u的评价偏差，bt是任务t的评价偏差.对公式(7)采用随机梯度下降法(stochasticgradientdescent，简称SGD)[4]求解，SGD与交替最小二乘法相比，在解决数据稀疏问题、模型精度、运算速度方面具备明显优势，适合于解决大数据量的最优化求解问题.基于随机梯度下降法对公式(7)进行求解得到的参数更新过程如公式(8)所示.
pagenumber_ebook=139，pagenumber_book=2312
其中，pagenumber_ebook=139，pagenumber_book=2312为评价误差，η是学习速率调节因子.根据公式(8)的计算结果，求出预测的评价矩阵为Rmf，其对应元素的计算方法如下：
pagenumber_ebook=139，pagenumber_book=2312
公式(9)给出了分解拟合后的评价矩阵，目的是借助矩阵分解和再拟合过程来预测评价矩阵中存在的未知项，从而进一步解决评价矩阵的数据稀疏和冷启动问题，提高开发者推荐系统的预测准确性.
3.3多特征融合的协同过滤开发者推荐方法
推荐系统领域的特征融合主要包括模型融合和推荐结果融合两种方式[22].模型融合是相对于推荐结果融合而言，是将多个特征模型作为输入，输出融合后的特征模型，在此模型基础上进行推荐结果的计算.而推荐结果融合则是基于多个特征模型的单独计算，在对各自的推荐结果按不同策略进行融合的方式.基于这一思想，在公式(9)的基础上，进一步融合开发者能力、任务-开发者的匹配度静态特征，基于多特征融合的方式提升协同过滤推荐结果的准确性、相关性和可解释性.令Rmfd表示多特征融合优化后的评价矩阵，pagenumber_ebook=140，pagenumber_book=2313表示开发者融合推荐值，则其计算过程如下：
pagenumber_ebook=140，pagenumber_book=2313
其中，pagenumber_ebook=140，pagenumber_book=2313，dcm(u)，md(u，t)分别由公式(9)、公式(2)、公式(3)定义.λ1，λ2，λ3∈[0，1]为权重因子，且满足条件λ1+λ2+λ3=1.公式(10)基于多特征推荐融合给出了开发者综合评价结果，从多个特征维度进行了综合考虑，既降低了评价矩阵稀疏性问题、冷启动问题对推荐结果的影响，同时又从不同维度对开发者能力进行了整体度量，提高了推荐结果的可信性和可解释性.而且更重要的是，通过对λ1，λ2，λ3权重的动态调整，能够满足不同企业、技术社区、软件众包平台对开发者能力特征的关注重点.例如，对于大型IT企业而言，更侧重于开发者的个人能力，则λ2可以给予较大权重；对于中小型企业而言，由于受到企业规模和成本的限制，更关注开发者技能匹配度和业务熟练程度，则λ3可以给予较大权重；而对于初创企业，比较看重开发者的新技术关注度、社区活跃度等，则λ1的权重设置较大.
基于评价矩阵Rmfd给出多特征融合增强的协同过滤开发者推荐(multi-featurefuseddeveloperrecommendation，简称MFD_Rec)，其算法的伪代码描述见算法1.首先，根据公式(11)计算任务之间的相似度tsd(tasksimilaritydegree)；然后，对每个任务i，找到与其最相似的s个任务集合Ti={t1，t2，…，ts}，查询Ti中任务关联的开发者并排除任务i已拥有的开发者，形成对应开发者集合U={u1，u2，…，ux}，对U中每个开发者，计算tsd(i，j)?pagenumber_ebook=140，pagenumber_book=2313，将计算结果存储在list中，对list排序，并返回list的top-k个元素所对应的开发者.
算法-FeatureFusedDeveloperRecommendation(MFD_Rec).
Input：Rmfd，k；/*Rmfdisfusedratingmaxtrix，kisthenumberofresult
Output：top-kdevelopers/*theresultlist
1：fori=0ton-1/*i，jistheindexoftask，nisthenumberoftask
2：forj=i+1ton/*inittasksimilaritydegreebyEq.(11)
3：a[i?(i+j)/2+j]←tsd(i，j)；/*aisanarraytostorecompressedmaxtrix
4：endfor
5：endfor
6：fori=0ton-1
7：Ti[0…s-1]←geti’stop-sneighborsbasedarraya；
8：forj=0tos-1/*getneighbors’developers
9：U[0…x]←getdevelopersrelatedtoTi[j]&&developersnotrelatedtoi；
10：foruinU[0…x]
11：list[u]←tsd(i，Ti[j])pagenumber_ebook=140，pagenumber_book=2313；/*tsd(i，Ti[j])byEq.(11)，pagenumber_ebook=140，pagenumber_book=2313byEq.(10)
12：endfor
13：endfor
14：endfor
15：sort(list)；/*sortthelistorderbylistelementdesc
16：returntop-kdevelopers；
如公式(11)所示，对任务相似性计算，由于余弦相似度计算方法更多的是从方向上区分差异，而对绝对的数值不敏感，因此难以衡量每个维度上数值的差异：
pagenumber_ebook=141，pagenumber_book=2314
基于这一问题，本文给出基于修正的余弦相似度算法(adjustedcosinesimilarity)[3]来求解任务之间的相似性，其优点在于考虑了不同开发者的评分尺度问题，通过减去每个维度上的平均值，降低了相似度计算的误差.另外，由于相似度矩阵是对称矩阵，所以算法1中借助一维数组a对相似度矩阵进行了压缩存储优化，如算法1中的第3行语句描述.
算法1是在评价矩阵增强、分解拟合、多特征融合优化的基础上给出的协同过滤推荐方法，从评价矩阵增强的基础上提出了基于多特征融合的协同过滤开发者推荐方法实现.
3.4大数据环境下开发者推荐系统实践
本节在多特征融合开发者推荐算法基础上实现了面向大数据环境的开发者实时推荐系统，包括数据实时采集、预处理、索引、存储、特征提取和实时计算过程.系统基于ElasticSearch(以下简称ES)、Spark等目前业界最流行的开源技术框架实现，能够满足大数据环境下开发者推荐系统的实时计算、大并发、水平伸缩性和可用性要求.如图4所示为系统整体实现框架，核心部件包括数据采集工具(爬虫工具Crawler、日志数据收集工具Logstash、网络抓包工具PackageBeta)、数据预处理和索引工具Logstash、数据存储检索框架ES、计算框架Spark等.系统支持处理PB级结构化或非结构化数据，具备s级的查询处理延迟，支持对互联网技术社区页面数据抓取和企业内部GitLab数据的实时采集.对企业内部数据，支持通过数据监听Agent(Logstash，PackageBeta，Webhooks)进行实时采集；对互联网数据源，支持通过爬虫(Crawler)工具爬取.数据采集后，通过ApacheKafka消息中间件进行消息缓存和中转分发，并借助Logstash进行预处理和索引，通过ES进行分片存储检索，并基于Spark的Map和Reduce实现开发者能力特征提取、开发者交互行为数据提取、相似度、匹配度计算、矩阵分解拟合计算、多特征融合计算等，最终实现多特征融合的协同过滤推荐和推荐列表展现.
4实验结果与分析
4.1数据集及实验设置
为了验证本文提出的多特征融合开发者推荐方法的有效性，分别选取互联网技术问答社区StackOverflow数据集和东软集团企业内部GitLab数据进行了分析，数据集描述见表3.实验过程采取分组进行的方式，将数据等分为10组，采用交叉验证的方式，即对数据集划分为10等份，每次选取一组数据作为测试集，其他组作为训练集，最终取平均值.系统软硬件环境配置见表4，核心参数设置见表5.
4.2数据特征映射
本节给出开发者能力特征模型与真实数据源之间的特征实例化映射和计算过程描述.为了保证特征实例化的合理性，通过参考对东软集团多位技术专家的建议，确定出特定数据源下的开发者能力特征映射方法及相应权重设置，具体过程描述如下.此外，关于多变量权重的最优化取值问题是下一步工作的研究内容之一，本文仅给出了基于经验值和枚举实验的方式对不同权重进行调整，以试图尽可能地保证权重设置的合理性.特征映射的选取方面，根据历史经验，由于开源社区与企业内部在数据结构和对开发者关注点不同，开源社区往往更加注重开发者的声誉和影响程度；而企业由于人员规模相对较小，往往侧重于开发者工作效率、行为活跃度等特征，因此，本文在StackOverflow和GitLab的开发者特征映射和选取上的侧重点也有所不同.
(1)StackOverflow特征映射
通过分析StackOverflow数据集和实体结构关系，并结合定义1给出基于StackOverflow的开发者能力特征模型的特征映射实例化.假设能力特征C={c1：“开发者声誉”，c2：“影响范围”，c3：“被关注度”}，对应权重W={w1：0.5，w2：0.2，w3：0.3}.其中，rep(u)，imp(u)，pv(u)分别映射StackOverflow的User实体对应的reputation，impact，profileview属性，|U|表示开发者集合U的元素数.能力特征计算方法为
pagenumber_ebook=142，pagenumber_book=2315
对于初始评价矩阵Rinit的映射计算，基于StackOverflow的任务-回答者的投票值进行了归一化处理，计算方法为
pagenumber_ebook=142，pagenumber_book=2315
其中，vote(t，u)为开发者u关于任务t获得的评分值.
对于开发者与任务关联度ad(u，t)的映射计算，设开发者与任务的交互项集合为A={a1：“回答”，a2：“收藏”，a3：“评论”，a4：“浏览”}，假设对应权重α={α1：0.4，α2：0.2，α3：0.3，α4：0.1}.其中，ad(u，t)的计算方法见定义3中的描述.对于开发者与任务的匹配度md(u，t)计算过程见定义2中的描述.
(2)GitLab特征映射
同理，给出GitLab的数据源特征映射及实例化.能力特征C={c1：“活跃度”，c2：“任务参与度”，c3：“贡献度”}，对应权重设为W={w1：0.2，w2：03，w3：0.5}.假设sigin(u)，assign(u)，push(u)表示映射到GitLab上Users实体的sign_in_count(登录次数)属性、Issues实体的assignee_id(任务执行者)属性、Events实体的push(代码提交)属性上的计算方法.其中，sigin(u)表示开发者u的登录次数，assign(u)表示开发者u被指定任务指派者的次数，push(u)表示开发者u代码提交数.计算方法分别为
pagenumber_ebook=143，pagenumber_book=2316
对于开发者与任务关联度rd(u，t)的映射计算，开发者与任务的交互项集合A={a1：“评论”，a2：“@”，a3：“点赞”，a4：“浏览”}，对应权重α={α1：0.4，α2：0.4，α3：0.1，α4：0.1}.计算方法见定义3中的描述.对于开发者与任务的匹配度md(u，t)，由于本实验项目的GitLab软件版本不支持开发者标签属性，所以对GitLab开发者在数据预处理阶段进行了标注处理.
4.3评测方法确立
实验采用离线评测的方式进行，评价指标选取推荐系统中通用的平均准确度(meanaverageprecision，简称MAP)和覆盖率(coverage)评价指标.MAP评价指标主要用于衡量推荐结果排序的好坏程度，其中，准确度指标(ap)的计算方法如公式(12)所示.
pagenumber_ebook=143，pagenumber_book=2316
其中，
·len表示推荐列表长度；
·predictioni表示前i个推荐结果的正确率；
·(changeinrecall)i为二值项：当第i个推荐结果正确时(推荐结果的正确性判定，是通过将分组实验的推荐结果与测试集中的真实结果对比得出)，值为1/len；否则为0.最终，平均准确度MAP是对所有推荐结果的(ap)取平均值.
关于公式(12)的详细说明见文献[23].
Coverage评价指标主要衡量推荐结果的覆盖范围，尽可能地让更多的开发者都有机会被推荐，避免只有少数的开发者被推荐的而出现的马太效应.Coverage评价指标定义为被推荐的开发者数量占开发者总数的比例，其计算过程如公式(13)所示.
pagenumber_ebook=143，pagenumber_book=2316
其中，T为任务集合，U为开发者集合，u(t)表示推荐给任务t的开发者集合.
4.4实验结果分析
通过实验，分别给出本文所提出的多特征融合协同过滤方法与目前典型的协同过滤推荐方法的对比分析.其中，BaseCF_Rec是基于原始评价矩阵Rinit实现的协同过滤开发者推荐方法，作为基线对比算法，协同过滤推荐算法原理参见文献[14].MFCF_Rec是基于矩阵分解(Rad)的协同过滤推荐算法，MFCF_Rec未考虑用户能力与行为感知对评价矩阵的增强作用，MFCF_Rec是目前协同过滤推荐算法中典型的算法实现，矩阵分解算法原理参见文献[4，8]中的描述.BaseCF_Rec与MFCF_Rec方法的区别在于，BaseCF_Rec针对原始评价矩阵进行协同过滤计算；而MFCF_Rec方法则是在原始评价矩阵基础上先进行了矩阵分解拟合，在拟合后的矩阵上再进行协同过滤计算.因为MFCF_Rec借助矩阵分解拟合原理降低了矩阵稀疏性，所以使得其推荐效果比BaseCF_Rec要好.而本文提出的MFD_Rec方法与BaseCF_Rec与MFCF_Rec的区别在于，MFD_Rec是基于能力与行为感知多特征融合评价矩阵(Rmfd)增强的评价矩阵基础上进行的协同过滤开发者推荐方法.
(1)平均准确度MAP分析
如图5所示，分别基于StackOverflow和GitLab数据集进行推荐算法的平均准确率指标MAP对比分析.
由于BaseCF_Rec是基于原始评价矩阵Rinit进行的协同推荐算法，原始评价矩阵的稀疏问题导致了平均推荐准确度非常低(StackOverflow为0.19，GitLab为0.25).而本文提出的多特征融合增强的推荐方法MFD_Rec相对于BaseCF_Rec，MFCF_Rec算法具有非常好的平均推荐准确度(StackOverflow为0.43，GitLab为0.67).另外，StackOverflow相对于GitLab数据源而言，平均准确度较低.主要原因是企业内部GitLab数据集中的开发者数量较少，但网络抓包数据中存在大量用户访问交互的行为数据，这使得开发者与issue的交互行为产生的关联关系非常紧密，开发者与任务的交互行为对解决评价矩阵的数据稀疏问题起到重要作用.
(2)平均覆盖率Coverage分析
如图6所示是对平均覆盖率的对比分析，由于对评价矩阵从多个特征维度的增强，使得评价矩阵中的未知项所占的比例平均减小了78.43%.对于StackOverflow数据集，MFD_Rec比MFCF_Rec覆盖率平均提升约1.71倍，比BaseCF_Rec覆盖率平均提升约2.36倍.而对于GitLab数据源而言，MFD_Rec比MFCF_Rec的覆盖率平均提升约1.31倍，比BaseCF_Rec覆盖率平均提升约3.42倍.由于StackOverflow评价矩阵比GitLab评价矩阵更为稀疏，使得对StackOverflow运用多特征融合增强后的平均覆盖率提升效果也比较显著.这表明，MFD_Rec方法与MFCF_Rec，BaseCF_Rec方法相比，推荐结果的覆盖率提升也比较明显.
(3)特征权重因子影响分析
为了进一步分析不同特征权重对推荐结果的影响，基于StackOverflow数据集，分别对权重因子λ1，λ2，λ3给出不同的权重组合，通过权重因子递增或递减调整验证对推荐结果的影响.如表6所示给出TOP10推荐过程中的结果分析，第1行作为基线对比，从序号2对应的数据可见，当固定λ1为0.33，增加λ2为0.60，λ3调整为0.07时，评价指标MAP和Coverage分别下降35.34%和37.18%.这是由于数据集中存在大量能力特征值很高的开发者，但这些开发者与特定任务的关联关系和匹配度又都非常小(遵循复杂网络的无标度特征)，因此，如果给予λ2过高权重，可能导致每次只有少数的能力特征值高的开发者被推荐，即所谓的马太效应.对于序号4，当固定λ2为0.33，增加λ1为0.60，λ3调整为0.07时，评价指标MAP和Coverage分别上升7.69%和17.78%.主要是因为增加了用户动态行为关联关系和矩阵分解对协同过滤推荐增强的结果.对于序号7，当固定λ3为0.33，增加λ1为0.60，λ2调整为0.07时，评价指标MAP和Coverage分别上升12.82%和26.67%.可见，给予λ1，λ3适当高的权值，能够提升推荐结果的准确率和覆盖率.对于开发者个体能力特征，通常大型IT企业更关注开发者个体能力，例如，面试时往往会参考开发者在开源社区的贡献和影响力等特征指标，即使被推荐的开发者与项目或者任务的匹配度、关联度不高，企业也愿意承担短期的培训成本.
(4)冷启动案例分析
为了证明本文推荐方法对冷启动问题的效率提升，选取GitLab上新创建的状态为“open”且未指派负责人的105个典型issue进行冷启动问题案例分析.由于选取的案例对应初始评价矩阵Rinit的数据非常稀疏，导致现有协同过滤推荐方法的准确率和覆盖率都很低.但通过对开发者行为数据分析发现，在新创建的issue中，约32.19%的issue都有被不同开发者点赞、浏览、评论、‘@’等行为数据存在，且不同开发者与issue关联关系的强弱程度也各不相同.基于本文定义的GitLab特征映射计算方法，并根据定义3中给出的开发者行为关联关系对开发者进行推荐算法生成，针对选取的样本数据的进行对比实验分析的结果如图7所示.
从图7可以看出，即便在评价矩阵稀疏的情况下，MFD_Rec方法由于借助了开发者能力和行为感知的特征融合方法，相对于现有技术方案也具备明显优势.在冷启动状态下，MFD_Rec的平均准确率为0.16，平均覆盖率为0.45，比BaseCF_Rec的平均推荐准确率提升2.67倍，平均覆盖率提升1.33倍；比MFCF_Rec的平均推荐准确率提升63.13%，平均覆盖率提升80.96%.从GitLab的冷启动案例的分析结果可以看出，MFD_Rec对冷启动问题的推荐准确度和覆盖率相对于现有方法具有明显的改善.
(5)不同特征组合分析
为了进一步分析单一特征和多特征组合下算法效率，基于GitLab数据集对不同特征组合进行对比分析，假设F1，F2，F3分别表示公式(10)中的pagenumber_ebook=146，pagenumber_book=2319，dcm(u)，md(u，t)对应的特征项.如图8所示.
·F1+F2相对于F1，平均准确度指标非常接近，但平均覆盖率指标却有所提升.这表明单纯的dcm(u)对平均准确度影响较小，但对覆盖率却有很好的提升作用.
·F1+F3相对于F1+F2有较好的平均准确度和覆盖率，这表明单纯的开发者与任务匹配度对推荐结果的影响大于开发者能力特征的影响.
·F1+F2+F3相对于F1，F1+F2或F1+F3来说有更好的推荐准确度和覆盖率，可见，F1+F2+F3相对于单一特征或单一特征组合的实现方式具有很好的效果.
5总结
本文从开发者推荐系统实践过程中存在的开发者能力评价问题、数据稀疏问题、大数据环境下推荐系统构建问题出发，提出了基于模糊综合评价的开发者能力评价模型.在此基础上，借助矩阵分解技术对评价矩阵增强优化，提出一种能力和行为感知的多特征融合协同过滤开发者推荐方法，有效解决了开发者推荐过程中存在的数据稀疏性、冷启动等问题.从工程实践角度出发，给出面向大数据环境的推荐技术方案选型、系统实现及优化过程的阐述.最后，对互联网问答社区StackOverflow数据集和东软集团企业内部GitLab的真实生产环境进行了实验分析，从不同评价指标维度给出了本文方法的有效性证明.
未来的工作将研究面向特定应用领域大项目、跨部门协作环境下的开发者协作团队推荐模型，构建协作关系在线实时推荐服务框架，解决目前IT企业DevOps开发运维一体化支撑普遍面临的多项目、大规模、多版本、跨团队协作开发、持续交付过程中面临的协作效率低下、沟通成本过高的问题.
致谢本文在实验分析、论文撰写和系统实践过程中得到了东软集团基础软件事业部架构师王伟、研发工程师王汉冲等人的支持和帮助，在此一并表示感谢.