基于协同过滤算法的宠物线上问诊平台的设计与实现

熊 炜，闵娟娟

（九江学院计算机与大数据科学学院，九江 332005）

0 引言

随着人们生活质量的提高，越来越多的宠物走进了普罗大众的家中。在西方国家，宠物通常被视为家庭成员与重要朋友，作为家庭的一员，宠物的健康也被人们高度关注。学者Baker 提出区域之间宠物的医疗资源是大相径庭的，为解决宠物远程就诊问题，近年来已萌生了宠物在线平台的概念，力图突破时空的限制，提供专属的医疗服务［1‑4］。美国ATA 协会通过多项研究表明，伴随着COVID‑19 的出现，远程问诊得到了更多人的重视，在远程问诊技术的发展之路上，有必要将宠物先引入远程问诊作为研究［5］。

在我国，调查显示宠物医疗已经占整体宠物服务业的29.2%［6］，然而在如此巨大的市场需求下，却隐藏着诸多问题：宠物医疗行业人才缺失、宠物医疗诊所稀缺、宠物治疗费用昂贵，等等［7］。在如此困境之下，改革是必然的。2018 年4 月份，国务院正式发布了《关于促进“互联网+医疗健康”的发展意见》，互联网+医疗成为我国医疗行业里的主流发展方向［8］，其本质是线上问诊的合理应用与推进线上、线下相结合的问诊流程。对于宠物医疗行业而言，这种改变无疑能促进医疗资源分配的合理性，是一场传统服务业与当下互联网相结合的一次技术革命。

综上所述，使传统宠物医疗行业搭上互联网的便车，开发宠物问诊平台有利于对当下宠物医疗资源进行统筹规划，吸引更多合格的、优质的宠物医院与医师加入，通过灵活的线上问诊方式充分利用医疗资源，改善分配不均的现状。同时，可以利用智能推荐算法，结合用户的操作进行平均加权，给予用户智能化的推荐与人性化的流程，从而根据用户的抉择不断对平台进行正向调节［9］。

1 平台功能概述

在查阅现有互联网医疗发展文献、对相关群众做出择医倾向调查、与现有宠物线上问诊类平台进行功能分析与实际使用后，发现从联系医生到医生审查病情，往往实时问诊耗时更长，因此明确了“有问题及时诊、线上线下强结合” 的基本方针［10］。经过分析得出，平台的主要功能有：智能推送医生、线上问诊、查看附近的医院、查看平台优质医生、平台药物购买、订单管理、疾病百科等。

宠物线上平台功能如图1所示。

图1 宠物线上问诊平台功能

下面对用户登录后的核心功能做详细介绍：

（1）智能推送医生。用户登录后，平台会根据用户的偏好以及用户的历史操作智能推送符合用户预期需求的优质医生。

（2）线上问诊。当用户在平台添加好自己的宠物后，可以根据宠物现有情况对医生专家发起图文问诊或预约线上即时问诊。图文问诊中，用户可以发送图片以及文字对宠物病症做出描述，适用于非急性病症；线上即时问诊针对急性病，可以与医生进行即时的沟通，通过图片、文字和语音的方式对病症做出更详细的描述。这两种方式的混合使用，实现了“有问题及时诊”这一思想，使得医生的问诊效率能在必要时达到高点。

（3）查看附近医院。用户可以根据宠物的医疗服务需求，通过地图范围定位对线下的宠物医院进行筛选，在医院板块中可以看到医院的基本介绍以及医院内的医生，用户可以在线上了解医生后，就近选择医院前往问诊，从而推动了线上与线下的“强结合”。

（4）平台药物购买。用户登录后，可以根据医生的建议在平台的商店选择药品加入购物车或者直接购买。

2 平台设计

2.1 用例设计

在需求分析的阶段，通过对目前市场的调研以及相关专业资料的查询，得出一个合理的模型，用例图是一个合理而直观的方式。接下来将从管理员、用户、医生三个角度来探究平台不同使用者的相应功能：

（1）管理员角色是平台的主要管理者，负责统筹管理医院医生、用户订单与上传疾病资讯等。其存在能够使得平台数据更加可靠，确保平台的正常运作。

（2）用户角色是平台核心的主要需求者，用户登录平台后，可以添加宠物、按条件查看宠物医院、根据宠物情况对合适的医生发起问诊请求、评价医生、根据医生的建议或是自身的需求在平台内购买相应药品或将药品加入购物车、对订单进行查看与修改、对个人信息做出修改。

