CN114661872A - 一种面向初学者的api自适应推荐方法与系统 - Google Patents

Abstract

本申请提供一种面向初学者的API自适应推荐方法，属于API技术领域。包括：解析API文档，得到多个API元素以及多个API元素之间的第一关联关系；基于多个API元素以及多个API元素之间的关联关系，构建具有多类API实体的初始知识图谱；每类API实体均具有多个相互连接的API实体；获取多个SO讨论帖；在初始知识图谱中，构建每个SO讨论帖与对应的目标API实体之间的第二关联关系，得到目标知识图谱；将目标知识图谱上的多个API实体，聚类为不同的API实体组，以构建不同的学习入口。使用本申请提供的自适应推荐方法，可以为初学者推荐所需的学习入口。

Description

一种面向初学者的API自适应推荐方法与系统

技术领域

本申请实施例涉及API技术领域，具体而言，涉及一种面向初学者的 API自适应推荐方法与系统。

背景技术

软件开发工具包(Software Development Ki，SDK)是一系列开发工具 的集合，在应用软件开发领域中，SDK通常会提供一系列不同的应用程序编 程接口(ApplicationProgramming Interface，API)供开发者使用。

一个完整的整的SDK往往囊括了成千上万个API，来实现SDK在开发 的不同层面提供的功能。对于软件开发的初学者而言，直接遍历、学习并理 解一个SDK中所有的API是不现实的，初学者往往需要根据自己的需求与 兴趣，来寻找一组API来作为一个学习入口，再以该学习入口为基础继续进 行学习。

对于缺乏经验的初学者而言，寻找一组API作为学习入口是困难的，初 学者在面对一个陌生的SDK时，由于初学者并不知道SDK中各类API的 API限定名(API限定名指的是API的官方名称)，所以在对各类API的学 习资料进行搜索时，往往会输入与API限定名并不相符的API名称，从而无 法获得与API相关的学习资料，难以获取到一个学习入口。

发明内容

本申请实施例提供一种面向初学者的API自适应推荐方法与系统，旨在 为初学者推荐自身所需的学习入口。

本申请实施例第一方面提供一种面向初学者的API自适应推荐方法，其 特征在于，所述方法包括：

解析API文档，得到多个API元素以及多个API元素之间的第一关联 关系；

基于多个API元素以及多个API元素之间的关联关系，构建具有多类API实体的初始知识图谱，每类API实体用于描述一种API；每类API实体 均具有多个相互连接的API实体，API实体之间相连接的边表征所述第一关 联关系，所述第一关联关系至少包括继承关系、包含关系、实现关系；

获取多个SO讨论帖，每个SO讨论帖中包括至少一个API实体指称， 所述API实体指称为所述SO讨论帖中讨论的API元素；

在初始知识图谱中，构建所述每个SO讨论帖与对应的目标API实体之 间的第二关联关系，得到目标知识图谱；

对所述目标知识图谱上的多个API实体进行聚类，得到不同的API实体 组，以构建为不同主题的学习入口。

可选地，构建所述每个SO讨论帖与对应的目标API实体之间的第二关 联关系，包括：

从所述SO讨论帖中提取出API实体指称；

将所述API实体指称分别与所述每类API实体中的多个API实体的API 限定名进行一次匹配，得到与所述API实体指称所匹配的多个第一候选API 实体，所述API限定名为所述API实体的命名；

将所述API实体指称分别与多个第一候选API实体进行二次匹配，得到 与所述API实体指称匹配的目标API实体；

建立所述API实体指称所在的SO讨论帖与所述目标API实体之间的第 二关联关系。

可选地，从所述SO讨论帖中提取出API实体指称包括：

对所述SO讨论帖进行预处理，得到句子的集合；

对所述句子的集合进行处理，得到词汇序列；

在所述词汇序列中，使用API命名实体识别模型标记所述API实体指称 所对应的词汇，作为提取出的API实体指称。

可选地，将所述API实体指称分别与多个第一候选API实体进行二次匹 配，得到与所述API实体指称匹配的目标API实体，包括：

对所述第一候选API实体的API限定名进行抽取，分别得到多个短限定 名；

从所述多个短限定名中，确定被所述API实体指称所包含的短限定名， 以作为目标短限定名；

将所述API实体指称分别与所述目标短限定名所表征的第一候选API 实体进行匹配，得到所述目标API实体。

可选地，将所述API实体指称分别与所述目标短限定名所表征的第一候 选API实体进行匹配，得到所述目标API实体，包括：

采用语义匹配模型，将所述API实体指称的上下文文本，分别与所述目 标短限定名所表征的多个第一候选API实体的描述文本进行语义匹配；

将语义匹配度高于预设匹配度的第一候选API实体，作为所述目标API 实体。

可选地，将所述目标知识图谱上的多个API实体聚类为不同的API实体 组，以构建不同的学习入口，包括：

基于所述目标知识图谱，获取在同一篇SO讨论帖中被讨论超过预设次 数的两个API实体；

将所述两个API实体添加至SO社区知识图谱中，并建立所述两个API 实体之间的第三关联关系；

基于Louvain算法，对所述SO社区知识图谱中每两个所述API实体之 间的第三关联关系进行分析，以将多个API实体聚类为不同的API实体组， 其中，每个所述API实体组中包括多个两两之间具有所述第三关联关系的 API实体；

将每个不同的API实体组，构建为不同API的学习入口。

可选地，所述方法还包括：

在所述目标知识图谱中，建立所述API实体与对应的第一领域术语之间 的第四关联关系，所述第一领域术语来源于所述API文档；

建立所述第一领域术语与第二领域术语之间的第五关联关系，所述第二 领域术语来源于维基百科；

从用户输入的查询文本中，提取出待查询领域术语；

将与所述待查询领域术语匹配的多个第一领域术语所关联的第二候选API实体，以及与所述待查询领域术语匹配的多个第二领域术语所关联的第 三候选API实体，作为候选API列表；

将所述待查询领域术语与所述候选API列表中的所有API实体进行语义 匹配，得到所有API实体的排列顺序；

在所述排列顺序中，推荐位于首位的API实体。

可选地，得到所述多个第一领域术语的排列顺序之后，所述方法还包括：

从用户输入的查询文本中，提取出待查询API限定名；

在所述目标知识图谱中，查询与所述待查询API限定名匹配的API限定 名；

将与所述待查询API限定名匹配的API限定名关联的API实体，置于 所述排列顺序的首位；

推荐所述置于排列顺序首位的API限定名所表征的API实体。

本申请实施例第二方面提供一种面向初学者的API自适应推荐系统，所 述系统包括：

解析模块，用于解析API文档，得到多个API元素以及多个API元素 之间的第一关联关系；

初始知识图谱构建模块，用于基于多个API元素以及多个API元素之间 的关联关系，构建具有多类API实体的初始知识图谱，每类API实体用于描 述一种API；每类API实体均具有多个相互连接的API实体，API实体之间 相连接的边表征所述第一关联关系，所述第一关联关系至少包括继承关系、 包含关系、实现关系；

获取模块，用于获取多个SO讨论帖，每个SO讨论帖中包括至少一个 API实体指称，所述API实体指称为所述SO讨论帖中讨论的API元素；

目标知识图谱构建模块，用于在初始知识图谱中，构建所述每个SO讨 论帖与对应的目标API实体之间的第二关联关系，得到目标知识图谱；

学习入口构建模块，用于对所述目标知识图谱上的多个API实体进行聚 类，得到不同的API实体组，以构建为不同主题的学习入口。

可选地，所述初始知识图谱构建模块包括：

提取模块，用于从所述SO讨论帖中提取出API实体指称；

一次匹配模块，用于将所述API实体指称分别与所述每类API实体中的 多个API实体的API限定名进行一次匹配，得到与所述API实体指称所匹 配的多个第一候选API实体，所述API限定名为所述API实体的命名；

二次匹配模块，用于将所述API实体指称分别与多个第一候选API实体 进行二次匹配，得到与所述API实体指称匹配的目标API实体；

关系建立模块，用于建立所述API实体指称所在的SO讨论帖与所述目 标API实体之间的第二关联关系。

采用本申请提供的面向初学者的API自适应推荐方法，基于该目标知识 图谱，将所述目标知识图谱上的多个API实体，聚类为不同的API实体组， 以构建不同的学习入口，因此可以自动为初学者推荐不同的学习入口，每个 学习入口中均分别汇聚了各自的一组API实体，初学者可以从推荐的多个学 习入口中，找到自身感兴趣的学习入口，由于该学习入口已经包含了自身所 需的一组API实体，因此不必主动建立搜索去寻找一组API实体来作为学习 入口。例如，当用户进入到“字符串操作”这一主题所对应的学习入口后， 可以基于目标知识图谱，为初学者自动地推荐与“字符串操作”相关的一组 API实体，而不必初学者去依次搜索这组API实体的API限定名来寻找这组 API实体，从而帮助初学者更加简便地获取到自身所需的学习入口。

并且基于目标知识图谱，可以自动地为初学者推荐不同学习入口下的高 质量的API学习资料。一方面，在目标知识图谱中，由于SO讨论贴关于 API实际使用场景的讨论质量高于第三方博客与教程网站，且多个API实体 均来源于API文档，API文档中准确全面地记载了各个API实体的功能描述， 所以，本申请基于API实体与SO讨论帖之间的第二关联关系所构建的目标 知识图谱，可以为初学者推荐质量更高且更全面准确的API学习资料；另一 方面，API实体以及API实体之间的第一关联关系可以为初学者提供学习 API实体的功能的途径，SO讨论帖为初学者提供了提供了学习API实体实 际使用场景的途径，二者相互结合，可以便于初学者更加深刻地理解API 实体的使用。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的 描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅 仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性 劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提出的一种面向初学者的API自适应推荐方法的 步骤流程图；

图2是本申请一实施例提出的目标知识图谱的示意图；

图3是本申请一实施例提出的API文档中记录方法实体的结构化信息的 示意图；

图4是本申请一实施例提出的API文档中记录继承关系的结构化信息的 示意图；

图5是本申请一实施例提出的API命名实体模型的架构示意图；

