3個因素看透 AI 技術架構方案的可行性

簡介:人工智能這幾年發展的如火如荼,不只在計算機視覺和天然語言處理領域發生了翻天覆地的變革,在其餘領域也掀起了技術革新的浪潮。不管是在新業務上的嘗試,仍是對舊有業務對改造升級,AI 這個奔涌了 60 多年的「後浪」,正潛移默化的影響着咱們傳統的技術架構觀念。算法

image.png

人工智能這幾年發展的如火如荼,不只在計算機視覺和天然語言處理領域發生了翻天覆地的變革,在其餘領域也掀起了技術革新的浪潮。不管是在新業務上的嘗試,仍是對舊有業務對改造升級,AI 這個奔涌了 60 多年的「後浪」,正潛移默化的影響着咱們傳統的技術架構觀念。架構

AI 架構(尤爲是以機器學習和深度學習爲表明的架構方案)已經成爲咱們技術架構選型中的一個新的選項。框架

你是否須要 AI 架構的解決方案?AI 架構選型的主要依據是什麼?這是咱們今天主要討論的問題。機器學習

咱們先來看一個典型的 AI 架構:分佈式

image.png

  • 一、首先須要採集訓練模型所須要的數據,這些數據有可能來自業務系統自己,如 CTR 預估任務中的用戶點擊數據、用戶下單數據等;也有可能來系統外部,公開購買或自主爬取,如圖片分類任務中的圖片、NLP 任務中的語料等。
  • 二、這些數據被收集起來後,通過清洗、加工,被存儲起來,由於畢竟不是隻用一次。通常是存儲在分佈式存儲設備(如 HDFS)或雲端,多數公司還會創建本身的數據平臺,保存在數據倉庫中,長期積累下來。
  • 三、須要使用的時候,先進行數據篩選,選擇合適的特徵數據,而後通過數據預處理,送入到算法模型中。模型的搭建可選的技術框架不少,能夠是基於 spark mllib,也能夠是 sklearn、tensorflow、pytorch 等。而後通過訓練、評估和調參,完成模型的構建工做。
  • 四、最後模型要應用到線上的具體業務中,完成分類、迴歸某一具體任務。在部署過程當中,有多是將模型打包,將預測模型直接部署到業務系統(客戶端)中;也有多是直接提供一個在線 RESTful 接口,方便跨語言調用。

總結一下,通過數據採集、加工處理、特徵選擇、數據預處理、模型訓練、模型評估、模型應用幾個環節,數據跨過業務系統、數據平臺、算法模型三個系統,造成一個閉環,最終又應用到業務系統中,這就構成了整個 AI 架構的核心。函數

是否須要 AI 架構,如何衡量這套技術架構方案的可行性?我認爲,主要是看如下三個要素。佈局

1. 場景

咱們討論架構的可行性,是否適合業務及業務發展是第一衡量準則,AI 架構也不例外。學習

回顧那些經典的、已經普遍應用的機器學習場景,好比推薦、搜索、廣告等,這些場景都具備這樣的特色:場景相對封閉、目標單1、可控。優化

究其緣由,不管算法模型多麼複雜,其最終都要落實到損失函數上的,然後者通常都是單目標、單優化任務。或追求極值(損失最小化)、或達到某種對抗上的平衡(好比GAN)。在這種狀況下,不管業務如何建模,仍是要落地到算法模型和損失函數的,最終也就限制了場景和目標上的單一。人工智能

所以,看一個業務是否適合AI架構,就要先看這個業務場景目標是否單1、可控。或通過業務建模和架構拆解後,每一個環節的場景是否單一。

舉個例子,同程藝龍酒店系統爲酒店商家提供了上傳酒店圖片的功能,在這個場景下,除了要審查圖片的合法性,還要給圖片打上分類標籤,如「大堂」、「前臺」、「客房」、「周邊」等。爲了能正常使用AI架構,就必須對場景內的各目標進行拆分,訓練不一樣的分類器。具體流程以下:

image.png

其中,第二、三、4步涉及到多個圖片分類器,每一個分類器的目標不一樣,所須要的訓練數據也不一樣。對於輸入的同一個樣本圖片,每一個分類器完成本身的職能,目標單一可控。對於一些不經過的樣本,可能還涉及到人工干預。最後合法的圖片存入系統。

