c敏感詞過濾演算法

❶ nxt雙規打同一個程序程式怎麼優化

冗餘的變數拷貝
相對C而言，寫C++代碼經常一不小心就會引入一些臨時變數，比如函數實參、函數返回值。在臨時變數之外，也會有其他一些情況會帶來一些冗餘的變數拷貝。
之前針對冗餘的變數拷貝問題寫過一些帖子，詳情請點擊這里。
多重過濾
很多服務都會過濾的部分結果的需求，比如游戲交談中過濾需要過濾掉敏感詞。假設現在有兩個過濾詞典，一個詞典A內容較少，另一個詞典B內容較多，現在有1000個詞需要驗證合法性。
詞落在詞典A中的概率是1%，落在詞典B中的概率是10%，而判斷詞是否落在詞典A或B中的操作耗時差不多，記作N。
那麼要判斷詞是否合法，有兩種方式：
1. 先判斷詞是否在A中，如果在返回非法；如果不在再判斷是否在B中，如果在返回非法，否則返回合法。
2. 和方式一類似，不過是先判斷是否在B中。
現在我們來計算兩種方式的耗時：
1. 1000*N+1000*(1-1%)*N
2. 1000*N+1000*(1-10%)*N
很明顯，方式二的過濾操作排序優化方式一。
說得有些啰嗦，其實簡單點說就是一句話：多重過濾中把強過濾前移；過濾強度差不多時，過濾消耗較小的前移。
如果有些過濾條件較強，但是過濾消耗也較大怎麼辦？該前移還是後移？個人到沒遇到過這種情況，如果確實需要考慮，也可以用之前計算方式一、二整體耗時的方法也計算一遍。
字元數組的初始化
一些情況是：寫代碼時，很多人為了省事或者說安全起見，每次申請一段內存之後都先全部初始化為0。
另一些情況是：用了一些API，不了解底層實現，把申請的內存全部初始化為0了，比如char buf[1024]=""的方式，有篇帖子寫得比較細，請看這里。
上面提到兩種內存初始化為0的情況，其實有些時候並不是必須的。比如把char型數組作為string使用的時候只需要初始化第一個元素為0即可，或者把char型數組作為一個buffer使用的大部分時候根本不需要初始化。

頻繁的內存申請、釋放操作
曾經遇到過一個性能問題是：一個服務在啟動了4-5小時之後，性能突然下降。
查看系統狀態發現，這時候CPU的sys態比較高，同時又發現系統的minflt值迅速增加，於是懷疑是內存的申請、釋放造成的性能下降。
最後定位到是服務的處理線程中，在處理請求時有大量申請和釋放內存的操作。定位到原因之後就好辦了，直接把臨時申請的內存改為線程變數，性能一下子回升了。
能夠迅速的懷疑到是臨時的內存申請造成的性能下降，還虧之前看過這篇帖子。
至於為什麼是4-5小時之後，性能突然下降，則懷疑是內存碎片的問題。
提前計算
這里需要提到的有兩類問題：
1. 局部的冗餘計算：循環體內的計算提到循環體之前
2. 全局的冗餘計算
問題1很簡單，大部分人應該都接觸到過。有人會問編譯器不是對此有對應的優化措施么？對，公共子表達式優化是可以解決一些這個問題。不過實測發現如果循環體內是調用的某個函數，即使這個函數是沒有side effect的，編譯器也無法針對這種情況進行優化。（我是用gcc 3.4.5測試的，不排除更高版本的gcc或者其他編譯器可以針對這種情況進行優化）
對於問題2，我遇到的情況是：服務代碼中定義了一個const變數，假設叫做MAX_X，處理請求是，會計算一個pow(MAX_X)用作過濾閾值，而性能分析發現，這個pow操作佔了整體系統CPU佔用的10%左右。對於這個問題，我的優化方式很簡單，直接計算定義一個MAX_X_POW變數用作過濾即可。代碼修改2行，性能提升10%。

❷ 百度知道BUG

