如何GoDaddy利用批量推理在Amazon Bedrock上建立大規模類別生成系統

這篇文章是由 GoDaddy 的數據工程領導者 Vishal Singh 共同撰寫的，屬於數據與分析團隊。

生成式人工智慧（Generative AI）解決方案有潛力改變商業運作，提升生產力並改善顧客體驗，使用大型語言模型（LLMs）在這些解決方案中變得越來越流行。然而，將 LLMs 作為單一模型調用或 API 呼叫的推理在許多生產應用中並不容易擴展。

透過批量推理（batch inference），你可以異步運行多個推理請求，有效處理大量請求。你也可以使用批量推理來改善在大型數據集上的模型推理表現。

這篇文章概述了 GoDaddy 開發的一個自訂解決方案，GoDaddy 是一個域名註冊商、註冊機構、網頁寄存和電子商務公司，旨在通過使用生成式人工智慧為超過 2100 萬顧客提供個性化的商業見解，使創業變得更容易。這些見解之前僅對大型企業可用。在這次合作中，生成式人工智慧創新中心團隊使用 Amazon Bedrock 的批量推理創建了一個準確且具成本效益的生成式人工智慧解決方案，幫助 GoDaddy 改善其現有的產品分類系統。

解決方案概述

GoDaddy 希望增強其產品分類系統，根據產品名稱為產品分配類別。例如：

GoDaddy 使用了一個現成的 Meta Llama 2 模型來生成六百萬個產品的類別，每個產品由 SKU 標識。生成的類別經常不完整或標籤錯誤。此外，對單個產品分類使用 LLM 的成本也很高。認識到需要更精確且具成本效益的解決方案，GoDaddy 尋求一種更準確且具成本效益的產品分類方法，以改善顧客體驗。

這個解決方案使用以下組件來更準確和高效地對產品進行分類：

關鍵步驟如以下圖所示：

一個包含產品數據的 JSONL 文件被上傳到 S3 存儲桶，觸發第一個 Lambda 函數。Amazon Bedrock 批量處理這個單一的 JSONL 文件，每一行包含輸入參數和提示。它生成一個輸出 JSONL 文件，並在每一行附加一個新的 model_output 值，對應於輸入數據。

Lambda 函數啟動一個 Amazon Bedrock 批量處理端點並傳遞 S3 文件位置。

Amazon Bedrock 端點執行以下任務：

• 它讀取產品名稱數據並生成分類輸出，包括類別、子類別、季節、價格範圍、材料、顏色、產品線、性別和首次銷售年份。
• 它將輸出寫入另一個 S3 位置。

第二個 Lambda 函數執行以下任務：

• 它監控 Amazon Bedrock 上的批量處理任務。
• 當處理完成時，它關閉端點。

這些安全措施本質上已整合到所使用的 AWS 服務中。詳細信息請參閱本文的安全最佳實踐部分。

我們使用了一個包含 30 個標記數據點和 100,000 個未標記測試數據點的數據集。標記數據點是由 llama2-7b 生成並由人類專家驗證的。如以下示例真實數據的截圖所示，有些字段的值為 N/A 或缺失，這並不理想，因為 GoDaddy 希望有一個對下游預測建模具有高覆蓋率的解決方案。每個可能字段的更高覆蓋率可以為他們的顧客提供更多商業見解。

每個 SKU 的單詞或標記數量的分佈顯示出輕微的異常情況，適合將許多產品打包在提示中進行分類，並可能提高模型的回應效率。

這個解決方案提供了一個全面的框架，用於在 GoDaddy 的產品分類系統中生成見解。它設計為與 Amazon Bedrock 上的一系列 LLM 兼容，具有可自定義的提示模板，並支持批量和實時（在線）推理。此外，該框架還包括可以擴展以適應準確性要求變化的評估指標。

在接下來的部分中，我們將更詳細地探討解決方案的關鍵組件。

批量推理

