自动识别图像中的文本(包括包含图像的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. 页面具有已嵌入和可索引的文本
2. 页面具有文本，但仅以图像的形式，因此当前不可索引
3. 页面没有实质性的文本内容

我们想跳过第1类和第3类的页面，只关注第2类，因为这是我们可以提供的好处。事实证明，3个桶中每个桶的页面分布分别为69％，28％和3％。总体而言，我们的目标用户的PDF大约是PDF的两倍，但每张PDF平均有8.8页，而PDF包含文本图像的可能性要高得多，因此就我们系统的整体负载而言，PDF将贡献超过10倍和JPEG一样多！然而，事实证明我们可以通过下面描述的简单分析显着减少这个数字。

总页数

一旦我们决定了文件类型并开发了每页上可以容纳多少OCR内容的估计，我们就想要了解我们接近每个文件的方式。某些PDF文档有很多页面，因此处理这些文件的成本更高。幸运的是，对于长文档，我们可以利用这样一个事实，即使索引几页也可能使文档更容易从搜索中访问。因此，我们查看了PDF样本中页面计数的分布情况，以确定每个文件最多可以索引多少页面。事实证明，一半的PDF只有1页，大约90％有10页或更少。所以我们的上限为10页 - 每篇文档的前10页。这意味着我们完全索引了近90％的文档，并且我们索引剩余文档的足够页面以使其可搜索。

自动图像文本识别系统组件

渲染

一旦我们开始在所有OCR-able文件上使用OCR提取文本的过程，我们意识到我们有两个选项来渲染嵌入在PDF文件中的图像数据：我们可以提取嵌入在文件中的所有光栅(即像素)图像对象单独流，或者我们可以将PDF的整个页面渲染为栅格图像数据。在对两者进行试验之后，我们选择了后者，因为我们已经为我们的文件预览功能提供了强大的大规模PDF渲染基础架构。使用此系统的一些好处包括：

• 它可以自然地扩展到其他渲染或图像嵌入文件格式，如PowerPoint，PostScript和我们的预览基础架构支持的许多其他格式
• 实际渲染自然保留了文本标记的顺序和文本在布局中的位置，考虑了文档结构，从多图像布局中提取单独的图像时无法保证

在我们的预览结构中使用的服务器端渲染是基于PDFium，在该PDF渲染器Chromium项目，由谷歌启动了一个开放源代码项目，这是Chrome浏览器的基础。相同的软件也用于正文检测并确定文档是否是“仅图像”，这有助于决定是否要应用OCR处理。

一旦我们开始渲染，每个文档的页面将被并行处理以降低延迟，根据我们上面的分析，前10页的上限。我们渲染每个页面的分辨率填充2048×2048像素的矩形，保留纵横比。

文档图像分类

我们的OCR-able机器学习模型最初是为Dropbox 文档扫描仪功能而构建的，目的是为了确定用户最近拍摄的(正常)照片是否可以建议他们“变成扫描”。这个分类器是使用线性分类器构建的在预先训练的ImageNet模型(GoogLeNet / Inception)的图像特征之上。它接受了从几个不同来源收集的数千张图像的培训，包括公共图像，用户捐赠的图像和一些Dropbox员工捐赠的图像。最初的开发版本是使用Caffe构建的，之后该模型转换为TensorFlow以与我们的其他部署保持一致。

在微调这个组件的性能时，我们学到了一个重要的教训：在开始时，分类器偶尔会产生误报(它认为包含文本的图像，但实际上没有)，例如空白墙，天际线或开放水域的图片。尽管它们看起来与人眼完全不同，但分类器在所有这些图像中都看到了相似的东西：它们都具有平滑的背景和水平线条。通过迭代标记并向训练集添加所谓的“硬阴性”，我们显着提高了分类的精确度，有效地教授了分类器，即使这些图像具有文本文档的许多特征，它们也不包含实际文本。

角点检测

在图像中定位文档的角并定义其(近似)四边形形状是字符识别之前的另一个关键步骤。给定角的坐标，可以通过简单的几何变换来校正图像中的文档(制成直角矩形)。文档角点检测器组件使用另一个ImageNet深度卷积网络(Densenet-121)构建，其顶层由产生四角坐标的回归器替换。

用于训练该模型的测试数据仅使用数百个图像。标签以四个或更多2-D点的形式定义了一个封闭的文档边界多边形，也由Mechanical Turk工作人员使用定制的UI绘制，并通过机器学习团队成员的注释进行扩充。通常，包含在训练图像中的文档的一个或多个角落位于图像边界之外，需要一些人类直觉来填充缺失的数据。

由于深度卷积网络被馈送按比例缩小的图像，因此四边形的原始预测位置的分辨率低于原始图像。为了提高精度，我们采用两步流程：

1. 获得最初的四边形
2. 在每个角落的较高分辨率补丁上运行另一个回归

从四边形的坐标，可以很容易地将图像校正为对齐的版本。

令牌提取

实际Ø ptical Ç haracter [R ecognition系统提取文本标记(大致相当于字)，在我们描述以前的博客文章。它将来自角点检测步骤的校正后的图像作为输入并生成令牌检测，其中包括令牌的边界框和每个令牌的文本。这些被排列成大致顺序的令牌列表并添加到搜索索引中。如果有多个页面，则每个页面上的标记列表将连接在一起以生成一个大列表。

把碎片放在一起

要为所有符合条件的用户在所有可能可索引的文件上运行自动图像文本识别，我们需要一个可以摄取传入文件事件(例如，添加或编辑)并启动相关处理的系统。这对于Cape来说是一个自然的用例，Cape是一种灵活的，大规模，低延迟的异步事件流处理框架，支持许多Dropbox功能。作为一般搜索索引框架的一部分，我们为OCR处理添加了一个新的Cape微服务工作者(称为“lambda”)。

前几个处理步骤利用了Dropbox的一般预览基础设施。这是一个可以有效地将二进制文件作为输入并返回此文件的转换的系统。例如，它可能需要一个PowerPoint文件并生成该PowerPoint文件的缩略图图像。该系统可通过插件进行扩展，这些插件对特定类型的文件进行操作并返回特定的转换; 因此，添加新文件类型或转换很容易。最后，系统还有效地缓存转换，因此如果我们尝试两次生成相同PowerPoint文件的缩略图图像，那么昂贵的缩略图操作将只运行一次。

我们为此功能编写了几个预览插件，包括(数字对应于上面的系统图)：

1. 根据是否为没有嵌入文本的JPEG，GIF，TIFF或PDF以及用户是否有资格使用该功能，检查是否应继续处理
2. 运行OCR-able分类器，该分类器确定给定图像是否具有文本
3. 在每个图像上运行文档角点检测器，以便我们对其进行纠正
4. 使用OCR引擎提取令牌
5. 将标记列表添加到用户特定的搜索索引

稳健性

为了在远程调用期间出现瞬态/临时错误的情况下提高系统的稳健性，我们使用抖动指数退避重试远程调用，这是分布式系统中的最佳实践技术。例如，通过第二次和第三次重试，我们将PDF元数据提取的失败率降低了88％。

性能优化

当我们将管道的初始版本部署到一小部分流量进行测试时，我们发现我们的机器学习模型(角点检测，方向检测，OCR等)的计算开销将需要一个巨大的集群来实现这一功能部署太昂贵了。此外，我们发现我们看到的流量大约是我们根据历史增长率估算的流量的2倍。

为了解决这个问题，我们首先提高了OCR机器学习模型的吞吐量，并假设增加吞吐量可以最大限度地减少我们需要的OCR集群的大小。

为了实现准确，可控的基准测试，我们构建了专用的沙盒环境和命令行工具，使我们能够将输入数据发送到多个子服务，以单独测量每个子服务的吞吐量和延迟。我们用于基准测试的秒表日志是从实际实时流量中采样的，没有残留数据收集。

我们选择从外部进行性能优化，从配置参数开始。在处理受CPU限制的机器学习瓶颈时，有时可以通过简单的配置和库更改来实现大的性能提升; 我们将在下面讨论几个例子。

第一个提升来自为jails中运行的代码选择正确的并发度：为了安全起见，我们运行大多数代码直接触及软件监狱中的用户内容，限制可以运行的操作，隔离来自不同用户的内容以防止软件错误从破坏数据，并保护我们的基础设施免受恶意威胁向量。我们通常在一台机器上为每个核心部署一个jail，以实现最大的并发性，同时允许每个jail只运行单线程代码(即数据并行)。

然而，事实证明，我们用于预测像素中字符的Tensor F 低深度学习框架默认配置了多核支持。这意味着每个jail现在都运行多线程代码，这导致了大量的上下文切换开销。因此，通过关闭 TensorFlow中的多核支持，我们能够将吞吐量提高约3倍。

在这个修复之后，我们发现性能仍然太慢 - 甚至在我们的机器学习模型之前，请求就变得瓶颈了！一旦我们针对我们使用的CPU核心数量调整了预分配的jail和RPC服务器实例的数量，我们终于开始获得预期的吞吐量。通过在TensorFlow中启用矢量化AVX2指令并通过TensorFlow XLA将模型和运行时预编译到C ++库中，我们得到了额外的显着提升。最后，我们对模型进行了基准测试，发现狭窄中间层上的2D卷积是热点，并通过在图表中手动展开它们来加速它们。

文档图像流水线的两个重要组成部分是角点检测和方向预测，两者都使用深度卷积神经网络实现。与我们之前使用过的Inception-Resnet-v2模型相比，我们发现Densenet-121的速度几乎快了两倍，而且在预测文档角落位置方面的准确性稍差。为了确保我们没有在准确性上回归太多，我们进行了A / B测试以评估对可用性的实际影响，比较用户手动校正自动预测文档角落的频率。我们得出结论，差异可以忽略不计，而且性能的提高是值得的。

整理不易，请大家多多评论转发加关注，谢谢您的支持！