[文献翻译自用]基于增强局部敏感哈希的隐私感知跨平台服务推荐

Privacy-Aware Cross-Platform Service Recommendation Based on Enhanced Locality-Sensitive Hashing（LianYong Qi）

(IEEE TRANSACTIONS ON NETWORK SCIENCE AND ENGINEERING, VOL. 8, NO. 2, APRIL-JUNE 2021)

基于增强局部敏感哈希的隐私感知跨平台服务推荐

摘要

推荐系统是用户从海量数据中快速找到感兴趣的有价值信息的有效途径。具体来说，通过捕捉用户的个性化偏好，推荐系统可以通过使用协同过滤来返回最符合用户偏好的物品清单。然而，在大数据环境中，当需要集成来自不同平台的QoS(服务质量)数据，同时还要确保敏感用户信息安全时，用于推荐决策的QoS数据的高度分散的分布带来了巨大的挑战。此外，在数据驱动应用中需要对对数据可用性和隐私之间的权衡，保护QoS数据中包含的敏感用户信息可能会降低QoS数据的可用性，最终导致推荐结果的不准确。考虑到这些挑战，我们增强了经典的局部敏感哈希(LSH)技术，之后提出了一种基于增强LSH的方法，用于准确且不太敏感的跨平台推荐。最后，在著名的WS-DREAM数据集上设计并测试了大量实验。测试报告证明了与其他竞争方法相比，我们的工作在推荐准确性、效率和隐私保护性能方面具有优势。

索引术语—推荐系统、跨平台集成、增强的位置敏感哈希、隐私保护。

1.引言

网络物理世界中可用数据的数量和种类不断增加，使得在大数据中根据用户偏好找到有用信息变得更加困难[1]–[3]。考虑到这一具有挑战性的任务，智能和自动化的协同过滤(CF)推荐技术帮助用户进行服务选择决策，因为CF独立于域并且易于理解[4]-[6]。通常，通过分析用户的历史服务选择和评分记录(例如，QoS(服务质量))，推荐系统可以捕获用户的个性化偏好，然后以简洁和经济的方式向用户返回与他或她的偏好最匹配的推荐项目列表[7]-[9]。

而在大数据环境中，用于形成QoS预测和建议的QoS数据往往不是集中的，而是高度分散的。通常，QoS数据由不同的服务平台收集并存储，这些平台之间通常存在竞争关系。在这种情况下，一个平台往往因为可能带来的隐私泄露问题而不敢与其他方共享其收集的QoS数据，即使数据共享对其有益[10]。因此，对于推荐系统来说，将包含敏感用户信息的跨平台QoS数据结合起来进行全面的用户偏好分析和精确的推荐通常是很困难的。

此外，在大多数数据驱动的应用程序中，通常需要权衡数据可用性和隐私保护问题[11]。例如，匿名技术可以保护敏感的用户数据；然而，由于一些特征和信息将在匿名化过程中被丢弃，可用的匿名数据量将相应地减少。因此，保护敏感信息可能会降低QoS数据的可用性，最终导致不准确的推荐结果。换句话说，很难同时优化QoS数据隐私保护性能和推荐精度。

考虑到上述两个挑战，我们使用增强的局部敏感哈希(LSH)(简写为e-LSH)来修改现有的基于CF的推荐方法。所提出的e-LSH技术可以保证参与多源推荐的多个平台安全高效的集成QoS数据。

具体来说，我们主要做出以下三点科学贡献。
(1) 改进了传统的LSH算法，提高了邻居搜索能力，并将数据隐私引入服务推荐领域。
(2) 提出了一种新的基于增强LSH的跨平台推荐解决方案——SRe-LSH。SRe-LSH平衡了QoS数据隐私和推荐的准确性。
(3) 使用WS- DREAM数据集进行了各种实验。实验报告证明了SRe-LSH在准确性方面的优势，同时确保了用户隐私。

本文剩余部分的结构如下。第二节总结了相关工作，回顾了当前的研究现状。第三部分阐述了隐私感知的跨平台推荐问题，并论证了论文的写作动机。第四节描述了SRe-LSH算法，第五节描述了实验评估。最后，在第六节中，我们得出结论并分析了可能的改进。

2.相关研究

我们从五个角度总结了推荐系统的隐私保护的近期研究。