图6是本申请一实施例提出的LTSM的神经元结构；

图7是本申请一实施例提出的SO社区知识图谱的示意图；

图8是本申请一实施例提出的语义匹配模型的架构示意图；

图9是本申请一实施例提出的SO讨论帖-API实体关联的整体流程图；

图10是本申请一实施例提出的基于目标知识图谱所能提供的功能图；

图11是本申请一实施例提出的面向初学者的API自适应推荐系统的结 构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行 清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是 全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创 造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请中，对于缺乏开发经验的初学者而言，学习SDK中的API并不 是简单的过程，学习的过程中，初学者往往会遇到以下两方面的困难：

第一个困难是：初学者难以找到自身所需的学习入口。

无经验的初学者初学者往往有着自己的个性化学习需求，对SDK某一 具体的功能比较感兴趣，需要寻找与SDK某一具体功能相关的一组API， 来作为学习入口，来进行初步的学习。

然而，对于缺乏经验的初学者而言，寻找一组API作为学习入口是困难 的，初学者在面对一个陌生的SDK时，由于初学者并不知道SDK中各个 API的API限定名(API限定名指的是API的官方名称)，所以在对API的 学习资料进行搜索时，往往会输入与API限定名并不相符的API名称，从而 无法获得与API相关的学习资料，难以获取到自身所需的学习入口。

第二个困难是：初学者难以找到高质量API学习资源。API学习资源是 指开发者在学习API使用时所参考的文档、文章、教程、代码示例等资源。 目前，有经验的开发者主要通过四种网络渠道获得API相关的学习资源： API文档、SDK的官方教程、由其他开发者分享的第三方博客与教程网站以 及Stack Overflow(SO)、思否(Segment Fault)等开发者的讨论社区。

其中，对于API文档而言，API文档提供了有关API功能、API使用参 数等情况的详细说明，且会随着SDK版本的更新而及时更新。然而，API 文档是对API基本功能的文档化描述，并不包含如何在实际开发场景下使用 API的相关知识。因此，API文档往往更适合已经有SDK相关开发经验的开 发者来进行查阅，而不适合对SDK的初学者提供学习上的支持。

其中，对于SDK的官方教程而言，部分SDK开发者或开发商会官方提 供SDK的使用教程与代码示例，指导开发者学习如何使用SDK中的各种 API。然而，官方的教程和示例往往仅对几种基础的使用场景中部分常用API 的使用方式进行展示，这是因为SDK本身提供的API往往数量庞大、使用 场景繁多，官方无法一一涉及。同时，部分API的实现可能存在错误，或使 用时有注意事项，而这些都是鲜少会被官方提及的。对于不同开发者多样的 学习需求，官方的学习资源是不充足的。

其中，对于其他开发者分享的第三方博客与教程网站而言，博客等第三 方资源分散在不同的Web站点中，彼此之间非常独立，开发者几乎只能通 过诸如Google、百度等搜索引擎对这些站点中的资源进行搜索。而缺乏经验 的初学者往往针对自己需要学习的内容无法构建起有效的检索，导致这些第 三方资源很难被他们快速找到。同时，由开发者自己单独写成的博客或教程 的质量取决于开发者本人的水平，且开发者自己分享的文章中也有可能会出 现错误。

其中，对于SO讨论帖而言，由于SO讨论帖中的问题几乎都是有关各 个开发者在实际开发过程中遇到的问题或实现的功能，因此SO讨论帖中存 在大量关于API在实际使用场景中的使用知识。然而，SO讨论帖缺少帮助 初学者找到API相关讨论帖的方法，这是因为SO讨论帖是一个开发者交流 问题的社区，而不是一个API学习站点。SO讨论帖在社区内提供了搜索引 擎，帮助开发者通过关键字找到自己可能感兴趣的帖子，但是由于初缺乏经 验的初学者往往针对自己需要学习的内容无法构建起有效的检索，仍然无法 找到所有自己感兴趣的知识。

可见，虽然网络上公开了各个API的学习资源，但是初学者经验不足难 以构建有效的搜索，来搜索到各类API学习资源，并且即使初学者寻找到一 组API作为学习入口，由于API的学习资源的质量参差不齐，初学者也无法 分辨API学习资源的质量好坏，同样也不利于初学者学习API的使用。

在面临初学者难以找到自身所需的学习入口，以及难以找到高质量API 学习资源这两种困难的基础上，本申请建立了目标知识图谱，该目标知识图 谱中包含了多类API实体，以及与每类API实体中的每个API实体之间具 有第二关联关系的SO讨论帖。

首先，基于该目标知识图谱，将所述目标知识图谱上的多个API实体， 聚类为不同的API实体组，以构建不同的学习入口，因此可以自动为初学者 推荐不同的学习入口，每个学习入口中均分别汇聚了各自的一组API实体， 初学者可以从推荐的多个学习入口中，找到自身感兴趣的学习入口，由于该 学习入口已经包含了自身所需的一组API实体，因此不必主动建立搜索去寻 找一组API实体来作为学习入口。例如，当用户进入到“字符串操作”这一 主题所对应的学习入口后，可以基于目标知识图谱，为初学者自动地推荐与 “字符串操作”相关的一组API实体，而不必初学者去依次搜索这组API 实体的API限定名来寻找这组API实体，从而帮助初学者更加简便地获取到 自身所需的学习入口。

其次，基于目标知识图谱，可以自动地为初学者推荐不同学习入口下的 高质量的API学习资料。本申请建立了每个SO讨论帖与对应的目标API实 体之间的第二关联关系。

一方面，由于SO讨论贴关于API实际使用场景的讨论质量高于第三方 博客与教程网站，且多个API实体均来源于API文档，API文档中准确全面 地记载了各个API实体的功能描述，所以，本申请基于API实体与SO讨论 帖之间的第二关联关系所构建的目标知识图谱，可以为初学者推荐质量更高 且更全面准确的API学习资料；另一方面，API实体以及API实体之间的第 一关联关系可以为初学者提供学习API实体的功能的途径，SO讨论帖为初 学者提供了提供了学习API实体实际使用场景的途径，二者相互结合，可以 便于初学者更加深刻地理解API实体的使用。

实施例一

请参阅图1所示，本申请实施例提供一种面向初学者的API自适应推荐 方法，该方法包括以下步骤：

步骤101：解析API文档，得到多个API元素以及多个API元素之间的 第一关联关系。

本申请实施例中，由于API文档提供了API功能、API使用参数等情况 的详细说明，即，API文档中包含了最为详细的关于各类API元素以及各类 API元素之间的第一关联关系的结构信息，因此，为了给初学者提供更加全 面的API学习资源，本申请中的初始知识图谱是以API文档中的各类API 元素以及各类API元素之间的第一关联关系来进行初步构建。

其中，各类API元素包括：方法、类、接口、属性、包与异常等元素； 各类API元素之间的第一关联关系根据各类API元素的类型的不同而不同， 第一关联关系包括继承关系、包含关系以及实现关系。

具体而言，包含关系可以为一个包包含了一个类或接口；实现关系可以 为一个类实现了一个接口；继承关系可以为一个类或接口继承了另外一个类 或接口。并且，关联关系还可以为一个类或者接口拥有一个属性、一个类或 接口拥有一个方法、一个方法将一个类或接口作为方法的参数、一个方法返 回一个类或接口类型的返回值。

步骤102：基于多个API元素以及多个API元素之间的关联关系，构建 具有多类API实体的初始知识图谱，每类API实体用于描述一种API；每类 API实体均具有多个相互连接的API实体，API实体之间相连接的边表征所 述第一关联关系，所述第一关联关系至少包括继承关系、包含关系、实现关 系。

知识图谱通常标识为一个图结构，由若干节点和边组成。知识图谱中的 节点代表着一个实体，其可以是现实世界中实际存在的各种事物、也可以是 一些抽象的概念。知识图谱中的边则通常代表着实体之间存在的各种关系。

例如，知识图谱中的节点可以是某个人、某部电影、或是某个概念(比 如机器学习)等；而知识图谱中节点之间的边则代表着对应实体之间的关系。 比如某个人出演了某部电影，则这个人对应的实体与这部电影对应的实体之 间存在着“出演”这一关系，并体现为知识图谱中的一条边。

对应到本申请中的初始知识图谱中，初始知识图谱包括多个API实体。 请参阅图2所示出的用于描述一种API的一类API实体，该类API实体具 有多个相互连接的API实体，每相邻两个API实体之间具有从一个API实 体指向另外一个API实体的边，例如两两之间连接的类实体、接口实体、属 性实体、方法实体、包实体、异常实体这六个属于同一类的API实体，并且 这六个API实体均用于描述一种类型的API。

其中，包实体分别与类实体和接口实体连接。包实体指向类实体的边表 示一个包实体包含了一个类实体；包实体指向接口实体的边表示一个包包含 了一个接口实体。

类实体分别与方法实体、包实体、属性实体以及接口实体连接。类实体 指向方法实体的边表示一个类拥有一个方法；类实体指向接口实体的边表示 一个类实现了一个接口；类实体指向属性实体的边表示一个类拥有一个属性； 类实体指向其本身的边表示一个类继承了另外一个类。

接口实体分别与包实体、方法实体、类实体以及属性实体连接。接口实 体指向方法实体的边表示一个接口拥有一个方法；接口实体指向属性实体的 边表示一个接口拥有一个属性；接口实体指向其本身的边表示一个接口继承 了另外一个接口。

方法实体分别与异常实体、类实体、接口实体以及属性实体连接，方法 实体指向类实体的边可以表示为一个方法返回给一个类的返回值或一个方 法将一个类作为方法的参数。

其中，实际的初始知识图谱中并不存在API实体，但为了便于读者更加 清楚地理解初始知识图谱的架构，本申请在图2所示的初始知识图谱中添加 了一种API实体，以表明与该API实体连接的方法实体、属性实体、包实体、 类实体、接口实体以及异常实体等API实体均是用于描述一种API，同时为 图谱中每一个API实体(如类、接口等)规定了与其对应的API实体的第一 关联关系，以表明类、接口、方法、属性等实体都是API实体的一种，类、 接口、方法、属性等实体统称为API实体。

