在之前的博客文章中，我们讨论了如何更新 Dropbox 搜索引擎以将智能添加到用户的工作流程中，以及如何构建光学字符识别（OCR）管道。用户将从这些更改中看到的最有影响力的好处之一是，使用 Dropbox Professional 和 Dropbox Business Advanced 和 Enterprise 方案的用户可以使用我们描述为自动图像文本识别的系统在图像和 PDF 中搜索英文文本。
自动识别图像（包括包含图像的PDF）中的文本的潜在好处是巨大的。人们在 Dropbox 中存储了超过 200 亿个图像和 PDF 文件。在这些文件中，10-20%是文档的照片（如收据和白板图像），而不是文档本身。这些现在是自动图像文本识别的候选者。同样，这些 PDF 中有 25% 是文档的扫描件，这些文档也是自动文本识别的候选项。
从计算机视觉的角度来看，尽管文档和文档的图像可能看起来与人非常相似，但计算机查看这些文件的方式有很大的不同：可以将文档编入索引以进行搜索，允许用户通过从文件中输入一些单词来查找它;图像对于搜索索引系统是不透明的， 因为它仅显示为像素的集合。图像格式（如 JPEG、PNG 或 GIF）通常不可索引，因为它们没有文本内容，而基于文本的文档格式（如 TXT、DOCX 或 HTML）通常是可索引的。PDF 文件介于两者之间，因为它们可以包含文本和图像内容的混合。自动图像文本识别能够智能地区分所有这些文档，以对其中包含的数据进行分类。
因此，现在，当用户搜索出现在其中一个文件中的英语文本时，它将显示在搜索结果中。这篇博客文章介绍了我们如何构建此功能。
评估挑战
首先，我们开始衡量任务的大小，特别是试图了解我们必须处理的数据量。这不仅将为成本估算提供信息，而且还将证实其有用性。更具体地说，我们想回答以下问题：
- 我们应该处理什么类型的文件？
- 其中哪些文件可能包含“可 OCR”的内容？
- 对于 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%的PDF只有10页或更少。因此，我们选择了10页的上限 - 每个文档中的前10页。这意味着我们完全索引了几乎90%的文档，并且我们索引了足够多的剩余文档页面以使其可搜索。
自动图像文本识别系统组件
渲染
一旦我们开始在所有可OCR的文件上使用OCR提取文本的过程，我们意识到我们有两种选择来渲染嵌入在PDF文件中的图像数据：我们可以单独提取嵌入在文件流中的所有光栅（即像素）图像对象，或者我们可以将PDF的整个页面渲染为光栅图像数据。在对两者都进行了实验之后，我们选择了后者，因为我们已经为文件预览功能提供了强大的大规模PDF渲染基础架构。使用此系统的一些好处包括：
- 它可以自然地扩展到其他渲染或图像嵌入文件格式，如PowerPoint，PostScript以及预览基础结构支持的许多其他格式
- 实际呈现自然会保留文本标记的顺序和文本在布局中的位置，同时考虑到文档结构，这在从多图像布局中提取单独的图像时无法得到保证
我们的预览基础结构中使用的服务器端渲染基于PDFium，这是Chromium项目中的PDF渲染器，这是Google启动的开源项目，是Chrome浏览器的基础。同一软件还用于正文文本检测，并决定文档是否为“仅图像”，这有助于确定我们是否要应用OCR处理。
一旦我们开始渲染，每个文档的页面都会并行处理，以降低延迟，根据我们上面的分析，上限为前10页。我们使用填充 2048 x 2048 像素矩形的分辨率呈现每个页面，同时保留纵横比。
文档图像分类
我们支持 OCR 的机器学习模型最初是为 Dropbox 文档扫描仪功能而构建的，目的是确定用户最近是否拍摄了（普通）照片，我们可以建议他们“变成扫描件”。这个分类器是使用线性分类器构建的，该分类器位于来自预训练的ImageNet模型（GoogLeNet/Inception）的图像特征之上。它接受过从多个不同来源收集的数千张图像的培训，包括公共图像，用户捐赠的图像以及一些Dropbox员工捐赠的图像。最初的开发版本是使用Caffe构建的，该模型后来被转换为TensorFlow以与我们的其他部署保持一致。
在微调此组件的性能时，我们学到了一个重要的教训：一开始，分类器偶尔会产生误报（它认为包含文本的图像，但实际上没有），例如空白墙壁，天际线或开阔水域的图片。虽然它们看起来与人眼完全不同，但分类器在所有这些图像中都看到了非常相似的东西：它们都有平滑的背景和水平线。通过迭代标记并将此类所谓的“硬底片”添加到训练集中，我们显着提高了分类的精度，有效地教导分类器，即使这些图像具有文本文档的许多特征，它们也不包含实际文本。
角检测
在图像中定位文档的角并定义其（大约）四边形形状是字符识别之前的另一个关键步骤。给定角的坐标，图像中的文档可以通过简单的几何变换进行校正（制成直角矩形）。文档角检测器组件是使用另一个ImageNet深度卷积网络（Densenet-121）构建的，其顶层被产生四角坐标的回归量所取代。
用于训练此模型的测试数据仅使用了几百张图像。这些标签以四个或更多定义封闭文档边界多边形的二维点的形式出现，也是由 Mechanical Turk workers 使用定制的 UI 绘制的，并通过机器学习团队成员的注释进行增强。通常，训练图像中包含的文档的一个或多个角位于图像范围之外，因此需要一些人类直觉来填充缺失的数据。
由于深度卷积网络馈送的缩小图像，因此四边形的原始预测位置的分辨率低于原始图像。为了提高精度，我们采用两步流程：
- 获取初始四边形
- 在每个角落附近的更高分辨率的补丁上运行另一个回归
从四边形的坐标来看，可以很容易地将图像整流成对齐的版本。
令牌提取
实际的 opticalcharacterrecognition 系统，它提取文本标记（大致对应于单词），在我们之前的博客文章中进行了描述。它将来自角检测步骤的校正图像作为输入，并生成令牌检测，其中包括令牌的边界框和每个令牌的文本。这些被排列成一个大致顺序的标记列表，并添加到搜索索引中。如果有多个页面，则每个页面上的令牌列表将连接在一起以形成一个大列表。
将各个部分放在一起
要对所有符合条件的用户的所有潜在可索引文件运行自动图像文本识别，我们需要一个可以引入传入文件事件（例如，添加或编辑）并启动相关处理的系统。事实证明，这是 Cape 的一个自然用例，Cape 是一个灵活、大规模、低延迟的异步事件流处理框架，可为许多 Dropbox 功能提供支持。我们添加了一个新的 Cape 微服务工作线程（称为“lambda”），用于 OCR 处理，作为常规搜索索引框架的一部分。
处理的前几个步骤利用 Dropbox 的常规预览版基础架构。这是一个可以有效地将二进制文件作为输入并返回此文件的转换的系统。例如，它可能采用 PowerPoint 文件并生成该 PowerPoint 文件的缩略图图像。该系统可以通过插件进行扩展，这些插件对特定类型的文件进行操作并返回特定的转换;因此，添加新的文件类型或转换很容易做到。最后，系统还可以有效地缓存转换，因此，如果我们尝试生成同一 PowerPoint 文件的缩略图图像两次，则昂贵的缩略图操作将只运行一次。
我们为此功能编写了几个预览插件，包括（数字对应于上面的系统图）：
- 检查我们是否应该继续处理，基于它是JPEG，GIF，TIFF还是没有嵌入文本的PDF，以及用户是否有资格获得该功能
- 运行可 OCR 的分类器，该分类器确定给定图像是否包含文本
- 对每个图像运行文档角检测器，以便我们可以对其进行校正
- 使用 OCR 引擎提取令牌
- 将令牌列表添加到特定于用户的搜索索引
鲁棒性
为了在远程调用期间出现暂时性/临时性错误时提高系统的健壮性，我们使用带抖动的指数退避（分布式系统中的最佳实践技术）重试远程调用。例如，我们通过第二次和第三次重试，将 PDF 元数据提取的失败率降低了 88%。
性能优化
当我们将管道的初始版本部署到一小部分流量进行测试时，我们发现机器学习模型（角检测，方向检测，OCRing等）的计算开销将需要一个巨大的集群，这将使此功能的部署成本太高。此外，我们发现我们看到的流量大约是我们根据历史增长率估计的流量的2倍。
为了解决这个问题，我们首先提高了 OCR 机器学习模型的吞吐量，并假设增加吞吐量是减少我们需要的 OCR 集群大小的最大杠杆。
为了实现准确、受控的基准测试，我们构建了一个专用的沙盒环境和命令行工具，使我们能够将输入数据发送到多个子服务，以单独测量每个子服务的吞吐量和延迟。我们用于基准测试的秒表日志是从实际的实时流量中采样的，没有残留数据收集。
我们选择从外到内进行性能优化，从配置参数开始。在处理CPU密集型机器学习瓶颈时，有时可以通过简单的配置和库更改来实现显着的性能提升;我们在下面讨论几个例子。
第一个提升来自为在 jail 中运行的代码选择正确的并发度：为了安全起见，我们在软件 jail 中运行大多数直接接触用户内容的代码，该 jail 限制可以运行的操作，将内容与不同用户隔离以防止软件错误损坏数据，并保护我们的基础架构免受恶意威胁向量的侵害。我们通常在机器上为每个内核部署一个 jail，以实现最大的并发性，同时允许每个 jail 仅运行单线程代码（即数据并行性）。
然而，事实证明，我们用于从像素预测字符的TensorF低深度学习框架默认配置了多核支持。这意味着每个 jail 现在都在运行多线程代码，这导致了大量的上下文切换开销。因此，通过关闭TensorFlow中的多核支持，我们能够将吞吐量提高约3倍。
在此修复之后，我们发现性能仍然太慢 - 甚至在达到我们的机器学习模型之前，请求就已经成为瓶颈！一旦我们根据所使用的 CPU 内核数调整了预分配的 jail 和 RPC 服务器实例的数量，我们终于开始获得预期的吞吐量。通过在TensorFlow中启用矢量化的AVX2指令，并通过TensorFlow XLA将模型和运行时预编译为C++库，我们获得了额外的显着提升。最后，我们对模型进行了基准测试，发现狭窄中间层上的2D卷积是热点，并通过在图中手动展开它们来加速它们。
文档图像管道的两个重要组件是角检测和方向预测，这两个组件都是使用深度卷积神经网络实现的。与我们之前使用的Inception-Resnet-v2模型相比，我们发现Densnet-121的速度几乎是其两倍，并且在预测文档角的位置方面仅略低。为了确保我们不会在准确性上倒退太多，我们运行了A / B测试来评估对可用性的实际影响，比较用户手动更正自动预测的文档角落的频率。我们的结论是，这种差异可以忽略不计，性能的提高是值得的。
为未来的智能功能铺平道路
使文档图像可搜索是更深入地了解文档结构和内容的第一步。有了这些信息，Dropbox 可以帮助用户更好地整理文件，这是迈向更开明的工作方式的一步。
自动图像文本识别是 Dropbox 工程师处理的大型项目类型的典型例子，这些项目涉及计算机视觉和机器学习。
