![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
我之前写过
现代数据湖,有时也称为数据湖屋,一半是数据湖,一半是基于开放表格式规范 (OTF) 的数据仓库。两者都建立在现代对象存储上。
同时,我们深入思考了组织如何构建 AI 数据基础设施,以支持所有 AI/ML 需求——而不仅仅是训练集、验证集和测试集的原始存储。换句话说,它应该包含训练大型语言模型、MLOps 工具、分布式训练等所需的计算能力。基于这种思路,我们整理了另一篇关于如何使用现代数据湖的论文
来源:
这两篇论文都没有提到具体的供应商或工具。我现在想讨论一下构建现代数据湖所需的供应商和工具。在这个前 10 名列表中,每个条目都是支持生成式 AI 所需的一项能力。
企业数据湖建立在对象存储之上。它不是那种用于廉价和深度存档用例的老式基于设备的对象存储,而是现代、高性能、软件定义和 Kubernetes 原生的对象存储,它们是现代 GenAI 堆栈的基石。它们可以作为服务(AWS、GCP、Azure)或本地或混合/两者(例如 MinIO)使用。这些数据湖必须支持流式工作负载,必须具有高效的加密和擦除编码,需要将元数据与对象一起原子存储,并支持 Lambda 计算等技术。鉴于这些现代替代方案是云原生的,它们将与其他云原生技术的整个堆栈集成 - 从防火墙到可观察性再到用户和访问管理 - 开箱即用。
对象存储也是基于 OTP 的数据仓库的底层存储解决方案。将对象存储用于数据仓库可能听起来很奇怪,但以这种方式构建的数据仓库代表了下一代数据仓库。这得益于 Netflix、Uber 和 Databricks 编写的 OTF 规范,这使得在数据仓库中使用对象存储变得无缝。
OTF(Apache Iceberg、Apache Hudi 和 Delta Lake)之所以诞生,是因为市场上没有产品能够满足创建者的数据需求。本质上,它们所做的(以不同的方式)都是定义一个可以构建在对象存储之上的数据仓库。对象存储提供了其他存储解决方案无法提供的可扩展容量和高性能的组合。由于这些是现代规范,它们具有老式数据仓库所没有的高级功能,例如分区演进、模式演进和零拷贝分支。
两个可以在 MinIO 上运行基于 OTF 的数据仓库的 MinIO 合作伙伴是 Dremio 和 Starburst。
MLOps 之于机器学习,就如同 DevOps 之于传统软件开发。两者都是一套旨在改善工程团队 (Dev 或 ML) 和 IT 运营 (Ops) 团队之间协作的实践和原则。目标是利用自动化简化开发生命周期,从规划和开发到部署和运营。这些方法的主要好处之一是持续改进。
MLOps 技术和功能在不断发展。您需要一个由主要参与者支持的工具,以确保该工具不断发展和改进并提供长期支持。这些工具中的每一个都使用 MinIO 来存储模型生命周期中使用的工件。
您的机器学习框架是您用来创建模型并编写训练模型的代码的库(通常为 Python)。这些库功能丰富,因为它们提供了一系列不同的损失函数、优化器、数据转换工具和用于神经网络的预构建层。这两个库提供的最重要的功能是张量。张量是可以移动到 GPU 上的多维数组。它们还具有自动微分功能,可用于模型训练。
当今最流行的两个机器学习框架是 PyTorch(来自 Facebook)和 Tensorflow(来自 Google)。
分布式模型训练是跨多个计算设备或节点同时训练机器学习模型的过程。这种方法可以加快训练过程,尤其是在需要大量数据集来训练复杂模型时。
在分布式模型训练中,数据集被划分为较小的子集,每个子集由不同的节点并行处理。这些节点可以是集群中的单个机器、单个进程或 Kubernetes 集群中的单个 pod。它们可以访问 GPU。每个节点独立处理其数据子集并相应地更新模型参数。以下五个库使开发人员免受分布式训练的大部分复杂性。如果您没有集群,您可以在本地运行它们,但您需要一个集群才能看到训练时间的显着减少。
模型中心实际上并不是现代数据湖参考架构的一部分,但我还是将其包括在内,因为它对于快速开始使用生成式 AI 非常重要。Hugging Face 已成为大型语言模型的首选。Hugging Face 拥有一个模型中心,工程师可以下载预先训练的模型并分享他们自己创建的模型。Hugging Face 还是 Transformers 和 Datasets 库的作者,这两个库与大型语言模型 (LLM) 以及用于训练和微调它们的数据一起使用。
还有其他模型中心。所有主要的云供应商都有上传和共享模型的方法,但 Hugging Face 凭借其模型和库集合,已成为该领域的领导者。
应用程序框架有助于将 LLM 整合到应用程序中。使用 LLM 与使用标准 API 不同。必须做大量工作才能将用户请求转换为 LLM 可以理解和处理的内容。例如,如果您构建了一个聊天应用程序并且想要使用检索增强生成 (RAG),那么您将需要对请求进行标记化,将标记转换为向量,与向量数据库集成(如下所述),创建提示,然后调用您的 LLM。生成式 AI 的应用程序框架将允许您将这些操作链接在一起。当今使用最广泛的应用程序框架是 LangChain。它与其他技术集成,例如 Hugging Face Transformer 库和 Unstructured 的文档处理库。它功能丰富,使用起来可能有点复杂,因此下面列出了一些替代方案,适合那些没有复杂要求并想要比 LangChain 更简单的东西的人。
大多数组织都没有一个包含干净准确文档的单一存储库。相反,文档以多种格式分散在整个组织的各个团队门户中。为生成式 AI 做好准备的第一步是构建一个管道,该管道仅接受已获准用于生成式 AI 的文档并将其放置在矢量数据库中。对于大型全球组织来说,这可能是生成式 AI 解决方案最艰巨的任务。
文档管道应该将文档转换为文本,对文档进行分块,并通过嵌入模型运行分块后的文本,以便将其向量表示保存到向量数据库中。幸运的是,一些开源库可以为许多常见的文档格式执行此操作。下面列出了一些库。这些库可以与 LangChain 一起使用,以构建完整的文档处理管道。
向量数据库有助于语义搜索。理解语义搜索需要大量的数学背景知识,而且很复杂。但是,语义搜索在概念上很容易理解。假设您想查找所有讨论与“人工智能”相关的文档。要在传统数据库中执行此操作,您需要搜索“人工智能”的所有可能的缩写、同义词和相关术语。您的查询将如下所示:
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 ...
这种手动相似性搜索不仅费力且容易出错,而且搜索本身也非常缓慢。矢量数据库可以接受类似下面的请求,并以更快、更准确的速度运行查询。如果您希望使用检索增强生成,那么快速准确地运行语义查询的能力非常重要。
{ Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }
下面列出了四种流行的矢量数据库。
拥有一些工具来处理数据并以不同的方式对其进行可视化总是一个好主意。下面列出的 Python 库提供了数据处理和可视化功能。这些工具可能看起来像是传统 AI 才需要的工具,但它们在生成 AI 中也很有用。例如,如果您正在进行情绪分析或情绪检测,那么您应该检查您的训练、验证和测试集,以确保您在所有类别中都有适当的分布。
以上就是:现代数据湖参考架构中可以找到的 10 种功能,以及每种功能的具体供应商产品和库。下表总结了这些工具。