11大Java開源中文分詞器的使用方法和分詞效果對比，當前幾個主要的Lucene中文分詞器的比較

時間  2019-11-08
標籤 java 開源 中文 分詞器 使用方法 分詞 效果 對比 當前 幾個 主要 lucene 比較 欄目 Java 简体版
原文   原文鏈接

本文的目標有兩個：php

一、學會使用11大Java開源中文分詞器html

二、對比分析11大Java開源中文分詞器的分詞效果java

本文給出了11大Java開源中文分詞的使用方法以及分詞結果對比代碼，至於效果哪一個好，那要用的人結合本身的應用場景本身來判斷。python

11大Java開源中文分詞器，不一樣的分詞器有不一樣的用法，定義的接口也不同，咱們先定義一個統一的接口：linux

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
  * 獲取文本的全部分詞結果, 對比不一樣分詞器結果
  * @author 楊尚川
  */
public  interface  WordSegmenter {
     /**
      * 獲取文本的全部分詞結果
      * @param text 文本
      * @return 全部的分詞結果，去除重複
      */
     default  public  Set<String> seg(String text) {
         return  segMore(text).values().stream().collect(Collectors.toSet());
     }
     /**
      * 獲取文本的全部分詞結果
      * @param text 文本
      * @return 全部的分詞結果，KEY 爲分詞器模式，VALUE 爲分詞器結果
      */
     public  Map<String, String> segMore(String text);
}

從上面的定義咱們知道，在Java中，一樣的方法名稱和參數，可是返回值不一樣，這種狀況不能夠使用重載。c++

這兩個方法的區別在於返回值，每個分詞器均可能有多種分詞模式，每種模式的分詞結果均可能不相同，第一個方法忽略分詞器模式，返回全部模式的全部不重複分詞結果，第二個方法返回每一種分詞器模式及其對應的分詞結果。git

在這裏，須要注意的是咱們使用了Java8中的新特性默認方法，並使用stream把一個map的value轉換爲不重複的集合。github

 

下面咱們利用這11大分詞器來實現這個接口：算法

一、word分詞器sql

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     for (SegmentationAlgorithm segmentationAlgorithm : SegmentationAlgorithm.values()){
         map.put(segmentationAlgorithm.getDes(), seg(text, segmentationAlgorithm));
     }
     return  map;
}
private  static  String seg(String text, SegmentationAlgorithm segmentationAlgorithm) {
     StringBuilder result =  new  StringBuilder();
     for (Word word : WordSegmenter.segWithStopWords(text, segmentationAlgorithm)){
         result.append(word.getText()).append( " " );
     }
     return  result.toString();
}

二、Ansj分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
 
     StringBuilder result =  new  StringBuilder();
     for (Term term : BaseAnalysis.parse(text)){
         result.append(term.getName()).append( " " );
     }
     map.put( "BaseAnalysis" , result.toString());
 
     result.setLength( 0 );
     for (Term term : ToAnalysis.parse(text)){
         result.append(term.getName()).append( " " );
     }
     map.put( "ToAnalysis" , result.toString());
 
     result.setLength( 0 );
     for (Term term : NlpAnalysis.parse(text)){
         result.append(term.getName()).append( " " );
     }
     map.put( "NlpAnalysis" , result.toString());
 
     result.setLength( 0 );
     for (Term term : IndexAnalysis.parse(text)){
         result.append(term.getName()).append( " " );
     }
     map.put( "IndexAnalysis" , result.toString());
 
     return  map;
}

三、Stanford分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
private  static  final  StanfordCoreNLP CTB =  new  StanfordCoreNLP( "StanfordCoreNLP-chinese-ctb" );
private  static  final  StanfordCoreNLP PKU =  new  StanfordCoreNLP( "StanfordCoreNLP-chinese-pku" );
private  static  final  PrintStream NULL_PRINT_STREAM =  new  PrintStream( new  NullOutputStream(),  false );
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     map.put( "Stanford Beijing University segmentation" , seg(PKU, text));
     map.put( "Stanford Chinese Treebank segmentation" , seg(CTB, text));
     return  map;
}
private  static  String seg(StanfordCoreNLP stanfordCoreNLP, String text){
     PrintStream err = System.err;
     System.setErr(NULL_PRINT_STREAM);
     Annotation document =  new  Annotation(text);
     stanfordCoreNLP.annotate(document);
     List<CoreMap> sentences = document.get(CoreAnnotations.SentencesAnnotation. class );
     StringBuilder result =  new  StringBuilder();
     for (CoreMap sentence: sentences) {
         for  (CoreLabel token: sentence.get(CoreAnnotations.TokensAnnotation. class )) {
             String word = token.get(CoreAnnotations.TextAnnotation. class );;
             result.append(word).append( " " );
         }
     }
     System.setErr(err);
     return  result.toString();
}

四、FudanNLP分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private  static  CWSTagger tagger =  null ;
static {
     try {
         tagger =  new  CWSTagger( "lib/fudannlp_seg.m" );
         tagger.setEnFilter( true );
     } catch (Exception e){
         e.printStackTrace();
     }
}
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     map.put( "FudanNLP" , tagger.tag(text));
     return  map;
}

五、Jieba分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private  static  final  JiebaSegmenter JIEBA_SEGMENTER =  new  JiebaSegmenter();
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     map.put( "INDEX" , seg(text, SegMode.INDEX));
     map.put( "SEARCH" , seg(text, SegMode.SEARCH));
     return  map;
}
private  static  String seg(String text, SegMode segMode) {
     StringBuilder result =  new  StringBuilder();                
     for (SegToken token : JIEBA_SEGMENTER.process(text, segMode)){
         result.append(token.word.getToken()).append( " " );
     }
     return  result.toString(); 
}

六、Jcseg分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private  static  final  JcsegTaskConfig CONFIG =  new  JcsegTaskConfig();
private  static  final  ADictionary DIC = DictionaryFactory.createDefaultDictionary(CONFIG);
static  {
     CONFIG.setLoadCJKSyn( false );
     CONFIG.setLoadCJKPinyin( false );
}
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
 
     map.put( "複雜模式" , segText(text, JcsegTaskConfig.COMPLEX_MODE));
     map.put( "簡易模式" , segText(text, JcsegTaskConfig.SIMPLE_MODE));
 
     return  map;
}
private  String segText(String text,  int  segMode) {
     StringBuilder result =  new  StringBuilder();        
     try  {
         ISegment seg = SegmentFactory.createJcseg(segMode,  new  Object[]{ new  StringReader(text), CONFIG, DIC});
         IWord word =  null ;
         while ((word=seg.next())!= null ) {         
             result.append(word.getValue()).append( " " );
         }
     }  catch  (Exception ex) {
         throw  new  RuntimeException(ex);
     }
     return  result.toString();
}

七、MMSeg4j分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
private  static  final  Dictionary DIC = Dictionary.getInstance();
private  static  final  SimpleSeg SIMPLE_SEG =  new  SimpleSeg(DIC);
private  static  final  ComplexSeg COMPLEX_SEG =  new  ComplexSeg(DIC);
private  static  final  MaxWordSeg MAX_WORD_SEG =  new  MaxWordSeg(DIC);
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     map.put(SIMPLE_SEG.getClass().getSimpleName(), segText(text, SIMPLE_SEG));
     map.put(COMPLEX_SEG.getClass().getSimpleName(), segText(text, COMPLEX_SEG));
     map.put(MAX_WORD_SEG.getClass().getSimpleName(), segText(text, MAX_WORD_SEG));
     return  map;
}
private  String segText(String text, Seg seg) {
     StringBuilder result =  new  StringBuilder();
     MMSeg mmSeg =  new  MMSeg( new  StringReader(text), seg);        
     try  {
         Word word =  null ;
         while ((word=mmSeg.next())!= null ) {       
             result.append(word.getString()).append( " " );
         }
     }  catch  (IOException ex) {
         throw  new  RuntimeException(ex);
     }
     return  result.toString();
}

八、IKAnalyzer分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
 
     map.put( "智能切分" , segText(text,  true ));
     map.put( "細粒度切分" , segText(text,  false ));
 
     return  map;
}
private  String segText(String text,  boolean  useSmart) {
     StringBuilder result =  new  StringBuilder();
     IKSegmenter ik =  new  IKSegmenter( new  StringReader(text), useSmart);        
     try  {
         Lexeme word =  null ;
         while ((word=ik.next())!= null ) {          
             result.append(word.getLexemeText()).append( " " );
         }
     }  catch  (IOException ex) {
         throw  new  RuntimeException(ex);
     }
     return  result.toString();
}

九、Paoding分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
private  static  final  PaodingAnalyzer ANALYZER =  new  PaodingAnalyzer();
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
 
     map.put( "MOST_WORDS_MODE" , seg(text, PaodingAnalyzer.MOST_WORDS_MODE));
     map.put( "MAX_WORD_LENGTH_MODE" , seg(text, PaodingAnalyzer.MAX_WORD_LENGTH_MODE));
     
     return  map;
}
private  static  String seg(String text,  int  mode){
     ANALYZER.setMode(mode);
     StringBuilder result =  new  StringBuilder();
     try  {
         Token reusableToken =  new  Token();
         TokenStream stream = ANALYZER.tokenStream( "" ,  new  StringReader(text));
         Token token =  null ;
         while ((token = stream.next(reusableToken)) !=  null ){
             result.append(token.term()).append( " " );
         }
     }  catch  (Exception ex) {
         throw  new  RuntimeException(ex);
     }
     return  result.toString();          
}

十、smartcn分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
private  static  final  SmartChineseAnalyzer SMART_CHINESE_ANALYZER =  new  SmartChineseAnalyzer();
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     map.put( "smartcn" , segText(text));
     return  map;
}
private  static  String segText(String text) {
     StringBuilder result =  new  StringBuilder();
     try  {
         TokenStream tokenStream = SMART_CHINESE_ANALYZER.tokenStream( "text" ,  new  StringReader(text));
         tokenStream.reset();
         while  (tokenStream.incrementToken()){
             CharTermAttribute charTermAttribute = tokenStream.getAttribute(CharTermAttribute. class );
             result.append(charTermAttribute.toString()).append( " " );
         }
         tokenStream.close();
     } catch  (Exception e){
         e.printStackTrace();
     }
     return  result.toString();
}

十一、HanLP分詞器

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
private  static  final  Segment N_SHORT_SEGMENT =  new  NShortSegment().enableCustomDictionary( false ).enablePlaceRecognize( true ).enableOrganizationRecognize( true );
private  static  final  Segment DIJKSTRA_SEGMENT =  new  DijkstraSegment().enableCustomDictionary( false ).enablePlaceRecognize( true ).enableOrganizationRecognize( true );
@Override
public  Map<String, String> segMore(String text) {
     Map<String, String> map =  new  HashMap<>();
     map.put( "標準分詞" , standard(text));
     map.put( "NLP分詞" , nlp(text));
     map.put( "索引分詞" , index(text));
     map.put( "N-最短路徑分詞" , nShort(text));
     map.put( "最短路徑分詞" , shortest(text));
     map.put( "極速詞典分詞" , speed(text));
     return  map;
}
private  static  String standard(String text) {
     StringBuilder result =  new  StringBuilder();
     StandardTokenizer.segment(text).forEach(term->result.append(term.word).append( " " ));
     return  result.toString();
}
private  static  String nlp(String text) {
     StringBuilder result =  new  StringBuilder();
     NLPTokenizer.segment(text).forEach(term->result.append(term.word).append( " " ));
     return  result.toString();
}
private  static  String index(String text) {
     StringBuilder result =  new  StringBuilder();
     IndexTokenizer.segment(text).forEach(term->result.append(term.word).append( " " ));
     return  result.toString();
}
private  static  String speed(String text) {
     StringBuilder result =  new  StringBuilder();
     SpeedTokenizer.segment(text).forEach(term->result.append(term.word).append( " " ));
     return  result.toString();
}
private  static  String nShort(String text) {
     StringBuilder result =  new  StringBuilder();
     N_SHORT_SEGMENT.seg(text).forEach(term->result.append(term.word).append( " " ));
     return  result.toString();
}
private  static  String shortest(String text) {
     StringBuilder result =  new  StringBuilder();
     DIJKSTRA_SEGMENT.seg(text).forEach(term->result.append(term.word).append( " " ));
     return  result.toString();
}

如今咱們已經實現了本文的第一個目的：學會使用11大Java開源中文分詞器。

最後咱們來實現本文的第二個目的：對比分析11大Java開源中文分詞器的分詞效果，程序以下：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public  static  Map<String, Set<String>> contrast(String text){
     Map<String, Set<String>> map =  new  LinkedHashMap<>();
     map.put( "word分詞器" ,  new  WordEvaluation().seg(text));
     map.put( "Stanford分詞器" ,  new  StanfordEvaluation().seg(text));
     map.put( "Ansj分詞器" ,  new  AnsjEvaluation().seg(text));
     map.put( "HanLP分詞器" ,  new  HanLPEvaluation().seg(text));
     map.put( "FudanNLP分詞器" ,  new  FudanNLPEvaluation().seg(text));
     map.put( "Jieba分詞器" ,  new  JiebaEvaluation().seg(text));
     map.put( "Jcseg分詞器" ,  new  JcsegEvaluation().seg(text));
     map.put( "MMSeg4j分詞器" ,  new  MMSeg4jEvaluation().seg(text));
     map.put( "IKAnalyzer分詞器" ,  new  IKAnalyzerEvaluation().seg(text));
     map.put( "smartcn分詞器" ,  new  SmartCNEvaluation().seg(text));
     return  map;
}
public  static  Map<String, Map<String, String>> contrastMore(String text){
     Map<String, Map<String, String>> map =  new  LinkedHashMap<>();
     map.put( "word分詞器" ,  new  WordEvaluation().segMore(text));
     map.put( "Stanford分詞器" ,  new  StanfordEvaluation().segMore(text));
     map.put( "Ansj分詞器" ,  new  AnsjEvaluation().segMore(text));
     map.put( "HanLP分詞器" ,  new  HanLPEvaluation().segMore(text));
     map.put( "FudanNLP分詞器" ,  new  FudanNLPEvaluation().segMore(text));
     map.put( "Jieba分詞器" ,  new  JiebaEvaluation().segMore(text));
     map.put( "Jcseg分詞器" ,  new  JcsegEvaluation().segMore(text));
     map.put( "MMSeg4j分詞器" ,  new  MMSeg4jEvaluation().segMore(text));
     map.put( "IKAnalyzer分詞器" ,  new  IKAnalyzerEvaluation().segMore(text));
     map.put( "smartcn分詞器" ,  new  SmartCNEvaluation().segMore(text));
     return  map;
}
public  static  void  show(Map<String, Set<String>> map){
     map.keySet().forEach(k -> {
         System.out.println(k +  " 的分詞結果：" );
         AtomicInteger i =  new  AtomicInteger();
         map.get(k).forEach(v -> {
             System.out.println( "\t"  + i.incrementAndGet() +  " 、"  + v);
         });
     });
}
public  static  void  showMore(Map<String, Map<String, String>> map){
     map.keySet().forEach(k->{
         System.out.println(k +  " 的分詞結果：" );
         AtomicInteger i =  new  AtomicInteger();
         map.get(k).keySet().forEach(a -> {
             System.out.println( "\t"  + i.incrementAndGet()+  " 、【"    + a +  "】\t"  + map.get(k).get(a));
         });
     });
}
public  static  void  main(String[] args) {
     show(contrast( "我愛楚離陌" ));
     showMore(contrastMore( "我愛楚離陌" ));
}