其中，在解析了API文档之后，可以从API文档中抽取各类API元素以 及各类API元素之间的第一关联关系，在构建初始知识图谱时，将各类API 元素以及各类API元素之间的第一关联关系进行可视化展示，形成多个相互 连接的，且连接的边标识第一关联关系的初始知识图谱。

那么，API文档中各个API元素之间的第一关联关系与初始知识图谱中 各个API实体之间相互连接的边一一对应，可以为继承关系、包含关系、实 现关系；API文档中的各个API元素也与初始知识图谱中的各个API实体一 一对应，均是方法、包、属性等。

步骤103：获取多个SO讨论帖，每个SO讨论帖中包括至少一个API实 体指称，所述API实体指称为所述SO讨论帖中讨论的API元素。

本申请实施例中，虽然基于API文档建立了初始知识图谱，但是对于初 学者而言，仅仅学习API文档中不同API元素的功能及含义，而没有各类 API元素的实际使用场景，也仍然无法准确透彻地掌握API的相关知识。

因此，为了进一步地帮助初学者学习不同的API，本申请还需要获取SO 讨论帖，以建立SO讨论帖与API实体之间的第二关联关系。

其中，SO讨论帖来源于SO讨论区，SO讨论区中集中了大量开发者， 开发者会在SO讨论区中讨论关于API元素的实际使用场景，SO讨论帖相 较于第三方博客与教程网站而言，其关于API应用场景的讨论质量较高，相 较于SDK的官方教程而言，其涉及到的API元素的数量更多，因此，本申 请选择将SO讨论帖作为构建目标知识图谱的数据源，以使得推荐给初学者 的学习资源质量更高，且由于SO讨论帖涉及的API数量更多，也能够满足 初学者的多样化需求。

其中，API实体指称指的是在SO讨论帖中被明确讨论过的API元素，将 这些API元素在SO讨论帖中的名称作为API实体指称。

步骤104：在初始知识图谱中，构建所述每个SO讨论帖与对应的目标 API实体之间的第二关联关系，得到目标知识图谱。

本申请实施例中，请参阅图2所示，可以在API实体与SO讨论帖之间 建立第二关联关系，以表明一篇SO讨论帖的内容中使用全部的API限定名， 或部分的API限定名明确提及了一个API实体，具体而言，是建立方法实体、 包实体、接口实体等API实体中的任意一个API实体与SO讨论帖之间的第 二关联关系，只是本申请为了便于读者阅读，在图2中表征为建立API实体 与SO讨论帖之间的第二关联关系关系。

其中，API限定名为API元素的官方名称，API实体指称指的是一篇SO 讨论帖中使用全部或部分的API限定名，明确提及了一个API元素(也可以 称为API实体)。例如，完整的官方API限定名是“java.util.ArrayList<E> .isEmpty()”，一篇SO讨论帖中提及了“isEmpty”，而“isEmpty”是完整的 官方API限定名中的部分API限定名，因此，“isEmpty”是API实体指称。

其中，为了在推荐API的学习资源时，将SO讨论帖中关于API的实际 使用场景推荐给初学者，需要建立一类API实体与SO讨论帖之间的关系， 如此，当确认向初学者推荐该种类型的API实体时，才能将与该类型API 实体有关联关系的SO讨论帖一并推荐给初学者。

步骤105：对所述目标知识图谱上的多个API实体进行聚类，得到不同 的API实体组，以构建为不同主题的学习入口。

本申请实施例中，目标知识图谱包含了多类API实体，每类API实体包 括多个相邻API实体之间具有第一关联关系的API实体，每个API实体均 与各自对应的SO讨论帖建立了第二关联关系。

在这个过程中，多类API实体的描述文本为初学者提供了API的功能描 述，SO讨论贴为初学者提供了API的实际使用场景，当多类API实体以及 多篇SO讨论帖共同构成一张目标知识图谱之后，自然基于目标知识图谱所 提供的API的学习资源也包含了API的功能描述以及API的实际使用场景。

其中，当目标知识图谱中包含了多个API实体的学习资源以后，可以将 多个API实体的学习资源进行分类，来得到不同的API的学习入口，最终再 将不同的API学习入口推荐给初学者。

其中，一个API的学习入口指的是同一主题下的一组具有第三关联关系 的API实体，而同一主题下的一组API实体是初学者在学习SDK中API时 首先开始学习的API，这组API实体可以是来源于同一类的API实体，也可 以来源于不同类的API实体。

例如，“并行”这一主题下的学习入口包括来自于“注册API”下的方 法实体以及“注册API”下的包实体，这些API实体的类型相同，且均与“并 行”相关；“字符串操作”这一主题下的学习入口包括来自于“注册API” 下的方法实体以及“登录API”下的类实体，这些API实体的类型虽然不同， 但是却均与“字符串操作”相关。

其中，第三关联关系与第一关联关系并不相同，第一关联关系指的是同 一类API下的不同API实体之间的关联关系，这些具有第一关联关系的API 实体均是用于描述同一类API；第三关联关系指的是同一学习入口下的不同 API之间的关联关系，这些具有第三关联关系的API实体是可以用于描述不 同类API的，也可以是用于描述同类API的，只是这些具有第三关联关系的 API实体具有相同的主题。

本申请提供一种面向初学者的API自适应推荐方法，可以基于API文档 构建初始知识图谱，再在初始知识图谱的基础上分别构建多类API实体与多 个SO讨论帖之间的第二关联关系，以形成目标知识图谱，如此，目标知识 图谱便包括了与各类API相关的实际使用场景与API功能描述等API相关 的学习资源，最后，使用该目标知识图谱来对API实体进行分类，以划分为 多组API实体，并将多组不同的API实体作为不同的学习入口以推荐给初学者。

对于缺乏经验的初学者而言，只需在构建后的多个学习入口中寻找自身 感兴趣的学习入口即可，而不必主动去依次搜索学习入口内一组API实体的 API限定名，从而能够帮助初学者更加简易地获取到自身感兴趣的学习入口。

并且进入到学习入口内后，学习入口内的API实体均分别与各自的SO 讨论帖建立了关联，可以自动地为初学者推荐与API相关的学习资料。由于 SO讨论贴关于API实际使用场景的讨论质量高于第三方博客与教程网站， 且多个API实体来源于API文档，API文档中全面准确地记载了各个API 的功能，所以，本申请基于API实体与SO讨论帖之间的第二关联关系所构 建的目标知识图谱，可以为初学者推荐质量更高且更全面的API学习资料。

进一步地，解析API文档，得到多个API元素以及多个API元素之间 的第一关联关系，包括：使用解析工具对API文档的HTML页面的结构进 行解析，得到API文档中所包括的多个API元素以及多个API元素之间的 关联关系。

其中，根据Stack Overflow的开发者调查，Java是世界上使用人数最多 的编程语言之一，也是开发者们最想学习使用的语言之一；同时，大部分的 API相关研究都选择JDK(Java Development Kit，Java开发工具)作为API文 档数据源。因此，本申请选择JDK内的API文档作为SDK的主要数据源， 以构建初始知识图谱。

JDK分为两个版本进行发行。一个是以开放源代码方式发行的开源版本 JDK——OpenJDK；另一个则是由Oracle公司进行官方维护的官方版本JDK ——Oracle JDK。两个版本的JDK的API文档都是可以开放获取的，为保证 本申请API文档的数据源的准确性，本文选择Oracle JDK作为API文档数 据来源。

其中，大部分API文档以Web页面的形式被公开于网络，具体来说， API文档体现为一系列的HTML页面，HTML是基于HTML标签的结构化 标记语言，因此，可以通过使用各种Web页面解析工具对API文档的HTML 页面进行解析。本文使用了Python语言的HTML解析库BeautifulSoup4，对 API文档中HTML页面的结构进行解析，得到API文档中所包括的多个API 元素以及多个API元素之间的关联关系。

在API文档中记录不同的API信息时，往往需要使用不同的样式，以达 到在视觉上易于开发者阅读的效果。为了在不同的API元素及API元素之间 关系的记录上应用不同的样式，API文档页面中不同API元素或API元素之 间的关系记录所对应的HTML标签往往拥有不同的属性。

请参阅图3所示，API文档中的方法被记录在一个以标题“Method Summary”开头的HTML表格中，方法本身对应的记录标签中带有一个值为 “memberNameLink”的“class”属性。

请参阅图4所示，API元素之间的继承关系被表述为一棵继承树，而这 棵继承树对应的“<div>”标签中含有值为“inheritance”的“class”属性。

可见，图3中方法这一API元素所对应的HTML标签具有 “memberNameLink”的“class”属性；图4中API元素之间的继承关系所 对应的HTML标签具有“inheritance”的“class”属性，二者的属性是不同 的，使得两张页面截图的样式不同。

而为了视觉的统一性，这些结构化信息在所有的HTML页面中是一致 的，意即：如图3和图4中例所示，方法与类之间的包含关系都是由HTML 表格中值为“memberNameLink”的“class”属性纪录的；而继承关系则都 是由“<div>”标签中含有值为“inheritance”的“class”属性纪录的。这就 保证了API文档的解析可以通过自动化的方式进行。因此，本申请可以采用 解析库BeautifulSoup4对HTML页面的结构化信息进行解析，进而抽取API 文档中所包括的多个API元素以及多个API元素之间的关联关系。

进一步地，构建所述每个SO讨论帖与对应的目标API实体之间的第二 关联关系，包括以下步骤，以下步骤可以参考图9所示的SO讨论帖-API实 体关联的整体流程图：

步骤201：从所述SO讨论帖中提取出API实体指称。

本步骤中，API实体指称指的是SO讨论帖中明确提及的API元素，且 API实体指称时SO讨论帖中的词汇，API元素可以为类、接口、属性、方 法、异常以及包等元素，这些API元素与后续的API实体的本质是相同的， 只是API元素位于API文档之中，API实体位于目标知识图谱之中，二者的 名称不同，以对二者所处的环境进行区分。