A. 部分释放(Partial release)【部分释放也还是要释放】
用户可以多次调用服务并生成多条QoS数据。在[12]中，作者建议用户不必公布自己观察到的所有QoS数据，而只公布最佳数据。这样，QoS记录中涉及的大部分优先级都可以得到保护。此外，在[13]中，作者对发布的QoS值和返回的推荐列表的精度之间的关系进行了建模，这为推荐系统提供了一种更灵活的方式来实现隐私和精度之间的折中。然而，在上述文献中，用户仍然需要向其他人透露一些QoS数据，这可能会泄露某些敏感的用户信息。

B. 匿名【降低性能，尤其对本身相似度就很高的数据来说】
在[14]中，作者利用微聚集技术实现了QoS数据的K-匿名性，保护了用户隐私，因为K-匿名性可以部分隐藏敏感的用户身份信息。在[15]中，作者在构建推荐时利用K-anonymey来泛化敏感的用户位置信息，以保护用户隐私。然而，正如我们之前在第一部分中所分析的，匿名QoS数据很可能会减少可用QoS数据的数量，并最终产生不准确且不可靠的推荐结果。具体来说，如果相似度非常高，推荐性能会显著降低，这可能会降低用户满意度。

C. 加密【耗时且通信成本高】
在[16]中，作者在众包应用中使用多项式加密函数来保护用户和提供商的关键信息，如用户需求和服务函数；通过这种方式，用户的敏感任务可以以安全的方式外包和执行。在[17]中应用了同态加密技术来保护部分敏感用户信息并降低加密成本。然而，作为一种相对较重的数据保护策略，加密通常既耗时又计算昂贵。此外，在大多数跨平台推荐应用中，加密或解密的数据需要在不同方之间传输，这也会产生额外的通信成本。

D. 扰动【累计噪声导致推荐不准确】
在[18]中，采用扰动策略来模糊推荐过程中使用的敏感QoS数据。将真实的服务质量数据转化为混乱的数据，利用这些数据进行推荐决策。同样，在[19]–[20]中采用了差分隐私（DP)技术来实现数据中断。然而，差分隐私技术通常涉及数据密集型计算，时间复杂度很高。此外，还会累积噪声数据，这可能会降低QoS数据的可用性，从而导致不准确的推荐结果。

E. 局部敏感哈希
哈希技术最近被用来在跨平台推荐过程中保护敏感的用户信息。在[21]中，作者结合LSH和基于用户的CF来构建不太敏感的用户索引(从用户体验的敏感QoS数据转换而来的另一个用户身份；例如(1，0，1))表，然后使用用户索引来查找在随后的推荐决策过程中至关重要的相邻用户。类似地，在[22]中，将基于项目的CF和LSH相结合，生成敏感性较低的服务索引表；随后，使用服务索引来查找相邻服务，以产生最终推荐列表。然而，作为一种概率邻居搜索策略，LSH在执行隐私保护推荐时不能始终保证良好的准确性，这大大降低了用户满意度。

总之，现有的隐私感知推荐研究往往无法在QoS数据隐私和推荐准确性之间实现良好的平衡或权衡。考虑到这一具有挑战性的问题，本文对现有的LSH技术进行了改进，以提高其做出准确推荐的能力，同时保护多源推荐决策中涉及的敏感用户数据。随后，我们根据增强的LSH提出了一个安全的跨平台推荐解决方案，命名为SRe-LSH。有关SRe-LSH的详细信息将在第四节中介绍。

3.动机

接下来，我们通过一个真实例子来引出我们的论文。随后，我们形式化了本文重点研究的隐私感知跨平台服务推荐问题。

A. 论文动机

我们利用图1中的现实应用场景来描述我们工作的动机。在这个例子中，用户生成的QoS数据由三个平台存储，谷歌、亚马逊和IBM；Alex是一个请求新推荐服务的目标用户。在这种情况下，推荐系统需要同时考虑和整合分布在三个平台上的所有QoS数据，以便进行全面的用户偏好或兴趣分析，并最终向Alex返回一组Alex以前从未收到过的新的优选的服务。

在上述跨平台QoS数据集成过程中，通常存在两个具有挑战性的问题。首先，三大平台(即谷歌、亚马逊和IBM)都缺乏足够的动力向推荐系统发布QoS数据，因为可能会有隐私泄露的情况；换句话说，缺乏安全的QoS数据共享机制。其次，由于在数据驱动的应用程序中，数据可用性和隐私之间存在共同的权衡，保护QoS数据中的私有用户信息可能会降低QoS数据的可用性，并最终导致推荐结果的不准确。【没有隐私保障；导致性能下降】

