應用場景 智能問答機器人火得不行，開始研究深度學習在NLP領域的應用已經有一段時間，最近在用深度學習模型直接進行QA系統的問答匹配。主流的還是CNN和LSTM，在網上沒有找到特別合適的可用的代碼，自己先寫了一個CNN的（theano），效果還行，跟論文中的結論是吻合的。目前已經應用到了我們的產品上。 原理 參看《Applying Deep Learning To Answer Selection: A Study And An Open Task》，文中比較了好幾種網絡結構，選擇了效果相對較好的其中一個來實現，網絡描述如下： Q&A共用一個網絡，網絡中包括HL，CNN，P+T和Cosine_Similarity，HL是一個g(W*X+b)的非線性變換，CNN就不說了，P是max_pooling，T是激活函數Tanh，最后的Cosine_Similarity表示將Q&A輸出的語義表示向量進行相似度計算。 詳細描述下從輸入到輸出的矩陣變換過程：

• Qp：[batch_size, sequence_len]，Qp是Q之前的一個表示（在上圖中沒有畫出）。所有句子需要截斷或padding到一個固定長度（因為后面的CNN一般是處理固定長度的矩陣），例如句子包含3個字ABC，我們選擇固定長度sequence_len為100，則需要將這個句子padding成ABC<a><a>…<a>(100個字)，其中的<a>就是添加的專門用于padding的無意義的符號。訓練時都是做mini-batch的，所以這里是一個batch_size行的矩陣，每行是一個句子。
• Q：[batch_size, sequence_len, embedding_size]。句子中的每個字都需要轉換成對應的字向量，字向量的維度大小是embedding_size，這樣Qp就從一個2維的矩陣變成了3維的Q
• HL層輸出：[batch_size, embedding_size, hl_size]。HL層：[embedding_size, hl_size]，Q中的每個句子會通過和HL層的點積進行變換，相當于將每個字的字向量從embedding_size大小變換到hl_size大小。
• CNN+P+T輸出：[batch_size, num_filters_total]。CNN的filter大小是[filter_size, hl_size]，列大小是hl_size，這個和字向量的大小是一樣的，所以對每個句子而言，每個filter出來的結果是一個列向量（而不是矩陣），列向量再取max-pooling就變成了一個數字，每個filter輸出一個數字，num_filters_total個filter出來的結果當然就是[num_filters_total]大小的向量，這樣就得到了一個句子的語義表示向量。T就是在輸出結果上加上Tanh激活函數。
• Cosine_Similarity：[batch_size]。最后的一層并不是通常的分類或者回歸的方法，而是采用了計算兩個向量（Q&A）夾角的方法，下面是網絡損失函數。，m是需要設定的參數margin，VQ、VA+、VA-分別是問題、正向答案、負向答案對應的語義表示向量。損失函數的意義就是：讓正向答案和問題之間的向量cosine值要大于負向答案和問題的向量cosine值，大多少，就是margin這個參數來定義的。cosine值越大，兩個向量越相近，所以通俗的說這個Loss就是要讓正向的答案和問題愈來愈相似，讓負向的答案和問題越來越不相似。
  

實現 代碼點擊這里，使用的數據是一份英文的insuranceQA，下面介紹代碼重點部分： 字向量。本文采用字向量的方法，沒有使用詞向量。使用字向量的目的主要是為了解決未登錄詞的問題，這樣在測試的時候就很少會遇到Unknown的字向量的問題了。而且字向量的效果也不一定比詞向量的效果差，還省去了分詞的各種麻煩。先用word2vec生成一份字向量，相當于我們在做pre-training了（之后測試了隨機初始化字向量的方法，效果差不多） 原理中的步驟2。這里沒有做HL層的變換，實際測試中，增加HL層有非常非常小的提升，所以在這里就省去了改步驟。 CNN可以設置多種大小的filter，最后各種filter的結果會拼接起來。 原理中的步驟4。這里執行卷積，max-pooling和Tanh激活。 生成的ouputs_1是一個python的list，使用concatenate將list的多個tensor拼接起來（list中的每個tensor表示一種大小的filter卷積的結果） 原理中的步驟5。計算問題、正向答案、負向答案的向量夾角 生成Loss損失函數和Accuracy。 核心的網絡構建代碼就是這些，其他的代碼都是訓練數據、驗證數據的讀入，以及theano構建訓練時的一些常規代碼。 如果需要增加HL層，可參照如下的代碼。Whl即是HL層的網絡，將input和Whl點積即可。 dropout的實現。 結果 使用上面的代碼，Test 1的Top-1 Accuracy可以達到61%-62%，和論文中的結論基本一致了，至于論文中提到的GESD、AESD等方法沒有再測試了，運行較慢，其他數據集也沒有再測試了。 下面是國外友人用一個叫keras的工具（封裝的theano和tensorflow）弄的類似代碼，Test 1的Top-1準確率在50%左右，比他這個要高 http://benjaminbolte.com/blog/2016/keras-language-modeling.html Test setTop-1 AccuracyMean Reciprocal Rank
Test 1 0.4933 0.6189
Test 2 0.4606 0.5968
Dev 0.4700 0.6088 另外，原始的insuranceQA需要進行一些處理才能在這個代碼上使用，具體參看github上的說明吧。 一些技巧

• 字向量和詞向量的效果相當。所以優先使用字向量，省去了分詞的麻煩，還能更好的避免未登錄詞的問題，何樂而不為。
• 字向量不是固定的，在訓練中會更新。
• Dropout的使用對最高的準確率沒有很大的影響，但是使用了Dropout的結果更穩定，準確率的波動會更小，所以建議還是要使用Dropout的。不過Dropout也不易過度使用，比如Dropout的keep_prob概率如果設置到0.25，則模型收斂得更慢，訓練時間長很多，效果也有可能會更差，設置會差很多。我這版代碼使用的keep_prob為0.5，同時保證準確率和訓練時間。另外，Dropout只應用到了max-pooling的結果上，其他地方沒有再使用了，過多的使用反而不好。
• 如何生成訓練集。每個訓練case需要一個問題+一個正向答案+一個負向答案，很明顯問題和正向答案都是有的，負向答案的生成方法就是隨機采樣，這樣就不需要涉及任何人工標注工作了，可以很方便的應用到大數據集上。
• HL層的效果不明顯，有很微量的提升。如果HL層的大小是200，字向量是100，則HL層相當于將字向量再放大一倍，這個感覺沒有多少信息可利用的，還不如直接將字向量設置成200，還省去了HL這一層的變換。
• margin的值一般都設置得比較小。這里用的是0.05
• 如果將Cosine_similarity這一層換成分類或者回歸，印象中效果是不如Cosine_similarity的（具體數據忘了）
• num_filters越大并不是效果越好，基本到了一定程度就很難提升了，反而會降低訓練速度。
• 同時也寫了tensorflow版本代碼，對比theano的，效果差不多。
• Adam和SGD兩種訓練方法比較，Adam訓練速度貌似會更快一些，效果基本也持平吧，沒有太細節的對比。不過同樣的網絡+SGD，theano好像訓練要更快一些。
• Loss和Accuracy是比較重要的監控參數。如果寫一個新的網絡的話，類似的指標是很有必要的，可以在每個迭代中評估網絡是否正在收斂。因為調試比較麻煩，所以通過這些參數能評估你的網絡寫對沒，參數設置是否正確。
• 網絡的參數還是比較重要的，如果一些參數設置不合理，很有可能結果千差萬別，記得最初用tensorflow實現的時候，應該是dropout設置得太小，導致效果很差，很久才找到原因。所以調參和微調網絡還是需要一定的技巧和經驗的，做這版代碼的時候就經歷了一段比較痛苦的調參過程，最開始還懷疑是網絡設計或是代碼有問題，最后總結應該就是參數沒設置好。
  

結語 如果關注這個東西的人多的話，后面還可以有tensorflow版本的QA CNN，以及LSTM的代碼奉上 Contact: jiangwen127@gmail.com weibo:碼壇奧沙利文
發表在 機器學習, 深度學習, 自然語言處理, 問答系統? ? ? ? | 留下評論

達觀數據搜索引擎的Query自動糾錯技術和架構詳解發表于 2016年04月27號 由 recommender
1 背景 如今，搜索引擎是人們的獲取信息最重要的方式之一，在搜索頁面小小的輸入框中，只需輸入幾個關鍵字，就能找到你感興趣問題的相關網頁。搜索巨頭Google，甚至已經使Google這個創造出來的單詞成為動詞，有問題Google一下就可以。在國內，百度也同樣成為一個動詞。除了通用搜索需求外，很多垂直細分領域的搜索需求也很旺盛，比如電商網站的產品搜索，文學網站的小說搜索等。面對這些需求，達觀數據(www.datagrand.com)作為國內提供中文云搜索服務的高科技公司，為合作伙伴提供高質量的搜索技術服務，并進行搜索服務的統計分析等功能。（達觀數據聯合創始人高翔） 搜索引擎系統最基本最核心的功能是信息檢索，找到含有關鍵字的網頁或文檔，然后按照一定排序將結果給出。在此基礎之上，搜索引擎能夠提供更多更復雜的功能來提升用戶體驗。對于一個成熟的搜索引擎系統，用戶看似簡單的搜索過程，需要在系統中經過多個環節，多個模塊協同工作，才能提供一個讓人滿意的搜索結果。其中拼寫糾錯（Error Correction，以下簡稱EC）是用戶比較容易感知的一個功能，比如百度的糾錯功能如下圖所示： 圖 1：百度糾錯功能示例 EC其實是屬于Query Rewrite（以下簡稱QR）模塊中的一個功能，QR模塊包括拼寫糾錯，同義改寫，關聯query等多個功能。QR模塊對于提升用戶體驗有著巨大的幫助，對于搜索質量不佳的query進行改寫后能返回更好的搜索結果。QR模塊內容較多，以下著重介紹EC功能。
繼續閱讀 →
發表在 自然語言處理? ? ? ? | 一條評論

非主流自然語言處理——遺忘算法系列（四）：改進TF-IDF權重公式發表于 2016年04月23號 由 老憨

一、前言
　　前文介紹了利用詞庫進行分詞，本文介紹詞庫的另一個應用：詞權重計算。

二、詞權重公式
　　1、公式的定義

　　　　定義如下公式，用以計算詞的權重：
　　　　
　　2、公式的由來

　　　　在前文中，使用如下公式作為分詞的依據：
　　　　

　　　　任給一個句子或文章，通過對最佳分詞方案所對應的公式進行變換，可以得到：
　　　　

　　　　按前面權重公式的定義，上面的公式可以理解為：一個句子出現的概率對數等于句子中各詞的權重之和。

　　　　公式兩邊同時取負號使權重是個正值。



三、與TF-IDF的關系
　　詞頻、逆文檔頻率（TF-IDF）在自然語言處理中，應用十分廣泛，也是提取關鍵詞的常用方法，公式如下：
　　

　　從形式上看，該公式與我們定義的權重公式很像，而且用途也近似，那么它們之間有沒有關系呢？

　　答案是肯定的。

　　我們知道，IDF是按文檔為單位統計的，無論文檔的長短，統一都按一篇計數，感覺這個統計的粒度還是比較粗的，有沒有辦法將文本的長短，這個明顯相關的因素也考慮進去呢，讓這個公式更加精細些？

　　答案也是肯定的。

　　文章是由詞鋪排而成，長短不同，所包含的詞的個數也就有多有少。

　　我們可以考慮在統計文檔個數時，為每個文檔引入包含多少個詞這樣一個權重，以區別長短不同的文檔，沿著這個思路，改寫一下IDF公式：
　　
　　我們用所有文檔中的詞做成詞庫，那么上式中：
　　
　　綜合上面的推導過程，我們知道，本文所定義的詞權重公式，本質上是tf-idf為長短文檔引入權重的加強版，而該公式的應用也極為簡單，只需要從詞庫中讀取該詞詞頻、詞庫總詞頻即可。

