當(dāng)然,絕大部分企業(yè)或者機(jī)構(gòu)都不會(huì)太需要自己去訓(xùn)練一個(gè)私有化的大模型,但是即使是做一個(gè)簡單的 RAG(Retrieval-Augmented Generation)系統(tǒng),我們也需要一個(gè)完整的文檔處理流水線來持續(xù)轉(zhuǎn)換文檔,劃分文檔為合適的文本塊,選擇合適的 embedding model 和向量數(shù)據(jù)庫,然后使用 prompt engineering 來構(gòu)建合理的問題提交給大模型。

在目前來說,類似于 LlamaIndex 或者?LangChain?的工具在使用集成的第三方 API 或者內(nèi)嵌的數(shù)據(jù)庫來實(shí)現(xiàn)快速原型是很方便的,但是如果我們想嘗試獨(dú)立的 embedding 模型,高速的分布式向量數(shù)據(jù)庫,定制化的文檔劃分策略,或者是細(xì)分的權(quán)限管理,還是有很多額外的工作要處理。

除了基礎(chǔ)大模型之外,大模型生態(tài)系統(tǒng)中用來建設(shè)一個(gè)模型流水線的工具組件可以分為兩大類:

第一類是作為第三方庫被其它應(yīng)用調(diào)用,從最底層的 CUDA,PyTorch,Pandas, 到中間的各種 tokenizer, quantization, 到上層的 Transformers, Adapters 等等。

第二類一般是作為建設(shè)一個(gè)完整模型流水線時(shí)的一個(gè)應(yīng)用組件,可以獨(dú)立運(yùn)行并完成特定的任務(wù)。

當(dāng)然,有些開源系統(tǒng)兩種使用形式都存在,例如向量數(shù)據(jù)庫,很多既可以獨(dú)立運(yùn)行,又可以作為一個(gè)內(nèi)嵌的組件供應(yīng)用使用。作為最終模型流水線的搭建者來講,我們直接打交道的大部分是第二類應(yīng)用組件類型的工具,它們又會(huì)去調(diào)用很多第一類的第三方庫來完成自己的工作。下面列出了一些常用的應(yīng)用組件類別以及其代表性開源組件。

1. Model Serving

模型服務(wù)工具,將訓(xùn)練好的模型部署為可供應(yīng)用程序使用的服務(wù)。這些工具通常提供 API 接口,允許開發(fā)者輕松地將模型集成到現(xiàn)有的系統(tǒng)中,支持高并發(fā)請求,確保模型的響應(yīng)速度和穩(wěn)定性。

2. Training Framework

訓(xùn)練框架,提供了工具和 API 來簡化大規(guī)模模型的訓(xùn)練過程。這些框架優(yōu)化了數(shù)據(jù)處理、模型構(gòu)建、訓(xùn)練循環(huán)和資源管理等過程,使得開發(fā)者可以更專注于模型的設(shè)計(jì)和實(shí)驗(yàn)。

3. Scheduling and Orchestration

調(diào)度工具,將模型運(yùn)行在云上或者分布式集群中。

4. Document Processing

文檔處理工具,專注于從非結(jié)構(gòu)化數(shù)據(jù)中提取信息和結(jié)構(gòu),如從 PDF、圖片或文本文件中提取文本內(nèi)容和元數(shù)據(jù)。

5. VectorDB

向量數(shù)據(jù)庫,專門用于存儲(chǔ)和檢索向量數(shù)據(jù),主要用于實(shí)現(xiàn)基于相似性搜索和 RAG 系統(tǒng)中。

6. Application Framework

應(yīng)用框架,提供了構(gòu)建特定應(yīng)用程序的基礎(chǔ)設(shè)施和組件,如語言模型的索引和檢索、聊天機(jī)器人的對話管理等。

7. Finetune

微調(diào)工具,允許開發(fā)者在特定的數(shù)據(jù)集上調(diào)整預(yù)訓(xùn)練模型的參數(shù),以提高模型在特定任務(wù)上的表現(xiàn)。