我們使用 Amazon Bedrock 進行批量推理處理。Amazon Bedrock 提供 CreateModelInvocationJob API 來創建一個具有唯一作業名稱的批量作業。此 API 返回一個包含 jobArn 的響應。請參考以下代碼：

我們可以使用 GetModelInvocationJob 監控作業狀態，使用在作業創建時返回的 jobArn。以下是在作業生命周期中有效的狀態：

• 已提交 – 當 JSON 文件準備好被 Amazon Bedrock 處理以進行推理時，作業標記為已提交。
• 進行中 – 當 Amazon Bedrock 開始處理 JSON 文件時，作業標記為進行中。
• 失敗 – 如果在處理過程中出現錯誤，作業標記為失敗。錯誤可以作為 modelOutput 的一部分寫入 JSON 文件。如果是 4xx 錯誤，它會寫入作業的元數據中。
• 完成 – 當為輸入 JSON 文件生成輸出 JSON 文件並已上傳到作為 CreateModelInvocationJob 的一部分提交的 S3 輸出路徑時，作業標記為完成。
• 已停止 – 當對正在進行的作業調用 StopModelInvocationJob API 時，作業標記為已停止。終端狀態作業（成功或失敗）不能使用 StopModelInvocationJob 停止。

以下是 GetModelInvocationJob API 的示例代碼：

當作業完成時，s3OutputDataConfig 中指定的 S3 路徑將包含一個帶有字母數字名稱的新文件夾。該文件夾包含兩個文件：

• json.out – 以下代碼顯示格式示例：

• <file_name>.jsonl.out – 以下截圖顯示代碼示例，包含成功處理的記錄，modelOutput 包含給定產品名稱的類別列表，以 JSON 格式表示。

然後我們在 Amazon S3 中處理 jsonl.out 文件。這個文件使用 LangChain 的 PydanticOutputParser 進行解析，以生成 .csv 文件。PydanticOutputParser 需要一個架構來解析 LLM 生成的 JSON。我們創建了一個 CCData 類，包含每個產品生成的類別列表，如以下代碼示例所示。由於我們啟用了 n-packing，我們將架構包裝在 List 中，如 List_of_CCData 中所定義。

我們還使用 OutputFixingParser 來處理初始解析嘗試失敗的情況。以下截圖顯示生成的 .csv 文件示例。

提示工程

提示工程涉及對輸入提示的巧妙設計和精煉。這個過程包括選擇正確的單詞、短語、句子、標點符號和分隔符，以有效利用 LLM 進行各種應用。基本上，提示工程就是有效地與 LLM 互動。提示工程的最佳策略需要根據特定任務和數據進行調整，特別是數據卡生成和 GoDaddy SKU。

提示由用戶的特定輸入組成，指導 LLM 根據指定的任務或指令生成合適的回應或輸出。這些提示包括幾個元素，例如任務或指令本身、周圍的上下文、完整的示例以及指導 LLM 編寫回應的輸入文本。提示的組成會根據特定用例、數據可用性和任務的性質而有所不同。例如，在檢索增強生成（RAG）用例中，我們提供額外的上下文並在提示中添加用戶提供的查詢，要求 LLM 專注於能回答該查詢的上下文。在元數據生成用例中，我們可以提供圖像並要求 LLM 生成描述和關鍵字，以特定格式描述該圖像。

在這篇文章中，我們將提示工程解決方案簡要分為兩個步驟：輸出生成和格式解析。

輸出生成

以下是輸出生成的最佳實踐和考量：