其中，在提取API实体指称的过程中，由于SO讨论帖中的讨论内容由 不同的开发者编写，对API实体指称的表达方式各不相同，且API实体指称 中所展现的API限定名会与一些常见的英文单词，比如“put”、“exist”等等 英文单词重合，因此，需要对API实体指称进行提取，以得到具有准确含义 的API实体指称。

具体而言，步骤201包括以下子步骤：

子步骤A1：对所述SO讨论帖进行预处理，得到句子的集合，步骤A1 中的预处理包括以下子步骤：

子步骤A11：收集SO讨论帖的讨论内容，讨论内容包括：讨论帖中的 标题、问题主干、以及回答列表中每条回答的回答主干。

其中，讨论帖中的标题、问题主干、以及回答列表中每条回答的回答主 干等属性，其本身所表征的就是SO讨论帖中主要的讨论内容，因此，可以 将这些属性先收集起来，以从这些属性中获取API实体指称。

子步骤A12：使用Python语言的解析库，对HTML文本的讨论内容进 行处理，去除讨论内容中的代码片段，保留实际讨论的讨论内容。

其中，在后续提取出API实体指称的过程中会使用到API实体命名识别 模型，由于API实体命名识别模型无法直接识别HTML文本格式的问题主 干与回答主干等讨论内容。

因此，可以采用Python的BeautifulSoup4工具库对这些HTML文本的 讨论内容进行解析，以使得解析后的讨论内容能够被API命名实体识别模型 识别。

其中，SO讨论中的代码片段通常会由于演示某一功能的实现而使用大 量API，而代码片段被使用，并不能代表开发者在SO讨论帖中正在讨论该 API。

因此，可以采用Python的BeautifulSoup4工具库，通过识别HTML文 本的讨论内容中的“<pre>”以及“<code>”标签，去除讨论内容中的代码 片段，以使得保留下的讨论内容是开发者在SO讨论帖中实际正在讨论的讨 论内容。

子步骤A13：将讨论内容从HTML文本转换成纯自然语言文本。

其中，去除了讨论内容中的代码片段，可是讨论内容中还具有纯自然语 言文本的讨论内容以及标签，API实体命名模型无法有效地识别标签，只有 使用纯自然语言文本，才能保证API实体命名识别模型能够学习到SO讨论 帖中讨论内容的有效语义特征。

因此，可以采用Python的BeautifulSoup4工具库对讨论内容的纯自然语 言文本的内容进行抽取，并丢弃讨论内容中所有的HTML标签，以使得API 实体命名识别模型所能学习的均是纯自然语言文本的讨论内容。

子步骤A14：使用工具包NLTK对纯自然语言文本的讨论内容进行分句， 将讨论内容分割为若干句交流讨论的句子的集合。

其中，SO讨论帖的内容通常都很长，而极长的纯自然语言文本会对API 命名实体识别模型的资源消耗和预测能力带来较强的负面影响。

因此，为了减少API命名实体识别模型的资源消耗以及提升API命名实 体识别模型的预测能力，可以采用NLTK(the natural language toolkit，自然 语言处理工具包)，将纯自然语言文本分割为多个句子，以形成句子的集合。

子步骤A2：对所述句子的集合进行处理，得到词汇序列。

其中，词汇序列是由句子分割为若干个词汇所构成的序列。

子步骤A3：在所述词汇序列中，使用API命名实体识别模型标记所述 API实体指称所对应的词汇，作为提取出的API实体指称。

本步骤中，在使用API命名实体模型之前，需要对API命名实体模型进 行训练，对API命名实体模型训练的过程中需要使用到数据集，数据集的选 取包括如下子步骤：

子步骤A31：遍历SO讨论帖，采用正则表达式匹配的方法，识别SO 讨论帖中的超链接文本是否指向了一个API实体，若是，则将超链接文本中 所包含的词语或词汇作为数据集。

其中，API命名实体模型为基于深度学习的监督式模型，因此需要为模 型的训练准备数据集，由于API命名实体识别模型为序列标记模型，该序列 标记模型得到分割后的词汇序列后，将词汇序列中API实体指称对应的词汇 标记出来，从而达到识别API实体指称的目的。

因此，需要使用SO讨论帖中关于API实体描述的词汇序列作为模型的 输入，使用词汇对应的标记作为模型的输出，来对API命名实体模型进行训 练，以使得API命名实体模型具有将词汇序列中API实体指称对应的词汇标 记出来的能力。

经研究发现，SO讨论帖中部分书写习惯比较标准的用户在引用一些外 部的Web页面时，会引用该Web页面中的短语(例如关于API的短语)标 记为超链接(hyperlink)，并将超链接的值设定为引用的Web页面的统一资 源定位符(uniform resource locator，URL地址)。因此，书写良好的SO讨 论帖中会存在指向API的超链接，而这个超链接作为了SO讨论帖所在Web 页面的URL地址。

并且，由于API文档中的API众多，API文档通常不会将所有内容都放 在同一个Web页面中，而是会在不同的Web页面中描述不同的API，这就 使得每个API所对应的URL地址都是不同的。那么，可以推断出不同的API 对应的不同的URL地址，不同的API也对应不同的超链接。

基于此发现，本申请采用正则表达式匹配的方法，识别SO讨论帖中的 超链接是否指向了一个API，若是，则代表该篇SO讨论帖中正在讨论该API， 因此可以将SO讨论帖中的超链接中所包含的词语或词汇作为训练API命名 实体识别模型的数据集。

子步骤A32：使用人工筛选的方式，对数据集中的每条数据，使用BIOS 标注规则进行审核与重新标注，以去除每条数据中无意义的词汇，得到准确 的数据集。

其中，通过子步骤A31中的自动化方法，收集的若干词汇存在着明显的 质量问题。比如，很多开发者在对SDK中的一个API进行指代时，往往会 使用一些无意义的词汇，如“here”、“this documentation”等，通过这些无 意义的词汇找到其指代的具体API是不可能的，因此，本申请对用上述方法 收集到的数据集进行了人工重新标注。

具体而言，可以对数据集中的每条数据进行审核，去除“here”、“thisdocumentation”等无意义的词汇，以确保数据集中被标注为API实体指称的 短语或词汇是正确的API实体指称，能让API命名实体识别模型学习到正确 的词汇。

在筛选出正确的词汇之后，还需要对词汇进行标注得到词汇对应的标记， 如此，才能对API命名实体模型进行训练。

具体而言，主要的标注规则如下：

1)、API实体指称的词性必须为名词，否则无法判定为对API实体的指 称；

2)、API实体指称可以为短语(多个词汇)，也可以为单个词汇；

3)、API实体指称使用JDK中API的限定名的全部或一部分、对JDK 中的某个API元素(如类、接口、方法等)起到了明显的指称作用；

4)、API实体指称的标注使用最大标注长度原则进行：只要被标注的词 汇或短语旁边仍然还有词汇或短语，且加入这些额外的词汇或短语后，指称 仍对API起到明显指称作用，就将这些词汇或短语加入指称的标注范围；

5)、对于API实体指称中的修饰词(如定语、冠词等)，不予标注；

6)、不标注在代码片段中出现的API实体指称(也就是在<pre>、<code> 的标签范围之内不予标注)；

7)、对于罕见案例，即无法确定是否应该标注的数据，需要协商后对其 标注原则进行确定。

在使用上述标注规则对若干词汇进行标记的过程中，本申请使用了BIOS标注规范对若干词汇进行了标注。

表格1

请参阅表格1所示，本申请在将一个句子分割为若干词汇之后，可以将 若干词汇中的每个词汇标记为B、I、O、S四种标记中的一种。

如此，SO讨论帖的超链接中指向API的每一个词汇均具有了标记，再 将若干词汇作为API命名实体模型的输入，将若干词汇对应的标记作为API 命名实体模型的输出，来对API命名实体模型进行训练。如此，API命名实 体模型在识别到词汇具有B、I、S中的任意一个标记时，则将这些词汇标记 出来，作为API实体指称。

本步骤中，请参阅图5所示，API命名实体模型包括：BERT编码层、 多尺度空洞卷积层、BiLSTM层、全连接层、CRF层。

本步骤中，API命名实体模型标记多个词汇的过程包括如下子步骤：

子步骤A33：将若干词汇输入至BERT编码层中，以使得每个词汇输出 带有上下文信息的语义向量。

其中，BERT编码层是经过预训练的BERT模型，BERT模型输出的每 个词汇对应的向量都包含了句子中其它单词的上下文信息，从而使得整个 BERT模型在微调阶段，能够利用更丰富的通用语义信息达到较好的效果。

BERT通过两个预训练任务在大规模语料库上进行预训练。第一个预训 练任务是遮盖语言模型(Masked Language Model)，该任务通过屏蔽句子中 的一些词汇，让BERT模型预测被屏蔽位置的单词，以帮助BERT在预训练 阶段获取充分的上下文信息；第二个任务是下一句预测(Next Sentence Prediction)，该任务为模型提供两个句子，并要求模型对第二个句子是否是 第一个句子的下一个句子进行预测，以帮助BERT充分理解句子之间的逻辑 关联。通过这两个预训练任务，使得BERT模型在针对具体任务的微调步骤 中，往往仅需要较少的词汇量就能达到较好的效果。

具体而言，请参阅图2所示，每一句来自SO讨论帖的句子被输入模型 前，将首先被分词为词汇序列，分别记作w₁，w₂，w₃…w_n，其中n代表着 分词后一个句子中包含的词汇的数量；这些词汇序列被输入BERT编码层， 该BERT编码层内部是经过预训练的BERTOverflow模型。由于 BERTOverflow模型已经在SO讨论帖上经过了充足的预训练，因此BERT 编码层无需训练就能够为每个词汇输出当前词汇位置上带有句子中上下文 信息的通用语义特征，具体来说，BERT编码层将为每个词汇都输出768维 的语义向量，用以表示该单词的语义特征，这些语义向量记作f₁，f₂，f₃…f_n。

子步骤A34：使用多尺度空洞卷积层对语义向量中的局部序列语义信息 进行丰富，得到扩展后的语义向量。

其中，空洞卷积是卷积的一种变种与改进，为了有效提取不同长度词汇 序列的局部语义特征，本申请在BERT编码层之后，使用一个多尺度的空洞 卷积层对BERT提取的语义向量中的局部序列语义信息进行丰富。