　　時間復雜度最快可達O（1）級，比如詞庫以Hash表存儲。

　　關于TF-IDF更完整的介紹及主流用法，建議參看阮一峰老師的博文《TF-IDF與余弦相似性的應用（一）：自動提取關鍵詞》。

四、公式應用
　　　　詞權重用途很廣，幾乎詞袋類算法中，都可以考慮使用。常見的應用有：

　　　　 1、關鍵詞抽取、自動標簽生成

　　　　 　　　作法都很簡單，分詞后排除停用詞，然后按權重值排序，取排在前面的若干個詞即可。

　　　　 2、文本摘要

　　　　 　　　完整的文本摘要功能實現很復雜也很困難，這里所指，僅是簡單應用：由前面推導過程中可知，句子的權重等于分詞結果各詞的權重之和，從而獲得句子的權重排序。

　　　　 3、相似度計算

　　　　 　　　相似度計算，我們將在下一篇文中單獨介紹。

五、演示程序
　　在演示程序顯示詞庫結果時，是按本文所介紹的權重公式排序的。

　　演示程序與詞庫生成的相同：

　　下載地址：遺忘算法（詞庫生成、分詞、詞權重）演示程序.rar

　　特別感謝：王斌老師指出，本文公式實質上是TF-ICF。
六、聯系方式：　　1、QQ：老憨 244589712
　　2、郵箱：gzdmcaoyc@163.com

發表在 自然語言處理? ? ? ? | 標簽為 TF-IDF, 自然語言處理, 遺忘算法? ? ? ? | 留下評論

非主流自然語言處理——遺忘算法系列（三）：分詞發表于 2016年04月23號 由 老憨

一、前言
　　前面介紹了詞庫的自動生成的方法，本文介紹如何利用前文所生成的詞庫進行分詞。

二、分詞的原理
　　分詞的原理，可以參看吳軍老師《數學之美》中的相關章節，這里摘取Google黑板報版本中的部分：

　　

　　從上文中，可以知道分詞的任務目標：給出一個句子S，找到一種分詞方案，使下面公式中的P（S）最大：

　　

　　不過，聯合概率求起來很困難，這種情況我們通常作馬爾可夫假設，以簡化問題，即：任意一個詞wi的出現概率只同它前面的詞 wi-1 有關。

　　關于這個問題，吳軍老師講的深入淺出，整段摘錄如下：
　　

　　另外，如果我們假設一個詞與其他詞都不相關，即相互獨立時，此時公式最簡，如下：
　　

　　這個假設分詞無關的公式，也是本文所介紹的分詞算法所使用的。

三、算法分析
　　問：假設分詞結果中各詞相互無關是否可行？

　　答：可行，前提是使用遺忘算法系列（二）中所述方法生成的詞庫，理由如下：

　　分析ICTCLAS廣受好評的分詞系統的免費版源碼，可以發現，在這套由張華平、劉群兩位博士所開發分詞系統的算法中假設了：分詞結果中詞只與其前面的一個詞有關。

　　回憶我們詞庫生成的過程可以知道，如果相鄰的兩個詞緊密相關，那么這兩個詞會連為一個粗粒度的詞被加入詞庫中，如：除“清華”、“大學”會是單獨的詞外，“清華大學”也會是一個詞，分詞過程中具體選用那種，則由它們的概率來決定。

　　也就是說，我們在生成詞庫的同時，已經隱含的完成了相關性訓練。

　　關于ICTCLAS源碼分析的文章，可以參看呂震宇博文：《天書般的ICTCLAS分詞系統代碼》。

　　問：如何實現分詞？

　　答：基于前文生成的詞庫，我們可以假設分詞結果相互無關，分詞過程就比較簡單，使用下面的步驟可以O(N)級時間，單遍掃描完成分詞：

　　逐字掃描句子，從詞庫中查出限定字長內，以該字結尾的所有詞，分別計算其中的詞與該詞之前各詞的概率乘積，取結果值最大的詞，分別緩存下當前字所在位置的最大概率積，以及對應的分詞結果。

　　重復上面的步驟，直到句子掃描完畢，最后一字位置所得到即為整句分詞結果。


　　3、算法特點
　　　　3.1、無監督學習；
　　　　3.2、O(N)級時間復雜度；
　　　　3.3、詞庫自維護，程序可無需人工參與的情況下，自行發現并添加新詞、調整詞頻、清理錯詞、移除生僻詞，保持詞典大小適當；
　　　　3.4、領域自適應：領域變化時，詞條、詞頻自適應的隨之調整；
　　　　3.5、支持多語種混合分詞。



四、演示程序下載
　　演示程序與詞庫生成的相同：

　　下載地址：遺忘算法（詞庫生成、分詞、詞權重）演示程序.rar

五、聯系方式：
　　1、QQ：老憨 244589712
　　2、郵箱：gzdmcaoyc@163.com

發表在 自然語言處理? ? ? ? | 標簽為 無監督分詞, 自然語言處理, 自適應詞典, 跨語種, 遺忘算法? ? ? ? | 13 條評論

非主流自然語言處理——遺忘算法系列（二）：大規模語料詞庫生成發表于 2016年04月23號 由 老憨
一、前言
　　本文介紹利用牛頓冷卻模擬遺忘降噪，從大規模文本中無監督生成詞庫的方法。



二、詞庫生成


　　　　算法分析，先來考慮以下幾個問題



　　　　問：目標是從文本中抽取詞語，是否可以考慮使用遺忘的方法呢？

　　　　答：可以，詞語具備以相對穩定周期重復再現的特征，所以可以考慮使用遺忘的方法。這意味著，我們只需要找一種適當的方法，將句子劃分成若干子串，這些子串即為“候選詞”。在遺忘的作用下，如果“候選詞”會周期性重現，那么它就會被保留在詞庫中，相反如果只是偶爾或隨機出現，則會逐漸被遺忘掉。



　　　　問：那用什么方法來把句子劃分成子串比較合適呢？

　　　　答：考察句中任意相鄰的兩個字，相鄰兩字有兩種可能：要么同屬于一個共同的詞，要么是兩個詞的邊界。我們都會有這樣一種感覺，屬于同一個詞的相鄰兩字的“關系”肯定比屬于不同詞的相鄰兩字的“關系”要強烈一些。

　　　　數學中并不缺少刻劃“關系”的模型，這里我們選擇公式簡單并且參數容易統計的一種：如果兩個字共現的概率大于它們隨機排列在一起的概率，那么我們認為這兩個字有關，反之則無關。

　　　　如果相鄰兩字無關，就可以將兩字中間斷開。逐字掃描句子，如果相鄰兩字滿足下面的公式，則將兩字斷開，如此可將句子切成若干子串，從而獲得“候選詞”集，判斷公式如下圖所示：

　　　　

　　　　公式中所需的參數可以通過統計獲得：遍歷一次語料，即可獲得公式中所需的“單字的頻數”、“相鄰兩字共現的頻數”，以及“所有單字的頻數總和”。



　　　　問：如何計算遺忘剩余量？

　　　　答：使用牛頓冷卻公式，各參數在遺忘算法中的含義，如下圖所示：



　　　　牛頓冷卻公式的詳情說明，可以參考阮一峰老師的博文《基于用戶投票的排名算法（四）：牛頓冷卻定律》。

　　　　

　　　　問：參數中時間是用現實時間嗎，遺忘系數取多少合適呢？

　　　　答：a、關于時間：

　　　　　　可以使用現實時間，遺忘的發生與現實同步。

　　　　　　也可以考慮用處理語料中對象的數量來代替，這樣僅當有數據處理時，才會發生遺忘。比如按處理的字數為計時單位，人閱讀的速度約每秒5至7個字，當然每個人的閱讀速度并不相同，這里的參數值要求并不需要特別嚴格。



　　　　　　b、遺忘系數可以參考艾賓浩斯曲線中的實驗值，如下圖（來自互聯網）

　　　　

　　　　　　我們取6天記憶剩余量約為25.4%這個值，按每秒閱讀7個字，將其代入牛頓冷卻公式可以求得遺忘系數：

　　　　



　　　　　　注意艾賓浩斯曲線中的每組數值代入公式，所得的系數并不相同，會對詞庫的最大有效容量產生影響。

二、該算法生成詞庫的特點
　　　　3.1、無監督學習

　　　　3.2、O(N)級時間復雜度

　　　　3.3、訓練、執行為同一過程，可無縫處理流式數據

　　　　3.4、未登錄詞、新詞、登錄詞沒有區別

　　　　3.5、領域自適應：領域變化時，詞條、詞頻自適應的隨之調整

　　　　3.6、算法中僅使用到頻數這一語言的共性特征，無需對任何字符做特別處理，因此原理上跨語種。

三、詞庫成熟度

　　由于每個詞都具備一個相對穩定的重現周期，不難證明，當訓練語料達到一定規模后，在遺忘的作用下，每個詞的詞頻在衰減和累加會達到平衡，也即衰減的速度與增加的速度基本一致。成熟的詞庫，詞頻的波動相對會比較小，利用這個特征，我們可以衡量詞庫的成熟程度。

四、源碼（C#）、演示程序下載

　　使用內附語料（在“可直接運行的演示程序”下可以找到）生成詞庫效果如下：
　　
　　下載地址：遺忘算法（詞庫生成、分詞、詞權重）演示程序.rar
五、聯系方式：

　　1、QQ：老憨 244589712
　　2、郵箱：gzdmcaoyc@163.com


發表在 自然語言處理? ? ? ? | 標簽為 未登錄詞發現, 牛頓冷卻公式, 自然語言處理, 詞庫生成, 遺忘算法? ? ? ? | 4 條評論

非主流自然語言處理——遺忘算法系列（一）：算法概述發表于 2016年04月19號 由 老憨
一、前言
這里“遺忘”不是筆誤，這個系列要講的“遺忘算法”，是以牛頓冷卻公式模擬遺忘為基礎、用于自然語言處理（NLP）的一類方法的統稱，而不是大名鼎鼎的“遺傳算法”！

在“遺忘”這條非主流自然語言處理路上，不知不覺已經摸索了三年有余，遺忘算法也算略成體系，雖然仍覺時機未到，還是決定先停一下，將腦中所積梳理成文，交由NLP的同好們點評交流。

二、遺忘算法原理
能夠從未知的事物中發現關聯、提煉規律才是真正智能的標志，而遺忘正是使智能生物具備這一能力的工具，也是適應變化的利器，“遺忘”這一頗具負能量特征的家伙是如何實現發現規律這么個神奇魔法的呢？

讓我們從巴甫洛夫的狗說起：狗聽到鈴聲就知道開飯了。

鈴聲和開飯之間并不存在必然的聯系，我們知道之所以狗會將兩者聯系在一起，是因為巴甫洛夫有意的將兩者一次次在狗那兒重復共現。所以，重復是建立關聯的必要條件。

我們還可以想像，狗在進食的時候聽到的聲音可能還有鳥叫聲、風吹樹葉的沙沙聲，為什么這些同樣具備重復特征聲音卻沒有和開飯建立關系呢？

細分辨我們不難想到：鈴聲和開飯之間不僅重復共現，而且這種重復共現還具備一個相對穩定的周期，而其他的那些聲音和開飯的共現則是隨機的。

那么遺忘又在其中如何起作用的呢？

1、所有事物一視同仁的按相同的規律進行遺忘； 2、偶爾或隨機出現的事物因此會隨時間而逐漸淡忘； 3、而具有相對穩定周期重復再現的事物，雖然也按同樣的規律遺忘，但由于周期性的得到補充，從而可以動態的保留在記憶中。

在自然語言處理中，很多對象比如：詞、詞與詞的關聯、模板等，都具備按相對穩定重現的特征，因此非常適用遺忘來處理。

三、牛頓冷卻公式
那么，我們用什么來模擬遺忘呢？

