現(xiàn)代數(shù)據(jù)湖參考架構(gòu)中可以找到的這 10 項功能，以及每個功能的供應(yīng)商工具和庫。

譯自The Architect’s Guide to the GenAI Tech Stack — 10 Tools，作者 Keith Pijanowski。

我之前寫過關(guān)于現(xiàn)代數(shù)據(jù)湖參考架構(gòu)，解決了每個企業(yè)面臨的挑戰(zhàn) — 更多數(shù)據(jù)、老化的 Hadoop 工具（特別是 HDFS）以及對 RESTful API（S3）和性能的更大需求 — 但我想填補一些空白。

現(xiàn)代數(shù)據(jù)湖，有時稱為數(shù)據(jù)湖倉，一半是數(shù)據(jù)湖，一半是基于開放表格式規(guī)范 (OTF) 的數(shù)據(jù)倉庫。兩者都建立在現(xiàn)代對象存儲之上。

同時，我們深入思考了組織如何構(gòu)建 AI 數(shù)據(jù)基礎(chǔ)設(shè)施，以支持所有 AI/ML 需求 — 不僅僅是訓(xùn)練集、驗證集和測試集的原始存儲。換句話說，它應(yīng)該包含訓(xùn)練大型語言模型、MLOps 工具、分布式訓(xùn)練等所需的計算能力。

基于這一思路，我們撰寫了另一篇關(guān)于如何使用現(xiàn)代數(shù)據(jù)湖參考架構(gòu)來支持 AI/ML需求的論文。下圖展示了現(xiàn)代數(shù)據(jù)湖參考架構(gòu)，其中突出了生成式 AI 所需的功能。

來源：現(xiàn)代數(shù)據(jù)湖中的 AI/ML

這兩篇論文都沒有提到特定的供應(yīng)商或工具。我現(xiàn)在想討論構(gòu)建現(xiàn)代數(shù)據(jù)湖所需的供應(yīng)商和工具。在這個前 10 名單中，每個條目都是支持生成式 AI 所需的功能。

1. 數(shù)據(jù)湖

企業(yè)數(shù)據(jù)湖建立在對象存儲之上。不是你老式的基于設(shè)備的對象存儲，它服務(wù)于廉價且深入的歸檔用例，而是現(xiàn)代的、高性能的、軟件定義的和 Kubernetes 原生的對象存儲，這是現(xiàn)代 GenAI 堆棧的基石。它們可用作服務(wù)（AWS，MicrosoftAzure）或本地或混合/兩者，例如 MinIO。

這些數(shù)據(jù)湖必須支持流式工作負(fù)載，必須具有高效的加密和糾刪碼，需要以原子方式將元數(shù)據(jù)與對象一起存儲，并支持 Lambda 計算等技術(shù)。鑒于這些現(xiàn)代替代方案是云原生的，它們將與其他云原生技術(shù)的整個堆棧集成 — 從防火墻到可觀察性再到用戶和訪問管理 — 開箱即用。

2. 基于 OTF 的數(shù)據(jù)倉庫

對象存儲也是基于 OTF 的數(shù)據(jù)倉庫的基礎(chǔ)存儲解決方案。將對象存儲用于數(shù)據(jù)倉庫聽起來可能很奇怪，但以這種方式構(gòu)建的數(shù)據(jù)倉庫代表了下一代數(shù)據(jù)倉庫。這得益于 Netflix、Uber 和 Databricks 編寫的 OTF 規(guī)范，它使在數(shù)據(jù)倉庫中無縫使用對象存儲成為可能。

OTF — Apache Iceberg、Apache Hudi 和 Delta Lake — 的編寫是因為市場上沒有能夠滿足創(chuàng)建者數(shù)據(jù)需求的產(chǎn)品。從本質(zhì)上講，它們（以不同的方式）所做的就是定義一個可以構(gòu)建在對象存儲之上的數(shù)據(jù)倉庫。對象存儲提供了其他存儲解決方案無法提供的可擴展容量和高性能的組合。

由于這些是現(xiàn)代規(guī)范，因此它們具有舊式數(shù)據(jù)倉庫所沒有的高級功能，例如分區(qū)演進(jìn)、模式演進(jìn)和零拷貝分支。

可以在 MinIO 上運行其基于 OTF 的數(shù)據(jù)倉庫的兩個 MinIO 合作伙伴是 Dremio 和 Starburst。