因此，如何在跨平台推荐场景中平衡数据隐私和准确性之间的权衡，成为一个需要深入研究的现实而重大的挑战。我们将在下一节研究这一具有挑战性的问题。

B. 问题定式化

为了更好地阐明隐私感知的跨平台服务推荐问题以及我们的解决方案，我们在表I中汇总了本文中使用的符号。这里，前六个符号用于问题描述，而后八个符号用于指定我们提出的推荐方法。为了简单起见，在下面的讨论中只考虑一个QoS标准q。

如表I所示，在本文中，我们考虑了包含m个用户$u^1,u^2,...,u^m$的推荐场景；和n个候选服务器$w{s}_1,\dots ,w{s}_n$; 用户在维度q上的历史 QoS 数据$q_{i,j,k}$存储在 z 平台$p{f}_1,\dots ,p{f}_z$。 因此，本文研究的隐私感知跨平台服务推荐问题可以描述如下:
通过分析QoS数据，$q_{i,j,k}(1\le i\le m,1\le j\le n,1\le k\le z)$ ,推荐系统向目标用户u^#返回最佳候选服务，同时确保$q_{i,j,k}$中敏感信息的安全。在下一节中，我们将提出一种新的解决方案来实现上述推荐目标。

4.推荐方法 $S{R}_{e-LSH}$

A.传统的LSH理论

在介绍增强 LSH 技术之前，我们首先阐明传统 LSH 的主要原理。LSH 是一种哈希技术，它以注重隐私方式在许多候选人中搜索近似的邻居，既有效又高效。一般来说，LSH 的主要思想可以描述如下[23]。

假设一个数据空间中有两个点A和B，其中d(A，B)表示从A到B的距离，h(.)是LSH函数。然后，如果A和B足够接近，那么通过LSH过程，这两个点将以很大的概率被分配相同的指数。更正式地说，如果d(A,B)小于距离阈值$d_1$，那么散列值h(A)=h(B)的概率大于阈值$p_1$ (见equation(1))。

相反，如果A和B的距离足够远，那么通过LSH，这两个点将会以很高的概率被划分在两个不同的busket里。更正式地说，如果d(A,B)大于距离阈值d2，那么哈希值h(A) = h(B)小于阈值p2的概率(见equation(2))。通过这种方式，我们可以根据它们各自不太敏感的哈希值来判断两个点是否接近，而无需揭示这两个点的具体坐标。 这就是为什么 LSH 可以实现隐私感知的跨平台服务推荐。

传统 LSH 可以帮助我们在进行跨平台信息整合时保护用户敏感数据的安全。然而，LSH 固有的基于概率的搜索特性在搜索目标用户u#的邻近用户时可能会带来意想不到的“假阳性”或“假阴性”结果，最终影响推荐列表的准确性。因此，我们将加强传统的 LSH并进一步利用增强的 LSH 来实现隐私意识跨平台环境中的准确推荐。

B.Our solution: :$S{R}_{e-LSH}$

在我们关注的隐私感知服务推荐场景中，有两方：（1）托管敏感 QoS 数据的平台（2）旨在通过分析敏感 QoS 数据进行推荐的推荐系统。$S{R}_{e-LSH}$的基本思想如下：首先，对于每个托管QoS数据的平台，我们在增强LSH的基础上生成隐私少的用户索引； 其次，推荐系统根据生成的用户索引找到与$u^{\#}$ 相似的用户；第三，针对$u^{\#}$ 预测候选服务上缺失的QoS值，并据此做出最终推荐。

总结来说，$S{R}_{e-LSH}$算法主要包括三个部分，如Fig2所示。
Step1: Use index Generation Based on Enhanced LSH
在这一部分，我们会基于增强的LSH技术生成用户索引。如Table1所示，$w{s}_1,\dots ,w{s}_n$表示所有平台$p{f}_1,\dots ,p{f}_z$的候选服务器。因此，对于一个用户$u_i(1\le i\le m)$，她/他在平台$p{f}_k$产生了QoS记录，该记录可以转化为一个n维向量，$\overrightarrow{u_{i(k)}}=(q_{i,1,k},q_{i,2,k},\dots ,q_{i,n,k})$，如果$p{f}_k$没有通过$u_i$记录$w{s}_j$在q上的QoS值，则令$q_{i,j,k}=0(1\le j\le n)$。

然后，我们随机生成G个n维向量，$\overrightarrow{v_1},\overrightarrow{v_2},\dots ,\overrightarrow{v_n}$，如equation(3)。$\overrightarrow{v_g}=\overrightarrow{v_{g,}},\dots ,\overrightarrow{v_{g,n}}(1\le g\le G),v_{g,j}\in [-1,1]$。我们随机选择C个向量，$\overrightarrow{v_1},\overrightarrow{v_2},\dots ,\overrightarrow{v_C}$，并用$\overrightarrow{u_{i(k)}}$根据equation(4)计算向量的点积。如果点积$\overrightarrow{u_{i(k)}}\ast \overrightarrow{v_y}>0(1\le g\le C)$，那么对应的布尔值，${\psi }_i(k)g=1$；否则，${\psi }_i(k)g=0$。因此，我们引入了一个C维的0-1向量，$（{\psi }_{i(k)1},\dots ,{\psi }_{i(k)C})$。

