ChatGPT從正式發(fā)布到擁有1億用戶僅僅用了5天的時間，基于大型語言模型（簡稱大模型，或基礎(chǔ)模型）的應(yīng)用給軟件行業(yè)乃至整個社會帶來巨大的影響。作為一名軟件系統(tǒng)的架構(gòu)師，除了傳統(tǒng)的軟件系統(tǒng)質(zhì)量屬性約束之外，還要面對由于大模型應(yīng)用的自身特點所帶來的新約束，面對更多的權(quán)衡，也面臨著更多的挑戰(zhàn)。

基于筆者近年來的探索與實踐，這里列舉了面向大模型應(yīng)用系統(tǒng)架構(gòu)設(shè)計的10個挑戰(zhàn)。

1. 生產(chǎn)環(huán)境的挑戰(zhàn)——推理框架的選擇

對于大模型應(yīng)用而言，生成環(huán)境的運行時是一個推理架構(gòu)。自主研發(fā)一個推理架構(gòu)需要的投入較大，而且需要專業(yè)人才，并不是每個企業(yè)都能夠做到的。這是第一架構(gòu)挑戰(zhàn)，選擇哪一種現(xiàn)有的推理框架呢？

當(dāng)批量提示詞的交付需要最大速度時，或許適合使用 vLLM。如果需要本地 HuggingFace 支持，并且不打算為核心模型使用多個適配器，或許TGI是個不錯的選擇。如果速度成為第一約束，并且計劃在 CPU 上運行推理，需要考慮 CTranslate2。如果希望將適配器連接到核心模型并利用 HuggingFace Agent， OpenLLM或許是個不錯的選擇，特別是不僅僅依賴于 PyTorch 的情況。對于希望相對成熟的項目，需要實現(xiàn)穩(wěn)定的流水線和靈活的部署，可以考慮使用 Ray Serve。如果在客戶端(邊緣計算)本機部署 LLM，例如，在 Android 或 iPhone 平臺上， MLC LLM會納入考量的范圍。如果已經(jīng)有使用 DeepSpeed-MII 庫的經(jīng)驗并且希望繼續(xù)使用它來部署 LLM， DeepSpeed-MII就成為了優(yōu)選。

架構(gòu)的核心在于權(quán)衡，推理框架的選擇同樣是一個架構(gòu)權(quán)衡的過程，沒有最好，需要關(guān)注合適于目標需求的推理框架

2. 數(shù)據(jù)依賴挑戰(zhàn)—— 數(shù)據(jù)流水線的構(gòu)建

數(shù)據(jù)是LLM開發(fā)的支柱，面向數(shù)據(jù)的有效管理對于開發(fā)準確可靠的大模型應(yīng)用至關(guān)重要。尤其是在需要對大模型進行微調(diào)或者蒸餾的時候，在構(gòu)建數(shù)據(jù)流水線時一些關(guān)鍵考慮因素包括：

• 準備和清洗數(shù)據(jù)：準備和清洗數(shù)據(jù)涉及將原始數(shù)據(jù)轉(zhuǎn)換成可用于LLM訓(xùn)練和推理的格式。這包括數(shù)據(jù)歸一化、特征工程和數(shù)據(jù)增強等任務(wù)。
• 確保數(shù)據(jù)質(zhì)量和一致性：確保數(shù)據(jù)高質(zhì)量和一致性對于開發(fā)準確的LLM模型至關(guān)重要。這涉及數(shù)據(jù)驗證和質(zhì)量控制措施，如異常值檢測和數(shù)據(jù)分析。
• 管理數(shù)據(jù)隱私和合規(guī)性：在處理敏感或個人數(shù)據(jù)時，數(shù)據(jù)隱私和合規(guī)性是必要的考慮因素。這包括實施數(shù)據(jù)安全措施，如加密和訪問控制，并遵守數(shù)據(jù)隱私法規(guī)，例如GDPR和《個保法》。

