人工智能應用架構的思考
一、Paddle Lite 和 PaddleSlim
目前在深度學習領域分類兩個派別，一派為學院派，研究強大、復雜的模型網絡和實驗方法，為了追求更高的性能；另一派為工程派，旨在將算法更穩定、高效的落地在硬件平臺上，效率是其追求的目標。復雜的模型固然具有更好的性能，但是高額的存儲空間、計算資源消耗是使其難以有效的應用在各硬件平臺上的重要原因。所以，卷積神經網絡日益增長的深度和尺寸為深度學習在移動端的部署帶來了巨大的挑戰，深度學習模型壓縮與加速成為了學術界和工業界都重點關注的研究領域之一。
1. 端側推理引擎的背景
隨著深度學習的快速發展、特別是小型網絡模型的不斷成熟，原本應用到云端的深度學習推理，就可以放到終端上來做，比如手機、手表、攝像頭、傳感器、音響，也就是端智能。此外，可用于深度學習計算的硬件也有井噴之勢，從 Intel 到 Nvidia、ARM、Mali、寒武紀等等。相比服務端智能，端智能具有延時低、節省資源、保護數據隱私等優勢。目前已經在 AI 攝像、視覺特效等場景廣泛應用。
然而，深度學習推理場景中，多樣的平臺、不同的芯片對推理庫的能力提出了更高的要求。端側模型的推理經常面臨算力和內存的限制，加上日趨異構化的硬件平臺和復雜的端側使用狀況，導致端側推理引擎的架構能力頗受挑戰。端側推理引擎是端智能應用的核心模塊，需要在有限算力、有限內存等限制下，高效地利用資源，快速完成推理。因此，飛槳期望提供面向不同業務算法場景、不同訓練框架、不同部署環境， 簡單、高效、安全的端側推理引擎。
2. Paddlelite 的特色
為了能夠完整地支持眾多的硬件架構，實現在這些硬件之上的各種人工智能應用的性能優化，飛槳提供端側推理引擎 Paddle Lite。截止到現在，Paddle Lite 已廣泛應用于搜索廣告、手機百度、百度地圖、全民小視頻等多個重要業務。
Paddle Lite 具備如下產品特色：
1） 移動端和嵌入端的模型部署工具，可使用其部署 PaddlePaddle、TensorFlow、Caffe、ONNX 等多種平臺的主流模型格式，包括 MobileNetV1、YoloV3、UNet、SqueezeNet 等主流模型。
2）多種語言的 API 接口：C++/Java/Python，便于嵌入各種業務程序。
3）豐富的端側模型：resnet、effcientnet、shufflenet、mobilenet、unet、facedetection、unet、ocr_attention 等。
4）支持豐富的移動和嵌入端芯片：ARM CPU、Mali GPU、Adreno GPU，昇騰 &麒麟 NPU，MTK NeuroPilot，RK NPU，寒武紀 NPU，X86 CPU，NVIDIA GPU，FPGA 等多種硬件平臺。
5）除了 Lite 本身提供的性能優化策略外，還可以結合 PaddleSlim 可以對模型進行壓縮和量化，以達到更好的性能。
3. 架構設計
架構圖如上所示，Paddle-Lite 架構側重多硬件、高性能的支持，其主要設計思想如下：
1）引入 Type system，強化多硬件、量化方法、data layout 的混合調度能力。
2）硬件細節隔離，通過不同編譯開關，對支持的任何硬件可以自由插拔。
3）引入 MIR(Machine IR) 的概念，強化待執行環境下的優化支持。
4）圖優化模塊和執行引擎實現了良好的解耦拆分，保證預測執行階段的輕量和高效率。
二、AIOps 的思考
1. 背景
AIOps，最初的定義是 Algorithm IT Operations，是利用運維算法來實現運維的自動化，最終走向無人化運維。隨著技術成熟，逐步確定為 Artificial Intelligence for IT Operations——智能運維，將人工智能應用于運維領域，基于已有的運維數據（日志、監控信息、應用信息等），通過機器學習的方式來進一步解決自動化運維無法解決的問題。
早期的運維工作大部分是由運維人員手工完成的，手工運維在互聯網業務快速擴張、人力成本高企的時代，難以維系。于是，自動化運維應運而生，它主要通過可被自動觸發、預定義規則的腳本，來執行常見、重復性的運維工作，從而減少人力成本，提高運維的效率。總的來說，自動化運維可以認為是一種基于行業領域知識和運維場景領域知識的專家系統。隨著整個互聯網業務急劇膨脹，以及服務類型的復雜多樣，“基于人為指定規則”的專家系統逐漸變得力不從心，自動化運維的不足，日益凸顯。
DevOps 的出現，部分解決了上述問題，它強調從價值交付的全局視角，但 DevOps 更強調橫向融合及打通，AIOps 則是 DevOps 在運維（技術運營）側的高階實現，兩者并不沖突。AIOps 不依賴于人為指定規則，主張由機器學習算法自動地從海量運維數據（包括事件本身以及運維人員的人工處理日志）中不斷地學習，不斷提煉并總結規則。AIOps 在自動化運維的基礎上，增加了一個基于機器學習的大腦，指揮監測系統采集大腦決策所需的數據，做出分析、決策，并指揮自動化腳本去執行大腦的決策，從而達到運維系統的整體目標。
下圖是百度運維發展歷程：
從 2014 年開始，從最開始的行業領域知識加上運維專家經驗，到之后加上人工智能算法，演進成 AIOps，從數據建設和智能監控場景入手，逐漸覆蓋到智能故障管理，變更管理，容量管理和服務咨詢。
綜上看，自動化運維水平是 AIOps 的重要基石，而 AIOps 將基于自動化運維，將 AI 和運維很好地結合起來，這個過程需要三方面的知識：
1）行業、業務領域知識，跟業務特點相關的知識經驗積累，熟悉生產實踐中的難題。
2）運維領域知識，如指標監控、異常檢測、故障發現、故障止損、成本優化、容量規劃和性能調優等。
3）算法、機器學習知識，把實際問題轉化為算法問題，常用算法包括如聚類、決策樹、卷積神經網絡等。
百度的故障管理場景如圖所示，主要包括故障發現，故障止損，故障診斷智能預警等。
2. 故障發現
運維的黃金指標有請求數（流入狀態），成功率（流出狀態），響應時間（用戶相應感受），系統容量（系統并發負載）等。其預測難點在于基線預測算法在遇到節假日這種不規律的情況時不準確，另外在于配置上的，忙閑時間機器需求差異很大，容易造成資源浪費。
2.1 基線預測算法
基線預測算法主要采用魯棒回歸+周期數據多模式挖掘相結合的算法。魯棒回歸算法的思想是假設較小窗口內符合線性趨勢變化，即局部符合線性。周期數據多模式的思想是對于不同的節假日，春節等特殊時期采用多種基線模型進行匹配。
3. 故障自愈
出現故障第一時間的原則是故障止損，而不是查明原因，甚至解決問題。先將損失止住，再進行分析。
傳統的人工故障止損有以下三個不足：相應可能不夠迅速，決策可能不夠準確，操作可能出現失誤。AIOps 中的故障止損叫做故障自愈，相對人工智障止損的不足，它可以 7*24 小時快速相應，全局一致性信息決策，程序自動化準確操作。
故障自愈的場景和止損方法如下：
4. 故障診斷
如下圖所示，為一個系統的運行流圖，G 節點此時出現故障。
人工故障針對的做法通常從兩個方向出發，一是找出 A 上的某故障跟 G 節點的關系，二是追查 G 節點異常的原因。這很大程度依賴人工歷史經驗，不易準確快速定位原因。AIOps 的智能故障診斷方法的做法是利用黃金指標綜合進行，做法如下所示：
5. 智能預警
一個很重要的運維手段就是在故障發生之前進行預警，從而減少實際損失。人工的預警方法通常是根據經驗，考慮的指標覆蓋范圍小，且閾值的設置較為困難，容易產生誤報和漏報。AIOps 的智能預警可以覆蓋上萬個指標，且通過機器學習自動學習到相應閾值，而無需人工干預。智能預警如下圖所示：
三、快手推薦系統 Dragonfly 架構啟發
1. 背景
以推薦系統為例，通常在線推薦系統包括召回，排序，重排三個模塊。召回是利用如 ANN 檢索，倒排檢索算法，將候選項從千萬降到十萬的數量級；排序是利用 CTR，LTR 等指標，將候選項從十萬降到千的數量級；最后重排是利用多樣性打散，強插，混排技術將候選項從千降到十的數量級。
為了快速復用，采用的如上圖的分離的系統架構，算法人員和架構人員的代碼交織在一起，那幺如何將業務代碼和架構代碼進行解耦呢？David Wheeler 說過，所有的計算機問題都可以通過增加一層抽象來解決。
2. 實現方法
快手架構的基本思想是構建了一種 DSL 語言 Dragonfly，讓算法人員用類 python 方式開發，而不用關注底層的實現，架構人員專注于用 c++實現底層架構。下圖右側的圖就是一個算法人員實現的例子，就是純 python 代碼，容易實現，易于閱讀。
具體解決方案是將算法都細分成算子的粒度，如下圖所示，所有的人工智能算法都是由各種算子進行組合搭建而成，架構人員負責開發這些算子的實現，算法人員在封裝好的算子基礎上進行運用。因此算法人員不關注底層實現，專心關注與上層邏輯，去編寫 DSL 語言，然后提交配置即可；架構人員不關注上層邏輯，只負責編寫底層算子。
在實現這種改進之后，最大的優點就是新場景的接入成本從 7 人日縮減到 1 人日。這種利用算子話粒度解耦的思想是我們是可以借鑒的，我們在做算法開發時，很多代碼都交織在一起，不能抽取出來，導致很多重復性的工作。如果把這些算法進行一步步的切分，分成很小的算子粒度，就能夠方便進行解耦，是的算法人員可以任意組合拼接算子，實現業務算法。
參考文獻：
[1]《Paddle Lite 端側部署》作者：吳建明
https://www.cnblogs.com/wujianming-110117/p/14398502.html
[2]《架構設計》Paddle-Lite
https://paddlepaddle.github.io/Paddle-Lite/v2.2.0/architecture/
[3]《故障管理場景 AIOps 實踐與探索》 作者：陳云
https://ppt.infoq.cn/slide/show?cid=83&pid=3355
[4]《Dragonfly 快手通用策略 DSL 在推薦系統架構的應用和演進》作者：方劍冰
https://ppt.infoq.cn/slide/show?cid=83&pid=3295
[5]《百度飛漿輕量化推理引擎 Paddle Lite 的實現和應用》作者：嚴春偉
https://ppt.infoq.cn/slide/show?cid=83&pid=3273