運行結果以下：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
********************************************
word分詞器 的分詞結果：
     1  、我 愛 楚離陌 
Stanford分詞器 的分詞結果：
     1  、我 愛 楚 離陌 
     2  、我 愛 楚離陌 
Ansj分詞器 的分詞結果：
     1  、我 愛 楚離 陌 
     2  、我 愛 楚 離 陌 
HanLP分詞器 的分詞結果：
     1  、我 愛 楚 離 陌 
smartcn分詞器 的分詞結果：
     1  、我 愛 楚 離 陌 
FudanNLP分詞器 的分詞結果：
     1  、我 愛楚離陌
Jieba分詞器 的分詞結果：
     1  、我愛楚 離 陌 
Jcseg分詞器 的分詞結果：
     1  、我 愛 楚 離 陌 
MMSeg4j分詞器 的分詞結果：
     1  、我愛 楚 離 陌 
IKAnalyzer分詞器 的分詞結果：
     1  、我 愛 楚 離 陌 
********************************************
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
********************************************
word分詞器 的分詞結果：
     1  、【全切分算法】 我 愛 楚離陌 
     2  、【雙向最大最小匹配算法】    我 愛 楚離陌 
     3  、【正向最大匹配算法】  我 愛 楚離陌 
     4  、【雙向最大匹配算法】  我 愛 楚離陌 
     5  、【逆向最大匹配算法】  我 愛 楚離陌 
     6  、【正向最小匹配算法】  我 愛 楚離陌 
     7  、【雙向最小匹配算法】  我 愛 楚離陌 
     8  、【逆向最小匹配算法】  我 愛 楚離陌 
Stanford分詞器 的分詞結果：
     1  、【Stanford Chinese Treebank segmentation】 我 愛 楚離陌 
     2  、【Stanford Beijing University segmentation】   我 愛 楚 離陌 
Ansj分詞器 的分詞結果：
     1  、【BaseAnalysis】  我 愛 楚 離 陌 
     2  、【IndexAnalysis】 我 愛 楚 離 陌 
     3  、【ToAnalysis】    我 愛 楚 離 陌 
     4  、【NlpAnalysis】   我 愛 楚離 陌 
HanLP分詞器 的分詞結果：
     1  、【NLP分詞】 我 愛 楚 離 陌 
     2  、【標準分詞】  我 愛 楚 離 陌 
     3  、【N-最短路徑分詞】  我 愛 楚 離 陌 
     4  、【索引分詞】  我 愛 楚 離 陌 
     5  、【最短路徑分詞】    我 愛 楚 離 陌 
     6  、【極速詞典分詞】    我 愛 楚 離 陌 
smartcn分詞器 的分詞結果：
     1  、【smartcn】   我 愛 楚 離 陌 
FudanNLP分詞器 的分詞結果：
     1  、【FudanNLP】  我 愛楚離陌
Jieba分詞器 的分詞結果：
     1  、【SEARCH】    我愛楚 離 陌 
     2  、【INDEX】 我愛楚 離 陌 
Jcseg分詞器 的分詞結果：
     1  、【簡易模式】  我 愛 楚 離 陌 
     2  、【複雜模式】  我 愛 楚 離 陌 
MMSeg4j分詞器 的分詞結果：
     1  、【SimpleSeg】 我愛 楚 離 陌 
     2  、【ComplexSeg】    我愛 楚 離 陌 
     3  、【MaxWordSeg】    我愛 楚 離 陌 
IKAnalyzer分詞器 的分詞結果：
     1  、【智能切分】  我 愛 楚 離 陌 
     2  、【細粒度切分】 我 愛 楚 離 陌 
********************************************

 

 

 

 


作中文搜索,關鍵詞提取,文檔分類都離不開中文分詞,能用的代碼包有以下

    • 單字切分 sphinx只要把min_word_len設置爲1,並配置charset_table,默認就是單字切分,lucene用StandardAnalyzer

    • CJKAnalyzer lucene自帶,兩兩分詞,就是把 ABCD 分紅 AB,BC,CD 3段

    • PaodingAnalyzer 開源,能夠用於lucene http://code.google.com/p/paoding/

    • sphinx-for-chinese 基於詞頻字典,sphinx中文分詞專屬插件,http://www.sphinx-search.com

    • MMseg 基於詞典+最大匹配+歧義消除,sphinx和lucence都能用,(sphinx能夠直接使用coreseek.com的版本)MMseg還有 python,ruby,php,java等各類語言的開發包

    • smallseg 很輕量級的python庫,只能單獨使用不能集成到(lucene或者sphinx)當中

    • jieba 另外一個python分詞庫 https://github.com/fxsjy/jieba

    • ICTCLAS 中科院的分詞算法,sphinx和lucene都能用,可是使用比較麻煩,還分商業版和免費版

 

 

 

 

 

中文分詞與搜索引擎

 

 

看到題目就知道我要說什麼了，這個話題好像已經被討論過n次了，看雅虎搜索blog上在06年就有過專題系列文章，地址爲： http://ysearchblog.cn/2006/07/post_16.html，文中詳細的介紹了有關中文分詞的意義，算法，跟搜索引擎的關係等等。我的認爲文章質量很是不錯。其實我所寫的也不外乎這些東西，可我爲何還要寫呢？是由於我花了將近一週的時間來理解中文分詞，收集有關資料，爲了避免讓努力白費，我仍是總結一下吧。

一．爲何要中文分詞？

對啊，爲什麼要分詞，不分詞行不行？要討論這個話題，首先須要瞭解一下搜索引擎的原理。搜索引擎的爲何能快速檢索到本身查詢的關鍵字呢？實際上這得 益於他的數據存儲機制-----倒排索引。這裏用一個例子來大致說明什麼是倒排索引（之因此說大致，是由於我也沒有深刻的瞭解）。假設我有10篇文章，他 們可能論述了相同或不一樣的主題。若是我想看看哪篇文中含有「中文分詞」這個詞語，我能夠這麼幹：循環遍歷每一篇文章，看看他的內容中有沒有含有「中文分 詞」這個詞語，而後把含有目標詞語的文章返回。很顯然，我須要打開10篇文章，而且從頭至尾的遍歷每篇文章，看能不能匹配到「中文分詞」，這樣的效率是很 低的，對於毫秒級的搜索引擎來講是絕對不能接受的。因此我要給每篇文章作個「目錄」！不是你想查詢「中文分詞」嗎？好，我事先找到含有「中文分詞」的文 章。假設文章1,3,5，7含有這個詞語，文章2,4,6,7含有「搜索引擎」，好，我創建一個對應關係表「中文分詞——>1,3,5,7」,「搜 索引擎——>2,4,6,7」，因而當你要檢索「中文分詞」這個詞語的時候，我再也不打開每篇文章去匹配，而是直接到對應關係表去看一下「中文分詞」 對應着文章1,3,5,7，好，結果出來了，文章1,3,5,7含有「中文分詞」這個詞語，一樣檢索「搜索引擎」，返回的結果是2,4,6,7。那我要同 時檢索「中文分詞」和「搜索引擎」呢？那就是（1,3,5,7）跟（2,4,6,7）取交集！結果是文章7同 時含有「中文分詞」，「搜索引擎」。那我搜其餘的詞語呢？那就把其餘詞語也放到這個對應表中。這個「對應關係表」其實就是所謂的倒排索引，固然，倒排索引 可能含有的信息更爲豐富，好比不只包含了詞語在哪一篇文章，同時還包含了在這篇文章的哪一個位置等等。很顯然，咱們須要把全部文章創建一個倒排索引。問題來 了，計算機怎麼認識哪一個是詞語呢？他並不知道「中文分詞」就是一個詞語。沒有詞語，怎麼創建索引呢？因而，咱們須要中文分詞！而且分詞發生在用戶查詢和服 務器創建索引時。

二．什麼樣的中文分詞適合搜索引擎

由於中文的每一個句子是連續的字的序列，詞語跟詞語直接沒有明顯的分隔（英文的單詞之間用格隔開），因而分詞看起來變得困難了許多。取一個最極端的方式，每個字做爲一個詞，即所謂的1元分詞。好比「山東經濟學院」，分爲「山_東_經_濟_學_院」，而後創建倒排索引：

山——>1,3

東——>2,3

經——>3,4

濟——>3,5,4

院——>3,5,6

因而，當我搜索「山東經濟學院」時，在倒排索引中查找每個字，而後取其交集，獲得的結果是3，文章3中 含有「山東經濟學院」這個詞。這看起來很完美，徹底解決了分詞的問題併成功的創建了倒排索引。顯然，博大精深的漢語不可能讓問題就這麼簡單！若是我按照一 元分詞對「主板和服務器」，創建倒排索引，當我想要檢索日本的「和服」時。出來的結果倒是「主板和服務器」八竿子打不着的結果。難免讓人云裏霧裏心頭不 爽！除了檢索質量，還有一個問題就是檢索效率，對「山東經濟學院」我須要查詢到6條目錄，而後取交集。這性能又下降了，對於毫秒級的搜索引擎，這怎麼能忍 呢。若是「山東經濟學院」就是一個詞，創建索引「山東經濟學院——>3」我豈不是一會兒就查到了，也不用作什麼交集運算。因此1元分詞顯然不能知足 人們的要求。相似的還有2元分詞，2元交叉分詞，好比「主板和服務器」，2元分詞爲：「主板_和服_務器」，2元交叉分詞爲「主板_板和_和服_服務_務 器，很顯然，這兩種分詞結果除了提升了一下檢索效率外，對搜索體驗卻沒什麼大的改善，總會讓我在查找「和服」時找到一堆關於電腦的東西。

       那 上面提到的「山東經濟學院」做爲一個詞的策略是否完美呢？這裏就體現出搜索引擎的中文分詞跟其餘專業領域的中文分詞的不一樣來，若是是機器翻譯，很顯然「山 東經濟學院」是一個專有名詞，不可分割。可是對於搜索引擎，我但願當我查詢「經濟學院」時也能查到山東經濟學院，這樣的話「山東經濟學院」又不能做爲一個 詞了。

       因此，搜索引擎的分詞應該控制合理的粒度！

       問題是，怎樣纔算合適的粒度？我認爲是能表達完整意義的最小詞語，有些拗口，解釋一下：「山東經濟學院」，能夠分爲「山東_經濟學院」或「山東_經濟_學 院」，我傾向的是後者，由於「經濟學院」是能夠再分的：「經濟_學院」。「經濟」和「學院」都是能夠理解的能表達完整意義的詞語，而且不可再分。這樣便保 證了查全率：「經濟學院」，「山東_學院」都能檢索到這條結果。至於搜索的滿意程度就須要作相關度排序，跟搜索詞語越相關的排在前面，好比搜索「山東經 濟」，一篇關於闡述山東經濟發展的文章應該在比較靠前的位置，而關於山東經濟學院的文章則應排在後面。

三．中文分詞算法

中文分詞有三種大相徑庭的分詞方法，每一種方法都對應了一種研究領域。

1．  基於詞典的分詞

2．  基於統計的分詞

3．  基於語法的分詞

我所瞭解的，及當前搜索引擎廣爲採用的是第一種分詞方法，有一個包含了不少詞語的詞典，你拿着一句話挨着到詞典裏去匹配，匹配上就算一個詞。好比 「山東經濟學院」，首先匹配「山」，詞典裏有，OK， 算一個詞，「山東」，詞典裏也有，那也是一個詞，假設「山東經濟」也包含在詞典裏呢？那我同時匹配到「山」，「山東」，「山東經濟」三個詞語，我該選擇哪 個呢？爲了解決這個問題，人們便制定了一些規則：選擇長度最大的那個詞語，由於實踐證實這每每是正確的（固然，不是絕對正確）。根據這個規則演變的算法有 正向最大匹配，逆向最大匹配，MMSEG算法等。上述各類算法都不是完美的，總會有分錯的時候，咱們只是指望儘量的正確（其實，對於搜索引擎，有時候分 詞不正確也並不影響檢索效果）。

       下面以「研究生命起源」這句話爲例講述一下上述三種算法的分詞狀況：

首先，咱們須要一個詞典，詞典裏含有這麼幾個詞:

研究

研究生

生命

起源

1．  正向最大匹配

顧名思義，方向爲從前日後正向匹配。

 

首先，拿到第一個詞「研」，查詢詞典，沒有，前進一步，拿到「研究」，查詢詞典，獲得詞語：「研 究」，並不罷休，繼續拿到「研究生」，查詢詞典，獲得詞語：「研究生」，仍不罷休，拿到「研究生命」，查詢詞典，沒有，繼續下去，一直打到你認爲合理的長 度，好比你以爲一個詞語不可能超過5個字，你拿到「研究生命起」，查詢詞典後，沒有結果，就不在繼續下去了。如今對查詢結果進行選擇，很顯然長度最大的爲 「研究生」，至此，咱們肯定了第一個詞「研究生」。

 

