本文為雷鋒字幕組編譯的技術(shù)博客，原標(biāo)題 DeepLeague: leveraging computer vision and deep learning on the League of Legends mini map + giving away a dataset of over 100,000 labeled images to further esports analytics research，作者Farza。

翻譯 | 于澤平 安妍     整理 |  凡江

嗨！請確定你已經(jīng)閱讀過 我用深度學(xué)習(xí)分析LoL小地圖，自制數(shù)據(jù)集DeepLeague開源（上），否則你可能會對這一部分感到困惑。

創(chuàng)建數(shù)據(jù)集

第一部分：神秘的網(wǎng)絡(luò)套接字

可能許多人都想知道如何創(chuàng)建這個(gè)數(shù)據(jù)集，因?yàn)檫@個(gè)數(shù)據(jù)集實(shí)在是太大了?，F(xiàn)在我來揭曉答案。我沒有手動(dòng)標(biāo)記100000張小地圖，那樣做太瘋狂了。每張圖片都有10個(gè)邊界框（假設(shè)所有10個(gè)英雄都存活），表示這些英雄在哪里以及它們是什么英雄。即使我手動(dòng)標(biāo)記每張圖片需要5秒鐘，也需要超過8000分鐘才能完成！

下面讓我來講講我是怎樣創(chuàng)建數(shù)據(jù)集的，這包含一些聰明的技巧以及Github上面另一位名為remixz的開發(fā)者的幫助。這位開發(fā)者創(chuàng)建了接下來我將介紹的神秘的網(wǎng)絡(luò)套接字?jǐn)?shù)據(jù)集（我喜歡這樣叫它）。

當(dāng)你在lolesports.com上面觀看英雄聯(lián)盟比賽直播時(shí)，實(shí)際上有一個(gè)神秘的網(wǎng)絡(luò)套接字，它不斷地拋出關(guān)于這場比賽直播的數(shù)據(jù)。我稱之為神秘的網(wǎng)絡(luò)套接字因?yàn)橛泻苌偃酥肋@件事，而且它似乎是半隱藏的。套接字產(chǎn)生的數(shù)據(jù)包含這場比賽中的選手名字、他選擇的英雄以及每一時(shí)刻的英雄位置和血量。它以這種形式存在是因?yàn)檫@樣可以讓直播軟件在網(wǎng)頁上實(shí)現(xiàn)統(tǒng)計(jì)功能。

你現(xiàn)在可能想知道我如何使用這個(gè)數(shù)據(jù)的了！

我創(chuàng)建了我自己的節(jié)點(diǎn)腳本（與remixz所創(chuàng)建的類似），每當(dāng)神秘的網(wǎng)絡(luò)套接字開啟，腳本監(jiān)聽傳入的數(shù)據(jù)，并將數(shù)據(jù)保存到一個(gè)JSON文件中。我在AWS EC2機(jī)器上托管了這個(gè)腳本，現(xiàn)在我正在自動(dòng)保存LCS（英雄聯(lián)盟冠軍聯(lián)賽）中北美賽區(qū)和歐洲賽區(qū)的比賽數(shù)據(jù)！

如果你仍對數(shù)據(jù)感到好奇，這里是從LCS一場比賽中獲取的小片段，可以讓你更好地理解它是什么樣子的。

這個(gè)JSON數(shù)據(jù)本身其實(shí)沒什么用。但是請記住，我們這樣做的目的是為了創(chuàng)建一個(gè)有標(biāo)簽的數(shù)據(jù)集。這個(gè)數(shù)據(jù)集是帶標(biāo)簽的小地圖圖片，標(biāo)簽表示各個(gè)英雄在小地圖上的位置。我并不關(guān)心JSON數(shù)據(jù)本身。

我應(yīng)該補(bǔ)充說明的是，深度聯(lián)盟只從比賽中識別了55個(gè)英雄，因?yàn)槲抑皇怯肔CS的數(shù)據(jù)。LCS中的選手通常只使用一部分英雄。例如，中單通常會玩狐貍，但是幾乎沒有人玩提莫！這意味著我沒有辦法訓(xùn)練一個(gè)可以識別提莫的模型。同樣，也意味著我有太多狐貍的數(shù)據(jù)。我需要在我的數(shù)據(jù)集中獲得英雄的平衡。你可以查看代碼，看看我如何使用check_champs函數(shù)平衡我的數(shù)據(jù)集的。

