註：大概2017年-2018年中國人工智慧熱度達到頂峰，隨後熱度開始逐漸減少。2018年前人工智慧被投資界、學術界、工業界和媒體炒的特別熱，各大企業都想嘗試一下深度學習技術在業務場景的應用。試水後大家發現人工智慧技術離真正地落地應用還有很遠路要走，之後便是人工智慧開始逐步降溫。本人做過電腦視覺相關的業務演算法應用研發，感覺做研發的演算法總是存在這樣那樣的不足，很多時候無法滿足產品實際應用的高要求。我想可能因為做過的項目不是特別多或對業務或者對項目理解不足，導致我對人工智慧存在一些負面看法。為此，我想多了解除電腦視覺演算法的應用外與電腦視覺並行的分支–自然語言處理（包括語音識別和語音合成），我做了一些演算法測試相關的工作。以下是做了兩個月的演算法測試後的個人感受及總結，希望能對一些人有一些幫助。（可能會有一些觀點或看法有些欠妥，歡迎大家評價討論。由於評論需要登錄部落格園帳號，如果不想註冊部落格園帳號，歡迎把意見或建議發送到郵箱：[email protected]）

現在的AI演算法依舊是依賴大量的數據進行模型訓練以獲取一個實際效果較好的模型，由於種種原因無法獲取真實應用場景足夠多的數據。即使能夠獲取大量真實場景數據，數據同質化較為嚴重，對模型性能的提升非常有限，在演算法應用落地時，需要解決大多數問題或需要知道演算法模型的性能邊界，此時需要對演算法進行評測以客觀有效地反應演算法的性能表現，為產品負責人和演算法研發人員提供有效參考。a.從演算法模型訓練的角度看，深度模型訓練需要大量的數據，獲取足夠多的測試數據以得到模型的性能表現有些困難，於是需要較為專業的演算法測試以獲取演算法的真實性能表現；b.業務人員需要了解演算法在實際場景中的表現，以對演算法進行驗收；c.演算法研發人員需要知道演算法在實際場景應用中的具體細節表現，以改進演算法模型更好地服務業務。

演算法測評工作內容包括：a.與演算法和產品一起確定演算法需求的實際應用場景；b.確定演算法的評測方案及指標；c.確定測評數據量及採集方案，並進行採集；d.演算法模型發版後對模型進行評測及分析。

軟體測試更側重於功能測試，測試軟體是否正確實現了需求功能，以及執行效率如何。演算法測試側重演算法本身的性能，主要測試演算法功能點在目標應用場景的實際性能表現，測試指標結果參考立項時對應的演算法指標，確定演算法是否滿足產品要求。通常產品人員對演算法的應用場景理解不足，導致在演算法指標確定時，儘可能高的同時適用演算法應用場景下所有情形，從未導致演算法指標設置偏高。然而在實際項目應用中，能夠明確演算法指標的也不是很多，此時需要多與產品人員和演算法人員進行溝通來解決目標問題。在參考標準或指標不確定的情況下，輸出的演算法品質無法有效保障。

演算法測評的工作職責確保產品中的演算法模組能夠有效滿足產品設定指標，同時確定演算法本身的性能邊界，為後續演算法優化和業務人員提供有效幫助。

演算法測試與演算法研發整體上要求一致，確定產品實際應用場景，獲取實際場景數據，然後進行模型訓練和評估。演算法測試的品質保證需要從產品應用場景，數據採集方案、實際場景數據和測試分析等四個方面進行保證。產品應用場景決定了該場景可能出現的問題，演算法為解決該場景中的問題而研發，從而演算法測試也應該是正對該場景進行測試，滿足產品負責人對演算法在該場景下實際性能表現客觀了解。在充分理解產品實際應用場景後，需要採集該場景下的數據進行測試。設計一個邏輯上非常嚴謹的數據採集方案相對容易，通常過於嚴謹的數據採集方案具有巨大的時間和人體成本，設計一個能夠較少採集數據，但又能客觀評價演算法性能的數據採集方案非常重要。有了數據採集方案後，便是數據採集，然而在實際應用中採集的數據比數據採集方案中預想的要少，此時需要評估採集的數據能夠反映產品應用中的哪些問題，以及哪些問題沒能有效數據進行評估。

由於演算法評測數據採集需要根據產品需求而定，因涉及場景理解無法實現自動化；能夠自動化的部分就剩下數據標註和結果分析自動化。數據標註結果可以使用人工進行標註，也可使用模型進行自動化標註或使用模型輔助半自動化標註。根據任務類型複雜程度和精度要求，確定是人工標註還是自動化標註。測試任務較為緊急且對最後結果要求不是很高，可以自動化數據標註。 然而為了保證測試品質，對標註數據的準確率要求很高， 以此客觀真實反映演算法的性能。測試結果分析自動化是對演算法模型輸出結果與真實結果之間比較分析。待任務整體確定下來後便可對結果分析自動化，隨著演算法版本的迭代，結果分析模組可以增加細分程度。建議構建結果分析模組時設計好整體框架，把後續可能的增加的擴展考慮進去。

8.AI演算法測評工作中需要溝通的相關方有哪些?

演算法測試主要涉及到演算法研發人員、產品需求方、項目管理方、演算法測試人員。測試方需要與演算法研發人員確定演算法相關細節，便於後續結果分心給出更多有意義的建議和結果；與產品需求方確定演算法應用場景的細節和演算法具體的測試方案，以及場景數據問題；與項目管理方確定和溝通演算法發版和提測任務時間節點。在項目立項初期可能還涉及研發負責人和項目負責人，主要是演算法需求和演算法技術實現需求的評審，演算法需求評審通過後，需要評審演算法技術實現可行性進行評估，最後確定演算法的應用場景和演算法指標。

由於演算法測評屬於演算法品質保障一塊，可以放在品質部，同時演算法測試要求對演算法有較多理解，也可以放在研發部門。由於演算法測試崗位屬於起步階段，還存在一些問題：實際場景數據不足、演算法技術方案的變更、演算法指標、測試品質保證。

實際場景數據不足：有時項目所有者不能獲取實際場景數據，或者不能夠獲取多樣性充足的數據，導致測試數據對實際場景覆蓋不足，從而測試結果不能有效反映實際真實指標。

演算法技術方案的變更：由於在項目立項對演算法的技術方案評估不足或者產品需求側需求發生變更導致演算法的技術方案變更，從而導致之前採集的數據不可用或之前創建的自動化標註和分析流程不可用。前期做的一些工作幾乎不可使用，或可使用的太少。此時對測試程式碼的模組化設計顯得非常必要了。

演算法指標：通常說的演算法指標更多是針對單點演算法，在業務場景更多是多種演算法的集成，或者業務演算法的測評指標與研發時的測評細節有差異導致相同指標不同數值等。此時需要多與演算法研發人員和產品測溝通。

測試品質保證：很多時候跟演算法相關的指標定義本身存在理解偏差，業務人員理解的指標和研發人員理解的指標不是同一個概念，或者說演算法指標不能很好反映實際場景演算法的性能，從而導致演算法測試的結果無法得到有效保證。