使用機器學習對數十億影像中的文字進行索引，會發生什麼？

作者：Leonard Fink

在我們之前的博文中，我們討論瞭如何更新Dropbox搜尋引擎，以將智慧新增到使用者的工作流程中，以及我們如何構建光學字元識別（OCR）管道。使用者將從這些變化中看到的最具影響力的好處之一是，Dropbox Professional和Dropbox Business Advanced 和企業計劃的使用者可以使用我們描述為自動影像文字識別的系統在影像和PDF中搜尋英文文字。

自動識別影像中的文字（包括包含影像的PDF）的潛在好處是巨大的。人們在Dropbox中儲存了超過200億個影像和PDF檔案。在這些檔案中，10%-20％是文件類收據和白板影像的照片，而不是文件本身。這些現在是自動影像文字識別的候選者。同樣，這些PDF中有25％的檔案是掃描文件，這些文件也是自動文字識別的候選物件。

從計算機視覺的角度來看，雖然文件和文件影像可能看起來與人類檢視看非常相似，但計算機看到這些檔案的方式有很大差異：文件可以被編入索引以供搜尋，允許使用者通過輸入找到它檔案中的一些單詞。搜尋索引系統的影像是不透明的，因為它只顯示為畫素集合。影像格式（如JPEG，PNG或GIF）通常不可索引，因為它們沒有文字內容，而基於文字的文件格式（如TXT，DOCX或HTML）通常是可索引的。PDF檔案介於這二者之間，因為它們可以包含文字和影像內容的混合。自動影像文字識別能夠智慧地區分所有這些文件，以對包含在其中的資料進行分類。

現在，當使用者搜尋出現在這些檔案中的英文文字時，它會出現在搜尋結果中。這篇文章描述了我們是如何構建這個特性的。

評估挑戰

首先，我們著手衡量任務的規模，特別是試圖瞭解我們必須處理的資料量。這不僅可以告知成本估算，還可以確認其有用性。更具體地說，我們想回答以下問題： ·我們應該處理哪些型別的檔案？ ·哪些檔案可能具有"OCR-able"內容？ ·對於像PDF這樣的多頁文件型別，我們需要處理多少頁才能使其有用？

我們要處理的檔案型別是那些當前沒有可索引文字內容的檔案。這包括沒有文字資料的影像格式和PDF檔案。但是，並非所有影像或PDF都包含文字。事實上，大多數只是沒有任何文字的照片或插圖。因此，一個關鍵的構建模組是一個機器學習模型，可以確定某個內容是否具有OCR能力，換句話說，它是否具有很有可能被我們的OCR系統識別的文字。這包括，例如，文件的掃描或照片，但不包括具有隨機路牌的影像之類的東西。我們訓練的模型是一個卷積神經網路，它在將輸出轉換成關於它是否可能具有文字內容的二元決策之前獲取輸入影像。

對於影像，最常見的影像型別是JPEG，我們發現大約9％的JPEG可能包含文字。對於PDF檔案，情況稍微複雜一些，因為PDF檔案可以包含多個頁面，並且每個頁面可以存在三個類別之一： ·頁面具有已嵌入和可索引的文字 ·頁面具有文字，但僅以影像的形式，因此當前不可索引 ·頁面沒有實質性的文字內容

我們希望略過第1類和第3類中的頁面，並只關注第2類，因為這是我們可以提供好處的地方。事實證明，3類中的每類分佈分別為69％、28％和3％。總體而言，我們的目標使用者的JPEG數量大約是PDF的兩倍，但每個PDF平均有8.8頁，而PDF包含文字影像的可能性要高得多，所以就係統上的總體負載而言，PDF的貢獻將超過JPEG的10倍！然而，事實證明，通過下面描述的簡單分析，我們可以顯著減少這個數字。

頁面總數

一旦我們決定了檔案型別並開發了每頁上可以使用OCR內容的估計值，我們就希望對處理每個檔案的方式保持戰略性。某些PDF文件有很多頁面，因此處理這些檔案的成本更高。幸運的是，對於長文件，我們可以利用這樣一個事實，即使索引幾頁也可能使文件更容易從搜尋中訪問。因此，我們檢視了PDF樣本中頁面計數的分佈情況，以確定每個檔案最多可以索引多少頁面。事實證明，一半的PDF只有1頁，大約90％有10頁或更少。因此，我們採用了10頁的上限，也就是每個文件中的前10頁。這意味著我們完全索引了近90％的文件，並且索引剩餘文件的足夠頁面以使其可搜尋。

自動影像文字識別系統元件

渲染