具体来说，请参阅图2所示，本申请分别使用了三个卷积核尺寸为3的 卷积核对BERT提取的语义向量f₁，f₂，f₃…f_n进行卷积操作。在上述三个卷 积层中，第一个为传统卷积层，用来提取每个词前后小范围内的局部语义信 息；而第二个和第三个为空洞卷积层，两个空洞卷积层的扩张尺度分别为3 和5，也就是对词汇序列进行间隔为3和5的等间隔采样并进行卷积操作。 两个不同尺度的空洞卷积层相比传统卷积增大了卷积的感受视野，能够识别 更长词汇序列上的局部语义信息。

可见，使用多尺度的空洞卷积，能够对不同长度的API实体指称的局部 语义信息做到比较充分的捕获。通过将三个卷积层的卷积输出依次连接到 BERT层输出的语义向量上，多尺度空洞卷积扩展了每个词的语义向量维度 与其中的语义信息，扩展后的语义向量记作e₁，e₂，e₃…e_n。

子步骤A35：将扩展后的语义向量输入至BiLSTM层，以获取若干词汇 在序列长距离上的模式信息。

其中，LSTM(Long Short Term Memory，长短时记忆网络)是RNN (RecurrentNeural Network，循环神经网络)的一个改进变种。

RNN中的每个神经元在接受序列在当前位置的输入的同时，也接受了 从上个神经元传入的状态信息，因此神经元可以同时获得序列在当前位置的 信息与序列之前的信息。由于自然语言的句子通常都被处理为词汇序列，因 此RNN是十分适用于处理自然语言的一类模型。

然而，RNN在处理自然语言等序列信息时仍体现出一些不足之处。首 先，RNN在接受序列每一个位置的输入时，都会通过接受上一个神经元的 状态来获取所有序列在该位置之前的信息。然而，由于RNN中每个神经元 参数有限，这种方式无疑会使得序列该位置之前的信息产生大量的丢失，这 就使得RNN很难对相距较远的两个词汇之间的关系进行捕捉。另外，序列 中所有位置的信息都会被RNN所记录，这会导致一些无关紧要的位置上的值对模型效果产生影响。比如，一句话中经常出现很多对当前任务没有帮助 的词，而这些词的信息也会被RNN所捕捉。

为解决上述问题，提出了LSTM，LSTM是RNN的一个改进变种，其 基本网络结构与RNN没有区别，但在基本的神经元结构上，不同于RNN中 使用的全连接神经网络，LSTM通过对神经元引入三个“门”来控制神经元 对信息的输入输出与处理过程：

a)、输入门：控制当前输入是否要存入当前神经元。

b)、遗忘门：控制是否要对当前神经元的内容进行“遗忘”、即清空当 前神经元内容。

c)、输出门：控制是否将当前神经元的内容进行输出。

图6展示了LSTM的神经元结构，通过神经元中三个门的作用，LSTM 能够控制将序列中不必要的内容进行选择性遗忘，从而只将重要的信息存储 在神经元参数中，有效地解决了RNN在长序列上的信息丢失问题。

具体来说，请参阅图5所示，被多尺度空洞卷积层扩展后的语义向量， 输入一个双向的LSTM层，即BiLSTM层。该层包含一个正向的LSTM模 型与一个反向的LSTM模型，用以对词汇序列的两个方向进行建模。

BERT模型基于自注意力机制，弱化了词汇序列中词汇之间的序列位置 关系；多尺度空洞卷积层也无法对序列位置关系进行有效的捕获。

然而，在序列标注任务中，获取序列本身的序列位置关系也是非常重要 的。因此，本申请在API命名实体识别模型中加入BiLSTM层，以获取词汇 序列在序列长距离上的序列位置关系。

子步骤A36：将具有模式信息且扩展后的语义向量输入至CRF层，输 出每个词汇的标注，记作标注1，标注1…标注n,每个词汇的标注都是B、I、 O、S的一种。

其中，CRF层(Conditional Random Field，条件随机场)被经常用于序 列标注问题中。在实际序列标注中，充分考虑某一序列位置之前的序列标注 信息，从而对当前位置不同标注的条件概率做出合理的预测，也就是为序列 的标注添加逻辑上的规范，减少序列的标注不合规范的情况发生。

具体而言，BiLSTM层的输出在经过一个全连接神经网络后，被输入一 个CRF层。该CRF层包含一个条件随机场(CRF)，整个API命名实体识别 模型通过CRF层，为输出的词汇序列标注添加逻辑上的标准性约束。由于 本申请中使用BIOS标注规范，因此一些标注的标准需要CRF层进行规范， 比如标注为I的单词一定要紧跟在标注为B的单词之后。以使得从CRF层 输出词汇序列中每个词汇的标注，记作标注1，标注2，标注3…标注n，每 个词汇的标注都是B、I、O、S中的一种，而标注为B、I、S中任意一种的 词汇被提取为API实体指称。

步骤202：将所述API实体指称分别与所述每类API实体中的多个API 实体的API限定名进行一次匹配，得到与所述API实体指称所匹配的多个第 一候选API实体，所述API限定名为API实体的命名。

本步骤中，在通过步骤201得到SO讨论帖中的若干API实体指称之后， 需要在初始知识图谱中寻找可能是API实体指称所指代的API实体，因此需 要将API实体指称分别与每类API实体中的多个API实体的API限定名进 行匹配，即将API实体指称与初始知识图谱中的所有API实体的API限定 名进行匹配，来得到与API实体指称所匹配的多个API限定名，而多个API 限定名所对应的API实体为第一候选API实体。

具体地，本申请事先将初始知识图谱中所有API实体的API限定名分割 后，插入至Elasticsearch中；采用分布式搜索引擎Elasticsearch，将API实 体指称在所有的API限定名中进行搜索，将能够匹配到的API限定名所对应 的API实体返回，作为第一候选API实体。

其中，API实体的限定名来源于API文档，考虑到部分开发者在API文 档中书写API限定名时，可能将API限定名进一步拆分成独立词汇使用(比 如，使用短语“array list”指代JDK中的API“ArrayList”)，因此，本申请 进一步将API限定名以驼峰命名法和下划线命名法的规则进行了拆分，以尽 可能帮助搜索引擎搜索到并生成正确的第一候选API实体。

其中，将所述API实体指称分别与多个API实体的API限定名进行一 次匹配指的是，将API实体指称所表征的词汇，分别与多个API实体的API 限定名所表征的词汇进行名称匹配。

步骤203：将所述API实体指称分别与多个第一候选API实体进行二次 匹配，得到与所述API实体指称匹配的目标API实体。

本步骤中，由于将API实体指称分别与多个API实体的API限定名进 行一次匹配，一次匹配是将两个词汇进行名称匹配，但是当名称相同的两个 词汇所表征的意义并不相同时，会导致得到的多个第一候选API实体中存在 错误的第一候选API实体。

为了筛除错误的第一候选API实体，消除词汇之间的歧义，步骤203可 以称为第一候选API实体的命名消岐方法，具体包括以下子步骤，以下子步 骤为API实体指称分别与多个第一候选API实体进行二次匹配的过程，二次 匹配的过程分为API实体指称与多个短限定名之间的名称匹配过程，以及 API实体实体指称的上下文文本与目标短限定名所表征的第一候选API实体 的描述文本之间的语义匹配过程，具体而言：

子步骤B1：对所述第一候选API实体的API限定名进行抽取，分别得 到多个短限定名。

在本文中，短限定名的意思是API限定名中，通过分隔符分割后留下的 最后一部分能够表征API类型的名称。对于不同种类的API实体，短限定名 的意义各不相同，比如，对于类的实体来说，短限定名就是它的类名，而对 于方法的实体来说，短限定名就是它的方法名。

虽然不同的短限定名对不同API的意义不同，但该部分短限定名往往都 能够对API实体起到明确指定的作用，开发者对API实体进行指称时，不使 用短限定名的部分就无法对API实体进行明确的指定。

比如，对于API限定名为java.util.ArrayList<E>.isEmpty()的方法类型的 API而言，其短限定名为“isEmpty”。开发者无论使用怎样的表达，API实 体指称中都需要包含“isEmpty”或者“is empty”等类似字样的短限定名， 如果不包含该短限定名，仅使用如“ArrayList”等表述，则是在对其所属的 类进行指称，无法起到指代该方法的作用。

本申请通过正则表达式匹配与字符切割的方法，针对API限定名进行了 抽取，来得到短限定名。为了减少无关因素的影响，抽取过程中去掉了限定 名中对于指代API没有影响的部分，例如包括方法参数(“()”中的内容)、 泛型参数(“<>”中的内容)等。

子步骤B2：从所述多个短限定名中，确定被所述API实体指称所包含 的短限定名，以作为目标短限定名。

其中，目标短限定名可以为多个，API实体指称与多个短限定名之间匹 配的原则是：使用字符串匹配方法，确定API实体指称中是否包含了完全的 短限定名，若包含，则将这些短限定名作为目标短限定名；若不包含，则筛 除该短限定名。

需要注意的是，开发者表述API时，可能会根据驼峰命名法或下划线命 名法规则将API限定名拆解表述，比如将“isEmpty”表述成“is empty”。 本申请中同样也考虑了开发者各种形式表述的影响，将匹配过程中输入的两 个字符串事先进行分词、小写字母转化以及根据驼峰命名和下划线命名法的 分割，以最大限度减少误匹配的情况发生。

子步骤B3：将所述API实体指称分别与所述目标短限定名所表征的第 一候选API实体进行匹配，得到所述目标API实体。

子步骤B3可以包括以下步骤：

子步骤B31：采用语义匹配模型，将所述API实体指称的上下文文本， 分别与所述目标短限定名所表征的多个第一候选API实体的描述文本进行 语义匹配。

其中，由于API实体指称是在SO讨论帖中提及到的一些词汇或短语， 因此在SO讨论帖中提及到API实体指称的句子可以被视作API实体指称的 上下文信息。为了丰富API实体指称的上下文文本，本申请也将API实体指 称所在的SO讨论帖的标题以及标签连接在其所在的句子之前，一同作为API 实体指称的上下文文本输入至语义匹配模型之中。

