使用這些基本 REST API 最佳實踐構建出色的 API
通用AI大模型應用平臺整體架構
（上圖可編輯文檔可關注索取）
這是一個相當復雜的系統。將從最簡單的架構開始，逐步（Step by Step）添加更多組件。在最簡單的形式中，應用程序接收查詢并將其發送到模型。模型生成響應，并將其返回給用戶。沒有護欄，沒有增強上下文，也沒有優化。模型 API框指的是第三方 API（例如 OpenAI、Google、Anthropic）和自托管 API。
從這里，可以根據需要逐步添加更多組件：
可觀測性，它可以讓你對系統進行監控和調試以獲得可見性，以及編排，它涉及將所有組件串聯在一起，是平臺的兩個基本組成部分。
平臺的初始擴展通常涉及添加機制，以允許系統為每個查詢添加必要的信息。收集相關信息的過程稱為上下文構建。
許多查詢需要上下文才能回答。上下文中的相關信息越多，模型對其內部知識的依賴就越少，而由于其訓練數據和訓練方法，這些知識可能不可靠。研究表明，訪問上下文中的相關信息可以幫助模型生成更詳細的響應，同時減少幻覺。
例如，對于查詢“Acme 的 fancy-printer-A300 能否打印 100pps？”，如果模型獲得 fancy-printer-A300 的規格，它將能夠做出更好的響應。
基礎模型的上下文構建相當于傳統 ML 模型的特征工程。它們的目的相同：為模型提供處理輸入所需的信息。
上下文學習，即從上下文中學習，是一種持續學習的形式。它使模型能夠不斷吸收新信息來做出決策，防止其過時。例如，使用上周數據訓練的模型將無法回答有關本周的問題，除非其情境中包含新信息。通過使用最新信息（例如 fancy-printer-A300 的最新規格）更新模型的上下文，該模型將保持最新狀態，并可以在截止日期之后響應查詢。
最著名的上下文構建模式是RAG，即檢索增強生成。RAG由兩個組件組成：生成器（例如語言模型）和檢索器，后者從外部來源檢索相關信息。
檢索并非RAG所獨有的功能。它是搜索引擎、推薦系統、日志分析等的支柱。許多為傳統檢索系統開發的檢索算法都可以用于 RAG。
外部存儲源通常包含非結構化數據，例如備忘錄、合同、新聞更新等。它們可以統稱為文檔。一個文檔可以是 10 個標記，也可以是 100 萬個標記。簡單地檢索整個文檔可能會導致上下文變得任意長。RAG 通常要求將文檔拆分為可管理的塊，這可以根據模型的最大上下文長度和應用程序的延遲要求確定。
一旦來自外部存儲源的數據被加載和分塊，就會使用兩種主要方法進行檢索。
這可以像關鍵字搜索一樣簡單。例如，給定查詢“transformer”，獲取包含此關鍵字的所有文檔。更復雜的算法包括 BM25（利用 TF-IDF）和 Elasticsearch（利用倒排索引）。
基于Term的檢索通常用于文本數據，但它也適用于具有文本元數據（如標題、標簽、說明、評論等）的圖像和視頻。
使用嵌入模型（例如BERT、句子轉換器以及OpenAI 或 Google 提供的專有嵌入模型）將數據塊轉換為嵌入向量。給定一個查詢，將檢索由向量搜索算法確定的向量最接近查詢嵌入的數據。
向量搜索通常被稱為最近鄰搜索，使用近似最近鄰 (ANN) 算法，例如FAISS（Facebook AI 相似性搜索）、Google 的ScaNN、Spotify 的ANNOY和hnswlib（分層可導航小世界）。
這不僅適用于文本文檔，還適用于圖像、視頻、音頻和代碼。許多團隊甚至嘗試匯總 SQL 表和數據框，然后使用這些摘要生成用于檢索的嵌入。
基于Term的檢索比基于嵌入的檢索更快、更便宜。它開箱即用，是一個有吸引力的入門選擇。BM25 和 Elasticsearch 都在業界廣泛使用，是更復雜檢索系統的強大基線。基于嵌入的檢索雖然計算成本高昂，但隨著時間的推移可以得到顯著改進，從而超越基于Term的檢索。
生產檢索系統通常結合多種方法。將基于術語的檢索和基于嵌入的檢索相結合稱為混合搜索。
一種常見的模式是順序的。首先，一個便宜但不太精確的檢索器（例如基于Term的系統）會獲取候選詞。然后，一個更精確但更昂貴的機制（例如 k-最近鄰）會從這些候選詞中找出最佳詞。第二步也稱為重新排序。
例如，給定術語“transformer”，可以獲取包含單詞 transformer 的所有文檔，無論它們是關于電氣設備、神經結構還是電影。然后使用向量搜索在這些文檔中找到與您的 transformer 查詢實際相關的文檔。
上下文重新排序與傳統的搜索重新排序不同，項目的確切位置不那么重要。在搜索中，排名（例如第一或第五）至關重要。在上下文重新排序中，文檔的順序仍然很重要，因為它會影響模型處理文檔的能力。正如論文Lost in the middle所建議的那樣，模型可能會更好地理解上下文開頭和結尾的文檔。但是，只要包含文檔，其順序的影響就不如搜索排名中的影響大。
另一種模式是組合。檢索器的工作方式是按文檔與查詢的相關性得分對文檔進行排名。可以使用多個檢索器同時獲取候選，然后將這些不同的排名組合在一起以生成最終排名。
外部數據源也可以是結構化的，例如數據框或 SQL 表。從 SQL 表中檢索數據與從非結構化文檔中檢索數據有很大不同。給定查詢，系統的工作方式如下。
對于文本轉 SQL 步驟，如果有許多可用表的架構無法全部放入模型上下文中，則可能需要一個中間步驟來預測每個查詢要使用哪些表。文本轉 SQL 可以由用于生成最終響應的同一模型或許多專門的文本轉 SQL 模型之一完成。
互聯網是數據的一個重要來源。像 Google 或 Bing API 這樣的網絡搜索工具可以讓模型訪問豐富的最新資源，以收集每個查詢的相關信息。例如，給定查詢“今年誰獲得了奧斯卡獎？”，系統會搜索有關最新奧斯卡獎的信息，并使用此信息生成對用戶的最終回復。
基于Term的檢索、基于嵌入的檢索、SQL 執行和 Web 搜索是模型可以采取的操作，以增強其上下文。可以將每個操作視為模型可以調用的函數。可以合并外部操作的工作流也稱為agentic。
? Action vs 工具 ?
一個工具允許執行一項或多項操作。例如，人員搜索工具可能允許執行兩項操作：按姓名搜索和按電子郵件搜索。但是，兩者之間的區別很小，因此會交替使用action和工具。
? 只讀actions與寫入actions ?
從外部源檢索信息但不改變其狀態的操作是只讀actions。賦予模型寫入actions（例如更新表中的值）可使模型執行更多任務，但也會帶來更多風險。
通常，需要重寫用戶查詢以增加獲取正確信息的可能性。考慮以下對話。
User: When was the last time John Doe bought something from us?AI: John last bought a Fruity Fedora hat from us two weeks ago, on January 3, 2030.User: How about Emily Doe?
最后一個問題“Emily Doe 怎么樣？”含糊不清。如果逐字使用此查詢來檢索文檔，則可能會得到不相關的結果。需要重寫此查詢以反映用戶實際詢問的內容。新查詢本身應該有意義。最后一個問題應該重寫為“Emily Doe 上次從我們這里買東西是什么時候？”
查詢重寫通常使用其他 AI 模型來完成，使用類似于“給定以下對話，重寫最后的用戶輸入以反映用戶實際詢問的內容”的提示。
查詢重寫可能會變得很復雜，特別是當需要進行身份解析或整合其他知識時。如果用戶問“他的妻子怎么樣？”，首先需要查詢數據庫以找出他的妻子是誰。如果沒有這些信息，重寫模型應該承認這個查詢是不可解決的，而不是產生一個名字的幻覺，從而導致錯誤的答案。
護欄有助于降低 AI 風險，不僅保護您的用戶，還保護開發人員。只要有可能出現故障，就應該設置護欄。這篇文章討論了兩種類型的護欄：輸入護欄和輸出護欄。
2.1 輸入護欄
輸入護欄通常可以防止兩種類型的風險：將私人信息泄露給外部 API，以及執行危害系統的惡意提示（模型越獄）。
此風險特定于使用外部模型 API，即當你需要將數據發送到組織外部時。例如，員工可能會將公司的機密或用戶的私人信息復制到提示中，并將其發送到托管模型的任何地方。
早期最引人注目的事件之一是三星員工將三星的專有信息放入 ChatGPT 中，意外泄露了公司的機密。目前尚不清楚三星是如何發現這次泄密的，以及泄露的信息是如何被用來對付三星的。然而，這起事件的嚴重性足以讓三星在 2023 年 5 月禁止使用 ChatGPT。
使用第三方 API 時，沒有萬無一失的方法可以消除潛在的泄漏。但是，你可以使用護欄來緩解它們。你可以使用許多可用的自動檢測敏感數據的工具之一。要檢測哪些敏感數據由你指定。常見的敏感數據類別有：
許多敏感數據檢測工具使用 AI 來識別潛在的敏感信息，例如確定字符串是否類似于有效的家庭住址。如果發現查詢包含敏感信息，您有兩個選擇：阻止整個查詢或從中刪除敏感信息。例如，可以使用占位符 [PHONE NUMBER] 屏蔽用戶的電話號碼。如果生成的響應包含此占位符，請使用 PII 可逆字典將此占位符映射到原始信息，以便您可以取消屏蔽，如下所示。
模型越獄
試圖越獄人工智能模型，讓它們說壞話或做壞事，已經成為一項在線運動。雖然有些人可能會覺得讓 ChatGPT 發表有爭議的言論很有趣，但如果客戶支持聊天機器人（帶有您的名稱和徽標）做同樣的事情，那就沒那么有趣了。這對于有權使用工具的人工智能系統來說尤其危險。想象一下，如果用戶找到一種方法讓系統執行破壞數據的 SQL 查詢。
為了解決這個問題，應該首先在系統上設置護欄，以便不會自動執行任何有害操作。例如，未經人工批準，不能執行可以插入、刪除或更新數據的 SQL 查詢。這種增加的安全性的缺點是它會降低系統速度。
為了防止應用程序發表不該發表的離譜言論，可以為應用程序定義超出范圍的主題。例如，如果應用程序是客戶支持聊天機器人，它就不應該回答政治或社會問題。一個簡單的方法是過濾掉包含通常與有爭議的話題相關的預定義短語的輸入，例如“移民”或“反疫苗”。更復雜的算法使用人工智能來分類輸入是否與預定義的受限主題之一有關。
如果系統中的有害提示很少見，可以使用異常檢測算法來識別不尋常的提示。
AI 模型是概率性的，因此其輸出不可靠。可以設置護欄來顯著提高應用程序的可靠性。輸出護欄有兩個主要功能：
要發現不符合標準的輸出，需要了解故障是什么樣子的。以下是故障模式的示例及其發現方法。
AI 模型是概率性的，這意味著如果您再次嘗試查詢，可能會得到不同的響應。許多故障可以通過使用基本的重試邏輯來緩解。例如，如果響應為空，請重試 X 次或直到您得到非空響應。同樣，如果響應格式不正確，請重試，直到模型生成格式正確的響應。
但是，這種重試策略可能會產生額外的延遲和成本。一次重試意味著 API 調用次數增加 2 倍。如果在失敗后進行重試，則用戶所經歷的延遲將增加一倍。為了減少延遲，可以并行進行調用。例如，對于每個查詢，不必等待第一個查詢失敗后再重試，而是同時將此查詢發送到模型兩次，獲得兩個響應，然后選擇更好的一個。這會增加冗余 API 調用的數量，但保持延遲可控。
依靠人工來處理棘手的查詢也很常見。例如，如果查詢包含特定的關鍵短語，則可以將其轉交給人工操作員。一些團隊使用專門的模型（可能在內部訓練）來決定何時將對話轉交給人工。例如，當情緒分析模型檢測到用戶生氣時，一個團隊會將對話轉交給人工操作員。另一個團隊在一定次數后轉移對話，以防止用戶陷入無限循環。
可靠性與延遲的權衡：雖然承認護欄的重要性，但一些團隊告訴我，延遲更重要。他們決定不實施護欄，因為護欄會顯著增加應用程序的延遲。然而，這些團隊是少數。大多數團隊發現，增加的風險比增加的延遲更昂貴。
在流完成模式下，輸出防護措施可能無法正常工作。默認情況下，整個響應在顯示給用戶之前生成，這可能需要很長時間。在流完成模式下，新令牌在生成時會流式傳輸給用戶，從而減少用戶等待查看響應的時間。缺點是很難評估部分響應，因此在系統防護措施確定應阻止不安全的響應之前，它們可能會被流式傳輸給用戶。
自托管與第三方 API 的權衡：自托管模型意味著不必將數據發送給第三方，從而減少了對輸入護欄的需求。然而，這也意味著您必須自己實現所有必要的護欄，而不是依賴第三方服務提供的護欄。
護欄可以是獨立的工具，也可以是模型網關的一部分。如果使用評分器，則將其歸類在模型 API 下，因為評分器通常也是 AI 模型。用于評分的模型通常比用于生成的模型更小、更快。
隨著應用程序變得越來越復雜并且涉及更多的模型，出現了兩種類型的工具來處理多種模型：路由器和網關。
應用程序可以使用不同的模型來響應不同類型的查詢。針對不同的查詢提供不同的解決方案有幾個好處。首先，這允許擁有專門的解決方案，例如一個專門用于技術故障排除的模型和另一個專門用于訂閱的模型。專用模型的性能可能比通用模型更好。其次，這可以節省成本。可以將更簡單的查詢路由到更便宜的模型，而不是將所有查詢路由到昂貴的模型。
路由器通常由一個意圖分類器組成，該分類器可以預測用戶想要做什么。根據預測的意圖，查詢將被路由到適當的解決方案。例如，對于客戶支持聊天機器人，如果意圖是：
意圖分類器還可以幫助您的系統避免超出范圍的對話。例如，可以使用意圖分類器來預測查詢是否超出范圍。如果查詢被視為不合適（例如，如果用戶詢問您將在即將到來的選舉中投票給誰），聊天機器人可以使用其中一個常規回復（“作為聊天機器人，我沒有投票權。如果您對我們的產品有疑問，我很樂意為您提供幫助。”）禮貌地拒絕參與，而不會浪費 API 調用。
如果系統可以訪問多個操作，路由器可以包含下一步操作預測器，以幫助系統決定下一步要采取什么操作。如果查詢不明確，則一個有效的操作是要求澄清。例如，在響應查詢“凍結”時，系統可能會問：“您想凍結您的帳戶還是在談論天氣？”或者簡單地說，“對不起。你能詳細說明一下嗎？”
意圖分類器和下一步行動預測器可以是通用模型或專用分類模型。專用分類模型通常比通用模型小得多且速度快得多，因此系統可以使用多個專用分類模型，而不會產生顯著的額外延遲和成本。
當將查詢路由到具有不同上下文限制的模型時，查詢的上下文可能需要進行相應調整。假設一個包含 1,000 個標記的查詢，該查詢適用于具有 4K 上下文限制的模型。然后系統執行操作（例如網絡搜索），該操作會返回 8,000 個標記上下文。可以截斷查詢的上下文以適應最初預期的模型，也可以將查詢路由到具有更大上下文限制的模型。
模型網關是一個中間層，可讓組織以統一且安全的方式與不同的模型進行交互。模型網關的最基本功能是讓開發人員能夠以相同的方式訪問不同的模型 – 無論是自托管模型還是 OpenAI 或 Google 等商業 API 背后的模型。模型網關使維護代碼變得更加容易。如果模型 API 發生變化，只需更新模型網關，而不必更新使用此模型 API 的所有應用程序。
最簡單的模型網關形式是一個統一的包裝器，如以下代碼示例所示。此示例旨在了解如何實現模型網關。它不具備功能性，因為它不包含任何錯誤檢查或優化。
import google.generativeai as genaiimport openai
def openai_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()}
def gemini_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'])def model_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")
if model_type == "openai": result = openai_model(input_data, model_name, max_tokens) elif model_type == "gemini": result = gemini_model(input_data, model_name, max_tokens) return jsonify(result)模型網關是訪問控制和成本管理。不必向所有想要訪問 OpenAI API 的人提供的組織tokens（這些tokens很容易泄露），而只需向人們提供模型網關的訪問權限，從而創建一個集中且受控的訪問點。網關還可以實現細粒度的訪問控制，指定哪個用戶或應用程序應該有權訪問哪個模型。此外，網關可以監控和限制 API 調用的使用，從而防止濫用并有效管理成本。
模型網關還可用于實施回退策略，以克服速率限制或 API 故障（不幸的是后者很常見）。當主要 API 不可用時，網關可以將請求路由到替代模型，短暫等待后重試，或以其他優雅的方式處理故障。這可確保您的應用程序能夠順利運行而不會中斷。
由于請求和響應已經流經網關，因此它是實現其他功能（如負載平衡、日志記錄和分析）的好地方。一些網關服務甚至提供緩存和護欄。
由于網關的實現相對簡單，因此有許多現成的網關。例如 Portkey 的網關、MLflow AI 網關、WealthSimple 的llm-gateway、TrueFoundry、Kong和Cloudflare。
隨著網關和路由器的增加，生成式AI平臺變得更加精彩。與評分一樣，路由也位于模型網關中。與用于評分的模型一樣，用于路由的模型通常比用于生成的模型小。
緩存可能是生成式AI平臺中最被低估的組件。緩存可以顯著降低應用程序的延遲和成本。
緩存技術也可用于訓練，但由于本文是關于部署的，將重點介紹用于推理的緩存。一些常見的推理緩存技術包括提示緩存、精確緩存和語義緩存。提示緩存通常由使用的推理 API 實現。在評估推理庫時，了解它支持的緩存機制會很有幫助。
注意力機制的 KV 緩存超出了本次討論的范圍。
應用程序中的許多提示都有重疊的文本段。例如，所有查詢都可以共享相同的系統提示。提示緩存會存儲這些重疊的段以供重復使用，因此只需處理一次即可。不同提示中常見的重疊文本段是系統提示。如果沒有提示緩存，模型需要在每個查詢中處理系統提示。有了提示緩存，它只需要為第一個查詢處理一次系統提示。
對于系統提示較長的應用程序，提示緩存可以顯著減少延遲和成本。如果系統提示是 1000 個令牌，并且應用程序今天生成 100 萬個模型 API 調用，則提示緩存將會每天免于處理大約 10 億個重復輸入令牌！但是，這并非完全免費。與 KV 緩存一樣，提示緩存大小可能非常大，需要大量的工程工作。
對于涉及長文檔的查詢，提示緩存也很有用。例如，如果許多用戶查詢與同一篇長文檔（例如一本書或一個代碼庫）相關，則可以緩存這篇長文檔以供查詢重復使用。
自 2023 年 11 月Gim 等人推出以來，prompt cache 已被納入模型 API。Google 宣布 Gemini API 將于 2024 年 6 月以context cache的名稱提供此功能。與常規輸入令牌相比，緩存的輸入令牌可享受 75% 的折扣，但必須為緩存存儲支付額外費用（每小時 1.00 美元/100 萬個令牌）。鑒于 prompt cache 的明顯優勢，如果它變得像 KV 緩存一樣受歡迎，將不會讓人感到驚訝。
雖然 llama.cpp 也有提示緩存，但它似乎只緩存整個提示并用于同一聊天會話中的查詢。它的文檔有限，但從閱讀代碼中猜測，在長時間的對話中，它會緩存以前的消息并僅處理最新消息。
如果提示緩存和 KV 緩存是基礎模型所獨有的，那么精確緩存則更為通用和直接。系統會存儲已處理的項目，以便在以后請求精確項目時重新使用。例如，如果用戶要求模型總結產品，系統會檢查緩存以查看是否緩存了該產品的摘要。如果是，則獲取此摘要。如果沒有，則總結產品并緩存摘要。
精確緩存還用于基于嵌入的檢索，以避免重復的向量搜索。如果傳入的查詢已經在向量搜索緩存中，則獲取緩存的搜索結果。如果沒有，則對此查詢執行向量搜索并緩存結果。
緩存對于需要多個步驟（例如思路鏈）和/或耗時操作（例如檢索、SQL 執行或 Web 搜索）的查詢尤其有吸引力。
可以使用內存存儲實現精確緩存，以實現快速檢索。但是，由于內存存儲有限，因此也可以使用 PostgreSQL、Redis 或分層存儲等數據庫實現緩存，以平衡速度和存儲容量。制定驅逐策略對于管理緩存大小和保持性能至關重要。常見的驅逐策略包括最近最少使用 (LRU)、最不頻繁使用 (LFU) 和先進先出 (FIFO)。
緩存查詢的時間取決于該查詢再次被調用的可能性。特定于用戶的查詢（例如“我最近的訂單狀態如何”）不太可能被其他用戶重復使用，因此不應緩存。同樣，緩存對時間敏感的查詢（例如“天氣怎么樣？”）也沒有什么意義。一些團隊會訓練一個小型分類器來預測是否應該緩存查詢。
與精確緩存不同，語義緩存不要求傳入查詢與任何緩存查詢相同。語義緩存允許重復使用類似的查詢。假設一個用戶問“What’s the capital of Vietnam?”，模型會生成答案“河內”。后來，另一個用戶問“What’s the capital city of Vietnam? ”，這是同一個問題，但多了一個單詞“城市”。語義緩存的理念是系統可以重復使用答案“河內”，而不是從頭計算新查詢。
僅當有可靠的方法來確定兩個查詢在語義上是否相似時，語義緩存才有效。一種常見的方法是基于嵌入的相似性，其工作原理如下：
這種方法需要一個向量數據庫來存儲緩存查詢的嵌入。
與其他緩存技術相比，語義緩存的價值更令人懷疑，因為它的許多組件都容易出現故障。它的成功依賴于高質量的嵌入、功能性向量搜索和值得信賴的相似性度量。設置正確的相似性閾值也很棘手，需要大量的反復試驗。如果系統誤認為傳入的查詢與另一個查詢相似，則從緩存中獲取的返回響應將不正確。
此外，語義緩存可能非常耗時且計算量大，因為它涉及向量搜索。此向量搜索的速度和成本取決于緩存嵌入數據庫的大小。
如果緩存命中率較高，語義緩存可能仍然值得使用，這意味著可以通過利用緩存結果有效地回答大部分查詢。然而，在考慮語義緩存的復雜性之前，請務必評估與之相關的效率、成本和性能風險。
添加緩存系統后，生成式AI平臺如下所示。KV 緩存和提示緩存通常由模型 API 提供程序實現，因此未在此圖中顯示。如果必須將它們可視化，將它們放在模型 API 框中，有一個新的箭頭用于將生成的響應添加到緩存中。
到目前為止，討論過的應用程序的流程相當簡單。基礎模型生成的輸出大部分返回給用戶（除非他們沒有通過護欄）。但是，應用程序流程可能會更復雜，包含循環和條件分支。模型的輸出還可用于調用寫入操作，例如撰寫電子郵件或下訂單。
一個模型的輸出可以有條件地傳遞到另一個模型，或作為下一步輸入的一部分反饋給同一個模型。這個過程一直持續到系統中的某個模型決定任務已完成，并應將最終響應返回給用戶。
當讓系統能夠規劃并決定下一步做什么時，就會發生這種情況。例如，考慮查詢“規劃巴黎周末行程”。該模型可能首先生成一個潛在活動列表：參觀埃菲爾鐵塔、在咖啡館吃午餐、游覽盧浮宮等。然后可以將每一項活動反饋到模型中以生成更詳細的計劃。例如，“參觀埃菲爾鐵塔”可以促使模型生成子任務，例如查看開放時間、購買門票和查找附近的餐館。這個迭代過程持續進行，直到創建全面而詳細的行程。
基礎設施現在有一個箭頭，將生成的響應指向上下文構建，然后再反饋給模型網關中的模型。
用于構建上下文的操作是只讀操作。它們允許模型從其數據源讀取以收集上下文。但系統也可以有寫操作，對數據源和世界進行更改。例如，如果模型輸出：“向 X 發送一封包含消息 Y 的電子郵件”，系統將調用該操作send_email(recipient=X, message=Y)。
寫操作使系統功能更加強大。它們可以讓你自動化整個客戶拓展工作流程：研究潛在客戶、尋找他們的聯系人、起草電子郵件、發送第一封電子郵件、閱讀回復、跟進、提取訂單、用新訂單更新數據庫等。
然而，讓人工智能自動改變我們生活的前景令人恐懼。就像你不應該讓實習生有權刪除你的生產數據庫一樣，你也不應該允許不可靠的人工智能發起銀行轉賬。對系統功能及其安全措施的信任至關重要。你需要確保系統受到保護，以免被那些試圖操縱系統執行有害操作的壞人所利用。
與其他軟件系統一樣，人工智能系統也容易受到網絡攻擊，但它們還有另一個弱點：提示注入。提示注入是指攻擊者操縱輸入提示進入模型，使其表現出不良行為。可以將提示注入視為針對人工智能而非人類進行的社會工程。
許多公司擔心的情況是，他們讓人工智能系統訪問其內部數據庫，而攻擊者會誘騙該系統泄露這些數據庫中的私人信息。如果系統對這些數據庫具有寫權限，攻擊者可以誘騙系統破壞數據。
任何想要利用人工智能的組織都需要認真對待安全問題。然而，這些風險并不意味著人工智能系統永遠不應該被賦予在現實世界中行動的能力。人工智能系統可能會失敗，但人類也會失敗。如果我們能讓人們相信機器能帶我們進入太空，希望有一天，安全問題足以讓我們信任自主人工智能系統。
雖然將可觀察性放在了單獨的部分，但它應該從一開始就集成到平臺中，而不是事后才添加。可觀察性對于各種規模的項目都至關重要，其重要性隨著系統的復雜性而增長。
可觀察性的所有細微差別并未全部涵蓋，僅簡要概述監控的三大支柱：日志、追蹤和指標。關于用戶反饋、偏差檢測和調試就不過多介紹了。
討論監控時，大多數人都會想到指標。要跟蹤哪些指標取決于想要跟蹤系統的哪些方面，這些指標與應用程序相關。但是，一般來說，需要跟蹤兩種類型的指標：模型指標和系統指標。
系統指標可以告訴整個系統的狀態。常見指標包括吞吐量、內存使用率、硬件利用率以及服務可用性/正常運行時間。系統指標是所有軟件工程應用程序所共有的。
模型指標評估模型的性能，例如準確度、毒性和幻覺率。應用程序管道中的不同步驟也有自己的指標。例如，在 RAG 應用程序中，檢索質量通常使用上下文相關性和上下文精度來評估。向量數據庫可以通過索引數據所需的存儲空間以及查詢數據所需的時間來評估
模型輸出失敗的原因有很多種。識別這些問題并制定指標來監控這些問題至關重要。例如，可能希望跟蹤模型超時、返回空響應或生成格式錯誤的響應的頻率。如果擔心模型泄露敏感信息，請找到一種方法來跟蹤這些信息。
與長度相關的指標（例如查詢、上下文和響應長度）有助于了解模型的行為。一個模型是否比另一個模型更冗長？某些類型的查詢是否更有可能導致冗長的答案？它們對于檢測應用程序中的變化特別有用。如果平均查詢長度突然減少，則可能表明存在需要調查的潛在問題。
長度相關指標對于跟蹤延遲和成本也很重要，因為較長的上下文和響應通常會增加延遲并產生更高的成本。
跟蹤延遲對于了解用戶體驗至關重要。常見的延遲指標包括：
還需要跟蹤成本。與成本相關的指標包括查詢數量以及輸入和輸出令牌的數量。如果使用具有速率限制的 API，則跟蹤每秒的請求數非常重要，以確保保持在分配的限制范圍內并避免潛在的服務中斷。
計算指標時，可以選擇抽樣檢查或詳盡檢查。抽樣檢查涉及對數據子集進行抽樣以快速識別問題，而詳盡檢查則評估每個請求以獲得全面的性能視圖。選擇取決于您的系統要求和可用資源，兩者結合可提供平衡的監控策略。
計算指標時，確保可以按相關軸（例如用戶、發布、提示/鏈版本、提示/鏈類型和時間）進行細分。這種粒度有助于了解性能變化并識別特定問題。
日志的理念很簡單：記錄一切。記錄系統配置。記錄查詢、輸出和中間輸出。記錄組件的啟動、結束、崩潰等時間。記錄日志時，請確保為其添加標簽和 ID，這樣可以幫助了解此日志來自系統的哪個位置。
記錄所有內容意味著日志量會快速增長。許多用于自動日志分析和日志異常檢測的工具都由 AI 提供支持。
雖然不可能手動處理日志，但每天手動檢查生產數據以了解用戶如何使用的應用程序很有用。隨著開發人員與更多數據的交互，他們對好輸出和壞輸出的看法會發生變化，這使得他們既可以重寫提示以增加獲得良好響應的機會，也可以更新評估流程以捕捉不良響應。
追蹤是指對請求通過各種系統組件和服務的執行路徑進行詳細記錄。在 AI 應用程序中，追蹤揭示了從用戶發送查詢到返回最終響應的整個過程，包括系統采取的操作、檢索到的文檔以及發送給模型的最終提示。它還應顯示每個步驟所需的時間及其相關成本（如果可衡量）。例如，這是Langsmith跟蹤的可視化。
理想情況下，應該能夠逐步跟蹤每個查詢在系統中的轉換。如果查詢失敗，您應該能夠準確指出出錯的確切步驟：是處理有誤、檢索到的上下文不相關，還是模型生成了錯誤的響應。
AI應用程序可能相當復雜，包含多個模型、從多個數據庫檢索數據，并且可以使用各種工具。編排器可幫助指定如何將這些不同的組件組合（串聯）在一起以創建端到端的應用程序流程。
從高層次上看，編排器的工作分為兩個步驟：組件定義和串聯（也稱為流水線）。
編排器負責在步驟之間傳遞數據，并提供工具來幫助確保當前步驟的輸出符合下一步所需的格式。
在為具有嚴格延遲要求的應用程序設計管道時，盡可能多地并行執行。例如，如果有一個路由組件（決定將查詢發送到哪里）和一個PII（個人身份信息） 刪除組件，它們可以同時執行這兩項操作。
有很多 AI 編排工具，包括LangChain、LlamaIndex、Flowise、Langflow和Haystack。每個工具都有自己的 API，不在這里展示實際的代碼。
雖然在啟動項目時直接使用編排工具很誘人，但首先不要使用編排工具來構建應用程序。任何外部工具都會增加復雜性。編排器可以抽象出系統工作原理的關鍵細節，使理解和調試系統變得困難。
隨著您進入應用程序開發過程的后期階段，可能會決定使用編排器可以讓任務更輕松。在評估編排器時，牢記以下三個方面。
從基本架構開始，然后逐漸添加組件以應對日益增長的應用程序復雜性。每增加一個組件都會帶來一系列好處和挑戰，需要仔細考慮和實施。
雖然組件分離對于保持系統模塊化和可維護性很重要，但這種分離是流動的。組件之間有很多重疊。例如，模型網關可以與護欄共享功能。緩存可以在不同的組件中實現，例如在矢量搜索和推理服務中。
文章來源：From 0 to 1: How to Design and Implement an AI Large Model Application Platform