從業務必要性上來講,也並非全部業務場景都須要AI架構。算法模型是對事物的精確模擬和抽象,複雜度也是比較高的。但可能有時咱們業務上並不須要如此精細的控制。好比有時一個簡單的if...else...就解決了問題;複雜點的可能會設計幾種「策略」,而後由業務專家針對每種狀況進行配置;再複雜的可能還會考慮BI的方案:收集數據,而後展開多維度的分析,最後由分析師連同業務專家獲得某種規律性的結論,再內置到系統裏,效果可能也不錯。

再舉個酒店分銷調價的例子,在將酒店分銷給代理售賣前,通常會在底價基礎上對產品賣價進行干預,調整必定的點數(百分比),保證銷量的同時,最大化收益。

一開始,可能僅僅是一個固定的比率(好比加價6%)。隨着業務發展,設計了一系列策略,好比針對「是否獨家」、「是否熱門」2維度將酒店劃分到4個象限裏,對「獨家-熱門」酒店實施一個較高的調價比率,而對「非獨家-冷門」酒店實施一個較低的比率。結果收益提升了一大截,效果不錯。

然後,業務人員但願施行更加精細的控制,因而對酒店的星級、地區、商圈、獨家、房型等維度進行了更爲精細的劃分,並結合歷史數據進行統計分析,對各類結果施以不一樣的調價比率。產量和收益又進一步提高了。

這時若是各業務方都比較滿意、成本也不高,系統複雜度也不高,那就沒必有再考慮更爲精細、智能的AI架構了。引入AI,本質上,仍是要帶來效率、體驗或準確性的提高,同時平衡成本和收益,控制系統複雜度。若是不能帶來這些,那就要從新審視咱們的方案了。

固然,有時咱們也會考慮架構的擴展性和業務的發展,預留一些設計上的「開閉」空間。「策略模式」這時也許是個不錯的選擇。對於系統的默認策略,採用基於人工的、配置的方案,同時保留策略擴展接口,隨着未來業務要求的增高,再引入「基於AI的策略」。這樣即控制了當前的成本,又平衡了系統的擴展性。

2. 數據

數據決定了機器學習的上限,而算法和模型只是逼近這個上限而已。

數據的採集和獲取一般須要很長時間,創建充分、全面的數據倉庫,更須要長時間的積累和打磨,所以,數據在任何一個公司都是寶貴的資產,不願輕易送出。而一個算法模型的成功與否,關鍵看數據和特徵。所以,一套 AI 架構的解決方案,最終可否取得好的效果,關鍵看是否已經採集到了足夠、充分的數據。

這些數據來源通常包括:自有系統採集、互聯網公開數據收集(或爬取)、外購等。

自有系統採集是最多見的方案,業務系統自身產生的數據,通常也更適合業務場景的應用。可這樣的數據珍貴且稀少,因此每每須要公司的決策者提早佈局,早早的開始收集、整理業務數據,建設數據平臺、充實數據倉庫,這樣通過幾個月甚至幾年之後,在真正用到AI架構時,彈藥庫裏已經儲備了充足的「彈藥」了。

互聯網公開的數據爬取也是一個快速且免費的方法,但在茫茫大海中找到適合本身的數據並不容易,且由於你能拿到、別人也能拿到,所以很難拉開和其餘競對公司的差別。

外購通常要花費鉅額費用,且質量良莠不齊,通常是互聯網公司最後不得已的方案。