你好樓主！
這個問題大家都有，網路審核問題。
回答或提問提示通過不一定通過審核了
一般有網址、圖片或有敏感字和qq號等聯系方式就審核嚴格！
如果不違規在[我的提問]里沒有你的提問或回答，那就有可能是被刪除了。
知道原則，以後提問盡量避免違規。
http://www..com/search/_help.html#如何避免問答被刪
你可以到「網路知道投訴吧」里去投訴叫管理員給你恢復!
（寫清楚提問或者回答的時間、主要內容等）
網站:http://post..com/f?kw=%B0%D9%B6%C8%D6%AA%B5%C0%CD%B6%CB%DF

❸ 微軟小冰什麼原理

作者：梁川
鏈接：http://www.hu.com/question/23952075/answer/26243159
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

剛好做過一個類似的產品，雖然沒有那麼高大上，但一些核心技術原理應該也參考意義，說一下做的思路。
類似小冰這樣的產品說簡單也簡單，說復雜也復雜。單純從外面看你會覺得小冰與去年人人網上流行的小黃雞類似，但在技術實現上有本質的差異。
此類應用的大致流程都是：用戶輸入一段話（不一定只是單詞）->後端語義引擎對用戶輸入的語句進行語義解析->推斷用戶最可能的意圖->調用對應的知識庫、應用、計算引擎->返回結果給用戶。

1、最初級的實現方法：關鍵詞匹配
建一個關鍵詞詞庫，對用戶輸入的語句進行關鍵詞匹配，然後調用對應的知識庫。
此種方式入門門檻很低，基本上是個程序員都能實現，例如現在微信公眾平台的智能回復、諸多網站的敏感詞過濾就是此類。
但此種方式存在諸多問題，例如：
a、由於是關鍵詞匹配，如果用戶輸入的語句中出現多個關鍵詞，此時由於涉及關鍵詞權重（與知識庫的關鍵詞對比）等等問題，此時關鍵詞匹配的方法就不擅長了
b、不存在對用戶輸入語句語義的理解，導致會出現答非所問的現象。當然在產品上對回答不上的問題就採用賣萌的方式來規避掉。
c、基本上無自學習能力，規則只能完全由人工維護，且規則基本是固定死的。
d、性能、擴展性較差。還是上面的一句話中包含多個關鍵詞的例子，採用普通程序語言來做關鍵詞匹配，性能奇差。即便採用一些文本處理的演算法來做（例如Double-array trie tree），也很難滿足大規模場景需求。

2、稍微高級點的實現方法：基於搜索引擎、文本挖掘、自然語言處理（NLP）等技術來實現
相對於1的關鍵詞匹配，此種實現方法要解決的核心的問題可以大致理解為：根據一段短文本（例如用戶問的一句話）的語義，推測出用戶最可能的意圖，然後從海量知識庫內容中找出相似度最高的結果。
具體技術實現就不細說了。舉一個很粗糙的例子來簡單說一下此種實現方法處理的思路（不嚴謹，只是為了說明思路）。
假如用戶問：北京後天的溫度是多少度？
如果採用純搜索引擎的思路（基於文本挖掘、NLP的思路不盡相同，但可參考此思路），此時實際流程上分成幾步處理：
1、對輸入語句分詞，得到北京、後天、溫度3個關鍵詞。分詞時候利用了預先建好的行業詞庫，「北京」符合預先建好的城市庫、「後天」符合日期庫、「溫度」符合氣象庫
2、將上述分詞結果與規則庫按照一定演算法做匹配，得出匹配度最高的規則。假定在規則庫中有一條天氣的規則：城市庫+日期庫+氣象庫，從而大致可以推測用戶可能想問某個地方某天的天氣。
3、對語義做具體解析，知道城市是北京，日期是後天，要獲取的知識是天氣預報
4、調用第三方的天氣介面，例如中國天氣網-專業天氣預報、氣象服務門戶 的數據
5、將結果返回給用戶

以上例子其實很粗糙，實際上還有諸多問題沒提到：語義上下文、語義規則的優先順序等等。
例如用戶上一句問：北京後天的溫度是多少度？下一句問：後天的空氣質量呢？這里實際上還涉及語義上下文、用戶歷史喜好數據等等諸多問題。

