點擊上方關注，All in AI中國

作者：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工程師處理的涉及計算機視覺和機器學習的大型項目類型的主要示例。

總結

以上是生活随笔為你收集整理的使用机器学习对数十亿图像中的文本进行索引，会发生什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。