記錄一次在客戶現場進行資料採集的經歷與感想

事情的起因

大家都知道搞 AI 要有海量的高質量資料才能玩的轉，那這些資料要從哪裡來？不同的業務有不同的做法，結構化資料領域可能相對簡單一些，很多時候都可以透過 sql 語句從線上庫中把資料過濾拼接出來，不用很大的採整合本， 甚至資料標註的工作很多時候也可以自動拼接出來。 而 NLP 領域會更噁心一些，它不是噁心在資料採集上， 因為在網際網路資訊爆炸的現在，很多資料都是爬取出來， NLP 領域的資料噁心在標註上。 因為它往往需要理解一份文件的內容才能進行標註。 比如我們要做一個問答模型， 往往需要標註人員讀懂一篇專業的文件，然後從中提取相關的問題和答案（問題和答案就是標註資料了）。 這也是為什麼業內很多團隊都會選擇利用 GPT 進行 “蒸餾” 法，也就是把一個問題發給 GPT 來回答， 然後把 GPT 輸出的答案就當是標註資料了。 這樣就不用人工的來對資料進行標註了。 當然 Open AI 是不准許這麼幹的，這也是為什麼位元組的 Open AI 賬號被封掉的原因， 因為 Open AI 發現該賬號存在這種行為。

而這一次我接到的任務則是在計算機視覺領域中， 這個領域中的標註是非常簡單的，而採整合本卻異常的高（跟 NLP 完全相反）。 跟視覺相關的很多場景都設計到了資料隱私安全，所以在網路上很難找得到符合要求的資料。比如在計算機視覺中非常常見的人臉識別，使用者的人臉資訊是非常敏感的，在以前很多門店（房屋中介，4s 店）都會假設攝像頭採集使用者人臉資訊，這在行業中是預設的潛規則， 但在 2,3 年前已經被國家徹底禁止了。 毫無底線的獲取使用者資訊的時代已經過去了，這時候想要再收集到人臉或者其他資訊，就需要使用者的授權才可以。 而我們這一次為了提高電動車識別效果（自打某城市電動車著火把整棟樓燒掉後， 電動車識別就成了一個強需求），在與客戶溝通後便派人前往客戶處構造並採集資料。

為什麼是我去

本來資料採集的工作不是測試人員的負責範圍的， 公司有專門的資料組， 也有專業的交付人員到客戶處進行溝通。 但有些時候怎麼說呢， 理想很豐滿現實很骨感，網上不是流傳一句話麼，叫整個世界就是一個草臺班子。 所以即便是在頂級的公司內部，大多數地方也都挺亂的，流程並不完善。 所以在這個專案中在一開始就缺失了資料採集的這麼個角色， 所以我們總監就臨時讓測試來頂了資料採集的活。 這也是我們這邊的理念或者是現在整個行業中比較流行的理念吧 -- 角色是不設邊界的（測試人員不是隻關注測試這一塊，在發現其他崗位有缺口時也要補上去），大家互相補位把產品做好，在我們公司也有一句話叫能上能下。 但其實也是面向領導程式設計的工作態度， 很多時候當領導希望你做某件事的時候，抱著崗位邊界這個原則來說事往往是非常無力的。

如何採集資料

專案在一開始的時候只需要採集自然資料即可， 就是不會刻意的去構造資料， 就在真實的攝像頭中拉流，抽幀。把資料提交到資料組的平臺中，再由演算法人員核查，核查後提交給標註組標註，之後模型訓練即可。 但自然資料必然會帶來正樣本稀少的缺點，因為現在很多園區的管理也挺好的（尤其高檔園區），有很多的保安在站崗，能把電動車推進樓道/電梯/大廳的情況本身就很少。 所以採集了很多天其實也沒采集到多少正樣本。

PS： 這裡貼一下資料採集的工具：

sudo bin/ffmpeg -i rtsp://xxx:xxx@xxxx:554/cam/realmonitor?channel=1\&subtype=0 -r 1/5 -f image2 -q:v 1 -an ./xxx/xxx_7zuoketi_$(date +%Y%m%d-%H%M%S)-%03d.jpg

ffmpeg 和 opencv 都是計算機視覺領域中測試人員常用的工具（其實交付，工程，演算法也都用）， 尤其 ffmpeg 的使用頻率非常高， 它可以把各種形式的視覺資料經過處理轉換成另外一種形式。比如在這個場景中我們使用 ffmpeg 從某個攝像頭中拉取 rtsp 協議的實時影片流，並設定每 5s 抽一幀並儲存到對應的目錄中。

所以其實可以看出來，資料採集的技術難度不高， 只要對計算機視覺方向有基本的瞭解，學會 ffmpeg 這個工具即可。 但資料採集噁心的地方在於如果不認為構造資料， 僅憑自然資料那就收集不到足夠的正樣本（在本例中就是壓根採集不到多少張有人推著電動車進入樓道的圖片）， 所以這裡就需要開展認為構造資料了， 那怎麼構造呢， 其實很原始。 招聘演員和租用各種不同的電動車，到客戶的各個攝像頭下按照固定的路線和姿勢推著電動車走來走去就行了。 這裡需要注意的是：