現(xiàn)在，我擁有的一切是這些JSON文件，它們對應(yīng)某場比賽每一時(shí)刻的每一個(gè)英雄的位置。因此，我所需要做的就是下載JSON文件對應(yīng)的比賽視頻，并將JSON數(shù)據(jù)與視頻匹配。起初我認(rèn)為這很簡單。我以為只需要去YouTube上面找到并下載比賽視頻，寫一個(gè)腳本自動(dòng)從視頻中提取幀，再將它與JSON數(shù)據(jù)匹配就可以了。

第二部分：理解問題

我犯了一個(gè)很大的錯(cuò)誤。讓我來解釋一下。

我無法像處理我在家里錄制的英雄聯(lián)盟視頻一樣處理LCS的視頻。舉個(gè)例子，如果我需要記錄我自己在家從頭到尾玩的一局英雄聯(lián)盟，我只需要運(yùn)行這段代碼：

注意：當(dāng)我說“幀”時(shí)，我的意思是假設(shè)游戲中的每一秒與一個(gè)圖像“幀”相對應(yīng)。一個(gè)60秒的視頻將一共有60幀，每一幀都對應(yīng)一秒。因此，1FPS（每秒傳輸幀數(shù)）！

# first go through every single frame in the VOD.

in_game_timestamp = 0

for frame in vod:

    # go in the vod's json data. find the json data associated with 

    # that specific timestamp.

    frame.json_data = vod_json_data[in_game_timestamp]

    in_game_timestamp += 1

一幀的例子。我保存了完整的視頻，只是從中裁剪出了小地圖。

這段代碼可以在我家里保存的游戲視頻上完美運(yùn)行。假設(shè)我在游戲中0：00的時(shí)間戳開始錄制視頻，在22：34時(shí)間戳停止。那么如果我想要游戲計(jì)時(shí)器中每一秒的一幀數(shù)據(jù)，這是很容易的，因?yàn)椋?/p>

我在家里錄制的視頻的時(shí)間戳與游戲中時(shí)間戳是直接對齊的。

哈哈，朋友們，我真希望LCS視頻也可以這樣簡單地處理。

獲得LCS比賽視頻的唯一方式是通過Twitch上的直播流。這些LCS比賽的Twitch直播流在比賽過程中有許多終端，例如即時(shí)回放，選手采訪以及暫停。視頻的JSON數(shù)據(jù)對應(yīng)游戲中的計(jì)時(shí)器。你明白這為什么會成為一個(gè)問題了嗎？我的視頻計(jì)時(shí)器與游戲計(jì)時(shí)器不是對齊的。

溜了溜了

假設(shè)發(fā)生了這種情況：

• LCS比賽在游戲計(jì)時(shí)器中時(shí)間戳為12：21

• LCS比賽在游戲計(jì)時(shí)器中時(shí)間戳為12：22

• LCS比賽在游戲計(jì)時(shí)器中時(shí)間戳為12：23

• 流轉(zhuǎn)換為即時(shí)回放，并播放最近的一場團(tuán)戰(zhàn)，共17秒。

• LCS比賽在游戲計(jì)時(shí)器中時(shí)間戳為12：24

天哪！這真是太可怕了。我完全失去了游戲計(jì)時(shí)器的軌跡，因?yàn)檫@次中斷，游戲時(shí)間戳和視頻時(shí)間戳變得不對齊了！我的程序應(yīng)該怎樣了解如何從視頻中提取數(shù)據(jù)，并將每一幀與我從網(wǎng)絡(luò)套接字中獲得的JSON數(shù)據(jù)相關(guān)聯(lián)呢？

第三部分：一鍵薅到谷歌云服務(wù)的羊毛

