企业近实时社交推荐系统解析
1. 数据概述
- StackExchange 数据集 :该数据集包含 371 个用户,这些用户至少在三个站点之一有一个兴趣或一篇帖子。他们总共提出了 752 个问题,给出了 496 个答案(并非每个问题都有有效答案)。图中还有 607 个标签,StackExchange 图共有 2200 个实体和 15000 条边。
-
DBpedia 背景知识
:DBpedia 提供了相关概念之间的背景知识连接。它从维基百科页面的信息框和其他部分提取信息,并使用 RDF 和简单知识组织系统(SKOS)等词汇将其转换为链接数据。我们使用了 DBpedia 3.7 版本的一个子集,具体文件如下:
- mappingbased_properties_en.nt :通过 DBpedia 项目基于严格本体的提取方法,从维基百科信息框中提取的实体及其属性。
- article_categories_en.nt :从维基百科页面的类别中提取的实体与类别之间的连接。
- skos_categories_en.nt :从维基百科类别树中提取的类别之间的连接,使用 SKOS 词汇进行编码,例如两个类别之间的更广泛或更狭窄的连接。
- disambiguations_en.nt :DBpedia 实体之间的消歧链接。
- redirects_en.nt :DBpedia 实体之间的重定向链接。
这个子集包含了实体之间的所有可用链接,大小为 5.46GB 的原始 NTriples 数据,图中包含 1100 万个实体和 4000 万条边。
2. 数据模式:CISCO ERT
为了将 StackExchange 数据转换为 RDF,我们使用了 Cisco ERT 模式版本 10,并根据演示需要添加了必要的属性。以下是不同元素的具体信息:
|元素|rdf 类型|描述|
| ---- | ---- | ---- |
|帖子|sioc:Post|StackExchange 区分问题和答案|
|问题|advansse:Question|有 dc:description(帖子正文)和 dc:title(帖子标题),可通过 ert:hasTopic 属性添加标签|
|答案|advansse:Answer|有 dc:description,但无 dc:title,通过 advansse:hasAnswer 与问题连接|
|用户|sioc:UserAccount|有 sioc:name(StackExchange 上的显示名称),可通过 ert:interestedIn 属性连接零个或多个标签|
|标签|ctag:Tag|标签字符串用 ctag:label 表示,可通过 ctag:means 属性连接具有相同含义的另一个 URI|
3. ADVANSSE 服务器
ADVANSSE 服务器的实现比抽象架构包含更多组件,主要原因如下:
- 服务器包含 XMPP 客户端和服务器,因为 Ignite OpenFire XMPP 服务器扩展性不佳,个性化组件需作为 XMPP 客户端实现。
- 服务器包含多个 RDF 存储,由于原型中不使用关系数据库,不同组件需要持久化不同类型的数据。
- 推荐算法有两个自己的 RDF 存储,传播激活算法需要可扩展且快速的 RDF 存储,但最佳候选是只读存储,因此使用第二个存储来保存所有可变数据。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(ADVANSSE 连接社交平台):::process --> B(XMPP 客户端: Ignite Smack):::process
B --> C(Web 应用: Tomcat + Servlet):::process
C --> D(RDF 存储: Jena Fuseki):::process
D --> E(ADVANSSE 服务器):::process
E --> F(个性化组件):::process
E --> G(推荐算法):::process
F --> H(XMPP R/W RDF 存储: Jena Fuseki):::process
G --> I(Fast, R/O RDF 存储: HDT):::process
E --> J(XMPP 服务器: Ignite OpenFire):::process
J --> K(XMPP 客户端: Ignite Smack):::process
F --> L(链接解析器):::process
L --> M(RDF 存储: Jena Fuseki):::process
4. 服务器组件详细解析
- XMPP 服务器:Openfire :使用 Ignite OpenFire 3.7.0 版本的标准安装作为 XMPP 服务器,为演示配置了一组用户账户和一些初始订阅。服务器将把从活跃发布者收到的 XMPP 节分发给相关订阅者,RDF 内容以嵌入在 XMPP IQ 节中的 SPARQL 1.1 更新查询的形式分发。由于 Ignite OpenFire 的扩展机制非常受限,我们将 RDF 元数据存储集成到个性化组件中,并为个性化组件添加了 XMPP 客户端,使用 Ignite Smack Java 库实现。
- 个性化组件 :该组件为推荐算法、RDF 元数据存储和 XMPP 服务器提供集成点。为了向用户推荐帖子或获取用户兴趣更新,推荐算法需要将这些数据保存在持久存储中。个性化组件使用 Ignite Smack XMPP 客户端库订阅连接社交平台上的所有用户,新帖子和用户偏好更新将存储在 RDF 元数据存储中,并转发给推荐算法。它通过 HTTP 使用 SPARQL 访问 RDF 元数据存储,通过 HTTP 使用 SPARQL 和 Java API 调用访问推荐算法。
- RDF 元数据存储:Jena Fuseki :使用 Jena Fuseki 2.7.3 版本作为 RDF 元数据存储,它是 Jena TDB 的包装器,提供 SPARQL 查询和更新的 HTTP 端点,支持插入、更新、删除和查询操作。个性化组件有自己的 Jena Fuseki 实例,用于持久化所有发布帖子的元数据,以及确定新的和已看过的推荐。推荐算法也使用一个 Jena Fuseki 实例来保存所有关于用户偏好和新帖子的数据,这些数据可以在个性化组件运行时添加、修改或删除。
-
链接解析器
:为了将提取的 StackExchange 数据集与 DBpedia 的背景知识结合使用,需要将 StackExchange 的标签与 DBpedia 的概念进行链接。我们实现了一个基于 Python 脚本的基线链接解析器,具体步骤如下:
- 为标签分配 URI:为 StackExchange 数据集中使用的每个标签分配 advansse 命名空间中的 URI,并将其 rdf 类型设置为 ctag:Tag。
-
将标签字符串匹配到维基百科页面 URI:使用两个维基百科搜索引擎将标签字符串解析为一个或多个维基百科页面 URI。
- Wikipedia Opensearch API :进行模糊匹配,返回一个(排名最高)结果。
- Wikipedia 全文查询 API :返回排名前 5 的结果。如果 Opensearch API 返回结果,则使用该结果;否则,使用全文查询 API 的第一个结果。
- 将维基百科页面 URI 匹配到 DBpedia 实体 URI:使用 DBpedia SPARQL 端点找到与维基百科页面 URI 对应的 DBpedia 实体 URI,DBpedia 使用 foaf:primaryTopic 属性编码此连接。
最终结果是一个 NTriple 文件,通过 ctag:means 属性将标签 URI 与 DBpedia URI 连接起来,该文件可以与 StackExchange 和 DBpedia 数据集一起加载到 RDF 存储中。
企业近实时社交推荐系统解析
5. 推荐算法
推荐算法为 ADVANSSE 演示器实现了传播激活算法,该算法适合 ADVANSSE 的用例,能实现多源和跨域用户配置文件的推荐。它结合了基于内容和基于知识的推荐算法的特点,需要一个语义网络来运行。
-
输入数据
:来自 StackExchange 数据集的用户配置文件和帖子,其中包含用于用户配置文件兴趣和帖子标签的纯文本标签。
-
背景知识
:DBpedia 图以及链接解析器的结果,间接通过 DBpedia 提供 StackExchange 数据中相似标签的背景信息。
-
推荐输出
:为每个用户提供三个排名列表,分别是帖子、用户和标签的前 k 个推荐。
推荐算法由个性化组件通过 Java API 触发,所有带有新帖子和用户兴趣更新的 RDF 更新都从个性化组件传递给推荐算法,以保持其自身数据的最新状态。
6. 算法实现与测试
- 实现 :传播激活算法的实现使用了 Header - Dictionary - Triples (HDT) RDF 存储。HDT 是一个快速且可扩展的 RDF 存储后端,作为一个常规的 Java 库,能让我们近乎实时地返回推荐结果,并轻松集成到 ADVANSSE 服务器中。
- 基准测试结果 :使用 StackExchange 数据集进行基准测试,该数据集包含 371 个用户,平均每个用户有 6 个兴趣。大多数用户节点的度在 2 到 5 之间,有长尾分布,最高可达 51,还有两个度为 140 和 176 的离群值。
通过对不同配置进行实验,最佳配置如下:
|配置项|详情|
| ---- | ---- |
|距离约束|禁用|
|扇出约束|启用|
|目标激活数|10|
|激活阈值|0.5|
|初始激活|4.0|
|最大出边数|500|
|最大波数|10|
|阶段数|1|
在这个配置下,371 个用户中有 315 个用户达到了对用户、帖子和标签各 10 个推荐的目标,成功率为 85%。在没有足够推荐的 56 个用户中,64% 只有 2 个出链,20% 只有 3 个出链,这表明不太受欢迎的兴趣或帖子在生成推荐时会出现问题,导致类似冷启动的问题。
该实现的性能允许按需计算推荐,算法的最基本操作是对 HDT 存储的简单查询,平均时长为 0.2 毫秒,但时长会随结果数量线性增加,一次传播激活算法运行的平均时长为 200 毫秒,平均每秒可为 5 个用户生成推荐,或按需为 1 个用户生成推荐(不到 1 秒)。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(开始):::process --> B(选择最佳配置):::process
B --> C(运行算法):::process
C --> D{是否达到目标推荐数}:::process
D -- 是 --> E(输出推荐结果):::process
D -- 否 --> F(分析出链情况):::process
F --> G(考虑冷启动问题):::process
G --> C
E --> H(结束):::process
7. 数据存储
基于 HDT 的传播激活算法实现使用了两个 RDF 存储来达到基准测试中描述的速度:
-
HDT 存储
:针对快速查询和完全在内存中处理大型数据集进行了优化,使用压缩二叉树进行存储,能将大型数据集完全装入内存并快速回答查询。演示中使用的 DBpedia 图有 1100 万个实体和 4000 万条边,使用 HDT 对该数据集的压缩率为 92%,原始 NTriples 大小为 5.46GB,HDT 文件为 436MB,简单主题或对象查询的平均时长为 0.2 毫秒。但 HDT 是只读存储,用于保存 DBpedia 数据集的所有静态数据。
-
Apache Jena TDB
:提供读写功能,作为 Apache Jena 项目的持久 RDF 存储,可通过 SPARQL 查询进行查询,并通过 SPARQL 更新进行管理。用于保存 StackExchange 数据集的所有数据,因为需要动态添加新的用户配置文件和新帖子。StackExchange 数据集由 2200 个实体和 15000 条边组成,仅占 DBpedia 数据集的 0.003%。
将 Jena TDB 与 HDT 结合使用,与仅使用 HDT 相比,传播激活算法的执行时间会增加一倍,但比仅使用 Jena TDB 处理所有数据要快,这样可以将 HDT 对 99% 数据的快速查询执行与对 1% 数据的修改操作相结合,实现按需、近乎实时的推荐算法执行。
8. ADVANSSE 连接社交平台
ADVANSSE 架构允许多个社交平台通过 XMPP 协议连接到 ADVANSSE 服务器。演示中实现了一个简单的网站来模拟社交平台上用户的行为:
-
Web 应用
:使用 Apache Tomcat 7.0 实现的 Java servlet,允许用户创建账户、登录网站。用户可以创建带标签的帖子、添加或删除兴趣标签、订阅或取消订阅其他用户、为订阅添加关键字过滤器,还可以查看兴趣、用户和帖子的推荐。
-
XMPP 客户端
:Java servlet 通过 Ignite Smack XMPP 客户端库连接到 ADVANSSE 服务器。
-
RDF 存储
:使用 Jena Fuseki 作为用户生成内容和用户兴趣的持久存储,它提供了快速的存储后端(Jena TDB)和 SPARQL HTTP 端点,Java servlet 使用该端点查询和更新存储的 RDF 数据。
9. 总结与展望
该系统提出了一种现代企业分布式社交平台的架构,使用可扩展消息和存在协议(XMPP)和 RDF 的 SPARQL 查询语言来集成分布式社交平台的数据。同时审查了适用于企业社交网络的个性化方法,识别了个性化方法的需求,并阐述了传播激活方法在企业用例中的应用。
未来工作包括对分布式社交平台进行定性和定量评估。计划在不同架构约束下测量和评估 XMPP 和 SPARQL 结合的性能,将传播激活方法与最先进的方法(如协同过滤或基于内容的方法)进行定性比较评估,还将进行一组定量实验和用户研究,使用标准信息检索指标(如精度/召回率)和用户感知来评估所提出方法的性能。
超级会员免费看
5万+

被折叠的 条评论
为什么被折叠?



