[轉]OKapi BM25 算法

BM25（Best Match25）是在信息檢索系統中根據提出的query對document進行評分的算法。It is based on the probabilistic retrieval framework developed in the 1970s and 1980s by Stephen E. Robertson, Karen Spärck Jones, and others.BM25算法首先由OKapi系統實現，所以又稱爲OKapi BM25。

BM25屬於bag-of-words模型，bag-of-words模型只考慮document中詞頻，不考慮句子結構或者語法關係之類，把document當做裝words的袋子，具體袋子裏面可以是雜亂無章的。It is not a single function, but actually a whole family of scoring functions, with slightly different components and parameters. One of the most prominent instantiations of the function is as follows.

　　對於一個query $Q$ , 包括關鍵字 $q_1, ..., q_n$ , 一個文檔的BM25得分:

$\text{score}(D,Q) = \sum_{i=1}^{n} \text{IDF}(q_i) \cdot \frac{f(q_i, D) \cdot (k_1 + 1)}{f(q_i, D) + k_1 \cdot (1 - b + b \cdot \frac{|D|}{\text{avgdl}})},$

其中IDF是上篇文章《TD-IDF》中的IDF，f是《TD-IDF》中的TF，|D|是文檔D的長度，avgdl是語料庫全部文檔的平均長度。k₁和b是參數。usually chosen, in absence of an advanced optimization, as $k_1 \in [1.2,2.0]$ and $b = 0.75$ 。

TF-IDF

詞語頻率( Term Frequency), 簡稱 “TF”, 是一個很簡單的度量標準：一個特定的詞語在文檔出現的次數。你可以把這個值除以該文檔中詞語的總數，得到一個分數。例如文檔中有 100 個詞， ‘the’ 這個詞出現了 8 次，那麼 ‘the’ 的 TF 爲 8 或 8/100 或 8%（取決於你想怎麼表示它）。

逆向文件頻率（Inverse Document Frequency）, 簡稱 “IDF”，要複雜一些：一個詞越稀有，這個值越高。它由總文件數目除以包含該詞語之文件的數目，再將得到的商取對數得到。越是稀有的詞，越會產生高的 “IDF”。

如果你將這兩個數字乘到一起 (TF*IDF), 你將會得到一個詞語在文檔中的權重。“權重”的定義是：這個詞有多稀有並且在文檔中出現的多麼頻繁？

你可以將這個概念用於文檔的搜索查詢。在查詢中的對於查詢中的每個關鍵字，計算他們的 TF-IDF 分數，並把它們相加。得分最高的就是與查詢語句最符合的文檔。

很酷吧！

Okapi BM25

上述算法是一個可用的算法，但並不太完美。它給出了一個基於統計學的相關分數算法，我們還可以進一步改進它。

Okapi BM25 是到目前爲止被認爲最先進的排名算法之一（所以被稱爲 ElasticSearch ）。Okapi BM25 在 TF-IDF 的基礎上增加了兩個可調參數，k1 和 b，, 分別代表 “詞語頻率飽和度（term frequency saturation）” 和 “字段長度規約”。這是什麼鬼？

爲了能直觀的理解“詞語頻率飽和度”，請想象兩篇差不多長度的討論棒球的文章。另外，我們假設所有文檔(除去這兩篇)並沒有多少與棒球相關的內容，因此 “棒球” 這個詞將具有很高的 IDF – 它極稀少而且很重要。這兩篇文章都是討論棒球的，而且都花了大量的篇幅討論它，但是其中一篇比另一篇更多的使用了“棒球”這個詞。那麼在這種情況，是否一篇文章真的要比另一篇文章相差很多的分數呢？既然兩個兩個文檔都是大篇幅討論棒球的，那麼“棒球”這個詞出現 40 次還是 80 次都是一樣的。事實上，30 次就該封頂啦！

這就是 “詞語頻率飽和度。原生的 TF-IDF 算法沒有飽和的概念，所以出現 80 次“棒球”的文檔要比出現 40 次的得分高一倍。有些時候，這時我們所希望的，但有些時候我們並不希望這樣。

此外，Okapi BM25 還有個 k1 參數，它用於調節飽和度變化的速率。k1 參數的值一般介於 1.2 到 2.0 之間。數值越低則飽和的過程越快速。（意味着兩個上面兩個文檔有相同的分數，因爲他們都包含大量的“棒球”這個詞語）

字段長度歸約（Field-length normalization）將文檔的長度歸約化到全部文檔的平均長度上。這對於單字段集合（single-field collections）（例如 ours）很有用，可以將不同長度的文檔統一到相同的比較條件上。對於雙字段集合（例如 “title” 和 “body”）更加有意義，它同樣可以將 title 和 body 字段統一到相同的比較條件上。字段長度歸約用 b 來表示，它的值在 0 和 1 之間，1 意味着全部歸約化，0 則不進行歸約化。

算法