有效的數(shù)據(jù)管理需要數(shù)據(jù)科學(xué)家、工程師和利益相關(guān)者之間的協(xié)作，以確保數(shù)據(jù)清潔、可靠和合規(guī)的數(shù)據(jù)采集。投資于數(shù)據(jù)流水線的建設(shè)可以幫助簡化數(shù)據(jù)準備和驗證任務(wù)，并提高LLM模型的質(zhì)量。在需要對大模型進行微調(diào)或者蒸餾的時候， 數(shù)據(jù)流水線的構(gòu)建是一個依賴條件。

3. RAG應(yīng)用的挑戰(zhàn)——分塊向量化

將大文檔分割成較小的分塊是一項關(guān)鍵而復(fù)雜的任務(wù)，對RAG系統(tǒng)的性能有著重大的影響。一般地，RAG系統(tǒng)旨在通過將基于檢索的方法和基于生成的方法相結(jié)合，提高產(chǎn)出的質(zhì)量和相關(guān)性。有多種框架提供了文檔分塊方法，每種方法都有自己的優(yōu)點和典型用例。根據(jù)任務(wù)的具體要求，可以以多種方式來實現(xiàn)文本分塊，下面是針對不同需求分塊方法：

• 按字符分塊：此方法將文本分解為單個字符。它適用于需要細粒度文本分析的任務(wù)，例如字符級語言模型或某些類型的文本預(yù)處理。
• 按Token分塊：將文本分割成token，是自然語言處理中的一種標準方法。基于令牌的組塊對于文本分類、語言建模和其他依賴于token化輸入的 NLP 應(yīng)用程序等任務(wù)來說是必不可少的。
• 按段落分塊：按段落分段整理文本有助于維護文檔的整體結(jié)構(gòu)和流程。此方法適用于需要較大上下文的任務(wù)，如文檔摘要或內(nèi)容提取。
• 遞歸分塊：這涉及到重復(fù)地將數(shù)據(jù)分解成更小的塊，通常用于分層數(shù)據(jù)結(jié)構(gòu)。遞歸組塊有利于需要多級分析的任務(wù)，如主題建?；?qū)哟尉垲悺?/li>
• 語義分塊：根據(jù)意義而非結(jié)構(gòu)元素對文本進行分組對于需要理解數(shù)據(jù)上下文的任務(wù)至關(guān)重要。語義塊利用諸如句子嵌入等技術(shù)來確保每個塊代表一個連貫的主題或想法。
• 代理分塊：這種方法的重點是在識別和分組文本的基礎(chǔ)上增加參與的代理，如人或組織。它在信息抽取和實體識別任務(wù)中非常有用，因為理解不同實體之間的角色和關(guān)系非常重要。

在良好分塊的基礎(chǔ)上， 我們再選擇Embedding Model，HuggingFace的排行榜為我們提供了參考。

4. Agent應(yīng)用的挑戰(zhàn)——接口設(shè)計的語義化表達

在基于大模型的Agen應(yīng)用中，接口設(shè)計的語義化表達是其中的一個關(guān)鍵所在，也面臨諸多挑戰(zhàn)。以下是一些主要的挑戰(zhàn)：

• 多角色處理能力：Agent常常需要在不同任務(wù)中扮演多種角色，如代碼生成器、測試員等。這要求接口設(shè)計能夠靈活地適應(yīng)不同角色的需求，確保每種角色都能準確地理解和執(zhí)行其對應(yīng)的任務(wù)。
• 復(fù)雜輸入的處理：Agent感知需要接收并處理來自外部的多模態(tài)信息，這些輸入形式各異，且往往包含復(fù)雜的語義和結(jié)構(gòu)信息，如何將這些信息有效地轉(zhuǎn)換為適合LLM處理的嵌入向量不是一個簡單的任務(wù)。
• 幻覺問題的解決：由于訓(xùn)練數(shù)據(jù)的不完整或偏差，Agent也會產(chǎn)生幻覺，即輸出不存在的API或錯誤的代碼。這要求接口設(shè)計能夠具備一定的驗證和糾錯機制，以減少或避免這類問題的發(fā)生。
• 效率問題：在多Agent協(xié)作中，計算資源的需求和通信開銷可能會影響協(xié)作的效率和實時性。因此，接口設(shè)計需要考慮如何在保證功能完整性的同時，優(yōu)化計算資源的使用和降低通信開銷。
• 可解釋性問題：Agent系統(tǒng)的自主性和交互能力正在重新定義人機協(xié)作的模式。然而，為了確保用戶對Agent的信任和接受度，接口設(shè)計需要具備一定的可解釋性，即能夠清晰地展示Agent的決策過程和結(jié)果依據(jù)。