提到遺忘，很自然的會想到艾賓浩斯遺忘曲線，如果這條曲線有個函數形式，那么無疑是模擬遺忘的最佳建模選擇。遺憾的是它只是一組離散的實驗數據，但至少讓我們知道，遺忘是呈指數衰減的。

另外有一個事實，有的人記性好些，有的人記性則差些，不同人之間的遺忘曲線是不同的，但這并不會從本質上影響不同人對事物的認知，也就是說，如果存在一個遺忘函數，它首先是指數形式的，其次在實用過程中，該函數的系數并不那么重要。

這提醒我們，可以嘗試用一些指數形式的函數來代替遺忘曲線，然后用實踐去檢驗，如果能滿足工程實用就很好，這樣的函數公式并不難找，比如：退火算法、半衰期公式等。

有次在阮一峰老師的博客上看關于帖子熱度排行的算法時，其中一種方法使用的是牛頓冷卻定律，遺忘與冷卻有著相似的過程、簡潔優美的函數形式、而且參數只與時間相關，這些都讓我本能想到，它就是我想要的“遺忘公式”。

在實踐檢驗中，牛頓冷卻公式，確實有效好用，當然，不排除有其他更佳公式。

四、已經實現的功能
如果把自然語言處理比作從礦砂中淘金子，那么業界主流算法的方向是從礦砂中將金砂挑出來，而遺忘算法的方向則是將砂石篩出去，雖然殊途但同歸，所處理的任務也都是主流中所常見。

本系列文章將逐一講解遺忘算法如何以O（N）級算法性能實現：

1、大規模語料詞庫生成
　　　　1.1、跨語種，算法語種無關，比如：中日韓、少數民族等語種均可支持
　　　　1.2、未登錄詞發現（只要符合按相對穩定周期性重現的詞匯都會被收錄）
　　　　1.3、領域自適應，切換不同領域的訓練文本時，詞條、詞頻自行調整
　　　　1.4、詞典成熟度：可以知道當前語料訓練出的詞典的成熟程度

2、分詞（基于上述詞庫技術）
　　　　2.1、成長性分詞：用的越多，切的越準
　　　　2.2、詞典自維護：切詞的同時動態維護詞庫的詞條、詞頻、登錄新詞
　　　　2.2、領域自適應、跨語種（繼承自詞庫特性）

3、詞權值計算
　　　　3.1、關鍵詞提取、自動標簽
　　　　3.2、文章摘要
　　　　3.3、長、短文本相似度計算
　　　　3.4、主題詞集

五、聯系方式：
1、QQ：老憨 244589712

2、郵箱：gzdmcaoyc@163.com





發表在 自然語言處理? ? ? ? | 標簽為 牛頓冷卻公式, 自然語言處理, 遺忘算法? ? ? ? | 留下評論

達觀數據對于大規模消息數據處理的系統架構發表于 2015年12月2號 由 recommender
達觀數據是為企業提供大數據處理、個性化推薦系統服務的知名公司，在應對海量數據處理時，積累了大量實戰經驗。其中達觀數據在面對大量的數據交互和消息處理時，使用了稱為DPIO的設計思路進行快速、穩定、可靠的消息數據傳遞機制，本文分享了達觀數據在應對大規模消息數據處理時所開發的通訊中間件DPIO的設計思路和處理經驗（達觀數據架構師 桂洪冠） 一、數據通訊進程模型 在設計達觀數據的消息數據處理機制時，首先充分借鑒了ZeroMQ和ProxyIO的設計思想。ZeroMQ提供了一種底層的網絡通訊框架，提供了基本的RoundRobin負載均衡算法，性能優越，而ProxyIO是雅虎的網絡通訊中間件，承載了雅虎內部大量計算節點間的實時消息處理。但是ZeroMQ沒有實現基于節點健康狀態的最快響應算法，并且ZeroMQ和ProxyIO對節點的狀態管理，連接管理，負載均衡調度等也需要各應用自己來實現。 達觀科技在借鑒兩種設計思路的基礎上，從進程模型、服務架構、線程模型、通訊協議、負載均衡、雪崩處理、連接管理、消息流程、狀態監控等各方面進行了開拓，開發了DPIO（達觀ProxyIO的簡寫，下文統稱DPIO），確保系統高性能處理相關數據。 在DPIO的整個通訊框架體系中，采用集中管理、統一監控策略管理節點提供服務，節點間直接進行交互，并不依賴統一的管理節點（桂洪冠）。幾種節點間通過http或者tcp協議進行消息傳遞、配置更新、狀態跟蹤等通訊行為。集群將不同應用的服務抽象成組的概念，相同應用的服務啟動時加入的相同的組。每個通訊組有兩種端點client和server。應用啟動時通過配置決定自己是client端點還是server端點，在一個組內，每個應用只能有一個身份；不同組沒要求。

• 監控節點，顧名思義即提供系統監控服務的，用來給系統管理員查看集群中節點的服務狀態及負載情況，系統對監控節點并無實時性及穩定性要求，在本模型中是單點系統。
• 在上圖的架構中把管理節點設計成雙master結構，參考zookeeper集群管理思路，多個master通過一定算法分別服務于集群中一部分節點，相對于另外的服務節點則為備份管理節點，他們通過內部通訊同步數據，每個管理節點都有一個web服務為監控節點提供服務節點的狀態數據。
• 服務節點即是下文要談的代理服務，根據服務對象不同分為應用端代理和服務端代理。集群中的服務節點根據提供服務的不同分為多個組，每個代理啟動都需要注冊到相應的組中，然后提供服務。
  

二、DPIO消息傳遞邏輯架構 DPIO服務節點內/間的通訊及消息傳遞模型見下圖：

• clientHost和serverHost間使用socketapi進行tcp通訊，相同主機內部的多個進程間使用共享內存傳遞消息內容，client和clientproxy、server和serverproxy之間通過domain socket進行事件通知；在socket連接的一方收到對端的事件通知后，從共享內存中獲取消息內容。
• clientproxy/serverproxy啟動時綁定到host的一個端口響應應用api的連接，在連接到來時將該api對應的共享內存初始化，將偏移地址告訴給應用。clientproxy和serverproxy中分別維護了一個到應用api的連接句柄隊列，并通過io復用技術監聽這些連接上的讀寫事件。
• serverproxy在啟動時通過socket綁定到服務器的一個端口，并以server身份注冊到一個group監聽該端口的連接事件，當事件到達時回調注冊的事件處理函數響應事件。
• 在serverproxy內部通過不同的thread分別管理從本地應用建立的連接和從clientproxy建立的連接。thread的個數在啟動proxy時由用戶指定，默認是分別1個。每個clientproxy啟動時會以client身份注冊到一個group，并建立到同組的所有serverproxy的連接，clientproxy內部包含了連接的自管理能力及failover的處理(將在下面連接管理部分描述)。 DPIO實現了負載均衡，路由選擇和透明代理的功能。
  

三、線程模型 DPIO的線程模型： App epoll thread檢測從api來的請求信息，并將請求信息轉發到待處理隊列中。從已處理隊列中獲取應答包，并將處理結果轉發給api Io epoll thread檢測從遠端的proxy來的可寫事件，并將請求包轉發到遠端的proxy。檢測從遠端的proxy的可讀事件，并將應答包放在已處理隊列中 Monitor thread檢測DPIO的工作狀態請求，將DPIO的工作狀態返回。并將決定Io epoll thread和app epoll thread的負載均衡（桂洪冠）。 四、通信協議

• Api與DPIO通信協議
  

• 共享內存存儲消息格式
  

字段	含義	長度
protocol len	協議包的總長度	4bytes
protocol head len	協議頭的長度	1byte
Version_protocol_id	協議的版本號和協議號	1byte
Flag	消息標志，標志路由模式，是否記錄來源地址,有二級路由，所以這個字段一定要Eg，末位表示要記錄src，倒數第二位表示按roundrobin路由，倒數第3位表示按消息頭路由，xxx	1byte
Proxy	來源/目的 proxy	2bytes
Api	來源/目的 api	2bytes
ApiTtl	協議包的發送時間	2Bytes
ClientTtl	消息存活的時間，后面添加，增加路由策略，選擇app_server	2Bytes
ClientProcessTime	客戶端處理所用時間	2Bytes
ServerTtl	消息存活的時間，后面添加，增加路由策略，選擇app_client	2Bytes
timeout	協議包的超時時間	2 byte
Sid	消息序列號	4bytes
protocol body len	Body長度	4bytes
protocol body	消息體	Size

• 請求協議包
  

字段	含義	長度
protocol head len	協議頭的長度	1byte
Version_protocol_id	協議的版本號和協議號	1byte
Flag	消息標志，標志路由模式，是否記錄來源地址,有二級路由，所以這個字段一定要Eg，末位表示要記錄src，倒數第二位表示按roundrobin路由，倒數第3位表示按消息頭路由，xxx	1byte
ApiTtl	協議包的發送時間	2bytes
Timeout	協議包的超時時間	2bytes
Api	來源/目的 api	2bytes
Sid	消息序列號	4byte
Begin_offset	協議包的起始偏移	4bytes
len	協議包長度	4bytes

• 響應協議包
  

字段	含義	長度
protocol head len	協議頭的長度	1byte
Version_protocol_id	協議的版本號和協議號	1byte
Flag	消息標志，標志路由模式，是否記錄來源地址,有二級路由，所以這個字段一定要Eg，末位表示要記錄src，倒數第二位表示按roundrobin路由，倒數第3位表示按消息頭路由，xxx	1byte
Result	處理結果	1byte
sid	消息序列號	4bytes
begin_offset	協議包的起始偏移	4bytes
len	協議包長度	4bytes

• Proxy與監控中心的監控信息
  

• 請求協議包
  

字段	含義	長度
protocol len	協議包的總長度	4bytes
protocol head len	協議頭的長度	4bytes
Version	協議的版本號	4bytes
protocol id	協議的協議號	4bytess
status_version	當前狀態版本	4bytes
Proxy_identify_len	該proxy標識長度	4bytess
Proxy_identify	該proxy 標識	4bytes
protocol body	消息體	Size

• 應答包
  

字段	含義	長度
protocol len	協議包的總長度	4bytes
protocol head len	協議頭的長度	4bytes
Version	協議的版本號	4bytes
protocol id	協議的協議號	4bytess
protocol body len	Body長度	4bytes
protocol body	消息體	Size

五、負載均衡 DPIO的負載均衡基于最快響應法 DPIO將所有的統計信息更新到監控中心，監控中心通過處理所有的節點的狀態信息，統一負責負載均衡。 DPIO從監控中心獲取所有連接的負載均衡策略。每個連接知道只需知道自己的處理能力。 以上圖為例，有三個proxy server處理程序。處理能力分別為50、30、20，一次epoll過程能夠同時探測多個連接的可寫事件。 假設：三個proxy server的屬于同一epoll thread，且三個proxy server假設都處理能力無限大。 限制：如果剛開始時待處理隊列的數據包個數為100個，多次發送輪回后proxy server A≥proxy server B≥proxy server C， 每個發送的最多發送協議包數為待處理隊列協議包個數 * 該連接所占權重 六、雪崩處理 大型在線服務，特別是對于時延敏感的服務，當系統外部請求超過系統服務能力，而沒有適當的過載保護措施時，當系統累計的超時請求達到一定規模，將可能導致系統緩沖區隊列溢出，后端服務資源耗盡，最終像雪崩一樣形成惡性循環。這時系統處理的每個請求都因為超時而無效，系統對外呈現的服務能力為0，且這種情況下不能自動恢復。 我們的解決策略是對協議包進行生命周期管理，現在協議包進出待處理隊列和已處理隊列時進行超時檢測和超時處理（超時則丟棄）。 proxy client： 當app epoll thread將協議包放入待處理隊列時，會將該協議包的發送時間、該協議包的超時時間，當前時間戳來判斷該協議包是否已經超時。 當app epoll thread將協議包從已處理隊列中移除時，會將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 當Io epoll thread將協議包從待處理隊列中移除時，會將該協議包的發送時間、該協議包的超時時間，當前時間戳，該連接的協議包的平均處理時間移除。 當io epoll thread將協議包放入已處理隊列時，會將將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 proxy server： 當App epoll thread將協議包從待處理隊列中移除時，會將該協議包在客戶端的處理時間、該協議包的超時時間、該協議包的proxy server接收時間戳、當前時間戳來判斷該協議包是否已超時。 當app epoll thread將協議包放入已處理隊列時，會將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 當io epoll thread將協議包從已處理隊列中移除時，會將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 當io epoll thread將協議包放入待處理隊列時，會將該協議包的發送時間、該協議包的超時時間來判斷該協議包是否已超時。 七、連接管理 紅黑樹： 紅黑樹：保存所有連接的最近的讀/寫時間戳。 當epoll_wait時，首先從紅黑樹中獲取oldest的時間戳，并將當前時間戳與oldest時間戳的時間差作為epoll_wait的超時時間，當連接中有可讀/寫事件發送時，首先從紅黑樹中刪除該節點，當可讀/寫事件處理完畢后，再將節點插入到紅黑樹中，當處理完所有連接的可讀/寫事件時，再從紅黑樹中依次從移除時間戳小于當前時間戳的連接，并觸發該連接的timeout事件。 八、消息處理流程

