導讀：伴隨著AI的興起，越來越多的智能產品誕生，演算法鏈路也會變得越來越復雜，在工程實踐中面臨著大量演算法模型的從0到1快速構建和不斷迭代優化的問題，本文將介紹如何打通資料分析-樣本標注-模型訓練-監控回流的倍訓，為復雜演算法系統提供強有力的支持，
新技術/實用技術點：
- 實時、離線場景下資料加工的方案選型
- 高維資料的可視化互動
- 面對不同演算法，不同部署場景如何對流程進行抽象
01. 背景 - 技術背景及業務需求
小蜜系列產品是阿里巴巴為消費者和商家提供的智能服務解決方案，分別在用戶助理、電商客服、導購等方面做了很多作業，雙十一當天提供了上億輪次的對話服務，其中用到了問答、預測、推薦、決策等多種演算法模型，工程和演算法同學在日常運維中會面臨著如何從0到1快速演算法模型并不斷迭代優化，接下來將從工程角度介紹如何打通資料->樣本->模型->系統的倍訓，加速智能產品的迭代周期，
- 實作
實作這一程序分為2個階段：
0->1階段：
模型冷啟動，這一階段更多關注模型的覆寫率，
實作步驟：
A. 抽取對話日志作為資料源
B. 做一次知識挖掘從日志中挑出有價值的資料
C. 運營人員進行標注
D. 演算法對模型進行訓練
E. 運營人員和演算法端統一對模型做評測
F. 模型發布
1->100階段：
badcase反饋和修復階段，主要目標是提升模型的準確率，
實作步驟：
A. 運營端根據業務反饋（頂踩按鈕）、用戶不滿意會話（如：轉人工）收集badcase資訊
B. 進行資料分析，將分析結果給到不同的模型模塊、規則模塊
C. 演算法端對以上模型分別進行訓練
D. 最終發布到線上生效
- 痛點
在以上程序中，會遇到如下幾個痛點：
A. 不同演算法需要不同的標注互動形式，如何快速支持
B. 運營方的標注憑借個人感覺，缺少指導，無法保障質量
C. 線上badcase如何快速發現和修復
D. 機器人中部署了上百個演算法模型，日常維護需要占用工程師大量的精力
E. 資料樣本在業務和演算法之間來回傳遞，有安全隱患
02. 倍訓迭代模型的產生 - 模型訓練倍訓
基于以上的痛點，阿里小蜜團隊構建了模型訓練倍訓，該倍訓系統主要包括對話系統層、資料層、樣本層和模型層這4個部分，
彼此之間的關系、流程如下：
A. 對話系統層：用戶端會跟機器人系統進行對話
B. 對話產生的日志經過數倉埋點進入到資料層
C. 資料層由運營人員做標注
D. 完成標注的資料作為樣本，借助演算法團隊提供的訓練/評測服務，進入到模型層
E. 模型發布到系統中，形成訓練倍訓 - 系統 => 資料
① 多維資料查詢
這一部分講述如何從系統層到達資料層，這里會涉及到“多維資料查詢”這樣一個概念，前面提到，資料來源的渠道是多種多樣的；這些資料會具備多種多樣的屬性，例如：行業屬性、用戶型別屬性等，不同業務的對話日志帶有各自的業務屬性，
在應用多維資料查詢的程序中，難點是屬性相交等問題，平臺的第一項作業就是資料預處理，遍歷出所有的業務-屬性組合；運營人員取資料的時候，先選擇業務維度；接著從業務維度到資料維度進行一層映射，從而去掉其業務屬性（例如，時間、地點、行業等維度分別映射成A、B、C）
② OLAP與“資料立方體”
這里用到了聯機分析處理（OLAP ，On-Line Analytical Processing，一種資料動態分析模型）技術，首先會構造“資料立方體”這樣一種資料結構，將資料分成多種維度，包括：來源維度、路線維度、時間維度，
對資料立方體由上卷和下鉆這兩種基本操作，生成新的立方體，下圖中，右半部分是將城市維度進行了上卷操作，左半部分是將季度維度進行了下鉆操作，
資料立方體結構的不足：
A. 維度型別，對于商家這種百萬數量級的維度，搜索起來效率低下，針對這種缺點，選擇對于重點商家重點維度進行存盤，
B. 多條件的or關系查詢，在這種立方體結構中無法實作，
C. 列舉數量和效率的平衡，需要根據具體覆寫業務定義屬性等， - 資料 => 樣本
① 標注組件
資料標注環節由“人工智能訓練師”這個角色參與，標注形式會根據演算法的選擇而調整，包括：標簽、物體、屬性間關系等，
如下圖所示：
組件包括狀態欄、搜索框、表格（支持配置），可進行標注分類、文本型精選、排序型篩選、任務操作內容等多個模塊（詳見下圖），
這樣的組件有如下的缺點：
A. 1D表格無法有效利用演算法資料結構
B. 操作繁瑣困難
C. 浪費像素空間
D. 無盡的翻頁
② 高維資料可視化
基于組件存在的以上種種缺點，我們選擇了將資料降維，
什么是高維資料？
高維資料包括：
A. 機器人阿里小蜜的文本資料
B. 圖片
C. 語音資料
可視化后的高維資料長什么樣子？
可視化前
可視化后
上圖是對文本資料可視化后的結果，實作步驟：
A. 對文本資料進行聚類，根據相似度變成平面結構
B. 用顏色區分類別
這種方式可以直觀看出線上的語料分布，包括分布類別、分布集中趨勢等，
這里用到的技術方案包括：
A. 降維：主要用PCA和T-SNE兩種降維方式
B. 向量化：資料拆分之后，將資料轉變為可比較的表示形式，對于文字，主要使用word2vec；而對于圖片，主要使用phash編碼，
C. 聚類：聚類主要使用k-means，
③ 散點圖塌縮及其互動
下圖中的左圖是聚類后的效果圖，聚類完成后，每一類圖片的每一類都會分布到一起；再通過散點圖塌縮演算法，將每一個類壓縮成一個散點，通過顏色區分類別種類，
利用這種方式，可以找出badcase中占比最高的一類，從而進行修復，
在對類的互動中，有一些特殊的操作，例如：框選，上圖右圖的散點圖中，可以通過框選的方式抽取每一類的關鍵詞，
03. 實時布防 - 語料關鍵詞的識別與添加
上圖是某一天貓商家的海報圖：某商家正在搞一個促銷活動，找易烊千璽作為代言人，由于機器人預先不知道會有這樣一個活動發生，模型中自然不包含這樣的關鍵詞，商家發現當天的未識別語料全部都和“易烊千璽”相關，但是機器人不識別這個關鍵詞（未識別率達70%以上），怎樣快速幫商家解決這類問題呢？
- 實時布防
這類的AI能力如何做實時布防呢？將這類問答、意圖等AI能力在自己的服務器上以日志的形式做埋點，服務器會將日志收集起來通過flink平臺做實時流式聚類，商家作業臺通過標注組件的形式展現當前時段的高頻問題，并通過互動式選項選擇如何修復（以上圖中的藍色選定區域為例），從而讓機器人能夠識別該語料，
- 資料加工
從業務日志中提取模型需要的語料需要進行一些基本的演算法加工，這些步驟除了面臨大資料的壓力，研發工程師還要考慮對這種加工能力的封裝和復用，
A. 首先，對日志資料做脫敏：將日志中的手機號、地址、人名等去掉，對單字型文本、語聊型文本的去除；
B. 接下來對資料做去重和向量化；
C. 下一步是對處理完成的資料做聚類；
D. 聚類后的資料做摘要，進而做相似度計算，
整個程序需要很多的演算法模塊，每一個模塊都會封裝成一個演算法組件，提供到不同的模型迭代中，上圖的下半部分就是語料經過了不同演算法模塊的變化，從向量到聚類，進而抽取不同Topic，
下圖是以上程序抽象成的模板，
模板中包含了演算法組件、標注組件、訓練組件等不同的組件；運營人員在線上可以挑選不同組件配置模板來優化對應的模型，
在模板執行的程序中，可使用mapreduce組件、UDF組件以及Spark組件，Spark組件是目前通用性較強的組件，既可本地調度，又可遠程調度， - 構建資料處理引擎
基于Spark構建資料處理引擎，分為客戶端和計算集群兩個系統，客戶端包括組件庫、調度引擎，以及Spark Client Runner，
這種架構的好處：演算法可以在本地開發spark組件，直接集成到模板中；同時支持遠程集群模式和本機輕量級調度，大小資料量都適用；同時spark擁有 SQL和spark mllib兩個組件庫，研發通過封裝可以直接開放給業務使用，
本次分享就到這里，謝謝大家，
歡迎加入DataFunTalk交流群，跟同行零距離交流，如想進群，請加逃課兒同學的微信（微信號：DataFunTalker），回復：交流，逃課兒會自動拉你進群，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/49912.html
標籤：其他
上一篇：IoU-aware Single-stage Object Detector for Accurate Localization