而後，從下一個詞開始，依次拿到「命」，「命起」，「命起源」，到詞典查詢，都沒有結果，因而把「命」這個字做爲一個詞。

 

再次，從下一個詞開始，依次拿到「起」，「起源」，到詞典查詢，獲得「起源」。

 

至此分詞完成，獲得結果「研究生_命_起源」，很明顯分錯了~。

2．  逆向最大匹配

基本上仍是上面的過程，不過「研究生命起源」這句話要到這來

首先，依次拿到「源」，「起源」，「命起源」，「生命起源」，「究生命起源」到詞典匹配，獲得結果「起源」。

而後，依次拿到「命」，「生命」，「究生命」，「研究生命」，到詞典查詢，獲得結果「生命」。

再次，依次拿到「究」，「研究」，查詢詞典，獲得結果「研究」

 

至此，分詞完成，獲得結果「研究_生命_起源」，分詞正確。

 

整體說來，廣泛認爲逆向最大匹配的正確率要高於正向最大匹配。

3．  MMSEG算法

MMSEG算法相對上面兩種算法來講比較複雜，由於其正確率比較高因此被廣泛採用，由於有各類語言的實現，好比python的pymmseg ,java 的mmseg4j, c/c++的libmmseg等，

網上關於這個算法有不少介紹，爲了偷懶，我在這裏就不贅述，想了解的同窗請google之。

四．中文分詞面臨的問題

當前中文分詞主要面臨兩個問題：

1．  歧義消解

2．  新詞發現

關於歧義消解：

好比「研究生命」，是應該分爲「研究_生命」仍是「研究生_命」，這是關於「生」的歸屬問題，「生」能夠跟「研究」一塊兒，變成「研究生」，也能夠跟 「命」一塊兒，變成「生命」。「研究生」跟「生命」有一個交集「命」，這即是交叉型歧義。另外一個例子「中國人」，能夠分爲「中國_人」，也能夠「中國人」整 個是一個詞。即「中國」和「人」的不一樣組合形成了歧義，這即是組合型歧義

上述各類算法無非就是對這兩種歧義的消解。

按照我在第二條提到的觀點，搜索引擎分詞的粒度應該是：能表達完整意義的最小詞語。因此應該不會出現組合型歧義，重點應該放到解決「交叉型歧義」的問題上。

歧義的消解應該針對特殊狀況作出合理的調整。能夠結合不一樣的分詞方法，好比語法分析，統計等。

舉例來講：「武夷山路」，詞典中含有「武夷」，「山路」兩個詞的時候，MMSEG算法和逆向最大匹配會分詞爲：「武夷_山 路」，當用戶輸入「武夷山路」時，無論分詞正確與否，都能正確匹配到正確的結果。可是，在這個城市裏生活的人們，可能想經過「武夷山」就能檢索到武夷山路 （由於你們都知道這個城市裏沒有武夷山，輸入「武夷山」，默認想獲得的結果就是關於武夷山路的）。如今來看分詞爲何錯誤了呢？由於詞典裏存在「山路」這 個詞！是「路」這個僅僅起後綴做用的字干擾了分詞，因此我認爲這樣的後綴詞，不該該參與分詞，相似的還有「省，市，縣，鎮」等。

關於新詞發現：

由於精力有限，目前還不瞭解這個領域的狀況，大致能夠經過對用戶搜索日誌進行數據挖掘得出。

五．總結

1．  搜索引擎須要中文分詞，分詞的對象爲要創建索引的文檔和用戶提交的查詢詞，而且二者對同一段語句的分詞結果必須一致。

2．  分詞粒度應該控制爲：能表達完整意義的最小詞語。這樣便避免了組合型歧義。

3．  對於消解歧義應該根據具體狀況調整，適當綜合利用各類分詞方法。

4．  若是用戶查詢詞跟創建索引時分詞結果一致，就算分詞錯誤，也能檢索到，因此有人認爲當分詞正確率達到必定值時，正確率對搜索質量的影響便不會那麼明顯了。所以不必一味的追求正確率。

六．參考資料

1．  中文分詞和搜索引擎（一）

2．  中文分詞和搜索引擎（二）

3．  中文分詞和搜索引擎（三）

4．  搜索引擎之中文分詞(Chinese Word Segmentation)簡介

5．  Google

 

 

 

 

當前幾個主要的Lucene中文分詞器的比較

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 編碼， 分割。不支持自動檢測。

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 中選一個。關於這兩個分詞效果的對比，能夠參考：

http://blog.chenlb.com/2009/04/mmseg4j-max-word-segment-compare-with-paoding-in-effect.html

或者本身再包裝一下，將 paoding 的詞庫更新檢測作一個單獨的模塊實現，而後就能夠在全部基於詞庫的分詞算法之間無縫切換了。

ps，對不一樣的 field 使用不一樣的分詞器是一個能夠考慮的方法。好比 tag 字段，就應該使用一個最簡單的分詞器，按空格分詞就能夠了。

本文來自：http://blog.fulin.org/2009/08/lucene_chinese_analyzer_compare.html

 

 

 

 

 

深刻淺出Hadoop Mahout數據挖掘實戰(算法分析、項目實戰、中文分詞技術) 

Mahout簡介

Mahout 是 Apache Software Foundation（ASF） 旗下的一個開源項目，

提供一些可擴展的機器學習領域經典算法的實現，旨在幫助開發人員更加方便快捷地建立智能應用程序

Mahout相關資源

Mahout主頁:http://mahout.apache.org/

Mahout 最新版本0.8下載: http://mirrors.hust.edu.cn/apache/mahout/0.8/ 

使用mahout-distribution-0.8.tar.gz可試跑，源碼在mahout-distribution-0.8-src.tar.gz中

Mahout 簡要安裝步驟:

如無需修改源代碼，只是試用試跑，請無需安裝maven(網上許多教程會有這個彎路，請跳過)，具體能夠參考如下教程

http://www.hadoopor.com/thread-983-1-1.html

若是須要能修改源代碼並從新編譯打包，須要安裝maven，請參考以下圖文教程：http://wenku.baidu.com/view/dbd15bd276a20029bd642d55.html

Mahout 專業教程 ： Mahout in action http://yunpan.taobao.com/share/link/R56BdLH5O

注： 出版時間2012年， 對應mahout版本0.5， 是目前mahout最新的書籍讀物。目前只有英文版，可是翻了一下，裏面詞彙基本都是計算機基礎詞彙，且配圖和源代碼，是適合閱讀的。

IBM mahout簡介: http://www.ibm.com/developerworks/cn/java/j-mahout/

注：中文版， 更新是時間爲09年，可是裏面對於mahout闡述較全面，推薦閱讀，特別是最後的書籍清單，適合深刻了解

 

 

課程介紹

本課程主要涉及如下內容的講解：

一、Mahout數據挖掘工具 

二、Hadoop實現推薦系統的綜合實戰，涉及到MapReduce、Pig和Mahout的綜合實戰

課程針對人羣

一、本課程適合於有必定java基礎知識，對數據庫和sql語句有必定了解，熟練使用linux系統的技術人員，特別適合於想換工做或尋求高薪職業的人士

二、最好有Greenplum Hadoop、Hadoop2.0、YARN、Sqoop、FlumeAvro、 Mahout等大數據基礎，學習過北風課程《Greenplum 分佈式數據庫開發入門到精通》、《全面深刻Greenplum Hadoop大數據分析平臺》、《Hadoop2.0、YARN深刻淺出》、《MapReduce、Hbase進階提高》、《MapReduce、Hbase進階提高》爲最佳。

 

 

 

課程大綱

Mahout數據挖掘工具（10課時）

數據挖掘概念、系統組成

數據挖掘經常使用方法及算法（迴歸分析、分類、聚類等）

數據挖掘分析工具

Mahout支持的算法

Mahout起源和特色

Mahout安裝、配置及測試

實戰：Mahout K-means聚類分析

Mahout實現Canopy算法

Mahout實現分類算法

實戰：Mahout邏輯迴歸分類預測

實戰：Mahout樸素貝葉斯分類

推薦系統的概念及分類

協同過濾推薦算法概念、分類及應用

實戰：實現基於Mahout的電影推薦系統

Hadoop綜合實戰-文本挖掘項目（7課時）

文本挖掘的概念及應用場景

項目背景

項目流程

中文分詞技術

庖丁分詞器的使用

MapReduce並行分詞程序的設計與實現

Pig劃分數據集

Mahout構建樸素貝葉斯文本分類器

模型應用-計算用戶偏好類別

 

 

 

 

 

分詞技術

 
 

 

目錄(?)[+]

咱們要理解分詞技術先要理解一個概念。那就是查詢處理，當用戶向搜索引擎提交查詢後，搜索引擎接收到用戶的信息要作一系列的處理。步驟以下所示：

1.首先是到數據庫裏面索引相關的信息，這就是查詢處理。

那麼查詢處理又是如何工做的呢？很簡單，把用戶提交的字符串沒有超過3個的中文字，就會直接到數據庫索引詞彙。超過4箇中文字的，首先用分隔符好比空格，標點符號，將查詢串分割成若干子查詢串。

舉個例子。「什麼是百度分詞技術」 咱們就會把這個詞分割成「 什麼是，百度，分詞技術。」這種分詞方法叫作反向匹配法。

2.而後再看用戶提供的這個詞有沒有重複詞彙

若是有的話，會丟棄掉，默認爲一個詞彙。接下來檢查用戶提交的字符串，有沒有字母和數字。若是有的話，就把字母和數字認爲一個詞。

這就是搜索引擎的查詢處理。

分詞的原理:

百度是如何來分詞的呢？分詞技術現今很是成熟了。分爲3種技術。

字符串匹配的分詞方法

這是種經常使用的分詞法，百度就是用此類分詞。字符串匹配的分詞方法，又分爲3種分詞方法。

（1）.正向最大匹配法

就是把一個詞從左至右來分詞。

舉個例子：」不知道你在說什麼」

這句話採用正向最大匹配法是如何分的呢？「不知道，你，在，說什麼」。

（2）.反向最大匹配法

"不知道你在說什麼"反向最大匹配法來分上面這段是如何分的。「不，知道，你在，說，什麼」，這個就分的比較多了，反向最大匹配法就是從右至左。

（3）.就是最短路徑分詞法。

就是說一段話裏面要求切出的詞數是最少的。

「不知道你在說什麼」最短路徑分詞法就是指，把上面那句話分紅的詞要是最少的。「不知道，你在，說什麼」，這就是最短路徑分詞法，分出來就只有3個詞了。

（4）.雙向最大匹配法。

而有一種特殊的狀況，就是關鍵詞先後組合內容被認爲粘性相差不大，而搜索結果中也同時包含這兩組詞的話，百度會進行正反向同時進行分詞匹配。

詞義分詞法

就是一種機器語音判斷的分詞方法。很簡單，進行句法、語義分析，利用句法信息和語義信息來處理歧義現象來分詞，這種分詞方法，還不成熟，處在測試階段。

統計分詞法

根據詞組的統計，就會發現兩個相鄰的字出現的頻率最多，那麼這個詞就很重要。就能夠做爲用戶提供字符串中的分隔符，這樣來分詞。

好比，「個人，你的，許多的，這裏，這一，那裏」等等，這些詞出現的比較多，就從這些詞裏面分開來。

 

 

搜索引擎中文分詞技術

　　因爲不少朋友要求寫一篇搜索引擎分詞技術的文章，特別是關於百度分詞的。我今天就發發給你們

　　Moon 10月9號在SEOWHY週四答疑羣給講解的分詞技術今天給你們帖出來供你們學習一下。

　　分詞技術 : 什麼是分詞, 如何分詞搜索引擎會認可,此次第一位朋友提的問題，想必你們也據說過，很好奇，什麼是分詞技術，什麼又是百度分詞呢?分詞你們容易理解。就是一段詞用字符分開，好比標點符號，空格等。

　　那什麼叫分詞技術呢?分詞技術就是SE針對用戶提交查詢的關鍵串進行的查詢處理後根據用戶的關鍵詞串用各類匹配方法進行的一種技術。你們好好理 解。那麼咱們要理解分詞技術先要理解一個概念。那就是查詢處理，當用戶向搜索引擎提交查詢後，搜索隱藏接收到用戶的信息要作一系列的處理。首先是到數據庫 裏面索引相關的信息，

　　這就是查詢處理，那麼查詢處理又是如何工做的呢?很簡單，把用戶提交的字符串沒有超過3個的中文字，就會直接到數據庫索引詞彙。超過4箇中文字 的，首先用分隔符好比空格，標點符號，將查詢串分割成若干子查詢串。舉個例子。「什麼是百度分詞技術」 咱們就會把這個詞分割成「 什麼是，百度，分詞技術。」這種分詞方法叫作反向匹配法。2.而後再看用戶提供的這個詞有沒有重複詞彙。

　　若是有的話，會丟棄掉，默認爲一個詞彙。接下來檢查用戶提交的字符串，有沒有字母和數字。若是有的話，就把字母和數字認爲一個詞。好了，這就是SE的查詢處理。

　　講了查詢處理後，你們對分詞技術，尤爲是中文分詞技術有了一個基本的瞭解。

　　其實我講的都是搜索引擎的原理。好了，我接下來說分詞的原理。咱們用百度來舉例

　　百度是如何來分詞的呢?分詞技術現今很是成熟了。他分爲3種技術。

　　1.字符串匹配的分詞方法

　　2.詞義分詞法。

　　3.統計分此法。

　　先說第一種。

　　也是經常使用的分詞法，百度就是用此種分詞。字符串匹配的分詞方法，他又分爲3中分詞方法。

　　1.正向最大匹配法

　　什麼意思呢?就是把一個詞從左至右來分詞。

　　舉個例子。

　　「不知道你在說什麼」

　　這句話採用正向最大匹配法是如何分的呢?「不知道，你，在，說什麼」與正向最大匹配法相對應的是反向最大匹配發。這是第二種分詞方法。

　　2.反向最大匹配法 來分上面我舉的例子是如何分的呢 "不知道你在說什麼"。反向最大匹配法來分上面這段是如何分的。「不，知道，你在，說，什麼」，這個就分的比較多了，反向最大匹配法就是從右至左。

　　3.就是最短路徑分詞法。