現(xiàn)在問題已經(jīng)很清晰了。我用來從視頻中提取數(shù)據(jù)的腳本必須知道游戲中的時(shí)間戳的實(shí)際情況。只有這樣我才能真正確定正在展示的是比賽而不是一些類似即時(shí)回放或是其他中斷的內(nèi)容。同樣，知道游戲中的時(shí)間戳是非常重要的，因?yàn)樯衩氐木W(wǎng)絡(luò)套接字?jǐn)?shù)據(jù)集給我們的是實(shí)際游戲中的每一秒對應(yīng)的幀的數(shù)據(jù)。即使有類似即時(shí)重放的事情出現(xiàn)，神秘的網(wǎng)絡(luò)套接字仍然在向我們發(fā)送數(shù)據(jù)。因此，為了匹配JSON數(shù)據(jù)中的幀，我們需要知道游戲中的時(shí)間戳。

我做的第一個(gè)嘗試是使用基本的OCR（光學(xué)字符識別）識別時(shí)間戳。我嘗試了很流行的庫，但都獲得了很糟糕的結(jié)果。我猜測的是，奇怪的字體以及總在變化的背景使其變得十分困難。

裁剪出的游戲計(jì)時(shí)器的樣例

最后，我發(fā)現(xiàn)了谷歌的Cloud Vision API，其中也有OCR功能。這個(gè)API效果很好，幾乎不犯錯(cuò)誤。但有一個(gè)問題。

每使用API處理1000張圖片需要花費(fèi)1.5美元。我首先想到的是將所有時(shí)間戳放到同一張圖片中，并將它們作為一張圖片進(jìn)行處理。但由于某種原因，我得到了很糟糕的結(jié)果。API一直在給我錯(cuò)誤的答案。這意味著我有一個(gè)選擇，我將需要每次發(fā)送給API一個(gè)小時(shí)間戳。我有超過100000幀，這代表我需要付150美元。這其實(shí)也不算太差，只是我沒有那么多錢，我還在上大學(xué)，我還只是個(gè)孩子…

但是！我很幸運(yùn)地找到了這個(gè)：

創(chuàng)建一個(gè)賬戶就可以獲得免費(fèi)使用的300美元。無疑，我現(xiàn)在還沒有創(chuàng)建3個(gè)賬戶，因此我可以用免費(fèi)的900美元處理我的視頻，并在GCP上做隨機(jī)測試和腳本。這將違反服務(wù)條款，也不尊重公司。 

無論如何，憑借這筆免費(fèi)資金，我編寫了一個(gè)腳本，可以逐個(gè)使用Google Vision API處理視頻。這個(gè)腳本輸出了一個(gè)名為time_stamp_data_clean.json的JSON文件，它從游戲中提取了各個(gè)幀，并根據(jù)每一幀對應(yīng)的時(shí)間從游戲計(jì)時(shí)器中讀取并標(biāo)記。

time_stamp_data_clean.json的數(shù)據(jù)，告訴我們游戲計(jì)時(shí)器根據(jù)特定幀讀取的內(nèi)容。

太厲害了！ 這種方法是有效的！

在這一點(diǎn)上，一切都接近完美，數(shù)據(jù)集幾乎準(zhǔn)備就緒。 現(xiàn)在是最后一步了。 我們只需要將來自此JSON的數(shù)據(jù)與來自神秘網(wǎng)絡(luò)套接字的JSON匹配。 為此，我創(chuàng)建了這個(gè)腳本。

對于一個(gè)巨大的數(shù)據(jù)集，如果沒有合適地處理它，使用起來是很麻煩的。我需要一種好方法去說“這個(gè)幀有這些邊界框+標(biāo)簽”。我可以只留下一些.jpg文件和一個(gè)包含所有標(biāo)簽和坐標(biāo)信息的.csv文件。它看起來就像這樣：

frame_1.jpg, Ahri [120, 145], Shen [11, 678], ...
frame_2.jpg, Ahri [122, 147], Shen [15, 650], ...
frame_3.jpg, Ahri [115, 133], Shen [10, 700], ...

但這是不好的。因?yàn)镃SV很煩人，JPG更煩人。另外，這意味著我將不得不對所有圖片文件重命名，以便使它們與CSV對應(yīng)。這樣肯定不行。必須要有一個(gè)更好的辦法。確實(shí)有。