我们将向量转换为十进制数，$De{c}_{i(k)}$ ；举例来说，向量(1,0,1)转换为5。

上述的将向量$\overrightarrow{u_{i(k)}}$转换为5的例子，“$\overrightarrow{u_{i(k)}}->5$”，表示, 表示一个LSH函数对应的投影过程，h(.)，比如$h(u_{i(k)})=5$。由于 LSH 是一种概率感知的邻居搜索策略，一个 LSH 函数通常不足以确保邻居搜索结果的准确。考虑到这一点，r个LSH 函数，$h_1(.),\dots ,h_r(.)$，在这里应用，我们随机选择r次，每次选择C个向量$\overrightarrow{v_1},\overrightarrow{v_2},\dots ,\overrightarrow{v_C}，h_1(u_{i(k)}),\dots ,h_r(u_{i(k)})$。然后，对于用户$u_i$，平台$p{f}_k$记录的他/她的QoS数据可以转换为不太敏感的用户子索引，$H(u_{i(k)})$，如equation(5)。除此之外，因为用户$u_i$的QoS数据分布在z个平台，$p{f}_1,\dots ,p{f}_z$，用户$u_i$的综合索引，$H(u_i)$，可以通过整合z个子索引$H(u_{i(1)}),\dots ,H(u_{i(z)})$来计算,equation(5)。换言之，equation(6)成立。

举个例子，假设有三个LSH函数（r=3）和两个平台（z=2），用户$u_i$对应两个平台的子索引分别是(1,2,3)和(4,5,6)。然后用户$u_i$的综合索引就是一个六维向量（1,2,3,4,5,6）。Step 1 到此结束，Algorithm 1正式给出这一步的伪代码。