（3）医生角色是平台问诊功能的主要提供者，医生登录后，可以对医生信息进行修改，对接诊时间做出修改，并对用户发起的提问做出专业回复。

宠物线上问诊平台用例图如图2所示。

图2 宠物线上问诊平台用例

2.2 概要设计

数据库的设计需要开发人员对系统的开发背景有整体性的了解，在设计数据库时，要从全面去考虑问题，不应该只考虑数据库在单个页面上的作用，更需要从业务流程以及优化的方面对表之间的合理性做整体的考量［11］。通过探究平台系统内实体与实体的联系，画出实体−联系图，如图3所示。

图3 系统实体-联系

2.3 平台的基本业务流程

流程图作为一个有效的说明工具，能够辅助管理者做出决定，帮助确定可供选择的行动方案，并直观地叙述一个业务的整体运作步骤。

用户的基本业务流程图如图4所示。

图4 用户的基本业务流程

3 平台的实现

3.1 平台实现的关键技术

本平台分为微信小程序端与后台管理端，在小程序端开发中，采用Hubuilder 与微信开发者工具作为开发工具，在开发语言上选择以Vue为内核的uni‑app框架，结合SCSS、JavaScript与uView 2.0 作为页面样式支撑。uni‑app 作为新生的编程框架，其优势在于一次编写，能在多端使用，并且得益于插件库中丰富的开源组件，使得在开发效率上也有了极大的提升。

在后台方面选择了当下最常用的Spring‑Boot+Mybatis‑plus 作为基础框架，极大提升了开发效率，并采取抽象工厂的设计模式，使得系统将具体的类进行抽离，在编写时只需要通过相应的抽象接口进行使用。数据库方面，使用MySQL 与Redis，将暂时性的缓存信息存入Re‑dis，减轻反复查询的负担，重要核心的数据存入MySQL，以确保数据的持续储存。在安全性方面，使用JWT 生成用户的唯一token，存入Redis中，并使用Spring Security对安全访问进行控制，这两项技术成熟实用，能够减轻开发者在安全代码上的重复工作。前后端分离的交互如图5所示。

图5 前后端分离交互

3.2 平台功能实现的关键算法与技术

在用户使用平台的过程中，其中最重要的核心模块有三：一是智能推荐，二是与平台医生的即时问诊技术，三是使用Spring Security、JWT与Redis三位一体的权限认证。

3.2.1 智能推荐

本平台采取的是推荐算法中的基于领域的算法。根据平台的性质与实际调查，选择了基于物品的协调过滤算法（Item CF）。相较于基于用户的协调过滤算法（User CF），Item CF 更加关注用户的历史性操作数据，更能从历史操作中挖掘出用户的潜在兴趣，给予用户更丰富的医生供其选择［12］。在试验下，Item CF 也具备良好的召回率、精确度，并同时保证了对数据的高覆盖度［13］。其算法的本质是为用户建设偏好文档，假设选择医生A 的用户大多数也会选择医生B，那么我们认为医生A 与医生B 相似，相似度高的医生更符合用户偏好，将会优先推送给用户。这个推荐往往是稳定的，因为在医生数量小于用户数量的平台上，避免了频繁更新医生的相似度。其中用户关于医生的操作记录将被转化为用户对医生偏好程度的影响因子，系统中的用户操作对应的影响因子如表1所示。

表1 用户操作影响因子表

假设有四名用户A、B、C、D 对四名宠物医生a，b，c，d进行了操作，如表2所示。

表2 用户操作表

那么根据表1中的对应操作与影响因子相互转化转换，如表3所示。

表3 用户操作对应影响因子表

此时可以通过余弦公式:

便可以计算出相应的医生之间的相似度，但是在表2中可以发现，用户A习惯于对每个医生进行反复的查看与问诊。这是因为某类用户对医生频繁访问与形成习惯性的问诊后，便会造成影响因子数据的不规范性，此时使用余弦公式计算出的结果便不那么准确了，此时就需要算法考虑自动修正这部分数据。这里改用皮尔逊相关系数公式，原理是将用户的操作因子抽象成为医生的向量，再将两个用户操作对应的医生向量减去它们对应的平均值，再通过余弦公式来进行计算［14］。

养生旅游业发展起步晚，没有形成统一规划的格局，吸引力较低。养生旅游作为一种体验式旅游项目，游客停留时间较长，对旅游设施要求高，而旅游道的线路长，弯道大，车道窄，容易使游客感到疲倦与不适。目前，在普洱旅游道内主要以养生为主题的酒店稀少，可接待人数少，难以满足游客需求。此外，农家乐成了主要的接待机构，缺乏规范，设施简陋，卫生条件等不符合养生食疗理念。