此種處理方法存在的最大問題：規則庫還主要依賴於人工的建立，雖然有一定的學習能力，但自我學習能力還是較弱。可以藉助一些訓練演算法來完善規則，但效果並不是很好。而這也是目前流行的深度挖掘技術所擅長的。

3、當下時髦且高級的玩法：基於深度挖掘、大數據技術來實現
這是cornata、google now等後端的支撐技術，至於小冰，感覺應該是以2為主+部分領域知識的深度挖掘。

❹ 句易網敏感詞過濾教程是怎麼樣的

這個文案過濾平台篩選敏感詞都是實時更新,只要搜索,你就可以准確地審核,整個效率也很高,文本的用戶優化,融合你整個的語義去檢測，更好的檢測出敏感詞，讓大家的文案都可以更加的安全，軟體內的數據樣板都是根據大數據來的，整體都是非常的高效率的。

營銷推廣文案模板也很齊全，不需要充錢也沒有門檻限制,多少次都免費，非常方便,新手也可以理解。

有了這個，用戶在發布復制時，可以非常方便，直接拷貝在過濾欄，所有敏感詞、禁用詞都會按字識別，操作不難，可以點擊界面直接使用，方便易用。使用過它的抖音用戶不再需要擔心因為抖音敏感詞而被禁。識別優化的文案資源可以。

❺ pytho敏感詞過濾的准確性

DFA的演算法准確度高，應用最多。
replace就是最簡單的字元串替換，當一串字元串中有可能會出現的敏感詞時，我們直接使用相應的replace方法用*替換出敏感詞即可。正則表達式算是一個不錯的匹配方法了，日常的查詢中，幾乎都會用到正則表達式。
DFA的演算法，即DeterministicFiniteAutomaton演算法，翻譯成中文就是確定有窮自動機演算法。它的基本思想是基於狀態轉移來檢索敏感詞，只需要掃描一次待檢測文本，就能對所有敏感詞進行檢測。AC自動機需要有前置知識：Trie樹，簡單介紹：又稱前綴樹，字典樹，是用於快速處理字元串的問題，能做到快速查找到一些字元串上的信息。

❻ 大家說，2012年12月21日 世界末日會發生嗎

給你看下我看過的一篇博文~但還是不好判斷吧，僅供參考(*^__^*)

明年就是傳說中的2012了，據說在2012年12月21日那天，地球會毀滅，毀滅時的場景眾說紛紜。

所以我們暫且不論場景，先談談這個末日預言是從何而起的吧，據我了解，一共有兩種說法：

1. 這是一種流傳得最廣的說法，相傳在2002年，有個細心的西域男青年發現當年的第一場雪比以往時候來得更晚一些。然後這場雪通過蝴蝶效應被放大了1000W倍，導致2012年的地球再次進入了冰川時代，人類慘遭滅絕。

2.這是一種比較小眾的說法，流傳在一小撮腦殘之間。據說有一個叫瑪雅的文明孕育了一個叫瑪雅的民族，這個叫瑪雅的民族用一個叫瑪雅的歷法預言了2012年的世界末日。

我來給大家分別分析一下這兩種說法的可靠性：

關於第一個說法：據我深入而廣泛的調查發現，這個所謂的「細心的西域男青年」名叫刀郎，原名羅林，是個深受中老年朋友喜愛的西域歌手，他16歲時初中輟學，便走進了音樂行業。

從此紅得一發不可收拾，前幾年的時候，每當夜晚有北方的漢子喝醉了開始引吭高歌，多半是吼著的是刀郎的西域情歌。所以這個所謂的西域男青年並不具備任何與天文或者占卜有關的能力。而至於蝴蝶效應，多半用在消極的方面，比如某人做了一個關於天氣預報或者地震的模擬系統，結果兩月後發現實際情況跟自己的預測結果不一樣，他回頭思考原因，會發現當時忘了考慮一個因素或者某時突然多了一個微小的干擾因素，而這個微小的干擾原因經過蝴蝶效應的放大，使最終結果遠遠偏離了預期。還很少聽說有誰通過一點點端倪就可以利用蝴蝶效應對未來進行某些預測的。所以第一個說法顯然是不成立的。