• Dremio Sonar（數(shù)據(jù)倉庫處理引擎）
• Dremio Arctic（數(shù)據(jù)倉庫目錄）
• 開放數(shù)據(jù)湖倉 | Starburst（目錄和處理引擎）

3. 機器學(xué)習(xí)運維 (MLOps)

MLOps 對機器學(xué)習(xí)來說就像 DevOps 對傳統(tǒng)軟件開發(fā)一樣。兩者都是旨在改善工程團隊（開發(fā)或機器學(xué)習(xí)）和 IT 運維（運維）團隊之間協(xié)作的一組實踐和原則。目標(biāo)是使用自動化簡化開發(fā)生命周期，從規(guī)劃和開發(fā)到部署和運維。這些方法的主要好處之一是持續(xù)改進(jìn)。

MLOps 技術(shù)和功能不斷發(fā)展。您需要一個由主要參與者支持的工具，以確保該工具不斷開發(fā)和改進(jìn)，并提供長期支持。這些工具中的每一個都在底層使用 MinIO 來存儲模型生命周期中使用的工件。

• MLRun (Iguazio, acquired by McKinsey & Company)
• MLflow (Databricks)
• Kubeflow (Google)

4. 機器學(xué)習(xí)框架

您的機器學(xué)習(xí)框架是您用來創(chuàng)建模型并編寫訓(xùn)練它們代碼的庫（通常用于 Python）。這些庫功能豐富，因為它們提供了一系列不同的損失函數(shù)、優(yōu)化器、數(shù)據(jù)轉(zhuǎn)換工具和神經(jīng)網(wǎng)絡(luò)的預(yù)構(gòu)建層。這兩個庫提供的最重要的功能是張量。張量是可以移動到 GPU 上的多維數(shù)組。它們還具有自動微分，用于模型訓(xùn)練。

當(dāng)今最流行的兩個機器學(xué)習(xí)框架是 PyTorch（來自 Facebook）和 Tensorflow（來自 Google）。

• PyTorch
• TensorFlow

5. 分布式訓(xùn)練

分布式模型訓(xùn)練是在多個計算設(shè)備或節(jié)點上同時訓(xùn)練機器學(xué)習(xí)模型的過程。這種方法可以加快訓(xùn)練過程，尤其是在需要大型數(shù)據(jù)集來訓(xùn)練復(fù)雜模型時。

在分布式模型訓(xùn)練中，數(shù)據(jù)集被分成較小的子集，每個子集由不同的節(jié)點并行處理。這些節(jié)點可以是集群中的各個機器、各個進(jìn)程或 Kubernetes 集群中的各個 Pod。它們可能可以訪問 GPU。每個節(jié)點獨立處理其數(shù)據(jù)子集并相應(yīng)地更新模型參數(shù)。以下五個庫使開發(fā)人員免受分布式訓(xùn)練的大部分復(fù)雜性影響。如果您沒有集群，可以在本地運行它們，但您需要一個集群才能看到訓(xùn)練時間顯著減少。

• DeepSpeed（來自 Microsoft）
• Horovod（來自 Uber）
• Ray（來自 Anyscale）
• Spark PyTorch Distributor（來自 Databricks）
• Spark TensorFlow Distributor（來自 Databricks）

6. 模型中心

模型中心實際上并不是現(xiàn)代數(shù)據(jù)湖參考架構(gòu)的一部分，但我還是將其包括在內(nèi)，因為它對于快速入門生成式 AI 非常重要。Hugging Face 已成為獲取大型語言模型的去處。Hugging Face 托管著一個模型中心，工程師可以在其中下載預(yù)訓(xùn)練模型并分享他們自己創(chuàng)建的模型。Hugging Face 也是 Transformers 和 Datasets 庫的作者，這些庫與大型語言模型 (LLM) 及用于訓(xùn)練和微調(diào)它們的數(shù)據(jù)配合使用。

還有其他模型中心。所有主要的云供應(yīng)商都有一些上傳和共享模型的方法，但 Hugging Face 憑借其模型和庫集合已成為該領(lǐng)域的領(lǐng)導(dǎo)者。

• Hugging Face

7. 應(yīng)用程序框架

