公司簡介
杭州知衣科技有限公司是一家以人工智能技術為驅(qū)動的國家高新技術企業(yè)，致力于將數(shù)據(jù)化趨勢發(fā)現(xiàn)、爆款挖掘和供應鏈組織能力標準化輸出，打造智能化服裝設計的供應鏈平臺。知衣成立于2018年2月，同年獲得千萬美金A輪融資；2021年完成由高瓴創(chuàng)投、萬物資本領投的2億人民幣B輪融資，同年入圍“杭州市準獨角獸企業(yè)榜單”。
知衣憑借圖像識別、數(shù)據(jù)挖掘、智能推薦等核心技術能力，不斷升級服務體系，自主研發(fā)了知衣、知款、美念等一系列服裝行業(yè)數(shù)據(jù)智能SaaS產(chǎn)品，為服裝企業(yè)和設計師提供流行趨勢預測、設計賦能、款式智能推薦等核心功能，并通過SaaS入口向產(chǎn)業(yè)鏈下游拓展，提供一站式設計+柔性生產(chǎn)的供應鏈平臺服務。目前已服務UR、唯品會、綾致、赫基、太平鳥、海瀾之家、森馬等數(shù)千家時尚品牌和平臺。
方案架構(gòu)
當前知衣在阿里云上的整體方案架構(gòu)如下，大致分為產(chǎn)品層、服務層、數(shù)據(jù)層以及大數(shù)據(jù)平臺。
產(chǎn)品層：知衣目前有多款APP應用，如主打產(chǎn)品知衣、增強設計協(xié)作的美念等。除此之外，我們還提供定制化API向第三方開放數(shù)據(jù)接口服務和以圖搜圖的功能。從數(shù)字選款到大貨成品交付的一站式服裝供應鏈平臺也是核心的能力輸出。
服務層：相關產(chǎn)品的前后端系統(tǒng)都已經(jīng)實現(xiàn)容器化，部署在阿里云的ACK容器服務集群
數(shù)據(jù)層：主要保存原始圖片、業(yè)務系統(tǒng)產(chǎn)生的業(yè)務數(shù)據(jù)、以及OLAP數(shù)據(jù)分析服務
對象存儲OSS：保存原始圖片，構(gòu)建服裝行業(yè)十億級別款式庫
數(shù)據(jù)庫MySQL：OLTP業(yè)務數(shù)據(jù)
HBase：以KV格式訪問的數(shù)據(jù)，如商品詳細信息、離線計算榜單等數(shù)據(jù)
特征向量庫：由圖片識別抽取的向量再經(jīng)過清洗后保存在阿里達摩院開發(fā)的Proxima向量檢索引擎庫
ElasticSearch：用于點查及中小規(guī)模數(shù)據(jù)的指標統(tǒng)計計算。設計元素標簽超過1000個，標簽維度主要有品類、面料、紋理、工藝、輔料、風格、廓形、領型、顏色等
大數(shù)據(jù)平臺
日志服務SLS：用于緩存經(jīng)過圖片識別后的海量向量數(shù)據(jù)。SLS還有一個基于SQL查詢的告警能力，就是若向量數(shù)據(jù)沒有進來會觸發(fā)告警，這對于業(yè)務及時發(fā)現(xiàn)問題非常有用。
離線數(shù)倉（DataWorks + MaxCompute）：通過DataWorks集成緩存了圖片特征向量的日志服務作為數(shù)據(jù)源，然后創(chuàng)建數(shù)據(jù)開發(fā)任務對原始特征向量進行清洗（比如去重等）保存在MaxCompute，再通過DataWorks將MaxCompute清洗后的向量數(shù)據(jù)直接寫入ElasticSearch的Proxima
數(shù)據(jù)挖掘 & 算法推薦：部署在ACK里的一些Python任務，主要做推薦相關的內(nèi)容，比如用戶特征Embedding計算、基于用戶行為的款式圖片的推薦、相似性博主的推薦等
圖片識別服務：目前圖片識別服務主要還是部署在IDC機房，5~6臺GPU服務器對圖片進行批量識別
大數(shù)據(jù)方案演進
知衣的大數(shù)據(jù)方案也是經(jīng)過不同的階段不斷的演進，滿足我們在成本、效率和技術方面的追求，本質(zhì)上還是服務于業(yè)務需求。
階段一：IDC自建CDH集群
我們的業(yè)務系統(tǒng)一開始就部署在阿里云，同時在IDC機房部署了10臺服務器搭建CDH集群，構(gòu)建Hive數(shù)倉。計算過程是先將云上生產(chǎn)環(huán)境數(shù)據(jù)同步到CDH，在CDH集群進行計算后將計算結(jié)果再回傳到阿里云上提供數(shù)據(jù)服務。
自建CDH集群雖然節(jié)省了計算費用，但是也帶來不少問題。最主要的就是運維比較復雜，需要專業(yè)的人員進行集群的運維管理。出現(xiàn)問題也是在網(wǎng)上到處搜索排查原因，效率比較低。
階段二：DataWorks + MaxCompute替換CDH集群
為了降低運維復雜度，我們將計算任務遷移到MaxCompute，直接基于DataWorks做任務編排調(diào)度。
階段三：ElasticSearch構(gòu)建即席查詢
知款聚焦于快速發(fā)現(xiàn)時尚趨勢靈感，集成了社交平臺、品牌秀場、零售及批發(fā)市場、淘系電商、時尚街拍五大圖源，海量的設計靈感參考，幫助服裝品牌及設計師快速準確地預判時尚風向，掌握市場動態(tài)。其中趨勢分析板塊就需要對某個季度下各種組合條件下的設計要素標簽進行統(tǒng)計分析，并輸出上升、下降以及餅圖等指標。這也是我們數(shù)據(jù)量最大的查詢場景，掃描分析的數(shù)據(jù)量量級會接近百萬。
阿里云托管版ElasticSearch相比較開源版本最大優(yōu)點就是開箱即用免運維，特別的就是支持達摩院的Proxima向量檢索引擎，非常適合我們業(yè)務的多維查詢和統(tǒng)計分析場景。后面會在圖片識別展開講述Proxima向量引擎。
圖片識別
我們的核心功能場景是以圖搜圖，前提是需要對海量的圖片庫數(shù)據(jù)進行識別。我們以離線的方式對圖片庫的所有圖片進行機器學習分析，將每一幅圖抽象成高維（256維）特征向量，然后將所有特征借助Proxima構(gòu)建成高效的向量索引。
模型訓練
圖片識別之前需要訓練模型。由專業(yè)的服務行業(yè)背景的人員對圖片庫進行標注，然后線下部署的GPU集群從阿里云對象存儲OSS批量拉取已標注的圖片進行訓練。為了降低標注的成本，我們采用了主動學習（Active Learning）方法，即基于一部分已標注的圖片由機器學習訓練出一個模型，然后對未標注的圖片進行預測，讓人工對預測結(jié)果再次進行確認和審核，再將標注的數(shù)據(jù)使用監(jiān)督學習模型繼續(xù)進行模型訓練，逐步提升模型效果。
批量圖片識別
模型生成以后打包到Docker鏡像，然后在GPU節(jié)點上運行容器服務就可以對海量的服裝圖片進行識別，提取出高維的特征向量。因為提取的特征向量數(shù)據(jù)量很大且需要進行清洗，我們選擇將特征向量先緩存在阿里云日志服務SLS，然后通過DataWorks編排的數(shù)據(jù)開發(fā)任務同步SLS的特征向量并進行包含去重在內(nèi)的清洗操作，最后寫入向量檢索引擎Proxima。
因為一次批量識別圖片的工作量很大，線下的GPU服務器計算性能有瓶頸，所以我們就借助云上彈性的GPU資源做計算資源的補充。線下GPU和云上GPU組成一個計算資源池，共同消費同一批需要進行圖片識別的計算任務，效率大大提升。云上我們購買的是GPU搶占式實例，一般是按量價格的2~3折，可以進一步降低成本。
單次圖片識別
我們以在線serving的模式在web前端提供單次單張圖片識別功能，比如用戶上傳一張圖片，通過模型的推理輸出如下結(jié)果。
以圖搜圖
構(gòu)建好服裝圖片的特征向量庫，我們就可以實現(xiàn)以圖搜圖的功能。當用戶上傳一張新圖片的時候，我們用之前的機器學習方法對其進行分析并產(chǎn)出一個表征向量，然后用這個向量在之前構(gòu)建的向量索引中查找出最相似的結(jié)果，這樣就完成了一次以圖片內(nèi)容為基礎的圖像檢索。選擇合適的向量檢索引擎非常重要。
Faiss
Faiss (Facebook AI Similarity Search) 是Facebook AI 團隊開源的向量檢索庫引擎。初期我們也是選擇Faiss部署分布式服務，在多臺GPU服務器上部署特征向量搜索匹配服務，將搜索請求分發(fā)到每臺GPU子服務進行處理，然后將TOP N的相似結(jié)果數(shù)據(jù)匯總返回給調(diào)用方。
在使用Faiss的過程中，我們也遇到了實際的困難。當然這并不是Faiss本身的問題，而是需要投入更多人力開發(fā)運維分布式系統(tǒng)才能匹配業(yè)務需求。
穩(wěn)定性較差：分布式GPU集群有5~6臺，當某一臺機器掛了會拉長整個接口響應時間，業(yè)務的表現(xiàn)就是搜圖服務等很久才有結(jié)果返回。
GPU資源不足：我們采用的是最基礎的暴力匹配算法，2億個256維特征向量需要全部加載到顯存，對線下GPU資源壓力很大。
運維成本高：特征庫分片完全手動運維，管理比較繁瑣。數(shù)據(jù)分片分布式部署在多個GPU節(jié)點，增量分片數(shù)據(jù)超過GPU顯存，需要手動切片到新的GPU節(jié)點。
帶寬爭搶：圖片識別服務和以圖搜圖服務都部署在線下機房，共享300Mb機房到阿里云的專線帶寬，批量圖片識別服務占用大帶寬場景下會直接導致人機交互的圖搜響應時間延長。
特定場景下召回結(jié)果集不足：因為特征庫比較大，我們?nèi)斯⑻卣鲙觳鸪?0個分片部署在多臺GPU服務器上，但由于Faiss限制每個分片只能返回1024召回結(jié)果集，不滿足某些場景的業(yè)務需求。
Proxima
Proxima是阿里達摩院自研的向量檢索引擎（https://developer.aliyun.com/article/782391），實現(xiàn)了對大數(shù)據(jù)的高性能相似性搜索，也集成在我們之前在用的阿里云托管版的ElasticSearch。功能和性能上與Faiss相比各有千秋，主要是針對Faiss使用上的困難，ElasticSearch + Proxima幫助我們解決了。
穩(wěn)定性高：開箱即用的產(chǎn)品服務SLA由阿里云保障，多節(jié)點部署的高可用架構(gòu)。到目前為止，極少碰到接口超時問題
算法優(yōu)化：基于圖的HNSW算法不需要GPU，且與Proxima集成做了工程優(yōu)化，性能有很大的提升（1000萬條數(shù)據(jù)召回只需要5毫秒）。目前業(yè)務發(fā)展特征向量已經(jīng)增長到3億。
運維成本低：分片基于ES引擎，數(shù)據(jù)量大的情況下直接擴容ElasticSearch計算節(jié)點就可以
無帶寬爭搶：以圖搜圖的服務直接部署在云上，不占用專線帶寬，圖搜場景下沒有再出現(xiàn)超時查詢告警
召回結(jié)果集滿足業(yè)務需求：Proxima也是基于segment分片取Top N相似，聚合后再根據(jù)標簽進行過濾。因為segment較多，能搜索到的數(shù)據(jù)量就比原先多很多。
技術架構(gòu)升級展望
OLAP分析場景優(yōu)化迭代
隨著數(shù)據(jù)量的不斷增長以及業(yè)務需求的不斷變化，OLAP分析場景越來越復雜，對算法和技術方案選型要求越來越高。舉個業(yè)務場景的例子：
10萬博主發(fā)布的圖片數(shù)量有1億多，用戶可以對博主進行關注訂閱，關注上限是2000個博主。用戶關注的2000個博主對應的圖片量級會在200萬左右。需要對用戶關注的圖片進行實時多條件統(tǒng)計分析（每個用戶關注博主不同）
以上例子在使用Elasticsearch實現(xiàn)查詢的時候需要9秒，顯然不滿足業(yè)務需要。那有沒有更好的方案呢？近期在調(diào)研完Clickhouse之后，對數(shù)據(jù)進行預處理產(chǎn)生大寬表再查詢，查詢時延已經(jīng)降低到2秒以內(nèi)，很好的滿足了業(yè)務需求。阿里云Clickhouse開箱即用，降低業(yè)務試錯成本，幫助我們快速響應業(yè)務需求。
規(guī)范數(shù)據(jù)建模和數(shù)據(jù)治理
目前DataWorks主要是用來做數(shù)據(jù)集成和任務調(diào)度，也有些少量的基于規(guī)則判斷數(shù)據(jù)質(zhì)量，團隊內(nèi)部的約定更多的是文檔化的開發(fā)規(guī)范，缺乏一些有效工具的輔助。隨著業(yè)務場景越來越復雜，集成的數(shù)據(jù)源越來越豐富，數(shù)據(jù)開發(fā)人員也越來越多，制定全部門統(tǒng)一的開發(fā)規(guī)范非常必要。DataWorks的數(shù)據(jù)建模通過工具和流程建立數(shù)據(jù)標準，可以實現(xiàn)結(jié)構(gòu)化有序的統(tǒng)一管理。數(shù)據(jù)治理模塊可以通過配置檢查項檢測不符合數(shù)據(jù)規(guī)范的開發(fā)流程，基于多項治理項的健康分度量項目健康度以及治理成效。目前我們正在結(jié)合自己的業(yè)務試用數(shù)據(jù)建模和數(shù)據(jù)治理，期待能幫助我們更好的管理數(shù)據(jù)，實現(xiàn)數(shù)據(jù)價值的最大化。
圖搜方案進階合作
在服裝行業(yè)領域圖片識別和以圖搜圖是我們的核心競爭力。阿里云機器學習PAI也提供了相似圖匹配的圖像檢索解決方案（https://help.aliyun.com/document_detail/313270.html）只需要配置原始圖像數(shù)據(jù)，無需標注就可以在線構(gòu)建模型，這點對我們來說比較有吸引力，后續(xù)可以考慮進行測試對比，展開在服裝圖片建模領域的合作。