　　這個什麼理解呢 ，就是說 我一段話裏面要求切出的詞數是最少的。仍是上面哪句話

　　「不知道你在說什麼」最短路徑分詞法就是指，我把上面哪句話分紅的詞要是最少的。不知道，你在，說什麼，這就是最短路徑分詞法，分出來就只有3 個詞了 。好了，固然還有上面三種能夠相互結合組成一些分詞方法。好比正向最大匹配法和反向最大匹配法組合起來就能夠叫作雙向最大匹配法。好了，第一種說完了，

　　2.詞義分詞法。

　　這種其實就是一種機器語音判斷的分詞

　　方法。很簡單，進行句法、語義分析，利用句法信息和語義信息來處理歧義現象來分詞，這種分詞方法，如今還不成熟。處在測試階段。

　　第三種，統計的分詞方法。

　　這個很簡單，就是根據詞組的統計，就會發現兩個相鄰的字出現的頻率最多，那麼這個詞就很重要。就能夠做爲用戶提供字符串中的分隔符。這樣來分 詞。好比，「個人,你的，許多的，這裏，這一，那裏」。等等，這些詞出現的比較多，就從這些詞裏面分開來。好了，分詞技術講完了。

　　那麼咱們剛剛學了分詞技術，又如何來運用他們爲咱們的站點得到流量呢

　　1.咱們能夠利用分詞技術來增長咱們站點長尾詞。這樣就能夠獲取流量排名。

　　不但這些分出來的長尾詞可以獲取必定的排名，也可以推進站點的目標關鍵詞獲取很好的排名。這個原理就是內鏈原理，這裏再也不講了。講了這麼多，咱們舉個例子。

　　例如：三亞酒店預約，如何來分呢?

　　正向最大匹配，反向最大匹配，雙向最大匹配，最短連接匹配。

　　1.正向最大匹配

　　「三亞，酒店預約」

　　2.反向最大匹配

　　「三亞酒店，預約」

　　3.雙向最大匹配

　　「三亞，酒店，預約」

　　4.最短路徑最大匹配。

　　「三亞酒店預約」好了，咱們分了詞爲

　　「三亞，「酒店預約，預約，三亞酒店，三亞，酒店 ，三亞酒店預約。」

　　這些詞每一個均可以作一個主題頁爲目標關鍵詞

　　這些分出來的詞，把他們都做爲你站點的主題頁，導入連接權重上來了，競爭力就大了，由於這些頁面把他內鏈起來。用錨連接，指向主頁的目標關鍵 詞。呵呵，這就是分詞的好處。他可以提高目標關鍵詞的排名的競爭力也同時給站點帶來必定流量。一旦導入連接權重上來了，競爭力就大了，由於這些頁面把他內 鏈起來。

　　用錨連接，指向主頁的目標關鍵詞。呵呵，這就是分詞的好處。他可以提高目標關鍵詞的排名的競爭力也同時給站點帶來必定流量。分詞還有一種好處。 那就是提高內頁的排名。好的，這個我就不詳細講了。由於我在SEOWHY已經寫了一篇文章。你們能夠去看一下。就是關於百度，捕獲描述的文章。若是你的內 頁不作描述，那麼百度就會給你定義一個描述或者從你的頁面捕獲一個描述。在捕獲描述的時候，若是你的知道他會捕獲哪一段，那麼你說，你的排名會不會上升。 你就刻意寫哪一段。

　　我寫的那篇文章地址以下。你們能夠去看一下。

　　http://www.seowhy.com/bbs/thread-4451-1-1.html

 

搜索引擎技術揭密：中文分詞技術

　　信息的飛速增加，使搜索引擎成爲人們查找信息的首選工具，Google、百度、中國搜索等大型搜索引擎 一直是人們討論的話題。隨着搜索市場價值的不斷增長，愈來愈多的公司開發出本身的搜索引擎，阿里巴巴的商機搜索、8848的購物搜索等也陸續面世，天然， 搜索引擎技術也成爲技術人員關注的熱點。

　　搜索引擎技術的研究，國外比中國要早近十年，從最先的Archie，到後來的Excite，以 及altvista、overture、google等搜索引擎面世，搜索引擎發展至今，已經有十幾年的歷史，而國內開始研究搜索引擎是在上世紀末本世紀 初。在許多領域，都是國外的產品和技術一統天下，特別是當某種技術在國外研究多年而國內纔開始的狀況下。例如操做系統、字處理軟件、瀏覽器等等，但搜索引 擎倒是個例外。雖然在國外搜索引擎技術早就開始研究，但在國內仍是陸續涌現出優秀的搜索引擎，像百度（http://www.baidu.com）等。目前在中文搜索引擎領域，國內的搜索引擎已經和國外的搜索引擎效果上相差不遠。之因此能造成這樣的局面，有一個重要的緣由就在於中文和英文兩種語言自身的書寫方式不一樣，這其中對於計算機涉及的技術就是中文分詞。

　　什麼是中文分詞

　 　衆所周知，英文是以詞爲單位的，詞和詞之間是靠空格隔開，而中文是以字爲單位，句子中全部的字連起來才能描述一個意思。例如，英文句子I am a student，用中文則爲：「我是一個學生」。計算機能夠很簡單經過空格知道student是一個單詞，可是不能很容易明白「學」、「生」兩個字合起來 才表示一個詞。把中文的漢字序列切分紅有意義的詞，就是中文分詞，有些人也稱爲切詞。我是一個學生，分詞的結果是：我 是 一個 學生。

　　中文分詞和搜索引擎

　 　中文分詞到底對搜索引擎有多大影響？對於搜索引擎來講，最重要的並非找到全部結果，由於在上百億的網頁中找到全部結果沒有太多的意義，沒有人能看得 完，最重要的是把最相關的結果排在最前面，這也稱爲相關度排序。中文分詞的準確與否，經常直接影響到對搜索結果的相關度排序。筆者最近替朋友找一些關於日 本和服的資料，在搜索引擎上輸入「和服」，獲得的結果就發現了不少問題。下面就以這個例子來講明分詞對搜索結果的影響，在現有三個中文搜索引擎上作測試， 測試方法是直接在Google（http://www.google.com）、百度（http://www.baidu.com）上以「和服」爲關鍵詞進行搜索：

　　在Google上輸入「和服」搜索全部中文簡體網頁，總共結果507,000條，前20條結果中有14條與和服一點關係都沒有。

　　在百度上輸入「和服」搜索網頁，總共結果爲287,000條，前20條結果中有6條與和服一點關係都沒有。

　　在中搜上輸入「和服」搜索網頁，總共結果爲26,917條，前20條結果都是與和服相關的網頁。

　　此次搜索引擎結果中的錯誤，就是因爲分詞的不許確所形成的。經過筆者的瞭解，Google的中文分詞技術採用的是美國一家名叫Basis Technology（http://www.basistech.com）的公司提供的中文分詞技術，百度使用的是本身公司開發的分詞技術，中搜使用的是國內海量科技（http://www.hylanda.com）提供的分詞技術。因而可知，中文分詞的準確度，對搜索引擎結果相關性和準確性有至關大的關係。

　　中文分詞技術

　　中文分詞技術屬於天然語言處理技術範疇，對於一句話，人能夠經過本身的知識來明白哪些是詞，哪些不是詞，但如何讓計算機也能理解？其處理過程就是分詞算法。

　　現有的分詞算法可分爲三大類：基於字符串匹配的分詞方法、基於理解的分詞方法和基於統計的分詞方法。

　　一、基於字符串匹配的分詞方法

　 　這種方法又叫作機械分詞方法，它是按照必定的策略將待分析的漢字串與一個「充分大的」機器詞典中的詞條進行配，若在詞典中找到某個字符串，則匹配成功 （識別出一個詞）。按照掃描方向的不一樣，串匹配分詞方法能夠分爲正向匹配和逆向匹配；按照不一樣長度優先匹配的狀況，能夠分爲最大（最長）匹配和最小（最 短）匹配；按照是否與詞性標註過程相結合，又能夠分爲單純分詞方法和分詞與標註相結合的一體化方法。經常使用的幾種機械分詞方法以下：

　　1）正向最大匹配法（由左到右的方向）；

　　2）逆向最大匹配法（由右到左的方向）；

　　3）最少切分（使每一句中切出的詞數最小）。

　 　還能夠將上述各類方法相互組合，例如，能夠將正向最大匹配方法和逆向最大匹配方法結合起來構成雙向匹配法。因爲漢語單字成詞的特色，正向最小匹配和逆向 最小匹配通常不多使用。通常說來，逆向匹配的切分精度略高於正向匹配，遇到的歧義現象也較少。統計結果代表，單純使用正向最大匹配的錯誤率爲1/169， 單純使用逆向最大匹配的錯誤率爲1/245。但這種精度還遠遠不能知足實際的須要。實際使用的分詞系統，都是把機械分詞做爲一種初分手段，還需經過利用各 種其它的語言信息來進一步提升切分的準確率。

　　一種方法是改進掃描方式，稱爲特徵掃描或標誌切分，優先在待分析字符串中識別和切分出一些 帶有明顯特徵的詞，以這些詞做爲斷點，可將原字符串分爲較小的串再來進機械分詞，從而減小匹配的錯誤率。另外一種方法是將分詞和詞類標註結合起來，利用豐富 的詞類信息對分詞決策提供幫助，而且在標註過程當中又反過來對分詞結果進行檢驗、調整，從而極大地提升切分的準確率。

　　對於機械分詞方法，能夠創建一個通常的模型，在這方面有專業的學術論文，這裏不作詳細論述。

　　二、基於理解的分詞方法

　 　這種分詞方法是經過讓計算機模擬人對句子的理解，達到識別詞的效果。其基本思想就是在分詞的同時進行句法、語義分析，利用句法信息和語義信息來處理歧義 現象。它一般包括三個部分：分詞子系統、句法語義子系統、總控部分。在總控部分的協調下，分詞子系統能夠得到有關詞、句子等的句法和語義信息來對分詞歧義 進行判斷，即它模擬了人對句子的理解過程。這種分詞方法須要使用大量的語言知識和信息。因爲漢語語言知識的籠統、複雜性，難以將各類語言信息組織成機器可 直接讀取的形式，所以目前基於理解的分詞系統還處在試驗階段。

　　三、基於統計的分詞方法

　　從形式上看，詞是穩定的字的組 合，所以在上下文中，相鄰的字同時出現的次數越多，就越有可能構成一個詞。所以字與字相鄰共現的頻率或機率可以較好的反映成詞的可信度。能夠對語料中相鄰 共現的各個字的組合的頻度進行統計，計算它們的互現信息。定義兩個字的互現信息，計算兩個漢字X、Y的相鄰共現機率。互現信息體現了漢字之間結合關係的緊 密程度。當緊密程度高於某一個閾值時，即可認爲此字組可能構成了一個詞。這種方法只需對語料中的字組頻度進行統計，不須要切分詞典，於是又叫作無詞典分詞 法或統計取詞方法。但這種方法也有必定的侷限性，會常常抽出一些共現頻度高、但並非詞的經常使用字組，例如「這一」、「之一」、「有的」、「個人」、「許多 的」等，而且對經常使用詞的識別精度差，時空開銷大。實際應用的統計分詞系統都要使用一部基本的分詞詞典（經常使用詞詞典）進行串匹配分詞，同時使用統計方法識別 一些新的詞，即將串頻統計和串匹配結合起來，既發揮匹配分詞切分速度快、效率高的特色，又利用了無詞典分詞結合上下文識別生詞、自動消除歧義的優勢。

　 　到底哪一種分詞算法的準確度更高，目前並沒有定論。對於任何一個成熟的分詞系統來講，不可能單獨依靠某一種算法來實現，都須要綜合不一樣的算法。筆者瞭解，海 量科技的分詞算法就採用「複方分詞法」，所謂複方，至關於用中藥中的複方概念，即用不一樣的藥才綜合起來去醫治疾病，一樣，對於中文詞的識別，須要多種算法 來處理不一樣的問題。

　　分詞中的難題

　　有了成熟的分詞算法，是否就能容易的解決中文分詞的問題呢？事實遠非如此。中文是一種十分複雜的語言，讓計算機理解中文語言更是困難。在中文分詞過程當中，有兩大難題一直沒有徹底突破。

　　一、歧義識別

　 　歧義是指一樣的一句話，可能有兩種或者更多的切分方法。例如：表面的，由於「表面」和「面的」都是詞，那麼這個短語就能夠分紅「表面 的」和「表 面的」。這種稱爲交叉歧義。像這種交叉歧義十分常見，前面舉的「和服」的例子，其實就是由於交叉歧義引發的錯誤。「化妝和服裝」能夠分紅「化妝 和 服裝」或者「化妝 和服 裝」。因爲沒有人的知識去理解，計算機很難知道到底哪一個方案正確。

　　交叉歧義相對組合歧義來講是還算比較容易處 理，組合歧義就必需根據整個句子來判斷了。例如，在句子「這個門把手壞了」中，「把手」是個詞，但在句子「請把手拿開」中，「把手」就不是一個詞；在句子 「將軍任命了一名中將」中，「中將」是個詞，但在句子「產量三年中將增加兩倍」中，「中將」就再也不是詞。這些詞計算機又如何去識別?

　　如 果交叉歧義和組合歧義計算機都能解決的話，在歧義中還有一個難題，是真歧義。真歧義意思是給出一句話，由人去判斷也不知道哪一個應該是詞，哪一個應該不是詞。 例如：「乒乓球拍賣完了」，能夠切分紅「乒乓 球拍 賣 完 了」、也可切分紅「乒乓球 拍賣 完 了」，若是沒有上下文其餘的句子，恐怕誰也不知道「拍賣」在這裏算不算一個詞。

　　二、新詞識別

　　新詞，專業術語稱爲未登 錄詞。也就是那些在字典中都沒有收錄過，但又確實能稱爲詞的那些詞。最典型的是人名，人能夠很容易理解句子「王軍虎去廣州了」中，「王軍虎」是個詞，由於 是一我的的名字，但要是讓計算機去識別就困難了。若是把「王軍虎」作爲一個詞收錄到字典中去，全世界有那麼多名字，並且每時每刻都有新增的人名，收錄這些 人名自己就是一項巨大的工程。即便這項工做能夠完成，仍是會存在問題，例如：在句子「王軍虎頭虎腦的」中，「王軍虎」還能不能算詞？

