面向架构师的 GenAI 技术栈指南 - 十大工具

Keith Pijanowski Keith Pijanowski 于 AI/ML 2024 年 6 月 24 日

The Architect’s Guide to the GenAI Tech Stack - Ten Tools

这篇文章最早出现在 The New Stack 上，日期是 2024 年 6 月 3 日。

我之前写过关于现代数据湖参考架构的文章，讨论了每个企业都面临的挑战——更多的数据、老化的 Hadoop 工具（特别是 HDFS）以及对 RESTful API（S3）和性能的更高要求——但我想要填补一些空白。

现代数据湖，有时被称为数据湖仓，是数据湖和基于 Open Table Format Specification (OTF) 的数据仓库的结合。两者都建立在现代对象存储之上。

与此同时，我们深入思考了组织如何构建 AI 数据基础设施，以支持所有 AI/ML 需求——不仅仅是训练集、验证集和测试集的原始存储。换句话说，它应该包含训练大型语言模型所需的计算能力、MLOps 工具、分布式训练等等。基于这些思考，我们撰写了另一篇关于如何在现代数据湖中使用参考架构来支持你的 AI/ML需求的论文。下图说明了现代数据湖参考架构，并突出显示了生成式 AI 所需的功能。

来源：现代数据湖中的 AI/ML

这两篇论文都没有提到具体的供应商或工具。我现在想讨论构建现代数据湖所需的供应商和工具。在这个前 10 名列表中，每个条目都是支持生成式 AI 所需的功能。

1. 数据湖

企业数据湖建立在对象存储之上。不是你以前的那种用于廉价且深层存档用例的基于设备的对象存储，而是现代的、高性能的、软件定义的、原生 Kubernetes 对象存储，它们是现代 GenAI 堆栈的基石。它们可以作为服务（AWS、GCP、Azure）提供，也可以在本地或混合/两者兼而有之，例如 MinIO。这些数据湖必须支持流式工作负载，必须具有高效的加密和擦除编码，需要将元数据与对象原子地存储在一起，并支持 Lambda 计算等技术。鉴于这些现代替代方案是云原生的，它们将开箱即用地与其他云原生技术的整个堆栈集成——从防火墙到可观察性到用户和访问管理。

2. 基于 OTF 的数据仓库

对象存储也是 OTP 基数据仓库的底层存储解决方案。使用对象存储作为数据仓库可能听起来很奇怪，但这样构建的数据仓库代表着下一代数据仓库。这得益于 Netflix、Uber 和 Databricks 制定的 OTF 规范，它们使在数据仓库中无缝地使用对象存储成为可能。

OTF——Apache Iceberg、Apache Hudi 和 Delta Lake——之所以被编写出来，是因为市场上没有产品可以满足创建者的数据需求。从本质上讲，它们（以不同的方式）所做的就是定义一个可以建立在对象存储之上的数据仓库。对象存储提供了其他存储解决方案无法提供的可扩展容量和高性能的结合。由于这些是现代规范，因此它们拥有传统数据仓库所不具备的先进功能，例如分区演进、模式演进和零拷贝分支。

两家可以在 MinIO 之上运行其基于 OTF 的数据仓库的 MinIO 合作伙伴是 Dremio 和 Starburst。

Dremio Sonar（数据仓库处理引擎）

Dremio Arctic（数据仓库目录）

Open Data Lakehouse | Starburst（目录和处理引擎）

3. 机器学习操作 (MLOps)

MLOps 对于机器学习来说就像 DevOps 对于传统软件开发一样。两者都是一套旨在改进工程团队（开发或 ML）与 IT 运维团队（运维）之间协作的实践和原则。目标是使用自动化简化开发生命周期，从规划和开发到部署和运营。这些方法的主要优势之一是持续改进。

MLOps 技术和功能不断发展。你需要一个由主要参与者支持的工具，以确保该工具不断开发和改进，并将提供长期支持。这些工具中的每一个都在底层使用 MinIO 来存储模型生命周期中使用的工件。

MLRun（Iguazio，被麦肯锡公司收购）

MLflow（Databricks）

Kubeflow（Google）

4. 机器学习框架

