1. 基本介紹：

paoding ：Lucene中文分詞“庖丁解牛” Paoding Analysis
imdict ：imdict智慧詞典所採用的智慧中文分詞程式
mmseg4j ： 用 Chih-Hao Tsai 的 MMSeg 演算法 實現的中文分詞器
ik ：採用了特有的“正向迭代最細粒度切分演算法“，多子處理器分析模式

2. 開發者及開發活躍度：

paoding ：qieqie.wang， google code 上最後一次程式碼提交：2008-06-12，svn 版本號 132
imdict ：XiaoPingGao， 進入了 lucene contribute，lucene trunk 中 contrib/analyzers/smartcn/ 最後一次提交：2009-07-24，

mmseg4j ：chenlb2008，google code 中 2009-08-03 （昨天），版本號 57，log為：mmseg4j-1.7 建立分支
ik ：linliangyi2005，google code 中 2009-07-31，版本號 41

3. 使用者自定義詞庫：

paoding ：支援不限制個數的使用者自定義詞庫，純文字格式，一行一詞，使用後臺執行緒檢測詞庫的更新，自動編譯更新過的詞庫到二進位制版本，並載入
imdict ：暫時不支援使用者自定義詞庫。但 原版 ICTCLAS 支援。支援使用者自定義 stop words
mmseg4j ：自帶sogou詞庫，支援名為 wordsxxx.dic， utf8文字格式的使用者自定義詞庫，一行一詞。不支援自動檢測。 -Dmmseg.dic.path

ik ： 支援api級的使用者詞庫載入，和配置級的詞庫檔案指定，無 BOM 的 UTF-8 編碼，\r\n 分割。不支援自動檢測。

4. 速度（基於官方介紹，非自己測試）

paoding ：在PIII 1G記憶體個人機器上，1秒 可準確分詞 100萬 漢字
imdict ：483.64 (位元組/秒)，259517(漢字/秒)
mmseg4j ： complex 1200kb/s左右, simple 1900kb/s左右
ik ：具有50萬字/秒的高速處理能力

5. 演算法和程式碼複雜度

paoding ：svn src 目錄一共1.3M，6個properties檔案，48個java檔案，6895 行。使用不用的 Knife 切不同型別的流，不算很複雜。

imdict ：詞庫 6.7M（這個詞庫是必須的），src 目錄 152k，20個java檔案，2399行。使用 ICTCLAS HHMM隱馬爾科夫模型，“利用大量語料庫的訓練來統計漢語詞彙的詞頻和跳轉概率，從而根據這些統計結果對整個漢語句子計算最似然(likelihood)的切分”
mmseg4j ： svn src 目錄一共 132k，23個java檔案，2089行。MMSeg 演算法 ，有點複雜。
ik ： svn src 目錄一共6.6M(詞典檔案也在裡面)，22個java檔案，4217行。多子處理器分析，跟paoding類似，歧義分析演算法還沒有弄明白。

6. 文件

paoding ：幾乎無。程式碼裡有一些註釋，但因為實現比較複雜，讀程式碼還是有一些難度的。
imdict ： 幾乎無。 ICTCLAS 也沒有詳細的文件，HHMM隱馬爾科夫模型的數學性太強，不太好理解。
mmseg4j ： MMSeg 演算法 是英文的，但原理比較簡單。實現也比較清晰。
ik ： 有一個pdf使用手冊，裡面有使用示例和配置說明。

7. 其它

paoding ：引入隱喻，設計比較合理。search 1.0 版本就用的這個。主要優勢在於原生支援詞庫更新檢測。主要劣勢為作者已經不更新甚至不維護了。
imdict ：進入了 lucene trunk，原版 ictclas 在各種評測中都有不錯的表現，有堅實的理論基礎，不是個人山寨。缺點為暫時不支援使用者詞庫。
mmseg4j ： 在complex基礎上實現了最多分詞(max-word)，但是還不成熟，還有很多需要改進的地方。
ik ：  針對Lucene全文檢索優化的查詢分析器IKQueryParser

8. 結論

個人覺得，可以在 mmseg4j 和 paoding 中選一個。關於這兩個分詞效果的對比，可以參考：

或者自己再包裝一下，將 paoding 的詞庫更新檢測做一個單獨的模組實現，然後就可以在所有基於詞庫的分詞演算法之間無縫切換了。

ps，對不同的 field 使用不同的分詞器是一個可以考慮的方法。比如 tag 欄位，就應該使用一個最簡單的分詞器，按空格分詞就可以了。