• 電動車的種類/顏色/大小都要不同， 儘量要豐富。 還需要有覆蓋雨衣/擋風服等場景。
• 演員推動電車的方式有左扶，右扶，騎行，停歇等姿勢。 因為人對於電動車的遮擋程度也影響演算法的識別結果
• 演員的服裝要更換，不能一直固定。因為人和服裝等因素會影響演算法的識別結果。
• 要覆蓋大廳/電梯/過道等不同的攝像點位和攝像角度

所以根據以上背景， 上週日晚上領導們緊急開會後，當天夜裡就定了第二天早上的機票飛往廣州客戶處。

中間遇到的困難

• 需要招聘演員/臨時工（包括電動車）， 好在我們的客戶比較給力， 跟我一起去的標註組的妹子也給力，我因為飛機延遲到的比較晚， 她到了後跟客戶協商後給了我們 5 個保安協助我們工作， 每人每天 100 塊錢酬勞。
• 盒子與大量的攝像頭之間網路不穩定，導致拉流和抽幀會失敗，或者圖片質量受到影響。 這就使得我必須頻繁的檢查抽幀質量， 觀察攝像頭實時畫面。
• 客戶攝像頭管理混亂，未按規劃實施。 比如在 4 期 2 號地 1 座大廳這個點位， 在系統中錄入的是 4 期 12 棟。 這導致我們是不能按名字和位置來匹配點位資訊的，所以我們採集之前必須踩點，資料組的妹子到點位攝像頭下，而我在系統裡去挨個點位檢視， 看哪個點位能看見她， 就對應到哪個點位了。 這導致採集比較麻煩。
• 辦公環境惡劣。 這一週廣州下暴雨， 今天還颳了龍捲風。 所以這一週我們有不少時間其實是在暴雨中作業的。好在很多場景都是在室內構造。但也因為天氣過於惡劣給我們造成了很大的麻煩。 比如我們只能在工作日的早上 9 點到下午 5 點之間進行資料構造和採集， 因為其他時間小區的居民要大量的出入小區，使用基礎設施比如電梯。 而由於暴雨我們倆是打不到車的，所以需要在暴雨下徒步走到客戶小區（好在只有 2,3 公里好像）。 然後現場是沒有座位沒有廁所沒有空調，在地下的點位採集的時候那個悶熱的要命，我只能蹲在某個犄角旮旯裡開著電腦採集，要不是地下有個消防栓讓我放電腦，我估計我都得扎馬步了。 為什麼不座地上？ 因為下暴雨麼。。。。地上都是水。。。地下可能還漏水。。。 再然後廣州的蚊子。。。嗯。。。太牛逼了。。。第一天我身上就 20 個包起步（小區的綠化太特麼好了，肉眼可見的一堆蚊子在我身邊飛）。
• 還有一個事想一想還是說一說麼， 就是我被嘲笑了。。。。因為。。。。雖然我是來採集電動車資料的， 但是我不會騎電動車。。。每天都是讓標註組的妹子馱著我奔波在各個小區之間採集資料。。。所以我被一眾保安大哥們給嘲笑了。 就挺荒誕的：專門來採集電動車資料的人竟然不會騎電動車~~~ 天天讓妹子馱著我也是挺丟臉的~~

說說感受吧

最大的感受是一線實施的人真的苦逼， 這錢真的是一個辛苦錢。 上面說的困難裡最讓我難受的就是辦公環境， 我們倆個一天真的是不敢喝水，就怕喝水上廁所，小區裡沒有公共廁所的， 想去廁所得不行 10 分鐘到保安辦公區那裡。 但我倆都得盯著演員或者盯著監控或者盯著採集。 哪敢一走就是 10 幾 20 分鐘的。畢竟我們只有早 9 晚 5 這段時間能採集，那都是爭分奪秒的（採集壓力是很大的，必須在規定時間內採集到足夠的資料，長期這麼採集是不現實的，因為這擾民啊，比如在電梯場景裡採集資料， 那就是佔著電梯，居民就用不了這個電梯了只能用別的， 一旦人流量上來了讓居民排隊了就會被投訴的）。 然後一整天都在喂蚊子， 並且要麼站一天，要麼蹲著一天。 我基本採集的第二天大腿和腰就痠疼痠疼的，因為我一直在用蹲著的姿勢一蹲就幾個小時（中間也就偶爾站起來活動活動，或者轉點位的時候走動走動）。 所以這一次出來採集資料， 最大的感受就是體會到了一線實施的同學真特麼是掙的辛苦錢。演員也挺可憐，跟著我們一走就是一天，結果就百十來塊錢的。

這次出來也算是又補全了在 AI 領域裡的一個經歷了， 以前還真沒搞過現場資料構造與採集的活， 算是體驗了一把， 也深切的感受到了那句話：人工智慧是有多少人工就有多少智慧。 一個個牛逼的模型背後，都是大量的一線人員的汗水。