• 提供簡單、清晰且完整的指令 – 這是提示工程工作的通用指導原則。
• 一致使用分隔符 – 在這個用例中，我們使用換行符號 \n。
• 處理缺失的預設輸出值 – 在這個用例中，我們不希望出現 N/A 或缺失等特殊值，因此我們在行內放置多個指令，旨在排除預設或缺失值。
• 使用少量示例提示 – 也稱為上下文學習，少量示例提示涉及提供少量示例，這可以幫助 LLM 更有效地理解輸出要求。在這個用例中，對 Llama 2 和 Anthropic 的 Claude 模型測試了 0–10 個上下文示例。
• 使用打包技術 – 我們將多個 SKU 和產品名稱合併到一個 LLM 查詢中，以便一些提示指令可以在不同 SKU 之間共享，以優化成本和延遲。在這個用例中，對 Llama 2 和 Anthropic 的 Claude 模型測試了 1–10 的打包數量。
• 測試良好的泛化能力 – 你應該保留一個保留測試集和正確的回應，以檢查你的提示修改是否具有泛化能力。
• 對 Anthropic 的 Claude 模型系列使用額外技術 – 我們採用了以下技術：

• 將示例包裝在 XML 標籤中：

• 使用人類和助手的註釋：

• 指導助手提示：

• 對 Llama 模型系列使用額外技術 – 對於 Llama 2 模型系列，你可以將示例包裝在 [INST] 標籤中：

格式解析

以下是格式解析的最佳實踐和考量：

• 用修飾符精煉提示 – 任務指令的精煉通常涉及改變提示的指令、任務或問題部分。這些技術的有效性根據任務和數據而異。在這個用例中，一些有益的策略包括：
• 角色假設 – 要求模型假設它在扮演一個角色。例如：

你是一名產品信息經理、分類學家和分類專家，能夠很好地遵循指令。

• 提示具體性：對模型提供非常具體和詳細的指令可以幫助生成更好的回應以滿足所需任務。

每個類別信息都需要根據產品名稱和你的最佳猜測填寫。如果你忘記生成任何類別信息，請將其留作缺失或 N/A，否則無辜的人將會死去。

• 輸出格式描述 – 我們通過 JSON 字符串直接提供 JSON 格式指令，並通過少量示例間接提供。

注意少量示例格式 – LLM（Anthropic 的 Claude 和 Llama）對微小的格式差異非常敏感。在多次迭代後，少量示例格式的解析時間顯著改善。最終解決方案如下：

• 對 Anthropic 的 Claude 模型系列使用額外技術 – 對於 Anthropic 的 Claude 模型，我們指示它以 JSON 格式格式化輸出：

• 對 Llama 2 模型系列使用額外技術 – 對於 Llama 2 模型，我們指示它以 JSON 格式格式化輸出如下：

以 JSON 格式格式化你的輸出（確保轉義特殊字符）：輸出應格式化為符合以下 JSON 架構的 JSON 實例。例如，對於架構 {“properties”: {“foo”: {“title”: “Foo”, “description”: “a list of strings”, “type”: “array”, “items”: {“type”: “string”}}}, “required”: [“foo”]}，對象 {“foo”: [“bar”, “baz”]} 是架構的良好格式實例。對象 {“properties”: {“foo”: [“bar”, “baz”]}} 不是良好格式。

這是輸出架構：

