蘑菇街如何通過構建平臺搞定數據標註難題?

數據標註行業流淌這麼一句話:“有多少智能,就有多少人工”。大量的訓練數據是進行深度學習的前提,數據的質量決定了模型的上限,而訓練數據產生離不開數據標註,數據標註作爲機器學習工程中重要的一環,是構建 AI 金字塔的基礎。以曠世科技 AI 獨角獸爲例,它的標註員工多達 405 人,佔公司員工比例的 17.2 %

在許多學術界和工業界人士努力下,先後在多個領域誕生了開放數據集,從入門的 MNIST,再到大名鼎鼎的 Image Net,涵蓋了通用場景。但在實際的業務通常碰到某些細分領域沒有開放數據集,比如服裝的類型和風格,這就要求自己構建訓練數據集,或自力更生,或臨時僱用外包人員(自己提供工具),甚至全權委託給專業標註公司(無需提供標註工具,成本高)。蘑菇街有大量數據標註的需求,綜合成本、效率等因素考慮,我們建設了統一的標註平臺,支撐衆多的標註業務,部分樣圖請見如下。

常見的標註場景

從領域角度,蘑菇街的機器學習業務可分爲 CTR(點擊通過率)、計算視覺和 NLP 三類,其中 CTR 爲排序推薦相關業務,這類業務通過埋點收集數據。對於大部分計算視覺和 NLP 的訓練任務,需要標註構建數據集。

不僅於蘑菇街,放眼業界,常見的標註場景可以分爲如下兩大類(音頻的場景相對較少,不在討論範圍內):

  • 計算視覺
  • 分類:對圖片和視頻進行分類,例如服裝顏色、類型分類等。
  • 分割:對圖片進行分割,比如從交通圖像分割出道路,從服裝圖像分割出褲子、上衣等。
  • 目標檢測:通常採用矩形框圈出目標物體,並貼上標籤,比如圈出服裝圖像中的鞋子,交通圖像中的汽車。
  • NLP
  • 分類:對文本進行分類,比如情感分類。
  • 實體識別:從文本提取出具有特定意義的實體,比如從商品描述中標註商品名稱,描述商品的形容詞等。
  • 翻譯:不同語言之間的轉換,如英譯中。

開源的標註工具

Github 誕生了許多開源的標註工具,涵蓋了計算視覺、NLP 等諸多領域,特別在計算視覺方面,許多優秀的開源項目如雨後春筍一般,其中不乏有如 OpenCV 社區和 Microsoft 等商業公司的支持。筆者梳理了部分計算視覺、NLP 等領域部分人氣較好的標註項目,如下表所示。

項目

適合場景

說明

桌面/Web

stars

labelImg

目標檢測(圖像)

採用矩形框標註目標,結果保存至本地 xml 文件

桌面軟件

8.8K

cvat

目標檢測、分割、分類任務(圖像和視頻)

功能強大,支持圖像和視頻的多種標準場景,支持導出多種格式結果文件

Django Web 服務

2.6K

labelme

目標檢測、分割、分類任務(圖像)

功能較爲強大

桌面軟件

3.5K

vatic

目標檢測、目標跟蹤(視頻)

面向視頻的目標檢測和目標跟蹤,結果保存至 DB 中

Web 服務

0.4K

doccano

NLP 命名實體識別、文本分類、翻譯任務

功能強大,支持多種語言,支持用戶管理,結果保存至 SQL DB 中

Django Web 服務

1.9K

Chinese-Annotator

NLP 命名實體識別、文本分類、關係提取

面向中文的智能文本標註,結果保存至 Mongo DB 中

Django Web 服務

0.9 K

audio-annotator

音頻分類標註

面向音頻片段的分類標註

Web 服務

0.2K

這些優秀的開源項目專注於細分的領域,適合通用場景下的標註,用戶經安裝和配置即可開展標註工作,有些還甚至支持生成訓練樣本,這對於規模較小,算法業務較爲單一的團隊很適合。但是對於算法業務複雜,數據量大,場景特殊的公司而言,直接基於上述工具可能會帶來巨大的維護和管理成本。

  1. 服務管理:在多人(特別是異地外包)標註下,採用桌面工具會帶來大量部署和維護的問題,同時涉及大量數據分發和分配問題,繁雜且容易引入錯誤。所以標註服務最好應該提供統一的 Web 入口,標註人員無論身處何處,採用何種操作系統,僅需登錄 web 界面即可開展工作;對研發人員而言,維護一個統一的前後端服務的工作量遠遠低於維護多個標註工具。
  2. 數據管理:有些工具將數據保存到本地 xml,有些保存到 MySQL 或者 NoSQL,不同項目的數據格式也存在很大差異,帶來較高的管理成本和隱患。因此數據應該採用統一的高可靠存儲,不僅可以精簡維護成本,而且利於銜接樣本構建模塊。
  3. 用戶管理:用戶和權限管理是多人標註下的一個重要需求,也是大部分標註工具缺失的功能。它在保證安全的同時,還記錄了數據的標註者和審覈者,便於追溯和結算。

由此可知對於標註業務繁多的團隊,很有必要構建統一的標註平臺,從而規範流程和風格,對外提供簡單易用的服務,支持多人標註,降低維護成本;同時把數據存儲集中化,數據結構標準化,爲下游的樣本生成模塊奠定良好的基礎。

蘑菇街標註平臺的設計