　　新詞中除了人名之外，還有機構名、地名、產品名、商標名、簡稱、省略語等都是很難處理的問題，並且這些又正好是人們常用的詞，所以對於搜索引擎來講，分詞系統中的新詞識別十分重要。目前新詞識別準確率已經成爲評價一個分詞系統好壞的重要標誌之一。

　　中文分詞的應用

　 　目前在天然語言處理技術中，中文處理技術比西文處理技術要落後很大一段距離，許多西文的處理方法中文不能直接採用，就是由於中文必需有分詞這道工序。中 文分詞是其餘中文信息處理的基礎，搜索引擎只是中文分詞的一個應用。其餘的好比機器翻譯（MT）、語音合成、自動分類、自動摘要、自動校對等等，都須要用 到分詞。由於中文須要分詞，可能會影響一些研究，但同時也爲一些企業帶來機會，由於國外的計算機處理技術要想進入中國市場，首先也是要解決中文分詞問題。 在中文研究方面，相比外國人來講，中國人有十分明顯的優點。

　　分詞準確性對搜索引擎來講十分重要，但若是分詞速度太慢，即便準確性再高， 對於搜索引擎來講也是不可用的，由於搜索引擎須要處理數以億計的網頁，若是分詞耗用的時間過長，會嚴重影響搜索引擎內容更新的速度。所以對於搜索引擎來 說，分詞的準確性和速度，兩者都須要達到很高的要求。目前研究中文分詞的大可能是科研院校，清華、北大、中科院、北京語言學院、東北大學、IBM研究院、微 軟中國研究院等都有本身的研究隊伍，而真正專業研究中文分詞的商業公司除了海量科技之外，幾乎沒有了。科研院校研究的技術，大部分不能很快產品化，而一個 專業公司的力量畢竟有限，看來中文分詞技術要想更好的服務於更多的產品，還有很長一段路。

 

 

淺述搜索引擎的兩種分詞算法

21世紀互聯網的快速發展讓人們生活愈來愈便利，當日益劇增的海量信息讓咱們眼花繚亂時，搜索引擎的出現可讓咱們快速找到本身想要的答案。所以多瞭解搜索引擎的分詞算法，可讓網站在搜索引擎上得到更好的展示機會。在講解中文分詞技術以前，先來了解下全文檢索技術。

全文檢索技術

全文檢索是指索引程序掃描文章中的每一個詞並創建對應索引，記錄該詞出現的位置和次數。當經過搜索引擎查詢時，檢索程序就在記錄的索引進行查找並返回 給用戶。全文檢索又分爲基於字的全文索引和基於詞的全文索引。基於字的全文索引會對內容中的每一個字創建索引並記錄，此方法查全率高，但查準率低，特別是對 於中文，有時搜索馬克，會列出馬克思的結果。基於詞的全文索引是把一個詞語做爲一個單位進行索引記錄，並能處理同義詞。搜索引擎有本身的詞庫，當用戶搜索 時，搜索引擎會從詞庫中抽取關鍵詞做爲索引項，這樣能夠大大提升檢索的準確率。

中文分詞技術

一 直以來你們都比較熟悉百度，百度有本身的中文分詞技術。通常採用的包括正向最大匹配，反向最大匹配，最佳匹配法，專家系統方法等。其中最大正向匹配是最常 用的分詞解決方案，它採用機械式算法，經過創建詞典並進行正向最大匹配對中文進行分詞。舉個簡單的例子好比搜索「北京大學在哪裏」，則返回結果不少都是包 含北京大學，北大等詞語的網頁，搜索引擎就是採用正向最大匹配去判斷，把北京大學當作一個詞語來索引記錄並返回。固然，正向最大匹配也有不完整性，好比長 度過長的詞語，搜索引擎有時沒法準確的分詞，或者對先後都相互關聯的詞沒法準確分詞。例如「結合成分子時」，會被返回結合、成分、子時，而有時咱們想要的 關鍵詞是「分子」。

不少時候百度都會根據本身詞庫中詞語的權重進行拆分，權重的計算基於生活各個方面，比較複雜，搜索引擎要作的就是返回用戶最想要的結果，有時站長們 作網站要站在用戶的角度去考慮問題，其實這也是站在搜索引擎的角度考慮問題，不論在肯定目標關鍵詞或者是長尾關鍵詞時，均可以根據中文分詞的原理來選擇， 這樣能夠最大化的減小無用功。

分詞原理不斷在變化，不斷在更新，咱們應該繼續學習，只有掌握了本質才能抓住實質。

本文出自深圳網站建設，原文地址：http://www.68160.com ，歡迎你們和我交流，之後關於更多分詞技術，特別是中文分詞技術的更多應用我會陸續和你們分享。

 

 

 

淘寶搜索：打造黃金標題之揭祕淘寶分詞算法

【淘寶搜索：打造黃金標題之揭祕淘寶分詞算法】提到分詞，有必要說下那個分詞能夠理解爲多詞分詞，然而淘寶卻不是這樣去分詞的。簡單來講：淘寶的識別第一原則：中心詞率先識別，且多半是不可分詞！告訴你們一個小小的技巧，如何識別本身的寶貝標題的權重中心詞

           

百度分詞算法

1、關於中文分詞：

　　1.中文分詞難度分析

　　首先要說明下的是：普通用戶的搜索與作SEO或者更大說熟悉網絡搜索用戶的搜索習慣是很是不同的，而恰巧普通搜索用戶是百度搜索的基礎力量。 在開頭 贅述 這一點是蔣鑫鵬爲了表達其對於百度搜索算法中的中文分詞的重視。由於，對於百度google這樣的第二代搜索引擎來講，採用的檢索技術主要是依靠關鍵字來 匹配的，而用戶對於關鍵詞的理解與機器程序對於關鍵詞的理解是有很大距離的。

　　在中文分詞方面百度賽過了Google，這是baidu取勝google的關鍵因素之一，中文的分詞比英文要複雜得多(一樣與中文分詞同樣麻煩 的重要 語言 還有日語、韓語、俄語，這也是Google沒辦法在這幾個地區取勝的緣由之一)，蔣鑫鵬在這裏由於篇幅不作贅述，有興趣的朋友能夠研究一下拉丁語系(以英 文爲例)的造句與中文造句的區別，中文造句不只近義詞不少，並且語序變化無常，副詞太多(主謂賓以外的定狀補，嘆詞等等)。

　　　　簡單舉個例子「百度如何排名」「百度是如何排名的」「百度怎麼排名」「百度是怎麼排名的」「百度如何排位」「百度怎麼排位」「百度按什麼排 名」「百度 靠什 麼排名」「百度的搜索是怎麼排位的」……這幾個短語短句至少都包含一個意思「百度搜索結果的排名是什麼規則(原理)」，除此以外，每一個句子都有其餘的含 義，如這些句子還包含有「怎麼作百度排名(實現這個目標的方法)」「百度是怎麼進行搜索排名的(原理實現的過程)」……

　　拿上面的例子來講：當用戶輸入以上短句時(大多數狀況下，普通用戶把百度當作是萬能的，因此才搜索SEO開來這麼不符合規則的搜索行爲)，百度要迅速的響應出用戶須要的結果，這個時候，百度面臨的核心問題是：

　　A.首先要知道用戶是要搜什麼(語義分析，見「二」);

　　B.其次由於百度的檢索方式目前仍然以關鍵詞匹配技術爲主，因此要對用戶的搜索進行分詞(下一段將分析百度如何分詞);

　　C.而後百度要經過分詞分出的結果，去數據庫中檢索匹配的快照;

　　D.上一步只是檢索出來，還要進行第四部的排名，這個時候已經不是挑戰百度的難題了(雖然在SEO看來，這一步確實是很是艱難的)

　　E.第五步要將獲得的結果返回到搜索頁面給用戶使用，而且要完成其廣告的投放(百度競價廣告)，並要適當推廣本身的產品(百度知道、百度文庫……)寫的有點亂，SEO顧問蔣鑫鵬在此致歉，沒找到更好的陳述方式，望朋友們整理髮揚光大。

　　2.百度中文分詞方式：

　　百度對於中文的分詞不只是大量的用戶搜索(這點不一樣於Google，百度畢竟是植根於中國文化的，對中文更瞭解)，並且還有龐大的中文詞典數據 庫做支 撐， 而且動態加入了搜索熱詞，搜索行爲造詞等技術，【從近期百度算法的調整看，百度比之前更加尊重用戶的搜索行爲，就是用戶的輸入爲首要，百度糾正次要，這點 那很重要哦】下面以實例來講，用戶搜索「百度如何排名?」時的分詞：

　　A.天然分割：包括標點符號、空格引發的分割，這是首要因素，好比或者「百度 如何排名」這樣的搜索行爲會被百度首先劃分爲「百度」、「如何排名」，這一點是確定的，要理解用戶搜索的行爲意圖，首先是要尊重用戶的搜索行爲;(這是 SEO顧問蔣鑫鵬根據實戰中的觀察總結出的，作SEO的不少朋友可能沒注意到，在此提個醒)

　　B.中文詞庫分割：不難理解，「百度如何排名」將被分爲「百度」「如何」「排名」這幾個詞，由於這是中文詞典裏存在的詞，百度有龐大的中文詞典庫支撐，這個不是難度;

　　C.分詞組合分詞：B中的分詞顯然是不夠的，要更能理解用戶意圖，必須保證語義連貫，那麼那三個詞能夠組合成「百度如何排名」;「百度如何」+ 「排 名」; 「百度排名」+「如何」;「如何排名」+「百度」以及這幾個詞顛倒的組合，重要程度按照順序優先原則，緊接着是倒序和雙向序列的分詞組合，分析切分有個基 本的原則就是最少的切分。

　　以上三點是一般意義上的分詞，除此以外，還有更麻煩的分詞須要百度處理，見後幾點。

　　D.分字：若是用戶搜索「百 度 如 何 排名」的時候，百度也是迫不得已的，由於你不能判斷出來用戶就是在搜索「百度 如何 排名」，還得尊重用戶搜索行爲，因此，不得不進一步將中文詞進行分字：「百」「度」「如」「何」「排名」，而後在進行組合分詞，組成不一樣的詞組去數據庫中 匹配。

　　E.別音字/錯別字：若有人搜索「白度如何排名」其實是誤將「百度」打成「白度」，那麼百度還要糾正這種錯誤，但近期的調整看，百度不像之前 經過詞 庫近 義匹配來進行糾錯【而更多的是以用戶搜索後瀏覽的行爲積累的數據來爲糾錯作準備】(如搜索「白度」的不少用戶最後花更多時間在「百度」關鍵詞頁面上，那麼 百度之後對於「白度」的搜索糾錯會偏重到「百度」上!

　　固然，這個詞是蔣鑫鵬舉例說明，實際上百度搜索「白度」不是這樣的，例子能夠參看百度的「美規車」查看，百度會提示或者說試探你「您要找的是不 是: 美規車」)，此外，百度對於糾錯經過搜索下拉框相關詞推薦、搜索頁面底部「相關搜索」、百度知道(用戶量很大，是百度搜索的重要補充)來進行糾錯數據的統 計與糾錯引導。

　　F.新詞：新詞的來源通常有兩種：a.近期流行語形成，這個百度的數據庫會根據用戶搜索行爲積累的數據以及網絡熱詞監測數據來進行調整補充到詞庫;b.語言新詞/用戶造詞，這個主要是靠搜索行爲累積的數據調整，也針對部分語言新詞人工做補充。