關於第二個說法：這個預言提到了瑪雅文明，這個文明貌似很神秘，無所不能，上知天文下知地理，還貌似有許多與他們有關的驚人巧合。所以今天我來科普科普，讓大家對瑪雅文明有更多的了解。了解後你會發現，瑪雅文明跟我們華夏文明的距離根本不在一個數量級上。

瑪雅的天文

這可能是大家聽說得最多的地方，據說在天文這一點上，瑪雅人比古埃及和古支那人都要發達很多。其中的原因在於，瑪雅文明生長的地方叫做尤卡坦半島，在墨西哥那裡，該島地處「北緯15-20度之間，太陽的高度變化不大，季節更替不明顯，尤其是溫度差別幾乎不存在。如果只看溫度的話，尤卡坦半島常年適合種植莊稼，但每年8-10月是颶風季節，往往一場大颶風就毀掉了所有農作物。這個特點決定了瑪雅農民必須掌握年歷的計算方法，依靠天象來決定何時播種。」 也就是說，他們天文如果沒學好的話，就沒糧食吃，所以逼不得已地大力發展了天文。一個整天「仰望星空」的民族，難免會觀測點什麼金星火星水星的，所以出土的那些瑪雅文明有關金星之類的行星的歷法，也不足為奇了。

瑪雅人的歷法是一個月20天的，他們有兩套歷法，分別規定了農業活動與宗教活動。前者一年有18個月，20*18=360天，其中有5天瑪雅人認為不吉利所以不進行計算；後者一年有13個月，合計13*20=260天，據說是因為瑪雅人認為一個孕婦的孕期是260天。這兩個歷法每52年重復一次，由於瑪雅人一般活不過52年，所以這兩個歷法就可以記錄一個人的一生了。

而一旦要記錄稍長的時間，就會用到一個叫做「長紀年歷（Long Count Calendar）」的東西了。「這套歷法同樣每個月是20天，每年是360天（不算額外那5天）。此後每20年叫做一個Katun，也就是7200天。每400年叫做一個Baktun，也就是144000天。再往後就不乘以20了，而是乘以13，144000X13=1872000天，這個數除以365.25，就得出了5125.25這個數字。換句話說，瑪雅人認為世界每隔5125.25年就要重新洗牌一次。

當初發明這套演算法的瑪雅人隨便往前推了一個數字，宣布這就是瑪雅文明的起始日（此處Also表示有點不理解）。按照歷史學家的換算，這個日子就是公元前3114年的8月11日。這個日子加上5125.25年，就得出了2012年12月21日，這就是2012的由來。」

瑪雅的文字

研究瑪雅文字的時候學者們用到了「符號的計數」的方法，也就是統計符號的數量和出現頻率。「看過福爾摩斯的人肯定記得那個跳舞小人的故事，福老師找到的第一個突破口是認出了英文字母E，因為它出現的次數最多。然後是單詞Never，因為英文里只有3個5字母單詞的字母E分別位於第二和第四位置。但是瑪雅文字的破解可就沒這么簡單了，因為我們對它的造字規律一無所知，沒有任何純文字的線索。」

如果一種文字有20至30個字元，那麼它就是一種拼音文字，類似英文那樣的；如果一種文字有80至100個字元，那麼就是一種拼音文字，例如漢語拼音就有50個字元左右(ing,eng這些也包含的話)；如果一種文字有數百個字元，像我們漢字這樣的，就是表意文字了，一個字代表一個意思。

瑪雅的字元有800多個，相對於表意文字來說太少，相對於拼音文字來說太多。於是學者們一致認為瑪雅文字是一種混合體系，結合了文字元號和語音符號。也就是說，一個字既可能是音也可能是意。韓國和日本就是這么乾的。而且最奇怪的是，瑪雅的「音」文字很多重復，也就是一個音對應著多個字元，大多數情況下一個音可以找到好幾個甚至十幾個替換它的字元。這就有點現在的非主流的意思，比如「cao（操）」這個音，瑪雅人可以寫成cao，caO，cσΟ，cаΟ，cαΟ，сАΟ，cāo，cáo，caō。我可不是在說笑。