• apiclient通過調用api的接口，將消息傳給
• api接受消息體，從共享內存中申請內存，填寫消息頭size（協議總長度）、Offset （協議版本號和協議號）、Headsize （協議頭的總長度）、flag(路由策略)，ApiTtl （協議包的發送時間）、timeout （協議包的超時時間）、sid(序列號)，size(消息體長度)字段，封裝成協議包，將協議包寫入共享內存。
• api通過socket發送請求給proxy。
• app epoll thread通過檢測api的可讀事件，接受請求。通過解析請求內容，獲取請求協議包所在的共享內存的偏移、請求協議包的長度和api連接index加入到處理隊列。
• proxy client的io epoll thread通過檢測對端DPIO連接的可寫事件，從發送隊列中獲取請求包，將api的index加入到協議包的api index字段。
• proxy client的io epoll thread從共享內存中讀取協議包，釋放由請求包中所標識的內存空間。
• proxy server的io epoll thread通過檢測對端DPIO的可讀事件，接受請求。
• proxy server的io epoll thread從共享內存中申請空間，將proxy的index加入到協議包的proxy index字段。將請求內存寫入到申請的空間中。
• proxy server的io epoll thread 將協議包在共享內存的偏移和協議包的長度加入的待處理隊列中。
• app epoll thread從待處理隊列中獲取請求包，將協議包轉發給相應的api進行處理。
• api通過檢測DPIO的可讀事件，解析請求內容。
• api通過解析請求內容，獲取請求協議包在共享內存中的偏移和請求協議包的長度。從共享內存中讀取請求內容，并釋放相應空間。
• api將請求協議包返回給應用層進行處理。
• 應用層將應答包傳給api。
• Api從共享內存中申請空間，將應答包寫入到共享內存中。
• Api將應答包在共享內存中的偏移和應答包的大小寫入到共享內存中。
• App epoll thread通過檢測可讀事件，將應答包寫入到已處理隊列中。
• proxy server的Io epoll thread通過檢測對端的DPIO的可寫事件，將已處理隊列中獲取應答包。
• proxy server的Io epoll thread從共享內存中讀取應答包。
• Proxy client的Io epoll thread檢測可讀事件，讀取應答包。
• Proxy client的Io epoll thread通過解析應答包，從共享內存中申請空間，將應答包寫入到申請的內存中。
• Proxy client的Io epoll thread將應答包移入到已處理隊列。
• App epoll thread通過檢測api的可寫事件，將已處理隊列中獲取應答包。
• App epoll thread發送應答包。
• Api通過檢測可讀事件，獲取應答包，通過解析應到包，獲取應答包在共享內存中的偏移和應到的大小，從共享內存中讀取應到包。
• Api將應答包返回給應用端。(桂洪冠 陳運文)。
  

九、狀態監控 連接池中存在：當前可用連接個數 連接池中再分別獲取每個連接的狀態 每個可用連接分別維護以下信息： 連接處理的數據包個數、連接send失敗次數、連接協議包的平均處理時間。 連接的連接狀態(當重連失敗達到一定次數時，定義為連接失敗)。 連接的重連次數、連接的超時次數。 當監控線程accept到client的連接時，解析請求內容，然后調用連接池對象的statistics方法，連接池對象首先寫入自己的統計信息，然后分別調用每個連接的statistics方法，每個連接分別填寫自己的統計信息 本文小結 大規模消息傳遞會遇到很多可靠性、穩定性的問題，DPIO是達觀在處理大數據通訊時的一些經驗，和感興趣的朋友們分享，期待與大家不斷交流與合作
發表在 數據挖掘? ? ? ? | 標簽為 數據處理, 數據通訊? ? ? ? | 留下評論

在微信公眾號里使用LaTeX數學公式發表于 2015年11月17號 由 52nlp
因為有同學在微信后臺咨詢這個問題，所以這里簡單記錄一下，其實自己之前也摸索了一些方法，不是太完美，目前所使用的這個方法算是折中后比較好的。 這段時間在鼓搗“NLPJob”這個公眾號，特別是微信公眾號支持“原創聲明”后，就很樂意將52nlp上積攢的一些文章搬上去，但是逐漸會遇到一些數學公式的問題。目前在52nlp上用的是mathjax完美支持LaTeX數學公式展現，但是微信公眾號的編輯器沒有這個支持，另外mathjax支持的公式形式不是圖片形式，所以不能直接將文章拷貝上去，但是如果是數學公式圖片，微信編輯器可以直接拷貝，所以最直接的想法就是將mathjax支持的LaTeX公式轉換為公式圖片保存在文章中，然后再全文拷貝到微信公眾號編輯器中。 其實在mathjax之前，網頁上的很多數學公式都是用這種折中的方式，包括很多wordpress數學公式插件，當年我也因為52nlp上的公式問題還自己動手寫了一個小的wordpress插件，但是當mathjax出現之后，之前的方案就顯得很一般了。所以就開始嘗試找一下支持img緩存的LaTeX公式插件，不過多數都不滿意或者有瑕疵，甚至自己又開始動手修改代碼，然后blablabla….，最終發現 quicklatex這個神器和它的wordpress插件QuickLaTeX，幾乎完美支持和兼容Mathjax所支持的LaTeX數學公式。方法很簡單，只要在wordpress中安裝quicklatex，然后在文章的開頭添加一個：[latexpage] ，然后文章中所有的latext公式都會轉換為圖片形式，類似昨天發出的rickjin的這篇文章：LDA數學八卦：神奇的Gamma函數(1)。當然需要先在wordpress中完成編輯轉換，再全文拷貝到微信公眾號中，微信會自動的將這些圖片上傳到它自己的圖片服務器上。不過依然希望微信公眾號編輯器能早日支持LaTeX公式編輯甚至Mathjax。
發表在 隨筆? ? ? ? | 標簽為 latex公式, latex數學公式, MathJax, 微信, 微信latex, 微信公眾號, 微信公眾號數學公式編輯器, 微信公式編輯器, 微信數學公式? ? ? ? | 2 條評論

斯坦福大學深度學習與自然語言處理第四講：詞窗口分類和神經網絡發表于 2015年09月14號 由 52nlp
斯坦福大學在三月份開設了一門“深度學習與自然語言處理”的課程：CS224d: Deep Learning for Natural Language Processing，授課老師是青年才俊 Richard Socher，以下為相關的課程筆記。 第四講：詞窗口分類和神經網絡（Word Window Classification and Neural Networks） 推薦閱讀材料：

• [UFLDL tutorial]
• [Learning Representations by Backpropogating Errors]
• 第四講Slides [slides]
• 第四講視頻 [video]
  

以下是第四講的相關筆記，主要參考自課程的slides，視頻和其他相關資料。
繼續閱讀 →
發表在 機器學習, 深度學習, 自然語言處理? ? ? ? | 標簽為 Deep Learning, Deep Learning公開課, Deep NLP, DL, NER, Richard Socher, softmax, word vectors, word2vec, wordnet, 二元邏輯回歸, 人名識別, 公開課, 分類, 分類器, 前饋網絡記錄, 反向傳播算法, 命名實體識別, 回歸, 地名識別, 斯坦福大學, 機器學習, 梯度下降, 深度學習, 深度學習與自然語言處理, 深度學習技術, 深度學習模型, 神經元, 神經網絡, 窗口向量, 窗口向量分類, 自然語義處理, 自然語言處理, 詞向量, 詞嵌入, 語義詞典, 邏輯回歸, 隨機梯度下降? ? ? ? | 3 條評論

出門問問宣布完成由Google投資的C輪融資，累計融資7500萬美金發表于 2015年09月2號 由 52nlp
注：出門問問是我們的老朋友，創始人李志飛也是NLP和機器翻譯領域的大牛，今天出門問問拿到了Google的C輪融資，志飛兄第一時間和我分享了這條新聞，太牛了。 人工智能創業公司出門問問（Mobvoi），于近日完成了由Google投資的C輪融資，累計融資7500萬美金。現有投資方包括紅杉資本、真格基金，SIG海納亞洲、圓美光電、及歌爾聲學。此輪投資Google并不控股，出門問問團隊依舊有絕對控制權。 此次由Google投資的C輪融資，能夠保證出門問問在人工智能領域長期持續深耕，專注核心技術上的進一步研發，在可穿戴、車載以及機器人領域拓展新的人機交互產品形態，更深入地完善用戶體驗，在吸引全球頂尖技術與商務人才上更具優勢。對于海外市場的擴展，此次融資也將發揮非常重要的作用。 Google 企業發展部副總裁Don Harrison 說到選擇投資出門問問的原因：“出門問問研發了非常獨特自成體系的語音識別與自然語言處理技術。我們被他們的創新科技與發展潛力打動，所以我們很迅速地決定用投資的方式幫助他們在未來快速成長。” 紅杉資本全球執行合伙人沈南鵬評價：“出門問問一直處于高速的不斷創新過程中，從移動app到硬件產品到語音搜索平臺，不同形式的產品背后是團隊長期以來形成的強大技術核心，獲得Google的投資是對這種中國原創能力的最好肯定。我很高興Google這樣的巨頭看好出門問問，并和我們一起投入到這支高速創新的團隊中。” 真格基金創始人徐小平說：“我第一次遇見谷歌科學家李志飛博士，是三年前。那時候，他的語音搜索創業計劃，真是一個“異想天開”的夢。志飛相信自己的夢，相信自己的技術，相信市場對這個技術產品的需求，歷經萬難，終于“搜索”到了屬于他自己的那片天空。志飛的創業歷程，是又一個中國好故事，會激勵更多人追求并實現自己的好夢。” 志同道合是此次融資達成的最重要的原因。扎實做技術和產品，運用科技的力量改變人們的日常生活，是出門問問一直篤信的價值觀。 出門問問CEO 李志飛表示：“引入Google的投資，不僅意味Google對于我們技術的認可，更是源于雙方持有共同的價值觀，通過對人工智能技術的極致追求，打造毫不妥協的用戶體驗。” 與Google相似，出門問問也是信仰“工程師文化”的團隊，強大的研發團隊由Google前科學家、人工智能專家領銜，團隊成員來自哈佛、MIT、斯坦福、劍橋、清華等名校名企。 此次融資是中國人工智能創業公司首次獲得像Google這樣的國際技術巨頭的投資與認可。這在某種程度上說明，在人工智能領域，中國的創業公司不容小覷。
繼續閱讀 → 應用場景 智能問答機器人火得不行，開始研究深度學習在NLP領域的應用已經有一段時間，最近在用深度學習模型直接進行QA系統的問答匹配。主流的還是CNN和LSTM，在網上沒有找到特別合適的可用的代碼，自己先寫了一個CNN的（theano），效果還行，跟論文中的結論是吻合的。目前已經應用到了我們的產品上。 原理 參看《Applying Deep Learning To Answer Selection: A Study And An Open Task》，文中比較了好幾種網絡結構，選擇了效果相對較好的其中一個來實現，網絡描述如下： Q&A共用一個網絡，網絡中包括HL，CNN，P+T和Cosine_Similarity，HL是一個g(W*X+b)的非線性變換，CNN就不說了，P是max_pooling，T是激活函數Tanh，最后的Cosine_Similarity表示將Q&A輸出的語義表示向量進行相似度計算。 詳細描述下從輸入到輸出的矩陣變換過程：