　　蔣鑫鵬再次補充說明一下，百度其實很累的，它對用戶的每一次搜索行爲都要進行統計(固然是機器程序記錄的方式)：通常主要記錄搜索的關鍵詞、到 訪的頁 面及 到訪方式(通常都是連接)、各頁面停留時間(以前不容易讀取到，如今百度經過瀏覽cookis、百度帳戶、IP記錄、百度統計【若是網站裝了百度統計的程 序，實際上百度很聰明，用各類方式想盡辦法進入到網站，好比最近流行的百度分享按鈕，這個工具實際上就是最大的間諜】等大量輔助工具來統計)，通常測算是 根據搜索後到訪的百度提供的快照頁面的瀏覽行爲(先打開哪一個，而後打開哪一個，在哪裏停留的時間長，最後從哪裏離開百度來實現，百度對於一個網頁對用戶是否 有用的觀點：在該頁面停留時間最長，並最終在此頁面瀏覽完畢後離開百度爲首要標準，其次還有在這些頁面的互動程度所起的因素。

　　2、關於語義分析：

　　其實這段要說的在上一段已經都提到，列出來無非是將「語義分析」這一檢索行爲與「分詞」區別開來，語義分析與分詞是相輔相成的，語義分析更多的 創建在 分詞 與用戶瀏覽行爲習慣數據的研究結論基礎之上，如前所述，百度經過各類方式大量統計用戶的行爲並針對這些行爲及所用的關鍵詞及輸入方式索索的統計數據進行分 詞的支撐與分詞的匹配。

　　畢竟，再怎麼算，那麼多網頁、天天數十億次的檢索行爲，百度仍是難以計算出來的(百度正在經過不斷改進方式及完善機器算法來努力實現這一浩大工 程)， 目前 主要採用的是針對熱門搜索的抽樣統計與其餘搜索的隨機統計來實現搜索語義分析(此爲SEO顧問蔣鑫鵬根據實戰中的觀察作的假想推斷)。

   　百度最難以捉摸透的與其說是排名算法，不如說是語義分析算法，由於與SEO搞不懂百度算法同樣，百度一樣搞不懂搜索用戶的搜索意圖(因此百度一直在研 究， 一直在調整，一直在完善，就像SEO一直在研究，一直在調整，一直在完善同樣的道理)。捉摸不透是一個緣由，更重要的是這些計算不只僅是對於文字及分詞、 匹配度的研究，更是經過統計學、線性數學、邏輯學、行爲學、心理學等衆多的學科的精華計算方法結合在一塊兒設計出的算法結構，並不斷修補完善的，說到這個算 法，百度有一個形容「海量基礎算法」，更不用提每種算法的學科自己的難度了，這就是苦逼的SEO遲遲不能搞懂百度算法的根本緣由，固然，做爲苦逼的 SEO，蔣鑫鵬一樣也是搞不懂的，若是能搞懂的，大多都是數學或計算機天才或頂尖人才，早都去搞本身的研究或者發明去了，還至於追在百度後面吹毛求疵?

　　更況且，百度自己對於搜索結果的「人爲干涉」及「壟斷」都帶來各類斥責，更況且SEO爲了一己之利不斷刷排名給用戶推薦低質量的信息，那就更遭 懂得並 理解 搜索算法的牛人看不起了……因此看到這裏，若是你以爲你很牛，就不要作SEO了，若是做爲SEO你明白了做者蔣鑫鵬寫此篇文章的意圖，那你就站在SEM或 者網絡運營、網絡營銷的高度來看待SEO，而不是爲了半夜趴在電腦前發外鏈混營生而SEO。

　　扯遠了，迴歸正題，作不到像百度同樣設計算法的那個能耐，若是說還能從語義分析中挖掘點對SEO有幫助的東西，那麼蔣鑫鵬建議能夠去研究研究你 正在作 的優 化的相關詞的用戶搜索習慣，好比，蔣鑫鵬最近給上海智寶美規車作網絡運營服務期間，發現「美規車」這一詞正在受到越來 越多的關注，而作這個詞優化的不少SEO或者說站長都頂住「美規車」一個詞作，而這個詞用戶搜索的時候，有可能衍生爲「美規汽車」「美規汽車SUV」「美 規車SUV」「美規SUV」「美規車銷售」「美規車經銷」「美規車經銷商」「美規汽車經銷」「美規汽車銷售」「美規汽車進口代理」等衆多的派生詞，甚至 「美規車哪裏買」「上海哪兒銷售美規車」這樣的更具備成交意義的長尾關鍵詞，若是理解用戶的搜索意圖，再針對性的作SEO，這樣取得的效果會更好。

　　3、關於關鍵詞匹配度：

　　1.關鍵詞分詞匹配重點次序：

　　這是蔣鑫鵬根據SEO實際操做結合網友分享作的總結，精確度不高，但可做爲參考。通常意義上的分詞算法是「關鍵詞比率」：計算該關鍵詞在頁面信 息中的 比 重，一般包含的參數有：title(網頁標題)、meta deｓｃｒｉｐｔion(網頁描述/摘要)、meta keywords(網頁關鍵詞)、網頁H1~H6標籤、錨文本(按照重點程度及頁面位置排序)、內容文本(突出程度如字體、大小、顏色、周圍的背景或者說 文字等，通常的位置順序是從左上到右下)、圖片及其餘頁面文件的Html標記語言屬性。

　　2.關鍵詞匹配度計算：

　　分詞後，要對短語中的關鍵詞進行「索庫」，若是某個詞在短語中與其餘詞相關性不大，將去除匹配，可是其餘詞計算匹配度時任然做爲字數計算。以 「百度如 何排 名」來分析：通常意義上，這個搜索短語被分爲「百度如何排名」;「百度如何」+「排名」;「百度排名」+「如何」……：那麼「百度如何排名」匹配度就是 100%，緊接着就是「百度排名如何」，「如何排名百度」，「如何百度排名」，「排名百度如何」，「排名如何百度」;「百度排名」的匹配度是1/3+1 /3=2/3;「如何排名」的匹配度是1/2;「百度」的匹配度是1/3……以上只是粗略的估算，具體的都多分詞算法還要加入相關參數計算，如順序優先 度，倒序優先度，雙序優先度，最少化切詞度……(具體的算法因蔣鑫鵬學識有限，恕不能分享，在此只是一個基本思路的分析，能夠供朋友們參考，另外分詞中含 有不少關於標點符號、空格、單字等的處理)

　　3.title關鍵詞匹配度：

　　title中的關鍵詞在title自己的分詞匹配中的計算方式與2中提到的同樣，蔣鑫鵬在此想說明兩點：A.根據觀察推斷，百度收錄快照後，對 快照的 存檔 中應該已經作好可能的分詞及匹配度的數據標註(若是不是這樣，那麼百度檢索的效率不會有這麼高)B.每一次用戶的檢索百度都要進行分詞，並依分詞的結果從 從檔的快照中的分詞標註中作最大化的匹配。

　　另外，Title的公認長度通常認爲是不超過80個字符(包含標點及空格，摺合中文漢字約爲40個字)，但從百度檢索結果的快照標題中看，對於 不一樣站 點百 度根據權重會有不一樣的限制，通常爲60個字符，有的站能達到70個字符，超過的部分用「…」代替，但並不意味着百度不計算在內，以 「www.zhibaosuv.com」來講，蔣鑫鵬再添加標題的時候將「智寶美規車SUV」放到最後，但你百度「智寶美規車SUV」的時候現實的快照標 題能夠正常顯示「智寶美規車SUV」而將title超過顯示的部分以段前段後省略的方式顯示。

　　通常，若是沒有特殊必要，建議不要超過公認的80字符，不然，不只稀釋了關鍵詞的匹配度，還會影響搜索引擎對快照的打分。

　　【作title的技巧】，寫到此，順便分享下蔣鑫鵬的一點技巧，企業網站由於頁面少，通常容易得到排名的主要是主頁，因此主頁的title必定 要精心 布 置，若是實在放不下的關鍵詞放到deｓｃｒｉｐｔion中靠前的位置，另外，建議將站點名稱簡寫放在後面，以保證重點關鍵詞靠前而得到較好的匹配度，站點 名稱用「【】」起來，雖然浪費了4個字符，可是在搜索結果中會比較突出，能吸引用戶的注意而提升網站知名度和進入率。

　　順便提下，蔣鑫鵬在操做中發現，若是頭部標籤更新頻繁過分會被降權處理(通常頭部修改後會進入快照觀察期，搜索結果對於修改後的標題顯示會延遲 1~3 周不 等，具體根據不一樣關鍵詞在頁面內容中的體現更新及外部連接錨文本中包含該關鍵詞的更新度不等而延遲時間不等)，頭部標籤一月內修改2次以上，百度會直接隨 機抓取頁面內的文本做爲描述摘要。Google對於Title更新頻繁的頁面，會直接抓頁面佈局中重點體現的某段短語作標題。

　　4.deｓｃｒｉｐｔion關鍵詞匹配度：

　　與title的計算方式相似，只不過deｓｃｒｉｐｔion不會被百度像title同樣被分詞，而只做爲title中關鍵詞和keyword中 的關鍵 詞以 及給給頁面帶來流量較大的關鍵詞的匹配計算，關鍵詞在deｓｃｒｉｐｔion中的匹配度按照順序優先原則，以關鍵詞在deｓｃｒｉｐｔion總字符中的佔 有比率及連貫度計算。

　　deｓｃｒｉｐｔion是對頁面的摘要說明，作SEO的童鞋務必遵照規則，不要將無關信息或者說頁面文本中不包含的關鍵詞堆疊到此，以避免降分。

　　deｓｃｒｉｐｔion公認的容許最大字符量爲200，百度快照顯示的通常爲140字符左右，蔣鑫鵬建議不要超過160字符，由於這樣不只稀釋 關鍵詞 匹配 度，並且百度最近的算法調整，對deｓｃｒｉｐｔion超出快照顯示的部分將再也不作關鍵詞匹配。一樣以智寶美規車來講 明，蔣鑫鵬將美規GMC放在描述摘要最好，最近算法調整後不作顯示了(固然多是個案，僅供參考)。

　　5.keywords關鍵詞匹配度：

　　keywords對於百度來說，貌似自己不做爲匹配，可是有一點百度很在乎：不要將頁面沒有的關鍵詞加到keywords中，若是這樣，有可能會被認爲是在做弊，這點對於Google來講更是如此，Google對於keywords做弊比百度嚴格的多。

　　keywords通常公認的不超過100字符，這點，蔣鑫鵬的理解是，對於Google來說：keywords必定不要過多，要與頁面匹配，一 般頁面 能容 忍的關鍵詞也就十多個到頭;對於百度來說，建議keywords的設計根據百度權重(可用站長工具或愛站網測試)關鍵詞來設計，有權重的詞，能夠加到 keywords中。

　　對於企業網站而言，由於Title和deｓｃｒｉｐｔion限制而字數有限，沒法容納公司全稱，這個時候能夠考慮將公司全稱及簡稱在keywords中體現一下，由於頁面版權信息中通常會包含公司名和簡稱。

　　6.頁面內容中的關鍵詞匹配度：

　　頁面內容不作分詞計算，但標籤中的分詞和快照中存檔的分詞在頁面所佔比列計算中會對頁面中包含的關鍵詞進行匹配並計算次數及在整個頁面字符中所佔比例。

　　頁面的關鍵詞重要程度首要的是H標籤和其餘重要的標籤，固然在百度快照中主要是按照頁面世家顯示的文字爲標準，通常連接錨文本中包含的關鍵詞、 頁面突 出位 置出現的關鍵詞、以突出的方式(字體、顏色)展現出的關鍵詞會比較重要，這點要根據具體頁面做分析，SEO朋友們能夠在檢索關鍵詞結果中直接查看百度快照 中顯示的關鍵詞匹配程度，黃色最高，其次爲紅色和藍色、綠色。

　　快照是存放在百度數據庫中的靜態網頁，不是真實的網頁，因此就有快照更新一說。從快照頁面源代碼中能夠看出，百度快照中只是記載了頁面的基本代碼及文本文件，併爲存儲照片及其餘文件，現實中的快照中的圖片是從頁面文件收錄快照時記錄的文件地址調用過來的。

　　百度快照的存在，纔是你們都關心百度快站更新的根本緣由，由於若是快照不跟新，得到排名的機會就會變少，這個時候的你的網站的快照在百度快照數 據庫中 就像 一個棄嬰……寫到此，做者蔣鑫鵬再次將本身的觀察提醒一下：之前你們都認爲靜態頁面更受搜索歡迎，隨着2.0的不斷髮展及互聯網社交化的趨勢，彷佛這點正 在被改寫並朝着相反方向發展，靜態頁面、僞靜態開始被搜索程序嫌棄……蔣鑫鵬是這樣理解的，若是頁面是靜態的，那麼搜索引擎更容易認爲你的頁面內容更新會 比較慢，這樣天然影響收錄頻率，蜘蛛到訪的頻次也就下降了……

　　4、關鍵詞匹配操做——實例分析

　　以上大體講述了SEO蔣鑫鵬對於百度搜索中文分詞及語義分析、關鍵詞匹配的皮毛理解，下文經過實例重點講一下如何讓網頁與關鍵詞進行匹配。通 常，SEO一 般接到的任務都是客戶/領導甩過來一個站，指定幾個關鍵詞，而後放手去作，除了在頭部標籤加上關鍵詞，大量採集一些關鍵詞相關的文章，剩下的貌似都是用各 種工具進行大量的「外部連接生產」工做了，一時間，包含「www.zhibaosuv.com」的亂七八糟的信息鋪天蓋地涌向各大論壇、博客、店鋪、分類 信息……(固然，蔣鑫鵬也很低俗，作外鏈也大體是這樣操做的，只不過基本不用工具，儘可能減匹配度高相關性強的站點，針對性地發外鏈)。

　　實際上，更好的SEO方式，是在進行排名優化操做前，根據用戶的需求，作調查分析統計，而後依次配合客戶其餘需求，策劃網站方案，將SEO的意 圖在建 設網 站衆志傳媒出品)的過程當中很好地融入，這樣SEO作起來不累，也容易取得較爲理想的效果，以上文中蔣鑫鵬提到的 服務中的客戶上海智寶名車的例子來講，建站之初，衆志傳媒根據客戶專營進口美規車SUV這一特色，經過百度搜索指數、Google關鍵詞榜單、百度相關搜 索推薦、站長工具(tool.chinaz.com)進行過較爲詳盡的統計分析，最後根據客戶主營的美規奔馳、美規寶馬、美規奧迪、美規卡宴、美規路虎、 美規福特、美規豐田、美規林肯、美規GMC這些品牌車，肯定了上述關鍵詞(【特別說明，關鍵詞的策劃還要考慮百度競價競爭程度、頁面收錄數量、首頁結果頁 的快照更新程度及百度全彙總，以此來肯定難易程度，結合預算與工做量來肯定】)。

　　在網站設計工程中，衆志傳媒將產品展現這一欄目設計爲「美規車頻道」，並依次將上述關鍵詞做爲分類，並如下拉菜單的方式實現(蔣鑫鵬提醒：導航 條的錨 文本 出現的關鍵詞是很重要的，而如今作優化，用戶對於關鍵詞數量要求愈來愈多，結合這一狀況，蔣鑫鵬建議首選將導航作成頁面左側的列表通道【實戰中發現頗有 效，以三禾彩鋼爲例】，其次考慮希下拉表菜單及最近流行的頁面底部行列式導航)，在主頁內容安排有限的前提下，在底部將關鍵詞對應的欄目頁URL作了輔助 導航，在首頁文字信息中恰當地將錨文本融入，給主要的圖片作了ALT屬性等。

　　在title設計中，固然「美規車」首選，其次根據關鍵詞順序排列優先的原則，將主頁title設計爲「美規車_美規奔馳,美規寶馬,美規路 虎,美規 卡 宴,美規奧迪【智寶美規車SUV】」，由於其餘幾個關鍵詞沒法擠在title中，檢索量及價值也不是很高，就放在了deｓｃｒｉｐｔion中，而且在 deｓｃｒｉｐｔion開頭中加入「上海智寶名車公司,頂級美規車進口商，豪華名車SUV美規版經銷專賣」，即顯示了公司名稱，同時又突出了公司特色並在 此體現了核心關鍵詞「美規車」，接下來的「美規寶馬X5X6,美規奔馳ML/GL系列,美規保時捷卡宴,美規奧迪Q7,美規路虎攬勝極光,美規林肯外交 官,美規福特,美規豐田,美規GMC。」是對重點產品型號關鍵詞的體現，如「美規寶馬X5」，「美規奧迪Q7」等。 畢竟頁面的頭部文件字符限制，致使不少有限關鍵詞不能體現，對於規車這個網站，衆志傳媒作了內鏈的優化及各個頁面的 代碼優化工做，完善了站內全部頁面的頭部標籤及頁面的其餘標籤、連接，保證每一個頁面名稱都不重複。以美規車頻道 「http://www.zhibaosuv.com/Brand.asp」這個頁面來講，title採用了「美規車,美規奔馳配置,豪華車SUV美規版 價格_智寶美規車頻道」，核心關鍵詞、頁面重點關鍵詞、站點名稱及頁面名稱都在title中有良好的表現，而且欄目頁面對應的產品子頁面都是後臺發佈新產 品生成的，每一個頁面的標題及描述摘要都是動態調用了發佈產品的名稱幾摘要。

