文字上的演算法讀書筆記六--搜尋引擎
6 搜尋引擎是什麼玩意兒
Google這家搜尋引擎公司的巨大成功,才把文字處理技術推向了一個新的高度。
6.1 搜尋引擎原理
假設Q為使用者要查詢的關鍵詞;為所有網頁集合中第i個網頁;表示給定一個Q,第i個網頁滿足了使用者需求的概率,那麼搜尋引擎乾的就是根據使用者的輸入Query(也包括一些隱性的資訊,比如地域等),在所有的網頁集合中計算,並排序返回給使用者。
如果按照之前的相關性方法把query和每一個網頁的相關性計算出來,然後排個序。但是網際網路的網頁數量多的驚人,這樣的方法計算量太大,因為大部分是和使用者查詢不相關的,不需要去計算,怎麼過濾到不相關的?
沒辦法計算,那麼計算等價方式,使用貝葉斯公式:
只與query自身有關,對於同一個query來說,它都是一樣的,所以可以不計算了。但是對分析整個query來說還是有用的,對於熱門query,較大,必須使右邊式子的分子更大才能滿足使用者需求,也就是說對排序要求越高;相反,對於冷門query,較小,右邊式子的分子不用太大都能滿足使用者需求,也就是說對排序要求較低。
比如使用者搜“騰訊網”(熱門query),如果哪個搜尋引擎第一條不是騰訊網的首頁連結,那麼這個搜尋引擎質量太差了,不能容忍。
比如使用者從某處複製了一串很長的文字(冷門query),放到了搜尋引擎中去搜,那麼只要搜尋引擎能返回包含該串的結果就行了,至於排到第一位還是第二位或是其他文職,只要不是很靠後,都可以接受。
第i個網頁的重要程度,與使用者查詢無關,可以線下計算好,可以簡單用網頁的pagerank表示。
給定一個網頁滿足了使用者的需求,那麼使用者的查詢是q的概率。反映了一個網頁滿足不同需求之間的比較。但是沒法窮舉所有的query,怎麼計算呢?假設query是由若干個片語成,那麼:
一種策略,如果我們認為之間相互獨立,那麼就有:
式子只與單個的詞有關,從query級別轉換成詞級別就可以線下計算了,都可以線下計算好存起來,需要用的時候取出來就可以了,同一個詞會在若干個文件中出現,那麼按某一種方式儲存起來,就可以一次全部取出來所在的所有文件,這就是索引。
一個Query由若干個片語成,上面的假設
上述叫概率語言模型。計算語言模型要平滑。
如果直接,可以用點選的方法,現在的搜尋引擎會記錄使用者在哪個query下點選了哪些網頁,以及順序,時間等,是不可以用所有使用者在該query下點選第i個文件的次數來表示,點的越多說明該文件越能滿足使用者需求,實際使用中是按照點選在已有相關性上調權,而不是直接用來排序。
6.2 搜尋引擎架構
搜尋引擎的工作流程是怎麼樣呢,如圖分為線下計算和線上計算兩大模組。
線下模組:
爬蟲會從網際網路上抓取所有網頁,抓取下來做很多事情:網頁解析,權重計算(包括計算pagerank值),然後對網頁建立索引,一般網頁是分庫分機來建索引的。
線上模組:
輸入一個query只會,首先會發到主控模組(MC,main control),該模組會把query輸入給query 分析模組(QA,query analysis),然後獲得query分析結果,之後把所有這些資訊發給每一個搜尋模組(SM,search model),搜尋模組就會從每個索引庫(index)中讀相關的索引並篩選排序,將結果返回給主控模組,主控模組這時候經過一系列調權(其中包括點選調權,呼叫點選模型(CM,click),進行rerank),最後從摘要庫(AD,abstract data)裡把相應的摘要獲取到一併將結果發給使用者。
6.3 搜尋引擎核心模組
爬蟲
從網際網路上爬取網頁,要求抓的儘可能抓的全,儘可能快。整個網路是一個圖,遍歷就有兩種,深度遍歷和廣度遍歷。工作方式是給定一些初始連結種子,然後對這些連結進行深度或廣度遍歷獲得更多的連結,注意,不要反覆抓取已經抓取過的連結。
網頁解析計算
包括網頁解析,權重計算,索引生成。
網頁解析:
解析,格式轉換(不同的格式有html,doc,pdf等檔案),去掉html等標籤,解析出網頁標題,正文,去掉網頁上的廣告等等。
權重計算:
特徵提取,權重計算。特徵提取就是從網頁中取出特徵,如title,meta等,還會計算出高階特徵,如主題匹配等。
權重計算包括term級別的計算和網頁級別的計算。 ,不同的位置,重要程度不一樣,比如Title比正文重要,就算出現在正文中,不同的位置及不同的標籤也對權重有影響。網頁級別的計算就是計算網頁的特徵,比如:時間因子,頁面是否豐富,網頁主題,超載權重等,用於調權。
索引生成:
數量量太大,索引庫要分庫,分為:橫向和縱向。不同的搜尋引擎會有不同的分法,但是總的原則是分為高質量庫和低質量庫,就像金字塔,塔上面是高質量庫且網頁數量少,塔下面是低質量庫且網頁數量大。
縱向就是先在高質量庫中檢索,如果滿足要求就返回,否則再去低質量庫中檢索。
不管是高質量庫還是低質量庫都有很大的資料量,不可能一臺機器搞定,所以分為小庫分別部署到不同的機器上,橫向的就是檢索高質量庫或者低質量庫的時候,回去同時檢索每臺機器的小庫,然後彙總歸併。
query 分析模組(QA):
對使用者輸入的query進行解析,供下游檢索使用。
包括:
1. term級別分析
分詞/專有名詞,term重要性,term緊密程度。
分詞/專有名詞:
專有名詞識別方法包括詞表識別(影視名、音樂名等)和機器學習識別(人名、地名、機構名)
term重要性計算
一個query會包括多個term,那麼就要給term計算一個權重,權重越高越重要。
tf*idf,tf是區域性資訊,idf 是全域性資訊。但是tf在query 一般是1.如果只用if*idf,只用了idf。效果不好,優化即對tf優化。作用為一是計算相關性,二是對不重要的詞可以省略,擴大召回。
term緊密度
term緊密度是用來計算term之間的位置資訊的。如query 是老大的幸福線上觀看(老大/的/幸福/線上/觀看),老大的幸福是最緊密的,因為是專有名詞,以為這不能分開,要合併要一起。線上/觀看,是其次緊密的,儘量合併,分開也可以接受。老大的幸福和線上觀看是不緊密的。也是用來相關性排序的。
2.query級別分析
query需求識別:
query 是什麼型別的,比如:視訊需求,是百科需求,還是小說需求等。因為不同的類別對相應網頁有不同的提權。一般query需求識別有:1.模板匹配 2.基於分類思想的識別方法 3.根據點選反饋來判斷意圖
query時效性判斷:
時效性分為三種:泛時效性,週期時效性,突發時效性。
泛時效性是指有些query永遠有時效性,比如減肥,永遠是熱門話題。
週期時效性具有周期性的事件,比如高考,世界盃等
突發時效性:突然發生的事件。比如寶強離婚,文章出軌等
前兩個可以根據歷史資訊可以積累。後一種根據query log的分佈變化檢測出來。
3.query 變換
替換成另一個query而不改變原來的意思。主要包括:同義改寫,糾錯改寫,省略變換等,還有些關聯擴充套件等。
同義改寫:
query中某些term替換成其他同義的term而不影響這個句子的意思。比如:招商銀行官網-招行官網
糾錯改寫:
query是指query中有些是使用者輸錯的,需要跟據使用者的意圖把它改寫正確。如薛子謙-薛之謙
省略變換:
省略不影響整個意思,比如招行客服電話-招行電話
目的是termA替換成termB整個句子的意思沒有變化,省略變換其實就是termA替換成空,一個特例。
一定是句子級別的替換,否則會出現重大的badcase。
例如南航網上值機如果替換成南京航空航天大學網上值機就是錯誤的。意思偏離了。
大多數搜尋都不是句子級別的替換而是直接同義詞替換去索引,然後對同義結果降權,其實是不好的。
句子級別應該是相當於一個新的query,就像對待原query 一樣去檢索,不同的query召回的結果放在不同的佇列中,最後將權重歸併起來。
給定query S,找到最佳替換T的模型是:
替換對的挖掘及概率計算,語言模型的引數估計,最優解的搜尋演算法等。
主控模組(MC)
職責包括排程和rerank
排程:
query發給QA,獲得分析結果,然後把結果發給SM模組,獲得結果,進行Rerank操作,然後從AD模組中獲得摘要資訊,返回給使用者。
Rerank:
SM中返回的結果要進行調權,大概有這麼多的因素:頁面質量調權,Query需求調權,時效性調權,多樣性調權,點選調權等。
點選調權是很重要的模組,線下對query的點選行為做很多的計算,它有好幾種模型,如論文
《A Dynamic Bayesian NetworkClick Model for Web Search Ranking》 對DBN講的很清楚。
還有對多個佇列,單佇列調權和多佇列調權。也可以從AD中獲取網頁的正排資訊,進行更精細的排序。
搜尋模組(SM)
負責將結果從索引庫中召回並按照相關性返回給MC模組。
細節如下:
首先獲得最基本的結果,進行一次過濾,先索引歸併,然後計算相關性:term權重*位置資訊,一般搜尋引擎只用到Proximity層面,當然也可以加入語義資訊。當一次篩選後,還會進行二次過濾。二次過濾會根據頁面屬性進行篩選(比如頁面質量,死鏈等)。前兩次篩選其實是在單褲,多庫結果彙總之後可能還要過濾。得到url表。
有不少引數,調參是一件頭疼的事情,於是可以使用機器學習來解決這個問題。Learning to rank,排序。
pointwise方法:
將排序問題轉化為多類分類問題或者回歸問題,就是講(query,di)結構作為一個類別(5個類別,Perfect=5,Excellent=4,Good=3,Fair=2,Bad=1)作為一個類別。只要(query,document)的相關度相同,比如都為perfect,就會被放在一個類別裡,即屬於同一類的例項,而無論query是什麼。比較簡單,但效果不是很好。實現方法有McRank。
pairwise 方法:
排序問題轉化為二元分類問題。對於同一個query,在它的所有相關文件裡,對任兩個不同的Label的文件,都可以得到一個訓練例項對,如(d1,d2)分別對應5和3,則賦予+1,以及-1。這樣的方法不再是query獨立的,但是缺點是不同query的訓練集的數量會出現不均衡的問題,對相關文件集小的query所產生的訓練例項區分不好。實現Pairwise方法有RankSVM,RankNet,FRank和rankBoost等。
Listwise方法:
直接對排序結果進行優化。給定一個query,以及其對應的document list,現在得到了一個標註好的分數列表z(每個文件的點選率等)。然後採用某個函式f給每個document打分,得到一個預測排序得分列表y,然後採用某種損失函式計算loss(listNet採用交叉熵,即將z和y帶入交叉熵公式中作為損失函式學習引數)。實現方法有ListNet,RankCosine,SVM-MAP等。
索引
索引結構如圖,把文件的正排資訊(一個文件有若干個term組成。每個term有位置,權重等屬性)建立索引(倒排資訊,從term找到所對應的文件)。
一個索引結構其實可以簡單看做key-value結構,termA在docid1和docid2中出現,且在docid1中分別出現在pos1和pos2的位置上,且屬性(例如權重)分別是attr1和attr2,一般是按照文件號遞增的來儲存的,怎麼排序取決於用什麼演算法歸併。問題是如果來了這樣的一個query,分詞後有多個term,怎麼找到包含這些term的文件呢?就是要怎麼歸併這些key-list。有兩種方法:TAAT和DAAT。
Term-At-A-Time(TAAT):
TAAT查詢時,每次只打開一個term對應的倒排表(list),然後對其進行完整的排序。每處理一個文件只能得到這個詞對這篇文件的貢獻,只有處理完所有term的倒排鏈後,才能獲得文件的完整的得分。通常需要一個數組來儲存文件的臨時分數,這個陣列的大小通常需要一個數組來儲存文件的臨時分數,大小與文件集規模相當,文件集很大時,額外的陣列儲存開銷會變的非常大。
Document-At-A-Time(DAAT):
DAAT查詢時,首先會開啟各個term對應的倒排鏈。然後對這些倒排鏈進行遍歷。每次對當前文件號最小的文件計算相關性得分。在處理下一篇文件之前,它會完整的計算出當前處理文件的最終相關性得分。只需使用較少空間來儲存當前得分最高的文件及其得分,通常使用優先佇列來儲存。
資料量大的時候DAAT的方式進行查詢歸併,用的更多的是基於文件號遞增排序的倒排索引結構。一般資料量大的時候,每個term對應的倒排鏈會很長,如果都遍歷的話,效能不高,使用跳錶解決。
跳錶是簡單而高效的資料結構,redis和leveldb都使用了跳錶作為核心資料結構。是有序鏈,在原連結串列上設定了若干層的有序連結串列,每一層都比上一層的節點要少。如39,可通過紅色路線查詢到。比原連結串列路徑要短,加快連結串列歸併。
跳錶論文:《Skip Lists: a Probabilistic Alternativeto Balanced Trees》
跳錶優化只對AND有用,對OR不起作用。要滿足OR查詢可以用剪枝限界。
MaxScore和Weak-AND,通過計算每個term的貢獻上限來估計文件的相關性上限,從而建立起一個閾值對倒排中的幾個進行剪枝,提速。
知道一個term的相關性上界值,可以知道一個query和一個文件的相關性上限值,就是他們共同term的相關性上限值的和,然後和一個閾值(TOP-N的最小值)比較,小於則跳過。
細節參考論文《EfficientQuery Evaluation using a Two-Level Retrieval Process》
還有根據term的重要性,有時為了增加召回,可以去掉不重要的term。
索引的不同資訊會被分在不同的庫中,分佈是詞典庫(term以及其在索引庫的位置偏移,一般常駐記憶體),位置庫(存放term的其他屬性,根據資料規模決定存放磁碟還是記憶體),屬性庫(存放term的其他屬性,詞頻,權重等等,也是根據資料規模決定存放磁碟還是記憶體),跳錶庫(存放跳錶指標,一般常駐記憶體);
查庫順序:首先查詞典庫,根據位置偏移查詢相關資訊,對於磁碟的話,可能會用到別的資料結構(有序陣列,B+樹或者LSM樹,為的是提高效能,因為磁碟I/O操作效能不高,減少I/O操作),一般的網頁可能會分域,還需要很多的技術。
引擎評價指標
有NDCG、MAP、MRR、AB-testing
DCG:
基於兩點假設
1.高相關性的文件比邊緣相關的文件要有用的多。
2.一個相關文件的排序位置越靠後,對使用者的價值越低。
作為衡量一篇文件的有用性或者增益,DCG方法的定義為:
是排序位置為i的文件的相關性等級(分為5等,非常差(1),差(2),一般(3),好(4),非常好(5))
便於平均不同查詢的評價值,可以通過將每個排序位置上的DCG與該查詢的最優排序的DCG值比較,得到一個歸一化的值。
即為某一查詢的理想的DCG值。
舉例:一組6個文件的排序的相關性等級和理想等級分別為:
可以計算出它們對應的DCG值分別為:
那麼
重要的步驟就是快取cache,提高效能。
query log和點選資料進行各種挖掘工作,比如新詞、擴充套件等,算是搜尋引擎特有的優質資源。
6.4 搜尋廣告
搜尋引擎怎麼贏利的呢,廣告!
廣告常見的術語有:
CPC(cost per click):每次點選的費用,按照廣告被點選的次數收費。
CPM(cost per Mille/cost per thousand click-through):每千次印象(展示)費用,廣告每展示1000次的費用。
CPA(cost per action):每次行動的費用,按照使用者對廣告採取的行動(完成一次交易,產生一個註冊使用者等)收費
CPS(cost per sales):以每次實際銷售產品數量來收費
CPL(cost per Leads):根據每次廣告產生的引導(通過特定連結,註冊成功後)付費。
CPD(cost for day):按天收費
CTR(click through rate):廣告的點選率
CVR(click value rate):廣告的轉化率
RPM(revenue per mille):廣告每千次展示的收入
廣告一般分為:品牌廣告和效果廣告
品牌廣告
是用來樹立品牌形象,目的在於提升長期的離線轉化率,不要求購買,希望當你需要該產品的時候可以想起這個品牌。
效果廣告
分為:展示廣告和搜尋廣告
展示廣告
廣告系統找到該網民與context上下文(網頁等)滿足相應投放設定的廣告
做的最好的是實時競價廣告RTB(real-time bidding)
同一個廣告位,不同的人看到不同的廣告,更加精準
需要不同的參與方合作完成:
1.AD exchange(廣告交易平臺):服務的中心,相當於交易所的功能
2.DSP(demand side platform 需求方平臺):供廣告主使用的平臺。廣告主可以在這個平臺設定受眾目標,投放區域和標價等
3.SSP(sell side plateform 供應方平臺):供應方使用的平臺,供應方可以在SSP上提交他們的廣告位
4.DMP(Date management platform,資料管理平臺):面向各個平臺的,主要用於資料管理、資料分析等
舉例:
RTB的廣告流程:
騰訊有個廣告位進入到了某個SSP平臺,而這個SSP平臺把廣告位的展示放在AD中,現有兩個廣告主,一個是賣體育用品的耐克,一個是賣汽車的寶馬。耐克選擇DSP1,
搜尋廣告
廣告系統找到與使用者輸入的query(及網民)相關且滿足投放設定的廣告,設定如果某使用者是體育愛好者,就出1塊錢去競拍這次的廣告位,寶馬選擇DSP2平臺,如果是汽車愛好者,出2塊錢展示。使用者瀏覽騰訊網是,AD告訴DSP1和DSP2.根據cookie,去DMP找這個cookie的資料,發現搜尋過籃球,歸為體育愛好者,然後DSP1告訴AD,有個耐克的客戶,願意出1塊錢,DSP2去cookie中發現瀏覽過某個汽車網,歸為汽車愛好者,告訴AD,有個寶馬的客戶,願意出2塊錢。
AD拿到DSP1和DSP2的出價資料後,發現DSP2出價高,競拍成功。
廣告交易平臺(AD exchange模式),相比傳統的廣告網路,優點是更偏重於對使用者的精準投放。
搜尋廣告整體框架
4大業務:
業務系統
廣告主管理個人資訊,管理廣告,購買廣告等操作,還要對使用者的消費產生報表等
檢索系統
完成整個廣告的檢索
計費統計系統
對使用者的點選產生計費,記錄一些其他的資訊
反作弊系統
打擊各種作弊行為,保護廣告主的利益
搜尋廣告的檢索系統
與搜尋引擎類似
首先query解析,做些分詞、query變換、意圖分析等等
發給觸發系統,幫助query找到最相關的廣告,匹配有精確匹配,短語匹配,廣泛匹配
精確匹配:一模一樣
短語匹配:是query的一個子集
廣泛匹配:短語匹配的進一步放鬆限制,在分詞,倒序,同義替換,上下位替換上加了近義替換、相關詞等操作。
排序模組:
對召回的廣告排序,規則是,就是拍賣詞的出價,Q是廣告質量。
pctr是預估的點選率。
找打使用者越可能點選且出價高的廣告
用的邏輯斯蒂迴歸。
ctr預估就是使用邏輯迴歸來計算的,一般用到3個特徵:
query特徵,使用者特徵和廣告特徵。每一維度特徵都是很大的,ctr預估特徵都是百億甚至千億級別的。
展示,觸發計費系統。
扣錢採用廣義的二階價格(GSP),即:
6.5 推薦系統
推薦系統是給某個使用者推薦了某件物品(在社交網路中物品也可以是人)。所以使用者和物品就是推薦系統的兩個關鍵。根據對這兩個點的不同定位就會產生不同的演算法。所有使用者相同對待來處理(不考慮使用者因素)?
還是按不同屬性大致劃分後再處理(將使用者分類/聚類來處理)?
或是每個使用者都不同對待來處理(完全的個性化)
對於物品也有類似這樣的區分:不考慮物品的具體內容,對物品分類/聚類,完全區分物品
不像搜尋系統有那麼清晰的架構流程,
大致來說,分為:
基於協同過濾的推薦演算法和基於內容的推薦演算法,還有基於知識的推薦,就是根據使用者的一些約束條等來匹配出待推薦的物品
基於協同過濾的推薦演算法(Collaborative filtering,CF)
協同過濾是個典型的利用集體智慧的方法,思想很容易理解:如果某個使用者和你的興趣相似,那麼他喜歡的物品很有可能是你喜歡的。
第一步就是要收集使用者興趣,然後根據使用者興趣計算相似使用者或者物品,之後就可以推薦了。
產生兩種協同過濾方法:基於使用者的協同過濾(user-based CF)和基於物品的協同過濾(Item-based CF)
使用者和物品的關係可以表示一個句子(表),每一行是使用者對相應物品的打分。如何根據協同過濾計算出小明對Item5的打分,如果打分高,那麼就可以把Item5推個小明瞭。
基於使用者的協同過濾
根據使用者記錄,找到和目標使用者相似的N個使用者,然後根據這N個使用者對目標物品的打分計算出目標使用者對目標物品的預測打分,然後決定要不要推薦。
首先要計算使用者之間的相似度,使用者間的相似度用皮爾森相關係數效果好一點。計算完後,發現小明和其他四個使用者的相似度了。小明與user1和user2最相似。接下來就是根據User1和User2對Item5 預測小明對Item5的打分,
是使用者u對物品i的打分,表示使用者u和使用者v的皮爾森相關係數,表示使用者v對物品i的打分,表示使用者的u的平均打分。
計算出小明對所有物品的打分預測值,然後把高的top-n推薦給小明就可以了。
基於物品的協同過濾
利用其它使用者間物品相似度進而計算預測值。首先計算出與Item5最相近的物品,物品之間的相似度可以用餘弦相似度表示,確定了相似度後,可以通過小明對所有Item5相似物品的加權評分綜合來預測小明對Item5的預測值了,
兩種方法的優缺點
基於使用者的需要實時計算使用者的相似度,計算量大且頻繁,擴充套件性也不強。
基於物品的計算物品的相似度可以線下計算,減少線上的計算量,大型電子商務一般用這種方法。
當網站使用者量和物品數量很多時,計算量還是很大的,為了降低計算量,提出slope One預測器
論文《Slope One Predictors for Online Rating-Based Collaborative Filtering》
協同過濾還有兩個大問題:1.資料稀疏問題。使用者一般只會評價少部分物品。所以居住就會非常稀疏,對精度有很大的影響。
2.冷啟動問題,對於還未做過任何評分的使用者或者從未被評分的物品就直接用協同過濾了
基於模型的協同過濾方法
使用奇異值分解對矩陣處理,同時可降維
參考論文《Application of Dimensionality Reduction in Recommender System -- A Case Study》
還有把預測某個使用者對某個物品的評分看成分類問題(1-5),這樣就可以使用貝葉斯等分類器來計算出該使用者對某個物品的打分屬於哪列。
關聯規則,通過對使用者記錄學習出一組關聯規則集合,然後就可以通過這些規則預測使用者對物品打分了。
都是基於其他使用者對某個使用者的操作。沒有考慮物品的基本內容是什麼,而物品的內容有額很有資訊量。
基於內容的推薦方法
淡化了使用者,更多的從內容(物品特徵屬性的描述)的相似度決定是否推薦
分類/聚類方法
把推薦問題可以看出一個分類問題,根據使用者對已有的內容的打分(一般用點選行為,也就是點選了是正例,否則是反例)訓練了分類模型(lr),而聚類問題就是看和某物品聚到一起的其他問題的打分情況來決定對這個物品是否要推薦。
搜尋方法
通過搜尋要推薦的物品找出最相似的物品,然後推薦給使用者。與搜尋引擎的區別是搜尋引擎提交的是query,而這兒提交的是物品,根據不同的場景(視訊推薦,新聞推薦,APP推薦)會有不同的搜尋條件和排序策略。搜尋引擎的結果一定要精確,而這兒的推薦系統結果要發散一點,只要不是太差都可以接受。
參考論文google的一篇《Up Next: Retrieval Methods for Large Scale Related Video Suggestion》
總結
總的來說,就是先找出可能推薦的集合,然後排序推薦出來,還要注意多樣性等一些策略,但是針對不同的場景(視訊推薦,新聞推薦,APP推薦)設計不同的演算法和策略
《App Recommendation: A Contest between Satisfaction and Temptation》
論文提出了APP推薦模型,比如手機上已經裝了天氣預測的APP,再推薦下載慾望非常低,但是對於電影問題就少一點,看了速度與激情1,給推薦速度與激情2,3,覺得還可以。
點選是重要的反饋指標,反映了使用者的興趣,推薦系統更多的是和場景相關,很難把一個場景的推薦演算法完全照搬到別的場景上用。目的是能產生某種行為(點選、購買等),本質是預測能力。好的推薦系統就是最大化達到目的的預測器。