其中，在使用Python语言的HTML解析库BeautifulSoup4，对API文 档中HTML页面的结构进行解析之后，不仅仅抽取了API文档中所包括的 多个API元素以及多个API元素之间的关联关系，还抽取了对每个API实 体的描述文本，API实体的描述文本包含着API实体的语义信息。

并且，本申请在向分布式搜索引擎Elasticsearch中插入分割后的API限 定名的同时，也将每个API实体的描述文本作为附加信息插入至Elasticsearch 的文档集合中，以在搜索与API实体指称匹配的第一候选API实体的同时， 从Elasticsearch的文档集合中获取到若干第一候选API实体的描述文本，最 终为每个API实体指称生成若干带有描述文本的第一候选API实体，以将若 干带有描述文本的第一候选API实体输入至语义匹配模型之中，与API实体 指称的上下文文本进行语义匹配。

其中，相比与常规知识图谱进行的命名消歧，初始知识图谱中的命名消 歧的复杂度要低很多，这是因为API中的各个API实体与通常常规知识图谱 中的实体不同，通常常规知识图谱中的实体都是人们在日常生活中接触的概 念和事务、事物，很容易有造成歧义的表述，而API中的各个API实体是 SDK开发者统一进行设计和规范的，每个API实体都具有唯一的开发者设 计的指定限定名称，很难有歧义情况。

因此，基于短限定名消岐方法在实际应用中能够解决很大部分候选中心 节点消岐的问题，经过基于短限定名匹配的消歧方法，对于一个API实体指 称来说往往只能在目标知识图谱找个一个符合要求的API实体。

然而，对于一部分的API实体来说，基于短限定名的消歧方法仍然无法 为API实体指称找到唯一的API实体。这是因为许多API实体拥有完全相 同的短限定名，而它们位于不同的包或者类之中，是通过不同的包名或类名 进行区分的。例如java.util.ArrayList<E>.get()和java.util.HashMap<E>.get() 两个方法API，它们的短限定名都为“get”，但是因为所处的类不同，因此 所处的语境也有所不同：java.util.ArrayList<E>.get()是用来在列表中获取一个 元素，而java.util.HashMap<E>.get()则是用来在字典中获取一个元素，这些 语义上的差别会体现在不同API实体的不同描述文本之中。因此，本申请通 过使用一个监督式的API描述-API指称语义匹配模型，简称语义匹配模型， 对输入API实体指称的上下文文本与API实体的描述文本二者的语义进行匹 配，进一步对这种短限定名极为相似的多个第一候选API实体进行消歧。

其中，语义匹配模型的作用是：对API实体指称的上下文文本与API 实体的描述文本进行语义的匹配，当二者语义的匹配程度高于预设匹配度时， 语义匹配模型会输出1，来表征该API实体是API实体指称所指向的API实 体。具体而言，是对API实体指称的上下文文本与API实体的描述文本进行 语义匹配，以输出二者语义的匹配程度，匹配程度的范围是[0，1]，当匹配 程度大于或等于0.5时，表明短限定名的描述文本与API实体指称的上下文文本匹配度较高，语义匹配模型会输出1，以确定该短限定名所表征的API 实体为目标API实体。

其中，在使用语义匹配模型之前，需要对语义匹配模型进行训练，对语 义匹配模型训练的过程中需要使用到数据集，为了确保语义匹配模型能够在 获取到API实体指称的上下文文本与多个目标短限定名所表征的API实体的 描述文本之后，在多个目标短限定名相同的API实体之间进行消岐，本申请 选择能够匹配到多个相同短限定名的API实体的API实体指称作为数据集。

具体而言，对于每个加入数据集中的API实体指称，为其准备了三个第 一候选API实体进行匹配：其中一个是根据URL地址收集的作为ground-truth 的API实体；另外两个API实体则与ground-truth的短限定名相同，作为数 据集中的负样本。因此，在训练和测试语义匹配模型的过程中，语义匹配模 型模型将会对每个API实体指称的三个第一候选API实体进行三次匹配，并 在三个第一候选API实体中匹配到正确的API实体，如此语义匹配模型便具 有了从多个目标短限定名相同的API实体中识别出目标API实体的功能。

其中，请参阅图8所示，语义匹配模型的架构包括：CLS层、BERT编 码层以及全连接层。

本步骤中，语义匹配模型对API实体指称的上下文文本与多个目标短限 定名所表征的API实体的描述文本进行匹配的过程包括如下子步骤：

子步骤B311：将API实体指称的上下文文本和API实体的描述文本输 入至CLS层中，CLS层输出API实体指称的上下文文本的词汇序列，以及 API实体的描述文本的词汇序列。

其中，在将API实体指称的上下文文本和API实体的描述文本这两个句 子输入至CLS层中之前，将这两个句子通过BERT模型给定的分隔符Sep 进行连接；同时，一个BERT模型给定的特殊分类符CLS被添加在两个句 子的最前面，该分类符的作用是在经过BERT编码层的编码后，收集两个输 入句子的整体语义信息。

子步骤B312：将CLS层输出API实体指称的上下文文本的词汇序列， 以及API实体的描述文本的词汇序列输入至BERT编码层进行编码后，在 CLS位置的BERT编码向量将被视作两个输入句子的匹配语义信息，并被输 入至全连接层中。

其中，全连接层由两个全连接神经网络层构成。

子步骤B313：全连接层输出API实体指称的上下文文本的词汇序列， 以及API实体的描述文本的词汇序列之间的语义匹配度。

其中，全连接层会输出一个位于0到1之间的值，视作API实体指称和 第一候选API实体的匹配分数。由于匹配分数位于0到1之间，因此将匹配 分数0.5以上视作匹配成功，否则为匹配失败。

子步骤B32：将语义匹配度高于预设匹配度的第一候选API实体，作为 所述目标API实体。

其中，预设匹配度可以为0.5，当API实体指称与第一候选API实体之 间的预设匹配度高于0.5，则可以将该第一候选API实体作为目标API实体。

在通过一次匹配与二次匹配之后，可以从初始知识图谱中获取到唯一与 API实体指称匹配的API实体。

步骤204：建立所述API实体指称所在的SO讨论帖与所述目标API实 体之间的第二关联关系。

其中，由于一篇SO讨论帖中可能讨论了多类API实体下的API实体， 例如讨论了“注册API”下的方法实体这一API实体，也讨论了“登录API” 下的方法实体这一API实体，也讨论了“注销API”下的方法实体这一API 实体，因此，可以将这篇SO讨论帖同时与不同类型的方法实体均建立第二 关联关系。

其中，由于一类API实体下的某一个API实体可能被多篇SO讨论帖讨 论，例如，“注册API”下的方法实体这一API实体同时被SO讨论帖A、B、 C讨论，也可以将方法实体同时与这三篇SO讨论帖建立第二关联关系。

最终在初始知识图谱上建立了API实体指称所在的SO讨论帖与目标 API实体之间的第二关联关系之后，形成目标知识图谱，使得目标知识图谱 上的每个API实体都具有其对应的SO讨论帖，即，每个API实体都具有其 对应的实际使用场景。

其中，第二关联关系用于表征一篇SO讨论帖在其内容中，使用全部或 部分的API限定名、明确提及了一个API实体。

进一步地，对所述目标知识图谱上的多个API实体进行聚类，得到不同 的API实体组，以构建为不同主题的学习入口，包括以下步骤：

步骤301：基于所述目标知识图谱，获取在同一篇SO讨论帖中被讨论 超过预设次数的两个API实体。

其中，可以通过分析目标知识图谱中的第二关联关系，以确定在目标知 识图谱中所有API实体两两之间被同一篇SO讨论帖一起讨论的次数，并获 取在同一篇SO讨论帖中被讨论超过预设次数的两个API实体。

其中，预设次数用于表征API实体的常见程度，当两个API实体被同一 篇SO讨论帖频繁讨论，则表征这两个API实体的常见程度较高。

步骤302：将所述两个API实体添加至SO社区知识图谱中，并建立所 述两个API实体之间的第三关联关系。

其中，请参阅图7所示，SO社区知识图谱是基于目标知识图谱上的第 二关联关系所建立的图谱，SO社区知识图谱仅包含API实体，并仅包含一 种关系，该关系为第三关联关系，关系名为“co-occur”，第三关联关系可以 存在于任意两个API实体之间，意味着两个API实体在同一篇SO讨论帖中 被共同地讨论的次数超过预设次数。

其中，SO社区知识图谱中具有多对API实体，每对API实体之间具有 第三关联关系。在SO社区知识图谱构建的过程中，已经就API在社区中被 讨论的频率做出了筛选，保证了SO社区知识图谱中的API实体均为SDK 中的常用API实体，如此，基于SO社区知识图谱所构建的学习入口，也是 初学者常用的学习入口。

步骤303：基于Louvain算法，对所述SO社区知识图谱中每两个所述 API实体之间的第三关联关系进行分析，以将多个API实体聚类为不同的 API实体组，其中，每个所述API实体组中包括多个两两之间具有所述第三 关联关系的API实体。

其中，基于Louvain算法，可以对SO社区知识图谱中API实体之间的 第三关联关系进行分析，将常用的API实体分组为若干学习入口，保证每个 学习入口涉及到SDK的不同主题，并且每个学习入口内部的API实体全部 都和SDK的某个具体主题相关。

其中，Louvain算法是社群发现算法，社群发现算法是一种在图的数据 上被用来发现社群结构的重要算法，可以在广义上被视作一种在图上进行的 聚类算法。一个社群是图中的一个子图结构，包含图中的若干节点与节点之 间的边。社群本身并没有十分明确的定义，一般通过模块度(Modularity)， 即这一子图的属性来判定一个子图是不是社群，模块度较高的子图就被认为 是一个社群。

Louvain算法基于上述的模块度定义，通过两个阶段进行社群的发现。

在第一个阶段，Louvain算法不断遍历图中的节点，通过比较将每个节 点加入每个相邻社区带来的模块度的变化，将单个节点加入到能够使得模块 度得到最大提升的临近社群中。在算法一开始时，每个节点都是一个独自的 社群。

