前言

很長一段時間沒有寫部落格，因為最近在忙一些學校的事情，在資料知識工程這門課上，老師留了一個大作業，是做一個簡單的搜尋引擎，功能需求如下：

要求：

使用者可指定返回結果數

顯示查詢的響應時間

排序結果中提取文件中包含查詢關鍵詞的片段

支援短語（2單詞）查詢

按照功能的需求，我們最終完成了一個簡單的搜尋引擎，可以返回指定結果數、顯示查詢的響應時間，可以對結果進行排序，並且顯示搜尋結果所在的部分的文字，支援短語（2單詞）的查詢，並且支援類似於google /4 baidu的搜尋方式，用以搜尋在google和baidu之間間隔小於等於四個詞的文件。

設計過程

索引

對於一個搜尋引擎來說，最重要的部分應該就是索引的建立，一個索引建立的好壞與否直接決定了後面搜尋部分的速度和準確度。而根據資料知識工程這門課程前面的講解，建立索引就是通過對所有文字的掃描來獲得單詞token

獲取token就是讀取檔案的過程，然後通過porter stemmer將單詞轉換為term。在建立索引的過程中有兩個部分需要設計相應的資料結構。Dictionary和PostingList。

dictionary的建立可以使用兩種資料結果來實現，一種是雜湊表，一種是樹。兩種資料結構各有優劣，雜湊表可以實現常數時間的查詢，查詢速度最快，但是如果dictionary需要增長的話需要耗費大量時間來重新建立雜湊表。用樹來儲存

public class Entry {

public int idf = 0;

public List<PostingListItem> postingList;

public Entry(int idf, List postingList){

this.idf = idf;

this.postingList = postingList;

}

 

}
 

PostingList是文件Id的列表，每個dictionary裡面的term都有一個指向相應PostingList的指標，PostingList裡儲存著文件Id等資訊，我們使用Java的LinkedList來作為PostingList的資料結構，如下。

</pre><pre name="code" class="java">

public class PostingListItem {
	public int DocumentId;
	public int tf;
	//public int position;
	public List<PositionItem> positionList;
	
	public PostingListItem(int id, int tf, List<PositionItem> positionList) {
		// TODO Auto-generated constructor stub
		this.DocumentId = id;
		this.tf = tf;
		//this.position = position;
		this.positionList = positionList;
	}
}

public class PositionItem {

 

int wordPos;

int charPos;

public PositionItem(int wordPos, int charPos){

this.wordPos = wordPos;

this.charPos = charPos;

}

 

}

最後整體的資料結構如下：

對索引部分進行了單元測試，部分結果如下：

For term: unit

DocumentId: 6

tf: 2

[176 22] [559 82]

DocumentId: 9

tf: 1

[1190 185]

DocumentId: 17

tf: 1

[28 4]

DocumentId: 21

tf: 3

[107 15] [199 29] [251 37]

DocumentId: 27

tf: 2

[156 20] [267 38]

DocumentId: 28

tf: 1

[101 17]

查詢

至此，索引的建立已經完畢，接下來要進行的就是查詢部分的設計，查詢分為單詞查詢和片語查詢，使用的是tf-idf來對每次搜尋在每個文件的重要程度進行的打分。

其中的tf就是我們在postingListItem中儲存的int型別的tf，idf就是我們在entry中儲存的int型別的idf，N是資料集中的文件數目。在查詢的時候通過公式進行計算得到相應的值。

單詞搜尋

最先完成的是對單詞進行的搜尋。因為需求中規定了可以指定返回的結果數目，所以我們沒有必要對所有文件進行排序，而是使用堆排序的方法，因為要返回前k個大的文件，所以堆排序是最適合該情況的方法。堆排序的建堆的時間複雜度為O(n)，通過維護一個大小為k的最小堆來儲存前k大的文件，如果新文件比堆頂的要大，就更換堆頂，否則跳過。如果採用其它方法如快排，時間複雜度平均要O(n log n)。

搜尋的過程，首先對搜尋的單詞進行詞根處理，然後通過hash表找到term在dictionary裡的位置，並且找到其postingList，沿著postingList通過最小堆來篩選出score最大的前k個文件並返回其文件id，weight和position到資料結構ResultSet中。

public class ResultSet {

public int DocumentId;

public double weight;

public int position;

public ResultSet(int id, double weight, int position){

this.DocumentId = id;

this.weight = weight;

this.position = position;

}

}

單詞搜尋的結果展示如下：

片語搜尋

片語搜尋的完成是基於單詞搜尋的基礎上，將搜尋的片語作為一個向量（向量的每一維都是一個term的tf-idf），被搜尋的每個文件都作為一個向量，找出與搜尋向量最相近的k個向量。

使用向量夾角來量化搜尋與文件之間的關係

片語搜尋還要在兩個單詞相鄰的基礎上再進行向量夾角的計算，所以在之前的資料結構中使用了positionList來儲存每個term在每個文件中出現的位置（單詞位置），通過查詢兩個位置是否相鄰來獲取該檔案是否有該片語出現。同時也實現了google /4 baidu的搜尋效果，通過查詢兩個單詞的位置是否相差小於等於4的單詞數。獲取到含有該片語的文件後，再通過向量夾角的cos值來獲得score，並且使用最小堆得到前k個結果並返回。

片語搜尋的結果如下：

遇到的問題

遇到的問題是向量夾角cos的計算，在大量term存在的情況下，向量的維度會非常大，如果進行幾千維度與幾千維度的向量之間的點乘運算會耗費大量搜尋時間。後來發現搜尋的片語只有兩個單詞，也就是說其它維度的數值都是0，在進行點乘運算時與0相乘的步驟可以忽略，直接進行term1_score * doc1.term1_scor + term2_score * doc 2.term2_score ...得到結果。

還有就是片語搜尋需要知道某個單詞在文件中是第幾個，因此修改了資料結構postingList，增加了連結串列positionList來儲存term在某個文件中所有出現過的位置。

系統的特點

可以查詢單詞和片語（2單詞），查詢響應速度快，返回結果根據使用者的輸入按照weight由高到低返回前k個，可以返回查詢的時間，文件的id和文件名，相應的weight，term在文件中的字元位置，term所在位置的部分文字顯示。

支援在兩單詞中間輸入/n來表示搜尋兩單詞間距小於等於n的結果。