• Qp：[batch_size, sequence_len]，Qp是Q之前的一個表示（在上圖中沒有畫出）。所有句子需要截斷或padding到一個固定長度（因為后面的CNN一般是處理固定長度的矩陣），例如句子包含3個字ABC，我們選擇固定長度sequence_len為100，則需要將這個句子padding成ABC<a><a>…<a>(100個字)，其中的<a>就是添加的專門用于padding的無意義的符號。訓練時都是做mini-batch的，所以這里是一個batch_size行的矩陣，每行是一個句子。
• Q：[batch_size, sequence_len, embedding_size]。句子中的每個字都需要轉換成對應的字向量，字向量的維度大小是embedding_size，這樣Qp就從一個2維的矩陣變成了3維的Q
• HL層輸出：[batch_size, embedding_size, hl_size]。HL層：[embedding_size, hl_size]，Q中的每個句子會通過和HL層的點積進行變換，相當于將每個字的字向量從embedding_size大小變換到hl_size大小。
• CNN+P+T輸出：[batch_size, num_filters_total]。CNN的filter大小是[filter_size, hl_size]，列大小是hl_size，這個和字向量的大小是一樣的，所以對每個句子而言，每個filter出來的結果是一個列向量（而不是矩陣），列向量再取max-pooling就變成了一個數字，每個filter輸出一個數字，num_filters_total個filter出來的結果當然就是[num_filters_total]大小的向量，這樣就得到了一個句子的語義表示向量。T就是在輸出結果上加上Tanh激活函數。
• Cosine_Similarity：[batch_size]。最后的一層并不是通常的分類或者回歸的方法，而是采用了計算兩個向量（Q&A）夾角的方法，下面是網絡損失函數。，m是需要設定的參數margin，VQ、VA+、VA-分別是問題、正向答案、負向答案對應的語義表示向量。損失函數的意義就是：讓正向答案和問題之間的向量cosine值要大于負向答案和問題的向量cosine值，大多少，就是margin這個參數來定義的。cosine值越大，兩個向量越相近，所以通俗的說這個Loss就是要讓正向的答案和問題愈來愈相似，讓負向的答案和問題越來越不相似。
  

實現 代碼點擊這里，使用的數據是一份英文的insuranceQA，下面介紹代碼重點部分： 字向量。本文采用字向量的方法，沒有使用詞向量。使用字向量的目的主要是為了解決未登錄詞的問題，這樣在測試的時候就很少會遇到Unknown的字向量的問題了。而且字向量的效果也不一定比詞向量的效果差，還省去了分詞的各種麻煩。先用word2vec生成一份字向量，相當于我們在做pre-training了（之后測試了隨機初始化字向量的方法，效果差不多） 原理中的步驟2。這里沒有做HL層的變換，實際測試中，增加HL層有非常非常小的提升，所以在這里就省去了改步驟。 CNN可以設置多種大小的filter，最后各種filter的結果會拼接起來。 原理中的步驟4。這里執行卷積，max-pooling和Tanh激活。 生成的ouputs_1是一個python的list，使用concatenate將list的多個tensor拼接起來（list中的每個tensor表示一種大小的filter卷積的結果） 原理中的步驟5。計算問題、正向答案、負向答案的向量夾角 生成Loss損失函數和Accuracy。 核心的網絡構建代碼就是這些，其他的代碼都是訓練數據、驗證數據的讀入，以及theano構建訓練時的一些常規代碼。 如果需要增加HL層，可參照如下的代碼。Whl即是HL層的網絡，將input和Whl點積即可。 dropout的實現。 結果 使用上面的代碼，Test 1的Top-1 Accuracy可以達到61%-62%，和論文中的結論基本一致了，至于論文中提到的GESD、AESD等方法沒有再測試了，運行較慢，其他數據集也沒有再測試了。 下面是國外友人用一個叫keras的工具（封裝的theano和tensorflow）弄的類似代碼，Test 1的Top-1準確率在50%左右，比他這個要高 http://benjaminbolte.com/blog/2016/keras-language-modeling.html Test setTop-1 AccuracyMean Reciprocal Rank
Test 1 0.4933 0.6189
Test 2 0.4606 0.5968
Dev 0.4700 0.6088 另外，原始的insuranceQA需要進行一些處理才能在這個代碼上使用，具體參看github上的說明吧。 一些技巧

• 字向量和詞向量的效果相當。所以優先使用字向量，省去了分詞的麻煩，還能更好的避免未登錄詞的問題，何樂而不為。
• 字向量不是固定的，在訓練中會更新。
• Dropout的使用對最高的準確率沒有很大的影響，但是使用了Dropout的結果更穩定，準確率的波動會更小，所以建議還是要使用Dropout的。不過Dropout也不易過度使用，比如Dropout的keep_prob概率如果設置到0.25，則模型收斂得更慢，訓練時間長很多，效果也有可能會更差，設置會差很多。我這版代碼使用的keep_prob為0.5，同時保證準確率和訓練時間。另外，Dropout只應用到了max-pooling的結果上，其他地方沒有再使用了，過多的使用反而不好。
• 如何生成訓練集。每個訓練case需要一個問題+一個正向答案+一個負向答案，很明顯問題和正向答案都是有的，負向答案的生成方法就是隨機采樣，這樣就不需要涉及任何人工標注工作了，可以很方便的應用到大數據集上。
• HL層的效果不明顯，有很微量的提升。如果HL層的大小是200，字向量是100，則HL層相當于將字向量再放大一倍，這個感覺沒有多少信息可利用的，還不如直接將字向量設置成200，還省去了HL這一層的變換。
• margin的值一般都設置得比較小。這里用的是0.05
• 如果將Cosine_similarity這一層換成分類或者回歸，印象中效果是不如Cosine_similarity的（具體數據忘了）
• num_filters越大并不是效果越好，基本到了一定程度就很難提升了，反而會降低訓練速度。
• 同時也寫了tensorflow版本代碼，對比theano的，效果差不多。
• Adam和SGD兩種訓練方法比較，Adam訓練速度貌似會更快一些，效果基本也持平吧，沒有太細節的對比。不過同樣的網絡+SGD，theano好像訓練要更快一些。
• Loss和Accuracy是比較重要的監控參數。如果寫一個新的網絡的話，類似的指標是很有必要的，可以在每個迭代中評估網絡是否正在收斂。因為調試比較麻煩，所以通過這些參數能評估你的網絡寫對沒，參數設置是否正確。
• 網絡的參數還是比較重要的，如果一些參數設置不合理，很有可能結果千差萬別，記得最初用tensorflow實現的時候，應該是dropout設置得太小，導致效果很差，很久才找到原因。所以調參和微調網絡還是需要一定的技巧和經驗的，做這版代碼的時候就經歷了一段比較痛苦的調參過程，最開始還懷疑是網絡設計或是代碼有問題，最后總結應該就是參數沒設置好。
  

結語 如果關注這個東西的人多的話，后面還可以有tensorflow版本的QA CNN，以及LSTM的代碼奉上 Contact: jiangwen127@gmail.com weibo:碼壇奧沙利文
發表在 機器學習, 深度學習, 自然語言處理, 問答系統? ? ? ? | 留下評論

達觀數據搜索引擎的Query自動糾錯技術和架構詳解發表于 2016年04月27號 由 recommender
1 背景 如今，搜索引擎是人們的獲取信息最重要的方式之一，在搜索頁面小小的輸入框中，只需輸入幾個關鍵字，就能找到你感興趣問題的相關網頁。搜索巨頭Google，甚至已經使Google這個創造出來的單詞成為動詞，有問題Google一下就可以。在國內，百度也同樣成為一個動詞。除了通用搜索需求外，很多垂直細分領域的搜索需求也很旺盛，比如電商網站的產品搜索，文學網站的小說搜索等。面對這些需求，達觀數據(www.datagrand.com)作為國內提供中文云搜索服務的高科技公司，為合作伙伴提供高質量的搜索技術服務，并進行搜索服務的統計分析等功能。（達觀數據聯合創始人高翔） 搜索引擎系統最基本最核心的功能是信息檢索，找到含有關鍵字的網頁或文檔，然后按照一定排序將結果給出。在此基礎之上，搜索引擎能夠提供更多更復雜的功能來提升用戶體驗。對于一個成熟的搜索引擎系統，用戶看似簡單的搜索過程，需要在系統中經過多個環節，多個模塊協同工作，才能提供一個讓人滿意的搜索結果。其中拼寫糾錯（Error Correction，以下簡稱EC）是用戶比較容易感知的一個功能，比如百度的糾錯功能如下圖所示： 圖 1：百度糾錯功能示例 EC其實是屬于Query Rewrite（以下簡稱QR）模塊中的一個功能，QR模塊包括拼寫糾錯，同義改寫，關聯query等多個功能。QR模塊對于提升用戶體驗有著巨大的幫助，對于搜索質量不佳的query進行改寫后能返回更好的搜索結果。QR模塊內容較多，以下著重介紹EC功能。
繼續閱讀 →
發表在 自然語言處理? ? ? ? | 一條評論

非主流自然語言處理——遺忘算法系列（四）：改進TF-IDF權重公式發表于 2016年04月23號 由 老憨

一、前言
　　前文介紹了利用詞庫進行分詞，本文介紹詞庫的另一個應用：詞權重計算。

二、詞權重公式
　　1、公式的定義

　　　　定義如下公式，用以計算詞的權重：
　　　　
　　2、公式的由來

　　　　在前文中，使用如下公式作為分詞的依據：
　　　　

　　　　任給一個句子或文章，通過對最佳分詞方案所對應的公式進行變換，可以得到：
　　　　

　　　　按前面權重公式的定義，上面的公式可以理解為：一個句子出現的概率對數等于句子中各詞的權重之和。

　　　　公式兩邊同時取負號使權重是個正值。



三、與TF-IDF的關系
　　詞頻、逆文檔頻率（TF-IDF）在自然語言處理中，應用十分廣泛，也是提取關鍵詞的常用方法，公式如下：
　　

　　從形式上看，該公式與我們定義的權重公式很像，而且用途也近似，那么它們之間有沒有關系呢？

　　答案是肯定的。

　　我們知道，IDF是按文檔為單位統計的，無論文檔的長短，統一都按一篇計數，感覺這個統計的粒度還是比較粗的，有沒有辦法將文本的長短，這個明顯相關的因素也考慮進去呢，讓這個公式更加精細些？

　　答案也是肯定的。

　　文章是由詞鋪排而成，長短不同，所包含的詞的個數也就有多有少。

　　我們可以考慮在統計文檔個數時，為每個文檔引入包含多少個詞這樣一個權重，以區別長短不同的文檔，沿著這個思路，改寫一下IDF公式：
　　
　　我們用所有文檔中的詞做成詞庫，那么上式中：
　　
　　綜合上面的推導過程，我們知道，本文所定義的詞權重公式，本質上是tf-idf為長短文檔引入權重的加強版，而該公式的應用也極為簡單，只需要從詞庫中讀取該詞詞頻、詞庫總詞頻即可。

