拆解生成式AI平臺(tái)：基礎(chǔ)組件、功能及實(shí)現(xiàn)

始，并逐步添加更多組件。在最簡(jiǎn)單的形式中，應(yīng)用程序接收查詢(xún)并將其發(fā)送到模型。模型生成回答并將其返回給用戶(hù)。當(dāng)前形式下，沒(méi)有防護(hù)措施、增強(qiáng)上下文或優(yōu)化。模型API指的是第三方API（例如OpenAI、Google、Anthropic）和自托管的API。從這里開(kāi)始，可以根據(jù)需要添加更多組件。本文所討論的是常見(jiàn)順序，但你不必完全遵循。如果你的系統(tǒng)運(yùn)行良好，可以跳過(guò)某些組件。在開(kāi)發(fā)的每個(gè)步驟中，評(píng)估都是必要的。1.通過(guò)讓模型訪(fǎng)問(wèn)外部數(shù)據(jù)源和信下文。2.設(shè)置防護(hù)措施以保護(hù)系統(tǒng)和用戶(hù)。3.添加模型路由和網(wǎng)關(guān)，以支持復(fù)雜的Pipeline并增強(qiáng)安全性。4.用緩存優(yōu)化時(shí)延和成本。5.添加復(fù)雜的邏輯和寫(xiě)入操作，以將系統(tǒng)能力最大化。可觀測(cè)性使我們可以對(duì)系統(tǒng)進(jìn)行監(jiān)控和調(diào)試，而編排則涉及將所有組件鏈接在一起。這兩個(gè)部分都是平臺(tái)的基本組成部分，我們將在文章最后進(jìn)行討論。本文重點(diǎn)討論了部署AI應(yīng)用的總體架構(gòu)，討論了構(gòu)建這些組件所需的組件和注意事項(xiàng)，并不涉及如何構(gòu)建AI應(yīng)用，因此不討論模型評(píng)略。（這些主題會(huì)在即將出版的《AI工程》一書(shū)中詳細(xì)介紹。）1第一步：增強(qiáng)上下文平臺(tái)的初步擴(kuò)展通常涉及添加機(jī)制，使系統(tǒng)能夠?yàn)椴樵?xún)補(bǔ)充必要的信息。收集相關(guān)信息的過(guò)程被稱(chēng)為上下文構(gòu)建。許多查詢(xún)需要上下文才能得到解答。上下文中包含的相關(guān)信息越多，模型對(duì)其內(nèi)部知識(shí)的依賴(lài)就越少，因?yàn)槟Ｐ偷膬?nèi)部知識(shí)可能由于訓(xùn)練數(shù)據(jù)和訓(xùn)練方法的局限性而不可靠。研究表明，訪(fǎng)問(wèn)上下文中的相關(guān)信息可以幫助模型生成更詳細(xì)的回答，同時(shí)減少幻覺(jué)(Lewisetal.,2020)。例如，詢(xún)問(wèn)“Acme的fancy-printer-A300能否每秒打印100張？”如果模型能獲取fancy-printer-A300的規(guī)格信息，它就能夠給出更好的回答。（感謝ChetanTekur提供的例子。）對(duì)于基礎(chǔ)模型來(lái)說(shuō)，上下文構(gòu)建相當(dāng)于傳統(tǒng)機(jī)器學(xué)習(xí)模型中的特征上下文學(xué)習(xí)（從上下文中學(xué)習(xí)）是一種持續(xù)學(xué)習(xí)的形式。它使模型能夠持續(xù)整合新信息以做出決策，從而防止模型過(guò)時(shí)。例如，使用上周數(shù)據(jù)訓(xùn)練的模型，如果不包含新信息，就無(wú)法回答本周的查詢(xún)。通過(guò)用最新信息（如fancy-printer-A300的最新規(guī)格）更新模型的上下文，模型可以保持最新?tīng)顟B(tài)，并能夠回答超出其訓(xùn)練截RAG最有名的構(gòu)建上下文的模式是RAG，即檢索增強(qiáng)生成（Retrieval-AugmentedGeneration）。RAG由兩個(gè)部分組成：一個(gè)生成器（例如語(yǔ)言模型）和一個(gè)檢索器，后者從外部來(lái)源檢索相關(guān)信息。的核心。許多為傳統(tǒng)檢索系統(tǒng)開(kāi)發(fā)的檢索算法都可以用于RAG。外部存儲(chǔ)源通常包含非結(jié)構(gòu)化數(shù)據(jù)，例如備忘錄、合同、新聞更新含100萬(wàn)個(gè)詞元。直接檢索整個(gè)文檔可能會(huì)導(dǎo)致上下文過(guò)長(zhǎng)。RAG通常要求將文檔分割成可管理的塊，其大小可以根據(jù)模型的最大上下文長(zhǎng)度和應(yīng)用的時(shí)延要求來(lái)確定。（要了解有關(guān)分塊和最佳塊大小的更多信息，請(qǐng)參閱Pinecone、Langchain、Llamaindex和GregKamradt的教程。）一旦外部存儲(chǔ)源中的數(shù)據(jù)被加載并分塊，檢索就主要通過(guò)兩種方法進(jìn)行：“transformer”，檢索所有包含該關(guān)鍵詞的文檔。更復(fù)雜的算法包括BM25（利用TF-IDF）和Elasticsearch（利用倒排索引）。基于術(shù)語(yǔ)的檢索通常用于文本數(shù)據(jù)，也同樣適用于具有文本元數(shù)據(jù)（如標(biāo)題、標(biāo)簽、字幕、評(píng)論等）的圖像和視頻?？梢允褂们度肽Ｐ停ㄈ鏐ERT、sentence-transformers，以及OpenAI或Google提供的專(zhuān)有嵌入模型）將數(shù)據(jù)塊轉(zhuǎn)換為嵌入向量。給定一個(gè)查詢(xún)，通過(guò)向量搜索算法檢索與查詢(xún)嵌入最接近的數(shù)據(jù)。如FAISS（FacebookAISimilaritySearch）、Google的ScaNN、Spotify的ANNOY和hnswlib（HierarchicalNavigableSmallWorld）。ANN-benchmarks網(wǎng)站使用四個(gè)主要指標(biāo)對(duì)多個(gè)數(shù)據(jù)集上的不同ANN算法進(jìn)行比較，并考慮了索引和查詢(xún)之間的權(quán)衡?！ふ倩芈剩核惴ㄕ业浇彽谋壤??！っ棵氩樵?xún)數(shù)（QPS）：算法每秒能處理的查詢(xún)流量應(yīng)用至關(guān)重要。（例如數(shù)據(jù)發(fā)生變化這個(gè)指標(biāo)非常重要。存儲(chǔ)需求至關(guān)重要。這種方法不僅適用于文本文檔，還適用于圖像、視頻、音頻和代碼。許多團(tuán)隊(duì)甚至嘗試總結(jié)SQL表和Dataframe，然后使用這些摘要生成用于檢索的嵌入?；谛g(shù)語(yǔ)的檢索比基于嵌入的檢索更快且成本更低。它在初始狀態(tài)Elasticsearch在行業(yè)中都得到了廣泛使用，并成為了更復(fù)雜檢索系統(tǒng)的強(qiáng)有力的基準(zhǔn)。盡管基于嵌入的檢索計(jì)算開(kāi)銷(xiāo)較大，但隨著時(shí)間的推移，這一點(diǎn)可以得到顯著改進(jìn)，最終超越基于術(shù)語(yǔ)的檢索。生產(chǎn)環(huán)境中的檢索系統(tǒng)通常結(jié)合了幾種方法。結(jié)合基于術(shù)語(yǔ)的檢索和基于嵌入的檢索被稱(chēng)為混合搜索。一種常見(jiàn)的模式是順序處理。首先，使用廉價(jià)但精度較低的檢索器（如基于術(shù)語(yǔ)的系統(tǒng)）獲取候選文檔。然后，使用更精確但成本較高的機(jī)制（如k近鄰）從這些候選文檔中找到最合適的。第二步也被稱(chēng)為重排序（reranking）。例如，針對(duì)“transformer”這個(gè)詞，可以檢索所有包含“transformer”這個(gè)詞的文檔，無(wú)論是關(guān)于電氣設(shè)備、神經(jīng)網(wǎng)絡(luò)架構(gòu)還是電影。之后，可以使用向量搜索從這些文檔中找到與transformer查詢(xún)真正相關(guān)的那一部分。上下文重排序與傳統(tǒng)搜索重排序不同之處在于，項(xiàng)目的精確位置并不那么重要。在搜索中，排名（例如第一還是第五）至關(guān)重要。而在上下文重排序中，文檔的順序仍然重要，因?yàn)樗鼤?huì)影響模型處理它們的效果。研究表明，模型可能更好地理解上下文中開(kāi)頭和結(jié)尾的文檔(Liuetal.,2023)。然而，只要文檔被包含在內(nèi)，其順序的影響就不如在搜索排名中那么顯著。另一種模式是集成。檢索器通過(guò)根據(jù)查詢(xún)與文檔的相關(guān)性評(píng)分進(jìn)行排名?？梢酝瑫r(shí)使用多個(gè)檢索器獲取候選文檔，然后將這些不同的排名結(jié)合起來(lái)生成最終排名。帶有表格數(shù)據(jù)的RAG外部數(shù)據(jù)源也可以是結(jié)構(gòu)化的，例如Dataframe或SQL表。從SQL表中檢索數(shù)據(jù)與從非結(jié)構(gòu)化文檔中檢索數(shù)據(jù)有很大不同。給定一個(gè)查詢(xún)時(shí)，系統(tǒng)的工作流程如下。1.文本到SQL：根據(jù)用戶(hù)查詢(xún)和表的模式，確定需要哪種SQL查詢(xún)。2.SQL執(zhí)行：執(zhí)行SQL查詢(xún)。3.生成：基于SQL結(jié)果和原始用戶(hù)查詢(xún)生成回答。在“文本到SQL”這一步中，如果有多個(gè)可用的表且其模式無(wú)法全部放入模型上下文中，你可能需要一個(gè)中間步驟來(lái)預(yù)測(cè)每個(gè)查詢(xún)應(yīng)使AgenticRAG互聯(lián)網(wǎng)是一個(gè)重要的數(shù)據(jù)來(lái)源。像Google或BingAPI這樣的網(wǎng)頁(yè)搜索工具可以讓模型訪(fǎng)問(wèn)豐富的、最新的資源，以便為查詢(xún)收集相索最新的奧斯卡信息，并利用這些信息生成最終的回答返回給用戶(hù)?；谛g(shù)語(yǔ)的檢索、基于嵌入的檢索、SQL執(zhí)行和網(wǎng)頁(yè)搜索都是模型可以用來(lái)增強(qiáng)其上下文的方法?？梢詫⒚總€(gè)動(dòng)作視為模型可以調(diào)用的函數(shù)。能夠整合外部動(dòng)作的工作流程也被稱(chēng)為“Agentic”。其架構(gòu)如下圖所示。一個(gè)工具可以允許一個(gè)或多個(gè)動(dòng)作。例如，一人搜索工具可能允許兩個(gè)動(dòng)作：按姓名搜索和按電子郵件搜索。不過(guò)，這兩者的差別很小，所以許多人會(huì)將動(dòng)作和工具交替使用。?只讀動(dòng)作與寫(xiě)入動(dòng)作?從外部來(lái)源檢索信息但不更改其狀態(tài)的動(dòng)作稱(chēng)為只讀動(dòng)作。賦予模型寫(xiě)入動(dòng)作的能力，例如更新表中的值，能夠讓模型執(zhí)行更多任務(wù)，但也帶來(lái)了更多風(fēng)險(xiǎn)，這一點(diǎn)之后討論。查詢(xún)重寫(xiě)用戶(hù)的查詢(xún)（Query）通常需要重寫(xiě)，以增加獲取正確信息的可能性。閱讀以下對(duì)話(huà)。用戶(hù)：JohnDoe最近一次在我們這里購(gòu)買(mǎi)東西是什么時(shí)候？AI：John從我們這里購(gòu)買(mǎi)了一頂FruityFedora帽子，是兩周前，2030年1月3日。用戶(hù)：那EmilyDoe呢？最后一個(gè)問(wèn)題“HowaboutEmilyDoe?”是不清晰的。如果直接使用這個(gè)查詢(xún)來(lái)檢索文檔，可能會(huì)得到不相關(guān)的結(jié)果。需要重寫(xiě)這個(gè)查詢(xún)，才能反映用戶(hù)實(shí)際在問(wèn)什么。新的查詢(xún)應(yīng)該具有獨(dú)立的意義。最后一個(gè)問(wèn)題應(yīng)該重寫(xiě)為“WhenwasthelasttimeEmilyDoeboughtsomethingfromus?”（EmilyDoe最近一次從我們這里購(gòu)買(mǎi)東西是什么時(shí)候?qū)懹脩?hù)的最后輸入，以反映用戶(hù)實(shí)際在問(wèn)什么”的提示。查詢(xún)重寫(xiě)可能會(huì)很復(fù)雜，尤其是在一些需要進(jìn)行身份解析或結(jié)合其他知識(shí)的情況下。如果用戶(hù)問(wèn)“Howabouthiswife?”（他的妻子呢你首先需要查詢(xún)數(shù)據(jù)庫(kù)，以確定他的妻子是誰(shuí)。如果你沒(méi)有這方面的信息，重寫(xiě)模型應(yīng)承認(rèn)這個(gè)查詢(xún)無(wú)法解決，而不是憑空編造一個(gè)名字，否則可能會(huì)導(dǎo)致錯(cuò)誤的回答。2第2步：設(shè)置防護(hù)措施防護(hù)措施有助于降低AI風(fēng)險(xiǎn)，不僅保護(hù)用戶(hù)，也保護(hù)開(kāi)發(fā)者。防護(hù)措施應(yīng)在任何可能出現(xiàn)故障的地方都進(jìn)行設(shè)置。本文討論了兩種類(lèi)型的防護(hù)措施：輸入防護(hù)措施和輸出防護(hù)措施。輸入防護(hù)措施及執(zhí)行會(huì)損害系統(tǒng)的惡意提示（如模型越獄）。向外部API泄露私人信息這種風(fēng)險(xiǎn)特指在使用外部模型API時(shí)需要將數(shù)據(jù)發(fā)送到組織外部。比如，員工可能會(huì)將公司的機(jī)密或用戶(hù)的私人信息復(fù)制到提示中，并將其發(fā)送到模型所在的服務(wù)器。這一點(diǎn)先前曾有一個(gè)典例：三星員工將三星的專(zhuān)有信息輸入到ChatGPT中，意外泄露了公司的機(jī)密。雖然并不清楚三星是如何發(fā)現(xiàn)這次泄露的，以及泄露的信息如何被用來(lái)對(duì)付三星，但這次事件十分嚴(yán)重，導(dǎo)致三星在2023年5月禁止使用ChatGPT。以通過(guò)防護(hù)措施來(lái)減輕這些風(fēng)險(xiǎn)。可以使用現(xiàn)有的眾多工具之一來(lái)自動(dòng)檢測(cè)敏感數(shù)據(jù)。你可以指定需要檢測(cè)哪些敏感數(shù)據(jù)。常見(jiàn)的敏感數(shù)據(jù)類(lèi)別包括：人臉識(shí)別信息。與公司知識(shí)產(chǎn)權(quán)或?qū)Ｓ行畔⑾嚓P(guān)的特定關(guān)鍵詞和短語(yǔ)。許多敏感數(shù)據(jù)檢測(cè)工具使用AI來(lái)識(shí)別潛在的敏感信息，例如判斷字符串是否類(lèi)似于有效的家庭住址。如果發(fā)現(xiàn)查詢(xún)中包含敏感信息，你有兩個(gè)選擇：屏蔽整個(gè)查詢(xún)或移除其中的敏感信息。例如，可以用占位符[PHONENUMBER]來(lái)屏蔽用戶(hù)的電話(huà)號(hào)碼。如果生成的回原始信息，以便能夠揭秘它，如下圖所示。模型越獄嘗試越獄AI模型，使其說(shuō)出或做出不當(dāng)?shù)氖?，已?jīng)成為了一種網(wǎng)絡(luò)娛樂(lè)活動(dòng)。雖然讓ChatGPT發(fā)表一些有爭(zhēng)議的言論可能會(huì)讓一些人感到好笑，但如果你的客服聊天機(jī)器人（帶有你的品牌名稱(chēng)和標(biāo)志）做出同樣的事情，那就一點(diǎn)也不好笑了。對(duì)于那些可以訪(fǎng)問(wèn)工具的AI系統(tǒng)來(lái)說(shuō)，這一點(diǎn)尤其危險(xiǎn)。想象一下，如果用戶(hù)找到了一種方法來(lái)讓你的系統(tǒng)執(zhí)行破壞數(shù)據(jù)的SQL查詢(xún)，那將會(huì)多么糟糕。為了解決這個(gè)問(wèn)題，應(yīng)該首先在系統(tǒng)上設(shè)置防護(hù)措施，以確保任何有害的操作都無(wú)法自動(dòng)執(zhí)行。例如，任何可以插入、刪除或更新數(shù)據(jù)的SQL查詢(xún)?cè)跊](méi)有人工批準(zhǔn)的情況下都不能執(zhí)行。雖然增加這種安全性可保護(hù)系統(tǒng)，但缺點(diǎn)是可能會(huì)減慢系統(tǒng)的運(yùn)行速度。為了防止應(yīng)用程序發(fā)表不該說(shuō)的離譜言論，可以為應(yīng)用程序定義一些超出其職責(zé)范圍的話(huà)題。例如，如果應(yīng)用程序是一個(gè)客服聊天機(jī)器人，它就不應(yīng)該回答政治或社會(huì)問(wèn)題。一個(gè)簡(jiǎn)單的方法是過(guò)濾掉義的限制話(huà)題。如果系統(tǒng)中有害的提示非常少見(jiàn)，可以使用異常檢測(cè)算法來(lái)識(shí)別異常提示。輸出防護(hù)措施AI模型具有概率性，這使得其輸出并不總是可靠。通過(guò)設(shè)置防護(hù)措施，可以顯著提高應(yīng)用程序的可靠性。輸出防護(hù)措施主要有兩個(gè)功能：輸出質(zhì)量評(píng)估以下是一些失敗模式的例子以及捕捉它們的方法。2.空白回答。如果應(yīng)用程序期望得到JSON格式的輸出，而生成的回答卻缺少關(guān)閉括號(hào)。某些格式（如正則表達(dá)式、JSON和Python代碼）有專(zhuān)門(mén)的驗(yàn)證工具。此外，還有一些用于受限采樣的工具，如guidance、outlines和instructor。用各種檢測(cè)工具來(lái)捕捉這些有害內(nèi)容。一個(gè)很活躍的研究領(lǐng)域，一些相關(guān)的解決方案已經(jīng)涌現(xiàn)，如SelfCheckGPT(Manakuletal.,2023)和SAFESearchEngineFactualityEvaluator,(Weietal.,2024)?？梢酝ㄟ^(guò)為模型提供足夠的上下文以及使用思維鏈等提示技術(shù)來(lái)減少幻覺(jué)的發(fā)生。6.含有敏感信息的回答。這種情況可能出現(xiàn)在以下兩種場(chǎng)景：息。這些敏感信息傳遞到回答中。這種失敗模式可以通過(guò)不在模型訓(xùn)練時(shí)使用敏感數(shù)據(jù)以及不允許模型檢索敏感數(shù)據(jù)來(lái)防止。輸出中的敏感數(shù)據(jù)可以使用與輸入防護(hù)措施相同的工具來(lái)檢測(cè)。一個(gè)例子是，由X公司訓(xùn)練的模型Grok生成的回答暗示Grok是由OpenAI訓(xùn)練的，這引發(fā)了網(wǎng)絡(luò)對(duì)X公司涉嫌竊取OpenAI數(shù)據(jù)的猜測(cè)。關(guān)鍵字監(jiān)控可以削弱這種失敗模式的影響。一旦識(shí)別出涉及品牌和競(jìng)爭(zhēng)對(duì)手的輸出內(nèi)容，可以選擇屏蔽這些輸出，將其交由人工審核，或者使用其他模型檢測(cè)這些輸出的情感，以確保只返回正確的情感內(nèi)容。篇文章寫(xiě)得非常糟糕，或者你要求模型提供一個(gè)低熱量蛋糕的食譜，而生成的食譜卻含有過(guò)多的糖?，F(xiàn)在越來(lái)越流行使用AI評(píng)判者來(lái)評(píng)估模型回答的質(zhì)量。這些AI評(píng)判者可以是通用模型（如ChatGPT、Claude也可以是專(zhuān)門(mén)訓(xùn)練的打分工具，針對(duì)給定的查詢(xún)對(duì)回答給出具體評(píng)分。故障管理AI模型具有概率性，這意味著如果重復(fù)提問(wèn)，可能會(huì)得到不同的回答。許多故障可以通過(guò)基本的重試邏輯來(lái)消除。例如，如果回答是空的，可以重試X次或直到得到非空的回答。同樣，如果回答格式錯(cuò)誤，可以反復(fù)嘗試，直到模型生成正確格式的回答。然而，這種重試策略可能會(huì)帶來(lái)額外的時(shí)延和成本。一次重試意味著API調(diào)用次數(shù)增加一倍。如果重試是在故障發(fā)生后進(jìn)行的，用戶(hù)體驗(yàn)到的時(shí)延將會(huì)翻倍。為了減少時(shí)延，可以并行調(diào)用。例如，不必等待第一次調(diào)用失敗后再進(jìn)行重試，可以同時(shí)將該查詢(xún)發(fā)送給模型兩次，得到兩個(gè)回答后，選擇其中較好的一個(gè)。雖然這種方式增加棘手的查詢(xún)通常還會(huì)依靠人工干預(yù)來(lái)解決。例如，當(dāng)一個(gè)查詢(xún)包含特定的關(guān)鍵短語(yǔ)時(shí)，你可以將其轉(zhuǎn)交給人工操作員處理。有些團(tuán)隊(duì)會(huì)使用一個(gè)專(zhuān)門(mén)的模型來(lái)決定何時(shí)將對(duì)話(huà)轉(zhuǎn)交給人工處理，這個(gè)模型可能是內(nèi)部訓(xùn)練的。比如，某個(gè)團(tuán)隊(duì)的情感分析模型檢測(cè)到用戶(hù)開(kāi)始生氣，團(tuán)隊(duì)便將對(duì)話(huà)轉(zhuǎn)交給人工操作員處理。另一個(gè)團(tuán)隊(duì)則在對(duì)話(huà)進(jìn)行到一定次數(shù)后轉(zhuǎn)交，以防止用戶(hù)陷入無(wú)限循環(huán)。保護(hù)措施的權(quán)衡可靠性與時(shí)延的權(quán)衡：雖然保護(hù)措施的重要性不容忽視，但有些團(tuán)隊(duì)認(rèn)為時(shí)延更為重要。他們決定不實(shí)施保護(hù)措施，因?yàn)楸Ｗo(hù)措施可能會(huì)顯著增加應(yīng)用程序的時(shí)延。然而，這些團(tuán)隊(duì)只是少數(shù)，大多數(shù)團(tuán)隊(duì)認(rèn)為風(fēng)險(xiǎn)增加的成本比時(shí)延增加更高。在流式完成模式下，輸出保護(hù)措施可能效果不佳。默認(rèn)情況下，完整的回答會(huì)在顯示給用戶(hù)之前完成生成，這可能需要很長(zhǎng)時(shí)間。在流式完成模式中，新生成的詞元會(huì)實(shí)時(shí)傳輸給用戶(hù)，從而減少用戶(hù)等待回答的時(shí)間。流式完成模式的缺點(diǎn)是某些回答很難評(píng)估，因此不安全的回答可能會(huì)在系統(tǒng)保護(hù)措施確定其應(yīng)該被阻止之前就已經(jīng)傳輸給用戶(hù)。自托管與第三方API的權(quán)衡：自托管模型意味著不需要將數(shù)據(jù)發(fā)送給第三方，從而減少了對(duì)輸入保護(hù)措施的需求。然而，這也意味著你必須自己實(shí)施所有必要的保護(hù)措施，而不是依賴(lài)第三方服務(wù)提供的保護(hù)措施。我們的平臺(tái)目前就是這樣。保護(hù)措施可以是獨(dú)立的工具或模型網(wǎng)關(guān)的一部分，這一點(diǎn)稍后會(huì)討論。如果使用評(píng)分器，它們會(huì)被歸入模生成的模型更小且更快。3第3步：添加模型路由器和網(wǎng)關(guān)隨著應(yīng)用程序變得越來(lái)越復(fù)雜并涉及更多模型，出現(xiàn)了兩種協(xié)助處理多個(gè)模型的工具：路由器和網(wǎng)關(guān)。路由器應(yīng)用程序可以使用不同的模型來(lái)回答不同類(lèi)型的查詢(xún)。針對(duì)不同查詢(xún)采用不同的解決方案有幾個(gè)好處。首先，能夠有專(zhuān)業(yè)化的解決方案，例如一個(gè)模型專(zhuān)注于技術(shù)故障排除，另一個(gè)模型專(zhuān)注于訂閱問(wèn)題。專(zhuān)業(yè)化模型通常比通用模型表現(xiàn)更佳。其次，這可以節(jié)省成本。與其將所有查詢(xún)都路由到一個(gè)昂貴的模型，不如將簡(jiǎn)單的查詢(xún)路由到便宜的模型上。路由器通常包含一個(gè)意圖分類(lèi)器，用來(lái)預(yù)測(cè)用戶(hù)的意圖。根據(jù)預(yù)測(cè)的意圖，查詢(xún)會(huì)被路由以適當(dāng)?shù)慕鉀Q方案。以一個(gè)客服聊天機(jī)器人為例，如果意圖是：·重置密碼->將此用戶(hù)路由到密碼重置頁(yè)面?！じ~單錯(cuò)誤->將此用戶(hù)路由到人工操作員。了微調(diào)的模型。意圖分類(lèi)器還可以幫助系統(tǒng)規(guī)避一些超出范圍的對(duì)話(huà)。例如，可以用意圖分類(lèi)器預(yù)測(cè)查詢(xún)是否超出范圍。如果查詢(xún)被認(rèn)為是不合適的（例如，如果用戶(hù)詢(xún)問(wèn)你會(huì)在即將到來(lái)的選舉中投票給誰(shuí)聊天機(jī)器人可以禮貌地拒絕參與，使用一些標(biāo)準(zhǔn)回答（“作為聊天機(jī)器人，我沒(méi)有投票的能力。如果你對(duì)我們的產(chǎn)品有疑問(wèn)，我很樂(lè)意幫助?！倍粫?huì)浪費(fèi)一次API調(diào)用。如果系統(tǒng)可以執(zhí)行多種操作，那么路由器還可以包含一個(gè)下一步操作預(yù)測(cè)器，幫助系統(tǒng)決定接下來(lái)采取什么行動(dòng)。如果查詢(xún)模糊不統(tǒng)可能會(huì)問(wèn)：“你是想凍結(jié)你的賬戶(hù)還是在談?wù)撎鞖?？”或者?jiǎn)單地說(shuō)：“對(duì)不起。你能詳細(xì)說(shuō)明一下嗎？”意圖分類(lèi)器和下一步操作預(yù)測(cè)器可以是通用模型，也可以是專(zhuān)門(mén)的分類(lèi)模型。專(zhuān)門(mén)的分類(lèi)模型通常比通用模型小且更快，這使得系統(tǒng)可以使用多個(gè)模型而不會(huì)造成大量的額外時(shí)延和成本。當(dāng)把查詢(xún)路由到具有不同上下文限制的模型時(shí)，問(wèn)題的上下文可能K上下文限制的模型。系統(tǒng)隨后采取一個(gè)操作，例如網(wǎng)絡(luò)搜索，返回8000詞元的上下文。你可以將查詢(xún)的上下文截?cái)嘁赃m應(yīng)最初計(jì)劃的模型，或者把查詢(xún)路由到一個(gè)有更大的上下文限制的模型。網(wǎng)關(guān)模型網(wǎng)關(guān)是一個(gè)中間層，它能夠使組織以統(tǒng)一且安全的方式與不同的模型交互。模型網(wǎng)關(guān)最基本的功能是使開(kāi)發(fā)人員能夠以相同的方式訪(fǎng)問(wèn)不同的模型——無(wú)論是自托管模型還是如OpenAI或Google等商業(yè)API背后的模型。模型網(wǎng)關(guān)讓代碼維護(hù)變得更容易。如果模型API發(fā)生變化，只需更新模型網(wǎng)關(guān)，而不必更新所有使用該模型API的應(yīng)用程序。在最簡(jiǎn)單的形式中，模型網(wǎng)關(guān)是一個(gè)統(tǒng)一的封裝器，代碼示例如下。本示例旨在幫助你了解模型網(wǎng)關(guān)如何實(shí)現(xiàn)，并不具有實(shí)際功能，因?yàn)樗话魏五e(cuò)誤檢查或優(yōu)化。importgoogle.generativeaiasgenaiimportopenaidefopenai_model(input_data,model_name,max_tokens):openai.api_key=os.environ["OPENAI__API__KEY"]response=openai.Completion.create(engine=model__name,prompt=input_data,max_tokens=max_tokens)return{"response":response.choices[0].text.strip()}defgemini_model(input_data,model_name,max_tokens):genai.configure(api_key=os.environ["GOOGLE_API_KEY"])model=genai.GenerativeModel(model_name=model_name)response=model.generate_content(input_data,max_tokens=max_tokens)return{"response":response["choices"][0]["message"]["content"]}@app.route('/model',methods=['POST'])defmodel_gateway():data=request.get_json()model_type=data.get("model_type")model_name=data.get("model_name")input_data=data.get("input_data")max_tokens=data.get("max_tokens")ifmodel_type=="openai":result=openai_model(input_data,model_name,max_tokens)elifmodel_type=="gemini":result=gemini_model(input_data,model_name,max_tokens)returnjsonify(result)模型網(wǎng)關(guān)還包括訪(fǎng)問(wèn)控制和成本管理。與其把組織詞元給那些想要訪(fǎng)問(wèn)OpenAIAPI的人，不如只給他們?cè)L問(wèn)模型網(wǎng)關(guān)的權(quán)限，從而創(chuàng)建一個(gè)集中和受控的訪(fǎng)問(wèn)點(diǎn)。網(wǎng)關(guān)還可以實(shí)現(xiàn)精細(xì)化的訪(fǎng)問(wèn)控制，指定哪個(gè)用戶(hù)或應(yīng)用程序應(yīng)有權(quán)訪(fǎng)問(wèn)哪個(gè)模型。此外，網(wǎng)關(guān)可以監(jiān)控和限制API調(diào)用的使用，防止濫用并有效管理成本。模型網(wǎng)關(guān)還可以用于實(shí)施回退策略，以克服速率限制或API故障（很備用模型，經(jīng)過(guò)短暫等待后重試，或以其他合理的方式處理故障。這確保了應(yīng)用程序可以平穩(wěn)運(yùn)行而不受中斷。由于請(qǐng)求和回答已經(jīng)通過(guò)網(wǎng)關(guān)流動(dòng)，因此模型網(wǎng)關(guān)是實(shí)現(xiàn)其他功能的良好位置，例如負(fù)載均衡、日志記錄和分析。一些網(wǎng)關(guān)服務(wù)甚至提供緩存和保護(hù)措施。Portkey的網(wǎng)關(guān)、MLflowAIGateway、WealthSimple的llm-gateway、TrueFoundry、Kong和Cloudflare。隨著網(wǎng)關(guān)和路由器的添加，我們的平臺(tái)變得越來(lái)越有意思。與評(píng)分類(lèi)似，路由也在模型網(wǎng)關(guān)中。與用于評(píng)分的模型類(lèi)似，用于路由的模型通常比用于生成的模型小。4第4步：用緩存減少時(shí)延當(dāng)我和我的朋友EugeneYan分享這篇文章時(shí)，他提到緩存可能是AI平臺(tái)中最被低估的組件。緩存可以顯著減少應(yīng)用程序的時(shí)延和成本。緩存技術(shù)也可以在訓(xùn)練過(guò)程中使用，但由于這篇文章是關(guān)于部署的，我將重點(diǎn)討論推理中的緩存。常見(jiàn)的推理緩存技術(shù)包括提示緩存、精確緩存和語(yǔ)義緩存。提示緩存通常由使用的推理API實(shí)現(xiàn)。在評(píng)估一個(gè)推理庫(kù)時(shí)，了解它支持哪種緩存機(jī)制是很有幫助的。提示緩存許多應(yīng)用中的提示具有重疊的文本段。例如，所有查詢(xún)都可以共享同一個(gè)系統(tǒng)提示。提示緩存會(huì)存儲(chǔ)這些重疊的段落以便重復(fù)使用，因此只需要處理一次。不同提示中的常見(jiàn)重疊文本段是系統(tǒng)提示。如果沒(méi)有提示緩存，模型需要對(duì)每個(gè)查詢(xún)都處理系統(tǒng)提示。有了提示緩存，模型只需在第一個(gè)查詢(xún)時(shí)處理一次系統(tǒng)提示。對(duì)于具有長(zhǎng)系統(tǒng)提示的應(yīng)用程序，提示緩存可以顯著減少時(shí)延和成次模型API調(diào)用，那么提示緩存將幫助你每天少處理大約10億個(gè)重的大小可能相當(dāng)大，并且需要很多工程投入。提示緩存對(duì)涉及長(zhǎng)文檔的查詢(xún)也很有用。例如，如果許多用戶(hù)問(wèn)題都與同一個(gè)長(zhǎng)文檔（如一本書(shū)或一段代碼庫(kù)）有關(guān)，那么這個(gè)長(zhǎng)文檔可以緩存下來(lái)，以供多個(gè)問(wèn)題重復(fù)使用。型API中。Google宣布GeminiAPI將在2024年6月提供這一功能，并命名為上下文緩存。緩存的輸入詞元相比普通輸入詞元有用為每小時(shí)每百萬(wàn)詞元1美元）。鑒于提示緩存的明顯優(yōu)勢(shì)，如果未盡管llama.cpp也有提示緩存功能，但它似乎只緩存完整的提示，并且僅適用于同一聊天會(huì)話(huà)中的查詢(xún)。其文檔有限，但從閱讀代碼來(lái)看，我猜測(cè)在長(zhǎng)對(duì)話(huà)中，它緩存了前面的消息，只處理最新的消息。精確緩存如果說(shuō)提示緩存和KV緩存是基礎(chǔ)模型所獨(dú)有的，那么精確緩存則更加通用且直觀。系統(tǒng)可以存儲(chǔ)已處理的項(xiàng)目，以便在處理相同項(xiàng)目時(shí)重復(fù)使用。例如，如果用戶(hù)要求模型總結(jié)某個(gè)產(chǎn)品，系統(tǒng)會(huì)檢查緩存中是否已有該產(chǎn)品的摘要。如果有，就取出這個(gè)摘要。如果沒(méi)有，則生成摘要并緩存該摘要。精確緩存還用于基于嵌入的檢索，可以避免冗余的向量搜索。如果查詢(xún)已經(jīng)在向量搜索緩存中存在，則獲取緩存的搜索結(jié)果。如果沒(méi)有，則為該問(wèn)題執(zhí)行向量搜索并緩存結(jié)果。緩存在需要多步操作（如思維鏈）和/或耗時(shí)操作（如檢索、SQL執(zhí)行或網(wǎng)絡(luò)搜索）的查詢(xún)中特別有效。精確緩存可以使用內(nèi)存存儲(chǔ)來(lái)實(shí)現(xiàn)，以便快速檢索。然而，由于內(nèi)存存儲(chǔ)是有限的，緩存也可以使用像PostgreSQL、Redis或分層存儲(chǔ)這樣的數(shù)據(jù)庫(kù)來(lái)平衡速度和存儲(chǔ)容量。制定一個(gè)驅(qū)逐策略對(duì)管理緩存大小和維持性能至關(guān)重要。常見(jiàn)的驅(qū)逐策略包括最近最少使緩存一個(gè)查詢(xún)的時(shí)間長(zhǎng)短取決于該查詢(xún)被再次調(diào)用的可能性。用戶(hù)時(shí)間敏感查詢(xún)也意義不大。一些團(tuán)隊(duì)會(huì)訓(xùn)練小型分類(lèi)器來(lái)預(yù)測(cè)某個(gè)查詢(xún)是否應(yīng)該被緩存。語(yǔ)義緩存與精確緩存不同，語(yǔ)義緩存不要求傳入的查詢(xún)與緩存中的查詢(xún)完全語(yǔ)義緩存只有在你有可靠的方法來(lái)判斷兩個(gè)查詢(xún)?cè)谡Z(yǔ)義上是否相似時(shí)才有效。常用的方法是基于嵌入的相似性，其工作原理如下：1.對(duì)查詢(xún)使用嵌入模型生成其嵌入表示。這個(gè)相似度分?jǐn)?shù)是X。3.如果X超過(guò)了設(shè)定的相似性閾值，則認(rèn)為緩存的查詢(xún)與當(dāng)前查詢(xún)相同，并返回緩存的結(jié)果。如果不超過(guò)，則處理當(dāng)前查詢(xún)，并將其與嵌入和結(jié)果一起緩存。這種方法需要使用向量數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)緩存查詢(xún)的嵌入表示。與其他緩存技術(shù)相比，語(yǔ)義緩存的價(jià)值更加不穩(wěn)定，因?yàn)槠浣M件容易出現(xiàn)故障。它的成功依賴(lài)于高質(zhì)量的嵌入表示、功能完備的向量搜索以及可靠的相似度度量。設(shè)置正確的相似性閾值也可能是個(gè)棘手的挑戰(zhàn)，通常需要大量的嘗試和調(diào)整。如果系統(tǒng)錯(cuò)誤地將傳入的查詢(xún)視為與另一個(gè)查詢(xún)相似，返回的緩存回答可能是錯(cuò)誤的。此外，語(yǔ)義緩存因涉及向量搜索可能會(huì)很耗時(shí)且需要密集的計(jì)算。向量搜索的速度和成本取決于緩存嵌入數(shù)據(jù)庫(kù)的大小。如果緩存命中率較高，即大部分查詢(xún)可以通過(guò)利用緩存結(jié)果有效回答，那么語(yǔ)義緩存可能仍然值得使用。然而，在引入語(yǔ)義緩存的復(fù)雜性之前，務(wù)必評(píng)估與其相關(guān)的效率、成本和性能風(fēng)險(xiǎn)。會(huì)將它們放在模型API框中。我在圖中新增的回答添加到緩存中。5第5步：添加復(fù)雜邏輯并執(zhí)行寫(xiě)入動(dòng)作我們之前討論的應(yīng)用程序流程相對(duì)簡(jiǎn)單?；A(chǔ)模型生成的輸出大多直接返回給用戶(hù)（除非未通過(guò)保護(hù)措施）。然而，應(yīng)用程序的流程可以更加復(fù)雜，包含循環(huán)和條件分支。模型的輸出還可以用于觸發(fā)寫(xiě)入動(dòng)作，例如撰寫(xiě)郵件或下訂單。復(fù)雜邏輯模型的輸出可以有條件地傳遞給另一個(gè)模型，或者作為下一步輸入的一部分反饋給同一個(gè)模型。這個(gè)過(guò)程會(huì)持續(xù)進(jìn)行，直到系統(tǒng)中的某個(gè)模型決定任務(wù)已完成，并且應(yīng)該向用戶(hù)返回最終的回答。這種情況可能會(huì)在賦予系統(tǒng)規(guī)劃能力和決策能力時(shí)出現(xiàn)。舉個(gè)例子，“規(guī)劃巴黎周末行程”這一問(wèn)題。?；顒?dòng)的列表：參觀埃菲爾鐵塔、在咖啡館午餐、游覽盧浮宮等。然“參觀埃菲爾鐵塔”可能會(huì)促使模型生成子任務(wù)，如檢查開(kāi)放時(shí)間、一個(gè)全面詳細(xì)的行程。我們的基礎(chǔ)設(shè)施現(xiàn)在有一條箭頭指向生成的回答，并將其反饋給上下文構(gòu)建，這又會(huì)反饋給模型網(wǎng)關(guān)中的模型。寫(xiě)入操作用于上下文構(gòu)建的動(dòng)作是只讀動(dòng)作，它們?cè)试S模型從數(shù)據(jù)源讀取信息以收集上下文。但系統(tǒng)也可以執(zhí)行寫(xiě)入操作，對(duì)數(shù)據(jù)源和現(xiàn)實(shí)世Y”，系統(tǒng)將調(diào)用動(dòng)作send_email(recipient=X,message=Y)。寫(xiě)入操作使系統(tǒng)的能力大幅提升，可以將整個(gè)客戶(hù)外聯(lián)流程自動(dòng)化：研究潛在客戶(hù)、尋找聯(lián)系方式、起草郵件、發(fā)送初次郵件、讀取回答、跟進(jìn)、提取訂單、將新訂單更新到數(shù)據(jù)庫(kù)等。然而，賦予AI自動(dòng)改變我們生活的能力的前景是一件有些可怕的事情。就像不應(yīng)該讓實(shí)習(xí)生有權(quán)刪除生產(chǎn)數(shù)據(jù)庫(kù)一樣，同樣也不應(yīng)該允許一個(gè)不可靠的AI發(fā)起銀行轉(zhuǎn)賬。對(duì)系統(tǒng)能力和安全措施的信任至關(guān)重要。我們需要確保系統(tǒng)受到保護(hù)，避免系統(tǒng)被惡意行為者操縱而執(zhí)行有害動(dòng)作。AI系統(tǒng)和其他軟件系統(tǒng)一樣，容易受到網(wǎng)絡(luò)攻擊，但它們還有另一個(gè)弱點(diǎn)：提示注入（promptinjection）。提示注入是指攻擊者操縱輸入提示，使模型表現(xiàn)出不良行為?？梢詫⑻崾咀⑷胍暈獒槍?duì)AI而非人類(lèi)的社會(huì)工程攻擊。許多公司都很擔(dān)心的一種情景是：他們將AI系統(tǒng)接入內(nèi)部數(shù)據(jù)庫(kù)，而攻擊者誘使該系統(tǒng)泄露數(shù)據(jù)庫(kù)中的私人信息。如果系統(tǒng)擁有這些數(shù)據(jù)庫(kù)的寫(xiě)入權(quán)限，攻擊者可能會(huì)誘使系統(tǒng)破壞數(shù)據(jù)。任何要利用AI的組織都需要認(rèn)真對(duì)待安全和保障問(wèn)題。然而，這些風(fēng)險(xiǎn)并不意味著AI系統(tǒng)永遠(yuǎn)不應(yīng)該在現(xiàn)實(shí)世界中采取行動(dòng)。AI系統(tǒng)可能會(huì)失敗，但人類(lèi)也會(huì)失敗。如果我們能讓人們相信機(jī)器可以帶我們進(jìn)入太空，我希望有一天，安全措施足夠完善，使我們可以信任自主的AI系統(tǒng)?？捎^測(cè)性雖然我將可觀測(cè)性放在了一個(gè)獨(dú)立的部分中，但它應(yīng)該從一開(kāi)始就集成到平臺(tái)中，而不是作為事后才添加的內(nèi)容?？捎^測(cè)性對(duì)于所有相比其他部分，本節(jié)提供的信息最少。一篇文章不可能涵蓋可觀測(cè)性的所有細(xì)節(jié)。因此，我將簡(jiǎn)要概述監(jiān)控的三大支柱：日志、追蹤和指標(biāo)。文章不會(huì)涉及具體內(nèi)容或用戶(hù)反饋、漂移檢測(cè)和調(diào)試。指標(biāo)談到監(jiān)控時(shí)，大多數(shù)人會(huì)想到指標(biāo)。要跟蹤哪些指標(biāo)取決于想要監(jiān)控系統(tǒng)的哪些方面，這通常根據(jù)應(yīng)用來(lái)特定的。不過(guò)，通常有兩種類(lèi)型的指標(biāo)需要跟蹤：模型指標(biāo)和系統(tǒng)指標(biāo)。系統(tǒng)指標(biāo)會(huì)反應(yīng)整個(gè)系統(tǒng)的狀態(tài)。常見(jiàn)的系統(tǒng)指標(biāo)包括吞吐量、內(nèi)所有軟件工程應(yīng)用中都是通用的。在本文中，我將重點(diǎn)關(guān)注模型指標(biāo)。模型指標(biāo)評(píng)估模型的性能，例如準(zhǔn)確性、有害性和幻覺(jué)率。應(yīng)用Pipeline中的不同步驟也有各自的指標(biāo)。例如，在RAG（檢索增強(qiáng)生成）應(yīng)用中，檢索質(zhì)量通常通過(guò)上下文相關(guān)性和上下文精度來(lái)評(píng)估。向量數(shù)據(jù)庫(kù)可以通過(guò)其索引數(shù)據(jù)所需的存儲(chǔ)空間以及查詢(xún)數(shù)據(jù)所需的時(shí)間來(lái)評(píng)估。模型輸出的失敗方式可能是多種多樣的。識(shí)別這些問(wèn)題并制定監(jiān)控它們的指標(biāo)至關(guān)重要。例如，可能需要跟蹤模型超時(shí)的頻率、返回空回答的次數(shù)或生成格式錯(cuò)誤回答的情況。如果擔(dān)心模型泄露敏感信息，也需要找到跟蹤這種情況的方法。與長(zhǎng)度相關(guān)的指標(biāo)（如問(wèn)題長(zhǎng)度、上下文長(zhǎng)度和回答長(zhǎng)度）有助于理解模型的行為。某個(gè)模型是否比另一個(gè)更冗長(zhǎng)？某些類(lèi)型的問(wèn)題是否更可能導(dǎo)致冗長(zhǎng)的回答？這些指標(biāo)對(duì)于檢測(cè)應(yīng)用程序中的變化尤其有用。如果平均問(wèn)題長(zhǎng)度突然減少，可能表明存在需要調(diào)查的潛在問(wèn)題。與長(zhǎng)度相關(guān)的指標(biāo)對(duì)于跟蹤時(shí)延和成本也很重要，因?yàn)檩^長(zhǎng)的上下文和回答通常會(huì)增加時(shí)延并帶來(lái)更高的成本。跟蹤時(shí)延對(duì)于理解用戶(hù)體驗(yàn)至關(guān)重要。常見(jiàn)的時(shí)延指標(biāo)包括：·第一個(gè)詞元生成時(shí)間（TTFT生成第一個(gè)詞元所需的時(shí)·詞元間時(shí)間（TBT）：每個(gè)詞元生成之間的間隔時(shí)間?！っ棵肷稍~元數(shù)（TPS）：生成詞元的速率。·每個(gè)輸出詞元生成時(shí)間（TPOT）：生成每個(gè)輸出詞元所需的時(shí)間。·總時(shí)延：完成一次回答所需的總時(shí)間。還需要跟蹤成本。與成本相關(guān)的指標(biāo)包括問(wèn)題數(shù)量和輸入、輸出詞以確保API速率在分配的限額內(nèi)并避免潛在的服務(wù)中斷。在計(jì)算指標(biāo)時(shí)，可以選擇抽樣檢查或全量檢查。抽樣檢查涉及對(duì)數(shù)據(jù)子集進(jìn)行采樣，以快速識(shí)別問(wèn)題，而全量檢查則評(píng)估每個(gè)請(qǐng)求，以全面了解性能。選擇取決于系統(tǒng)的需求和可用資源，結(jié)合兩者可以提供平衡的監(jiān)控策略。在計(jì)算指標(biāo)時(shí)，確保它們可以按相關(guān)維度進(jìn)行細(xì)分，如用戶(hù)、發(fā)布版本、提示/鏈條版本、提示/鏈條類(lèi)型和解性能變化并識(shí)別具體問(wèn)題。日志記錄日志的理念很簡(jiǎn)單：記錄一切。記錄系統(tǒng)配置，記錄問(wèn)題、輸出以及中間輸出。記錄每個(gè)組件的啟動(dòng)、結(jié)束以及發(fā)生崩潰的時(shí)間系統(tǒng)的哪個(gè)部分。記錄一切意味著日志的數(shù)量可能會(huì)迅速增長(zhǎng)。許多用于自動(dòng)日志分雖然手動(dòng)處理日志是不可能的，但每日手動(dòng)檢查生產(chǎn)數(shù)據(jù)對(duì)于了解用戶(hù)如何使用應(yīng)用程序是有幫助的。Shankar等人發(fā)現(xiàn)，隨著開(kāi)發(fā)人員與更多數(shù)據(jù)的交互，他們對(duì)好壞輸出的看法會(huì)發(fā)生變化，這使得他們能夠重新編寫(xiě)提示，以增加獲得優(yōu)質(zhì)回答的機(jī)會(huì)，并更新評(píng)估流程以捕捉不良回答。追蹤追蹤指的是詳細(xì)記錄請(qǐng)求在各種系統(tǒng)組件和服務(wù)中的執(zhí)行路徑。在AI應(yīng)用程序中，追蹤揭示了從用戶(hù)發(fā)送問(wèn)題到最終回答返回的整個(gè)過(guò)程，包括系統(tǒng)采取的操作、