一旦我們開始在所有OCR檔案上使用OCR提取文字的過程，我們意識到我們有兩個選項來渲染嵌入在PDF檔案中的影像資料：我們可以提取嵌入在檔案中的所有光柵（即畫素）影像物件單獨流，或者我們可以將PDF的整個頁面渲染為柵格影像資料。在對兩者進行實驗之後，我們選擇了後者，因為我們已經為我們的檔案預覽功能提供了強大的大規模PDF渲染基礎架構。使用此係統的一些好處包括：

• 它可以自然地擴充套件到其他渲染或影像嵌入檔案格式，如PowerPoint、PostScript和我們的預覽基礎架構支援的許多其他格式。

• 實際渲染自然保留文字標記的順序和文字在佈局中的位置，考慮文件結構，從多影像佈局中提取單獨的影像時無法保證。

我們的預覽基礎架構中使用的伺服器端渲染基於PDF，這是Chromium專案中的PDF渲染器，這是一個由Google啟動的開源專案，是Chrome瀏覽器的基礎。相同的軟體也用於正文檢測並確定文件是否是"僅限於影像"，這有助於決定我們是否要應用OCR處理。

一旦開始渲染，每個文件的頁面將被並行處理以降低延遲，根據我們上面的分析，以前10頁為上限。我們渲染每個頁面的解析度填充2048×2048畫素的矩形，保留縱橫比。

文件影像分類

我們的OCR機器學習模型最初是為Dropbox文件掃描器功能而構建的，目的是為了確定使用者最近拍攝的（正常）照片是否可以建議他們"變成掃描"。這個分類器是使用線性分類器構建的在預先訓練的ImageNet模型（GoogLeNet / Inception）的影像特徵之上。它接受了從幾個不同來源收集的數千張影像的訓練，包括公共影像、使用者捐贈的影像和一些Dropbox員工捐贈的影像。原始開發版本是使用Caffe構建的，之後該模型轉換為TensorFlow，以與我們的其他部署保持一致。 在微調這個元件的效能時，我們學到了一個重要的教訓：在開始時，分類器偶爾會產生誤報（它認為包含文字的影像，但實際上沒有），例如空白牆壁、天際線或開闊水域的圖片。儘管它們看起來與人眼完全不同，但是分類器在所有這些影像中都看到了相似的東西：它們都具有平滑的背景和水平線條。通過迭代標記並將這種所謂的"難分樣本(hard negatives)"新增到訓練集中，我們顯著提高了分類的精確度，有效地教授了分類器，即使這些影像具有文字文件的許多特徵，它們也不包含實際文字。

角點檢測

在影像中定位文件的角並定義其（大致）四邊形是字元識別之前的另一個關鍵步驟。給定角的座標，可以通過簡單的幾何變換來校正影像中的文件（製成直角矩形）。文件角點檢測器元件使用另一個ImageNet深度卷積網路（Densenet-121）構建，其頂層由產生四角座標的迴歸器替代。

用於訓練該模型的測試資料僅使用數百個影像。四個或更多定義封閉文件邊界多邊形的2-D點形式的標籤也由Mechanical Turk工作人員使用定製的使用者介面（UI）繪製，並通過機器學習團隊成員的註釋進行擴充。通常，包含在訓練影像中的文件的一個或多個角落位於影像邊界之外，需要人類直覺來填充缺失的資料。

由於深度卷積網路被饋送按比例縮小的影像，因此四邊形的原始預測位置的解析度低於原始影像。為了提高精度，我們採用兩步流程：

（1）獲得初始的四邊形

（2）在每個角落的較高解析度補丁上執行另一個迴歸

從四邊形的座標，可以很容易地將影像校正為對齊的版本。

令牌提取

在我們之前的部落格文章中描述了實際的光學字元識別系統，它提取文字標記（大致對應於單詞）。它將來自角點檢測步驟的校正後的影像作為輸入，並生成令牌檢測，其中包括令牌的邊界框和每個令牌的文字。這些被排列成大致順序的令牌列表並新增到搜尋索引中。如果有多個頁面，則每個頁面上的標記列表將串聯在一起以生成一個大列表。

把碎片拼在一起

要為所有符合條件的使用者在所有可能可索引的檔案上執行自動影像文字識別，我們需要一個可以攝取傳入檔案事件（例如，新增或編輯）並啟動相關處理的系統。事實證明，這是Cape的一個自然用例，這是一種靈活的、大規模、低延遲的非同步事件流處理框架，支援許多Dropbox功能。作為一般搜尋索引框架的一部分，我們為OCR處理新增了一個新的Cape微服務工作者（稱為"lambda"）。