我將所有數(shù)據(jù)保存到一個(gè).npz文件中用來代替JPG和CSV。這個(gè).npz文件使用numpy的矩陣保存。Numpy是機(jī)器學(xué)習(xí)的一種語言，所以這很完美。每個(gè)圖片被保存到numpy數(shù)組中，標(biāo)簽也隨之保存，就像這樣：

[
[[image_as_numpy_array],
[[Ahri, 120, 145, 130, 150],
[Shen, 122, 147, 170, 160],
...
],[[image_as_numpy_array],
[[Ahri, 125, 175, 180, 190],
[Shen, 172, 177, 190, 180],
...
]
...]

現(xiàn)在我們不再需要處理煩人的文件名或者CSV了。所有數(shù)據(jù)都被保存在同一個(gè)文件的許多數(shù)組中，并且可以通過索引輕松訪問。

最后就是困難的深度學(xué)習(xí)部分了，獲取+處理數(shù)據(jù)，已經(jīng)完成了！

選擇一個(gè)神經(jīng)網(wǎng)絡(luò)框架

假如不用模型來訓(xùn)練數(shù)據(jù)，那數(shù)據(jù)有什么用？

從最開始我就想用一個(gè)專門用于檢測物體的現(xiàn)有框架，因?yàn)檫@只不過是個(gè)概念驗(yàn)證罷了。我不想花上幾周時(shí)間來搭一個(gè)適合電游的框架。這事兒我還是留給未來的博士生們?nèi)プ霭?)。

我在上文提到過，之所以選用YOLO框架，是因?yàn)樗\(yùn)行速度很快，而且在一度算得上先進(jìn)。另外，YOLO的作者很了不起，他開放了所有源代碼，向開發(fā)人員們敞開了大門。但他寫YOLO用的是C++語言。我不太愛用C++，因?yàn)樗蟛糠謹(jǐn)?shù)據(jù)的代碼完全可以用Python和Node.js來做。幸好有人決定創(chuàng)建YAD2K，這樣大家就能用Python和Keras來使用YOLO了。說實(shí)在的，我選擇YOLO還有一個(gè)重要原因在于我讀懂了它的論文。我深知只有真的讀懂了這篇論文，才能弄清楚框架背后的核心代碼。其他熱門框架的論文我沒能讀得這么透。YOLO只需看一眼圖像就能得出結(jié)論，這項(xiàng)能力比R-CNN用的上千個(gè)區(qū)域提案還要人性化。最重要的是，YOLO的代碼對照著論文就很好懂。

至于YOLO是如何運(yùn)行的，我在此就不贅述了。有很多其他資源對此做出了解釋，比如這個(gè)（此處有超鏈接），就比我解釋得清楚多了！

對YOLO進(jìn)行再訓(xùn)練

注意：這部分的技術(shù)性較強(qiáng)，如果你有什么不懂的地方，盡管在推特上問我！

YOLO是個(gè)特別有深度的神經(jīng)網(wǎng)絡(luò)。也有可能它其實(shí)沒什么深度，是我太容易被打動(dòng)了。不管怎樣，框架是這樣的：

我用的是一臺2012年的MacBook Pro。我沒法用它來訓(xùn)練YOLO這么個(gè)龐大的模型，那估計(jì)得花上好幾年時(shí)間。于是我買了個(gè)AWS EC2 GPU實(shí)例，因?yàn)槲蚁朐?1世紀(jì)結(jié)束前完成模型訓(xùn)練。

以下是再訓(xùn)練腳本的運(yùn)行方式：

• 我沒有完全從頭開始訓(xùn)練YOLO。 

• YAD2K首先得經(jīng)得住訓(xùn)練前的重量，凍結(jié)主體的所有層次，然后運(yùn)行5次迭代。

• 接著，YAD2K和整個(gè)模型在未凍結(jié)的狀態(tài)下運(yùn)行30次迭代。

• 然后，當(dāng)驗(yàn)證損失開始增加時(shí)，YAD2K會盡早停止并退出，這樣模型就不會被過度訓(xùn)練了。

