基本原则

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

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

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

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

他们是：

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

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

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

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

图 1：显示较差的界面隔离的 ML 系统示意图。

让您的接口具体化，不要定义和构建与不必要组件交互的大型、混乱、通用的接口。一个干净、规范的 REST API（作为示例）是您的好朋友。

(D) 依赖倒置：同样，当应用于 OOP 时，其目的是通过让组件或对象依赖于抽象而不是直接依赖于彼此来解耦它们。倒置指的是，您正在将依赖关系的方向从较高级别的组件依赖于较低级别的组件更改为相反的方向。当考虑诸如包之类的东西时，这种方法非常有效，我们可以从较高级别的包依赖于较低级别的包（“导入 X”），但实际上两个包都引用了半独立的抽象。

如果您牢记这些原则，那么在 MLOps 和 LLMOps 旅程中您将会受益匪浅。

现在让我们来看看一些可以帮助您将您的建筑和设计之旅提升到一个新水平的资源。

AWS 架构详解和完善的架构框架

了解大量 ML 架构的一个好方法是查看云提供商建议您在其平台上做什么。AWS 在策划大量非常具有解释性的资源方面做得非常出色。我特别喜欢他们的Architecture Lens和Well Architected资源集，它们为您提供了大量现成的见解。例如，如果我们查看他们的 Machine Learning Lens，我们会获得有关 ML 项目生命周期的有用内容（参见图 2），或者此生命周期特定部分的详细工作图，如图 3 所示的监控生命周期图。

图 2：ML 生命周期https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/well-architected-machine-learning-lifecycle.html

图 3 特别说明了 ML Lens 资源如何在核心技术之上提供分层视图来展示流程。我一直认为，您需要构建的流程才是真正构成您的解决方案的要素！

图 3：来自 AWS ML Lens 的 ML 生命周期的模型监控阶段https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/ml-lifecycle-phase-monitoring.html。

此类资源是极佳的起点，在您着手构建自己的解决方案时，它们会为您提供大量素材。绝对值得一看！

作为对此的补充，AWS 还拥有其完善的架构框架，该框架以上述“镜头”为基础，提供一系列可供您使用的实验室以及根据您所需的工作负载评估和生成有用的架构内容的工具。

图 4：AWS Well Architected Framework 工作流程https://aws.amazon.com/well-architected-tool/

这些资源通常非常互补，所以可以同时查看两者。我特别喜欢 Well Architected 框架强调“最佳实践”的应用并帮助您完成这一旅程。

这些材料读起来非常有用，但我认为学习优秀设计和建筑的真正方法是去建造。所以在你的项目中使用这些材料，但一旦你真正深入其中，你就会感觉到理论与现实的差距有多大，以及你可能必须在哪些方面调整这些原则和设计以适应你所处的环境。这都是工作的一部分，这将使你的团队或组织在短时间内从业余爱好者一跃成为专业的运营团队！

注意：我仍然不太清楚这两种资源有何区别，但它们都很有用！我认为 Lenses 属于 Well Architected Framework，是具体的项目范例……

LLMOps 的架构和设计原则

说到 LLMOps（以及其他类型的生成式 AI 操作），有些事情略有不同，但很多事情保持不变。我认为上述原则和资源仍然非常有用，仍然适用。当我们转向 LLMOps 时，我想说，差异更多地在于我们关注的领域以及我们如何努力在如此快速发展的领域中发展良好的实践。

就该领域的快速发展而言，平台团队、架构师和用例或业务线团队必须齐心协力，不断分享知识，确保快速反馈哪些设计可行、哪些不可行以及哪些需要更改。图 5 显示了试图强调这些要点的图表。

图 5：当我们试图了解 GenAI 和 LLMOps 的“良好”面貌时，不同团队和能力之间的反馈循环和互动。

我看到的一些事情已经实现（我会尝试在其他帖子中介绍更多内容）：

堆栈肯定在发生变化，但许多核心组件仍然存在，其中一些元素是新的，而有些只是我们以前所做工作的改编。参见图 6。
RAG 是许多应用程序的基础，我认为它不会消失。有人猜测大型上下文窗口（例如 Google Gemini 的 150 万个上下文窗口）会取代 RAG。这绝对是少数人的观点，现在大多数人似乎都同意，实际上长上下文窗口并不是用来存储所有内容的！它们可以处理更大的文本片段，但这并不能取代您所需语料库的永久、可读取存储。
护栏不仅可以保护，还可以帮助实现标准化。通过研究Nemo-Guardrails等项目，护栏的 .yml 和 colang 配置实际上为应用程序的 LLM 交互提供了许多不错的结构。我认为我们会看到越来越多这样的情况。因此，护栏可以阻止 LLM 超出行为规范的容忍度，同时也有助于创建更可预测的解决方案。
监控和评估仍将能够利用我们已经建立的许多核心流程（构建监控管道，获取基本事实，或者您的指标在没有它的情况下是否能工作，计算指标，将结果显示为遥测警报），但我们用于评估的数据集和我们计算的指标的细节似乎仍然需要大量的创造力和思考。所以花点时间想想“我将如何监控和评估我的 LLM 系统以适应我的用例？”
对于如何处理即时注入等安全问题的理解正在迅速发展，但保障措施、护栏、内容审核和其他技术的操作实施仍在许多组织和用例中得到验证。再次，花时间进行实验、实验、实验，并通过良好的红队补充所有这些工作。（有关 LLMSecOps 的更多信息，请尝试观看 Abi Aryan的演示文稿之一）。