人工智慧落地之路:從概念驗證到產品
大資料文摘出品
來源:medium
編譯:李雷、蔡婕、雪清、橡樹_hiangsug
只有不到20%的機器學習PoC(概念驗證)專案能夠順利投產,而這其中的大部分也可能會止步於其方案的“產品化”階段。從概念驗證到實際產品,人工智慧應用落地到底要跨越多大的鴻溝呢?來看看這篇文章怎麼說。注意:文中可能存在“機器學習”和“人工智慧”概念混用的情況,不必糾結於此。
今年,雖然不少公司都在部署人工智慧解決方案,也取得了一定的成果,但只有少數公司做到了全面部署人工智慧,從而為公司帶來真正的附加價值。
據我所知,只有不到20%的機器學習PoC(概念驗證)專案能夠順利投產,而這其中的大部分也可能會止步於其方案的“產品化”階段。
PoC的困境
大多數公司首先透過概念驗證(proof of concept , PoC)專案來證明人工智慧方案可以削減成本,改善客戶體驗,或者在某種程度上形成業務差異化。
PoC通常採用相對簡單的演算法,訓練資料也是即時可用的或內部標記的,其主要目標是證明可以用少量的資料訓練演算法以解決特定場景的問題。
如果PoC獲得成功,那麼專案將繼續進入產品化階段。
進入產品化階段意味著AI專案將變得更加複雜。這個階段不再需要證明該解決方案的有效性,而是要將AI專案整合到公司的基礎架構中,並保證它在真實環境下能夠很好地工作。
為了使專案取得成功,機器學習專案需要從一開始就將公司結構、客戶、公司規模和內部工作流程等考慮在內。
PoC往往會影響系統基礎架構的效能以及知識和資料管理等,這些都將阻礙它們進入下一階段——產品化。在AI專案中,產品化階段的困難程度往往容易被低估。在這個階段裡,系統的工作方式很有可能需要完全改變,並且當我們越來越接近解決方案的最終版本時,新的問題也會不時出現。
在人工智慧整合的最後階段,AI專案可能會跨多個業務線,甚至可能直面普通使用者/客戶,面臨著來自企業級基礎架構、安全性和技術支援等多方面的挑戰。
產品:在現實生活中使用的系統。它不像PoC那樣是為了測試某些東西是否有效,也不像用樣本資料做的簡單實驗。它是用真實資料來解決現實問題的系統。
很多時候,AI方案提供商都未能證明其初始方案的有效性。為什麼AI專案的實施過程會變成一場噩夢呢?其實,大多數時候,AI專案沒能進入產品化階段是因為以下因素:
PoC專案沒有產生期望的結果
運營成本過高
操作過於複雜
缺乏資料
PoC專案沒能達到利益相關者的要求
比如,某公司有一個業務問題,剛好可以用人工智慧來解決,但如果需要提供核心資料或必須使用新的工作流程,那麼這個公司可能就會放棄該專案。實際上,在AI專案產品化之前,必須先處理好它與軟體、資料安全和大規模的新的訓練資料等一系列相關的問題。
另一個原因可能是低估了構建一個具有實際功能的AI所需的成本。將原型進行產品化需要很大的投資!公司管理層要確保他們能夠負擔得起。
機器學習的概念驗證(PoC)是漫長實踐過程中的第一步。當你將其擴充套件到實際規模的應用時,你需要站在更高的角度來看待所出現的問題。
為什麼會失敗?
AI專案的概念驗證(PoC)路線圖上存在某些挑戰,比如資料的缺乏,法律上的問題,公司員工對AI相關應用的畏懼以及系統整合能力是否足夠等,因此任何公司都必須在將模型產品化之前先分析相關影響因素。
在我看來,公司應該同時開展多個PoC專案,因為這樣有助於瞭解公司的潛力,改善內部行為方式,快速終止那些沒有前景的人工智慧PoC,併發掘出最有前景的專案以便繼續監控和投入資源。我看到有些公司指望用他們的第一個PoC來賺錢並且解決複雜問題,這麼做十有八九會失敗!
公司還應該考慮到,進行概念驗證所需的技能與將其轉化為產品所需的技能是大不相同的。如果沒有一個支援AI整合的架構,那麼即使是最有前景的專案也會夭折。
人工智慧專案還需要得到管理層的支援,如果沒有長期投資的恆心,AI應用就只能是小打小鬧,永遠達不到任何有意義的規模或實用性水平。這類專案的成功需要時間和耐心。
為了使PoC獲得成功,必須進行廣泛的研究,建立一個跨職能部門的團隊,並調研和測試各種硬體規格,此外還可能需要請外部專家對模型進行微調。雖然我們在最初研究的2-3周內就做可以做出原型,但接下來的開發需要更長的時間,並且需要大量的資金和時間投入。
根據我的經驗,一個好的PoC需要大約半個月時間。事實上,整個資料收集過程是非常耗時的。更不必說,大多數公司在提到使用AI都有驚奇的想法,但往往得不到對的資料。
舉個例子,如果在做PoC的時候,演算法可以識別在相同光線、距離和角度下拍攝到的人臉,那麼在試點專案中該演算法就需要適應不同的光線、距離、角度、膚色、性別,等等。這自然意味著更多的資料。
PoC中的機器學習模型所需的輸入資料與產品中持續大規模的輸入資料之間存在很大差別,能認識到這一點很重要,但這經常被公司或者專案組所忽視。
我在幾個專案中使用了不一樣的和不完善的資料集,這使我意識到:人們在將小規模的ML演算法轉移到生產過程中時,可能會大大低估為獲取資料而投入的時間和精力,而這些資料是擴充套件原有ML演算法所必不可少的。
關鍵之處在於將實際需求和POC資料集之間的“差距”最小化。因此,我強烈建議使用真實場景的資料。
構建一個可靠且相關的資料集需要很多時間。為了正確地訓練一個預測模型,必須遵循特定的流程來生成符合標準的資料。
當PoC成功後,一些AI團隊會考慮獨立完成整個專案的資料準備工作。我相信,他們低估了公司提供所需資料的難度(資訊孤島,效率低下等)。在這一步,我們通常會開始瞭解公司的運作方式。
實際上,生產系統中會包含許多未知案例,訓練演算法會產生對大量資料的需求(通常是壓倒性的)。
試點階段
一個成功的POC將說服專案所有者交付試點階段(a pilot phase)的資金。試點是POC與生產專案之間的一個專案步驟,組織不會關停任何其他系統或更改人員配置。在對演算法進行調整和訓練的過程中,試點與現有系統一起執行。這是一個必要的步驟,因為在此過程中會面臨許多問題或工作流程挑戰。
生產的持續時間在某種程度上是由生產所需的人工智慧精度水平決定的。顯然,一些專案需要更多的時間來達到一定的成熟水平(自動駕駛汽車等)。其他專案可以在明顯較低的置信水平下帶來積極的投資回報率(Return On Investment, ROI)。
大多數情況下,試點專案沒有足夠多樣化的資料來進行大規模運作。
從PoC到產品
正如我們所說的,很少有專案團隊能夠成功地跨越這個階段並繼續下去。實際上,大多數專案從PoC到產品化需要大量不同的資源。在生產步驟中,當我們意識到可能存在的新的問題時,通常會發現專案需要更多的時間才能完全執行。此外,我們越多地涉及終端使用者,就越發意識到PoCs離現實應用還有很遠的距離。
PoC所有形式的資料建模都必須簡化但又要反映真實情況,而在這個過程中,總會丟失一些真實性。這為ML帶來了風險,因為實際資料可能比概念驗證(POC)所用的訓練資料更容易出現建模問題。
對此,明顯的解決方案是為模型新增更多細節,並擁有更多欄位、表格、關係等。但是,模型越精細,就越難以使用和理解。這也是建立在你可以獲得更多資料的假設之下。我見過許多專案因為缺乏資料而失敗,還有一些專案使用了資料增廣技術(在影像識別專案中,這是一種減少過擬合的好方法)。
Source
部署常規的軟體應用程式本就是困難的——但是如果軟體是基於機器學習的,情況可能會更糟!ML具有一些特性,將使得大規模部署變得更加困難。
在我最近的一個專案中,我意識到一旦你的演算法訓練好後,它們就不會一直被使用。例如,你的客戶/終端使用者只會在需要的時候呼叫它們。
管理API呼叫的想法是關鍵。實際上,你需要確保免為不需要的伺服器付費。一旦AI解決方案的執行成本過高,公司可能會憂心於繼續使用它。
進入生產階段後,從資料的角度來看,事情將開始變得更加複雜。除非演算法的問題空間非常簡單或是完全靜態的,否則訓練永遠不會結束。問題空間在演變,新的使用案例也在不斷變化,以及來自競爭對手的壓力——他們也試圖實施差異化ML策略,所有這些意味著組織必須使他們的模型勝任更加模糊的特定案例。而在已經很高的模型置信水平下,就訓練資料而言,每1%的增量增長都相當昂貴。
資訊系統中的AI整合
AI解決方案可能已準備就緒,但是還有一步工作要做。事實上,實際規模的實現還包括將AI與資訊系統和架構連線起來。根據經驗,我得出的結論是——人工智慧部署中最大的問題是難以將認知專案與現有流程和系統進行整合。最佳選擇是提供機器學習模型的API,或將其作為現有系統中的程式程式碼模組。
當涉及到AI專案時,無論是否成功,PoC都非常有用。我相信,透過一個特別的過程(資料分析,組織調整等),我們有可能增加PoC進入生產階段的機會。
企業需要為與AI供應商的合作做好準備,這種合作方式應當既不會讓企業的資料面臨風險,也不會造成長期依賴,反而會增強其競爭優勢。
相關報導:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562039/viewspace-2644225/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 中國醫療人工智慧現狀分析:從產品驗證進入市場驗證人工智慧
- 從程式碼到產品,我的IT職業成長之路
- 細數從Al演算法到產品化落地的八大鴻溝演算法
- 產品學習之路
- 技術創業者必讀:從驗證想法到技術產品商業化的全方位解析創業
- 從 Flutter 的視訊渲染到 App 落地經驗FlutterAPP
- 產品概念證明的優先順序如何安排? - Reddit
- 從《人人都是產品經理》分析自我轉型之路
- 2023 re:Invent AI 生成產品體驗,從 Bedrock 到 Amazon QAI
- 社群產品從0-1|從冷啟動到正常運營(我的經驗案例)
- 從專案到產品:生產線類比的終結
- 從試驗品到產品:AutoML是如何一步步貼近產業應用的?TOML產業
- 從捕捉創意到產品落地,獨立遊戲團隊可遵循的成功路徑到底有什麼?遊戲
- Packstack:建立概念驗證雲
- 產品設計中收不到驗證碼解決策略
- 如何從1到99做好產品 | 得物技術
- 從驗證到不變性保護機制
- 網路驗證碼的進化:從簡單圖文到無感驗證
- 從idea到網站產品的五個環節Idea網站
- 從 API、UI、結構到商業產品設計精髓APIUI
- 谷歌年度回顧:從軟體到硬體,從打造產品到重構影響力谷歌
- 淺談人工智慧精益生產落地之道人工智慧
- MaxCompute產品最新進展 -- 從馬力到計算力
- 產品手記|從使用場景到使用者價值
- 從產品展示頁面談談Hybris的特有概念和設計結構
- 華為雲對Kubernetes在Serverless Container產品落地中的實踐經驗ServerAI
- [產品經理之路] 0:持續優化著世界的產品經理優化
- Unity和騰訊遊戲成立聯合創新實驗室,從技術創新探索遊戲產品新模式和概念Unity遊戲模式
- 2018醫療人工智慧報告:調研60家國內醫療人工智慧企業產品落地情況,第一代產品已成熟人工智慧
- Identity Server 4 從入門到落地(十二)—— 使用Nginx整合認證服務IDEServerNginx
- 產品手記|一些基礎概念
- Oracle產品考試認證列表Oracle
- 推薦系統之路 (2):產品聚類聚類
- 小白從零到AIoT之路(前言)AI
- 從產品到平臺 PingCAP的堅持與探索|魚論PingCAP
- Windows 程式設計精髓:從 API、UI、結構到商業產品Windows程式設計APIUI
- 從需求分析、產品設計到部署交付各階段說明
- 蘋果概念咖啡杯 智慧特性的概念型高科技產品蘋果