目前缺乏成熟的設(shè)計模式來指導(dǎo)Agent接口的設(shè)計，這也導(dǎo)致了不同開發(fā)者在構(gòu)建Agent系統(tǒng)時可能采用不同的接口標準和實現(xiàn)方式，從而增加了系統(tǒng)的復(fù)雜度和維護成本。

5. 安全性挑戰(zhàn)——不一樣的訪問控制

基于尺寸、復(fù)雜性和敏感數(shù)據(jù)的處理能力，LLM面臨著獨特的安全挑戰(zhàn)。為了確保LLM模型和數(shù)據(jù)的安全，需要考慮以下問題：

• 保護LLM模型和數(shù)據(jù)：這包括實施訪問控制、加密和安全數(shù)據(jù)存儲，以防止未經(jīng)授權(quán)的訪問LLM模型和數(shù)據(jù)。
• 審計LLM使用情況：重要的是要跟蹤誰在訪問LLM模型和數(shù)據(jù)以及為什么目的。這有助于檢測和防止LLM的未經(jīng)授權(quán)使用或濫用。
• 管理對LLM模型的訪問：需要確保只有經(jīng)過授權(quán)的用戶和應(yīng)用程序才能訪問LLM模型。這涉及設(shè)置身份驗證和授權(quán)機制，以及實施防火墻和網(wǎng)絡(luò)隔離。

另外， 提示詞注入攻擊也是一個不得不考慮的問題。

6. 開發(fā)范式的挑戰(zhàn)——提示詞管理

在很大程度上，大模型應(yīng)用是一種開發(fā)范式的轉(zhuǎn)變——面向提示詞的編程。基于AB測試，版本控制等方面的考量，這種開發(fā)方式面對的挑戰(zhàn)就是提示詞管理。

大模型應(yīng)用需要一個針對產(chǎn)品級大型語言模型的高效管理系統(tǒng)。這一系統(tǒng)致力于精確處理輸入至語言模型的各類查詢與指令，其運作機制可類比于數(shù)字圖書館的管理體系，只不過這里的“藏書”換成了一個個精心設(shè)計的提示詞。

從抽象視角來看，提示詞管理是一系列優(yōu)化實踐的集合，旨在提升應(yīng)用程序中大模型對提示的處理能力。其核心在于實現(xiàn)提示詞的版本控制，確保其與應(yīng)用程序的核心代碼及部署流程相分離，同時保證從請求的角度能夠輕松追蹤。鑒于多人協(xié)作在快速開發(fā)中的普遍性，提示詞管理系統(tǒng)還支持不同版本的并行開發(fā)與測試，確保這一過程不會干擾到生產(chǎn)環(huán)境的穩(wěn)定性。此框架為團隊成員提供了一個共享的工作空間，他們可以在此獨立地開展工作并對提示詞進行測試。

提示詞管理框架借鑒了傳統(tǒng)軟件開發(fā)的基本準則，并針對大模型應(yīng)用程序的獨特需求進行了適應(yīng)性調(diào)整，涵蓋了其他需要特別關(guān)注的“可編碼”元素。

另外，提示詞管理與提示詞工程略有不同。后者關(guān)注于創(chuàng)造性的設(shè)計提示詞以最大化每次與大模型交互的效率，涉及一系列獨特的實踐和原則。而前者則更側(cè)重于及時、高效的管理流程，與代碼或模型管理緊密相連，盡管聯(lián)系緊密，但二者在概念上仍有明顯區(qū)別。

7. 設(shè)計范式的挑戰(zhàn)——大模型應(yīng)用架構(gòu)模式的采用

在塑造新領(lǐng)域的過程中，我們往往依賴于一些經(jīng)過實踐驗證的策略、方法和模式。這種觀念對于軟件工程領(lǐng)域的專業(yè)人士來說，已經(jīng)司空見慣，設(shè)計模式已成為程序員們的重要技能。然而，當(dāng)我們轉(zhuǎn)向大模型應(yīng)用和人工智能領(lǐng)域，情況可能會有所不同。面對新興技術(shù)，例如生成式AI，我們尚缺乏成熟的設(shè)計模式來支撐這些解決方案。

