🔎大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流🔎
📝个人主页－Sonhhxg_柒的博客_CSDN博客 📃
🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝
📣系列专栏 - 机器学习【ML】 自然语言处理【NLP】 深度学习【DL】
🖍foreword
✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。
如果你对这个系列感兴趣的话，可以关注订阅哟👋
文章目录
Spark NLP 模型缓存
Spark NLP 和 TensorFlow 集成
Spark 优化基础
设计级优化
分析工具
监控
管理数据资源
测试基于 NLP 的应用程序
单元测试
集成测试
烟雾和健全性测试
性能测试
可用性测试
演示基于 NLP 的应用程序
清单
模型部署清单
扩展和性能检查表
测试清单
结论
我们讨论了许多可以用来构建 NLP 应用程序的不同方法和技术。我们已经讨论了如何规划和开发 NLP 应用程序。现在，让我们谈谈部署 NLP 应用程序。
我们还将讨论在生产环境中部署模型。在讨论如何部署模型之前，我们需要了解对我们产品的需求。如果模型在批处理过程中使用，而不是由 Web 服务用于单独评估，这会改变我们想要部署的方式。我们还需要知道模型需要什么样的硬件。我们在这里讨论的一些事情应该在建模开始之前考虑——例如，生产中的可用硬件。
最简单的情况是您的应用程序在内部集群上作为批处理运行。这意味着您的性能要求仅基于内部用户（在您的组织中），并且保护数据也将更加简单。但并非一切都这么简单。
部署生产质量系统的另一个重要部分是确保应用程序以足够快的速度运行以满足用户需求，而不会占用太多资源。在本章中，我们将讨论如何优化 NLP 系统的性能。首先，我们需要考虑我们想要优化什么。
当人们谈论性能测试时，他们通常是指测试程序运行需要多长时间以及需要多少内存。由于文档大小可能存在差异，这会使基于 NLP 的应用程序的性能测试变得更加困难。此外，像 Spark NLP 这样的注释框架可以产生比输入多很多倍的数据，因此优化磁盘使用也很重要。Spark NLP 是一个分布式框架，因此您还应该考虑作为分布式系统的性能。
分布式系统需要考虑到单个机器的所有性能要求，并确保集群得到有效使用。这意味着您不会不必要地锁定资源，而是使用分配给您的进程的资源。
即使应用程序投入生产，仍有工作要做。我们需要监控软件和模型的性能。在本章中，我们将讨论当我们想要上线应用程序时需要做什么。
启动任何应用程序的第一步是确保产品所有者和利益相关者感到满意。对于某些应用程序，这将像展示我们可以演示需求中的功能一样简单。对于基于 NLP 的应用程序，这可能会更加困难。这是因为关于 NLP 工作原理的直觉往往是错误的。这就是为什么测试如此重要。
本章的清单比本书这一部分的其他清单要大得多。这是因为 NLP 应用程序的部署可能非常复杂。它可能看起来势不可挡，但我们也可以使用这些问题的答案来更清楚地了解我们的项目范围。
让我们从模型部署开始。
Spark NLP 模型缓存
我们在本书的几个章节中使用了 Spark NLP 中的预训练模型。这些模型存储在本地缓存中。预训练的管道存储在这里，管道中各个步骤的模型以及 TensorFlow 模型也是如此。在探索神经网络时，我们在本书中使用了 Keras。然而，Keras 是用于神经网络库的高级 API。TensorFlow 是执行实际计算的框架。然而，TensorFlow 模型是另一种动物，因为它们是工作机器所必需的，而不仅仅是驱动程序。只要这些机器可以访问互联网，Spark NLP 就会为您设置此缓存。如果您没有 Internet 访问权限，您可以将文件放在共享存储（如 HDFS）中，并修改您的代码以从该位置加载。
此模型缓存需要访问永久磁盘存储。大多数部署方案都满足此要求，但如果您要在 Amazon Lambda 上进行部署，这不是一个好主意。
一般来说，Spark 对于实时 NLP 应用程序来说并不是一个好的解决方案。尽管缓存提高了性能，但 Spark 的开销最小。您可以使用 Spark NLP 轻型管道，它们是在 Spark 外部运行的预训练管道（如果可用），但您应该在部署到任何外部场景之前测试性能。
要考虑的另一件事是生产环境中的内存可用性。Spark NLP 使用 RocksDB 作为静态嵌入的内存键值存储。您应该确保您的环境可以支持这种内存负载。如果您使用的是 Spark，那么几乎可以肯定您有足够的内存用于嵌入。
我们已经讨论了 Spark NLP 如何访问模型；现在让我们谈谈它如何与 TensorFlow 集成。
Spark NLP 和 TensorFlow 集成
GPU 可以大大缩短训练时间的原因是 GPU 是为进行批量并行处理而构建的。这对于进行矩阵运算非常有用。然而，并不是所有的机器都有适合的硬件。这意味着为您的项目启用 GPU 支持可能需要额外的投资。如果你在你的开发机器上训练，有一些常见的显卡可以很好地进行一些简单的 GPU 训练。由于训练比提供模型的计算密集度更高，因此您可能只需要 GPU 支持来进行训练。有些模型足够复杂，以至于在 CPU 上评估模型的速度非常慢。如果您打算使用如此复杂的模型，则需要与处理硬件基础架构的团队进行协调。他们需要征用机器，
既然我们已经讨论了特定于 Spark NLP 的部署注意事项，那么让我们讨论一下复合系统的部署。
Spark 优化基础
优化基于 Spark 的程序以及基于 Spark NLP 的程序的一个重要方面是持久性。谈持久化，让我们回顾一下 Spark 是如何组织工作的。
当您引用 aDataFrame时，它不一定引用集群上的实际数据，因为 Spark 是惰性的。这意味着如果您加载数据并执行一些简单的转换，例如将字符串更改为小写，则不会加载或转换任何数据。相反，Spark 制定了一个执行计划。当您向此执行计划添加更多指令时，它会形成一个有向无环图 (DAG)。当您从 请求数据时DataFrame，它会触发 Spark 创建作业。作业分为多个阶段。阶段是为您引用的对象生成数据所必需的一系列处理步骤。然后将这些阶段拆分为任务，每个分区一个，分发给执行者。执行器将运行与处理器一样多的任务。
当您持久化 aDataFrame时，这将导致 Spark 在实现后存储实际数据。当您将重用一组特定数据时，这很有用。例如，当您训练逻辑回归模型时，将会对数据进行迭代。您不希望 Spark 在每次迭代时都从磁盘重新加载，因此您应该保留DataFrame包含训练数据的内容。幸运的是，您不需要自己执行此操作，因为它是在逻辑回归的训练代码中实现的。
有一些参数可以控制数据的持久化方式。首先是是否使用磁盘。如果您坚持到磁盘，您将拥有更多空间，但重新加载它将更加耗时。第二个参数是是否使用内存。您必须使用磁盘或内存，或者您可以选择两者。如果您同时选择两者，Spark 会将它可以存储的内容存储在内存中，并在必要时“溢出”到磁盘。您还可以选择使用堆外内存。在 Java 中，内存有两个部分。堆或堆上内存是存储 Java 对象的地方。JVM 垃圾收集器在堆上工作。另一部分是堆外内存。Java 将 JVM 使用的类、线程和其他数据存储在堆外内存中。将数据持久保存在堆外内存空间意味着您不受限于分配给 JVM 的内存。这可能很危险，因为 JVM 不管理或限制这个空间。如果你占用太多堆内存，你的程序会得到一个OutOfMemoryError; 如果您占用过多的非堆内存，则可能会导致机器停机。
除了配置存储持久数据的位置之外，您还可以决定是否将其序列化。存储序列化数据可以更节省空间，但会占用更多 CPU。最后一个参数是复制。这将导致数据在不同的工作人员上复制，如果工作人员失败，这可能很有用。
坚持将帮助我们避免不必要地重做工作，但我们也希望确保我们有效地完成工作。如果您的分区太大，则执行程序将无法处理它们。您可以为执行程序添加更多内存，但这会导致 CPU 利用率低下。如果您的工作人员有多个核心，但您将大部分内存用于处理一个核心上的一个分区，那么所有其他核心都被浪费了。相反，您应该尝试减小分区的大小。但是，您不想走另一个极端。分区有开销，因为 Spark 可能需要打乱数据。这将导致聚合和分组操作非常低效。理想情况下，每个分区的大小应为 200 MB。
Spark 开发人员一直在研究提高性能的新方法，因此您应该查看每个版本中的编程指南，看看是否有优化应用程序的新方法。
设计级优化
- 数据准备
- 特征创建
- 超参数调优
- 最终训练
- 指标计算
- 模型评估
您可以将这些组合在一起，但要考虑到集群中的其他居民，并注意工作流不同部分的资源需求。
另一个重要方面是监控您的管道以及它们使用和产生的数据。有许多“神秘”的故障是由于一个奇怪的文档、一个空文档或一个比正常大三百倍的文档造成的。您应该记录管道中的信息。有时，这会创建自己的大数据。除非您尝试调试管道，否则您不需要为每个文档输出信息或记录您正在处理的内容。相反，您至少可以跟踪最小值、均值和最大值。应该跟踪的基本值是文档大小和处理时间。如果你实现了这个，那么你有一个快速的第一步来分类问题。
分析工具
有多种分析工具可用于检查性能。这些工具每个都有一个使用它们的上下文。让我们首先看一下 Java Microbenchmark Harness。
Java Microbenchmark Harness (JMH)是一个 JVM 框架，可让您测试代码中的原子（或接近原子）操作。例如，如果您使用自定义数据结构，则可以使用 JMH 来测试插入和检索。JMH 在测试库代码时比测试应用程序更有用。这是因为大多数应用程序代码依赖于许多库函数，因此不是原子的。但是，这不是您可以用来监视的东西。它通过编译运行（和重新运行）部分代码的单独程序来工作。
VisualVM 是 JVM 应用程序的免费分析器。它允许您跟踪创建的类实例的数量，以及在方法中花费的时间。如果您发现性能问题，这是一个很好的调查工具。一个缺点是它确实要求您可以在一台机器上运行您的应用程序。VisualVM 运行一个应用程序来检查应用程序的 JVM，因此它会对性能产生负面影响。
监控
如果你想监控 NLP 应用程序，Ganglia 是我喜欢的应用程序。Ganglia 允许您实时查看集群中的 CPU 和内存利用率。许多现代资源管理器，如 Mesos 和 Kubernetes，都内置了类似的功能。如果您需要应用程序可靠运行，Ganglia 或资源管理器提供的资源监控是必不可少的。
现在我们知道如何检查应用程序使用的资源，我们需要考虑应用程序使用和生成的数据。
管理数据资源
NLP 应用程序中使用了三种数据。有输入数据，这是您的应用程序处理的数据。输入数据的示例包括文档语料库、单个文档或搜索查询。有输出数据，这是您的应用程序生成的数据。输出数据的示例包括序列化、注释文档的目录、包含注释的文档对象或文档列表和相关性分数。第三个数据是您的应用程序用作配置的数据。配置数据的示例包括训练模型、引理词典或停用词列表。
单元测试
最著名的测试是单元测试。单元测试是测试代码中的一个功能单元。例如，如果您有一个短语分块器，它使用辅助函数来提取词性标签，您不应该为辅助函数编写单独的测试。该辅助函数不是分块器的单独功能，它是分块功能的一部分。单元测试应该只需要他们正在测试的代码。它们不应该需要网络资源、生产数据、其他服务等等。如果您的代码确实假设了这些东西，那么您将需要模拟这些东西。嘲笑是一种创建所需组件外观的技术。使用数据，您可以获取最小的必要数据样本，也可以创建少量的假数据。
集成测试
一旦您构建了系统的组件，您将需要确保它可以与其他组件一起使用。这称为集成测试。通常，集成测试是在单元测试框架中实现的，因此它们可能被错误地称为“单元”测试。让我们看一下我们的研究论文分类器项目，以获取集成测试的假设示例。如果我们将与用于向大学数据库提交论文的现有系统集成，我们将需要有两组集成测试。第一组将测试分类器服务如何与管理数据库的代码集成。第二组将测试分类器如何与论文提交系统的 UI 集成。
烟雾和健全性测试
您还需要测试来帮助我们测试系统总体上是否符合我们的预期。这样的测试一般有两种。首先是冒烟测试。冒烟测试会尽可能多地测试代码，以确定是否存在任何阻碍问题。这个比喻来自测试管道。如果您想在化粪池系统中找到泄漏点，您可以将烟雾泵入管道。如果你看到冒烟，那就告诉你问题出在哪里。您通常需要涵盖系统主要用途的冒烟测试。另一种整体系统测试是健全性测试。健全性测试用于确保系统与“常规”输入一起工作。如果冒烟测试或健全性测试失败，则不应部署。如果您在部署后发现系统中的错误，您应该使用重现步骤作为未来的冒烟测试。这些称为回归测试。它们帮助我们避免意外地重新引入错误。
性能测试
一旦进行了功能测试，您就可以着眼于测试系统的其他方面。让我们从性能测试开始. 在本章前面，我们讨论了优化应用程序性能的方法。要知道应用程序的新版本是否会引入性能问题，您应该进行自动化测试。这是您与性能监控结合使用的东西。如果性能不是一个重要的要求，那么跳过这种测试是合理的。有时，由于创建类似生产环境的费用，性能测试被跳过。您应该更改性能测试的规模，而不是这样做。虽然您确实无法在没有类似生产环境的情况下测试应用程序的性能，但您仍然可以测试组件的性能。这不会捕捉到全球性问题，但是本地性能测试可以测试特定组件或功能是否存在性能恶化的错误。使用我们在上一章中讨论的分析工具，您可以在代码中找到热点，即占用最多时间或内存的区域。本地性能测试应侧重于这些领域。
可用性测试
另一种重要的非功能测试是可用性测试. 如果您的应用程序只是一个批处理过程，那么就不需要进行这种测试。但是，如果您的应用程序有真正的最终用户，比如客户，那么您绝对应该拥有这个。当人们使用基于 NLP 的系统时，有时会出现过高的期望。例如，假设我们正在构建一个情绪分析工具。该工具预测情绪并突出显示导致预测的术语。该模型可能会识别出对其训练的语料库具有统计意义的单词，但人类可能会认为它们很愚蠢。要找到这些夸大的期望，您应该找到与实际用户尽可能相似的测试用户。如果你只是使用同样熟悉软件的同事，那么他们可能对系统能做什么有更真实的理解。
由于直觉并非万无一失，尤其是在语言方面，我们需要确保测试我们的假设。然而，测试利益相关者的假设更加困难。应用程序需要通过另一个测试——演示。
演示基于 NLP 的应用程序
因为这些显然很糟糕，但在统计上是合理的，示例可能会令人尴尬，因此挑选示例可能很诱人。这不仅是不道德的，而且会将他们的发现转移到生产中，这会更糟。即使问题不是“真正的”问题，您也应该尽可能坦诚相待。了解软件工程、数据科学和语言学的人的交叉点很小，因此利益相关者可能很难理解解释。如果在完全部署后发现问题，您的解释将受到额外的怀疑。
清单
考虑每个清单中的问题。
模型部署清单
扩展和性能检查表
测试清单
- 谁在部署我的应用程序？
- 我是否进行了部署测试（集成测试、冒烟测试、性能测试等）？
- 如何演示应用程序？
- 我如何监控我的应用程序？
- 我需要处理敏感数据吗？
- 我将如何查看我的应用程序的性能？
-
测试基于 NLP 的应用程序
- 我的单元测试有多少覆盖率？
- 我要集成哪些系统/组件？
- 谁将运行我的烟雾/理智测试？
- 我可以进行全局性能测试吗？
- 我的性能热点在哪里？
- 我的应用程序会有实际用户吗？
- 有潜在用户试用过我的产品吗？
-
演示基于 NLP 的应用程序
- 我要向谁展示我的作品？他们的背景是什么（技术、领域专家，都不是？）
- 系统有什么限制？
- 如果有潜在的问题结果，为什么是合理的？或者，我将如何修复它们？
结论
在本章中，我们讨论了使用 NLP 应用程序之前所需的最后步骤。然而，这还不是结束。您可能会想办法改进您的处理、建模、测试以及有关 NLP 应用程序的所有其他方面。本章讨论的想法是改进的起点。软件开发中最困难的事情之一就是接受发现问题和错误最终是一件好事。如果您看不到某个软件的问题，那意味着您最终会感到惊讶。
在这本书中，我谈到了身兼三个帽子——软件工程师、语言学家和数据科学家——并讨论了在构建 NLP 应用程序时考虑所有三个方面的必要性。这可能看起来很困难，而且经常如此，但这也是一个成长的机会。尽管存在难以解释的统计上合理的错误，但当 NLP 应用程序做一些直观的事情时，它是令人难以置信的回报。
在需要添加或“修复”一个东西和想要将它推向世界之间总是存在平衡。软件工程、语言学等科学和数据科学的伟大之处在于，你肯定会在工作中犯错。你之前的每个人都犯过错误，你之后的每个人都会犯错。重要的是我们修复它们并减少错误。