皮尔逊相关系数公式为:

其中：系数P即反应操作向量Ri,p与Ri,p之间的关系，当其间取值在［−1,1］之间，这个相关性可以是弱的也可以是强的［15］。皮尔逊相关系数越大，我们认为医生向量相似度越强。当两个向量为正相关时，在通常情况下取约定系数范围对应强度，如表4所示。

表4 系数强度表

本例中借助Python 进行系数计算，其核心代码如下：

通过对用户操作矩阵的计算，我们可以得到医生相关系数，如图6所示。

图6 医生相关系数

所以在本例中，当出现新注册的用户E 仅查看过医生b后，我们可以根据相似度，以医生c、医生a、医生d的顺序对其进行智能推荐。随着用户日常操作所产生的数据日益丰富，传统协同过滤算法的表现也日趋良好［16］。至此，通过统计用户历史操作并进行计算便可以预测用户对医生的偏好，从而达到智能推荐的效果。

3.2.2 即时问诊

平台采用的即时通讯技术源于集成环信SDK，一套通讯组件内部含有多个子系统，开发难度大，开发周期长，整体的成本高昂［17］。所以对于个人开发者，有着良好可扩展性、可靠性与稳定性的第三方SDK 显然是首选。此时，便可以获得一套涵盖文字、emoji 表情、语音、图片的完善聊天页面。然而，仅仅是一个聊天界面显然是不够的，我们必须要考虑两个问题，首先是用户与医生在未读的情况下，是否有未读消息的提示，其次是如何使得这单问诊在规定时间内自动结束。

为解决未读消息的提示，系统将对两种情况分别进行讨论，第一种是当前角色在发送消息时，需要更新的是Redis 中对应角色的未读消息。第二种是关于已读消息，此处并不能使用惯性思维，即进入聊天界面便所有消息已读，因为当前角色在发送消息，对方角色也同样可能在发送消息，会造成Redis 中的未读消息数量超出实际的情况。故只能在退出时，清空对方在Redis中发送的未读消息数量。

为了使问诊订单在超出规定时间后自动结束，平台在用户开始即时问诊订单后，使用expire方法设置倒计时，将用户与医生的消息回复数量全部初始化为0，将其存入Redis中。注意此处订单与消息数量不可以设置为同一个Key，否则订单自动结束后未读消息将会一并自毁。

即时通讯效果图如图7所示。

图7 即时通讯效果

3.2.3 权限认证

身份认证是系统中的核心功能，确认合法性，确保核心资源的安全与稳定是本平台的重要考核指标［18］。平台实际采用的身份认证系统使用了SpringBoot+Spring Security，相较于使用Spring+Spring Security 通过控制反转，注入依赖与面向切面编程的方式，引入SpringBoot 简化了对于文档的编写，将代码量进行了大幅度的缩减［19−20］。本平台验证当前角色的操作是否符合权限需求，都以在接收请求时，请求头中携带的token 是否能够在系统中解析出相应的权限字段作为判定标准。

Spring Security 的本质是由一串过滤器组成的过滤链，如图8所示。

图8 过滤链

在过滤链中，过滤器UsernamePasswordAu‑thenticationFilter 承担处理用户在登录页面填写的用户名密码后的请求登录操作的功能职责。然而在平台的登录流程中，自带的过滤器无法按照预期，即登录成功后在内部响应JWT生成的token，所以需要自定义的Controller 接口接收由前端传入的账号与密码，再通过UserDetail‑Service 对信息进行校验。若用户输入的账号与密码成功匹配，将通过ProviderManager 的方法生成JWT 存入Redis中完成登录流程；若匹配失败，则将被过滤器ExceptionTranslationFilter 捕获，抛出异常并返回给前端。

登录时序图如图9所示。

图9 登录时序

认证过程中出现异常的核心代码如下：

4 结语

宠物线上问诊平台实现了智能化的医生推荐、查看筛选附近诊所、线上问诊、平台购买与订单管理等功能。系统界面简洁大方，运行流畅，可扩展性高，Spring Security 与JWT 的结合使得平台还有更多权限变更的操作空间。使用该平台，不仅用户能够突破周边医疗资源的匮乏困境，而且宠物也能在万里之外获得优质医生的诊断，同时医院与医生也能通过该平台获取额外的知名度。目前宠物医疗与互联网相结合在国内仍是一片巨大的蓝海，相信在未来，线上宠物问诊能够让更多养宠人士受益，助力于宠物经济的良性发展。