有些人會覺得奇怪，為什麼瑪雅人在發展過程中沒有人來簡化這些字？或是瑪雅政府也進行了敏感詞過濾，人們要逃避審查嗎？

字的復雜是因為文字在瑪雅文明中是貴族才能學習的事物，一般老百姓看待文字甚至還有些神聖的意味。通過文字來區別貴族與老百姓，使得兩者在智商和知識上產生巨大差異來穩定統治。同時貴族們利用習得的天文歷法進行腦力工作，指導平民們的耕作，換取優越生活。長久以來，他們就這樣相偎相依，安安穩穩地過著日子。

站在藝術的角度來看，瑪雅文字是很有意思的；而站在實用性的角度來說，瑪雅文字是低等的。

瑪雅的戰爭

瑪雅人所在的尤卡坦半島只有廣西這么大，卻大大小小建立著100多個國家。因為瑪雅人馴養潛力的野生動物（個中原因請參考《槍炮病菌與鋼鐵》，裡面有非常絕妙的解釋），也缺乏有馴化潛力的野生植物。瑪雅人養著狗和火雞，種著玉米、豆子和青南瓜。這些動物不能幫著打仗和馱運東西，這些植物也不方便攜帶。所以經常走幾步打一打，歇一歇再打一打，打來打去永遠都統一不了。

瑪雅人之間的戰爭也是所謂的「禮儀戰爭」，只有象徵性的打仗作用。出征時，只有貴族可以去打，農民必須留在地里耕田。貴族間表示勝利的方式就是俘虜對方的將領。之所以打這種仗，是因為大家都太窮了，如果像當年的支那人那樣動不動幾萬人打仗的話，他們早滅族了。

美洲有三大文明只說，地處墨西哥高原的阿茲泰克文明和地處南美印第安山脈的印加文明，以及夾在他們中間的瑪雅文明。除了瑪雅文明，這兩個文明在西班牙人侵略前都是國王獨裁製，所以西班牙人以來就抓他們國王，搞定他們兩個國家了。而對於瑪雅文明這樣的游擊隊文明，西班牙人只能慢慢地趕盡殺絕。

瑪雅的宗教

「瑪雅宗教是多神的，崇拜大量自然神，從太陽月亮到風雷雲雨都被視為天神，活人祭祀現象非常普遍，這是一個極度靠天吃飯的原始民族必然出現的結果。」同其他古代的宗教一樣，瑪雅宗教也喜歡祭祀。當瑪雅文字還未被翻譯的時候，瑪雅文字研究界的權威Thompson認為瑪雅人的文字記載都是些關於天文和歷法的內容，認為瑪雅人文明程度較高，熱愛和平。而當破譯工作向前進行後，才發現很多石碑上都記載了大量的祭祀活動。比如這幅石碑，畫的是一個貴婦先刺穿自己的舌頭，然後再用一根繩子穿過自己的舌頭，

接著用沾滿自己鮮血的紙在陶碗中燃燒，

接著在裊裊而起的煙霧構成了一條蛇的幻想，蛇口中浮現出了一位先祖的面容。

–

再比如這幅很出名的圖（以前我經常在所謂XXX未解之謎看到），畫的好像是一個瑪雅人在開飛機。

而其實原圖是豎著的，畫的是「Pakal死後重生的情形，他身下是地獄，身上長出來的是「生命樹」，瑪雅人認為地球上的所有生命都是「生命樹」從地下帶上來的。」

\\\\\\\\\\\\\\\\\\

關於瑪雅人的經濟農業之類的就沒有什麼好介紹了，這與筆者要討論的主題無關。

通過上面的介紹，大家應該都對刀郎和瑪雅文明有了個大概的了解了吧？

