聊天机器人的风险 - iYouPort
聊天机器人的风险
- 提出两种方案尝试解决聊天机器人普遍使用中产生的隐私威胁
随着聊天机器人获得牵引力，其在不同垂直领域的应用越来越多，例如保健、银行、约会 …… 办理各种事务等等；尤其是，用户与聊天机器人分享了越来越多的私密信息 —— 相关研究已经开始强调聊天机器人的隐私风险。
本文将提出两种针对聊天机器人对话的隐私保护方法。
第一种方法是基于 “实体” 的隐私过滤和转换，可以直接在客户端上应用。然而，它需要知道聊天机器人的设计模式才能启用。第二种是基于可搜索加密的方案，它能够在不需要任何聊天机器人设计知识的情况下保护用户隐私。
最后将基于一个真实的员工帮助台聊天机器人提出一些实验结果，验证所提出的方法的必要性和可行性。
这份论文来自 Debmalya Biswas，它的预印本可以 在这里 下载。
- 不要错过早前的文章《 世界末日的聊天机器人 》
介绍
聊天机器人被誉为 “下一个交互层”，这意味着人们目前通过与网站/应用互动来消费信息的方式在很多情况下将被聊天机器人（的对话）所取代。Forrester 最近的一份报告 将聊天机器人的最先进技术总结如下：
“尽管消费者对聊天机器人褒贬不一，并对其产生了反弹，但企业普遍了解聊天机器人的价值，并继续采用聊天机器人作为客户服务的主要参与渠道。COVID-19 大流行的影响加强了这些企业利用聊天机器人改善服务和参与度、缓解危机状况的决心。过去两年来，聊天机器人技术供应商也迅速将这种方式应用于跨领域和垂直行业的客户服务。”
聊天机器人的研究大多集中在提高底层自然语言处理(NLP)的精度上，比如聊天机器人能更熟练地理解和回应用户的询问。
随着聊天机器人在不同的垂直领域，如健康、银行、交友等领域的应用越来越多，用户与聊天机器人分享的隐私信息也越来越多； 研究开始强调 聊天机器人的隐私风险
然而，目前所提出的方法仅限于明确共享的个人身份信息(PII)，如信用卡号码、银行账户细节、健康状况、约会偏好 等等；解决方案也仅限于传统的软件安全技术，如存储加密和多因素身份认证。虽然安全基础知识肯定是需要的，但是， 对于用户提出的开放式查询所带来的更高级别的和更隐含的隐私风险，现有文献中还没有涉及 。
例如，我们考虑以下两个用例来理解这种隐私风险的重要性。
用例1： 情感分析的隐私风险。
情感分析基本上是一个NLP分类任务，它允许聊天机器人根据用户的聊天回复来确定用户的（当前）情感 —— 例如，用于帮助台的聊天机器人，这样机器人就能够根据用户的情感来调整其回复。
虽然这样做的目的是为了 “好”，但是，现在让我们考虑一下它们在电商场景中的应用。 通过动态定价，机器人可以根据用户非常 “热情” 的询问，报出更高的价格。
例如，”“哇，这条裙子看起来真不错! 多少钱? ” 与更中性的询问相比，前者可能会导致更高的报价 ，如这样 “这件衣服符合我的要求，它的价格是多少？”
用例2：开放式查询（基于位置）。
考虑关于用户位置的开放式查询所带来的隐私风险。大多数聊天机器人通常是为特定区域设计/部署的。例如，一个人力资源信息机器人可能会被设计为公司有办事处的地方，同样，一个电子商务机器人也会被部署在供应商目前运送产品的国家。
考虑到这一点，诸如 “Hi，我现在在日内瓦。日内瓦的运费是多少？” 鉴于供应商不在瑞士送货，这就不必要地暴露了用户的位置。
在一个组织的背景下，有一个由外包厂商维护的HR聊天机器人（在云平台上），部署在日内瓦和克拉科夫；经常有员工以这样的形式询问：“我们米兰办事处的餐厅在哪里？” 这就会向供应商透露，公司员工最近经常前往米兰办事处。
传统的安全机制，如 限制对聊天机器人日志的访问（通过加密、访问控制策略等）都是不够的；因为需要对日志进行分析，以便对机器人进行持续改进，限制日志访问是完全不现实的，也根本不可能做到。
为了解决上述聊天机器人对话带来的隐私风险，本文将提出两种隐私保护方法。可应用于客户端/应用的隐私过滤和转换，以及可搜索加密，可独立于聊天机器人设计。
II. 隐私保护型聊天
A. 关于聊天机器人的基础
首先提供一些有关当前聊天机器人工作方式的背景知识。在理想的情况下，给定用户以自然语言进行查询，机器人将做出如下响应：
- 了解用户的意图；
- 从知识库中检索相关内容（KB）；
- 综合答案并回应用户（再次以自然语言进行）；
- 保留对话上下文以回答用户的任何后续问题。
遗憾的是，众多技术限制使我们无法实现上述工作流程。如今的企业聊天机器人（例如基于 IBM Watson Assistant , AWS Lex , Microsoft LUIS , Google Dialogflow 的聊天机器人）首先需要通过提供一组问题、问题变体及其对应的答案来进行训练。这些问题可以归纳为 “意图”。问题变体，在机器人术语中称为 “语句”，指的是终端用户可以提出相同问题的样本变体。
我们的想法是提供5到10个这样的语句（针对每个问题）作为输入，在此基础上，希望机器人能够理解50个不同的问题变体。大多数机器人引擎使用统计（如 tf-idf、Bag-of-Words）和深度学习（如BERT）技术的混合以执行意图匹配和情感分析。当没有匹配到可信度高于30%（可配置）的意图时，聊天机器人会返回一个后备答案。对于所有其他情况，引擎会将相应的置信度级别与回答一起返回。
B. 基于实体的隐私保护
本节概述基于 ‘实体’ 的隐私保护方法。实体指的是特定领域的词汇，例如在上述用例 2 中概述的人力资源机器人的上下文中，它们可以指的是办公地点；并且可以用来根据用户（查询）的位置来定制聊天机器人的响应。
基于实体的方法由一个称为隐私保护聊天模块（PPCM）的模块在客户端/应用端应用。PPCM 的设计依赖于对原始聊天机器人内容和聊天机器人平台使用的底层NLP技术的了解。
例如，参考上述用例2，PPCM需要了解原始聊天机器人设计中使用的实体列表（允许的办公地点），这样它就可以相应地应用必要的隐私保护措施。PPCM 解决方案架构如图1所示。它应用了基于过滤和转换的混合隐私保护技术来解决用户聊天的隐私问题。
筛选 —— 对于用例2，参照用户查询：“米兰办公室的餐厅在哪里？”，PPCM 使用与聊天机器人NLP引擎相同的文本提取技术来推断 “米兰” 是实体类型 “位置” 的一个值。随后会对查询进行过滤/删除，使其不会被发送到后端NLP引擎，并向用户传递适当的信息。
转化 —— 为了抵消上述用例1 中强调的定价劣势，PPCM 需要将原始用户查询改编为具有相同语义的更 “中性” 的响应；如此，转化后查询的用户情绪也会被聊天机器人NLP引擎归类为 “中性” —— 如图1所示。抽象形式的转化也可以应用于用例2中的 “位置” 实体类型，其中 “米兰” 被抽象为 “欧洲某地” —— 以保护用户聊天中的隐私。
C. 验证
我们在日内瓦和克拉科夫办事处员工可用的服务台聊天机器人上验证了所提出的基于实体的隐私保护方法。
该聊天机器人是在 IBM Watson Assistant 上开发的，有大约 400个intents，涵盖了与办公设备、交通、餐厅、休闲等设施相关的一系列主题。
intents 配置文件可 在这里 中获取。该聊天机器人已经上线6个多月，我们注意到聊天机器人在新员工、短期外派员工以及常驻日内瓦和克拉科夫的普通员工中同样受到欢迎，给我们带来了约5000名独立的测试受众。
我们在分析前10000个查询构成的基础上报告了一些观察结果。
结果证实了我们的假设，即： 许多员工仍然像与人聊天一样与聊天机器人交谈。他们不是先问直接的问题，而是首先提供一些上下文来开始查询 。
以下是一些示例查询（已编辑删除了公司的特定信息）：
“求助，我的手机又卡了，****，服务台在哪？”
“我开完第X次会议后压力巨大，请问Y餐厅的菜单是什么？”
“你好，我是雅加达办公室的。邮局在这栋楼的哪里？”
“这里的健身课程和我在伦敦上的那种一样吗？”
不用说，前两个查询从员工精神状态（HR）的角度来看是敏感的 —— 揭示了员工在压力和痛苦方面的情绪。后两个查询则不必要地透露了员工的基本位置。我们注意到， 近20%的查询中都嵌入了这种隐私敏感信息 。
为了解决上述隐私问题，我们用 Python 实现了一个PPCM客户端，使用 AWS Lex 进行情感分析。虽然 Lex 与聊天机器人用于情感分析的API —— IBM Tone Analyzer 有所不同；但它们都将情感值返回为0到1之间的值，因此能够交叉验证情感值，同时也表明不同的NLP引擎可以用于聊天机器人和PPCM，只要它们具有 “类似” 的功能。
由于位置是这里唯一的隐私敏感实体，可以基于位置值词典实现它的解析器。在这两种情况下，情感值大于一定阈值和不支持本实体（位置）的隐私敏感查询都得到了令人满意的处理。
在性能方面，我们能够在允许的2秒响应时间内处理两个API调用。唯一的缺点是成本增加了一倍，这是由于额外的 PPCM API 调用造成的。然而，聊天机器人的API调用越来越便宜，如果成本成为瓶颈，可以利用开源的 NLP/聊天机器人引擎，如 RASA 。
D. 基于可搜索加密的分布式隐私保护
现在解决的是聊天机器人黑箱式的场景 —— 主要适用于外部聊天机器人。我们提出了一种基于可搜索加密的方案，能够保护用户的聊天隐私，而不需要对聊天机器人的设计和NLP引擎算法有任何了解。
可搜索加密(SE)是一种保护敏感数据的技术，同时保留了服务器端(云端)的搜索能力。SE允许服务器搜索加密数据而不泄露明文数据中的信息。SE的两个主要分支是可搜索对称加密（SSE）和带关键字搜索的公钥加密（PEKS）。下面重点介绍 PEKS，它可以让知道公钥的多个用户产生密文，但只允许私钥持有者创建暗门。
在 PERK 方案的基础上再提出一种基于（聊天）实体的可搜索加密方案（SEE）。它由以下多项式时间随机化算法组成：
- KGEN(1^k) 输出公私钥对 (A_pub, A_priv)
- SENC(A_pub, w, m) 在实体 w 和公共密钥 A_pub 下输出聊天消息 m 的可搜索加密 s_w
- DOOR(A_priv, w) 输出一个暗门 t_w，它可以按实体w搜索
- TEST(A_pub, s_w, t_w′) 如果 w = w’，则输出消息 m
加密方案 SEE = (KGEN, SENC, DOOR, TEST) 假设决策双线性 Diffie-Hellman（DBDH）问题是棘手的，在随机 oracle 模型中选择明文攻击是语义安全的。
需要注意的是，本案例中的 PPCM 是分布式的，因此我们将 PPCM 的客户端和服务器（云）端组件分别称为 PPCM_C 和 PPCM_S。解决方案架构如下图2所示。
在给定SEE方案的情况下，启用隐私保护聊天的 PPCM 步骤如下：
- 移动聊天应用（PPCM_C）和聊天机器人服务器（PPCM_S）分别称为C和P，运行算法 KGEN(1^k) 来生成它们的公私密钥对：(C_pub，C_priv) 和 (P_pub，P_priv)
- C 为实体列表 L 中的所有实体 w 生成暗门 t_w = DOOR（C_priv，w）并发送给 P
对于每个用户聊天消息m：
- C 解析m，提取m中的所有令牌 W_m，然后为 W_m 中的每个令牌w生成一个可搜索的加密 s_w = SENC(C_pub, w, m)
- C 向S发送与 W_m 中所有令牌w的可搜索加密 s_w 相对应的列表 S_w
- 对于L中的每个实体w，P将其暗门值 t_w 与C共享的可搜索加密值 s_w 进行比较，仅在成功匹配时，P获得聊天信息 m = TEST(C_pub, s_f , t_f)，并根据其设计的对话流程进行聊天机器人响应处理（就像一般没有隐私约束的情况下那样）。
如果没有成功匹配，P就会以 “错误处理” 消息进行响应，并且永远都不会看到用户的原始聊天消息，从而保护了用户的隐私。
III. 结论
本文中概述了两种方法来执行隐私保护的机器人聊天 —— 应用哪种方法取决于聊天机器人设计和实现架构的透明度（仅需客户端/应用端与分布式部署）。希望这些方法能够解决聊天机器人中日益严重的隐私风险问题，从而不影响企业更多地采用聊天机器人。⚪️
文章版权归原作者所有。