在第二个阶段，算法对第一阶段的结果进行处理，将同一社群的节点合 并为一个大的节点并重新建立一个新的图。图中每个节点都是在上一个阶段 算法生成的社群，称为超点。此时两个超点之间的边的权重是两个超点内所 有原始节点之间相连的边权重之和。

Louvain算法在上述两个阶段之间不断迭代，直到每个社群达到稳定， 其内部的模块度都已经达到最大。

具体到本申请中，Louvain算法遍历SO社区知识图谱中的API实体之 间的第三关联关系，首先将一个API实体作为一个节点，然后将与该API 实体具有第三关联关系的API实体加入至该节点之中，形成一个社群，再将 与社群内的API实体之间具有第三关联关系的API实体加入至该社群，形成 一个更大的社群，如此反复迭代，最终形成多组社群。

在这个过程中，将与该API实体具有第三关联关系的API实体加入至该 社群内后，该社群的模块度会得到提升；将与该API实体之间不具备第三关 联关系的API实体加入至社群内后，该社群的模块度不会变化。如此，多个 社群进行迭代的过程中，若多个社群的模块度均达到最大值而不再变化时， 表明SO社区知识图谱中的所有API实体已经聚类成了多个社群。

其中，一个社群指的是一个API实体组，一个API实体组内的多个API 实体中每相邻两个API实体之间具有第三关联关系，请参阅图7所示，多个 API实体之间形成一个网状结构，该网状结构为一个API实体组，图7示出 了多个网状结构。

步骤304：将每个不同的API实体组，构建为不同API的学习入口。

其中，一个学习入口为一个主题，主题可以为字符串操作、IO、并行等 任意一种。

其中，在确定每个学习入口的主题名称时，可以从一个学习入口中的多 个API实体关联的SO讨论帖的标签中找出出现频率最多的一个标签，将该 标签作为该学习入口的主题名称。

在将SO社区知识图谱中的API实体聚类为多个不同的API实体组之后， 每个API实体组为一个学习入口，以推荐给初学者，由于API实体组中的 API实体是经常被使用的API实体，那么，该学习入口也是经常被使用的学 习入口，所以初学者可以更加容易地从推荐的学习入口中找到自身感兴趣的 学习入口。

进一步地，在初学者学习API的过程中，只是向初学者推荐常用的学习 入口并不足以覆盖SDK中API的所有使用场景，初学者也可能根据自己的 学习兴趣，自行搜索API作为学习入口。

然而，绝大多数API文档的搜索功能都简单地将用户输入的待查询文本 与API限定名进行匹配，并返回与查询文本匹配的API限定名所表征的API 实体。对于不知道SDK中API命名方式的初学者来说，不一定能够直接搜 索到API限定名，有可能只能联想到一些API实体相关的领域术语。因此， 本申请基于目标知识图谱，还设计了API学习入口搜索方法，该方法能够分 析用户输入的待查询文本的领域术语，并将其和API实体相关的各种领域术 语进行匹配，最终通过目标知识图谱进行联想并返回相关的API学习入口。 具体包括以下步骤：

步骤401：在所述目标知识图谱中，建立所述API实体与对应的第一领 域术语之间的第四关联关系，所述第一领域术语来源于所述API文档。

其中，请参阅图2所示，可以在API实体与第一领域术语之间建立第四 关联关系，表示在一个API实体的描述文本中提及了一个领域术语；第一领 域术语，用于代表一个API实体的描述文本中抽取的领域术语，而API实体 的描述文本来源于API文档。

其中，为了从API实体的描述文本中提取出与API实体相关的第一领域 术语，本申请使用了开源自然语言处理库Spacy对所有API实体的描述文本 进行了词性标注。被标注为名词的短语或单词将被作为一个第一领域术语加 入目标知识图谱。在加入目标知识图谱之前，每个短语或单词经过了去停用 词、词形还原和近义词检测的处理，以保证该短语或单词的通用性。

通过在目标知识图谱中，建立API实体与第一领域术语之间的关联关系， 可以在接收到初学者输入的查询文本之后，从目标知识图谱中进行搜索，以 获取与用户输入的查询文本所匹配的第一领域术语关联的API实体返回给 初学者，避免初学者输入领域术语而无法搜索到相关的API实体的情况出现。

步骤402：建立所述第一领域术语与第二领域术语之间的第五关联关系， 所述第二领域术语来源于维基百科。

其中，在图2中，第五关联关系用于表示一个第一领域术语与第二领域 术语在语义上相关；第二领域术语代表一个来自维基百科的通识概念对应的 领域术语。

其中，本申请利用词嵌入模型FastText两两比较目标知识图谱中第一领 域术语与第二领域术语的语义相似度，并在语义相似的第一领域术语和第二 领域术语之间建立第五关联关系。

对于每个第一领域术语，本申请收集了API文档中每一句提及了该第一 领域术语的句子，将这些句子中非停用词的单词的对应FastText词向量进行 平均，作为第一领域术语的语义表示。

对于每个第二领域术语，本申请收集了该第二领域术语对应的维基百科 页面，并抽取维基百科页面中的描述文本，并同样利用描述文本中非停用词 的FastText词嵌入向量的平均，作为第二领域术语的语义表示。

最终计算第一领域术语与第二领域术语之间语义表示的余弦相似度，并 在相似度高于一个给定的相似度阈值时，在第一领域术语与第二领域术语之 间添加第五关联关系。其中，相似度阈值可以为0.8。

步骤403：从用户输入的查询文本中，提取出待查询领域术语。

其中，对于用户输入的查询文本应用词性标注方法，并提取其中词性被 标注为名词的短语或单词，作为待查询领域术语。

步骤403：将与所述待查询领域术语匹配的多个第一领域术语所关联的 第二候选API实体，以及与所述待查询领域术语匹配的多个第二领域术语所 关联的第三候选API实体，作为候选API列表。

其中，第二候选API实体与第三候选API实体的数量均为多个，因此以 构成一个候选API列表。

步骤404：将所述待查询领域术语与所述候选API列表中的所有API实 体进行语义匹配，得到所有API实体的排列顺序。

其中，候选API列表具有用户并不需要的API实体，因此，需要在步骤 404中进行进一步地筛选。

具体地，可以根据候选API列表中所有API实体的描述文本与待查询领 域术语的语义相关性，对候选API列表中的所有API实体进行排序，排列顺 序中位于首位的API实体，与待查询领域术语之间的语义相关性最高。

步骤405：在所述排列顺序中，推荐位于首位的API实体。

其中，由于排列顺序中位于首位的API实体，与待查询领域术语之间的 语义相关性最高，所以可以将位于首位的API实体推荐给用户，以确保用户 输入待查询领域术语之后，也能够获取到与之匹配的API实体。

其中，本申请还可以在用户输入待查询文本后，为用户推荐学习入口， 具体而言：

可以以候选API列表中的所有API实体为起点，沿着目标知识图谱中 API实体之间的第一关联关系进行深度最大为2的广度进行搜索，将搜索到 的API实体视作与候选API列表中的所有API实体有紧密关系的其他API 实体，将这些API实体与候选API列表中的所有API实体组成一个集合， 并将该集合作为一个学习入口推荐给输入待查询文本的用户。

其中，本申请着重面Java的初学者，由于Java是面向对象的编程语言， 因此算法倾向于向学习者推荐类或者接口作为学习入口的中心，如果候选 API列表中的所有API实体是方法或者属性，则算法会首先将其转化为对应 的类或接口。

进一步地，用户在输入待查询文本的过程中，考虑到有经验的学习者也 可能直接会对API限定名进行搜索，为了保障有经验的学习者输入API限定 名之后，能够返回给学习者相应的API实体，本申请还包括以下步骤：

步骤501：从用户输入的查询文本中，提取出待查询API限定名。

步骤502：在所述目标知识图谱中，查询与所述待查询API限定名匹配 的API限定名。

步骤503：将与所述待查询API限定名匹配的API限定名关联的API实 体，置于所述排列顺序的首位。

其中，若在目标知识图谱中查找到与待查询API限定名完全匹配的API 限定名，则确定用户可能是在对API限定名进行搜索，此时可以将匹配的 API限定名所关联的API实体添加在排列顺序的首位，其余API实体排列在 该API限定名所关联的API实体的后面。

步骤504：推荐所述置于排列顺序首位的API限定名所表征的API实体。

从上可以看出，本申请基于目标知识图谱可以提供各种功能，进而构建 出一个API学习辅助系统，具体请参见图10，该API学习辅助系统具体可 以总共提供以下几种功能：查看API学习入口推荐、搜索API学习入口、查 看可视化API知识图谱(目标知识图谱)、查看API详细信息、以及查看API 相关SO讨论贴。

实施例二

基于同一发明构思，本申请实施例二提供一种面向初学者的API自适应 推荐系统，该系统包括：

解析模块，用于解析API文档，得到多个API元素以及多个API元素 之间的第一关联关系；

初始知识图谱构建模块，用于基于多个API元素以及多个API元素之间 的关联关系，构建具有多类API实体的初始知识图谱，每类API实体用于描 述一种API；每类API实体均具有多个相互连接的API实体，API实体之间 相连接的边表征所述第一关联关系，所述第一关联关系至少包括继承关系、 包含关系、实现关系；

获取模块，用于获取多个SO讨论帖，每个SO讨论帖中包括至少一个 API实体指称，所述API实体指称为所述SO讨论帖中讨论的API元素；

目标知识图谱构建模块，用于在初始知识图谱中，构建所述每个SO讨 论帖与对应的目标API实体之间的第二关联关系，得到目标知识图谱；

学习入口构建模块，用于对所述目标知识图谱上的多个API实体进行聚 类，得到不同的API实体组，以构建为不同主题的学习入口。

可选地，所述初始知识图谱构建模块包括：

提取模块，用于从所述SO讨论帖中提取出API实体指称；

一次匹配模块，用于将所述API实体指称分别与所述每类API实体中的 多个API实体的API限定名进行一次匹配，得到与所述API实体指称所匹 配的多个第一候选API实体，所述API限定名为所述API实体的命名；