在Okapi BM25 維基百科中你可以瞭解Okapi算法的公式。既然都知道了式子中的每一項是什麼，這肯定是很容易地就理解了。所以我們就不提公式，直接進入代碼：

BM25.Tokenize = function(text) {
    text = text
        .toLowerCase()
        .replace(/\W/g, ' ')
        .replace(/\s+/g, ' ')
        .trim()
        .split(' ')
        .map(function(a) { return stemmer(a); });

    // Filter out stopStems
    var out = [];
    for (var i = 0, len = text.length; i < len; i++) {
        if (stopStems.indexOf(text[i]) === -1) {
            out.push(text[i]);
        }
    }

    return out;
};

我們定義了一個簡單的靜態方法Tokenize()，目的是爲了解析字符串到tokens的數組中。就這樣，我們小寫所有的tokens（爲了減少熵）。我們運行Porter Stemmer 算法來減少熵的量同時也提高匹配程度（“walking”和”walk”匹配是相同的）。而且我們也過濾掉停用詞（很普通的詞）爲了更近一步減少熵值。在我所寫的概念深入之前，如果我過於解釋這一節就請多擔待。

BM25.prototype.addDocument = function(doc) {
    if (typeof doc.id === 'undefined') { throw new Error(1000, 'ID is a required property of documents.'); };
    if (typeof doc.body === 'undefined') { throw new Error(1001, 'Body is a required property of documents.'); };

    // Raw tokenized list of words
    var tokens = BM25.Tokenize(doc.body);

    // Will hold unique terms and their counts and frequencies
    var _terms = {};

    // docObj will eventually be added to the documents database
    var docObj = {id: doc.id, tokens: tokens, body: doc.body};

    // Count number of terms
    docObj.termCount = tokens.length;

    // Increment totalDocuments
    this.totalDocuments++;

    // Readjust averageDocumentLength
    this.totalDocumentTermLength += docObj.termCount;
    this.averageDocumentLength = this.totalDocumentTermLength / this.totalDocuments;

    // Calculate term frequency
    // First get terms count
    for (var i = 0, len = tokens.length; i < len; i++) {
        var term = tokens[i];
        if (!_terms[term]) { 
            _terms[term] = {
                count: 0,
                freq: 0
            }; 
        };
        _terms[term].count++;
    }

    // Then re-loop to calculate term frequency.
    // We'll also update inverse document frequencies here.
    var keys = Object.keys(_terms);
    for (var i = 0, len = keys.length; i < len; i++) {
        var term = keys[i];
        // Term Frequency for this document.
        _terms[term].freq = _terms[term].count / docObj.termCount;

        // Inverse Document Frequency initialization
        if (!this.terms[term]) {
            this.terms[term] = {
                n: 0, // Number of docs this term appears in, uniquely
                idf: 0
            };
        }

        this.terms[term].n++;
    };

    // Calculate inverse document frequencies
    // This is SLOWish so if you want to index a big batch of documents,
    // comment this out and run it once at the end of your addDocuments run
    // If you're only indexing a document or two at a time you can leave this in.
    // this.updateIdf();

    // Add docObj to docs db
    docObj.terms = _terms;
    this.documents[docObj.id] = docObj;
};

這就是addDocument()這種方法會奇蹟般出現的地方。我們基本上建立和維護兩個類似的數據結構:this.documents.和this.terms。

this.documentsis 是一個保存着所有文檔的數據庫，它保存着文檔的全部原始文字，文檔的長度信息和一個列表，列表裏面保存着文檔中的所有詞語和詞語的數量與出現頻率。使用這個數據結構，我們可以很容易的和快速的（是的，非常快速，只需要時間複雜度爲O(1)的哈表查詢時間）回答如下問題：在文檔 #3 中，’walk’ 這個詞語出現了多少次？

我們在還使用了另一個數據結構，this.terms。它表示語料庫中的所有詞語。通過這個數據結構，我們可以在O(1)時間內回答如下問題：’walk’ 這個詞在多少個文檔中出現過？他們的 id 是什麼？

最後，我們記錄了每個文檔的長度，並記錄了整個語料庫中文檔的平均長度。

注意，上面的代碼中， idf 被初始化 0，而且 updateidf() 方法被註釋掉了。這是因爲這個方法運行的非常慢，並且只需在建立索引之後運行一次就可以了。既然運行一次就能滿足需求，就沒有必要運行5000次。先把它註釋掉，然後在大批量的索引操作之後運行，就可以節省很多時間。下面是這個函數的代碼：

BM25.prototype.updateIdf = function() {
    var keys = Object.keys(this.terms);
    for (var i = 0, len = keys.length; i < len; i++) {
        var term = keys[i];
        var num = (this.totalDocuments - this.terms[term].n + 0.5);
        var denom = (this.terms[term].n + 0.5);
        this.terms[term].idf = Math.max(Math.log10(num / denom), 0.01);
    }
};