8. RAG: RAG(Retrieval-AugmentedGeneration)

是一種結(jié)合了檢索和生成的技術(shù),用于提高語言模型在特定任務(wù)上的表現(xiàn),如問答和文本生成。

9. ChatBot

集成聊天機(jī)器人,專注于構(gòu)建和部署交互式對話系統(tǒng),一般提供對話管理、提示詞工程管理、歷史管理的功能。

然而,使用這個(gè)生態(tài)系統(tǒng)搭建模型流水線的一個(gè)主要挑戰(zhàn)是管理和維護(hù)各種依賴項(xiàng)的兼容性,包括 Python 版本、第三方庫版本、CUDA 版本以及硬件和操作系統(tǒng)的兼容性。這些因素共同構(gòu)成了一個(gè)復(fù)雜的環(huán)境,經(jīng)常導(dǎo)致版本沖突和不兼容的情況。

此外,如何將各個(gè)組件的配置統(tǒng)一管理起來,不用重復(fù)配置,不用手動(dòng)配置各種端口以避免沖突,動(dòng)態(tài)管理依賴,也是常見需要解決的問題。除了應(yīng)用運(yùn)行之外,數(shù)據(jù)在這些組件之間的流動(dòng)也需要完善的管理以保證數(shù)據(jù)的正確性以及數(shù)據(jù)任務(wù)的及時(shí)完成。這些問題聽起來是不是有些熟悉呢?

是的,這些問題其實(shí)還是屬于傳統(tǒng)數(shù)據(jù)流水線(Data Pipeline)和運(yùn)維(DataOps)的范疇,只不過多了幾個(gè)特定功能場景:使用 GPU 或者 CPU 來發(fā)布大模型,用 sequence 數(shù)據(jù)(大部分是文檔)來 finetune, pretrain 大模型,或者用大模型來進(jìn)行 inference 服務(wù)或者以 agent 形式提供自動(dòng)操作。

在 A16Z 的“Emerging Architectures for LLM Applications”博客中列出的大模型應(yīng)用技術(shù)棧中,除了 Data Pipelines 本身就屬于這個(gè)技術(shù)棧的一部分之外,類似 Embedding Model, Vector DB, Logging/Observability, Orchestration 這些組件,其實(shí)和 DataOps 中相應(yīng)的組件的管理運(yùn)營方式差別不大,特別是在云原生和容器化這個(gè)方向上,基本是一致的。

所以,我們認(rèn)為,將這些組件以容器的形式實(shí)現(xiàn)標(biāo)準(zhǔn)化發(fā)布(上面的組件中很多都已經(jīng)提供 Docker 發(fā)布方式),使用類似于 Kubernetes 這樣的資源調(diào)度平臺(tái)來管理這些組件的運(yùn)行,可以大大降低大模型流水線的使用門檻,提高大模型應(yīng)用發(fā)布和運(yùn)行的效率。

而且,不管后端的基礎(chǔ)大模型如何變化,這樣建設(shè)流水線的工作都是需要的甚至我們可以說,為了適應(yīng)快速迭代的基礎(chǔ)大模型,我們應(yīng)該以云原生,容器化,服務(wù)化,標(biāo)準(zhǔn)化的方式建設(shè)我們的大模型流水線,允許我們在不同的私有發(fā)布,公有發(fā)布的大模型之間隨意切換,選擇最適合我們應(yīng)用場景和和價(jià)格最合適的大模型使用模式。

我們將會(huì)在”容器中的大模型”系列博客中,以不同的大模型應(yīng)用場景(例如 RAG,Text2SQL 等等)為例,展示如何以容器化的方式發(fā)布這些開源大模型應(yīng)用組件并合理地將它們組織起來來完成具體場景的工作。希望這些博客能為準(zhǔn)備建設(shè)大模型流水線的讀者提供一些參考,也非常期待大家的反饋和建議。

分享到

zhupb

相關(guān)推薦