產品經理如何快速測評新演算法

一、前言

在人工智慧已經成熟商業化的今天，我們的生活被各種演算法層層滲透，越來越多的產品無論是出於降本增效的目的，還是出於PR宣傳的目的，都開始應用演算法。

面對演算法的應用，產品經理要應對的一個重要難題，就是對演算法效果進行測評，尤其是面對一個新演算法能力，測評會更加棘手。

為什麼產品經理需要對演算法做測評呢？

對於自研演算法，僅有演算法研究員自測的實驗室指標是不夠的，業務產品需要透過自己的測評來判斷演算法是否達到商用標準，同時也能與實驗室指標形成對比，可以給演算法研究員作為重要參考；對於外採演算法，僅有供應商提供的演算法精度報告也是不夠的，我們更需要對多家供應商的演算法做測評，再結合價格、售後服務等因素綜合決定採購合作的供應商。

按照本文提供的框架，你可以“快速”完成對一個“新”演算法的測評。

二、演算法測評的基本原則

在進入測評框架的講述前，要先明確演算法測評的四個基本原則，非常重要！

原則1：演算法能力一致

面對橫向比較多個演算法優劣的測評，必須保證待測評演算法是解決同種問題或提供同種功能的。

原則2：樣本用例一致

同一個演算法，在不同樣本測試集上的指標表現是存在差異的，所以無論我們的測評是橫向比較多家演算法，還是縱向比較一家演算法的多個迭代版本，都必須保證採用的樣本測試集和測試用例保持完全一致，這樣得出的指標數值才有可比較的意義。

如果A演算法用a測試集，B演算法用b測試集，這樣得出的指標數值是沒有可比較性的，因為測試集不同。

原則3：執行方式一致

測評演算法的所有操作方式和環境必須保證完全一致。

原則4：評價指標一致

針對同種演算法的測評，必須採用計算公式或統計口徑完全一致的指標體系。

三、演算法測評，攏共分幾步1. 第1步：明確演算法的能力範圍

面對一個新演算法能力，首先要準確劃定這個演算法的能力範圍和邊界。

所謂能力範圍和邊界，就是這個演算法能做什麼不能做什麼，這一點和業務需求是強相關的；所以明確演算法能力範圍，其實就是梳理業務對演算法的需求，需求梳理完畢，演算法能力範圍也就清晰明瞭了。

業務對演算法的需求通常可來自於三個方面，一是政策法規、二是客戶需要、三是競品分析；這裡需要提示一點，如果想做到“快速”，就必須在滿足業務需求的前提下，將能力範圍最小化。

例如在筆者負責的業務中，需要對使用者上傳的身份證照片中的文字資訊進行提取，同時還需要判斷該身份證是原件/影印件/翻拍件。

透過對業務需求的梳理，我們已經得出了最小化的演算法能力範圍——身份證光學字元識別、身份證原件型別識別。

在市場上成熟的OCR演算法廠商中，提供的能力不僅僅是上述兩種，還包括證件反光提示、證件真偽判斷等等，但基於最小化原則，我們不需要追求全面測評，只需要關注業務需要的能力。

2. 第2步：明確測評目的

測評的目的無非就是得出一個好壞的結論，也就是相互比較。從比較型別的維度劃分，一般會分為橫向比較和縱向比較，橫向是針對多個廠商的演算法，縱向是針對同個演算法的多個版本。

這裡有個小提示，所有的測評，都必須要有基線作為參考，否則測評是沒有意義的。簡單來說，就是每次測評都必須是有兩個或以上的結果且結果可比較。

演算法能力的體現，也就是演算法的能力型別，通常包括演算法精度、演算法效能、操作體驗。

• 演算法精度，是指在既定的測試集上，演算法對樣本判斷、分析、預測的準確程度。
• 演算法效能，是指在既定品牌型號的伺服器上，演算法對樣本的處理速度。
• 操作體驗，是指C端使用者在裝置上操作演算法應用的難易程度。

綜上，測評目的可透過對“比較型別”和“能力型別”的排列組合得出。

3. 第3步：明確測評的執行方式

測評的執行方式分為批次跑測和端到端測試。

批次跑測，是指透過呼叫演算法模型的相關介面，將準備好的測試樣本批次送入模型，並批次得到模型返回結果的測試方式。

端到端測試，是指模擬使用者真實使用場景，從使用者裝置端（手機、PC等）傳入測試樣本，直到演算法服務端返回結果到使用者裝置端的測試方式。

針對精度和效能的測評，我們建議採用批次跑測的執行方式，資料準、效率高；針對操作體驗的測評，一般只能透過端到端的執行方式，才能準確還原真實操作場景。

4. 第4步：明確樣本型別和用例

樣本選取和用例設計是整個測評的核心，會直接影響測評結果是否能真實、客觀、全面的反映演算法能力。

不同演算法在樣本選取和用例設計上千差萬別，但有幾個小方法可以提供給大家參考：

1）全面覆蓋

