coursera課程 text retrieval and search engine 第四周 推薦。算法
根據現有蒐集的數據作估算,假設一個文檔被用戶看到了,若是文檔被用戶點擊進去,那麼認爲是相關的,不然不相關[只認爲相關和不相關],那麼在特定的查詢狀況下,即可獲得這種點擊比例。app
機率模型的核心思想就是,假設當前文檔是某個用戶想要的,那麼這其中有多大的機率代表這個查詢是來自於此特定用戶,即沒法處理用戶沒有看過的文檔以及沒有過的查詢函數
條件成立是基於一個假設:用戶的查詢是用戶自身基於某個類似文檔而寫下的查詢關鍵字.net
用來描述某個句子造成某種特定序列可能行,好比「Today is Wednesday」,和句子 「Today Wednesday is」這二者的順序各有一種可能性。這種計算方式,很明顯的是它依賴於當前語句的,用處在於處理天然語言中的不肯定性,好比要知道某個句子「Today is」下一個單詞是」Wednesday」的機率。這種模型最簡單的狀況就是 Unigram LM3d
假設全部單詞都是互相獨立的,那麼單個句子成立的機率就是每一個單詞出現的機率。 就統計來講,我存在一個文檔庫,能夠統計每一個單詞出現的次數,一定會出現一個排列cdn
而對另外一語更具體的文檔庫,可能會存在另外一排列 於是根據不一樣的文檔庫,能夠統計出不一樣的單詞排列,這樣就能夠生成文檔主題;類似的,對於相關性而言,好比個人當前文檔庫是全部包含」computer」的文檔庫,那麼能夠計算出 另外對於全部的文檔庫而言,都會有一些公共的經常使用的詞庫,爲提高辨識度,須要去掉,能夠採用機率除法,來突出當前文檔庫的相關單詞機率給定一個查詢,根據Unigram LM的規則,它能夠被拆分紅單個單詞的機率乘積blog
於是能夠對不一樣的文檔作機率排列,可是若是當前詞沒有出如今文檔裏面,它的機率確定是0update 沒有出現排序
能夠看出這樣計算也存在問題,它是根據文檔中包含查詢語句的方式來計算的;反過來想,用戶的全部可能輸入當作一個文檔庫,那麼他也會有一個相對的排序,因此也會出現一個單詞排列,而這些排列中的單詞頗有可能不在須要查詢到文檔庫中。所以爲解決這些問題,能夠在計算機率上加上log運算函數,改爲加法便能獲得解決文檔
能轉換成全部的單詞是由於當全部單詞在查詢語句中沒有的時候,其實就是0,等價於在查詢語句中的有的狀況it
通過log處理後,機率計算方式最關鍵的在於計算如何計算全部單詞在文檔中出現的機率,通常來講,這是一個」階梯」函數
已知的是,當前函數沒有處理到文檔中沒有的單詞,爲了處理沒有的狀況,能夠加上平滑處理,即對於沒有出如今當前文檔中的單詞,這個單詞會出如今與當前文檔相關的文檔中【好比引用文檔】,這個時候整個文檔庫的機率計算方式變成這裏的C指的是與當前文檔庫相關的集合,或者換句話說,等價於整個文檔庫,只不過會有一個因子決定不一樣文檔庫的權重
此時計算方式變成
|q|等價於整個文檔庫中的單詞在查詢語句中出現的次數,也就是查詢語句自己所包含的單詞的數量
函數重寫後,對於排序來說,最後一部分,全部的文檔算出來的值都是同樣,因此能夠忽略【針對全部的文檔庫計算的】,對於中間的部分,能夠看到相對長的查詢有一個基於因子的log算法,某種程度上是對長度的一種懲罰,越長能夠選擇較大的因子,而對於第一部分來說,能夠看到,可見的文檔的單詞機率則相似於TF,不可見的文檔部分則至關於IDF的做用[在非當前文檔中出現的機率越大,做用反而越小]
VSM經過計算查詢與文檔之間的類似性,經過點積來計算大小並歸一化以後來做爲排序依據; 機率模型是統計總的次數做爲機率預估[有通用的文檔庫計算,以及具體的文檔庫],最簡單的方式是給全部的單詞機率作乘積來作排序計算