聰明的人用腦子一想就知道，一個初中沒畢業的唱歌小伙和一個尚未開化的愚昧民族，如何決定得了世界末日呢？

❼ 微軟小冰的工作原理。

微瘋客小編為你回答，

類似小冰這樣的產品說簡單也簡單，說復雜也復雜。單純從外面看你會覺得小冰與去年人人網上流行的小黃雞類似，但在技術實現上有本質的差異。
此類應用的大致流程都是：用戶輸入一段話（不一定只是單詞）->後端語義引擎對用戶輸入的語句進行語義解析->推斷用戶最可能的意圖->調用對應的知識庫、應用、計算引擎->返回結果給用戶。

1、最初級的實現方法：關鍵詞匹配
建一個關鍵詞詞庫，對用戶輸入的語句進行關鍵詞匹配，然後調用對應的知識庫。
此種方式入門門檻很低，基本上是個程序員都能實現，例如現在微信公眾平台的智能回復、諸多網站的敏感詞過濾就是此類。
但此種方式存在諸多問題，例如：
a、由於是關鍵詞匹配，如果用戶輸入的語句中出現多個關鍵詞，此時由於涉及關鍵詞權重（與知識庫的關鍵詞對比）等等問題，此時關鍵詞匹配的方法就不擅長了
b、不存在對用戶輸入語句語義的理解，導致會出現答非所問的現象。當然在產品上對回答不上的問題就採用賣萌的方式來規避掉。
c、基本上無自學習能力，規則只能完全由人工維護，且規則基本是固定死的。
d、性能、擴展性較差。還是上面的一句話中包含多個關鍵詞的例子，採用普通程序語言來做關鍵詞匹配，性能奇差。即便採用一些文本處理的演算法來做（例如Double-array trie tree），也很難滿足大規模場景需求。

2、稍微高級點的實現方法：基於搜索引擎、文本挖掘、自然語言處理（NLP）等技術來實現
相對於1的關鍵詞匹配，此種實現方法要解決的核心的問題可以大致理解為：根據一段短文本（例如用戶問的一句話）的語義，推測出用戶最可能的意圖，然後從海量知識庫內容中找出相似度最高的結果。
具體技術實現就不細說了。舉一個很粗糙的例子來簡單說一下此種實現方法處理的思路（不嚴謹，只是為了說明思路）。
假如用戶問：北京後天的溫度是多少度？
如果採用純搜索引擎的思路（基於文本挖掘、NLP的思路不盡相同，但可參考此思路），此時實際流程上分成幾步處理：
1、對輸入語句分詞，得到北京、後天、溫度3個關鍵詞。分詞時候利用了預先建好的行業詞庫，「北京」符合預先建好的城市庫、「後天」符合日期庫、「溫度」符合氣象庫
2、將上述分詞結果與規則庫按照一定演算法做匹配，得出匹配度最高的規則。假定在規則庫中有一條天氣的規則：城市庫+日期庫+氣象庫，從而大致可以推測用戶可能想問某個地方某天的天氣。
3、對語義做具體解析，知道城市是北京，日期是後天，要獲取的知識是天氣預報
4、調用第三方的天氣介面，例如中國天氣網-專業天氣預報、氣象服務門戶 的數據
5、將結果返回給用戶

以上例子其實很粗糙，實際上還有諸多問題沒提到：語義上下文、語義規則的優先順序等等。
例如用戶上一句問：北京後天的溫度是多少度？下一句問：後天的空氣質量呢？這里實際上還涉及語義上下文、用戶歷史喜好數據等等諸多問題。

此種處理方法存在的最大問題：規則庫還主要依賴於人工的建立，雖然有一定的學習能力，但自我學習能力還是較弱。可以藉助一些訓練演算法來完善規則，但效果並不是很好。而這也是目前流行的深度挖掘技術所擅長的。

3、當下時髦且高級的玩法：基於深度挖掘、大數據技術來實現
這是cornata、google now等後端的支撐技術，至於小冰，感覺應該是以2為主+部分領域知識的深度挖掘。

並非原創，轉自 hu。