處理的前幾個步驟利用了Dropbox的一般預覽基礎設施。這是一個可以有效地將二進位制檔案作為輸入並返回此檔案的轉換的系統。例如，它可能需要一個PowerPoint檔案並生成該PowerPoint檔案的縮圖。該系統可通過外掛進行擴充套件，這些外掛對特定型別的檔案進行操作並返回特定的轉換。因此，新增新檔案型別或轉換很容易。最後，系統還有效地快取轉換，因此如果我們嘗試兩次生成相同PowerPoint檔案的縮圖影像，那麼昂貴的縮圖操作只會執行一次。

我們為此功能編寫了幾個預覽外掛，包括（數字對應於上面的系統圖）：

1. 檢查我們是否應該繼續處理，具體取決於它是JPEG、GIF、TIFF還是沒有嵌入文字的PDF，以及使用者是否有資格使用該特性。

2. 執行OCR能力分類器，該分類器確定給定影像是否具有文字。

3. 在每張影像上執行文件角點檢測器，以便我們對其進行糾正。

4. 使用OCR引擎提取令牌。

5. 將令牌列表新增到使用者特定的搜尋索引中。

穩健性

為了在遠端呼叫期間出現瞬態/臨時錯誤的情況下提高系統的穩健性，我們使用抖動指數退避重試遠端呼叫，這是分散式系統中的最佳實踐技術。例如，通過第二次和第三次重試，我們將PDF後設資料提取的失敗率降低了88％。

效能優化

當我們將管道的初始版本部署到一小部分流量進行測試時，我們發現機器學習模型（角點檢測、方向檢測、OCR等）的計算開銷將需要一個龐大的叢集，這會使該特性過於昂貴部署。此外，我們發現看到的流量大約是我們根據歷史增長率估算的流量的2倍。

為了解決這個問題，我們首先提高了OCR機器學習模型的吞吐量，並假設增加吞吐量可以最大限度地減少我們需要的OCR叢集的大小。

為了實現準確可控的基準測試，我們構建了專用的沙箱環境和命令列工具，使我們能夠將輸入資料傳送到多個子服務，以分別測量每個子服務的吞吐量和延遲。我們用於基準測試的秒錶日誌是從實際實時流量中取樣的，沒有殘留資料收集。

從配置引數開始，我們選擇從外部進入效能優化。在處理受CPU限制的機器學習瓶頸時，有時可以通過簡單的配置和庫更改來實現大的效能提升;我們將在下面討論幾個例子。

第一個提升來自為jails中執行的程式碼選擇正確的併發度：為了安全起見，我們執行大多數直接觸及軟體監獄中使用者內容的程式碼，這些程式碼限制了可以執行的操作，隔離來自不同使用者的內容以防止軟體錯誤從破壞資料，並保護我們的基礎設施免受惡意威脅向量。我們通常在一臺機器上為每個核心部署一個jail，以實現最大的併發性，同時允許每個jail只執行單執行緒程式碼（即資料並行）。

然而，事實證明，我們用於預測畫素中的字元的TensorFlow深度學習框架預設配置了多核支援。這意味著每個jail現在都執行多執行緒程式碼，這導致了大量的場景切換開銷。因此，通過關閉TensorFlow中的多核支援，我們能夠將吞吐量提高約3倍。

在這個修復之後，我們發現效能仍然太慢 - 甚至在我們的機器學習模型之前，請求就會出現瓶頸！一旦我們針對使用的CPU核心數量調整了預分配的jail和RPC伺服器例項的數量，我們終於開始獲得預期的吞吐量。通過在TensorFlow中啟用向量化AVX2指令，並通過TensorFlow XLA將模型和執行時預編譯到C ++庫中，我們得到了額外的顯著提升。最後，我們對模型進行了基準測試，發現狹窄中間層上的2D卷積是熱點，並通過在圖表中手動展開它們來加速它們。

文件影像流水線的兩個重要組成部分是角點檢測和方向預測，兩者都使用深度卷積神經網路實現。與我們之前使用過的Inception-Resnet-v2模型相比，我們發現Densenet-121的速度幾乎快兩倍，而且在預測文件角落位置方面的準確性稍差。為了確保我們沒有在準確性上回歸太多，我們進行了A/B測試以評估對可用性的實際影響，比較使用者手動校正自動預測文件角落的頻率。我們得出結論，差異可以忽略不計，並且效能的提升是值得的。

為未來的智慧功能鋪平道路

使文件影像可搜尋是向更加深入理解文件結構和內容的第一步。有了這些資訊，Dropbox可以幫助使用者更好地整理檔案，這是邁向更開明的工作方式的一步。

自動影像文字識別是Dropbox工程師處理的涉及計算機視覺和機器學習的大型專案型別的主要示例。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31545819/viewspace-2216217/，如需轉載，請註明出處，否則將追究法律責任。