{“properties”: {“list_of_dict”: {“title”: “List Of Dict”, “type”: “array”, “items”: {“$ref”: “#/definitions/CCData”}}}, “required”: [“list_of_dict”], “definitions”: {“CCData”: {“title”: “CCData”, “type”: “object”, “properties”: {“product_name”: {“title”: “Product Name”, “description”: “產品名稱，作為輸入提供”, “type”: “string”}, “brand”: {“title”: “Brand”, “description”: “從產品名稱推斷的品牌”, “type”: “string”}, “color”: {“title”: “Color”, “description”: “從產品名稱推斷的顏色”, “type”: “string”}, “material”: {“title”: “Material”, “description”: “從產品名稱推斷的材料”, “type”: “string”}, “price”: {“title”: “Price”, “description”: “從產品名稱推斷的價格”, “type”: “string”}, “category”: {“title”: “Category”, “description”: “從產品名稱推斷的類別”, “type”: “string”}, “sub_category”: {“title”: “Sub Category”, “description”: “從產品名稱推斷的子類別”, “type”: “string”}, “product_line”: {“title”: “Product Line”, “description”: “從產品名稱推斷的產品線”, “type”: “string”}, “gender”: {“title”: “Gender”, “description”: “從產品名稱推斷的性別”, “type”: “string”}, “year_of_first_sale”: {“title”: “Year Of First Sale”, “description”: “從產品名稱推斷的首次銷售年份”, “type”: “string”}, “season”: {“title”: “Season”, “description”: “從產品名稱推斷的季節”, “type”: “string”}}}}}

模型和參數

我們使用了以下提示參數：

• 打包數量 – 1、5、10
• 上下文示例數量 – 0、2、5、10
• 格式指令 – JSON 格式的偽示例（較短），JSON 格式的完整示例（較長）

對於 Llama 2，模型選擇為 meta.llama2-13b-chat-v1 或 meta.llama2-70b-chat-v1。我們使用了以下 LLM 參數：

對於 Anthropic 的 Claude，模型選擇為 anthropic.claude-instant-v1 和 anthropic.claude-v2。我們使用了以下 LLM 參數：

這個解決方案很容易擴展到其他托管在 Amazon Bedrock 上的 LLM，例如 Amazon Titan（例如將模型 ID 切換為 amazon.titan-tg1-large）、Jurassic（模型 ID ai21.j2-ultra）等。

評估

該框架包括可以進一步擴展以適應準確性要求變化的評估指標。目前，它涉及五個不同的指標：

• 內容覆蓋率 – 測量輸出生成步驟中缺失值的部分。
• 解析覆蓋率 – 測量格式解析步驟中缺失樣本的部分：
• 產品名稱的解析召回率 – 精確匹配作為解析完整性的下限（解析覆蓋率是解析完整性的上限），因為在某些情況下，兩個幾乎相同的產品名稱需要標準化和轉換為精確匹配（例如，“Nike Air Jordan”和“nike. air Jordon”）。
• 產品名稱的解析精確率 – 對於精確匹配，我們使用類似於解析召回率的指標，但使用精確率而不是召回率。

最終覆蓋率 – 測量輸出生成和格式解析步驟中缺失值的部分。

人類評估 – 專注於整體質量評估，如準確性、相關性和文本生成的全面性（豐富性）。

結果

以下是一些最佳表現設置下的近似樣本輸入和輸出長度：

• Llama 2 模型系列的輸入長度 – 10-shot 為 2,068 個標記，5-shot 為 1,585 個標記，2-shot 為 1,319 個標記。
• Anthropic 的 Claude 模型系列的輸入長度 – 10-shot 為 1,314 個標記，5-shot 為 831 個標記，2-shot 為 566 個標記，zero-shot 為 359 個標記。
• 5-packing 的輸出長度 – 約 500 個標記。

定量結果

以下表格總結了我們的整體定量結果。

為了簡潔，表格僅包含我們對每種模型類型的最終建議的一部分。

使用的指標是延遲和準確性。

最佳模型和結果以綠色和粗體字突出顯示。

以下表格總結了批量推理的擴展效果。

當從 5,000 擴展到 100,000 個樣本時，只需要八倍的計算時間。

對每個產品進行單獨的 LLM 調用進行分類，將使 100,000 個產品的推理時間增加約 40 倍，與批量處理方法相比。

覆蓋率的準確性保持穩定，成本大約呈線性擴展。

以下表格總結了 n-packing 的效果。Llama 2 的輸出長度限制為 2,048，最多可容納約 20 個打包。Anthropic 的 Claude 有更高的限制。我們對 1、5 和 10 個打包進行了 20 個真實樣本的測試，並選擇了所有模型和提示模板的結果。延遲的擴展效果在 Anthropic 的 Claude 模型系列中比 Llama 2 更明顯。當擴展輸出中的打包數量時，Anthropic 的 Claude 顯示出更好的泛化能力。

我們僅對 Llama 2 模型進行了少量測試，顯示出比零-shot 更高的準確性。

定性結果

我們注意到以下定性結果：

• 人類評估 – 生成的類別由 GoDaddy 的專家進行了定性評估。這些類別被認為質量良好。
• 學習 – 我們在兩個單獨的調用中使用了 LLM：輸出生成和格式解析。我們觀察到：

在這個用例中，我們發現 Llama 2 在格式解析方面表現不佳，但在輸出生成方面相對有能力。為了保持一致並進行公平比較，我們要求在兩個調用中使用相同的 LLM——兩個步驟中的 API 調用應全部調用 llama2-13b-chat-v1，或者全部調用 anthropic.claude-instant-v1。然而，GoDaddy 選擇 Llama 2 作為類別生成的 LLM。在這個用例中，我們發現僅使用 Llama 2 進行輸出生成，並使用 Anthropic 的 Claude 進行格式解析是合適的，因為 Llama 2 的模型能力相對較低。

通過提示工程改善格式解析（JSON 格式指令至關重要）以減少延遲。例如，使用 Anthropic 的 Claude-Instant 在 20 測試集上，並平均多個提示模板，延遲可以減少約 77%（從 90 秒減少到 20 秒）。這直接消除了使用經過微調的 LLM 的必要性。

Llama2 – 我們觀察到以下：

• Llama2-13b 和 Llama2-70b 模型都需要完整的指令作為 format_instruction() 在零-shot 提示中。
• Llama2-13b 在內容覆蓋率和格式方面似乎較差（例如，它無法正確轉義字符，\\“），這可能會導致顯著的解析時間和成本，並降低準確性。
• 當打包數量在 1、5 和 10 之間變化時，Llama 2 顯示出明顯的性能下降和不穩定性，顯示出與 Anthropic 的 Claude 模型系列相比較差的泛化能力。

Anthropic 的 Claude – 我們觀察到以下：

• Anthropic 的 Claude-Instant 和 Claude-v2，無論使用零-shot 還是少量示例提示，只需要部分格式指令，而不是完整的指令格式。這縮短了輸入長度，因此更具成本效益。它還顯示出 Anthropic 的 Claude 更好的遵循指令的能力。
• Anthropic 的 Claude 在打包數量在 1、5 和 10 之間變化時表現良好。

商業收穫

我們有以下幾個關鍵的商業收穫：

• 改善延遲 – 我們的解決方案在 12 分鐘內推理 5,000 個產品，這比 GoDaddy 的需求（1 小時內 5,000 個產品）快 80%。在 Amazon Bedrock 中使用批量推理顯示出高效的批量處理能力，並預期隨著 AWS 計劃部署更多雲實例而進一步擴展。擴展將導致時間和成本的節省。
• 更具成本效益 – 由生成式人工智慧創新中心使用 Anthropic 的 Claude-Instant 構建的解決方案比使用 Llama2-13b 的現有提案便宜 8%，同時提供 79% 的覆蓋率。
• 提高準確性 – 交付的產品在 5,000 和 100,000 的保留測試集上產生 97% 的類別覆蓋率，超過 GoDaddy 的 90% 需求。這個全面的框架能夠促進未來對當前模型參數和提示模板的迭代改進。
• 定性評估 – 通過 GoDaddy 的專家進行的人類評估顯示，類別生成的質量令人滿意。

技術收穫

我們有以下幾個關鍵的技術收穫：

• 該解決方案具有批量推理和近實時推理（每個產品 2 秒）能力，以及多個後端 LLM 選擇。
• Anthropic 的 Claude-Instant 在零-shot 中是明顯的贏家：
• 在 5,000 的保留測試集上，它在延遲、成本和準確性方面表現最佳。
• 它在更高的打包數量（每個查詢中的 SKU 數量）上顯示出更好的泛化能力，可能會進一步改善成本和延遲。

對提示模板的迭代顯示出所有這些模型的改善，這表明良好的提示工程是分類生成任務的實用方法。

在輸入方面，增加到 10-shot 可能進一步提高性能，如在小規模科學實驗中觀察到的，但也會將成本增加約 30%。因此，我們在大規模批量實驗中最多測試了 5-shot。

在輸出方面，增加到 10-packing 或甚至 20-packing（僅限 Anthropic 的 Claude；Llama 2 有 2,048 的輸出長度限制）可能進一步改善延遲和成本（因為更多的 SKU 可以共享相同的輸入指令）。

在這個用例中，我們看到 Anthropic 的 Claude 模型系列具有更好的準確性和泛化能力，例如：

• 最終類別覆蓋性能在 Anthropic 的 Claude-Instant 中更好。
• 當打包數量從 1、5 增加到 10 時，Anthropic 的 Claude-Instant 在延遲和準確性穩定性方面表現優於 Llama 2。
• 為了實現該用例的最終類別，我們注意到 Anthropic 的 Claude 需要更短的提示輸入來遵循指令，並且在更高的打包數量上具有更長的輸出長度限制。

GoDaddy 的下一步

以下是 GoDaddy 團隊考慮的未來步驟建議：

• 數據集增強 – 聚合更大的真實示例集，並擴展程序評估以更好地監控和改進模型性能。相關地，如果產品名稱能夠通過領域知識進行標準化，則更乾淨的輸入也有助於改善 LLM 的回應。例如，產品名稱“<product_name> Power t-shirt, ladyfit vest or hoodie”可以提示 LLM 回應多個 SKU，而不是一個 SKU（類似地，“<product_name> – $5 或 $10 或 $20 或 $50 或 $100”）。
• 人類評估 – 增加人類評估以提供更高的生成質量和與期望結果的一致性。
• 微調 – 考慮微調作為增強類別生成的潛在策略，當更廣泛的訓練數據集可用時。
• 提示工程 – 探索自動提示工程技術以增強類別生成，特別是在額外的訓練數據可用時。
• 少量學習 – 探索動態少量選擇和根據模型參數知識製作上下文示例的技術，以增強 LLM 的少量學習能力。
• 知識整合 – 通過將 LLM 連接到知識庫（內部或外部數據庫），改善模型的輸出，並使其能夠整合更多相關信息。這可以幫助減少 LLM 的幻覺並增強回應的相關性。

結論

在這篇文章中，我們分享了生成式人工智慧創新中心團隊如何與 GoDaddy 合作，創建一個更準確且具成本效益的基於生成式人工智慧的解決方案，使用 Amazon Bedrock 的批量推理，幫助 GoDaddy 改善其現有的產品分類系統。我們實施了 n-packing 技術，並使用了 Anthropic 的 Claude 和 Meta Llama 2 模型來改善延遲。我們實驗了不同的提示以改善 LLM 的分類，發現 Anthropic 的 Claude 模型系列比 Llama 2 模型系列提供了更好的準確性和泛化能力。GoDaddy 團隊將在更大的數據集上測試這個解決方案，並評估從建議的方法生成的類別。

如果你有興趣與 AWS 生成式人工智慧創新中心合作，請隨時聯繫我們。

安全最佳實踐

參考文獻

關於作者

Vishal Singh 是 GoDaddy 數據與分析團隊的數據工程領導者。他的主要專注領域是通過應用數據工程工具和生成式人工智慧來構建數據產品並從中生成見解。

Yun Zhou 是 AWS 的應用科學家，他幫助進行研究和開發，以確保 AWS 客戶的成功。他致力於為各行各業開創解決方案，使用統計建模和機器學習技術。他的興趣包括生成模型和序列數據建模。

Meghana Ashok 是生成式人工智慧創新中心的機器學習工程師。她與客戶密切合作，指導他們開發安全、具成本效益和韌性的解決方案及基礎設施，以滿足他們的生成式人工智慧需求。

Karan Sindwani 是 AWS 的應用科學家，他與 AWS 客戶在不同領域合作，加速他們使用生成式人工智慧和 AWS 雲服務來解決商業挑戰。

Vidya Sagar Ravipati 是生成式人工智慧創新中心的科學經理，他利用自己在大規模分佈式系統方面的豐富經驗和對機器學習的熱情，幫助 AWS 客戶在不同的行業加速他們的 AI 和雲採用。