根據業務需求，樣本和用例的設計要完整覆蓋需要測評和需要被客觀體現的演算法能力。如何做到完整全面的覆蓋？可以採用最小顆粒拆解方法。

2）最小顆粒

根據業務需求，將演算法能力拆解到最小的顆粒度，逐一測評最小顆粒的原子能力。如何拆解原子能力呢？這裡有個小技巧，就是多問幾個“為什麼”，其實就是拆解演算法訓練原理，再根據業務場景中實際會出現的情況，得出樣本和用例。

以筆者上面提到的“證件是否為原件的檢測演算法”為例——

問：“為什麼可以檢測出圖片中的證件是否為原件？”

答：“因為這個演算法可以區分出影印件、翻拍件。”

問：“為什麼可以區分出影印件？”

答：“透過圖片顏色的判斷。”

問：“為什麼透過顏色就可以判定是影印件？”

答：“影印件有黑白影印件和彩色影印件，黑白影印件可以直接透過色值判定，而彩色影印件的成像顏色對比度一般比原件的對比度要低，且影印件的底色背景絕大部分都是白色。”

從上述的問答中，我們就可以拆解出該演算法的樣本和用例如下——

注：以上問答經過簡化處理，方便理解。

3）單一變數

對演算法每個原子能力點的測評，可採用控制變數法，同時為了確保能有效反映每個原子能力的客觀結果，每組樣本和用例都要保證只有一個變數發生改變；因為在同一個用例中存在多個變數發生改變，我們很難區分演算法得出的測試集結果是由哪些變數引起的，不利於後期結果分析。

當然，如果有特殊需要，在能夠明確區分變數影響的情況下，也可以採用多變數變化測試。

4）側面轉換

當面臨某些演算法能力我們無法直接測評時，可採用轉換法，將無法直接測評的能力轉換為與該能力有直接關係且可測評的其他能力，從而側面驗證該演算法能力的效果。

5. 第5步：明確評價指標和計算公式

面對一個新演算法，最快了解這個演算法評價指標的方法，就是“問”。自研演算法的，可以問演算法研究員；外採演算法的，可以問多家演算法供應商，綜合選擇評價指標。

1）演算法精度指標

精度指標因演算法而異，一般可分為兩種型別：絕對指標和相對指標。

絕對指標通常就是準確率，是測試集演算法處理結果與測試集真實結果差異的百分比計算，目前筆者接觸過的絕對指標有FAR、FRR、召回率、字元準確率。

相對指標是指設定一個基準演算法，錨定該演算法的絕對指標準確率為100%，計算其他演算法相對於這個基準演算法在指標上的差異，相對指標一般會採用均方根誤差（標準誤差）作為結果。

可以這麼理解，統計絕對指標時，需要對測試集進行人工標註，即得到測試集真正的標準答案；統計相對指標時，不需要對測試集進行標註，而是直接以基準演算法測試的結果為標準答案。基於此我們可以得出一個小竅門，採用相對指標進行測評會更新快速，因為省去了人工標註的環節，但是測評結果會在客觀性上存在一定偏差。

2）演算法效能指標

通常包括，併發、QPS、吞吐量、耗時。

3）操作體驗指標

通常包括，頁面數、事件數、轉化率、可用率、轉化率、操作時長。

指標制定還需注意一個小細節，就是要明確指標評判好壞的邏輯，而且儘量保證所有指標的好壞邏輯一致；例如有a、b、c三個指標，他們的評判邏輯是數值越高表示效果越好，而有d指標，評判邏輯是數值越低效果越好，這樣對閱讀者來說是非常不友好的。

6. 第6步：撰寫測評報告

在執行完所有測試用例後，就要整理測試資料以及形成可閱讀的測評報告。

以下是測評報告的章節框架，供大家參考：

1）測評背景和目標

描述發起該測評的專案背景，以及在這個背景下，該測評想要到達什麼目的。

我們往往很容易忽略對背景的分析，其實這是不對的。深入瞭解專案背景，可以讓我們準確理解專案的起因由來，從而有利於我們更準確的理解業務和需求，能夠更準確的劃定各種事項邊界。

試問，如果我們對一個專案為什麼要做都沒能理解到位，那如何能準確的評估需求呢？

2）業務需求解讀

需求的解讀我們在第1步的描述中講過，一般可來自於三個方面，一是政策法規、二是客戶需要、三是競品分析；透過這三個方面的分析，推匯出需求功能。

3）競品/供應商能力分析

對競品的功能，或者對供應商的功能做全面的剖析。

4）測評方案描述

描述樣本型別、用例設計、執行方式、評價指標（指標定義+評判邏輯）。

5）測評指標結果

展示經過統計後的各項指標數值，是測評結論的客觀依據。

6）測評結論

針對指標結果，給出總結性的結論，結論需要與測評目的（目標）相呼應。

認知淺薄，歡迎討論。

本文由 @山雞Samson 原創釋出於人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基於CC0協議