編輯導(dǎo)語：上篇作者說到了case評(píng)測(cè)標(biāo)準(zhǔn)，本篇文章就可以正式開始進(jìn)行case評(píng)測(cè)，本篇將以搜索為例具體講一下搜索是怎么進(jìn)行case評(píng)測(cè)的，我們一起來看一下。

一、誰來參與

通常在搜索團(tuán)隊(duì)內(nèi)部，會(huì)把這個(gè)事情定義為“搜索用戶滿意度評(píng)測(cè)項(xiàng)目”，以便更好的進(jìn)行組織和推進(jìn)。

立項(xiàng)之后需要定義項(xiàng)目的參與方，“搜索滿意度評(píng)測(cè)”一般包含這幾個(gè)角色：項(xiàng)目負(fù)責(zé)人、產(chǎn)品經(jīng)理，算法工程師，開發(fā)工程師；他們的分工不一樣。

• 項(xiàng)目負(fù)責(zé)人：主要負(fù)責(zé)整個(gè)評(píng)測(cè)項(xiàng)目的時(shí)間計(jì)劃制定，溝通機(jī)制建立，評(píng)測(cè)意見統(tǒng)一以及評(píng)測(cè)過程中遇到的問題處理；
• 產(chǎn)品經(jīng)理：負(fù)責(zé)具體case的測(cè)評(píng)，評(píng)測(cè)報(bào)告的撰寫以及評(píng)測(cè)標(biāo)準(zhǔn)修訂建議收集；
• 算法工程師：負(fù)責(zé)具體case的評(píng)測(cè)，case歸因分析；
• 開發(fā)工程師：負(fù)責(zé)具體case的評(píng)測(cè)，一般參與較少；

這里簡(jiǎn)單解釋一下算法工程師和開發(fā)工程師，有的團(tuán)隊(duì)可能不會(huì)進(jìn)行區(qū)分，統(tǒng)一稱之為工程師；有的會(huì)做區(qū)分，算法工程師主要是負(fù)責(zé)人策略中算法、模型的開發(fā)；開發(fā)工程師則主要負(fù)責(zé)工程段的開發(fā)，通常指的是后端、服務(wù)端。

另外，搜索滿意度評(píng)測(cè)項(xiàng)目的實(shí)施周期可以按照搜索迭代計(jì)劃的快慢進(jìn)行靈活設(shè)置。

在迭代較快的情況下，測(cè)評(píng)的頻率也會(huì)相應(yīng)加快，我見過一些團(tuán)隊(duì)一周一次；如果迭代較慢，或者優(yōu)化項(xiàng)目周期跨度較長(zhǎng)，可以適當(dāng)把測(cè)評(píng)周期拉長(zhǎng)，我們之前做的是2個(gè)月一次。

二、case抽樣

case抽樣是指提取評(píng)測(cè)案例，一般是由工程師通過sql在搜索日志中取數(shù)。

對(duì)于搜索來說，一個(gè)case最基本需要包括用戶id，搜索關(guān)鍵詞和搜索結(jié)果；隨著業(yè)務(wù)的不同需要抽取的數(shù)據(jù)不同，比如在美團(tuán)還需要抽取搜索時(shí)間、搜索地點(diǎn)等。

對(duì)樣本的要求一般包括如下幾方面：

• 時(shí)間上一般選擇測(cè)評(píng)周期內(nèi)的最后一周，這個(gè)時(shí)候相關(guān)的優(yōu)化策略基本上都生效；
• case的數(shù)量按照項(xiàng)目參與人員的多少來確定，人均100個(gè)左右；
• 對(duì)于中臺(tái)搜索通常會(huì)服務(wù)于若干條業(yè)務(wù)線，因此需要控制好不同業(yè)務(wù)之間的case數(shù)量比例；
• 總體的抽取規(guī)則采用隨機(jī)抽取的方式，保證測(cè)評(píng)結(jié)果的可信度；

需要注意的是，隨機(jī)抽出的case很多時(shí)候都是無效case，比如：無關(guān)鍵詞、關(guān)鍵詞是特殊字符等等；但是只有基于有效case來進(jìn)行評(píng)測(cè)，這樣結(jié)果才可信，所以還需要對(duì)抽樣結(jié)果進(jìn)行過濾，一般抽樣的時(shí)候會(huì)比計(jì)劃評(píng)測(cè)case數(shù)量要多一些。

三、case測(cè)評(píng)

case評(píng)測(cè)是指評(píng)測(cè)人員對(duì)抽樣后的case質(zhì)量進(jìn)行評(píng)估的一個(gè)過程，就類似閱卷，需要給每一份試卷進(jìn)行打分。

