拆解生成式AI平臺：基礎組件、功能及實現

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