本節重點談談蘑菇街標註平臺的設計,我們的目標就是構建一個統一、擴展性強、易用的 Web 標註平臺,支持員工、外包等的標註和審覈工作。

設計要點

面向流程 vs 面向業務

我們起初試圖圍繞業務進行抽象,期望爲前後端提供一個統一的框架,深度調研發現不同的標註場景,其前端技術棧和實現,數據結構存在巨大的差異,抽象難度高,可行性低。但是從流程的角度出發,所有標註任務的流程非常相似,可梳理成如下:

我們所有標註業務都遵循上述流程,其中部分流程完全一樣,共用一套代碼邏輯即可,差異部分的流程由每個標註業務自己實現,且互相獨立,例如導入待數據過程中對數據的解析,標註和審覈頁面的實現等等。故每接入一個新標註業務,只需實現數據解析、標註和審覈頁面相關邏輯即可。特別對於前端頁面,由於標註業務之間互相獨立,可各自按需選擇前端框架,同時方便從開源的項目中移植相關代碼,具備良好的可擴展性。

數據管理

標註數據可分爲圖片、視頻、NLP 文本、元數據(包括標註結果)等等,其中圖片和視頻佔據較大的存儲空間,上千萬張圖片佔達着數 TB 的存儲空間,相比本地存儲,採用雲服務的對象存儲是更好的選擇。對於 NLP 文本、標註結果及元數據等,具有佔用空間少、結構化強的特點,適合存儲在數據庫中。

具體實現

框架選型

絕大部分開源的 Web 標註工具均基於 Django 實現,採用 Python Django 利於開源項目的移植;此外算法同學對 Python 的掌握好於其它語言,如此便於算法同學參與部分邏輯開發,比如數據的解析等等。

每當接入一個新的標註項目,採用如下命令即可創建一個 Django 應用,在對應目錄下實現差異化的流程即可。

python manage.py startapp {mark_app}

以蘑菇街的標註平臺爲例,這些差異化的流程體現在如下方面:

  • 解析導入的待標註數據文件:不同標註任務其原始數據差異較大,比如圖像通常圖片在 CDN 上的 URL,NLP 則爲文本文字,故需要實現特定的解析邏輯。
  • 標註結果序列化和反序列化:不同標註任務其標註結果存在較大差異,寫入和讀取 DB 時需要實現序列化和反序列化。
  • 標註和審覈 Web 頁面:不同標註任務的頁面差異較大,可選取合適的前端框架進行實現。

數據管理

我們把圖像和視頻全部存儲於雲服務中的對象存儲,由對象存儲保證高可靠性,每個圖片和視頻都有全局唯一的 URL,故導入待標註數據時只需導入 URL。在標註和審覈過程中,前端根據 URL 從 CDN 下載數據並展示,便捷而高效。

元數據存儲於 MySQL 中,主要有兩張表,一張爲用戶相關的表,用於用戶和權限的管理。另外一張爲標註相關的表,記錄了某條數據的基本信息,包括原始數據(data)、標註結果(label)、標註者、審覈者、狀態和所屬項目等信息,幾個重點的 column 如下:

  `id`         INT(11)
  `data`       MEDIUMTEXT   # 圖像視頻的 URL,NLP 文本,或者圖片和文本的混合
  `label`      MEDIUMTEXT   # 標註結果,一般爲 json 格式,便於序列化和反序列化
  `project`    VARCHAR(60)  # 對應的標註項目 
  `importuser` VARCHAR(60)  # 待標註數據導入者
  `markuser`   VARCHAR(60)  # 標註者
  `checkuser`  VARCHAR(60)  # 審覈者
  ...                       # 其它如時間、狀態等信息

不同標註業務的 data 字段和 label 字段內容差異很大,data 一般爲圖像視頻的 URL,NLP 的文本文字,或者圖像和文本的結合體;label 字段的差異就更大,分類項目的數據結構往往很簡單,而分割類項目的數據結構則複雜許多。所以我們把 data 和 label 兩個字段設置爲 text,數據結構的定義和數據的序列化、反序列化在各自的項目中實現,大大的提升了可擴展性。由於所有的標註數據均共用這張表,避免爲每個項目都維護一張數據表,降低了接入和維護成本。

部署架構

標註平臺的架構比較簡單,數據存儲在 MySQL 和對象存儲中,服務部署在 K8S 的 statefulset 中,由 statefulset 保證高可靠。用戶訪問 K8S 的 Service,再由 Service 將負載均衡轉發至 Pod。

順帶提下樣本構建模塊,它從 MySQL 獲取基本數據,並從 CDN 中下載對應的圖片或視頻,最終生成如 TFRecords 等格式的訓練樣本。

高級特性和展望

爲了保證數據質量,算法同學通常會承擔一定的審覈工作。但是由於標註的數據量實在太大,即使採用 10% 的抽查率,每個項目往往需要審覈數萬條數據。對於部分標註項目,我們的平臺支持採用早批次的數據訓練出模型,初步審查後續的標註結果,對於異常值,再由人工進行第二輪審覈,提升審覈效率。

在圖像分割和 NLP 領域,部分開源的標註工具包含了智能算法,輔助人員進行標註,以提升標註效率,本人認爲這是未來標註項目的一個趨勢,特別對於標註成本較高,數據量比較大的項目,可以考慮採用智能輔助標註降低成本,提升效率。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章