PG电子APPNLP任务的完整机器学习管道
2026-01-12 10:15:49
浏览次数：
次
返回列表
complete-machine-learning-pipeline-for-nlp-tasks-f39f8b395c0d
这个项目的灵感来源于我在职业生涯中有机会解决的一个问题，但是，这里提出的问题不同，本文不包含产品中使用的任何代码和/或解决方案。
这里给出的解决方案是一个简化的解决方案。文章的最后讨论了使其更接近可靠的生产就绪服务所需的进一步步骤。
几年前，一个可靠的ML系统在生产中运行并带来价值是大公司的特权，而其他公司则无法获得能够实现此类产品的人才和技术。
本文提供了将PoC转换为完整的ML产品所需的一切，包括简化管道的参考实现以及下一步操作的提示。
该系统解决的具体问题可以描述如下：从收到的电子邮件中提取公司名称并记录它们。这听起来可能是一个肤浅的问题，但应该可以用来演示如何将ML系统投入生产。
SMTP（发送电子邮件）/IMAP（阅读电子邮件）邮件服务器使用打开相应端口的GreenMail docker映像进行模拟：
预测工作者（Prediction Worker）是一种微服务，提供一个端点，用于从传入文本预测实体。在我们的示例中，我们将自己局限于一个非常简单的基于FastAPI的web服务，该服务从SpaCy加载一个预训练模型并将其应用于输入。
DB只是PostgreSQL DB的一个实例。同样，我们假设它应该足够的合理负载，我们不考虑可靠性问题时，你想有一个集群或创建一个只读副本的分析，因此分析师不能影响生产实例。
用于运行管道的PC应安装Docker和telnet。如果需要，请参阅系统的安装说明。
4个服务（邮件服务器、数据库、预测服务和orchestrator）的整个管道可以通过一个命令启动：
管道由邮箱中出现的未读电子邮件触发。为了发送一个，可以使用telnet util。
还必须将数据记录到数据库中。为了检查，任何DB客户端都可以使用以下连接参数：
这个实现可以让读者了解真正的ML系统是什么样子，以及它的组件是如何交互的。然而，为了使系统健壮、可靠和性能良好，还需要更多的步骤。
给定的实现是包括编排器（2）和预测工作者（3）中的同步处理程序，这意味着多个请求不能并行处理，也就是说，一个预测必须在发送下一个请求之前完成。
在编排器（发布主题的数据生产者）和预测工作者（订阅主题的数据消费者）之间以及数据源和编排器之间放置一个队列，如Apache Kafka，也许是个好主意。
如果预测工作者不能处理请求的数量，它将使服务更加解耦，并可能平滑负载峰值，避免超时。
拥有一个分布式的微服务系统而不是一个可以做所有事情的整体的优势之一是易于扩展。
由于可靠性以外的原因，合理的负载可能不需要将工作流编排器扩展到单个主机之外，但是，单个预测工作者很可能无法处理更高的负载。
幸运的是，预测工作者是一个无状态服务，这意味着它不需要在单个请求上下文之外维护状态（即，服务实例之间没有竞争条件），这反过来使其水平扩展和添加负载平衡服务变得简单。
由于简单，本文附带的示例使用docker compose部署管道。然而，实际生产系统很少依赖此工具。我经历了在科技公司部署微服务的两种主要方式：
有些服务甚至可以在没有任何附加代码的情况下发出度量。虽然这些集成可以为我们提供HTTP响应代码速率或响应延迟等基本指标，但ML管道需要的不仅仅是这些。让我们看看还可以/应该监控哪些内容：
模型预测的预测标签率和预测置信度/相似度。某些实体检测率的变化可以告诉我们潜在的模型过时和需要重新训练/微调，例如，编排器(2)可以基于某些阈值触发这些
用于检测输入数据分布漂移的输入数据参数，例如，输入文本的长度、字数等。与前一点类似，但此处的变化可能表明数据的性质已发生变化，并且可能需要对模型进行调整