　　時間復雜度最快可達O（1）級，比如詞庫以Hash表存儲。

　　關于TF-IDF更完整的介紹及主流用法，建議參看阮一峰老師的博文《TF-IDF與余弦相似性的應用（一）：自動提取關鍵詞》。

四、公式應用
　　　　詞權重用途很廣，幾乎詞袋類算法中，都可以考慮使用。常見的應用有：

　　　　 1、關鍵詞抽取、自動標簽生成

　　　　 　　　作法都很簡單，分詞后排除停用詞，然后按權重值排序，取排在前面的若干個詞即可。

　　　　 2、文本摘要

　　　　 　　　完整的文本摘要功能實現很復雜也很困難，這里所指，僅是簡單應用：由前面推導過程中可知，句子的權重等于分詞結果各詞的權重之和，從而獲得句子的權重排序。

　　　　 3、相似度計算

　　　　 　　　相似度計算，我們將在下一篇文中單獨介紹。

五、演示程序
　　在演示程序顯示詞庫結果時，是按本文所介紹的權重公式排序的。

　　演示程序與詞庫生成的相同：

　　下載地址：遺忘算法（詞庫生成、分詞、詞權重）演示程序.rar

　　特別感謝：王斌老師指出，本文公式實質上是TF-ICF。
六、聯系方式：　　1、QQ：老憨 244589712
　　2、郵箱：gzdmcaoyc@163.com

發表在 自然語言處理? ? ? ? | 標簽為 TF-IDF, 自然語言處理, 遺忘算法? ? ? ? | 留下評論

非主流自然語言處理——遺忘算法系列（三）：分詞發表于 2016年04月23號 由 老憨

一、前言
　　前面介紹了詞庫的自動生成的方法，本文介紹如何利用前文所生成的詞庫進行分詞。

二、分詞的原理
　　分詞的原理，可以參看吳軍老師《數學之美》中的相關章節，這里摘取Google黑板報版本中的部分：

　　

　　從上文中，可以知道分詞的任務目標：給出一個句子S，找到一種分詞方案，使下面公式中的P（S）最大：

　　

　　不過，聯合概率求起來很困難，這種情況我們通常作馬爾可夫假設，以簡化問題，即：任意一個詞wi的出現概率只同它前面的詞 wi-1 有關。

　　關于這個問題，吳軍老師講的深入淺出，整段摘錄如下：
　　

　　另外，如果我們假設一個詞與其他詞都不相關，即相互獨立時，此時公式最簡，如下：
　　

　　這個假設分詞無關的公式，也是本文所介紹的分詞算法所使用的。

三、算法分析
　　問：假設分詞結果中各詞相互無關是否可行？

　　答：可行，前提是使用遺忘算法系列（二）中所述方法生成的詞庫，理由如下：

　　分析ICTCLAS廣受好評的分詞系統的免費版源碼，可以發現，在這套由張華平、劉群兩位博士所開發分詞系統的算法中假設了：分詞結果中詞只與其前面的一個詞有關。

　　回憶我們詞庫生成的過程可以知道，如果相鄰的兩個詞緊密相關，那么這兩個詞會連為一個粗粒度的詞被加入詞庫中，如：除“清華”、“大學”會是單獨的詞外，“清華大學”也會是一個詞，分詞過程中具體選用那種，則由它們的概率來決定。

　　也就是說，我們在生成詞庫的同時，已經隱含的完成了相關性訓練。

　　關于ICTCLAS源碼分析的文章，可以參看呂震宇博文：《天書般的ICTCLAS分詞系統代碼》。

　　問：如何實現分詞？

　　答：基于前文生成的詞庫，我們可以假設分詞結果相互無關，分詞過程就比較簡單，使用下面的步驟可以O(N)級時間，單遍掃描完成分詞：

　　逐字掃描句子，從詞庫中查出限定字長內，以該字結尾的所有詞，分別計算其中的詞與該詞之前各詞的概率乘積，取結果值最大的詞，分別緩存下當前字所在位置的最大概率積，以及對應的分詞結果。

　　重復上面的步驟，直到句子掃描完畢，最后一字位置所得到即為整句分詞結果。


　　3、算法特點
　　　　3.1、無監督學習；
　　　　3.2、O(N)級時間復雜度；
　　　　3.3、詞庫自維護，程序可無需人工參與的情況下，自行發現并添加新詞、調整詞頻、清理錯詞、移除生僻詞，保持詞典大小適當；
　　　　3.4、領域自適應：領域變化時，詞條、詞頻自適應的隨之調整；
　　　　3.5、支持多語種混合分詞。



四、演示程序下載
　　演示程序與詞庫生成的相同：

　　下載地址：遺忘算法（詞庫生成、分詞、詞權重）演示程序.rar

五、聯系方式：
　　1、QQ：老憨 244589712
　　2、郵箱：gzdmcaoyc@163.com

發表在 自然語言處理? ? ? ? | 標簽為 無監督分詞, 自然語言處理, 自適應詞典, 跨語種, 遺忘算法? ? ? ? | 13 條評論

非主流自然語言處理——遺忘算法系列（二）：大規模語料詞庫生成發表于 2016年04月23號 由 老憨
一、前言
　　本文介紹利用牛頓冷卻模擬遺忘降噪，從大規模文本中無監督生成詞庫的方法。



二、詞庫生成


　　　　算法分析，先來考慮以下幾個問題



　　　　問：目標是從文本中抽取詞語，是否可以考慮使用遺忘的方法呢？

　　　　答：可以，詞語具備以相對穩定周期重復再現的特征，所以可以考慮使用遺忘的方法。這意味著，我們只需要找一種適當的方法，將句子劃分成若干子串，這些子串即為“候選詞”。在遺忘的作用下，如果“候選詞”會周期性重現，那么它就會被保留在詞庫中，相反如果只是偶爾或隨機出現，則會逐漸被遺忘掉。



　　　　問：那用什么方法來把句子劃分成子串比較合適呢？

　　　　答：考察句中任意相鄰的兩個字，相鄰兩字有兩種可能：要么同屬于一個共同的詞，要么是兩個詞的邊界。我們都會有這樣一種感覺，屬于同一個詞的相鄰兩字的“關系”肯定比屬于不同詞的相鄰兩字的“關系”要強烈一些。

　　　　數學中并不缺少刻劃“關系”的模型，這里我們選擇公式簡單并且參數容易統計的一種：如果兩個字共現的概率大于它們隨機排列在一起的概率，那么我們認為這兩個字有關，反之則無關。

　　　　如果相鄰兩字無關，就可以將兩字中間斷開。逐字掃描句子，如果相鄰兩字滿足下面的公式，則將兩字斷開，如此可將句子切成若干子串，從而獲得“候選詞”集，判斷公式如下圖所示：

　　　　

　　　　公式中所需的參數可以通過統計獲得：遍歷一次語料，即可獲得公式中所需的“單字的頻數”、“相鄰兩字共現的頻數”，以及“所有單字的頻數總和”。



　　　　問：如何計算遺忘剩余量？

　　　　答：使用牛頓冷卻公式，各參數在遺忘算法中的含義，如下圖所示：



　　　　牛頓冷卻公式的詳情說明，可以參考阮一峰老師的博文《基于用戶投票的排名算法（四）：牛頓冷卻定律》。

　　　　

　　　　問：參數中時間是用現實時間嗎，遺忘系數取多少合適呢？

　　　　答：a、關于時間：

　　　　　　可以使用現實時間，遺忘的發生與現實同步。

　　　　　　也可以考慮用處理語料中對象的數量來代替，這樣僅當有數據處理時，才會發生遺忘。比如按處理的字數為計時單位，人閱讀的速度約每秒5至7個字，當然每個人的閱讀速度并不相同，這里的參數值要求并不需要特別嚴格。



　　　　　　b、遺忘系數可以參考艾賓浩斯曲線中的實驗值，如下圖（來自互聯網）

　　　　

　　　　　　我們取6天記憶剩余量約為25.4%這個值，按每秒閱讀7個字，將其代入牛頓冷卻公式可以求得遺忘系數：

　　　　



　　　　　　注意艾賓浩斯曲線中的每組數值代入公式，所得的系數并不相同，會對詞庫的最大有效容量產生影響。

二、該算法生成詞庫的特點
　　　　3.1、無監督學習

　　　　3.2、O(N)級時間復雜度

　　　　3.3、訓練、執行為同一過程，可無縫處理流式數據

　　　　3.4、未登錄詞、新詞、登錄詞沒有區別

　　　　3.5、領域自適應：領域變化時，詞條、詞頻自適應的隨之調整

　　　　3.6、算法中僅使用到頻數這一語言的共性特征，無需對任何字符做特別處理，因此原理上跨語種。

三、詞庫成熟度

　　由于每個詞都具備一個相對穩定的重現周期，不難證明，當訓練語料達到一定規模后，在遺忘的作用下，每個詞的詞頻在衰減和累加會達到平衡，也即衰減的速度與增加的速度基本一致。成熟的詞庫，詞頻的波動相對會比較小，利用這個特征，我們可以衡量詞庫的成熟程度。

四、源碼（C#）、演示程序下載

　　使用內附語料（在“可直接運行的演示程序”下可以找到）生成詞庫效果如下：
　　
　　下載地址：遺忘算法（詞庫生成、分詞、詞權重）演示程序.rar
五、聯系方式：

　　1、QQ：老憨 244589712
　　2、郵箱：gzdmcaoyc@163.com


發表在 自然語言處理? ? ? ? | 標簽為 未登錄詞發現, 牛頓冷卻公式, 自然語言處理, 詞庫生成, 遺忘算法? ? ? ? | 4 條評論

非主流自然語言處理——遺忘算法系列（一）：算法概述發表于 2016年04月19號 由 老憨
一、前言
這里“遺忘”不是筆誤，這個系列要講的“遺忘算法”，是以牛頓冷卻公式模擬遺忘為基礎、用于自然語言處理（NLP）的一類方法的統稱，而不是大名鼎鼎的“遺傳算法”！

在“遺忘”這條非主流自然語言處理路上，不知不覺已經摸索了三年有余，遺忘算法也算略成體系，雖然仍覺時機未到，還是決定先停一下，將腦中所積梳理成文，交由NLP的同好們點評交流。

二、遺忘算法原理
能夠從未知的事物中發現關聯、提煉規律才是真正智能的標志，而遺忘正是使智能生物具備這一能力的工具，也是適應變化的利器，“遺忘”這一頗具負能量特征的家伙是如何實現發現規律這么個神奇魔法的呢？

讓我們從巴甫洛夫的狗說起：狗聽到鈴聲就知道開飯了。

鈴聲和開飯之間并不存在必然的聯系，我們知道之所以狗會將兩者聯系在一起，是因為巴甫洛夫有意的將兩者一次次在狗那兒重復共現。所以，重復是建立關聯的必要條件。

我們還可以想像，狗在進食的時候聽到的聲音可能還有鳥叫聲、風吹樹葉的沙沙聲，為什么這些同樣具備重復特征聲音卻沒有和開飯建立關系呢？

細分辨我們不難想到：鈴聲和開飯之間不僅重復共現，而且這種重復共現還具備一個相對穩定的周期，而其他的那些聲音和開飯的共現則是隨機的。

那么遺忘又在其中如何起作用的呢？

1、所有事物一視同仁的按相同的規律進行遺忘； 2、偶爾或隨機出現的事物因此會隨時間而逐漸淡忘； 3、而具有相對穩定周期重復再現的事物，雖然也按同樣的規律遺忘，但由于周期性的得到補充，從而可以動態的保留在記憶中。

在自然語言處理中，很多對象比如：詞、詞與詞的關聯、模板等，都具備按相對穩定重現的特征，因此非常適用遺忘來處理。

三、牛頓冷卻公式
那么，我們用什么來模擬遺忘呢？

