上一篇文章，分享了内容管理系统CMS在内容生产环节的产品思考与设计。今天来和大家聊聊内容管理系统CMS中，关于内容过滤的思考与总结。

内容的过滤

遵守国家法律法规、使平台免受违规内容的影响，很好地规避平台运营风险；维护内容社区健康，使用户免受垃圾内容的困扰，最大地保障用户消费体验。

这些都需要建立在对内容进行有效过滤的基础上。而过滤的工作量是巨大的，尤其当用户量和内容社区的氛围都做起来之后，就更是难以想象的。纯靠人工来完成是不可行、不准确和效率极低的，必须采用机器和系统检测，而机器学习和系统搭建是需要时间周期的，实现难度也是很大很大的。

一个内容社区可能同时会有好几个不同类型的内容，比如：文本、图片、视频、音频等。内容的类型不同，过滤所使用的技术手段也是不同。

如果所处的是一个创业团队，所做的是一个试验性产品，那在搭建CMS系统的过程中，同步来搭建这个内容过滤系统是不可能的，也是不明智的。

现在市场上，针对各种各样类型的内容，都已经有很多成熟的saas平台，提供优质的内容过滤服务，而且部署对接起来也很是方便。

有一些大的平台，因为业务的成熟度和数据的安全性，以及资源和技术的实力，自研了内容过滤系统，现在很多也投入商用了，比如：腾讯、阿里、百度、网易。

1.1 选择saas服务的参考点

Sue因为工作和学习的原因，调研过一些内容过滤的saas平台，对于如何选择有自己一点不成熟的总结，可以跟大家分享一下：

• 根据主要的内容类型来做选择，大平台不一定一好百好；
• 结合产品阶段、用户量级，对比分析服务的计费方式；
• 在满足需求的情况下，充分考虑性价比；
• 别在一棵树上吊死，不同阶段和量级，切换的不只是不同套餐，完全可以考虑换一家合作（可能更划算）。

1.2 saas服务的对接

如果接入第三方服务，利用第三方的技术方案完成内容过滤，那就只需要根据第三方返回的过滤结果，对内容进行不同的处理即可。

通常，第三方的过滤系统会返回以下几个信息：

1）判断依据

• 违规的文本段落、图片、音频和视频片段；
• 这是人工质检系统准确性、也是和内容发布者反馈违规内容的凭据。

2）风险描述

针对违规内容的类型描述，比如：

• 文本：广告文本、涉黄文本、暴恐文本、涉政文本、辱骂文本、灌水文本等等；
• 图片：涉黄图片、涉政图片、暴恐图片、违禁图片、广告图片等等；
• 音频（直播/点播）：涉黄语音、违规语音、推广语音等等；
• 视频（直播/点播）：涉黄视频、涉政视频、暴恐视频、违禁视频、广告视频等等。

3）过滤结果

内容过滤的判断结果和内容违规的等级鉴定，一般分为三类：安全、可疑、危险。

而我们需要做的就是，依据过滤结果来处理内容，也就是定义内容发布是否生效、内容的显示状态是前端展示还是屏蔽不展示等等。

发布的内容对于生产者来说，属于他在平台上的信息财富。我们需要给予充分的尊重，一旦我们要对其发布的内容进行删除/屏蔽等处理，那我们就需要负责任地通知到生产者，清楚告知原因，和提供对方沟通联系的方式，甚至提供申诉通道。

出于对内容生产者（尤其用户）的积极性保护，我们需要对过滤系统的准确性有较高的要求。而这种内容过滤的saas服务，面向的用户是各行各业、各种各样的产品，往往可能存在针对性不高、或者标准过严的情况，所以在刚完成接入后的一段时间内，需要投入一部分精力来帮这个系统和我们产品的磨合。

可以分为两个阶段来处理：

处于磨合阶段时：

Sue的建议方案是：根据过滤系统反馈的过滤结果“安全、危险、可疑”，分别对内容的；

状态进行如下调整：安全——展示内容、危险——屏蔽内容，而“可疑”的内容在磨合阶段。

可以有两种处理方式的：

1. 判断可疑——屏蔽内容（通知用户）——人工检查——确认过严——恢复内容
2. 判断可疑——人工检查——确认过松——屏蔽内容（通知用户）

Sue认为应该选择第（2）方式的，由人工完成二次确认的审核，不应该直接根据过滤结果就做出屏蔽内容的处理。这种做法，既不会传递产品过滤内容不严谨的问题，也不会因为判断不准确而给用户造成烦扰，还能加快系统和产品的磨合。唯一的缺点，就是需要耗费部分人力，但Sue认为在这个时间周期内是值得的。

Sue之前所在的一个内容社区项目中，就有接入一家内容过滤的saas服务，主要过滤的内容类型是文本。而我们的内容社区中，用户讨论的话题可谓是上天下地、纵横古今呀。

从Sue在后台的截图也可以看出来，用户讨论“电影、密码”，就被判断为“危险”了，如果按我们定义的处理方式：“危险——屏蔽内容”，那用户就会被深深”伤害“到了，感觉言论不自由，聊聊电影都被限制。类似的，还有我们的用户在文学板块聊”鲁迅”或“周树人”也曾被限制过。

