编辑
2022-04-21
感悟
00
请注意,本文编写于 966 天前,最后修改于 825 天前,其中某些信息可能已经过时。

目录

起因
基本构成要素
平台定位
目标群体
痛点分析
结论
概要设计
需求分析
功能设计
1. 虚假信息文本监测
2. 自定义舆论监测规则
3. 数据可视化服务

起因

​ 去年7月打计算机程序设计大赛的时候设计了一套互联网虚假信息监测开放平台,本来想着打完比赛就写篇博客,结果比赛越打越多,绝对不是我咕咕咕。最近投实习,暂时闲下来了,分享一下当时的一些设计思路与经验。

基本构成要素

一个开放平台以提供RPC(Remote Procedure Call)远程过程调用服务为主,应该包含以下要素:

  1. 鉴权设计(OAuth1.0、OAuth2.0)
  2. RPC服务

平台定位

​ 开放平台的定位大部分都是ToB的,因此需要精准定位客户需求,这里以我设计的互联网虚假信息监测开放平台为例。

目标群体

​ 要了解客户需求,首先要明确客户到底是哪些人。

​ 显而易见,需要互联网虚假信息监测服务的场景集中于各类社交平台等舆论密集的地方,因此,这种社交平台的开发者和管理者就是我们的目标群体。

痛点分析

​ 确立了目标群体,那么就要分析这个群体最需要什么,即这个行业中存在的痛点在哪,从痛点着手切入,才能开发出好用的产品。

在虚假信息监测开放平台中,目标群体的痛点就在于人力审核互联网舆论的高成本、低效率,众所周知,互联网舆论是非常庞大的,要审核起来非常费劲,但是又不能完全放弃管控,你永远不知道用户会搞出什么幺蛾子

​ 因此,本平台就立足于互联网人力审核成本高、效率低这一痛点上进行构建,平台的核心是监测互联网虚假信息,平台的目标,就是让社交平台的管理人员能够提高舆论审核的工作效率,降低人力成本,将他们从无尽地审核地狱里解放出来。

结论

​ 至此,我们就完成了第一步,开放平台的目标定位,接下来要做的,就是切入我们上面所分析出的行业痛点,进行平台的概要设计

概要设计

​ 在这一阶段我们需要完成整体项目的结构梳理,包括架构、功能点。

需求分析

​ 上面我们确立了平台需要致力于解决的痛点,那么接下来我们就需要针对痛点来推断需求,功能为需求而服务,因此基于关键痛点进行需求分析是非常重要的一个环节。

​ 针对互联网舆论人力审核成本高、效率低这一痛点,我们可以拆分出多条需求。

  1. 监测多种虚假信息文本,主要包括谣言、敏感词、营销号三种

  2. 需要提供自定义化服务,以解决不同平台有不同敏感词监测规范的情况。(比如在B站,你所热爱的就是你的生活,在B站是违禁词,但在其它地方可不一定是)

  3. 需要为接入的平台提供数据可视化服务,以方便用户查看各类虚假信息的趋势,更好地制定舆论管控规则

  4. 要有容易上手的接口设计和详细的说明文档,防止用户看完一头雾水,依然不会用

  5. 稳定可靠的服务支持,毫无疑问一个社交平台的信息量是非常恐怖的,因此我们的平台必须具有极高的稳定性,要能够抗住非常恐怖的流量才可以

功能设计

​ 有了明确的需求,就可以针对需求来设计功能了,我们从上面的五条需求展开来设计功能

1. 虚假信息文本监测

​ 针对于虚假信息文本监测的需求,我们以提供RPC接口的方式为用户提供云端虚假信息监测服务,身份校验采用OAuth1.0原则(因为简单,现在应该使用2.0),通过签发令牌的方式来实现。

​ 鉴于需要至少实现三种不同的舆论识别,也即谣言、敏感词、营销号,所以我们需要提供三套不同的RPC服务,分别就是:谣言监测、敏感词识别、营销文本分类识别。

2. 自定义舆论监测规则

​ 针对部分平台需要自定义监测规则的需求来说,同样可以使用RPC接口的方式为用户提供云端服务,不同与上一点,这个功能下我们需要让用户上传自定义的文件规则。然后后台基于该数据文件,制定适合用户的识别模型。

3. 数据可视化服务

​ 舆论的实时情况统计,统计用户的平台在某个时间段内的虚假信息数量,并展示给用户观看,因此需要后端实现在监测到违法信息时,对其进行一个分类统计的功能,包括在某个时间段内用户所接入平台的谣言舆论数量、带有敏感词监测的舆论数量。

本文作者:伞菌

本文链接:

版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!