所以，起初我還天真地從5個(gè)LCS游戲中提取了大約7,500幀的數(shù)據(jù)，用YOLO運(yùn)行了一遍，結(jié)果數(shù)據(jù)在2次迭代內(nèi)過度擬合然后湮滅了。這倒也說得通。這個(gè)模型有很多參數(shù)，而我沒有使用任何形式的數(shù)據(jù)增強(qiáng)，注定行不通。

說到數(shù)據(jù)增強(qiáng)，我其實(shí)沒用在這個(gè)項(xiàng)目上。通常來說，在針對現(xiàn)實(shí)中的物體訓(xùn)練模型時(shí)，數(shù)據(jù)增強(qiáng)對模型的幫助非常大。例如，一個(gè)杯子可以在圖像中顯示出數(shù)千種不同的尺寸。我們無法得到包含每個(gè)尺寸的數(shù)據(jù)集，因此使用數(shù)據(jù)增強(qiáng)。但就這個(gè)迷你地圖的例子而言，除了冠軍圖標(biāo)和其他一些東西（比如病房）的位置，一切都是恒定不變的。由于我只用了1080p的VOD，迷你地圖的大小也是恒定的。如果我想為某位冠軍提供更多數(shù)據(jù)，數(shù)據(jù)增強(qiáng)會非常有用。所以我可以把迷你地圖的框架翻轉(zhuǎn)過來，然后從一個(gè)框架中得到兩個(gè)框架。但與此同時(shí)，冠軍圖標(biāo)也會被翻轉(zhuǎn)，導(dǎo)致模型混淆。關(guān)于這一點(diǎn)我還沒測試過，但說不定能行呢！

經(jīng)歷了第一次失敗后，我想，“好吧，算了，我用整個(gè)數(shù)據(jù)集試試”。但我的訓(xùn)練腳本在大約20分鐘內(nèi)一直在崩潰，因?yàn)槲业南到y(tǒng)“內(nèi)存不足”（和RAM一個(gè)道理）。

再一次 溜了溜了

這也講得通，因?yàn)槲业臄?shù)據(jù)集十分龐大，而訓(xùn)練腳本是把整個(gè)數(shù)據(jù)集都加載到RAM內(nèi)存里，相當(dāng)于在電腦上一下子打開十萬張圖。我本可以租一個(gè)內(nèi)存更大的AWS實(shí)例，這樣就不會有任何問題；但我又摳又窮。于是我給訓(xùn)練腳本添加了新功能，以便批量訓(xùn)練。這樣一來，一次就只加載一部分?jǐn)?shù)據(jù)集，而不是一股腦兒全都加載到內(nèi)存里。得救了！

我用改進(jìn)后的“批量訓(xùn)練”來運(yùn)行YOLO，事情總算出現(xiàn)了轉(zhuǎn)機(jī)。我前前后后試了有10次。在這個(gè)過程中，我把模型運(yùn)行了好幾個(gè)小時(shí)，才意識到代碼有一個(gè)巨大的錯(cuò)誤，于是我終止訓(xùn)練，從頭再來一遍。最后，我修復(fù)了錯(cuò)誤，損失終于開始降低，而模型這次也沒有過度擬合！我花了大約兩天時(shí)間，讓模型運(yùn)行了完整的訓(xùn)練時(shí)長?？上н@下我的錢包癟了不少，好在最終我還是得到了最后的重量。損失呈現(xiàn)很好的收斂，驗(yàn)證損失也收斂得很好，而且正好處于訓(xùn)練損失之上。

我真想向大家展示一下我那美麗的TensorFlow圖形。怪我太蠢，我把訓(xùn)練后的重量保存到筆記本電腦之后，不小心刪除了我實(shí)例里的所有內(nèi)容。KMS :(。我可以再花2天時(shí)間來訓(xùn)練模型、分析訓(xùn)練，只要先給我買GPU的錢就行:)。

差不多就是這樣了！忙了這么久，我終于能取得些可靠的成果來用于我的任務(wù)了。寫到這兒，我本可以就此收尾，大談DeepLeague是個(gè)多么完美的工具，我是多么了不起。但那不是實(shí)話。特此澄清，DeepLeague還遠(yuǎn)稱不上完美，不過我的確很了不起。

