使用机器学习对数十亿图像中的文本进行索引，会发生什么？
点击上方关注，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文件的缩略图图像，那么昂贵的缩略图操作只会运行一次。
我们为此功能编写了几个预览插件，包括（数字对应于上面的系统图）：
- 检查我们是否应该继续处理，具体取决于它是JPEG、GIF、TIFF还是没有嵌入文本的PDF，以及用户是否有资格使用该特性。
- 运行OCR能力分类器，该分类器确定给定图像是否具有文本。
- 在每张图像上运行文档角点检测器，以便我们对其进行纠正。
- 使用OCR引擎提取令牌。
- 将令牌列表添加到用户特定的搜索索引中。
稳健性
为了在远程调用期间出现瞬态/临时错误的情况下提高系统的稳健性，我们使用抖动指数退避重试远程调用，这是分布式系统中的最佳实践技术。例如，通过第二次和第三次重试，我们将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工程师处理的涉及计算机视觉和机器学习的大型项目类型的主要示例。
