上一篇文章，分享了內容管理系統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 協議