　　在網站運營中，未得到更多有價值的關鍵詞的流量，智寶美規車新聞發佈中，儘可能採用原創的信息，並配合美觀的圖片及表格，以提高網頁信息的可讀 性，同 時，做 者不忘將關鍵詞在文章中以突出顯示的形式和加連接作成錨文本的形式表現，更有利於網站內部連接的建設及豐富，這在操做中得到明顯的搜索表現。此外，新聞的 更新，邊體重都是包含有限關鍵詞的，在首頁調用最新發布新聞標題的方式很好的保證了主頁的更新度。

　　寫的有點累贅，百度的算法不是一兩局說得清楚的，衆志傳媒網絡營銷顧問在整理髮布的，也只是皮毛，從SEO的價值來說，是一個理解SEO及百度關鍵詞 匹配 計算法的分析思路，歡迎SEO童鞋們加入討論，本文來自蔣鑫鵬的博客轉載請以連接形式標明

 

 

Baidu分詞算法分析

隨 着搜索經濟的崛起，人們開始越加關注全球各大搜索引擎的性能、技術和日流量。做爲企業，會根據搜索引擎的知名度以及日流量來選擇是否要投放廣告等；做爲 普通網民，會根據搜索引擎的性能和技術來選擇本身喜歡的引擎查找資料；做爲技術人員，會把有表明性的搜索引擎做爲研究對象。 搜索引擎經濟的崛起，又一次向人們證實了網絡所蘊藏的巨大商機。網絡離開了搜索將只剩下空洞雜亂的數據，以及大量等待去費力挖掘的金礦。


　 　可是，如何設計一個高效的搜索引擎？咱們能夠以百度所採起的技術手段來探討如何設計一個實用的搜索引擎。搜索引擎涉及到許多技術點，好比查詢處理，排序 算法，頁面抓取算法，CACHE機制，ANTI-SPAM等等。這些技術細節，做爲商業公司的搜索引擎服務提供商好比百度，GOOGLE等是不會公之於衆 的。咱們能夠將現有的搜索引擎看做一個黑盒，經過向黑盒提交輸入，判斷黑盒返回的輸出大體判斷黑盒裏面鮮爲人知的技術細節。


　　查詢處理與分詞是一箇中文搜索引擎必不可少的工做，而百度做爲一個典型的中文搜索引擎一直強調其「中文處理」方面具備其它搜索引擎所不具備的關鍵技術和優點。那麼咱們就來看看百度到底採用了哪些所謂的核心技術。

查詢處理

  1. 1

    用戶向搜索引擎提交查詢，搜索引擎通常在接受到用戶查詢後要作一些處理，而後在索引數據庫裏面提取相關的信息。那麼百度在接受到用戶查詢後作了些什麼工做呢？

  2. 2

     

  3. 3

    假設用戶提交了不僅一個查詢串

    好比「信息檢索 理論 工具」。那麼搜索引擎首先作的是根據分隔符好比空格，標點符號，將查詢串分割成若干子查詢串，好比上面的查詢就會被解析爲：《信息檢索，理論，工具》三個子字符串；這個道理簡單，咱們接着往下看。
    　　

  4. 4

    假設提交的查詢有重複的內容，搜索引擎怎麼處理呢？

    比 如查詢「理論 工具 理論」，百度是將重複的字符串看成只出現過一次，也就是處理成等價的「理論 工具」，而GOOGLE顯然是沒有進行歸併，而是將重複查詢子串的權重增大進行處理。那麼是如何得出這個結論的呢？咱們能夠將「理論 工具」提交給百度，返回341，000篇文檔，大體看看第一頁的返回內容。OK。繼續，咱們提交查詢「理論 工具 理論」，在看看返回結果，仍然是那麼多返回文檔，固然這個不能說明太多問題，那看看第一頁返回結果的排序，看出來了嗎？順序徹底沒有變化，而GOOGLE 則排序有些變更，這說明百度是將重複的查詢歸併成一個處理的，並且字符串之間的前後出現順序基本不予考慮（GOOGLE是考慮了這個順序關係的）。　　

  5. 5

    假設提交的中文查詢包含英文單詞，搜索引擎是怎麼處理的？

    比 如查詢」電影BT下載」，百度的方法是將中文字符串中的英文看成一個總體保留，並以此爲斷點將 中文切分開，這樣上述的查詢就切爲《電影，BT，下載》，不論中間的英文是否一個字典裏能查到的單詞也好，仍是隨機的字符也好，都會看成一個 總體來對待。至於爲何，你用查詢「電影dfdfdf下載」看看結果就知道了。固然若是查詢中包含數字，也是如此辦理。
    　　

  6. 6

    到目前爲止，一切很簡單，也很清楚，百度怎麼處理用戶查詢的呢？

    概括以下：首先根據分割符號將查詢分開，而後看看是否有重複的字符串，若是有，就拋棄多餘的，只保留一個，接着判斷是否有英文或者數字，若是有的話，把英文或者數字看成一個總體保留並把先後的中文切開。
    　　

    END

　中文分詞

  1. 1

    首先，講講百度的分詞時機或者條件問題，是不是個中文字符串百度就拿來切一下呢？非也，要想被百度的分詞程序榮幸的切割一下也是要講條件的，哪能是個字符串就切割啊？你當百度是賣鋸條的麼？

  2. 2

     

  3. 3

    那麼什麼樣的字符串才知足被切割的條件呢？

    簡單說來，若是字符串只包含小於等於3箇中文字符的話，那就保留不動，當字符串長度大於4箇中文字符的時候，百度的分詞程序纔出馬大幹快上，把這個字符串肢解掉。


    　　

  4. 4

     

  5. 5

    怎麼證實呢？

    我 們向百度提交「電影下載」，看看返回結果中標爲紅字的地方，不難看出來，查詢已經被切割成《電影，下載》兩個單詞了，說明分詞程序已經開工了，若是是比4 箇中文字符更長的字符串，那分詞程序就更不客氣了，必定大卸八塊然後快。咱們來看看三個字符的狀況，提交查詢「固然擇」，看起來這個查詢不三不四，那是因 爲我但願看到這個字符串被切分爲《固然，擇》，返回結果365篇相關頁面，翻到最後一頁，發現標紅的關鍵字都是」 固然擇」連續出現的狀況，好像沒有切分，可是還不肯定，那麼再提交人工分好的查詢「固然 擇」看看，返回結果1，090，000篇，基本上能夠肯定沒有進行分詞了，固然另一種解釋是：對於三個字符先切分，而後將切分後的結果看成一個短語查 詢，這樣看到的效果和沒有切分是類似的。可是我傾向於判斷百度對於少於3個字符的串沒有切分，奧卡姆不是說了麼「如無必要，勿增實體」，幹嘛作無用功呢。 那麼若是沒有切分，會有一個隨之而來的問題，怎麼從索引庫裏面提取未切分的字符串呢？這牽扯到索引的問題，我以爲百度應該採起了兩套索引機制，一種是按照 單詞索引，一種是按照N-GRAM索引，至於索引的具體問題，之後在詳細論述。

  6. 6

     

  7. 7

    下面咱們看看百度是採起的何種分詞算法，

    如今分詞算法已經算是比較成熟了，有簡單的有複雜的，好比正向最大匹配，反向最大匹配，雙向最大匹配，語言模型方 法，最短路徑算法等等，有興趣的能夠用GOOGLE去搜索一下以增長理解。這裏就不展開說了。可是要記住一點的是：判斷一個分詞系統好很差，關鍵看兩點， 一個是消除歧義能力；一個是詞典未登陸詞的識別好比人名，地名，機構名等。

  8. 8

    那麼百度用的是什麼方法？

    個人判斷是用雙向最大匹配算法。至於怎麼推理得出的，讓咱們一步步來看。固然，這裏首先有個假設，百度不會採起比較複雜的算法，由於考慮到速度問題。
    　　

    我 們提交一個查詢「胡深東北京華煙雲」，又一個不知所云的查詢，儘管不知所云可是自有它的道理，我想看看百度的分詞是如何消歧以及是否有詞典未登陸詞的識 別的功能，若是是正向最大匹配算法的話，那麼輸出應該是：」胡深東/北京/華/煙雲」，若是是反向最大匹配算法的話，那麼輸出應該是：」胡/胡/東北/京 華煙雲」，咱們看看百度的分詞結果：」胡深東/北/京華煙雲」，一個很奇怪的輸出，跟咱們的指望相差較多，可是從中咱們能夠得到以下信息：百度分詞能夠識 別人名，也能夠識別」京華煙雲」，這說明有詞典未登陸詞的識別的功能，咱們能夠假設分詞過程分爲兩個階段：第一階段，先查找一個特殊詞典，這個詞典包含一 些人名，部分地名以及一些普通詞典沒有的新詞，這樣首先將」胡深東」解析出來，剩下了字符串」北京華煙雲」，而」北/京華煙雲」，能夠看做是反向最大匹配 的分詞結果。這樣基本說得通。爲了證實這一點，咱們提交查詢」發胡深東北」，咱們指望兩種分詞結果，一個是正向最大匹配《發胡，深，東北》， 一個是上述假設的結果《發，胡深東，北》，事實上百度輸出是第二種狀況，這樣基本能肯定百度分詞采起了至少兩個詞典，一個是普通詞典，一個是 專用詞典（人名等）。並且是專用詞典先切分，而後將剩餘的片段交由普通詞典來切分。

    繼續測驗，提交查詢「古巴比倫理」，若是是正向最大匹 配，那麼結果應該是《古巴比倫，理》，若是是反向最大匹配，那麼結果應該是《古 巴，比，倫理》，事實上百度的分詞結果是《古巴比倫，理》，從這個例子看，好像用了正向最大匹配算法；此外還有一些例子代表好像是使用 正向最大匹配的；可是且慢，咱們看這個查詢「北京華煙雲」，正向最大匹配指望的結果是《北京，華，煙雲》，而反向最大匹配指望的結果是 《北，京華煙雲》，事實上百度輸出的是後者，這說明可能採用的反向最大匹配；從這點咱們能夠猜想百度採用的是雙向最大匹配分詞算法，若是正向 和反向匹配分詞結果一致固然好辦，直接輸出便可；可是若是二者不一致，正向匹配一種結果，反向匹配一種結果，此時該如何是好呢？從上面兩個例子看，在這種 狀況下，百度採起最短路徑方法，也就是切分的片段越少越好，好比《古巴，比，倫理》和《古巴比倫，理》相比選擇後者，《北 京，華，煙雲》和《北，京華煙雲》相比選擇後者。還有相似的一些例子，這樣基本能夠解釋這些輸出結果。
    　　

  9. 9

    可是仍然遺留的問題是：若是正向反向分詞不一致，並且最短路徑也相同，那怎麼辦？輸出正向的仍是反向的結果？

    我 們再來看一個例子。提交查詢「遙遠古古巴比 倫」，這個查詢被百度切分爲《遙遠，古古，巴比倫》，說明詞典裏面有」巴比倫」，可是是否有」古巴比倫」這個詞彙不肯定，此時看不出是正向切 分仍是反向切分得出的結果，換查詢爲「遙遠古巴比倫」，此時被切分爲「遙遠/古巴比倫」，這說明詞典裏面有」古巴比倫」這個詞彙，這說明了「遙遠古古巴比 倫」是正向最大匹配的結果。那爲何「遙遠古古巴比倫」不會被反向切分爲」遙/遠古/古巴比倫」呢，百度的可能選擇是這種狀況下選擇單字少的那組切分結 果。
    　　

  10. 10

    固然還能夠繼續追問：若是切分後單字也同樣多，那怎麼辦？

  11. 11

    最後看一個例子，查詢「王強大小：」，百度將其切分爲「王/強大/小」，是正向切分的結果，若是是反向的會被切分爲「王/強/大小」，這說明有歧義並且單字也相同則選擇正向切分結果。
    　　

    OK，看到這裏可能頭已經有些暈了，最後總結一下百度的分詞算法，固然裏面仍是有猜想的成分，算法以下：

  12. 12

    首先查詢專用詞典（人名，部分地名等），將專有名稱切出，剩下的部分採起雙向分詞策略，若是二者切分結果相同，說明沒有歧義，直接輸出分詞結果。若是不一致，則輸出最短路徑的那個結果，若是長度相同，則選擇單字詞少的那一組切分結果。若是單字也相同，則選擇正向分詞結果。

  13. 13

    百 度一直宣傳本身在中文處理方面的優點，從上面看，分詞算法並沒有特殊之處，消歧效果並不理想，即便百度採起比上述分詞算法複雜些的算法也難以說成是優點， 若是說百度有優點的話，惟一的優點就是那個很大的專用詞典，這個專用詞典登陸了人名（好比大長今），稱謂（好比老太太），部分地名（好比阿聯酋等），估計 百度採用學術界公佈的比較新的命名實體識別算法從語料庫裏面不斷識別出詞典未登陸詞，逐漸擴充這個專門詞典。若是這就是優點的話，那麼這個優點可以保持多 久就是個很明顯的問題。
    　　

  14. 14

    Spelling Checker拼寫檢查錯誤提示（以及拼音提示功能）
    拼寫檢查錯誤提示是搜索引擎都具有的一個功能，也就是說用戶提交查詢 給搜索引擎，搜索引擎檢查看是否用戶輸入的拼寫有錯誤，對於中文用戶來講通常形成的錯誤是輸入法形成的錯誤。那麼咱們就來分析看看百度是 怎麼實現這一功能的。
    　　

    END