盡管我們已經(jīng)有了一些探索，例如《大模型應(yīng)用的10個架構(gòu)模式》(https://mp.weixin.qq.com/s?__biz=MzAwOTcyNzA0OQ==&mid=2658978952&idx=1&sn=3dceab421afe0448f9b6ad190d586c41&chksm=80d351aeb7a4d8b8f3944343466d45708801af44fd5ddced1042b74f7140ba8a6a38f87a5550&scene=178&cur_album_id=2986642575455404032#rd)中所做出的總結(jié)：

• 路由分發(fā)模式
• 大模型代理模式
• 多任務(wù)微調(diào)模式
• 面向微調(diào)的分層緩存策略模式
• 混合規(guī)則模式
• 知識圖譜模式
• 智能體蜂巢模式
• 智能體組合模式
• 記憶認知模式
• 雙重安全模式

其中， 雙重安全模式也是解決安全性挑戰(zhàn)的一種應(yīng)對方式。圍繞大模型的核心安全性至少包含兩個關(guān)鍵組件：一是用戶組件，我們將其稱為用戶Proxy代理；二是防火墻，它為模型提供了保護層。用戶proxy代理在查詢發(fā)出和返回的過程中對用戶的query進行攔截。該代理負責(zé)清除個人身份信息和知識產(chǎn)權(quán)信息，記錄查詢的內(nèi)容，并優(yōu)化成本。防火墻則保護模型及其所使用的基礎(chǔ)設(shè)施。盡管我們對人們?nèi)绾尾倏v模型以揭示其潛在的訓(xùn)練數(shù)據(jù)、潛在功能以及當(dāng)今惡意行為知之甚少，但我們知道這些強大的模型是脆弱的。在安全性相關(guān)的技術(shù)棧中，可能還存在其他安全層，但對于用戶的查詢路徑來說，Proxy代理和防火墻是最關(guān)鍵的。

大模型應(yīng)用的架構(gòu)模式不僅僅是一種范式，很可能成為未來智能系統(tǒng)賴以成長的框架。隨著我們們繼續(xù)探索和創(chuàng)新，還會涌現(xiàn)出很多新的架構(gòu)模式。

8. 性能挑戰(zhàn)——如何評估大模型應(yīng)用

對 LLM 輸出進行評估對于驗證大模型應(yīng)用能否始終如一地產(chǎn)生高質(zhì)量的結(jié)果至關(guān)重要。關(guān)鍵在于準確性，確保 LLM 理解上下文并產(chǎn)生相關(guān)響應(yīng)，以及一致性，評估邏輯一致性。同時，相關(guān)性確保響應(yīng)有效地處理用戶查詢。然而，偏見和公平性檢查對于減少偏見和確保包容性至關(guān)重要。

常見的評估指標包括：

• Perplexity：當(dāng)一個模型按順序預(yù)測下一個單詞時，它的“困惑”或“混亂”的程度度量。
• BLEU：它通過比較機器生成的翻譯和基本事實來評估翻譯的準確性。
• ROUGE ：它通過與參考文獻摘要進行比較來評估 LLM 生成的文本摘要的質(zhì)量。
• WER：它通過比較系統(tǒng)生成的轉(zhuǎn)錄和人類轉(zhuǎn)錄來計算自動語音識別系統(tǒng)的準確性。
• MRR：幫助我們了解系統(tǒng)在尋找相關(guān)結(jié)果并將其置于最頂端方面的表現(xiàn)如何。
• BERTScore：使用一個預(yù)先訓(xùn)練好的 BERT 模型來評估與參考文本相比生成文本的質(zhì)量。它使用 BERT 嵌入來度量兩個文本之間的語義相似度。