二次匹配模块，用于将所述API实体指称分别与多个第一候选API实体 进行二次匹配，得到与所述API实体指称匹配的目标API实体；

关系建立模块，用于建立所述API实体指称所在的SO讨论帖与所述目 标API实体之间的第二关联关系。

可选地，所述提取模块包括：

预处理模块，用于对所述SO讨论帖进行预处理，得到句子的集合；

句子处理模块，用于对所述句子的集合进行处理，得到词汇序列；

序列标记模块，用于在所述词汇序列中，使用API命名实体识别模型标 记所述API实体指称所对应的词汇，作为提取出的API实体指称。

可选地，所述二次匹配模块包括：

抽取模块，用于对所述第一候选API实体的API限定名进行抽取，分别 得到多个短限定名；

短限定名确定模块，用于从所述多个短限定名中，确定被所述API实体 指称所包含的短限定名，以作为目标短限定名；

匹配模块，用于将所述API实体指称分别与所述目标短限定名所表征的 第一候选API实体进行匹配，得到所述目标API实体。

可选地，所述匹配模块包括：

语义匹配模块，用于采用语义匹配模型，将所述API实体指称的上下文 文本，分别与所述目标短限定名所表征的多个第一候选API实体的描述文本 进行语义匹配；

目标API实体确定模块，用于将语义匹配度高于预设匹配度的第一候选 API实体，作为所述目标API实体。

可选地，所述学习入口构建模块包括：

讨论确定模块，用于基于所述目标知识图谱，获取在同一篇SO讨论帖 中被讨论超过预设次数的两个API实体；

添加模块，用于将所述两个API实体添加至SO社区知识图谱中，并建 立所述两个API实体之间的第三关联关系；

聚类模块，用于基于Louvain算法，对所述SO社区知识图谱中每两个 所述API实体之间的第三关联关系进行分析，以将多个API实体聚类为不同 的API实体组，其中，每个所述API实体组中包括多个两两之间具有所述第 三关联关系的API实体；

构建子模块，用于将每个不同的API实体组，构建为不同API的学习入 口。

可选地，所述系统包括：

第四关联关系建立模块，用于在所述目标知识图谱中，建立所述API 实体与对应的第一领域术语之间的第四关联关系，所述第一领域术语来源于 所述API文档；

第五关联关系建立模块，用于建立所述第一领域术语与第二领域术语之 间的第五关联关系，所述第二领域术语来源于维基百科；

待查询领域术语提取模块，用于从用户输入的查询文本中，提取出待查 询领域术语；

候选API列表确定模块，用于将与所述待查询领域术语匹配的多个第一 领域术语所关联的第二候选API实体，以及与所述待查询领域术语匹配的多 个第二领域术语所关联的第三候选API实体，作为候选API列表；

语义匹配模块，用于将所述待查询领域术语与所述候选API列表中的所 有API实体进行语义匹配，得到所有API实体的排列顺序；

第一推荐模块，用于在所述排列顺序中，推荐位于首位的API实体。

可选地，所述系统包括：

待查询API限定名提取模块，用于从用户输入的查询文本中，提取出待 查询API限定名；

查询模块，用于在所述目标知识图谱中，查询与所述待查询API限定名 匹配的API限定名；

重置模块，用于将与所述待查询API限定名匹配的API限定名关联的 API实体，置于所述排列顺序的首位；

第二推荐模块，用于推荐所述置于排列顺序首位的API限定名所表征的 API实体。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较 简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明 的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见 即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装 置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全 软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例 可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介 质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程 序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计 算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实 现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的 流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算 机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器， 使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生 用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中 指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理 终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读 存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个 流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设 备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计 算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用 于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指 定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦 得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以， 所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所 有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语 仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求 或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术 语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得 包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且 还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或 者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……” 限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中 还存在另外的相同要素。

以上对本申请所提供的一种面向初学者的API自适应推荐方法与系统， 进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了 阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同 时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应 用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的 限制。

Claims (10)

1.一种面向初学者的API自适应推荐方法，其特征在于，所述方法包括：

解析API文档，得到多个API元素以及多个API元素之间的第一关联关系；

基于多个API元素以及多个API元素之间的关联关系，构建具有多类API实体的初始知识图谱，每类API实体用于描述一种API；每类API实体均具有多个相互连接的API实体，API实体之间相连接的边表征所述第一关联关系，所述第一关联关系至少包括继承关系、包含关系、实现关系；

获取多个SO讨论帖，每个SO讨论帖中包括至少一个API实体指称，所述API实体指称为所述SO讨论帖中讨论的API元素；

在初始知识图谱中，构建所述每个SO讨论帖与对应的目标API实体之间的第二关联关系，得到目标知识图谱；

对所述目标知识图谱上的多个API实体进行聚类，得到不同的API实体组，以构建为不同主题的学习入口。

2.根据权利要求1所述的方法，其特征在于，构建所述每个SO讨论帖与对应的目标API实体之间的第二关联关系，包括：

从所述SO讨论帖中提取出API实体指称；

将所述API实体指称分别与所述每类API实体中的多个API实体的API限定名进行一次匹配，得到与所述API实体指称所匹配的多个第一候选API实体，所述API限定名为所述API实体的命名；

将所述API实体指称分别与多个第一候选API实体进行二次匹配，得到与所述API实体指称匹配的目标API实体；

建立所述API实体指称所在的SO讨论帖与所述目标API实体之间的第二关联关系。

3.根据权利要求2所述的方法，其特征在于，从所述SO讨论帖中提取出API实体指称包括：

对所述SO讨论帖进行预处理，得到句子的集合；

对所述句子的集合进行处理，得到词汇序列；

在所述词汇序列中，使用API命名实体识别模型标记所述API实体指称所对应的词汇，作为提取出的API实体指称。

4.根据权利要求2所述的方法，其特征在于，将所述API实体指称分别与多个第一候选API实体进行二次匹配，得到与所述API实体指称匹配的目标API实体，包括：

对所述第一候选API实体的API限定名进行抽取，分别得到多个短限定名；

从所述多个短限定名中，确定被所述API实体指称所包含的短限定名，以作为目标短限定名；

将所述API实体指称分别与所述目标短限定名所表征的第一候选API实体进行匹配，得到所述目标API实体。

5.根据权利要求4所述的方法，其特征在于，将所述API实体指称分别与所述目标短限定名所表征的第一候选API实体进行匹配，得到所述目标API实体，包括：

采用语义匹配模型，将所述API实体指称的上下文文本，分别与所述目标短限定名所表征的多个第一候选API实体的描述文本进行语义匹配；

将语义匹配度高于预设匹配度的第一候选API实体，作为所述目标API实体。

6.根据权利要求1所述的方法，其特征在于，将所述目标知识图谱上的多个API实体聚类为不同的API实体组，以构建不同的学习入口，包括：

基于所述目标知识图谱，获取在同一篇SO讨论帖中被讨论超过预设次数的两个API实体；

将所述两个API实体添加至SO社区知识图谱中，并建立所述两个API实体之间的第三关联关系；

基于Louvain算法，对所述SO社区知识图谱中每两个所述API实体之间的第三关联关系进行分析，以将多个API实体聚类为不同的API实体组，其中，每个所述API实体组中包括多个两两之间具有所述第三关联关系的API实体；

将每个不同的API实体组，构建为不同API的学习入口。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述目标知识图谱中，建立所述API实体与对应的第一领域术语之间的第四关联关系，所述第一领域术语来源于所述API文档；

建立所述第一领域术语与第二领域术语之间的第五关联关系，所述第二领域术语来源于维基百科；

从用户输入的查询文本中，提取出待查询领域术语；

将与所述待查询领域术语匹配的多个第一领域术语所关联的第二候选API实体，以及与所述待查询领域术语匹配的多个第二领域术语所关联的第三候选API实体，作为候选API列表；

将所述待查询领域术语与所述候选API列表中的所有API实体进行语义匹配，得到所有API实体的排列顺序；

在所述排列顺序中，推荐位于首位的API实体。

8.根据权利要求7所述的方法，其特征在于，得到所述排列顺序之后，所述方法还包括：

从用户输入的查询文本中，提取出待查询API限定名；

在所述目标知识图谱中，查询与所述待查询API限定名匹配的API限定名；

将与所述待查询API限定名匹配的API限定名关联的API实体，置于所述排列顺序的首位；

推荐所述置于排列顺序首位的API限定名所表征的API实体。

9.一种面向初学者的API自适应推荐系统，其特征在于，所述系统包括：

解析模块，用于解析API文档，得到多个API元素以及多个API元素之间的第一关联关系；

初始知识图谱构建模块，用于基于多个API元素以及多个API元素之间的关联关系，构建具有多类API实体的初始知识图谱，每类API实体用于描述一种API；每类API实体均具有多个相互连接的API实体，API实体之间相连接的边表征所述第一关联关系，所述第一关联关系至少包括继承关系、包含关系、实现关系；

获取模块，用于获取多个SO讨论帖，每个SO讨论帖中包括至少一个API实体指称，所述API实体指称为所述SO讨论帖中讨论的API元素；

目标知识图谱构建模块，用于在初始知识图谱中，构建所述每个SO讨论帖与对应的目标API实体之间的第二关联关系，得到目标知识图谱；

学习入口构建模块，用于对所述目标知识图谱上的多个API实体进行聚类，得到不同的API实体组，以构建为不同主题的学习入口。

10.根据权利要求9所述的系统，其特征在于，所述初始知识图谱构建模块包括：

提取模块，用于从所述SO讨论帖中提取出API实体指称；

一次匹配模块，用于将所述API实体指称分别与所述每类API实体中的多个API实体的API限定名进行一次匹配，得到与所述API实体指称所匹配的多个第一候选API实体，所述API限定名为所述API实体的命名；

二次匹配模块，用于将所述API实体指称分别与多个第一候选API实体进行二次匹配，得到与所述API实体指称匹配的目标API实体；

关系建立模块，用于建立所述API实体指称所在的SO讨论帖与所述目标API实体之间的第二关联关系。

Images