應(yīng)用程序框架有助于將 LLM 納入應(yīng)用程序。使用 LLM 與使用標(biāo)準(zhǔn) API 不同。必須做大量工作才能將用戶請求轉(zhuǎn)換為 LLM 可以理解和處理的內(nèi)容。例如，如果您構(gòu)建了一個聊天應(yīng)用程序，并且您想使用檢索增強生成 (RAG)，那么您需要對請求進(jìn)行標(biāo)記化，將標(biāo)記轉(zhuǎn)換為向量，與向量數(shù)據(jù)庫（如下所述）集成，創(chuàng)建一個提示，然后調(diào)用您的 LLM。生成式 AI 的應(yīng)用程序框架將允許您將這些操作鏈接在一起。

當(dāng)今使用最廣泛的應(yīng)用程序框架是 LangChain。它與其他技術(shù)集成，例如 Hugging Face Transformer 庫和 Unstructured 的文檔處理庫。它功能豐富，使用起來可能有點復(fù)雜，因此下面列出了一些替代方案，供那些沒有復(fù)雜要求且希望比 LangChain 更簡單的東西的人使用。

• LangChain
• AgentGPT
• Auto-GPT
• BabyAGI
• Flowise
• GradientJ
• LlamaIndex
• Langdock
• TensorFlow (Keras API)

8. 文檔處理

大多數(shù)組織沒有一個包含干凈準(zhǔn)確文檔的單一存儲庫。相反，文檔分散在組織的各個團隊門戶中，采用多種格式。為生成式 AI 做準(zhǔn)備時的第一步是構(gòu)建一個流水線，該流水線僅獲取已批準(zhǔn)與生成式 AI 一起使用的文檔，并將它們放入您的向量數(shù)據(jù)庫中。對于大型全球組織來說，這可能是生成式 AI 解決方案最困難的任務(wù)。

圖片

文檔流水線應(yīng)將文檔轉(zhuǎn)換為文本，對文檔進(jìn)行分塊，并將分塊文本通過嵌入模型運行，以便可以將它的向量表示保存到向量數(shù)據(jù)庫中。幸運的是，一些開源庫可以針對許多常見文檔格式執(zhí)行此操作。下面列出了一些庫。這些庫可以與 LangChain 一起使用來構(gòu)建完整的文檔處理流水線。

• Unstructured
• Open-Parse

9. 向量數(shù)據(jù)庫

向量數(shù)據(jù)庫促進(jìn)了語義搜索。理解如何做到這一點需要大量的數(shù)學(xué)背景，并且很復(fù)雜。然而，語義搜索在概念上很容易理解。假設(shè)您想找到所有討論與“人工智能”相關(guān)的任何內(nèi)容的文檔。要在傳統(tǒng)數(shù)據(jù)庫上執(zhí)行此操作，您需要搜索“人工智能”的所有可能的縮寫、同義詞和相關(guān)術(shù)語。您的查詢看起來像這樣：

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 ...

這種手動相似性搜索不僅艱巨且容易出錯，而且搜索本身也非常緩慢。向量數(shù)據(jù)庫可以接受如下請求，并更快、更準(zhǔn)確地運行查詢。如果您希望使用檢索增強生成，那么快速準(zhǔn)確地運行語義查詢的能力非常重要。

{
Get {
	MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) 
      {snippet}
    }
}

下面列出了四個流行的向量數(shù)據(jù)庫：

• Milvus
• Pgvector
• Pinecone
• Weaviate

10. 數(shù)據(jù)探索和可視化

擁有允許您整理數(shù)據(jù)并以不同方式對其進(jìn)行可視化的工具始終是一個好主意。下面列出的 Python 庫提供了數(shù)據(jù)處理和可視化功能。這些看起來像是您僅在傳統(tǒng) AI 中需要的工具，但它們在生成式 AI 中也很有用。例如，如果您正在進(jìn)行情緒分析或情感檢測，那么您應(yīng)該檢查您的訓(xùn)練、驗證和測試集，以確保您在所有類別中都有適當(dāng)?shù)姆植肌?/p>

• Pandas
• Matplotlib
• Seaborn
• Streamlit

結(jié)論

您已經(jīng)了解了十種功能，這些功能可以在現(xiàn)代數(shù)據(jù)湖參考架構(gòu)中找到，以及針對每種功能的具體供應(yīng)商產(chǎn)品和庫。下面是一個總結(jié)這些工具的表格：