演算法評分機制
A. 從豆瓣電影評分演算法說起
在PingWest看到一篇《豆瓣電影打分規則竟如此簡單粗暴…》，作者寫這篇文章是因為豆瓣創始人阿北最近寫了一篇博文《豆瓣電影評分八問》，阿北博文是為了回應一些外界對豆瓣電影評分的質疑，然後作者看到這篇博文後，覺得豆瓣電影的評分演算法有點low，就寫了這樣一篇吐槽文章。
那麼這個很low的演算法究竟是什麼樣子的呢？此處引用阿北原文。
簡單說就是計算每部電影評論的算數平均值，並按此值來排名。
對這個演算法持懷疑態度，因為如果按照這神手個演算法的話，假設一部小眾文藝片有10個用戶給了全五星，和一部經典老片比如《十二怒漢》相比，小眾文藝片排名比《十二怒漢》還要高，不過這在豆瓣電影TOP250裡面不太可能。阿北可能只是為了文章寫作方便或是保密起見，把演算法故意說簡單了，因為假如豆瓣公布了詳細的演算法，那電影發行方的水軍們十分有可能針對這個演算法制定出有效的刷分策略的。可憐我還真信了。
下面是阿北當年在知乎上的 回答 。
順著PingWest這篇文章給的鏈接，我又去阮一峰博客看了他在2012年寫的《基於用戶投票的排名演算法》系列文章，以及這些文章里的參考文章，發現排名演算法很好玩很有趣，非常有收獲，推薦閱讀。
看完這些文章，我就想知道知乎的評論排名演算法是怎麼樣的，於是去知乎找到他們產品經理 @黃濤的回答 ，知乎在2014年底更新的演算法使用的正是Reddit在2009年引入的評論排名演算法，也就是阮一峰老師在系列文章第5篇中介紹的「威爾遜區間」演算法。在用這個演算法之前，知乎用的是直接利用好評減去差評的結果來給評論排序，這種演算法的缺點我就不介紹了，可以查看參考資料[1]。
「威爾悉磨遜區間」演算法的數學基礎是數學家Edwin B. Wilson在1927年提出的威爾遜區間修正公式，後來芝加哥工程師Evan Miller在2009年寫了一篇 博客 ，認為該修正公式睜瞎斗可以用來做排名。
這個演算法的核心思想是這樣的：
因為常見的置信區間計算公式「正態區間」不能很好的照顧小樣本數量的准確性，而威爾遜提出的修正公式能很好地修正小樣本數量的准確性問題，所以大家採用「威爾遜區間」演算法較多，像Reddit、Yelp、Digg，還有知乎。
不過這種演算法也有缺點，缺點就是對於那些得票少的新評論很難獲得出頭之日，因為得票少，置信區間就會寬，排名位置就會低，得到的關注也就會更少。
前面阿北的回答裡面提到了IMDB，IMDB是亞馬遜旗下的一個類似豆瓣的電影排名網站，他們在處理TOP250電影排名問題時採用了「貝葉斯平均」演算法來解決，這個演算法的核心思想是既然新興產品的評分數量很少，那我就為你人工補償一定的投票。關於這種演算法在阮一峰老師系列文章第6篇中有介紹。
更多參考資料：
B. 層次分析法的打分機制
如果寫這篇文章僅僅是介紹層次分析法的理論，顯得完全沒有必要。層次分析法作為最早接觸到的一批演算法，登山、旅遊的決策案例聽過太多遍了。
本文想講一講層次分析法在打分機制上的應用。
詳細內容查看 AHP層次分析法的步驟和方法
層次分析法繞不開的第一步就是確定層次結構.(需要特徵在三個及三個以上，否則無法滿足一致性檢驗)
建立對比矩陣C，判斷准則層三個特徵對項目而言的重要程度。
使用專家評分的方式，評定對於項目而言各個特徵的比較分值。
例如下圖第一行技術風險A2比環境風險A1重要很多，非技術風險A3比環境風險A1重要一點。
矩陣C按列歸一化處理，新矩陣B按行求和/n得到每個特徵的權重：0.64794686, 0.12218196, 0.22987118
該矩陣滿足一致性檢驗，CR=0.003
此方法適用方案層有三個及以上的參與者。理由是RI在n=1,2時，值為0，會導致一致性檢驗不滿足要求。
A1條件下
整體環境風險A1下，三個候選人D1、D2、D3的比較。
滿足一致性檢驗，CR = 0.056740233073197095
三個項目在A1條件下，各自的權重為：0.193, 0.083, 0.723。
A2條件下
技術風險A2下，三個候選人D1、D2、D3的比較
滿足一致性檢驗，CR = 0.015807980379472106
三個項目在A1條件下，各自的權重為：0.137, 0.623, 0.239
A3條件下
非技術風險A3下，三個候選人D1、D2、D3的比較
滿足一致性檢驗，CR = 0.056475713035283585
三個項目在A1條件下，各自的權重為：0.283, 0.643, 0.074
三個項目評分
項目甲D1在環境風險A1、技術風險A2、非技術風險A3下的分值分別為0.193、0.137、0.283。所以項目D1的總得分為=分值 * 特徵權重。
SCORE = 0.193 * 0.64794686 + 0.137 * 0.12218196 + 0.283 * 0.22987118 = 0.20696492
同理計算出項目乙得分0.27802246，項目丙得分0.51501263。所以丙是最合適的選擇。
項目甲D1在環境風險A1、技術風險A2、非技術風險A3三個方面的得分分別為72, 78, 88；
項目甲D2在環境風險A1、技術風險A2、非技術風險A3三個方面的得分分別為68, 90, 94；
項目甲D3在環境風險A1、技術風險A2、非技術風險A3三個方面的得分分別為98, 80, 78；
項目總得分為=分值 * 特徵權重。
甲乙丙三個項目得分分別為：77.49、79.93、86.43，丙為最優選擇。
已經根據層次分析計算出每個特徵的權重。
方法一是採用方案層在每個特徵下的比較；方案二是直接對每個項目打分；但這類打分人工隨意性比較大。還可以採用模糊評價法，設置評價集V={很好，好，一般，差}，找20個人來打分，數值為打這些分的人數。
對矩陣歸一化後為M，得分 = 權重 * M，再歸一化 。
D1 = [0.23, 0.23, 0.17, 0.37]
同理計算出項目乙D2，項目丙D3的模糊得分
D2 = [0.17, 0.31, 0.40, 0.12]
D3 = [0.46, 0.18, 0.24, 0.12]
說明項目甲23%程度為很好，23%程度為好，17%程度為一般，37%程度為差;
說明項目乙17%程度為很好，31%程度為好，40%程度為一般，12%程度為差;
說明項目丙46%程度為很好，18%程度為好，24%程度為一般，12%程度為差;
要求很好、好的概率在60%以上，因此項目丙是最優選擇。
覺得三個特徵還能繼續深入。擴展准則層。
第一步 ：建立A1,A2,A3三個大特徵的對比矩陣，計算三個特徵的權重W1、W2、W3。
第二步 ：特徵A1下有B1、B2、B3、B4四個特徵，建立B1、B2、B3、B4的對比矩陣，計算特徵的權重w11,w12,w13,w14;
特徵A2下有B5、B6、B7三個特徵，建立B5、B6、B7的對比矩陣，計算特徵的權重w21,w22,w23;
特徵A3下有B8、B9、B10三個特徵，建立B8、B9、B10的對比矩陣，計算特徵的權重w31,w32,w33。
B1、B2、B3、B4，...，B10的特徵權重為w11 W1，w12 W1，w13 W1，...，w33 W3
第三步 ：分值計算。
先設置項目在B系列特徵的得分a1,a2,...,a10,項目總得分為sum(權重*得分)。
（1）以上專家評分是在滿足邏輯的前提下，一堆亂打的分值。所以層次分析法的打分質量的好壞影響判斷，專家打分人為因素太強，解釋性不夠。
（2）准則層涉及的特徵不宜過多，特徵太多人工寫分數很麻煩。
層次分析法在項目風險分析中的應用
絕對打分方法
C. 豆瓣評分是怎麼計算出來的
眾所周知，在中國的電影觀看者心中，豆瓣電影的評分是很強大的一個參考標准。一些有文藝情懷的青年可以在此閑話國際新浪潮，批判一些超現實主義，而迷妹們可以為自己心中的偶像所，參演的影片點贊，支持……更多的人，可能根本對電影沒有太多研究，甚至只憑喜好或者「聽別人說」而去觀影的同時也會選擇在買票之前參考一下豆瓣電影的評分。
可以說，豆瓣電影的評分一度成為大家評價電影質量的標桿，甚至可以影響一部電影的票房高低，那麼豆瓣電影的評分標准到底是怎樣的呢?
上訴圖片是2015 年的時候豆瓣總經理阿北發表的一篇長文中所說的，意思很明確，豆瓣電影的評分就是基於用戶打分：把豆瓣用戶的打分(一到五星換算為零到十分)加起來，再除以用戶數。就是豆瓣電影的評分，這個分數完全來自程序的計算，中間沒有編輯審核，每隔幾分鍾就自動更新一下，以便快速的展現出及時的評分。
可以說，這是一個「簡單粗暴」的評分機制。觀眾的評價將以非常直接的方式反映在電影的分數上，心情好時打的「五星」和心情不好時的「一星」都將被加入到簡單的計算公式中，最終變成其他人的參考標准。
但同時，阿北也說到，豆瓣也是有「非正常打分」規避機制的。作為一個擁有一億多用戶的「大眾評審團」，每個用戶都是「一人一票」制，而且隨著打分人數的增加，單人評分對整體評分走向的影響其實是在不斷被稀釋。因此，評分計算方法很簡單，但「刷分」基本上是不可能的。
所以，總體來說，豆瓣的電影評分是參與評分人群的意見「平均值」，雖然有很多的規避以及防範措施，但總體上受評分人個人喜好的影響較大。但我們都知道，豆瓣的用戶，更多的是在全國一二線城市，而且受眾群體大多數都是人們口中所謂的文藝青年們，所以，對於擁有相對「高端」用戶群體的豆瓣，其評分還是偏「小眾」的
D. 英國高考採用演算法打分，這是一種什麼樣的打分方式
近期因為疫情，英國高考採用了一種演算法打分方式，簡要來說就是，老師先根據學生平時的學習表現預估出各科目的“原始分”，然後再將原始分輸入進電腦，通過演算法程序得出各科目的“最終分”——然後學生的高考成績單就出來了。
雖然美其名為“演算法打分制”，但明眼人一眼就看出，這種打分機制的關鍵決定權，其實是掌握在老師的手裡。
而所謂的“演算法”反而更像一塊“黑盒子”——或者說“遮羞布”？
當分數主要由老悶明師的主觀喜好決定的時候，“不公正”與“暗箱操作”自然也就無可避免了，這是正常人都一清二楚的事情。
由於我國古代沿襲了上千年的科舉制，我國人民對於高考的態度那是相當嚴肅，正因如此，當英國政府表現出對於高考如此兒戲的態度時，著實是驚掉了一螞洞告大群人的下巴。
E. 《王者榮耀》對局評分演算法是什麼
戰績(KDA)：死亡次數越少、擊殺數量越多、助攻數量越多，KDA評分就會越高。
參團率：個人單局擊殺和助攻的總數占我方全隊人頭數的比例，多參與團戰參團率自然就高。
金幣/分鍾：單局個人每分鍾獲得的經濟，經濟主要依靠擊殺敵方英雄、小兵、野怪以及摧毀對方防禦塔來獲得。
英雄傷害/分鍾：單局個人每分鍾對敵方英雄輸出的傷害，adc和apc的輸出一般比較高。
承受傷害/局：單局個人承受的傷害，坦克和肉輔通常是作為前排吸收傷害。
建築傷害/局：單局個人對敵方建築造成的傷害。
傷害轉化比
在《王者榮耀》新賽季手游中，游戲對局中的傷害轉化比指的是在本局中，傷害佔比/經濟佔比=傷害轉化比，數值越大說明玩家經濟吃的不多但是輸出非常可觀，而接近於1則表明持平。傷害轉換比可以理解為傷害轉換率，傷害佔比/經濟佔比*100%=傷害轉換率；比如：
1、傷害佔比30%，經濟佔比19% ，傷害轉化比就是1.6。
2、傷害佔比24%，經濟佔比23%，傷害轉化比就是1.0。
F. 王者榮耀評分是怎樣計算的 王者榮耀MVP計算方法
王者榮耀MVP計算公式：MVP=(擊殺+助攻)/死亡
在王者榮耀5v5競技中想要獲得MVP，就得格外注意K、D、A，也就是擊殺、死亡、助攻，本場最佳英雄公式為MVP=(K+A)/D，按照這個公式來說MVP不一定是擊殺最多的人，想要獲得MVP除了擊殺之外就是助攻了，擊殺助攻越多死亡越少那麼獲得MVP的機會也就越大。我們自己來計算的時候就是擊殺加上助攻除以死亡，得出來的數字最高的人就是本場的MVP，當然本場戰斗的勝利也是決定拿勝方MVP和敗方MVP的重要因素。
G. Elasticsearch——評分機制詳解
一個搜索引擎使用的時候必定需要排序這個模塊，如果在不選擇按照某一欄位排序的情況下，都是按照打分的高低進行一個默認排序的，所以如果正式使用的話，必須對默認排序的打分策略有一個詳細的了解才可以，否則被問起來為什麼這個在前面，那個在後面？
將查詢作為輸入，將每一個因素最後通過公式綜合起來，返回該文檔的最終得分。這個綜合考量的過程，就是將相關的文檔被優先返回的考量過程。
Elasticsearch是基於Lucene的，所以它的評分機制也是基於Lucene的。在Lucene中把這種相關性稱為得分（score），確定文檔和查詢有多大相關性的過程被稱為打分（scoring）。
ES最常用的評分模型是 TF/IDF和BM25，TF-IDF屬於向量空間模型，而BM25屬於概率模型，但是他們的評分公式差別並不大，都使用IDF方法和TF方法的某種乘積來定義單個詞項的權重，然後把和查詢匹配的詞項的權重相加作為整篇文檔的分數。
在ES 5.0版本之前使用了TF/IDF演算法實現，而在5.0之後默認使用BM25方法實現。
relevance score相關性算分：簡單來說，就是計算出，一個索引中的文本，與搜索文本，他們之間的關聯匹配程度。
通過倒排索引可以獲取與查詢語句相匹配的文檔列表，那麼如何將最符合用戶查詢需求的文檔放到前列呢？
本質是一個排序問題，排序的依據是相關性算分。
Elasticsearch使用的是 term frequency/inverse document frequency演算法，簡稱為TF/IDF演算法。TF詞頻(Term Frequency)，IDF逆向文件頻率(Inverse Document Frequency)
相關性算分的幾個重要概念如下：
ES目前主要有兩個相關性算分模型，如下：
BM25中的IDF公式為：
原版BM25的log中是沒有加1的，Lucene為了防止產生負值，做了一點小優化。雖然對公式進行了更改，但其實和原來的公式沒有實質性的差異，下面是新舊函數曲線對比：
BM25中TF的公式為：
其中tf是傳統的詞頻值。先來看下改良前後的函數曲線對比（下圖中k=1.2）：
可以看到，傳統的tf計算公式中，詞頻越高，tf值就越大，沒有上限。但BM中的tf，隨著詞頻的增長，tf值會無限逼近(k+1)，相當於是有上限的。這就是二者的區別。一般 k取 1.2，Lucene中也使用1.2作為 k 的默認值。
在傳統的計算公式中，還有一個norm。BM25將這個因素加到了TF的計算公式中，結合了norm因素的BM25中的TF計算公式為：
和之前相比，就是給分母上面的 k 加了一個乘數 (1.0−b+b∗L)(1.0−b+b∗L)。 其中的 L 的計算公式為：
其中，|d|是當前文檔的長度，avgDl 是語料庫中所有文檔的平均長度。
b 是一個常數，用來控制 L 對最總評分影響的大小，一般取0~1之間的數（取0則代表完全忽略 L ）。Lucene中 b 的默認值為 0.75。
通過這些細節上的改良，BM25在很多實際場景中的表現都優於傳統的TF-IDF，所以從Lucene 6.0.0版本開始，上位成為默認的相似度評分演算法。
上例是通過similarity屬性來指定打分模型，用到了以下三個參數：
如果我們要使用某種特定的打分模型，並且希望應用到全局，那麼就在elasticsearch.yml配置文件中加入：
通過boosting可以人為控制某個欄位的在評分過程中的比重，有兩種類型：
通過在mapping中設置boost參數，可以在索引期間改變欄位的評分權重：
需要注意的是：在索引期間修改的文檔boosting是存儲在索引中的，要想修改boosting必須重新索引該篇文檔。
一旦映射建立完成，那麼所有name欄位都會自動擁有一個boost值，並且是以降低精度的數值存儲在Lucene內部的索引結構中。只有一個位元組用於存儲浮點型數值（存不下就損失精度了），計算文檔的最終得分時可能會損失精度。
另外，boost是應用與詞條的。因此，再被boost的欄位中如果匹配上了多個詞條，就意味著計算多次的boost，這將會進一步增加欄位的權重，可能會影響最終的文檔得分。
查詢期間的boosting可以避免上述問題。
幾乎所有的查詢類型都支持boost，例如：
就對於最終得分而言，加了boost的name查詢更有影響力。也只有在bool查詢中，boost更有意義。
boost也可以用於multi_match查詢。
除此之外，我們還可以使用特殊的語法，只為特定的欄位指定一個boost。通過在欄位名稱後添加一個^符號和boost的值。告訴ES只需對那個欄位進行boost：
上例中，title欄位被boost了3倍。
需要注意的是：在使用boost的時候，無論是欄位或者詞條，都是按照相對值來boost的，而不是乘以乘數。如果對於所有的待搜索詞條boost了同樣的值，那麼就好像沒有boost一樣。因為Lucene會標准化boost的值。如果boost一個欄位4倍，不是意味著該欄位的得分就是乘以4的結果。
ES背後的評分過程比我們想像的要復雜，有時候某個查詢結果可能跟我們的預期不太一樣，這時候可以通過explain讓ES解釋一下評分細節。
由於結果太長，我們這里對結果進行了過濾（"size": 1返回一篇文檔），只查看指定的欄位（"_source": "name"只返回name欄位）。
在新增的_explanation欄位中，可以看到value值是0.9331132，那麼是怎麼算出來的呢？
分詞spring在描述欄位（name）出現了1次，所以TF的綜合得分經過"description" : "tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:"計算，得分是0.43243244。
那麼逆文檔詞頻呢？根據"description" : "idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:"計算得分是0.98082924。
需要注意的是，explain的特性會給ES帶來額外的性能開銷，一般只在調試時使用。
搜索的時候，要依靠倒排索引；排序的時候，需要依靠正排索引，看到每個document的每個field，然後進行排序，所謂的正排索引，其實就是doc values。
在建立索引的時候，一方面會建立倒排索引，以供搜索用；一方面會建立正排索引，也就是doc values，以供排序，聚合，過濾等操作使用。
doc values是被保存在磁碟上的，此時如果內存足夠，os會自動將其緩存在內存中，性能還是會很高；如果內存不足夠，os會將其寫入磁碟上。
DocValues默認是啟用的，可以在創建索引的時候關閉，如果後面要開啟DocValues，需要做reindex操作。
參考：
https://www.elastic.co/guide/cn/elasticsearch/guide/current/scoring-theory.html
https://blog.csdn.net/qq_29860591/article/details/109574595
https://www.jianshu.com/p/2624f61f1d02
http://www.dtmao.cc/news_show_378736.shtml
https://blog.csdn.net/molong1208/article/details/50623948
https://www.cnblogs.com/Neeo/articles/10721071.html
https://www.cnblogs.com/jpfss/p/10775376.html
https://zhuanlan.hu.com/p/27951938
H. 5. 簡答題 演算法的評價標准有哪些如何評價
評價演算法的四個標准：
1.正確性
能正確地實現預定的功能，滿足具體問題的需要。處理數據使用的演算法是否得當，能不能得到預想的結果。
2.易讀性
易於閱讀、理解和交流，便於調試、修改和擴充。寫出的演算法，能不能讓別人看明白，能不能讓別人明白演算法的邏輯？如果通俗易懂，在系統調試和修改或者功能擴充的時候，使系統維護更為便捷。
3.健壯性
輸入非法數據，演算法也能適當地做出反應後進行處理，不會產生預料不到的運行結果。數據的形式多種多樣，演算法可能面臨著接受各種各樣的數據，當演算法接收到不適合演算法處理的數據，演算法本身該如何處理呢？如果演算法能夠處理異常數據，處理能力越強，健壯性越好。
4.時空性
演算法的時空性是該演算法的時間性能和空間性能。主要是說演算法在執行過程中的時間長短和空間佔用多少問題。
演算法處理數據過程中，不同的演算法耗費的時間和內存空間是不同的。
(8)演算法評分機制擴展閱讀：
演算法是對特定問題求解步驟的一種描述，它是指令的有限序列，其中每一條指令表示一個或多個操作。此外，一個演算法還具有下列5個重要的特性。
（1）、有窮性
一個演算法必須總是（對任何合法的輸入值）在執行有窮步之後結束，且每一步都可在有窮時間內完成。
（2）、確定性
演算法中每一條指令必須有明確的含義，讀者理解時不會產生二義性。即對於相同的輸入只能得到相同的輸出。
（3）、可行性
一個演算法是可行的，即演算法中描述的操作都是可以通過已經實現的基本運算執行有限次來實現的。
（4）、輸入
一個演算法有零個或多個的輸入，這些輸入取自於某個特定的對象的集合。
（5）、輸出
一個演算法有一個或多個的輸出，這些輸出是同輸入有著某種特定關系的量。
I. 王者榮耀的評分機制是怎樣的
王者榮耀在1月12日開啟了新模式榮耀戰區，部分區目前還處於尚未開放階段，不過也有部分玩家率先體驗到了這個新模式，那麼榮耀戰區也是積分天梯制，本篇就為大家帶來榮耀戰區評分機制說明以及玩法規則介紹以供大家參考。
榮耀戰區規則：
系統根據召喚師上賽季英雄排位賽歷史數據繼承，繼承模型由各段位該英雄勝場數、各段位該英液雀雄勝率、該英雄周期內使用頻率等維度搭建，並最終得出召喚師英雄初始戰力。上賽季排位賽未使用的英雄的初始戰力為100。
增減分規則：
該英雄參與排位賽才可增減分，增減模型由該召喚師使用此英雄的歷史評分所計算而得的預期表現與此次對局評分對比、對手戰力評分、此英雄當前段位與其他玩家的平均表現等維度搭建。勝利，結算評分越高，得分越高；即使失敗，只要召喚師的評分高，也能實現加少量分；失敗且評分低，則扣分。該英雄參與排位賽對局的段位越高，榮耀戰力則加成越高，獲得分數越多。
FAQ:
1、現在看到輸了也會加分，但不清楚什麼時候會加？
官方答復：如果玩家當場表現的mvp分非常好，並且全隊就只有其一個人表現的非常好時，則會視該玩家使用該英雄的戰力值與對手隊伍的平均戰力值的差值情況，進行少量的加分。
2、低段位是不是比高段位戰鬥力增長會更快？看起來場次因素不小，那高段位使用同一英雄的頻率肯定比低段位高
官方答復：每個段位下的成績都是單獨記錄的，但高段位向下寬悔覆蓋低段位，每個段位的分都會大於0，所以段位越高，歷史戰績部分一定是收益越大的；對於歷史表現部分，將會根據玩家每場的表現情況與預期表現的差值進行隊伍內的排名，排名越高則勝利加分越高，失敗扣分越少，具體分支和段位及對手的平均戰力情況而定。
3、初始戰力評定不清楚：有的英雄打完一局從幾千開始變化，有的英雄打完從幾百開始變化
官方答復：版本剛更新時，會根據大家上賽季的戰績情況進行部分歷史戰績的繼承，所以導致大家登陸後的分數不同。
4、戰力增加的多少是否和每局結算的評分有關聯——表現不好但是贏了會不會扣分
官方答復：躺贏不會扣分，只是加的會比較少。
5、1000分和2000分的時候表現差不多，戰力加成是否會不一樣
官方答復：不一樣，分數越高時，系統會預期你打的更好，所以分數越高加的會越少，輸了扣的會越多
6、對不同類型的英雄是否有不同的演算法——類如輔助和輸出的演算法是否一樣
官方答復：對每個英雄都是分別計算的，會根據該英雄在相同段位下的平均mvp分計算出玩家應該打到的mvp分。
7、使用同一個英雄連勝會不會有加成鬧巧早
官方答復：連勝不會有額外的加成