Day 18 列出了 Software Team 負責的系統，今天先講其中的內部工具：我們自行開發的標註工具 BerryTool。

一開始的需求很單純：AI 工程師需要訓練資料，因此要有一個讓人在影片上框出車輛的工具。當時我們沒有預料到，這個專案後來會多出一張排班表。

AI 工程師提出的四個需求

最初幾個月，需求全部來自 AI 工程師，依序是下面四項。

「我要能框出物件。」

標註形狀本身不難，矩形、多邊形與像素級分割 (segmentation) 都有支援。較困難的是畫布。我們用 Paper.js (建立在 HTML5 Canvas 上的向量繪圖函式庫) 繪製圖形，但前端專案是 React，兩者各自維護畫面上元素的狀態，容易互相衝突。我們的做法是自行開發一層轉接層，把 Paper.js 的圖形包裝成 React 元件，讓工程師用撰寫一般 React 元件的方式描述畫布上的圖形。這層轉接在專案初期完成，至今仍在使用。

「影片裡的物件會移動。」

這項需求推翻了原本的資料模型。

如果標註的單位是「框」，一台車駛過畫面就會變成幾百個互不相關的框。但我們要回答的問題是「這台車從進場到離場花了多久」，問題的對象是一台車，所以這幾百個框必須串成同一個物件。此外，車輛會被柱子遮擋，也會駛出畫面再駛回來。

因此標註的單位改成軌跡 (track)：一段有起點與終點、而且允許中斷再接續的時間序列。中斷的空檔本身也帶有資訊：這台車仍在現場，只是暫時被遮擋或離開了畫面。

「逐格標註太耗時。」

一支幾分鐘的影片就有數千個影格 (frame)。因此工具加入了關鍵影格 (keyframe)：標註人員只標少數幾個影格，中間的影格由工具內插計算，也可以接上模型自動補標。以模型產生訓練模型所需的資料，省下了大量的標註時間。

「光有框還不夠。」

框只說明「這裡有一台車」，AI 工程師還需要知道這台車當下的狀態，所以工具加入了屬性 (attribute) 標註。屬性也會隨時間改變：同一台車，前半段在排隊，後半段在點餐。

到這個階段，工具已經能支援 AI 工程師的日常標註需求，當時我們認為主要功能已經完成。

BerryTool 的標註畫面。畫面中的場景圖為示意圖非真實店面。

從標註工具到流程管理

後來專案出現了明確的分水嶺。在那之前，開發內容都是「怎麼標」；在那之後，開發重心轉向「怎麼管理一群人標」。

工具成熟之後，瓶頸轉移到工具之外。新的問題包括：由誰標註？標註速度多快？品質是否正確？標完的資料接下來交給誰？這批資料何時能完成？

我們開始建立管理後台，先把這些問題相關的數字呈現出來。管理後台最核心的功能是流程圖編輯器。不同專案的標註流程差異很大，所以編輯器不內建任何流程：畫布一開始是空白的，由專案經理 (PM) 自行放置節點、命名並連線，例如「標註 → 審核 → 驗收」。要設幾道關卡、審核不通過時是否退回重標，都由 PM 決定。

流程之外，管理後台還提供排班、效率統計與線上人數。BerryTool 最初的定位是標註工具，最後成為一套涵蓋標註、產能統計，以及人力與流程管理的系統。

標註人員與管理者在意的事

這套系統服務兩種人，而兩者在意的事情幾乎沒有交集。

標註人員在意操作效率：熱鍵是否順手、畫布是否卡頓、標到一半瀏覽器當機時進度會不會遺失。這些細節決定了一個人一天能標完多少支影片。

管理者在意的是另一組問題：今天有多少人在線上、這批資料進行到哪一道關卡、何時能交付。他們關注的是整條標註產線的進度。

兩邊的需求有時會互相衝突。專案後期曾有人調換兩個熱鍵的位置，幾天後又全部改回原設定。對管理者而言，調換兩個按鍵是零成本的調整；對每天要按上千次的標註人員而言，這項調整直接影響當天的產出。

而實際操作這套工具的，是那群每天盯著螢幕拉框的標註人員。

小結

BerryTool 從單純的拉框工具開始，依照 AI 工程師的需求，先後加入 Paper.js 與 React 的轉接層、可中斷的軌跡、關鍵影格與模型補標，以及隨時間變化的屬性。工具成熟之後，開發重心轉向管理後台：流程圖編輯器讓 PM 自行定義每個專案的標註流程，排班、效率統計與線上人數則讓管理者掌握人力與產能。

這套系統同時服務標註人員與管理者，兩者在意的事情幾乎沒有交集，需求也會互相衝突：管理端眼中零成本的調整，可能直接影響標註人員當天的產出。

明天的 Day 20 從內部工具轉到客戶端，介紹 BI 動態看板如何從後端以 Python 計算指標、前端自行繪製圖表，換成導入 Superset。

參考資料

• Paper.js
• React

本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格。