評估工具的選擇同樣是一個挑戰(zhàn)，因為有各種各樣的開源和商業(yè)選擇，包括 OpenAI 評估、 Promptfoo、 BenchLLM、 RAGAS、 Deepcheck 和 Guardrails 等等。另外，為了確保準確性，人工評價者應(yīng)該包括在主觀評價任務(wù)中，如連貫性、語言流利性和內(nèi)容相關(guān)性。建議在不同的測試數(shù)據(jù)集和域上交叉驗證 LLM，以確保魯棒性和泛化性。

9. 適用性挑戰(zhàn)——大模型的應(yīng)用邊界

大模型在人工智能領(lǐng)域確實展現(xiàn)出了強大的能力，它們在各種控制平面和應(yīng)用場景中都發(fā)揮著重要作用。然而，盡管大模型的應(yīng)用范圍廣泛，但并不意味著它們是無所不能的。實際上，只有那些真正需要大模型來解決問題或?qū)崿F(xiàn)特定功能的場景，才能被稱為AI原生應(yīng)用。

當(dāng)我們設(shè)計系統(tǒng)架構(gòu)時，需要仔細考慮哪些場景或子系統(tǒng)與大模型相關(guān)。這意味著我們?nèi)匀恍枰钊肜斫鈽I(yè)務(wù)需求和技術(shù)挑戰(zhàn)，以確定是否真的需要引入大模型來解決問題。在某些情況下，傳統(tǒng)的機器學(xué)習(xí)算法或者規(guī)則引擎可能已經(jīng)足夠滿足需求，而無需使用復(fù)雜的大模型。

雖然大模型在人工智能領(lǐng)域具有廣泛的應(yīng)用前景，但并不是所有場景都適合使用大模型。在設(shè)計系統(tǒng)架構(gòu)時，我們需要根據(jù)具體需求和技術(shù)挑戰(zhàn)來判斷是否需要引入大模型，以確保系統(tǒng)的高效性和可靠性。

10. 運營挑戰(zhàn)——從devOps 到 LLMOps

DevOps是軟件工程效能的重要方法論以及工具集， 在人工智能領(lǐng)域同樣如此。

創(chuàng)建、部署和管理這些復(fù)雜的大模型應(yīng)用充滿了復(fù)雜性，包括需要大量的計算資源，管理大量的數(shù)據(jù)集，并遵守道德標準。解決這些挑戰(zhàn)需要一種稱為LLMOps的方法，是機器學(xué)習(xí)操作(MLOps)的一個關(guān)鍵子集，重點關(guān)注從開發(fā)到部署和持續(xù)管理的大模型應(yīng)用生命周期的流水線和自動化。LLMOps 通過結(jié)合“終身”學(xué)習(xí)擴展了 MLOps，使機器學(xué)習(xí)模型能夠隨著時間的推移不斷地從新數(shù)據(jù)中學(xué)習(xí)和改進，從而使數(shù)據(jù)快速變化的應(yīng)用程序受益。

實施LLMOps 的核心在于，定期監(jiān)控為分布式訓(xùn)練配置的性能指標，調(diào)整超參數(shù)、分區(qū)策略和通信設(shè)置以優(yōu)化性能，是提升訓(xùn)練效率的關(guān)鍵。實施模型的檢查點機制并在發(fā)生故障時進行有效的恢復(fù)，可以確保訓(xùn)練過程在無需從頭開始的情況下繼續(xù)進行。

另外， 大模型應(yīng)用的部署和運營操作需要一個復(fù)雜的框架來處理它們的復(fù)雜性和規(guī)模。自動化、編排和管道構(gòu)成了這個框架的主干，簡化了從數(shù)據(jù)準備到 LLMOps 景觀中的模型部署和監(jiān)控的每一步。

一句話小結(jié)

自從生成性人工智能成為焦點以來，基于大模型的應(yīng)用需求對架構(gòu)師帶來了一系列挑戰(zhàn)，包括推理框架選擇、數(shù)據(jù)流水線構(gòu)建、分塊向量化處理、接口設(shè)計語義化表達、安全性訪問控制、提示詞管理、架構(gòu)模式采用、性能評估方法、應(yīng)用邊界確定以及從DevOps向LLMOps的轉(zhuǎn)變。這些挑戰(zhàn)要求我們架構(gòu)上綜合考慮技術(shù)、安全和運營等多方面因素，以推動大模型應(yīng)用的落地。