你的机器学习框架是用来创建模型和编写训练模型代码的库（通常是 Python）。这些库功能丰富，因为它们提供了各种损失函数、优化器、数据转换工具和预构建神经网络层的集合。这两个库提供的最重要的功能是张量。张量是可以在 GPU 上移动的多维数组。它们还具有自动微分，在模型训练过程中使用。

如今，最流行的两种机器学习框架是 PyTorch（来自 Facebook）和 Tensorflow（来自 Google）。

PyTorch

TensorFlow

5. 分布式训练

分布式模型训练是在多个计算设备或节点上同时训练机器学习模型的过程。这种方法可以加快训练过程，尤其是在需要大型数据集来训练复杂模型时。

在分布式模型训练中，数据集被分成更小的子集，每个子集由不同的节点并行处理。这些节点可以是集群中的单个机器、单个进程或 Kubernetes 集群中的单个 pod。它们可能可以访问 GPU。每个节点独立地处理其数据集子集，并相应地更新模型参数。以下五个库为开发人员隔离了分布式训练的大部分复杂性。如果你没有集群，你可以在本地运行它们，但你需要集群才能看到训练时间显着减少。

DeepSpeed（来自 Microsoft）

Horovod（来自 Uber）

Ray（来自 Anyscale）

Spark PyTorch Distributor（来自 Databricks）

Spark TensorFlow Distributor（来自 Databricks）

6. 模型中心

模型中心并不是现代数据湖参考架构的一部分，但我还是把它加进来了，因为它对于快速开始生成式 AI 非常重要。Hugging Face 已经成为大型语言模型的必去之地。Hugging Face 主办了一个模型中心，工程师可以在那里下载预训练模型，并分享他们自己创建的模型。Hugging Face 也是 Transformers 和 Datasets 库的作者，它们与大型语言模型 (LLM) 和用于训练和微调它们的数据一起使用。

还有其他模型中心。所有主要的云供应商都提供某种上传和分享模型的方式，但 Hugging Face 凭借其模型和库的集合，已成为该领域的领导者。

Hugging Face

7. 应用程序框架

应用程序框架有助于将 LLM 集成到应用程序中。使用 LLM 与使用标准 API 不同。必须做很多工作才能将用户请求转换为 LLM 可以理解和处理的东西。例如，如果你构建了一个聊天应用程序，并且想使用检索增强生成 (RAG)，那么你需要对请求进行标记化，将标记转换为向量，与向量数据库（如下所述）集成，创建一个提示，然后调用你的 LLM。生成式 AI 的应用程序框架将允许你将这些操作链接在一起。如今，最广泛使用的应用程序框架是 LangChain。它与其他技术集成，例如 Hugging Face Transformer 库和 Unstructured 的文档处理库。它功能丰富，使用起来可能有点复杂，所以下面列出了一些替代方案，适用于那些没有复杂要求，想要使用比 LangChain 更简单的工具的用户。

TensorFlow（Keras API）

8. 文档处理

大多数组织都没有一个包含干净且准确文档的单一存储库。相反，文档分散在组织的各个团队门户中，以多种格式存在。准备生成式 AI 的第一步是构建一个管道，该管道只获取已批准用于生成式 AI 的文档，并将它们放到你的向量数据库中。对于大型全球组织来说，这可能是生成式 AI 解决方案中最困难的任务。

文档管道应将文档转换为文本，对文档进行分块，并将分块后的文本通过嵌入模型，以便将其向量表示保存到向量数据库中。幸运的是，有一些开源库可以为许多常见的文档格式执行此操作。下面列出了一些库。这些库可以与 LangChain 一起使用以构建完整的文档处理管道。

Unstructured

Open-Parse

9. 向量数据库

向量数据库有助于语义搜索。理解这其中的原理需要大量的数学背景，并且比较复杂。然而，语义搜索的概念很容易理解。假设您想找到所有讨论与“人工智能”相关的文档。在传统数据库中，您需要搜索“人工智能”的所有可能的缩写、同义词和相关词语。您的查询将

看起来像这样

SELECT snippet
FROM MyCorpusTable
WHERE (text like '%artificial intelligence%' OR
text like '%ai%' OR
text like '%machine learning%' OR
text like '%ml%' OR
... and on and on ...