Step2:Neighbor Search for $u^{\#}$ Based on User Indices
在Step1，我们已经获得了所有用户的索引值。下一步，根据将用户$u_i$转化为其索引$H(u_i)$的转换”$u_i\to H(u_i)$”，我们可以生成一个LSH表（用T来表示）。因此，根据LSH定理，如果两个用户，$u_1$和$u_2$，如果在LSH表T中具有相同的索引值即$H(u_1)=H(u_2)$，那么很有可能$u_1$和$u_2$就是邻居用户。因此，我们可以利用用户索引可以安全地找到用户u#的邻居。然而，然而，LSH基于概率的特性使得仅基于一个LSH表来评估不同用户之间的邻居关系是不合适的。

因此，我们重复执行Step1生成了L(L>1)个LSH表，$T_1,\dots ,T_L$。利用这L个LSH表，我们可以在一定程度上放宽邻居搜索条件。具体来说，如果在任意$T_x(1\le x\le L)$中都有 $H_x(u_1)=H_x(u_2)$，则可以认为$u_1$和$u_2$就是邻居用户。通过这种方式，我们可以尽可能避免搜索结果中的假阴性（邻居被视为非邻居）问题。

然后，我们介绍如何根据生成的L个哈希表来获得用户$u^{\#}$ 的邻居们，并将其放进集合$U_{Set}$#。具体来说，如果在任意$T_x$都有$H_x(u^{\#})=H_x(u_i)$，则将$u_i$放入$U_{Set}$#。注意用户$u_i$可能在多个哈希表中都与$u^{\#}$ 是邻居。在这种情况下，$u_i$将会被多次放入$U_{Set}$#。本文为了简介，我们不考虑邻居出现的频率。本步计算的伪代码如Algorithm2所示。

Step3: Recommend Services to $u^{\#}$ Based on $u^{\#}$ s Neighbors
对于$u^{\#}$ 之前没有评分过的任意$w{s}_j$，可以根据$U_{Se{t}^{\#}}$ 中 $u^{\#}$ 的邻居来预测它的未来质量（记作$q_{\#,})$）。具体来说，计算公式见equation(7)，$|U_{Se{t}^{\#}}|$表示$U_{Se{t}^{\#}}$ 的大小，$Average(q_{i,j,k})$表示$q_{(}i,j,k)$的平均值。平均质量值适用于以下两种具体情况：（1）用户多次从平台使用服务； (2) 用户从不同平台使用服务。

然后，我们可以通过equation(8)确定具有最优预测质量的最佳推荐（记作$w{s}^{\#}$），最后，我们将$w{s}^{\#}$作为最佳推荐结果返回给$u^{\#}$。本步伪代码见Algorithm3.

5.Evaluation

A.实验设置

我们的实验主要基于WS-DREAM的数据。该数据集记录了全球 339 个用户监控的 5825 个服务的吞吐量数据。为了确保预测的质量，99%的条目被随机从数据集中移除，即吞吐量的密度基质为1%(即β= 1%)。此外，Step1随机生成10个向量,即G = 10:每次选择的向量个数,C =1，2，3，4，5；哈希表的数量，L = 4，6，8，10；散列函数的数目，r = 4，6，8，10。

在下一小节中，我们将$S{R}_{e-LSH}$ 方法与其他两种最先进的方法$SerRe{c}_{distri-LSH}$[25]和 UPCC (benchmark)[26]进行比较，以展示$S{R}_{e-LSH}$ 的可行性和先进性。
实验是在配备 2.60 GHz 处理器和 8.0 GB 内存计算机上进行的其他配置包括Windows10操作系统和python3.6。每次测试执行 150 次，记录平均数据。

B.结果对比和讨论

Profile-1: The Accuracy of Recommendation Results by Three Approaches
准确性是评估推荐能力和潜在用户满意度的关键指标。我们通过平均绝对误差MAE(Mean Absolute Error)和均方根误差RMSE(Root Mean Square Error)这两个参数来评估我们的$S{R}_{e-LSH}$ 的准确性，并和$SerRe{c}_{distri-LSH}$和 UPCC (benchmark)这两个方法进行比较。在$S{R}_{e-LSH}$ 和$SerRe{c}_{distri-LSH}$中，参数L和r都在4-10之间取值；在$S{R}_{e-LSH}$ 中，参数C=2。具体数据见Fig3。

Fig 3 显示对于不同的L和r的取值，由于UPCC并不设计L和r参数，UPCC的性能保持不变。除此之外，$S{R}_{e-LSH}$和$SerRe{c}_{distri-LSH}$ 由于添加了额外的隐私保护方案来保护用户的敏感信息，所以在准确性上的表现比UPCC差。然而本文的$S{R}_{e-LSH}$在MAE和RMSE上都要表现的比$SerRe{c}_{distri-LSH}$好，并且在选择了合适的参数$（L,r,C）$时，性能与UPCC很接近。这是因为我们通过每次选择C 个向量进行散列（Step1）来增强LSH搜索相邻用户的能力。因此，根据加强LSH技术，我们的$S{R}_{e-LSH}$通常可以识别与用户$u^{\#}$最相似的用户们，然后据此给出更准确的推荐结果。

Profile-2：The Number pf Neighbors of $u^{\#}$ Returned by Three Approaches(比较三种方法返回的用户邻居数量)
在基于用户的 CF 方法中， $u^{\#}$的推荐列表取决于 $u^{\#}$的邻居。因此，$U_{Se{t}^{\#}}$的大小也会影响最终推荐结果和用户满意度。考虑到这一点，我们考虑到这一点，我们比较了三种方法返回的u^#的邻居数。在$S{R}_{e-LSH}$和$SerRe{c}_{distri-LSH}$中，参数L和r都在4-10之间取值；在$S{R}_{e-LSH}$中，参数C=2。实验结果见Fig4。

Fig.4显示对于不同的$L-r$值，UPCC方法返回的用户$u^{\#}$的邻居数量保持稳定。除此外，在$S{R}_{e-LSH}$和$SerRe{c}_{distri-LSH}$中，用户$u^{\#}$的邻居数量随着L减少r增加而下降。这种现象的解释如下：较小的L或较大的r表示对邻居查找的过滤约束更严格；结果就会导致更少的$u^{\#}$的邻居。本文提出的$S{R}_{e-LSH}$方法比$SerRe{c}_{distri-LSH}$返回更少的邻居数量，因为$S{R}_{e-LSH}$使用的加强LSH技术要比$SerRe{c}_{distri-LSH}$方法使用的传统的LSH技术更能缩小邻居搜索条件。此外，在$S{R}_{e-LSH}$中，较大的C值通常表示较严格的邻居搜索条件，因此导致u^#的邻居较少。

Profile-3: Time Costs of Three Approaches
我们在这一部分衡量这三个方法的效率。在$S{R}_{e-LSH}$和$SerRe{c}_{distri-LSH}$中，参数L和r都在4-10之间取值；在$S{R}_{e-LSH}$中，参数C=2。测试数据见Fig.5。

结果显示，对于不同的$L-r$值UPCC都保持稳定。$S{R}_{e-LSH}$和$SerRe{c}_{distri-LSH}$都要比UPCC的效率更高，因为基于LSH的方法需要的用户索引表可以离线生成。除此之外，我们的$S{R}_{e-LSH}$要比$SerRe{c}_{distri-LSH}$需要更少的计算时间，因此$S{R}_{e-LSH}$使用的加强的LSH技术通常会在连续的推荐过程中返回更少的邻居数量。除此之外，在$S{R}_{e-LSH}$算法中，当L减少r增加的时候，将会返回更少的邻居数量，进而需要更少的计算时间。

Profile-4: Performances of $S{R}_{e-LSH}$ With Varied Values of Parameters $L,r,C$
我们测量了在不同的$L、r、C$下，$S{R}_{e-LSH}$方法的各种性能指标（MAE，RMSE，u^#的邻居数量）。在实验中，参数L和r都在4-10之间取值，参数C在1-5之间取值。数据见Fig.6。如结果所示，$S{R}_{e-LSH}$的表现随着参数变化发生显著变化。详细的原因已经在Profile-1和Profile-2详细阐述，此处不再赘述。


Profile-5 : The Convergence of MAE/RMSE of $S{R}_{e-LSH}$With Respect to the Experiment Times (收敛性)
我们测量在不同的重复实验次数下，$S{R}_{e-LSH}$方法的MAE/RMSE的收敛性。测试次数在1-150之间，参数C=1,2,3,4。数据的敛散性表现详见Fig.7。在这里，Fig.7的每一行代表一对$L-r$的取值，从104到410；简洁起见，图中省略了$L-r$ 参数对的图例。
如图 7 所示，当实验次数增加时，$S{R}_{e-LSH}$ 方法表现出良好的 MAE/RMSE 收敛性。具体而言，当每个实验测试重复100次以上时，MAE/RMSE 值变得相对稳定。因此，我们合理地将每个实验重复 150 次，并报告平均结果(见第 V-A 节)。

6.Conclusion

分布式服务推荐决策需要一个推荐系统来整合来自多个相关平台的零碎QoS数据。这种跨平台的推荐场景通常会涉及隐私泄露风险，导致平台之间的数据共享不安全。因此，同时保证数据的隐私性和推荐的准确性已经成为一项实际而又具有挑战性的任务。为了应对这一挑战，我们改进了现有的 LSH 技术，以提高其设计精确和隐私感知邻居搜索策略的能力，并进一步提出了一种基于增强 LSH 技术的隐私感知和精确推荐解决方案。最后，基于流行的 WS-DREAM 数据集进行了一系列实验。实验报告表明，我们的解决方案在准确性、时间成本和隐私保护性能方面取得了更好的推荐性能。
对于未来的工作，我们将继续通过引入更多的上下文因素(例如，时间和位置)来改进隐私感知推荐模型，因为服务质量往往是上下文敏感的[27]-[31]。此外，本文仅考虑了一个 QoS 标准，这通常不足以做出全面的推荐决定。因此，多维度(例如，响应时间、吞吐量、安全性[32])建议以及维度相关性[33]是今后工作中需要深入研究的另一个研究课题。最后，用于推荐决策的历史服务质量矩阵通常非常稀疏，因此，推荐可能失败。未来，我们将研究这种 QoS 矩阵稀疏性问题，以提高推荐系统的鲁棒性。