在數據獲取成本高、難度大、積攢時間久這樣的前提下,而場景又適合使用 AI 架構,面對數據匱乏,是否是就沒有辦法了呢?也不盡然,咱們仍是有些替代方案的。

  • 一、 淺層模型一般比深層模型須要更少的數據量,所以,在數據量不足的時候,一般可使用淺層模型替代深層模型來減小對數據量的需求。固然,模型的表達能力也會隨之降低,但應對不是特別複雜的業務場景,淺層模型也同樣能取得很好的效果。固然,隨之而來的是對特徵挖掘更高的要求和對模型選擇的挑剔。拿分類任務來講,SVM、邏輯迴歸、隨機森林、樸素貝葉斯...每種模型都有其特色和適用性,要充分考慮和權衡,才能利用好每一條數據。所謂數據不夠、模型來湊,也是不得已的辦法。
  • 二、 採用預訓練模型也是下降數據需求量的一個很好的辦法,遷移學習已經在圖像分類問題上普遍運用, BERT 模型也將預訓練模型帶入天然語言處理的大門。在一些特定問題上,若是能找到合適的預訓練模型,再加之少許本身的數據進行微調,不但對數據的需求量下降,訓練時間也大大下降,一箭雙鵰。只是合適的預訓練模型可遇而不可求。
  • 三、 還有一個減小數據需求的變通的辦法是採用少許數據先「啓動」,而後不斷獲取數據,並加快模型更新頻率,直至採用「在線學習」的方法。這裏其實是將總的數據需求,拉長到時間維度去解決。固然,這裏也須要業務上容許前期模型的準確度不是那麼高,隨着數據的增多和模型的不斷更新,逐步達到預期效果。
  • 舉個例子,酒店 shopper 類產品的售賣,爲了加快展示速度,一般採起供應商數據預抓取的方式落地。但供應商給的 QPS 極其有限,每次只能抓取一個酒店,高頻率的抓取能夠保證酒店數據的新鮮度,給客人更好的體驗;低頻率的抓取因庫存、價格信息時效性不能保證,每每就會致使預約失敗,形成損失。所以,如何在酒店間合理的分配 QPS 就是一個典型的機器學習問題。
  • 咱們從酒店熱度、預約週期、節假日等多個維度進行了特徵挖掘,最後卻發現「季節」這個關鍵因素,咱們卻提取不到有效特徵,緣由是數據倉庫裏只有三個月的數據,也就是隻有當季的數據。
  • 爲了解決這個問題,咱們從新設計了模型,調整了架構方案,採用「在線學習」的方式,將模型更新問題歸入到了解決方案中。原始數據只用來訓練一個初始模型,上線後,模型不斷拿新產生的數據並進行迭代更新,同時對時間線更近的數據賦以更高的樣本權重,以此來保證對季節性因素的跟進。系統上線後,取得了很好的效果。
  • 四、 強化學習在初始數據缺少的狀況下,大多數時候也是一個備選方案。強化學習採用「試錯」的方式,不斷演化,並最終學到規律。固然這須要業務模型作相應的調整,同時,若是演化週期過長,那有可能模型在前期至關長的時間內,都不能作出較優的決策,所以須要業務容忍度較高。

3. 算力

衆所周知,訓練過程是一個典型的「計算密集型任務」,沒有強大的算力,是難以支撐算法模型的訓練和研究的。作機器學習的計算平臺,GPU 幾乎是標配,其訓練時間比 CPU 通常能縮短 5 倍以上。

目前,主要有自建和租賃雲平臺兩種途徑獲取。若是「不差錢」,固然能夠選擇自建,但如今 GPU 升級換代太快,基本一年一換。對於作機器學習的 GPU 來講,運算速度是關鍵,極可能花了大價錢搭建的 GPU 集羣,過幾年卻變成了一臺「老爺車」。

租賃雲平臺雖然能夠隨時享受最新 GPU 運算速度帶來的「快感」,但所需花費的精力也很多。不但要詳細對比每家雲平臺提供的服務和成本,還要合理的搭配 CPU和 GPU,作到資源利用最大化。

說了這麼多,提的最多的可能就是「成本」和「收益」這兩個詞了,這也是業務最關心的問題。不管是計算資源仍是系統架構,上一套 AI 架構的解決方案都是須要投入至關大的成本的,若是選擇得當,在一個合適的場景下,AI 也是能帶來至關不錯的收益;但若是入不敷出,選擇 AI 架構的解決方案就要慎重了。

最後,技術人員儲備和法律因素也是上AI架構前須要考量的問題,前陣子還發生了國家工信部約談AI換臉應用企業的事件。

AI 是一場浪潮,它不只帶來了新的技術和行業,也給了老系統煥發新生命活力的機會。做爲技術人員,咱們不只要擁抱新技術帶來的挑戰,更要清楚其技術選型的主要因素和背後的風險,這樣才能屹立浪潮之巔。那麼,你是否須要 AI 架構的解決方案呢?

相關文章
相關標籤/搜索