為了操作方便，在大型企業(yè)，一般都會(huì)自建case測(cè)評(píng)平臺(tái)，大家可以理解為這是一個(gè)case評(píng)測(cè)人員的協(xié)作平臺(tái)；它主要提供的功能就是對(duì)case進(jìn)行分配、篩選、查看、打分（分級(jí)）；若為badcase需要選擇原因，以及填寫備注。

注意這里的打分并不是按照評(píng)測(cè)人員的主觀判斷進(jìn)行打分，而是會(huì)提前制定一個(gè)算法，算法大概的思路就是不同的badcase結(jié)果有不同的分?jǐn)?shù)和權(quán)重，根據(jù)評(píng)測(cè)人員選擇的原因分類自動(dòng)進(jìn)行分?jǐn)?shù)計(jì)算。

比如：評(píng)測(cè)人員選擇badcase原因是無關(guān)商品排序靠前，記為0分；若是低相關(guān)商品排序靠前，則為3分——通俗理解，就是badcase越嚴(yán)重，得分越低，也意味著對(duì)用戶體驗(yàn)傷害越大。

case的評(píng)測(cè)最重要的前提就是需要定一個(gè)評(píng)測(cè)的標(biāo)準(zhǔn)，關(guān)于標(biāo)準(zhǔn)的制定見：如何搭建一個(gè)case評(píng)測(cè)流程（一） ；這里大家要注意的是，標(biāo)準(zhǔn)不是一成不變的，每一次評(píng)測(cè)都是一次優(yōu)化、完善標(biāo)準(zhǔn)的機(jī)會(huì)。

四、冗余評(píng)測(cè)

大多數(shù)團(tuán)隊(duì)在進(jìn)行了評(píng)測(cè)之后就開始進(jìn)行數(shù)據(jù)統(tǒng)計(jì)，看看goodcase有多少、badcase有多少，然后基于這兩個(gè)數(shù)據(jù)計(jì)算當(dāng)前評(píng)估周期的滿意度。

搜索滿意度的計(jì)算方式為：

goodcase/(goodcase+badcase)*100%

這里無論是goodcase，還是badcase，都是指的有效的case。

由于評(píng)測(cè)的標(biāo)準(zhǔn)是人工制定的，因此經(jīng)常出現(xiàn)一些標(biāo)準(zhǔn)沒有覆蓋的case，以及大家理解不一致的地方，因此這個(gè)時(shí)候就需要加一個(gè)冗余case評(píng)測(cè)環(huán)節(jié)。

冗余評(píng)測(cè)就是對(duì)評(píng)測(cè)過程中有意見分歧的case進(jìn)行項(xiàng)目組成員集體評(píng)測(cè)，最終做出決策。

顯然冗余評(píng)測(cè)的目的除了能夠保證滿意度結(jié)果的公正，更為重要的一環(huán)是基于大家對(duì)badcase的不同理解，去完善評(píng)測(cè)標(biāo)準(zhǔn)。

評(píng)測(cè)標(biāo)準(zhǔn)可以說是滿意度評(píng)測(cè)的根本，只有標(biāo)準(zhǔn)制定的好，才能產(chǎn)出一個(gè)客觀的滿意度結(jié)果。我微信后臺(tái)放了一個(gè)評(píng)測(cè)標(biāo)準(zhǔn)的模板，大家可以輸入模板來獲取。

五、case歸因

case評(píng)測(cè)的直接目標(biāo)是衡量搜索的滿意度，但是根本目標(biāo)還是通過badcase明確、指導(dǎo)搜索策略優(yōu)化。

因此，當(dāng)case評(píng)測(cè)進(jìn)行了bad和good判定之后，最后一個(gè)環(huán)節(jié)就是case歸因。

簡(jiǎn)單來說，就是分析造成每一個(gè)badcase的原因是什么？

一般來講對(duì)于搜索badcase，包含下面幾類：

1. 詞典問題
2. 查詢分析問題
3. 召回問題
4. 排序問題
5. 前端問題

這一塊下一篇再詳細(xì)講解。

#專欄作家#

夏唬人，微信公眾號(hào)：夏唬人，人人都是產(chǎn)品經(jīng)理專欄作家，2019年年度作者?！恫呗援a(chǎn)品經(jīng)理：數(shù)據(jù)賦能業(yè)務(wù)》作者。某廠策略產(chǎn)品經(jīng)理，關(guān)注推薦、搜索、AI策略方向。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議。