作者：字節終端技術——覃量
前言
端智能，顧名思義就是在端上跑AI模型。端智能作為目前火熱的一個新方向，在業界已經開始嶄露頭角。阿里、谷歌、快手等大企業都在積極布局端智能，用端上AI來優化各種業務場景並取得了非常突出的效果。
字節Client AI團隊深耕端智能領域，並在今年早些時候與西瓜視頻合作落地了端智能視頻預加載方案，取得了不錯的結果。本篇我們通過這個案例，帶大家一起來揭開端智能的面紗，看看端上AI在實際中是如何應用提高業務效果的。
一、場景
1.0 場景介紹
西瓜視頻預加載這個場景非常簡單： 在播放當前視頻時，客戶端會對后續3個視頻，每個視頻預加載固定800K的緩存。讓用戶在播放到后續的視頻時可以快速起播，獲得更為流暢的播放體驗。
但這樣一個固定的策略也有一些非常明顯的問題：
- 用戶大部分情況下不會看完800K的buffer，而是簡單瀏覽內容后就划到下一個視頻，造成帶寬的浪費
- 在用戶仔細瀏覽視頻內容時，如果沒有足夠的buffer，容易造成起播失敗或者卡頓，影響用戶體驗
最理想的預加載策略其實是使『預加載大小和播放大小盡量匹配，用戶在起播階段會看多少，我們就提前加載多少，即不會造成浪費，又不會影響用戶體驗』。
1.1 深入解析
但實際情況千變萬化，想要用戶看多少我們就提前加載多少是一件基本不可能做到的事情。這時我們有了一個想法，如果我們可以預測用戶接下來的行為模式， 比如 知道他接下來會 『 快 速切換視頻』 還是 『慢速消費視頻』 的話， 是不是 就可以輔助優化我們的預加載策略了 ？
事實上用戶在一段時間內的行為模式是具有一定規律的：這個用戶的『手速快慢』、對『互動的傾向性』、是不是在『碎片化時間』、是否是『工作日』等等。我們可以通過這些規律來預測用戶的行為模式，進而得到一個更佳的預加載策略。比如我們預測用戶接下來很大概率會進行『快速瀏覽視頻』這種模式，此時更符合用戶需要的預加載策略可能就是『減少預加載的緩存大小 & 增加預加載的視頻個數』，反之亦然。
1.2 突破方向
這時我們會發現優化這個場景的關鍵可以被轉換成這樣一個問題：如何預測端上用戶的行為模式？
其中又有這么幾個子問題：
-
使用『規則』還是『模型』來進行預測？
-
規則
- 優點：簡單、開發成本低、可以快速驗證方案效果
- 缺點：只能應對簡單場景，場景復雜度越高，規則會變得愈發的復雜，導致開發和維護成本變高
-
模型
- 優點：可以應對復雜場景、做更為精細化的策略
- 缺點：開發成本較高、周期也更長
-
一般來說：
- 在前期准備階段可以使用規則來快速驗證方案的效果，預估策略大致的收益
- 在方案落地階段會使用模型的學習預測能力，來制定高可用、高擴展的精細化策略，最后達到最大化的效果
-
-
這個模型預測應該在『雲端』上做還是在『客戶端』上做？
-
因場景而異，並沒有一個固定通用的做法
-
以目前這個場景為例，預加載場景具有這樣的特點：
- 需要預測用戶在頁面的行為模式，和用戶的滑動行為強相關
- 滑動行為在短時間周期（秒級、分鍾級）具有一定規律，長時間周期（天級、月級）規律性較弱
- 預加載觸發頻率高，時間短，對實時性要求很高（否則容易造成用戶卡頓）
- 端上一些特征由於隱私以及量級的關系，不適合進行上報
-
對於這樣實時性要求高、特征數據時間周期短的場景，比起請求雲端的長響應鏈路，在『客戶端』上直接跑模型來進行預測會是一個更好的方案。
-
最后用一個表格來小結一下『端智能』與『雲智能』的特性：
| 決策成本 | 響應延遲 | 數據維度 | 計算規模 | |
|---|---|---|---|---|
| 雲智能 | 網絡連接 + Native迭代 | 分級：埋點延遲 + 近線延遲 | 長期 + 全用戶 + 統計特征 | 大數據 + 大模型 |
| 端智能 | 數據觸發 + 動態腳本 | 秒級：端側計算延遲 | 短期 + 單用戶 + 時序特征 | 小數據 + 小模型 |
1.3 優化思路
經過上面的幾個拆解和分析，整個場景的優化思路已經慢慢浮出水面了：
我們可以利用 『端上的實時處理能力』 + 『AI的復雜場景抽象化能力』 來直接在客戶端上『預測用戶的行為模式』 ，進而根據預測結果來『優化視頻預加載策略』。
二、端智能預加載方案
2.0 端智能方案
有了思路以后，剩下的就是怎么把我們的思路落地了。
通常來說，端智能方案會包括以下幾個階段：
- 端上AI開發
- 客戶端開發
- 算法包開發
這幾個階段是互相獨立、可以並行推進的，下面會以這個『視頻預加載』場景為例來介紹一下上述的各個階段。
2.1 端上AI開發
2.1.0 特征挖掘
從這個場景的優化思路中我們已經明確了預測的目標是「用戶的行為模型」，剩下的問題就是：用什么來預測？
思考全屏內流場景下，什么特征會影響或者反映用戶會「快速滑動短暫瀏覽 or 緩慢滑動仔細觀看」？
- 設想一個用戶正在不斷滑動觀看視頻，如果連續幾個視頻都是他不怎么感興趣的內容，被一下滑過，那么用戶對下一個視頻的期望or耐心會不斷減小，如果還是不感興趣的內容可能會只瀏覽完標題就滑走，平均下來當前整體觀看時長也就較短。
- 相反，如果前幾個視頻用戶都比較感興趣，看得很開心，那么對於下一個視頻的期望or耐心也會隨之上升，平均下來當前整體觀看時長也就較長。
- 用戶在滑動瀏覽視頻時，對不同類型、甚至不同來源的視頻會不會有所偏向，導致觀看時長也因此不同？ 比如用戶當前想看一個比較短的視頻，那么對於長視頻就會直接滑過。
從這樣對場景的思考中，我們可以得出非常多的用戶行為特征：
有了用戶行為特征概念上的思考以后，我們就可以進行數據收集和分析， 把「概念」轉化為「數據」。這需要我們對這個場景相關的端上埋點進行一次梳理。梳理埋點的好處有這么幾個：
- 在梳理埋點的過程能夠讓我們以一個全面和直觀的視角來看我們的場景。
- 啟發特征挖掘的思路
- 對現有數據查缺補漏
2.1.1 特征處理
有了從埋點及其他來源的原始數據后，我們需要將原始數據進行處理，轉化成特征數據。特征處理的思路有非常多，可以通過不同維度來提取特征，比如分為歷史特征和實時特征。其中還可以通過不同維度、粒度，或者將多個特征進行有條件的組合來進行不同的嘗試，比如：
- 過去x條的樣本數據
- 過去x個視頻的相關樣本數據
- 過去x小時的樣本數據
2.1.2 特征分析
通過特征處理得到了一系列我們認為對當前的問題有意義的特征后，還需要進一步分析每個特征的價值大小。這里的價值指的是這些特征對模型的價值，進而我們才能夠在獲取這些特征的成本以及效果的收益上來做一個權衡。
分析特征對模型的價值也有幾個常用的方法，比如：
- pearson、spearman、cohen's kappa等相關性系數方法
- Lasso、Ridge等正則化方法
- 距離相關系數方法
- 決策樹特征排序方法
這些方法各自有自己的適用場景，這里就不再贅述。特征分析除了對模型效果進行先驗預估外，還可以幫助我們篩選出對當前場景最有價值的特征。因為增加特征通常來說是有附帶成本的，比如說：
- 可能增加數據采集的耗時
- 可能增加特征處理的耗時
- 可能增加模型的復雜度，從而增加模型的體積和推理耗時
作為在客戶端上運行的模型，為了更好的實時響應能力，盡可能地降低整個鏈路的耗時以及模型大小也能更好的保證端上智能的效果。
有了端上AI模型以后，我們還需要做一些客戶端和算法包對應的開發工作。
2.2 算法包開發
算法包開發主要做的事情有兩件。
2.2.0 端上特征工程
端上特征工程就是將端上原始數據處理為特征數據。在字節內有pitaya端智能框架，為端上特征工程的各項能力進行了支持。
一般來說，我們需要在端上提供這樣的特征工程能力：
- 支持不同的觸發方式來支持不同場景的需要
- 從不同的數據來源（埋點、用戶畫像數據、設備特征等...）來獲取端上特征的能力
- 對數據有不同維度和不同層級的管理
有了這樣的能力后，我們就可以在端上將特征實時處理為模型所需的輸入數據，來進行后續的推理預測。
2.2.1 端上模型推理
除了特征處理外，我們還需要在端上建立一個模型推理的鏈路，這部分在字節內同樣是由pitaya框架來支持的。這個鏈路主要分為三個部分：
環境部署
顧名思義，就是在端上提供可以在實時部署的推理引擎，以及對應虛擬機環境。
動態化能力
由於端上場景非常多、迭代也會非常的快。策略、模型、甚至場景都可能隨着客戶端更新或者時間推移來進行不斷快速的迭代。所以對於端智能來說，最重要的能力之一就是動態化能力。也就是動態地將算法包、模型和運行環境下拉到端上，並進行部署和管理的能力。通過動態更新能力，可以在不依賴客戶端發版的情況下就動態地更新我們的策略，用非常低成本的方式就可以實現策略的迭代。
實時效果監控
除此之外，還需要有一套實時效果監控系統。用來實時觀測模型的效果、性能和穩定性等關鍵指標，並在未來模型因為用戶群體改變或場景改變效果下降時來進行及時報警。
2.3 客戶端開發
對於客戶端來說，需要根據不同場景來決定不同算法包的觸發時機，以及對應算法包結果的解析邏輯，從而執行相應的業務邏輯。在視頻預加載場景下是這樣的：
-
觸發算法包執行
- 橫屏內流場景完成首幀渲染后，主動觸發算法包執行。
-
解析算法包結果
- 業務添加預加載任務的邏輯，由之前的固定策略，改為根據算法包返回的執行結果，解析后添加預加任務。
在視頻預加載這個場景中，我們在前期利用動態更新的能力快速實驗了預加載極端值和不同加載個數給播放體驗會帶來的影響，確定了適合視頻預加載的最佳組合區間。同時也利用實時效果監控，在實驗中發現出模型當前的各種問題，從而不斷進行修正和迭代，提升模型的效果
三、方案效果評估
客戶端業務代碼調整完成，模型和算法包也開發完成之后，就可以通過AB實驗來驗證我們方案的效果了。AB實驗大家都很熟悉，端智能的實驗本質上並沒有不同，但也有幾點需要我們特別關注一下。
3.0 快速迭代算法包
端智能在提供了靈活方案的同時，也為實驗帶來了更多可以驗證的維度。我們可以嘗試使用不同模型、組合上不同的策略、甚至不同的觸發時機。由於可以嘗試的組合太多，在實驗中很容易碰到流量以及實驗組不夠用的問題。
這個問題字節Pitaya平台是通過提供算法包部署和分流能力來解決的。支持在算法包發布時建立子發布，每一個子發布都可以當作我們的一個策略組，來驗證我們對一個策略方向的想法。同時每個策略組還可以與AB的實驗組一一綁定，在實驗過程中迭代更新我們的策略，以達到實驗不關停，快速驗證不同策略的目的。
在視頻預加載場景中，我們可以這樣設計我們的實驗：
| 實驗組 | 策略組 |
|---|---|
| 線上組 | |
| 實驗組一 | 改變預加載個數 (1,3,5,7, ..) |
| 實驗組二 | 改變預加載size (500, 700, 900, ..) |
| 實驗組三 | 改變預加載調度方式 (並行, 串行, ..) |
每一個策略組對應一個優化方向，具體優化細節在策略組內通過算法包迭代來調整。這使得我們能在短周期內快速觀察各方向的效果，並尋找出各策略組內表現最好的策略。
這樣的設計還有一個好處：算法包的發布大部分情況下不依賴於客戶端版本，算法包的迭代可以根據實驗反饋的情況進行更快速的調整，達到一周一次，甚至一周兩次的頻率。
3.1 算法包監控
端智能的實驗相比於一般的實驗，除了AB實驗中的業務效果指標外，我們還需要關注一下算法包本身的指標，來保證模型效果也符合我們的預期。這些指標通常包括：
- 性能指標：執行成功率、執行耗時、PV、UV，...
- 效果指標：accuracy、precision、recall、TP、FP、TN、FN、...
有了這樣的實時監控我們就可以隨時把握算法包的運行狀況以及模型的效果，在算法包出現異常導致效果下降時及時發現定位，並進行優化和迭代。
3.2 方案優化
在實驗過程中，我們根據實驗數據反映出來的問題，不斷對方案進行了很多次優化。
比如在review模型效果和實驗數據時，發現FN的影響在我們這個場景會比FP大很多。於是嘗試通過調整閾值來降低FN比例，並在實驗中快速迭代驗證了一下效果，結果播放卡頓率/啟播失敗率等指標都有比較明顯的優化。
再比如我們在分析模型預測結果時，發現用戶的行為模式在短時間段內具有一定的規律，並針對不同的時間段來優化我們的模型策略，進一步提升了業務效果。
在算法包動態更新能力的加持下，我們可以快速地迭代我們的策略。從啟動時的簡單粗略，不斷優化到模型能力越來越強大，算法策略越來越精細。最終能夠通過端上智能找到最符合當前業務場景的精細化策略。
3.3 收益結果
通過一系列的實驗，我們在西瓜視頻的視頻預加載策略也成功落地上線，並在各項視頻播放指標以及帶寬成本指標上取得了可觀的收益：
- 從播放指標上看：端智能預加載策略比起固定的預加載策略：失敗率上減少了3.372%，未起播失敗率減少了3.892%，卡頓率減少了2.031%，百秒卡頓次數減少了1.536%，卡頓滲透率減少了0.541%
- 從成本指標上看：端智能預加載策略比起固定的預加載策略，在總帶寬成本上減少了1.11%，為公司節省上千萬的成本。
四、總結
線上檢驗時我們會發現很多之前階段隱藏的問題，比如特征選取得不好需要添加新特征，推理耗時比較高需要優化模型和算法包，模型與策略結合得不好導致總體效果沒有達到預期等等...
每個新的問題都會反過來幫助我們優化之前的某個階段，迭代我們的策略，然后再一次接受線上的檢驗。整個階段可以被看成一個環：
AI和業務相結合的場景往往需要在這個環內經過若干的周期的優化和提煉，不斷達到更好的效果，才能最后迭代出一個成熟有效的方案，最終提升業務效果。
字節端智能平台 Pitaya，是字節跳動Client Infra團隊和Data-MLX團隊共同打造的一套端+雲的基礎設施，旨在幫助終端業務高效利用AI能力提高業務效果，拓展業務場景。目前主要建設有端上智能業務，端上特征工程，端上推理引擎，端上訓練等框架，在抖音，西瓜視頻，今日頭條，教育等多個業務合作落地，幫助業務提升效果。
火山引擎應用開發套件MARS是字節跳動終端技術團隊過去九年在抖音、今日頭條、西瓜視頻、飛書、懂車帝等 App 的研發實踐成果，面向移動研發、前端開發、QA、 運維、產品經理、項目經理以及運營角色，提供一站式整體研發解決方案，助力企業研發模式升級，降低企業研發綜合成本。可點擊鏈接進入官網了解更多產品信息。