導言

我經常光顧cnbeta，那里的評論很精辟，有時我也會忍不住評上兩句，但近來突然發現發布評論都必須經過審核才會顯示了，這讓我感到非常掃興。由此我又想起了此前我曾討論過的“非法內容核查方法”，我想這種人機結合的審核方式應該會比較適合現在的cnbeta吧。

而現在我已經對此方案有了更深、更好的思路了，想在此分享出來，和大家探討一下，我將在此逐步解析整個審查的流程：

準備工作

要審查臟話，首先需要創建對應的審查規則，每條規則需要提供以下基本信息：

1.         表達式：用于審查內容是否匹配的正則表達式。使用正則的原因在于其靈活性，常規的純文本檢索雖然快，但遇到干擾符等情況時束手無策，而正則就可以輕松解決，例如表達式“[煞傻媽狗屎賤騷瘙搔臊][\s\S]{0,4}?[逼筆比BＢ鼻Ｘ]”可以匹配多種組合的臟話，并可兼容至多4個干擾字符。

2.         首字符列表：用于遍歷文章內容時提取疑似首字符使用。對于表達式“[煞傻媽狗屎賤騷瘙搔臊][\s\S]{0,4}?[逼筆比BＢ鼻Ｘ]”來說，它的首字符列表中應包含“煞傻媽狗屎賤騷瘙搔臊”。

3.         尾字符列表：用于遍歷文章內容時提取疑似尾字符使用。對于表達式“[煞傻媽狗屎賤騷瘙搔臊][\s\S]{0,4}?[逼筆比BＢ鼻Ｘ]”來說，它的尾字符列表中應包含“逼筆比BＢ鼻Ｘ”。

4.         分值：即匹配成功后，為該文章增加的危險度分值。

5.         最大長度：就是臟話內容可能出現的最大字數。對于表達式“[煞傻媽狗屎賤騷瘙搔臊][\s\S]{0,4}?[逼筆比BＢ鼻Ｘ]”來說，它的最大長度應當是6。

6.         精確長度：就是當臟話內容完全無干擾符的情況下的實際字數。此屬性可以用于計算匹配內容的精準程度，比如還是用上面那個表達式“[煞傻媽狗屎賤騷瘙搔臊][\s\S]{0,4}?[逼筆比BＢ鼻Ｘ]”的例子，如果遇到語段“她的媽媽總是逼我們盡快完婚”也會匹配成功，但匹配到的內容長度會是5，與精確長度2進行比對的話，就可以得知此匹配項有可能屬于誤判；而且我們還可以讓程序依據精確程度為文章打分，比如此規則原始分值為10分，但只有40%的精確度，那么在加分時可以只加4分，這樣得出的危險度分值將更具參考性。

盡管主要目的是為了檢驗臟話，但此機制也完全適用于檢驗文章內的廣告、色情、血腥、政治、宗教等內容，甚至還可能用來給內容做積極方面的評分，比如用以審閱學生作文，對特定修辭手法予以加分。

初始化

在審查之前，需要事先載入先前創建的規則，并加以分類，以更方便及加速檢索。

分類的方法是建立一個Dictionary<規則>>類型的對象稱為規則字典，將規則可能觸發的首尾字符組合作為規則字典的鍵值，保存規則到對應的字典內的List中，這樣可以極大地提高檢索時獲取規則的速度。

比如規則的首尾字符分別為“王”和“蛋”，那么就將此規則存入規則字典[“王蛋”]內的List中去，如果此規則存在多種首尾字符組合，那么就保存多個副本到各種首尾組合的規則字典鍵值中。

在分類的同時，還應該采集并創建以下數據，并保存備用：

1.         全局最大長度：即所有規則中，最大長度屬性的最大值。此屬性將用在檢索時進行預判斷，以減少不必要的遍歷次數，提高效率。

2.         全局首字符列表：即所有規則中出現的首字符總列表。此屬性用于檢索文章全文時使用。

3.         全局尾字符列表：即所有規則中出現的尾字符總列表。此屬性用于檢索文章全文時使用。

遍歷內容全文

遍歷內容的每一個字符，依據全局首字符列表和全局尾字符列表找出可能是非法內容首字符或尾字符的字符，將該字符及其位置存入相應列表中，我們在這里將捕獲到的列表稱為疑似首字符列表及疑似尾字符列表。

這里我建議在捕獲到尾字符時倒序插入到疑似尾字符列表中，這樣在遍歷匹配時可以優先匹配字符較多的內容，比如“傻”和“傻瓜”都符合臟話規則的情況下，優先匹配“傻瓜”。

分析并處理捕獲內容

接著遍歷疑似首字符列表，從疑似尾字符列表中找出可能與之搭配的尾字符（根據當前首字符索引位置及規則的全局最大長度進行預篩檢：尾字符索引位置>=首字符索引位置&&尾字符索引位置<=首字符索引位置+全局最大長度）。

再將當前的首尾字符組合成字符串，當作鍵值，向規則字典查詢鍵值內可能匹配的規則（根據當前首尾字符索引位置進行預篩檢：規則最大長度>=尾字符索引位置-首字符索引位置+1）。

從原文中截取首字符索引位置到尾字符索引位置之間的片段，用當前規則進行檢驗，如匹配成功則依據匹配的精確度增加相應比例的分值（算法就是使用規則的精確長度除以實際捕獲到的文本內容長度，再乘以規則的分值），然后開始檢驗跨過當前尾字符索引位置之后的下一個首字符。

除了輸出累計評分外，還可以在審核時生成最高評分、平均精確度、危險內容覆蓋比例等信息，供人工審核時參考。

總結

依照上述步驟，即完成了整個機審過程，然后就可以根據評分結果來決定如何處理文章了。整個過程的簡略的流程示意圖如下：

這個經過改進的方案兼顧了性能與靈活性：只進行一次全文掃描；使用正則表達式進行語段匹配。預計稍加優化，并加入緩存機制的話，常規文章的審核耗時不會超過半秒。

存在并期待改進的缺點：由于采用了首尾字符匹配形式觸發正則驗證，正則中的斷言似乎就無用武之地了，這使得正則發揮的功能有所縮減，魚與熊掌真不可兼得嗎？

最后，再重申一下我對人機協作審核機制的處理建議：

我的想法就說到這里了，歡迎大家回復交流。

聲明：此方案參考并借鑒了Sumtec的字符串多模式精確匹配（臟字/敏感詞匯搜索算法）——TTMP算法 之理論如此一文中的部分算法思路，在此深表感謝。

下載本文的PDF版本：http://uushare.com/user/icesee/file/1387050