這是一個非常簡單的函數，但是由於它需要遍歷整個語料庫中的所有詞語，並更新所有詞語的值，這就導致它工作的就有點慢。這個方法的實現採用了逆向文檔頻率 (inverse document frequency) 的標準公式（你可以在 Wikipedia 上找到這個公式）— 由總文件數目除以包含該詞語之文件的數目，再將得到的商取對數得到。我做了一些修改，讓返回值一直大於0。

BM25.prototype.search = function(query) {

    var queryTerms = BM25.Tokenize(query);
    var results = [];

    // Look at each document in turn. There are better ways to do this with inverted indices.
    var keys = Object.keys(this.documents);
    for (var j = 0, nDocs = keys.length; j < nDocs; j++) {
        var id = keys[j];
        // The relevance score for a document is the sum of a tf-idf-like
        // calculation for each query term.
        this.documents[id]._score = 0;

        // Calculate the score for each query term
        for (var i = 0, len = queryTerms.length; i < len; i++) {
            var queryTerm = queryTerms[i];

            // We've never seen this term before so IDF will be 0.
            // Means we can skip the whole term, it adds nothing to the score
            // and isn't in any document.
            if (typeof this.terms[queryTerm] === 'undefined') {
                continue;
            }

            // This term isn't in the document, so the TF portion is 0 and this
            // term contributes nothing to the search score.
            if (typeof this.documents[id].terms[queryTerm] === 'undefined') {
                continue;
            }

            // The term is in the document, let's go.
            // The whole term is :
            // IDF * (TF * (k1 + 1)) / (TF + k1 * (1 - b + b * docLength / avgDocLength))

            // IDF is pre-calculated for the whole docset.
            var idf = this.terms[queryTerm].idf;
            // Numerator of the TF portion.
            var num = this.documents[id].terms[queryTerm].count * (this.k1 + 1);
            // Denomerator of the TF portion.
            var denom = this.documents[id].terms[queryTerm].count 
                + (this.k1 * (1 - this.b + (this.b * this.documents[id].termCount / this.averageDocumentLength)));

            // Add this query term to the score
            this.documents[id]._score += idf * num / denom;
        }

        if (!isNaN(this.documents[id]._score) && this.documents[id]._score > 0) {
            results.push(this.documents[id]);
        }
    }

    results.sort(function(a, b) { return b._score - a._score; });
    return results.slice(0, 10);
};

最後，search() 方法遍歷所有的文檔，並給出每個文檔的 BM25 分數，然後按照由大到小的順序進行排序。當然了，在搜索過程中遍歷語料庫中的每個文檔實是不明智。這個問題在 Part Two （反向索引和性能）中得到解決。

上面的代碼已經做了很好的註釋，其要點如下：爲每個文檔和每個詞語計算 BM25 分數。詞語的 idf 分數已經預先計算好了，使用的時候只需要查詢即可。詞語頻率作爲文檔屬性的一部分也已經預先計算好了。之後只需要簡單的四則運算即可。最後給每個文檔增加一個臨時變量 _score，然後根據 score 做降序排列並返回前 10 個結果。

示例，源代碼，注意事項和下一步計劃

上面的示例有很多方法進行優化，我們將在 “全文搜索”的第二部分中介紹它們，歡迎繼續收看。我希望我能在幾個星期之後完成它。下面列了下次將要提到的內容：

反向索引和快速搜索
快速索引
更好的搜索結果

爲了這個演示，我編了一個小的維基百科爬蟲，爬到相當多（85000）維基百科文章的第一段。由於索引到所有85K文件需要90秒左右，在我的電腦我已經削減了一半。不想讓你們僅僅爲了一個簡單的全文本演示浪費你的筆記本電腦電量。

因爲索引是一個繁重的、模塊化的CPU操作，我把它當成一個網絡工作者。索引運行在一個後臺線程上–在這裏你可以找到完整的源代碼。你也會發現到詞幹算法和我的停用詞列表中的源代碼參考。至於代碼許可，還是一如既往爲教育目的而免費，而不用於任何商業目的。

最後是演示。一旦索引完成，嘗試尋找隨機的東西和短語，維基百科會知道的。注意，只有40000段的索引，所以你可能要嘗試一些新的話題。

來源：http://blog.csdn.net/northhan/article/details/50952728

站內首發文章

黑夜路人博客專家

發佈了329 篇原創文章 · 獲贊 319 · 訪問量 463萬+

私信關注

[轉]OKapi BM25 算法

相關性

TF-IDF

Okapi BM25

算法

示例，源代碼，注意事項和下一步計劃

[轉]MySQL FullText檢索和MySQL5.6 InnoDB FULLTEXT Indexes研究測試

[轉]RTP協議全解析（H264碼流和PS流）

[轉]樸素貝葉斯分類器的應用

[轉]hls之m3u8、ts、h264、AAC流格式詳解

[轉]深入淺出CoreOS

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結