盡管DeepLeague大多數(shù)情況下都做得很好，但它仍存在一些主要問題。下面我們來看看其中一個(gè)。

在上面的輸出中，DeepLeague錯(cuò)誤地把Cho'Gath標(biāo)記成了Karma，還給了它1.0的置信度。這很糟。神經(jīng)網(wǎng)絡(luò)似乎百分百確定Cho'Gath就是Karma。我在其他地方提到過，我得對數(shù)據(jù)集加以平衡，否則我就會在掌握某個(gè)冠軍很多數(shù)據(jù)的同時(shí)，只掌握另一個(gè)冠軍很少的數(shù)據(jù)。例如，我有Karma的很多數(shù)據(jù)，是因?yàn)樗呀?jīng)壞了，而大家都在LCS游戲里扮演過她。但是，并沒有多少人扮演Cho'Gath！這代表我所掌握的Cho'Gath的數(shù)據(jù)要比Karma的少得多。其實(shí)，還存在一個(gè)更深層次的問題使得平衡數(shù)據(jù)集如此困難。

比方說，在Karma所在的游戲里，我有50,000個(gè)幀，整個(gè)數(shù)據(jù)集有100,000幀。對于單獨(dú)一位冠軍而言，這么多數(shù)據(jù)已經(jīng)相當(dāng)多了；而如果在很多Karma身上訓(xùn)練我的網(wǎng)絡(luò)，可能會使得神經(jīng)網(wǎng)絡(luò)對其他冠軍的了解變得困難很多。此外，還有可能導(dǎo)致嚴(yán)重的本土化問題。

我知道你們在想什么：“扔掉點(diǎn)兒Karma的數(shù)據(jù)唄！”我不能為了平衡數(shù)據(jù)集而扔掉含有Karma的幀，因?yàn)檫@些幀同時(shí)也包含了其他9位冠軍的數(shù)據(jù)。也就是說，如果我扔掉那些含有Karma的幀，就會同時(shí)減少其他那9位冠軍的數(shù)據(jù)！我試著盡可能去平衡數(shù)據(jù)集，但由于網(wǎng)絡(luò)只在地圖里的少數(shù)幾個(gè)地方見到過兩三次Cho'Gath，而在地圖上到處都能見到好多Karma，因此Cho'Gath很有可能被識別成Karma。正如很多深度學(xué)習(xí)中的問題一樣，針對這個(gè)問題最簡單的解決方案是：更多的數(shù)據(jù)。這是非?？尚械?，我們可以從web socket中持續(xù)抓取數(shù)據(jù)！我們還可以試試能“學(xué)著”平衡數(shù)據(jù)集的焦點(diǎn)損失，不過我還沒試過。

撇開對于某些冠軍的錯(cuò)誤分類不看，DeepLeague仍然好得出奇。我真的很想看看這個(gè)項(xiàng)目是不是也能啟發(fā)些別的點(diǎn)子。比如，我們可以在電游里進(jìn)行動(dòng)作檢測嗎？這樣一來，當(dāng)某些冠軍在某些時(shí)候使用某些法術(shù)時(shí)，我們就可以識別出來！當(dāng)Ahri把她的Q扔出去時(shí)，她會做出某些動(dòng)作，而神經(jīng)網(wǎng)絡(luò)可以分析這些動(dòng)作。試想一下，你可以對Faker是如何計(jì)算自己的能力、管理自己的法力、在地圖上漫游的進(jìn)行分析。這一切都可以通過計(jì)算機(jī)視覺實(shí)現(xiàn):)。

非常感謝你閱讀本文，我最喜歡你了。如果你有任何疑問，請隨時(shí)在Twitter上給我留言。先再見啦！

博客原址 https://medium.com/@farzatv/deepleague-part-2-the-technical-details-374439e7e09a

更多文章，關(guān)注雷鋒網(wǎng)

添加雷鋒字幕組微信號（leiphonefansub）為好友

備注「我要加入」，To be a  AI  Volunteer ！

雷鋒網(wǎng)雷鋒網(wǎng)

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。