Page 68 - 《软件学报》2025年第5期
P. 68

1968                                                       软件学报  2025  年第  36  卷第  5  期


                    在上述方法中, LightGCL    与  R-NGCF  的推荐质量较低, 它们仅从       Mashup  服务与  Web API 的组合调用关系建
                 立异质图模型, 通过相似       Mashup  服务进行  Web API 推荐, 在部分组件     Web API 已知的情况下具有较好的推荐效
                 果; 在需要获取全部组件       Web API 时, 推荐质量较差. SRMG     使用  BERT  模型生成服务功能向量进行功能匹配, 通
                 过  Mashup  服务-Web API 异构图获取交互信息, 但推荐评分时没有根据候选               Web API 对需求的潜在功能参与度
                 分配注意力权重, 容易推荐出功能匹配度低的              Web API.
                    DLOAR  提出了三级相似度匹配机制, 能够获取与             Mashup  服务需求相似度高的组件        Web API. 然而, 其仅考
                 虑功能需求的匹配, 忽视了组件          Web API 间的功能互补, 缺乏对推荐列表整体兼容性的考量, 容易推荐大量功能
                 相似的   Web API. MISR  使用  CNN  提取服务功能特征, 通过相似度为       Mashup  服务需求查找邻居      Mashup  服务, 提
                 升了协同过滤的效果, 该方法利用           3  种类型的交互信息对服务节点向量化, 提高了候选组件对于                  Mashup  服务需
                 求的评分合理性, 一定程度上提升了推荐质量.
                    DySR  明确提出组件     Web API 多样性概念, 从服务功能语义匹配与          Web API 协作两方面进行推荐, 在四种对
                 比方法中推荐质量最高. 相比本文方法, 该方法欠缺对服务潜在应用场景词的考虑, 无法从外界获取更丰富的特征
                 提升功能匹配的合理性, 缺乏         Web API 标签所代表的功能关联考量, 因此, 其推荐质量低于本文方法.

                 4.3.4    冷启动  Web API 推荐性能评估
                    冷启动是推荐系统所面临的一个重要问题. 在为                Mashup  服务需求推荐    Web API 时, 冷启动  Web API 是指新
                 发布未参与过真实       Mashup  服务构建的服务.
                    在理论上, 本文构建的二阶候选组件            Web API 集合  Cw-2(mr) 中可以有效地将与    Mashup  服务需求  mr 相关的
                 冷启动   Web API 纳入到候选组件     Web API 集合中, 从而为冷启动      Web API 提供参与推荐的机会. Cw-1(mr) 是一
                 阶候选组件    Web API 集合, 该集合采用协同过滤思想构建, 将与需求              mr 相似的  Mashup  服务中的真实组件      Web
                 API 放置在集合    Cw-1(mr) 中, 而  Cw-2(mr) 在构建时, 是将与  Cw-1(mr) 中的  Web API 相似度高的服务纳入到该集
                 合中, 因此, 若冷启动    Web API 和  Cw-1(mr) 中的某个  Web API 相似度高, 该  Web API 可以进入  Cw-2(mr) 集合, 从
                 而参与最终的     Web API 推荐.
                    由于  Web API 在发布后, 通常需要经历一段时间的使用才有可能被选中参与                    Mashup  服务的构建. 此外, 并非
                 所有新发布的     Web API 都会参与   Mashup  服务的构建. 为了验证本文方法对冷启动            Web API 的推荐能力, 将只参
                 加过一次   Mashup  服务创建的   Web API 作为冷启动推荐对象, 将其所在的           Mashup  服务功能描述作为     Mashup  服
                 务需求.
                    经过统计, 共计     392  个包含只参与一次     Web API 的  Mashup  服务, 将它们的服务描述作为      Mashup  服务需求,
                 利用本文方法进行       Web API 推荐, 划分为   4  个数据集, 见表   5. 数据集采取增量式划分, DS2       中的训练集    Mashup
                 服务即为   DS1  中训练集和测试集      Mashup  服务总和, DS3  与  DS2、DS4  与  DS3  的关系类同.

                                                 表 5 冷启动    Web API 数据集

                             数据     训练集Mashup服务个数       测试集Mashup服务个数     测试集中冷启动Web API个数
                             DS1           4 913               100                 100
                             DS2           5 013               100                 100
                             DS3           5 113               100                 100
                             DS4           5 213               92                   92

                    在指标   Recall、Precision、NDCG  和  ILS  基础上, 增加命中率  (hits ratio, HR) [4,42] 评估模型对冷启动  Web API
                 的推荐效果, 见公式      (37):

                                                          1  ∑ N
                                                     HR =       hit(i)                               (37)
                                                          N   i=1
                 其中, N  为参与测试的    Mashup  服务总数. 若冷启动    Web API 作为正例出现在推荐列表, hit(i) 值为      1, 否则为  0.
                    采用本文方法在       DS1–DS4  数据集进行对比, 推荐质量指标如表          6  所示. 从表中数据统计可知, 在       Top-3  推荐
                 时, 冷启动  Web API 推荐对应的    Recall 与  Precision  约占非冷启动  Web API 对应  Recall 与  Precision  的  49.2%  与
   63   64   65   66   67   68   69   70   71   72   73