旷野之间18 - MLOps 和 LLMOps 的一些架构和设计原则

基本原则

🏗 当谈到 MLOps 平台的架构时，您可能会感到恼火（喘息、震惊、恐惧），因为您实际上应该遵循与传统软件工程相同的许多原则。正如我将在本文后面讨论的那样，这也适用于 LLMOps。

让我们列出一些你应该知道的重要设计原则。文献中可能还有很多其他的原则，但这些只是我认为特别有用的一些原则（有关更多详细信息，请参阅我的书的第 5 章）：

1. 关注点分离：构建您的组件，使它们只做一件事并做好！如果您在编排工具中运行大量数据转换，或者尝试在 ML 管道中进行负载平衡，那么您可能已经违反了这一原则*。
2. 最小意外原则：在我看来，这个原则的定义并不太严格（如果你有一个很好的定义，请分享！）但我认为，当你向一个具有领域/架构知识的相当称职的人展示你的架构时，你应该尽量减少“意外”选择的数量。当你向他们介绍你的架构时，他们会说多少次“哦”？“哦，我看到你决定使用 SageMaker 模型注册表作为应用程序数据库”或“我看到你使用 LLM 生成了一些非常标准的查询来提取最后一天的数据”（极端的例子，但你明白了）。
3. 最省力原则：人类会选择阻力最小的路径，所以不要让事情变得比需要的更复杂，否则人们会找到捷径。此外，开发人员会使用有效的模式，只有当有更好的方法时才会反对它。我对此的解释实际上是说，让事情尽可能简单很重要，同时也愿意根据反馈再次让事情变得更简单。

然后，您可以了解一些真正的软件工程经典，即SOLID原则，这些原则被编写用于面向对象编程 (OOP)，但它们实际上是非常通用的概念，您通常可以将它们应用于整个架构！

他们是：

（S） 单一职责：至于关注点分离，只做一件事更容易维护，也更可靠！

(O) 开放/封闭：让您的组件“对扩展开放，但对修改封闭”。这意味着，如果我们的设计已经有 3 个 ML 管道，那么为了在解决方案中添加更多功能，我只需添加另外 1、2、3 …n 个管道即可。这表明设计对扩展开放。如果我在设计中规定所有 ML 功能都位于一个管道中，那么我必须进入并修改该单个管道以运行新模型并向此服务添加功能。这不太容易修改。注意：我认为这有灰色地带，您需要在某些地方修改设计，但它可以作为一个很好的指导。它也绝对适用于您的对象，因为它最初是为 OOP 设计的 – 让您的类对扩展开放，但对修改封闭。

(L) 里氏替换：最初，这主要集中在编写代码，其中对象/类可以被其子类型/子类替换，同时仍保持相同的应用程序行为。现在我认为我们可以概括地说，功能和接口是重要的部分，因此如果它们具有相同的接口和核心功能，将组件 A 替换为组件 B 不会对基本应用程序行为产生负面影响。

（I）接口隔离：这里的想法是组件不应该依赖于它们不会使用的接口/组件。因此，例如，如果我有一个如图 1 所示的简单设计，那么让应用程序数据库在最后与 ETL 管道对话或让 ML 管道与上游数据湖对话都是坏主意！

<