架构师的AI/ML数据湖参考架构指南
组织不应只建立专门用于人工智能的基础设施，而让数据分析和数据科学等工作自生自灭。
译自 Architect’s Guide to a Reference Architecture for an AI/ML Data Lake，作者 Keith Pijanowski。
在企业人工智能中，有两种主要类型的模型：判别式和生成式。判别式模型用于对数据进行分类或预测，而生成式模型用于创建新数据。尽管生成式 AI 近来占据新闻头条，但企业仍在追求这两种类型的 AI。
判别式 AI 对于希望更有效地运营并追求额外收入流的企业来说仍然是一项重要的举措。这些不同类型的 AI 有很多共同点，但在构建 AI 数据基础设施时必须考虑重大差异。
企业不应只构建专门用于 AI 的基础设施，而让数据分析和数据科学等工作自生自灭。构建一个完整的数据基础设施是可能的，该基础设施支持组织的所有需求——数据分析、数据科学、判别式 AI 和生成式 AI。
现代数据湖
让我们从定义一个现代数据湖开始，因为这将作为我们参考架构的基础。此架构并非“回收”的；相反，它反映了广泛适用的工程优先原则。
现代数据湖一半是数据仓库，一半是数据湖，并且对所有内容都使用对象存储。将对象存储用于数据湖非常有意义，因为对象存储适用于非结构化数据，而数据湖就是用来存储非结构化数据的。
然而，虽然将对象存储用于数据仓库听起来可能很奇怪，但以这种方式构建的数据仓库代表了下一代数据仓库。这得益于 Netflix、Uber 和 Databricks 编写的开放表格式规范 (OTF)，它使在数据仓库中无缝使用对象存储成为可能。
OTF 是 Apache Iceberg、Apache Hudi 和 Delta Lake。从本质上讲，它们以不同的方式定义了可以在对象存储之上构建的数据仓库。对象存储提供了其他存储解决方案无法比拟的规模和性能的组合。（这通常被称为“规模化性能”。）
由于这些是现代规范，因此它们具有旧式数据仓库所没有的高级功能，例如分区演进、模式演进和零拷贝分支。
最后，由于数据仓库是 使用对象存储构建的，因此你可以将同一对象存储用于图像、视频文件、音频文件和文档等非结构化数据。MLOps 工具将使用同一对象存储用于模型检查点、日志文件和数据集。非结构化数据通常存储在业界称为数据湖中。
将对象存储用作数据湖和数据仓库的基础，可以得到一个能够容纳所有数据的解决方案。结构化存储驻留在基于 OTF 的数据仓库中，非结构化存储驻留在数据湖中。对象存储的同一实例可用于两者。
在 MinIO，我们将这种基于 OTF 的数据仓库和数据湖的组合称为现代数据湖，我们将其视为所有 AI 和 ML 工作负载的基础。这是收集、存储、处理和转换数据的地方。使用判别式 AI（监督式、无监督式和强化学习）训练模型通常需要一个能够处理可以驻留在数据仓库中的结构化数据的存储解决方案。
另一方面，如果你正在训练 大型语言模型 (LLM)，则必须在数据湖中以原始和处理过的形式管理非结构化数据或文档。
来源：现代数据湖参考架构
这篇文章重点介绍了现代数据湖参考架构中支持不同 AI 和 ML 工作负载的那些领域——特别是判别式 AI 和生成式 AI。
判别式 AI
判别式 AI 模型需要各种类型的数据进行训练。图像分类和语音识别的模型将以图像和音频文件形式使用非结构化数据。另一方面，欺诈检测和医疗诊断的模型根据结构化数据进行预测。让我们看看现代数据湖中可用于存储和处理判别式 AI 所需数据的选项。
非结构化数据的存储
非结构化数据将驻留在数据湖中，在那里可用于训练和测试模型。可以放入内存的训练集可以在训练之前加载（在 epoch 循环开始之前）。但是，如果训练集很大且无法放入内存，则必须在训练之前加载对象列表，并在 epoch 循环中处理每个批次时检索实际对象。如果你没有使用高速网络和高速磁盘驱动器构建数据湖，这可能会给你的数据湖带来压力。
如果你正在使用无法放入内存的数据训练模型，那么我们强烈建议使用 100 GB 网络和非易失性存储器 (NVMe) 驱动器构建数据湖。
半结构化数据的存储
在现代数据湖中，有几个选项可用于存储半结构化文件，如 Parque、AVRO、JSON 甚至 CSV 文件。最简单的方法是将它们存储在数据湖中，并以与加载非结构化对象相同的方式加载它们。如果这些半结构化文件中的数据不被现代数据湖支持的其他工作负载（数据分析和数据科学）需要，这是最佳选择。
另一个选择是将这些文件加载到数据仓库中，其他工作负载可以在其中使用它们。当数据加载到数据仓库中时，你可以使用 零拷贝分支来执行实验。
数据仓库中的零拷贝分支
特征工程是一种用于改进用于训练模型的数据集的技术。基于 OTF 的数据仓库包括一个非常简洁的功能，称为零拷贝分支。这允许以在 git 存储库中分支代码相同的方式分支数据。顾名思义，此功能不会复制数据。相反，它使用用于实现数据仓库的开放表格式的元数据层来创建数据唯一副本的外观。
数据科学家可以对分支进行实验；如果他们的实验成功，那么他们可以将他们的分支合并回主分支供其他数据科学家使用。如果实验不成功，则可以删除该分支。
生成式 AI
所有模型，无论是使用 Scikit-Learn 构建的小模型、使用 PyTorch 或 TensorFlow 构建的自定义神经网络，还是基于 transformer 架构的大语言模型，都需要数字作为输入并产生数字作为输出。这对你用于生成式 AI 的数据基础设施提出了额外要求，其中单词必须转换为数字（或向量，我们稍后会看到）。
如果你想使用包含公司专有知识的私有文档来增强 LLM 产生的答案，那么基于生成式 AI 的解决方案会变得更加复杂。这种增强可以是检索增强生成或 LLM 微调的形式。
本节将讨论所有这些技术（将单词转换为数字、RAG 和微调）及其对 AI 数据基础设施的影响。让我们首先讨论如何构建自定义语料库以及它应该驻留在哪里。
使用向量数据库创建自定义语料库
如果你认真对待生成式 AI，那么你的自定义语料库应该定义你的组织。它应该包含其他人没有的知识文档，并且只应包含真实准确的信息。此外，你的自定义语料库应该使用向量数据库构建。向量数据库索引、存储并提供对文档及其向量嵌入的访问，向量嵌入是文档的数字表示。（这解决了上面描述的数字问题。）
向量数据库促进语义搜索。了解如何做到这一点需要大量的数学背景，并且很复杂。但是，语义搜索在概念上很容易理解。假设你想要查找讨论与人工智能相关的任何内容的所有文档。要在传统数据库上执行此操作，你需要搜索“人工智能”的每个可能的缩写、同义词和相关术语。你的查询看起来像这样：
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}
}
} 对于您的自定义语料库，安全性是另一个重要考虑因素。访问文档应遵守原始文档的访问限制。（如果实习生可以访问尚未向华尔街发布的首席财务官财务结果，那将非常不幸。）在您的向量数据库中，您应该设置授权以匹配原始内容的访问级别。这可以通过将您的向量数据库与您组织的身份和访问管理解决方案集成来完成。
从本质上讲，向量数据库存储非结构化数据。因此，它们应该使用您的数据湖作为其存储解决方案。
构建文档流水线
不幸的是，大多数组织没有一个包含干净准确文档的单一存储库。相反，文档以多种格式分散在组织的各个团队门户中。因此，构建自定义语料库的第一步是构建一个管道，该管道仅获取已批准与生成式 AI 一起使用的文档，并将它们放入您的向量数据库中。对于大型全球组织而言，这可能是生成式 AI 解决方案最艰巨的任务。
团队在其门户中以草稿格式拥有文档很常见。还可能有一些文档是对可能性的随机思考。这些文档不应成为自定义语料库的一部分，因为它们不能准确地代表业务。不幸的是，过滤这些文档将是一项手动工作。
文档管道还应将文档转换为文本。幸运的是，一些开源库可以针对许多常见文档格式执行此操作。此外，文档管道必须在将文档保存在向量数据库中之前将文档分解成小段。这是因为当这些文档用于检索增强生成（将在后面的章节中讨论）时，提示大小受到限制。
微调大型语言模型
当我们微调大型语言模型时，我们会使用自定义语料库中的信息对其进行更多训练。这可能是获得特定于领域的 LLM 的好方法。虽然此选项确实需要计算资源来针对您的自定义语料库执行微调，但它不像从头开始训练模型那样密集，并且可以在适度的时限内完成。
如果您的领域包括日常用语中找不到的术语，则微调可能会提高 LLM 响应的质量。例如，使用医学研究、环境研究和任何与自然科学相关的文档的项目可能会受益于微调。微调采用文档中发现的高度特定的语言，并将其融入模型的参数参数中。在决定采用此方法之前，应了解微调的优点和缺点。
缺点
- 微调需要计算资源。
- 无法解释。
- 随着语料库的发展，您需要定期使用新数据再次进行微调。
- 幻觉是一个问题。
- 文档级安全性是不可能的。
优点
- LLM 通过微调从您的自定义语料库中获取知识。
- 推理流程比 RAG 不那么复杂。
虽然微调是教 LLM 了解您的业务语言的好方法，但它会稀释数据，因为大多数 LLM 包含数十亿个参数，并且您的数据将分布在所有这些参数中。微调的最大缺点是文档级授权是不可能的。一旦文档用于微调，其信息就会成为模型的一部分。不可能根据用户的授权级别限制此信息。
让我们来看看一种在推理时将您的自定义数据和参数数据相结合的技术。
检索增强生成 (RAG)
检索增强生成 (RAG) 是一种从所问问题开始的技术。它使用向量数据库将问题与附加数据匹配，然后将问题和数据传递给 LLM 以进行内容创建。使用 RAG，不需要培训，因为我们通过向 LLM 发送来自我们高质量文档语料库的相关文本片段来对其进行教育。
它使用一个问答任务，其工作原理如下：用户在您应用程序的用户界面中提出问题。您的应用程序将获取问题——特别是其中的单词——并使用向量数据库，在您高质量文档的语料库中搜索在上下文上相关的文本片段。这些片段和原始问题将被发送到 LLM。 提示
整个包——问题加片段（上下文）——称为提示。LLM 将使用此信息生成您的答案。这看起来似乎是一件愚蠢的事情。如果您已经知道答案（片段），为什么还要费心使用 LLM？请记住，这是实时发生的，目标是生成您可以复制并粘贴到研究中的文本。您需要 LLM 来创建包含来自自定义语料库信息的文本。
这比微调复杂。但是，由于在推理时从向量数据库中选择了文档（或文档片段），因此可以实现用户授权。文档中的信息永远不会成为模型参数参数的一部分。RAG 的优缺点如下。
缺点
- 推理流程更复杂。
优点
- LLM 直接从您的自定义语料库中获取知识。
- 可以解释。
- 无需微调。
- 幻觉显着减少，并且可以通过检查向量数据库查询的结果来控制。
- 可以实现授权。
结论
这篇文章概述了我们在与企业合作构建 AI 数据基础设施方面的经验。它确定了核心组件、关键构建模块和不同 AI 方法的权衡。基础元素是建立在对象存储之上的现代数据湖。对象存储必须能够大规模提供性能，其中规模为数百 PB，通常为 EB。