提到遺忘，很自然的會想到艾賓浩斯遺忘曲線，如果這條曲線有個函數形式，那么無疑是模擬遺忘的最佳建模選擇。遺憾的是它只是一組離散的實驗數據，但至少讓我們知道，遺忘是呈指數衰減的。

另外有一個事實，有的人記性好些，有的人記性則差些，不同人之間的遺忘曲線是不同的，但這并不會從本質上影響不同人對事物的認知，也就是說，如果存在一個遺忘函數，它首先是指數形式的，其次在實用過程中，該函數的系數并不那么重要。

這提醒我們，可以嘗試用一些指數形式的函數來代替遺忘曲線，然后用實踐去檢驗，如果能滿足工程實用就很好，這樣的函數公式并不難找，比如：退火算法、半衰期公式等。

有次在阮一峰老師的博客上看關于帖子熱度排行的算法時，其中一種方法使用的是牛頓冷卻定律，遺忘與冷卻有著相似的過程、簡潔優美的函數形式、而且參數只與時間相關，這些都讓我本能想到，它就是我想要的“遺忘公式”。

在實踐檢驗中，牛頓冷卻公式，確實有效好用，當然，不排除有其他更佳公式。

四、已經實現的功能
如果把自然語言處理比作從礦砂中淘金子，那么業界主流算法的方向是從礦砂中將金砂挑出來，而遺忘算法的方向則是將砂石篩出去，雖然殊途但同歸，所處理的任務也都是主流中所常見。

本系列文章將逐一講解遺忘算法如何以O（N）級算法性能實現：

1、大規模語料詞庫生成
　　　　1.1、跨語種，算法語種無關，比如：中日韓、少數民族等語種均可支持
　　　　1.2、未登錄詞發現（只要符合按相對穩定周期性重現的詞匯都會被收錄）
　　　　1.3、領域自適應，切換不同領域的訓練文本時，詞條、詞頻自行調整
　　　　1.4、詞典成熟度：可以知道當前語料訓練出的詞典的成熟程度

2、分詞（基于上述詞庫技術）
　　　　2.1、成長性分詞：用的越多，切的越準
　　　　2.2、詞典自維護：切詞的同時動態維護詞庫的詞條、詞頻、登錄新詞
　　　　2.2、領域自適應、跨語種（繼承自詞庫特性）

3、詞權值計算
　　　　3.1、關鍵詞提取、自動標簽
　　　　3.2、文章摘要
　　　　3.3、長、短文本相似度計算
　　　　3.4、主題詞集

五、聯系方式：
1、QQ：老憨 244589712

2、郵箱：gzdmcaoyc@163.com





發表在 自然語言處理? ? ? ? | 標簽為 牛頓冷卻公式, 自然語言處理, 遺忘算法? ? ? ? | 留下評論

達觀數據對于大規模消息數據處理的系統架構發表于 2015年12月2號 由 recommender
達觀數據是為企業提供大數據處理、個性化推薦系統服務的知名公司，在應對海量數據處理時，積累了大量實戰經驗。其中達觀數據在面對大量的數據交互和消息處理時，使用了稱為DPIO的設計思路進行快速、穩定、可靠的消息數據傳遞機制，本文分享了達觀數據在應對大規模消息數據處理時所開發的通訊中間件DPIO的設計思路和處理經驗（達觀數據架構師 桂洪冠） 一、數據通訊進程模型 在設計達觀數據的消息數據處理機制時，首先充分借鑒了ZeroMQ和ProxyIO的設計思想。ZeroMQ提供了一種底層的網絡通訊框架，提供了基本的RoundRobin負載均衡算法，性能優越，而ProxyIO是雅虎的網絡通訊中間件，承載了雅虎內部大量計算節點間的實時消息處理。但是ZeroMQ沒有實現基于節點健康狀態的最快響應算法，并且ZeroMQ和ProxyIO對節點的狀態管理，連接管理，負載均衡調度等也需要各應用自己來實現。 達觀科技在借鑒兩種設計思路的基礎上，從進程模型、服務架構、線程模型、通訊協議、負載均衡、雪崩處理、連接管理、消息流程、狀態監控等各方面進行了開拓，開發了DPIO（達觀ProxyIO的簡寫，下文統稱DPIO），確保系統高性能處理相關數據。 在DPIO的整個通訊框架體系中，采用集中管理、統一監控策略管理節點提供服務，節點間直接進行交互，并不依賴統一的管理節點（桂洪冠）。幾種節點間通過http或者tcp協議進行消息傳遞、配置更新、狀態跟蹤等通訊行為。集群將不同應用的服務抽象成組的概念，相同應用的服務啟動時加入的相同的組。每個通訊組有兩種端點client和server。應用啟動時通過配置決定自己是client端點還是server端點，在一個組內，每個應用只能有一個身份；不同組沒要求。

• 監控節點，顧名思義即提供系統監控服務的，用來給系統管理員查看集群中節點的服務狀態及負載情況，系統對監控節點并無實時性及穩定性要求，在本模型中是單點系統。
• 在上圖的架構中把管理節點設計成雙master結構，參考zookeeper集群管理思路，多個master通過一定算法分別服務于集群中一部分節點，相對于另外的服務節點則為備份管理節點，他們通過內部通訊同步數據，每個管理節點都有一個web服務為監控節點提供服務節點的狀態數據。
• 服務節點即是下文要談的代理服務，根據服務對象不同分為應用端代理和服務端代理。集群中的服務節點根據提供服務的不同分為多個組，每個代理啟動都需要注冊到相應的組中，然后提供服務。
  

二、DPIO消息傳遞邏輯架構 DPIO服務節點內/間的通訊及消息傳遞模型見下圖：

• clientHost和serverHost間使用socketapi進行tcp通訊，相同主機內部的多個進程間使用共享內存傳遞消息內容，client和clientproxy、server和serverproxy之間通過domain socket進行事件通知；在socket連接的一方收到對端的事件通知后，從共享內存中獲取消息內容。
• clientproxy/serverproxy啟動時綁定到host的一個端口響應應用api的連接，在連接到來時將該api對應的共享內存初始化，將偏移地址告訴給應用。clientproxy和serverproxy中分別維護了一個到應用api的連接句柄隊列，并通過io復用技術監聽這些連接上的讀寫事件。
• serverproxy在啟動時通過socket綁定到服務器的一個端口，并以server身份注冊到一個group監聽該端口的連接事件，當事件到達時回調注冊的事件處理函數響應事件。
• 在serverproxy內部通過不同的thread分別管理從本地應用建立的連接和從clientproxy建立的連接。thread的個數在啟動proxy時由用戶指定，默認是分別1個。每個clientproxy啟動時會以client身份注冊到一個group，并建立到同組的所有serverproxy的連接，clientproxy內部包含了連接的自管理能力及failover的處理(將在下面連接管理部分描述)。 DPIO實現了負載均衡，路由選擇和透明代理的功能。
  

三、線程模型 DPIO的線程模型： App epoll thread檢測從api來的請求信息，并將請求信息轉發到待處理隊列中。從已處理隊列中獲取應答包，并將處理結果轉發給api Io epoll thread檢測從遠端的proxy來的可寫事件，并將請求包轉發到遠端的proxy。檢測從遠端的proxy的可讀事件，并將應答包放在已處理隊列中 Monitor thread檢測DPIO的工作狀態請求，將DPIO的工作狀態返回。并將決定Io epoll thread和app epoll thread的負載均衡（桂洪冠）。 四、通信協議

• Api與DPIO通信協議
  

• 共享內存存儲消息格式
  

字段	含義	長度
protocol len	協議包的總長度	4bytes
protocol head len	協議頭的長度	1byte
Version_protocol_id	協議的版本號和協議號	1byte
Flag	消息標志，標志路由模式，是否記錄來源地址,有二級路由，所以這個字段一定要Eg，末位表示要記錄src，倒數第二位表示按roundrobin路由，倒數第3位表示按消息頭路由，xxx	1byte
Proxy	來源/目的 proxy	2bytes
Api	來源/目的 api	2bytes
ApiTtl	協議包的發送時間	2Bytes
ClientTtl	消息存活的時間，后面添加，增加路由策略，選擇app_server	2Bytes
ClientProcessTime	客戶端處理所用時間	2Bytes
ServerTtl	消息存活的時間，后面添加，增加路由策略，選擇app_client	2Bytes
timeout	協議包的超時時間	2 byte
Sid	消息序列號	4bytes
protocol body len	Body長度	4bytes
protocol body	消息體	Size

• 請求協議包
  

字段	含義	長度
protocol head len	協議頭的長度	1byte
Version_protocol_id	協議的版本號和協議號	1byte
Flag	消息標志，標志路由模式，是否記錄來源地址,有二級路由，所以這個字段一定要Eg，末位表示要記錄src，倒數第二位表示按roundrobin路由，倒數第3位表示按消息頭路由，xxx	1byte
ApiTtl	協議包的發送時間	2bytes
Timeout	協議包的超時時間	2bytes
Api	來源/目的 api	2bytes
Sid	消息序列號	4byte
Begin_offset	協議包的起始偏移	4bytes
len	協議包長度	4bytes

• 響應協議包
  

字段	含義	長度
protocol head len	協議頭的長度	1byte
Version_protocol_id	協議的版本號和協議號	1byte
Flag	消息標志，標志路由模式，是否記錄來源地址,有二級路由，所以這個字段一定要Eg，末位表示要記錄src，倒數第二位表示按roundrobin路由，倒數第3位表示按消息頭路由，xxx	1byte
Result	處理結果	1byte
sid	消息序列號	4bytes
begin_offset	協議包的起始偏移	4bytes
len	協議包長度	4bytes

• Proxy與監控中心的監控信息
  

• 請求協議包
  

字段	含義	長度
protocol len	協議包的總長度	4bytes
protocol head len	協議頭的長度	4bytes
Version	協議的版本號	4bytes
protocol id	協議的協議號	4bytess
status_version	當前狀態版本	4bytes
Proxy_identify_len	該proxy標識長度	4bytess
Proxy_identify	該proxy 標識	4bytes
protocol body	消息體	Size

• 應答包
  

字段	含義	長度
protocol len	協議包的總長度	4bytes
protocol head len	協議頭的長度	4bytes
Version	協議的版本號	4bytes
protocol id	協議的協議號	4bytess
protocol body len	Body長度	4bytes
protocol body	消息體	Size

五、負載均衡 DPIO的負載均衡基于最快響應法 DPIO將所有的統計信息更新到監控中心，監控中心通過處理所有的節點的狀態信息，統一負責負載均衡。 DPIO從監控中心獲取所有連接的負載均衡策略。每個連接知道只需知道自己的處理能力。 以上圖為例，有三個proxy server處理程序。處理能力分別為50、30、20，一次epoll過程能夠同時探測多個連接的可寫事件。 假設：三個proxy server的屬于同一epoll thread，且三個proxy server假設都處理能力無限大。 限制：如果剛開始時待處理隊列的數據包個數為100個，多次發送輪回后proxy server A≥proxy server B≥proxy server C， 每個發送的最多發送協議包數為待處理隊列協議包個數 * 該連接所占權重 六、雪崩處理 大型在線服務，特別是對于時延敏感的服務，當系統外部請求超過系統服務能力，而沒有適當的過載保護措施時，當系統累計的超時請求達到一定規模，將可能導致系統緩沖區隊列溢出，后端服務資源耗盡，最終像雪崩一樣形成惡性循環。這時系統處理的每個請求都因為超時而無效，系統對外呈現的服務能力為0，且這種情況下不能自動恢復。 我們的解決策略是對協議包進行生命周期管理，現在協議包進出待處理隊列和已處理隊列時進行超時檢測和超時處理（超時則丟棄）。 proxy client： 當app epoll thread將協議包放入待處理隊列時，會將該協議包的發送時間、該協議包的超時時間，當前時間戳來判斷該協議包是否已經超時。 當app epoll thread將協議包從已處理隊列中移除時，會將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 當Io epoll thread將協議包從待處理隊列中移除時，會將該協議包的發送時間、該協議包的超時時間，當前時間戳，該連接的協議包的平均處理時間移除。 當io epoll thread將協議包放入已處理隊列時，會將將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 proxy server： 當App epoll thread將協議包從待處理隊列中移除時，會將該協議包在客戶端的處理時間、該協議包的超時時間、該協議包的proxy server接收時間戳、當前時間戳來判斷該協議包是否已超時。 當app epoll thread將協議包放入已處理隊列時，會將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 當io epoll thread將協議包從已處理隊列中移除時，會將該協議包的發送時間、該協議包的超時時間，已經當前時間戳來判斷該協議包是否已經超時。 當io epoll thread將協議包放入待處理隊列時，會將該協議包的發送時間、該協議包的超時時間來判斷該協議包是否已超時。 七、連接管理 紅黑樹： 紅黑樹：保存所有連接的最近的讀/寫時間戳。 當epoll_wait時，首先從紅黑樹中獲取oldest的時間戳，并將當前時間戳與oldest時間戳的時間差作為epoll_wait的超時時間，當連接中有可讀/寫事件發送時，首先從紅黑樹中刪除該節點，當可讀/寫事件處理完畢后，再將節點插入到紅黑樹中，當處理完所有連接的可讀/寫事件時，再從紅黑樹中依次從移除時間戳小于當前時間戳的連接，并觸發該連接的timeout事件。 八、消息處理流程