咱們分析拼寫檢查系統關注如下幾個問題：

  1. 1

    系統如何判斷用戶的輸入是有可能發生錯誤的查詢呢？
    　

  2. 2

    若是判斷是可能錯誤的查詢輸入，如何提示正確的詞彙呢？
    　　

  3. 3

    那麼百度是如何作的呢？

    百 度判斷用戶輸入是否錯誤的 標準，我以爲應該是查字典，若是發現字典裏面不包含這個詞彙，那麼頗有多是個錯誤的輸入，此時啓動錯誤提示功能，這個很好判斷，由於若是 是一個正常詞彙的話，百度通常不會有錯誤提示，而你故意輸入一個詞典不可能包含的所謂詞彙，此時百度通常會提示你正確的檢索詞彙。
    　　

  4. 4

    那麼百度是怎麼提示正確詞彙的呢？

    很 明顯是經過拼音的方式，好比我輸入查詢「 制才」，百度提供的提示詞彙爲： 「：制裁 質材 紙材「，都是同 音字。因此百度必然維持着一個同音詞詞典，裏面保留着同音詞信息，好比可能包含着下面這條詞條： 「 zhi cai à制裁，質材，紙材」，另外還有一 個標註拼音程序，如今可以看到的基本流程是： 用戶輸入「 制才」，查詞典，發現沒有這個詞彙，OK，啓動標註拼音程序，將「 制才」標註爲拼音「zhi cai」，而後查找同音詞詞典，發現同音詞「 制裁，質材，紙材」，那麼提示用戶可能的正確拼寫。
    　　

  5. 5

    總體流程看起來很簡單，可是還有一些遺留 的小問題，好比是否將詞表裏面全部同音詞都做爲用戶的提示信息呢？

    比 如某個拼音有10個同音詞，是否都輸出呢？百度並無將全部同音詞都輸 出而是選擇必定篩選標準，選擇其中幾個輸出。怎麼證實這一點？咱們看看拼音「liu li」的同音詞，紫光輸入法提示同音詞匯有「 流麗 流離 琉璃 流利」4個，咱們看看百度返回幾個，輸入「流厲」做爲查詢，這裏是故意輸入一個詞典不包含的詞彙，這樣百度的拼寫檢查纔開始工做，百度提示： 「 琉璃劉麗 劉莉 」，這說明什麼？說明不是全部同音詞都輸出，而是選擇輸出，那麼選擇的標準是什麼？我可以猜想到的方法是對於用戶查詢LOG進行 統計，提取用戶查詢次數多的那些同音詞輸出，若是是這樣的話，上面的例子說明用戶搜索「琉璃」次數比其它的都要高些，次之是「 劉麗」，再次是「 劉莉」，看來你們都喜歡查詢本身或者認識的人的名字。
    　　

  6. 6

    另一個小問題：同音詞詞典包含2字詞，3字詞，那麼是否包含4字詞以及更長的詞 條？是否包含一字詞？

    這 裏一字詞好回答，不用測試也能知道確定不包含，由於你輸入一個字，誰知道是不是錯誤的呢？反正只要是漢字就能在詞表 裏面找到，因此沒有判斷依據。二字詞是包含的，上面有例子，三字詞也包含，好比查詢 「中城藥」百度錯誤提示：「中成藥」，修改查詢爲「重城藥」，還 是提示「中成藥」 ，再次修改查詢 「重城要」，百度依然提示「中成藥」。 那麼4字詞彙呢？
    　　百度仍是會給你提示的，下面是個例子：
    　　輸入：靜華煙雲 提示 京華煙雲
    　　輸入：靜話煙雲 提示 京華煙雲
    　　輸入：靜話閻暈 提示 京華煙雲
    　　

  7. 7

    那麼更長的詞彙是否提示呢？

    也提示，好比我輸入： 「落花世界有風軍」，這個查詢是什麼意思，估計讀過古詩的都知道，看看百度的提示「落花時節又逢君」，這說明什麼？說 明同音詞詞典包含不一樣長度的同音詞信息，另外也說明了百度的核心中文處理技術，也就是那個詞典，還真挺大的。

    可是，若是用戶輸入的 查詢由兩個或者兩個以上子字符串構成，那麼百度的錯誤提示功能就罷工了，好比輸入查詢「哀體」，百度提示「艾提 挨踢」，可是。輸入爲 「我 哀體 」，則沒有任何錯誤提示。
    　　

  8. 8

    還有一個比較重要的問題：若是漢字是多音字那麼怎麼處理？

    百 度呢比較偷懶，它根本就沒有對多音字作處理。我 們來看看百度的一個標註拼音的錯誤，在看這個錯誤前先看看對於多音字百度是怎麼提示錯誤的，咱們輸入查詢「俱長」，百度提示「劇場 局長」， 「俱長「的拼音有兩個：」ju zhang /ju chang「 ，可見若是是多音字則幾種狀況都提示。.如今咱們來看看錯誤的狀況， 咱們輸入查詢」劇常「，百度 提示」：劇場局長「，提示爲」劇場「固然好解釋，由於是同音字，可是爲何 」局長「也會被提示呢？這說明百度的同音字詞典有錯誤，說明在」ju chang「這個詞條裏面包含」局長「這個錯誤的同音詞。讓咱們順藤摸瓜，這個錯誤又說明什麼問題呢？說明百度的同音詞典是自動生成的，並且沒有 人工校對。還說明在自動生成同音詞典的過程當中，百度不是根據對一篇文章標註拼音而後在抽取詞彙和對應的拼音信息得到的，而是徹底按照某個 詞典的詞條來標註音節的，因此對於多音字形成的錯誤沒法識別出來，若是是對篇章進行拼音標註，可能就不會出現這種很容易發現的錯誤標註。 固然還有另一種解釋，就是」局長「是故意被百度提示出來可能的正確提示詞彙，由於考慮到南方人」zh「和 」ch「等先後鼻音分不清麼，那麼是這 樣的麼？咱們繼續測試究竟是何種狀況。是百度有錯誤仍是這是百度的先進的算法？
    　　

     

    咱們考慮詞彙」長大 「，故意錯誤輸入爲」贓大「，若是 百度考慮到了先後鼻音的問題，那麼應該會提示」長大「，可是百度提示是」藏大「。這說明什麼？說明百度並無考慮先後鼻音問題，根本就是系統錯 誤。 咱們輸入查詢」懸賞「，故意將之錯誤輸入爲」懸桑「，沒有錯誤提示，說明確實沒有考慮這種狀況。前鼻音沒有考慮，那麼後鼻音考慮了麼，咱們 輸入」：常常「，故意改成後鼻音 」經纏「，百度提示爲」經產 經懺「，仍是沒有考慮後鼻音。這基本能夠肯定是百度系統的錯誤致使。

    END

根據以上推導， 咱們能夠得出以下結論：

百 度是將分詞詞典裏面每一個詞條利用拼音標註程序標註成拼音，而後造成同音詞詞典，因此兩個詞典是一樣大的 ，並且這個詞典也隨着分詞詞典的增加而在不斷增加。 至於標註過程當中多音字百度沒有考慮，若是是多音字就標註成多個發音組合，經過這種方式 造成同音詞詞典。這樣的同音詞詞典顯然包含着不少錯誤。

 


最 後一個問題：百度對於英文進行拼寫檢查麼？讓咱們試試看，輸入查 詢」china「，不錯，搜到很多結果，專一中文搜索的百度還能搜索到英文，真是意外的驚喜。變換一下查詢」chine「，會更加意外驚喜的給咱們提 示」china「嗎？百度提示的是： 吃呢持呢，原來是不當心觸發了百度的拼音搜索功能了。那麼拼音搜索和中文檢查錯誤是否採用同一套同音詞詞典 呢，讓咱們來實驗一下，搜索」rongji「，百度提示」 榕基 溶劑 容積「，OK，換個中文查詢」容機「，百度提示」 榕基 溶劑容積「，看來使用的是同一套 同音詞詞典。也就是說百度的中文糾錯和拼音檢索使用的機制相同，中文糾錯多了一道拼音註音的過程而已。難道這就是傳說中那個百度的」事實 上是一個無比強大的拼音輸入法「的拼音提示功能麼？　

最後讓咱們總結概括一下百度的拼寫檢查系統：

  1. 1

    後臺做業：
    　　

  2. 2

    前 面的文 章咱們說過，百度分詞使用的詞典至少包含兩個詞典一個是普通詞典，另一個是專用詞典（專名等），百度利用拼音標註程序依次掃描全部詞典中 的每一個詞條，而後標註拼音，若是是多音字則把多個音都標上，好比」長大「，會被標註爲」zhang da/chang da「兩個詞條。
    　　

  3. 3

    經過標註完的 詞條，創建同音詞詞典，好比上面的」長大「，會有兩個詞條： zhang daà長大」 ， chang daà長大。
    　　

  4. 4

    利用用戶查詢LOG頻率信息給予每一個 中文詞條一個權重;
    　　

  5. 5

    OK，同音詞詞典創建完成了，固然隨着分詞詞典的逐步擴大，同音詞詞典也跟着同步擴大;
    　　

  6. 6

    拼寫檢查：　　

  7. 7

    用戶輸入查詢，若是是多個子字符串，不做拼寫檢查;
    　

  8. 8

    對於用戶查詢，先查分詞詞典，若是發現有這個單詞詞條，OK， 不做拼寫檢查;
    　　

  9. 9

    若是發現詞典裏面不包含用戶查詢，啓動拼寫檢查系統;首先利用拼音標註程序對用戶輸入進行拼音標註;

  10. 10

    對於標註好的拼音在同音詞詞典裏面掃描，若是沒有發現則不做任何提示;
    　　

  11. 11

    若是發現有詞條，則按照順序輸出權重比較大的幾個提 示結果;
    　　

  12. 12

    拼音提示：　

  13. 13

    對於用戶輸入的拼音在同音詞詞典裏面掃描，若是沒有發現則不做任何提示;
    　

  14. 14

    若是 發現有詞條，則按照順序輸出權重比較大的幾個提示結果;
    　　

    上面說過，通過分析得出百度的分詞系統採用雙向最大匹配分詞，可是後來發現推理過程當中存在一個漏洞，並且推導出來的百度分詞算法步驟仍是過於繁瑣，因此進一步進行分析，看看是否前面的推導有錯誤。

  15. 15

    那麼之前的分析有什麼漏洞呢？

    我 們推導百度分詞有反向最大匹配的依據是百度將「北京華煙雲」分詞爲《北，京華煙雲》，從這裏看好像採用了反向最大匹配，由於正向最大匹配的結果應該是《北 京，華，煙雲》，可是由此就推論說百度採用了雙向最大匹配仍是太倉促了，前面文章咱們也講過，百度有兩個詞典，一個普通詞典，一個專有詞典，並且是專有詞 典的詞彙先切分，而後將剩餘片段交給普通詞典去切分。因此上面的「北京華煙雲」之因此被切分紅《北，京華煙雲》，另一個多是：京華煙雲這個詞彙是在專 有詞典裏面存儲的，因此先分析，這樣得出「京華煙雲」，剩下「北」，沒什麼好切分的，因此輸出《北，京華煙雲》。
    　這裏只是假設，那麼是否確實 「京華煙雲」在專有詞典呢？咱們再看一個例子「山東北京華煙雲」，百度切分的結果是《山東，北，京華煙雲》，若是「京華煙雲」在普通詞典，若是是反向切 分，那麼結果應該是《山，東北，京華煙雲》，若是是正向切分應該是《山東，北京，華，煙雲》，不管如何都分不出《山東，北，京華煙雲》。這說明什麼？說明 「京華煙雲」是在那個專有詞典，因此先切分出「京華煙雲」，而後剩下的「山東北」交由普通詞典切分，明顯是正向最大匹配的結果輸出《山東，北》。固然按照 咱們在第一篇文章的算法推導「山東北」的切分也會得出《山東，北》的結論，可是明顯比正向最大匹配多幾個判斷步驟，既然效果同樣，另一個更加簡潔的方法 也能說得通，那固然選擇簡便的方法了。因此初步判斷百度採起的是正向最大匹配。
    　　

    咱們繼續測試採用何種分詞算法，爲了減小專有詞 典首先分詞形成的影響，那麼查詢裏面不能出現相對特殊的詞彙，構築查詢「天才能量級」，這裏應該沒有專有詞典出現過的詞彙，百度切分爲《天才，能量， 級》，看來是正向最大匹配的結果。另外，若是全部查詢詞彙都出如今專有詞典，那麼採起的是何種方法？這樣首先就得保證詞彙都出如今專有詞典，這麼保證這一 點呢？咱們構造查詢「鋪陳曉東方」，百度切分爲《鋪，陳曉東，方》，能夠看出「陳曉東」是在專有詞典的因此先切分出來。另一個例子 「山東京城」，百度切分爲《山東，京城》，說明「東京」是在普通詞典的.OK，構造查詢「陳曉東京華煙雲」，經過前面分析能夠看出兩個詞彙都在專有詞典裏 面，百度切分爲《陳曉東，京華煙雲》，說明對於專有詞典詞彙也是採起正向最大匹配或者雙向最大匹配。那麼使用反向最大匹配了嗎？構造查詢例子「陳曉東方不 敗」，首先咱們確定「陳曉東」和「東方不敗」都是在專有詞典出現的，若是是正向切分，那麼應該是《陳曉東，方，不敗》或者《陳曉東，方，不，敗》若是是反 向切分則是《陳，曉，東方不敗》，能夠看出百度的切分是《陳曉東，方，不敗》或者《陳曉東，方，不，敗》，說明採用的是正向最大匹配。經過分析，百度的詞 典不包含「不敗」這個單詞，因此實際上百度的切分結果是《陳曉東，方，不，敗》，很明顯這和咱們之前推導的算法是有矛盾的，因此之前的分析算法確實有問 題，因此結論是百度採起的是正向最大匹配算法。

    END

注意事項

  • 從新概括一下百度的分詞系統：首先用專有詞典採用最大正向匹配分詞，切分出部分結果，剩餘沒有切分交給普通詞典，一樣採起正向最大匹配分詞，最後輸出結果。

  • 另外，GOOGLE也是採用正向最大匹配分詞算法，不過好像沒有那個專用詞典，因此不少專名都被切碎了。從這點講，GOOGLE在中文詞典構建上比百度差些，還須要加把子力氣才行，不過這也不是什麼多難的

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程