不能让我们珍贵的用户，成为我们的调试过滤系统准确性的牺牲品呀，如果真要拿用户当“小白鼠”，那麻烦偷着偷着来，别把小白鼠吓跑了（哈哈哈）。

在磨合阶段将“危险内容”默认处理为屏蔽，是要建立在早期对所要接入saas服务的充分调研上，也是为了让有限的人力更多更好地集中关注“可疑内容”，但不代表可以完全放心（哈哈哈，还是刚刚“电影”的那个例子）

所以在磨合阶段，过滤的标准可以相对严格一点。对“可疑内容”，做人工审核； 对“危险内容”，做人工质检。期间要保持和saas平台相关人员的沟通联系，针对性调整适合自己产品的内容过滤标准。

度过磨合阶段后：

通常，saas平台会对他们的过滤系统有一套关于准确性的评估分析标准。我们参考评估分析的结果，也可以自己定义一个基本的评估标准，比如在磨合阶段中，机器判断“可疑”而人工审核“危险”的比例已经优化到60%（数值是假设的），机器判断“危险”的质检准确性也是符合我们期望的了，那就可以算是顺利地过渡完磨合阶段了。

在这之后，我们可以把“可疑内容”的处理方案调整为和“危险内容”一样，也是默认屏蔽，进一步释放所投入的人力，之后保持对“可疑内容”和“危险内容”的人工质检即可。

1.3 容易忽略的中间状态

这里需要考虑一个问题，第三方服务的响应虽说都是毫秒级别的。但真正在投入使用后，你会发现除了反馈内容过滤的结果和状态外，还会有一个“待过滤”/“待处理”的状态。

这属于中间状态，往往可能会忽略或不重视中间状态下对内容的处理，随时会带来前端用户使用上的不明确和不好的体验感受。

Sue总结了一下，前端后台针对这种情况，可以有三种处理方式：

1）假象成功

过滤系统没有返回一个明确的过滤结果（明确安全/明确危险）时，为不影响用户的体验和保护用户创作积极性，都会制造一个发布成功的假象。

这个假象的现象是：用户在前端成功提交发布后，默认进入内容广场页面（如朋友圈），同时在列表第一条可以看到自己刚刚发布的内容。但这时候内容可能处于待审核或可疑待人工二次确认审核的状态中，其他人是暂时看不到这条内容的，而发布者是毫无察觉的，他以为其他人和他一样也能在广场（朋友圈）看到。

这种方式，把过滤系统对发布者的影响控制在最小的程度。如果不是内容被过滤系统判定为有问题，平台对内容进行屏蔽处理时通知发布者，他们可能都不知道原来内容还会被过滤审核。有的平台在“和谐”掉内容时并不会通知发布者，那就更难感知到了。

采取该方案的产品：微信。

2）等待结果

这种方式和第一种方式的页面流程比较相似，同样是在用户成功提交后，将用户带到内容广场页，但也会在页面内提示发布的进度情况（进度条的形式“soul”）或在内容下方提示“审核中”（文字提示的形式“探探”）。相同的是，中间状态的内容对他人都暂时不展示；不同的是，有没有让发布者感知到过滤系统的存在。

这种方式，发布者会明确地知道内容在提交后都需要被审核的，也会自觉地在编辑时就尽可能规范自己的言论。

采取该方案的产品：探探。

3）过滤后置

第三种方式，就是中间状态的内容等同于暂时安全的内容，默认对所有人都是直接先展示出来的，内容过滤是后置的，过滤结果出来了，该怎么处理就怎么处理。

这种方式是最大程度地保障了发布者的体验了，但对消费内容的用户体验可能会造成一些影响，也可能对平台运营带来一定的风险。

在体验了很多产品的内容发布流程后，会发现绝大多数产品好像都是采用了这种方式。（可能就真的是因为内容过滤的响应速度足够快）

采取该方案的产品：绿洲。

1.4 黑白名单管理

第三方的过滤系统，一般会支持以下几个名单/库的管理：

• 用户名单
• IP名单
• 设备名单
• URL名单
• 联系方式库

主要的意义是：降低特定对象（用户、IP、设备）或特殊内容（URL、联系方式）的误杀。

例如：

1. 内容运营的账号可能会有短时间大量发布内容的动作，如果没有这些名单管理，则可能会被判定为短时间大量发贴的灌水行为（对设备/IP的情况也是类似的）。
2. 发布的内容可能会附带上有运营推广宣传的URL，或让用户联系客服、工作人员而留的联系方式，如果没有这些名单管理，则可能被判定为广告内容和广告用户。

另外，我们可以在第三方过滤系统之外，建立自己的黑名单管理，将有问题的用户、IP、设备、URL和联系方式进行标记。

用户发布的内容，若被检测出属于符合黑名单中的标记，则无需再推送到第三方过滤系统进行判断，直接则可进行处理。

主要的意义是：减免特定对象（用户、IP、设备）和内容（URL、联系方式）的重复过滤，减少不必要的过滤成本。

以上，就是Sue对于内容管理系统CMS在内容过滤环节的总结与分享。

下期更文预告：搭建内容管理系统CMS（3）——内容呈现的模板化

分享个人一些小小的思考与想法，使自己保持输入转化、总结输出的学习习惯。如有不成熟、不正确的地方，希望有小伙伴指点赐教、欢迎讨论，共同进步。

本文由 @素小白 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议