• apiclient通過調用api的接口，將消息傳給
• api接受消息體，從共享內存中申請內存，填寫消息頭size（協議總長度）、Offset （協議版本號和協議號）、Headsize （協議頭的總長度）、flag(路由策略)，ApiTtl （協議包的發送時間）、timeout （協議包的超時時間）、sid(序列號)，size(消息體長度)字段，封裝成協議包，將協議包寫入共享內存。
• api通過socket發送請求給proxy。
• app epoll thread通過檢測api的可讀事件，接受請求。通過解析請求內容，獲取請求協議包所在的共享內存的偏移、請求協議包的長度和api連接index加入到處理隊列。
• proxy client的io epoll thread通過檢測對端DPIO連接的可寫事件，從發送隊列中獲取請求包，將api的index加入到協議包的api index字段。
• proxy client的io epoll thread從共享內存中讀取協議包，釋放由請求包中所標識的內存空間。
• proxy server的io epoll thread通過檢測對端DPIO的可讀事件，接受請求。
• proxy server的io epoll thread從共享內存中申請空間，將proxy的index加入到協議包的proxy index字段。將請求內存寫入到申請的空間中。
• proxy server的io epoll thread 將協議包在共享內存的偏移和協議包的長度加入的待處理隊列中。
• app epoll thread從待處理隊列中獲取請求包，將協議包轉發給相應的api進行處理。
• api通過檢測DPIO的可讀事件，解析請求內容。
• api通過解析請求內容，獲取請求協議包在共享內存中的偏移和請求協議包的長度。從共享內存中讀取請求內容，并釋放相應空間。
• api將請求協議包返回給應用層進行處理。
• 應用層將應答包傳給api。
• Api從共享內存中申請空間，將應答包寫入到共享內存中。
• Api將應答包在共享內存中的偏移和應答包的大小寫入到共享內存中。
• App epoll thread通過檢測可讀事件，將應答包寫入到已處理隊列中。
• proxy server的Io epoll thread通過檢測對端的DPIO的可寫事件，將已處理隊列中獲取應答包。
• proxy server的Io epoll thread從共享內存中讀取應答包。
• Proxy client的Io epoll thread檢測可讀事件，讀取應答包。
• Proxy client的Io epoll thread通過解析應答包，從共享內存中申請空間，將應答包寫入到申請的內存中。
• Proxy client的Io epoll thread將應答包移入到已處理隊列。
• App epoll thread通過檢測api的可寫事件，將已處理隊列中獲取應答包。
• App epoll thread發送應答包。
• Api通過檢測可讀事件，獲取應答包，通過解析應到包，獲取應答包在共享內存中的偏移和應到的大小，從共享內存中讀取應到包。
• Api將應答包返回給應用端。(桂洪冠 陳運文)。
  

九、狀態監控 連接池中存在：當前可用連接個數 連接池中再分別獲取每個連接的狀態 每個可用連接分別維護以下信息： 連接處理的數據包個數、連接send失敗次數、連接協議包的平均處理時間。 連接的連接狀態(當重連失敗達到一定次數時，定義為連接失敗)。 連接的重連次數、連接的超時次數。 當監控線程accept到client的連接時，解析請求內容，然后調用連接池對象的statistics方法，連接池對象首先寫入自己的統計信息，然后分別調用每個連接的statistics方法，每個連接分別填寫自己的統計信息 本文小結 大規模消息傳遞會遇到很多可靠性、穩定性的問題，DPIO是達觀在處理大數據通訊時的一些經驗，和感興趣的朋友們分享，期待與大家不斷交流與合作
發表在 數據挖掘? ? ? ? | 標簽為 數據處理, 數據通訊? ? ? ? | 留下評論

在微信公眾號里使用LaTeX數學公式發表于 2015年11月17號 由 52nlp
因為有同學在微信后臺咨詢這個問題，所以這里簡單記錄一下，其實自己之前也摸索了一些方法，不是太完美，目前所使用的這個方法算是折中后比較好的。 這段時間在鼓搗“NLPJob”這個公眾號，特別是微信公眾號支持“原創聲明”后，就很樂意將52nlp上積攢的一些文章搬上去，但是逐漸會遇到一些數學公式的問題。目前在52nlp上用的是mathjax完美支持LaTeX數學公式展現，但是微信公眾號的編輯器沒有這個支持，另外mathjax支持的公式形式不是圖片形式，所以不能直接將文章拷貝上去，但是如果是數學公式圖片，微信編輯器可以直接拷貝，所以最直接的想法就是將mathjax支持的LaTeX公式轉換為公式圖片保存在文章中，然后再全文拷貝到微信公眾號編輯器中。 其實在mathjax之前，網頁上的很多數學公式都是用這種折中的方式，包括很多wordpress數學公式插件，當年我也因為52nlp上的公式問題還自己動手寫了一個小的wordpress插件，但是當mathjax出現之后，之前的方案就顯得很一般了。所以就開始嘗試找一下支持img緩存的LaTeX公式插件，不過多數都不滿意或者有瑕疵，甚至自己又開始動手修改代碼，然后blablabla….，最終發現 quicklatex這個神器和它的wordpress插件QuickLaTeX，幾乎完美支持和兼容Mathjax所支持的LaTeX數學公式。方法很簡單，只要在wordpress中安裝quicklatex，然后在文章的開頭添加一個：[latexpage] ，然后文章中所有的latext公式都會轉換為圖片形式，類似昨天發出的rickjin的這篇文章：LDA數學八卦：神奇的Gamma函數(1)。當然需要先在wordpress中完成編輯轉換，再全文拷貝到微信公眾號中，微信會自動的將這些圖片上傳到它自己的圖片服務器上。不過依然希望微信公眾號編輯器能早日支持LaTeX公式編輯甚至Mathjax。
發表在 隨筆? ? ? ? | 標簽為 latex公式, latex數學公式, MathJax, 微信, 微信latex, 微信公眾號, 微信公眾號數學公式編輯器, 微信公式編輯器, 微信數學公式? ? ? ? | 2 條評論

斯坦福大學深度學習與自然語言處理第四講：詞窗口分類和神經網絡發表于 2015年09月14號 由 52nlp
斯坦福大學在三月份開設了一門“深度學習與自然語言處理”的課程：CS224d: Deep Learning for Natural Language Processing，授課老師是青年才俊 Richard Socher，以下為相關的課程筆記。 第四講：詞窗口分類和神經網絡（Word Window Classification and Neural Networks） 推薦閱讀材料：

• [UFLDL tutorial]
• [Learning Representations by Backpropogating Errors]
• 第四講Slides [slides]
• 第四講視頻 [video]
  

以下是第四講的相關筆記，主要參考自課程的slides，視頻和其他相關資料。
繼續閱讀 →
發表在 機器學習, 深度學習, 自然語言處理? ? ? ? | 標簽為 Deep Learning, Deep Learning公開課, Deep NLP, DL, NER, Richard Socher, softmax, word vectors, word2vec, wordnet, 二元邏輯回歸, 人名識別, 公開課, 分類, 分類器, 前饋網絡記錄, 反向傳播算法, 命名實體識別, 回歸, 地名識別, 斯坦福大學, 機器學習, 梯度下降, 深度學習, 深度學習與自然語言處理, 深度學習技術, 深度學習模型, 神經元, 神經網絡, 窗口向量, 窗口向量分類, 自然語義處理, 自然語言處理, 詞向量, 詞嵌入, 語義詞典, 邏輯回歸, 隨機梯度下降? ? ? ? | 3 條評論

出門問問宣布完成由Google投資的C輪融資，累計融資7500萬美金發表于 2015年09月2號 由 52nlp
注：出門問問是我們的老朋友，創始人李志飛也是NLP和機器翻譯領域的大牛，今天出門問問拿到了Google的C輪融資，志飛兄第一時間和我分享了這條新聞，太牛了。 人工智能創業公司出門問問（Mobvoi），于近日完成了由Google投資的C輪融資，累計融資7500萬美金。現有投資方包括紅杉資本、真格基金，SIG海納亞洲、圓美光電、及歌爾聲學。此輪投資Google并不控股，出門問問團隊依舊有絕對控制權。 此次由Google投資的C輪融資，能夠保證出門問問在人工智能領域長期持續深耕，專注核心技術上的進一步研發，在可穿戴、車載以及機器人領域拓展新的人機交互產品形態，更深入地完善用戶體驗，在吸引全球頂尖技術與商務人才上更具優勢。對于海外市場的擴展，此次融資也將發揮非常重要的作用。 Google 企業發展部副總裁Don Harrison 說到選擇投資出門問問的原因：“出門問問研發了非常獨特自成體系的語音識別與自然語言處理技術。我們被他們的創新科技與發展潛力打動，所以我們很迅速地決定用投資的方式幫助他們在未來快速成長。” 紅杉資本全球執行合伙人沈南鵬評價：“出門問問一直處于高速的不斷創新過程中，從移動app到硬件產品到語音搜索平臺，不同形式的產品背后是團隊長期以來形成的強大技術核心，獲得Google的投資是對這種中國原創能力的最好肯定。我很高興Google這樣的巨頭看好出門問問，并和我們一起投入到這支高速創新的團隊中。” 真格基金創始人徐小平說：“我第一次遇見谷歌科學家李志飛博士，是三年前。那時候，他的語音搜索創業計劃，真是一個“異想天開”的夢。志飛相信自己的夢，相信自己的技術，相信市場對這個技術產品的需求，歷經萬難，終于“搜索”到了屬于他自己的那片天空。志飛的創業歷程，是又一個中國好故事，會激勵更多人追求并實現自己的好夢。” 志同道合是此次融資達成的最重要的原因。扎實做技術和產品，運用科技的力量改變人們的日常生活，是出門問問一直篤信的價值觀。 出門問問CEO 李志飛表示：“引入Google的投資，不僅意味Google對于我們技術的認可，更是源于雙方持有共同的價值觀，通過對人工智能技術的極致追求，打造毫不妥協的用戶體驗。” 與Google相似，出門問問也是信仰“工程師文化”的團隊，強大的研發團隊由Google前科學家、人工智能專家領銜，團隊成員來自哈佛、MIT、斯坦福、劍橋、清華等名校名企。 此次融資是中國人工智能創業公司首次獲得像Google這樣的國際技術巨頭的投資與認可。這在某種程度上說明，在人工智能領域，中國的創業公司不容小覷。
繼續閱讀 →

總結

以上是生活随笔為你收集整理的QA问答系统中的深度学习技术实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。