作者 | 阿里文娛高階技術專家肖文良
但這樣乙個成熟技術，優酷在整個大規模落地其實遇到了很多問題和挑戰：
第一是國內使用者不太理解這個功能到底是解決什麼問題，覺得這個功能比較「傻」；第二是使用者體驗自身比較主觀，所以流暢和高畫質之間的體驗平衡點比較難把握；第三是公開演算法框架的線上效果不是特別理想，主要是公開演算法的特徵緯度比較單薄，並且比較少考慮實際產品體驗中的細節問題。
整體的技術架構，主要是由轉碼生產中心、內容分發網路、客戶端三部分構建。
在轉碼生產中心，我們把大的檔案切成非常小的分片，大概是5-10秒的時長，檔案尺寸上可能根據不同的清晰度大概從500k到3-4m這樣的水平。之後這些小的檔案分片被推送到oss儲存中心，通過骨幹網再到我們邊緣的混合雲的快取節點上去，這部分快取節點包含了傳統的cdn，也包含一些合作共建的邊緣計算節點，來提供相對比較廉價的內容分發服務。
整個智慧型檔的產品化落地，涵蓋了幾個產品技術問題：第一就是業務角度看，新技術對使用者體驗的價值如何衡量；其次是技術層面，我們沿用hls這種m3u8 + ts的協議框架，演算法上有rule-based、hybrid、deeplearning等不同模型的嘗試；最後是通過工程化、資料化角度，嘗試量化主觀使用者體驗，建立qoe的度量標準。
這個策略表就是乙個對智慧型檔決策機制的直觀抽象，演算法對每一種可能的組合輸入計算出預期的qoe得分，然後選擇最高的選項來執行。比如策略表裡列了5種可選的清晰度，從4k到360p，有效頻寬經過估算大概是30mbps，然後0.893是對這個頻寬以及當前網路質量的乙個評估置信度，再結合其它一些輸入比如buffer大小、二次卡頓概率等，最後得出乙個決策表，選擇乙個qoe得分最高的就結束了一次決策流程。這個例子中1080p看上去清晰度比較容易接受，卡頓的概率比較低，選擇這個可能是乙個比較好的策略。
直播對網路質量的感知或者說對網路速度的判定就變成跟點播不太一樣，點播場景下對網路速度因子的影響權重是較低的，對buffer時長的權重加的比較高，在buffer充裕且網路質量良好的情況下，我們有充裕時間給使用者提供更好畫質內容。
在直播場景下智慧型檔帶來新技術能力，基於這種動態的碼流切換的能力，再配合我們的實時策略聯動機制，智慧型檔提供了乙個非常完整強大的流量管理、排程框架，比如基於location、isp、裝置、場景等，可以在整體頻寬資源有限的情況下，進行更精細化的流量運營控制。比如ipadpro的2k屏，應該推送1080p以上的清晰度，而在手機上進行半屏**互動的使用者，限制清晰度在720p就足夠清晰了。
以上是2019雙11貓晚當天某個階段開始頻寬比較緊張的情況下，對一批符合流量調整條件的使用者進行的實時清晰度干預，基本上是1分鐘左右，藍色線瞬間掉下來，黃色線瞬間就上去，非常快速地完成了一次流量的調配。同時通過對hls協議的擴充套件，可以在端側支援兩個group下的主備流的自適應切換，來支援故障容災等場景的穩定性要求。
所以對主觀體驗的客觀量化衡量這條路基本上很難走好。這裡是乙個業界廣泛應用的qoe評估的標準公式，主要是在高畫質**時長得到的基礎體驗分上，通過對切換清晰度、卡頓等負面體驗的懲罰性扣分，來獲得乙個相對客觀的qoe評估分數。整體看這個分數還是比較優雅的，但是實際使用效果其實比較差。第乙個是它這個線性加權因子的權重，其實需要你自己調，比如你非常不希望使用者發生卡頓，那麼可以通過加大卡頓懲罰的θ因子來比較粗暴的訓練、調整你的演算法。
再講乙個直觀的例子，比如演算法在1080p和720p連續切換4次，按照公式的定義，1080p和720p切換的懲罰分相對是比較少的，連續切4次，基本上從和108p切換到480p切換1次的分數大致相同。但這個差異在公式上是無法體現的，但實際使用者會立刻感知到差異，而且很明顯高低位元速率的切換在視覺上會比較突兀，體驗也不好。所以整體上，qoe公式只能夠具備一定的解釋性，或者說邏輯上可行，但是實際應用起來，指導實踐的意義相對要弱很多。
在這個問題上，我們已經慢慢放棄用qoe來指導體驗的優化方向了，也不奢求找到乙個比較簡潔優雅的公式。針對體驗問題，核心思路是定義清楚關鍵鏈路、環節、場景下的核心標準，用這些子標準來定義好的體驗應該是什麼樣。比如起播場景，出現的畫面清晰度和延遲，要符合絕大多數使用者的心理預期，保證80%的使用者體驗；再比如每一輪的清晰度決策，我們都很關注決策執行後多久內發生了卡頓，如果剛把清晰度決策到1080p還沒30秒又發生了卡頓，這個也是比較難接受的。
比如我們會結合使用者歷史偏好、網路延遲，丟包率，tcp/udp協議棧資訊等來更好的評估頻寬和網路質量的可信度，同時增加更多主觀體驗上的約束條件。比如在乘坐地鐵期間，開啟優酷看電影，可能出現某段時間內手機4g訊號完全不行。傳統演算法，在速度降到很低或著將要卡頓時，立馬就去切360p，這個邏輯上沒問題，但是體驗不友好。因為在這種情況下做清晰度降級其實沒有意義，肯定還是會卡頓的。為了保證更連貫的體驗，可能我們在決策時就是什麼都不做，等著網路訊號變好，再提供更合適的**體驗。
另乙個技術創新突破點在於雲端聯動，即群體qoe優化。目前，所有端側的自適應演算法都是圍繞個體qoe的最大化來實現的。實際上每乙個「自私」的裝置個體，從乙個群體的角度來看，整體的體驗可能不是最好的，主要是頻寬資源太稀缺。比如大家都在同乙個會議場使用同乙個wi-fi熱點，通過雲端聯動來做群體qoe優化，一方面提公升頻寬的利用效率，同時又保證每個個體都能夠獲得理想的清晰度體驗。因此群體qoe優化也是我們的突破方向。
綜合來看，我們的技術突破主要是突破adaptive bitrate streaming這樣乙個相對純工程化、演算法化的邊界，往乙個更貼心、更聰明的產品技術方向在走。
在將成熟的學術演算法落地到工程業務場景的過程中的經驗：
第一，要抓住演算法框架的核心點，不要太在乎結構性的東西，要看演算法解決的核心問題的切入點，和你要解決的是不是乙個問題，是不是有借鑑參考意義。
第二，如果是和大資料有關的演算法，一定要關注好資料集的質和量，要結合自身業務，積累非常高質量的大量資料，這個底線是不能變的。
第三，演算法效果的度量標準，一定要結合實際的業務場景來看，尤其是那些不是特別標準化、不好量化的落地場景，避免生硬的套用已有標準，畢竟你才是對你要解決的問題最了解的人。
在優酷的幾道筆試題
一 求乙個三十二位整數的二進位制數中一的個數 int count ones unsigned a 二 水仙花數 int a n 10 int b n 10 10 int c n 100 if a a a b b b c c c n 三 點和麵的關係 法向量是垂直螢幕的法線表示的向量 設平面法向量為，...
優酷在多模態內容理解上的研究及應用
協同學習 每個模態的標註任務都很挑戰且成本高企，相對而言，文字模態的標註成本是比較低的，而如何能夠在缺乏標註資訊的模態資料上利用其它模態的資料進行訓練對於節省成本共享資訊非常有幫助 圖 2優酷業務構成 圖2呈現了目前優酷的主要業務模組構成以及其搜尋索引庫的內容型別及品類，單純的基於標題和描述作為被檢...
優酷闢謠裁員 阿里大文娛新財年將招聘超1800人
新浪科技訊3 月 www.cppcns.com23 日晚間訊息，針對程式設計客棧自 爆料稱優酷裁員的訊息，阿里大文娛表示，此前已做過公開闢謠，不存在裁員，未來一年公司計畫在影視內容製作 網際網路產品策程式設計客棧劃 技術研發等方向開放招聘超過 1800 名新員工。至於優酷少量人員變動的原因www.c...