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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

盡管我們已經(jīng)有了一些探索，例如《大模型應(yīng)用的10個(gè)架構(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ī)則模式
• 知識圖譜模式
• 智能體蜂巢模式
• 智能體組合模式
• 記憶認(rèn)知模式
• 雙重安全模式

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

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

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

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

常見的評估指標(biāo)包括：

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

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

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

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

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

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

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

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

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

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

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

一句話小結(jié)

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