基準測試亞馬遜Nova和GPT-4o模型與FloTorch

根據 FloTorch.ai 的首席技術官 Dr. Hemant Joshi 的原始文章

最近，FloTorch 進行了一項評估，對比了 Amazon Nova 模型和 OpenAI 的 GPT-4o 的性能。

Amazon Nova 是一個新一代的先進基礎模型 (FMs)，提供前沿智慧和行業領先的價格效能。Amazon Nova 模型系列包括 Amazon Nova Micro、Amazon Nova Lite 和 Amazon Nova Pro，這些模型支持文字、圖片和視頻輸入，同時生成基於文字的輸出。這些模型為企業提供多種能力，平衡準確性、速度和成本效益。

FloTorch 使用其企業軟體，對 Amazon Nova 模型和 OpenAI 的 GPT-4o 模型進行了廣泛的比較，使用了綜合檢索增強生成 (CRAG) 基準數據集。FloTorch 的評估專注於三個關鍵因素——延遲、準確性和成本——涵蓋五個不同的主題。

基準研究的主要發現：

GPT-4o 在準確性上稍微優於 Amazon Nova Pro
Amazon Nova Pro 在效率上超過 GPT-4o，運行速度快 97%，成本效益高 65.26%
Amazon Nova Micro 和 Amazon Nova Lite 在準確性上比 GPT-4o-mini 高出 2 個百分點
在價格方面，Amazon Nova Micro 和 Amazon Nova Lite 分別比 GPT-4o-mini 便宜 10% 和 56.59%
Amazon Nova Micro 和 Amazon Nova Lite 的回應時間也更快，分別提高了 48% 和 26.60%

在這篇文章中，我們將更詳細地討論這些基準的發現。

對成本效益 AI 模型的需求日益增長

生成 AI 的領域正在迅速發展。OpenAI 在 2024 年 5 月推出了 GPT-4o，而 Amazon 在 2024 年 12 月的 AWS re:Invent 會議上介紹了 Amazon Nova 模型。儘管 GPT-4o 在 AI 社區中獲得了廣泛關注，但企業對 Amazon Nova 的興趣日益增加，因為它的延遲更低且成本效益更高。

大型語言模型 (LLMs) 通常能夠很好地回答用戶的問題，但有時會生成過於廣泛或不準確的回答。此外，LLMs 可能會提供超出公司特定上下文的答案，使其不適合某些企業用例。

今天，LLMs 最重要的應用之一是檢索增強生成 (RAG)，這使 AI 模型能夠基於企業知識庫（如 PDF、內部文件和結構化數據）來提供回應。這對於希望其 AI 系統在明確範圍內提供回應的企業來說是至關重要的需求。

為了更好地服務企業客戶，評估旨在回答三個關鍵問題：

Amazon Nova Pro 在延遲、成本和準確性方面與 GPT-4o 的比較如何？
Amazon Nova Micro 和 Amazon Nova Lite 在這些相同指標下的表現如何？
這些模型在不同產業領域的 RAG 用例中表現如何？

通過回答這些問題，評估為企業提供了選擇合適 AI 模型的可行見解——無論是優化速度、準確性還是成本效益。

CRAG 基準數據集概述

CRAG 數據集由 Meta 發布，用於測試五個領域的事實查詢，包含八種類型的問題和大量的問題-答案對。CRAG 數據集的五個領域是金融、體育、音樂、電影和開放（雜項）。八種不同的問題類型包括簡單、簡單_有條件、比較、聚合、集合、錯誤前提、後處理和多跳。以下表格提供了示例問題及其領域和問題類型。

領域
問題
問題類型

體育
在高爾夫球比賽中，你能攜帶少於最大數量的球棒嗎？
簡單

音樂
你能告訴我 Arlo Guthrie 在第 60 屆格萊美獎（2017 年）之前贏得了多少格萊美獎嗎？
簡單_有條件

開放
我可以在空氣炸鍋裡做餅乾嗎？
簡單

金融
Meta 在 2022 年有進行任何合併或收購嗎？
簡單_有條件

電影
在 2016 年，哪部電影因其視覺效果而在奧斯卡獲得獎項？
簡單_有條件

評估考慮了來自該數據集的 200 個查詢，代表五個領域和兩種類型的問題，簡單和簡單_有條件。這兩種類型的問題是用戶常見的，典型的 Google 搜索查詢，例如「你能告訴我 Arlo Guthrie 在第 60 屆格萊美獎（2017 年）之前贏得了多少格萊美獎嗎？」將不會給你正確的答案（1 個格萊美獎）。FloTorch 使用這些查詢及其正確答案創建了一個子集基準數據集。CRAG 數據集還為每個查詢提供了前五個搜索結果頁面。這五個網頁作為知識庫（源數據），限制了 RAG 模型的回應。目標是使用通用嵌入算法動態索引這五個網頁，然後使用檢索（和重新排名）策略從索引的知識庫中檢索數據片段，以推斷最終答案。

評估設置

RAG 評估管道由幾個關鍵組件組成，如下圖所示。

在這一部分，我們將更詳細地探討每個組件。

知識庫

FloTorch 使用 CRAG 數據集中為每個查詢提供的前五個 HTML 網頁作為知識庫源數據。HTML 頁面被解析以提取文本以進行嵌入階段。

分塊策略

FloTorch 使用固定的分塊策略，塊大小為 512 個標記（四個字符通常約為一個標記），並且塊之間有 10% 的重疊。接下來幾週將進行不同分塊策略、塊大小和百分比重疊的進一步實驗，並會更新這篇文章。

嵌入策略

FloTorch 在 Amazon Bedrock 上使用 Amazon Titan 文本嵌入 V2 模型，輸出向量大小為 1024。該模型的最大輸入標記限制為 8,192，系統成功地高效地嵌入了來自知識庫源數據的塊以及來自 CRAG 數據集的短查詢。Amazon Bedrock API 使得使用 Amazon Titan 文本嵌入 V2 進行數據嵌入變得簡單。

向量數據庫

FloTorch 選擇 Amazon OpenSearch 服務作為向量數據庫，因為它具有高性能指標。實施包括一個配置的三節點分片 OpenSearch 服務集群。每個配置的節點為 r7g.4xlarge，因其可用性和足夠的容量以滿足性能要求而被選中。FloTorch 在 OpenSearch 服務中使用 HSNW 索引。

檢索（和重新排名）策略

FloTorch 使用檢索策略，對檢索的塊使用 k 最近鄰 (k-NN) 的五個。實驗排除了重新排名算法，以確保檢索的塊在推斷提供的查詢答案時對兩個模型保持一致。以下代碼片段嵌入給定的查詢並將嵌入傳遞給搜索功能：

def search_results(interaction_ids: List[str], queries: List[str], k: int):
“””檢索查詢的搜索結果。”””
results = []
embedding_max_length = int(os.getenv(“EMBEDDING_MAX_LENGTH”, 1024))
normalize_embeddings = os.getenv(“NORMALIZE_EMBEDDINGS”, “True”).lower() == “true”

for interaction_id, query in zip(interaction_ids, queries):
try:
_, _, embedding = create_embeddings_with_titan_bedrock(query, embedding_max_length, normalize_embeddings)
results.append(search(interaction_id + ‘_titan’, embedding, k))
except Exception as e:
logger.error(f”處理查詢 {query} 時出錯: {e}”)
results.append(None)
return results

推斷

FloTorch 使用 OpenAI 的 GPT-4o 模型，使用可用的 API 金鑰，並使用 Amazon Nova Pro 模型與對話 API。GPT-4o 支持 128,000 的上下文窗口，而 Amazon Nova Pro 的上下文窗口為 300,000。GPT-4o 的最大輸出標記限制為 16,384，而 Amazon Nova Pro 的最大輸出標記限制為 5,000。基準實驗在未使用 Amazon Bedrock Guardrails 功能的情況下進行。實施使用 FloTorch 企業版本提供的通用網關，以便使用相同的功能進行一致的 API 調用，並均勻跟踪標記計數和延遲指標。推斷功能代碼如下：

def generate_responses(dataset_path: str, model_name: str, batch_size: int, api_endpoint: str, auth_header: str,
max_tokens: int, search_k: int, system_prompt: str):
“””生成查詢的回應。”””
results = []

for batch in tqdm(load_data_in_batches(dataset_path, batch_size), desc=”生成回應”):
interaction_ids = [item[“interaction_id”] for item in batch]
queries = [item[“query”] for item in batch]
search_results_list = search_results(interaction_ids, queries, search_k)

for i, item in enumerate(batch):
item[“search_results”] = search_results_list[i]

responses = send_batch_request(batch, model_name, api_endpoint, auth_header, max_tokens, system_prompt)

for i, response in enumerate(responses):
results.append({
“interaction_id”: interaction_ids[i],
“query”: queries[i],
“prediction”: response.get(“choices”, [{}])[0].get(“message”, {}).get(“content”) if response else None,
“response_time”: response.get(“response_time”) if response else None,
“response”: response,
})

return results

評估

兩個模型通過運行批量查詢進行評估。選擇了一批八個，以符合 Amazon Bedrock 配額限制以及 GPT-4o 的速率限制。查詢功能代碼如下：

def send_batch_request(batch: List[Dict], model_name: str, api_endpoint: str, auth_header: str, max_tokens: int,
system_prompt: str):
“””向 API 發送批量查詢。”””
headers = {“Authorization”: auth_header, “Content-Type”: “application/json”}
responses = []

for item in batch:
query = item[“query”]
query_time = item[“query_time”]
retrieval_results = item.get(“search_results”, [])

references = “# 參考文獻 \n” + “\n”.join(
[f”參考文獻 {_idx + 1}:\n{res[‘text’]}\n” for _idx, res in enumerate(retrieval_results)])
user_message = f”{references}\n——\n\n僅使用上述列出的參考文獻，回答以下問題：\n問題: {query}\n”

payload = {
“model”: model_name,
“messages”: [{“role”: “system”, “content”: system_prompt},
{“role”: “user”, “content”: user_message}],
“max_tokens”: max_tokens,
}

try:
start_time = time.time()
response = requests.post(api_endpoint, headers=headers, json=payload, timeout=25000)
response.raise_for_status()
response_json = response.json()
response_json[‘response_time’] = time.time() – start_time
responses.append(response_json)
except requests.RequestException as e:
logger.error(f”查詢的 API 請求失敗: {query}. 錯誤: {e}”)
responses.append(None)

return responses

在 CRAG 數據集上的基準測試

在這一部分，我們討論在 CRAG 數據集上的延遲、準確性和成本測量的基準測試。

延遲

每個查詢回應的延遲測量是通過計算兩個時間戳之間的差異來得出的：當 API 調用發送到推斷 LLM 時的時間戳，以及從推斷端點接收到整個回應的第二個時間戳。這兩個時間戳之間的差異決定了延遲。較低的延遲表示 LLM 性能更快，適合需要快速回應時間的應用。研究表明，通過優化和緩存技術，可以進一步降低兩個模型的延遲；然而，評估專注於測量兩個模型的即時延遲性能。

準確性

FloTorch 使用了 CRAG 基準提供的 local_evaluation.py 腳本的修改版本進行準確性評估。該腳本經過增強，以提供正確、不正確和缺失回應的正確分類。評估腳本中的默認 GPT-4o 評估 LLM 被 mixtral-8x7b-instruct-v0:1 模型 API 替換。對腳本的其他修改使得能夠監控輸入和輸出標記以及延遲，如前所述。

成本

成本計算相對簡單，因為 Amazon Nova Pro 和 GPT-4o 都已公開每百萬個輸入和輸出標記的價格。計算方法涉及將輸入標記乘以相應的費率，並對輸出標記進行相同的處理。運行 200 個查詢的總成本是通過將輸入標記和輸出標記的成本相加來確定的。OpenSearch 服務的集群成本在此分析中被排除，因為成本比較僅專注於 Amazon Nova Pro 和 GPT-4o LLM 之間的推斷層面。

結果

以下表格總結了結果。

.
Amazon Nova Pro
GPT-4o
觀察

CRAG 數據集子集的準確性

51.50%

（200 個中有 103 個正確回應）

53.00%

（200 個中有 106 個正確回應）

GPT-4o 在準確性上比 Amazon Nova Pro 高出 1.5%

運行 200 個查詢的推斷成本
$0.00030205
$0.000869537
Amazon Nova Pro 比 GPT-4o 節省 65.26% 的成本

平均延遲（秒）
1.682539835
2.15615045
Amazon Nova Pro 比 GPT-4o 快 21.97%

輸入和輸出標記的平均數
1946.621359
1782.707547
GPT-4o 的回應通常比 Amazon Nova 的回應短

對於簡單查詢，Amazon Nova Pro 和 GPT-4o 的準確性相似（分別為 55 和 56 個正確回應），但對於有條件的簡單查詢，GPT-4o 的表現稍微優於 Amazon Nova Pro（50 對 48 個正確答案）。想像一下，你是某個組織的一部分，運行一個 AI 助手服務，每月處理 1,000 個問題，來自 10,000 名用戶（每月 10,000,000 次查詢）。與 GPT-4o 相比，Amazon Nova Pro 將為你的組織每月節省 $5,674.88（每年 $68,098）。

讓我們看看 Amazon Nova Micro、Amazon Nova Lite 和 GPT-4o mini 模型在相同數據集上的類似結果。

Amazon Nova Lite
Nove Micro
GPT-4o mini
觀察

CRAG 數據集子集的準確性

52.00%

（200 個中有 104 個正確回應）

54.00%

（200 個中有 108 個正確回應）

50.00%

（200 個中有 100 個正確回應）

Amazon Nova Lite 和 Amazon Nova Micro 分別比 GPT-4o mini 高出 2 和 4 分

運行 200 個查詢的推斷成本

$0.00002247

（比 GPT-4o mini 便宜 56.59%）

$0.000013924

（比 GPT-4o mini 便宜 73.10%）

$0.000051768
Amazon Nova Lite 和 Amazon Nova Micro 分別比 GPT-4o mini 便宜 56.59% 和 73.10%

平均延遲

（秒）

1.553371465

（比 GPT-4o mini 快 26.60%）

1.6828564

（比 GPT-4o mini 快 20.48%）

2.116291895
Amazon Nova 模型至少比 GPT-4o mini 快 20%

輸入和輸出標記的平均數
1930.980769
1940.166667
1789.54
GPT-4o mini 返回的答案較短

Amazon Nova Micro 在準確性上比 GPT-4o mini 更快且更便宜。如果你運行一個每月處理約 1,000 萬次查詢的服務，這將平均為你節省 73% 的費用，而這些費用是你為 GPT-4o mini 模型稍微不準確的結果所支付的。

結論

根據這些 RAG 案例的測試，Amazon Nova 模型在成本和延遲上都顯著低於 GPT-4o 和 GPT-4o mini 模型，並且產生可比或更高的準確性。FloTorch 正在繼續對其他相關 LLM 進行進一步實驗以進行比較。未來的研究將包括對不同查詢類型的額外實驗，例如比較、聚合、集合、錯誤前提、後處理和多跳查詢。

立即在 Amazon Bedrock 控制台上開始使用 Amazon Nova。了解更多信息，請訪問 Amazon Nova 產品頁面。

關於 FloTorch

FloTorch.ai 正在幫助企業客戶以安全和可擴展的方式設計和管理代理工作流程。FloTorch 的使命是幫助企業在端到端的生成 AI 管道中做出數據驅動的決策，包括但不限於模型選擇、向量數據庫選擇和評估策略。FloTorch 提供開源版本，供客戶進行可擴展的實驗，使用不同的分塊、嵌入、檢索和推斷策略。開源版本在客戶的 AWS 帳戶上運行，因此你可以使用自己的專有數據在 AWS 帳戶上進行實驗。有興趣的用戶可以從 AWS Marketplace 或 GitHub 嘗試 FloTorch。FloTorch 還為在雲平台上進行 LLM 模型和向量數據庫的可擴展實驗提供企業版本。企業版本還包括一個通用網關，具有模型註冊功能，以自定義定義新的 LLM 和推薦引擎，以建議新的 LLM 和代理工作流程。如需更多信息，請通過 info@flotorch.ai 與我們聯繫。

關於作者

Prasanna Sridharan 是 AWS 的首席生成 AI/ML 架構師，專注於為企業客戶設計和實施 AI/ML 和生成 AI 解決方案。他熱衷於幫助 AWS 客戶構建創新的生成 AI 應用，專注於創建可擴展的尖端 AI 解決方案，以推動業務轉型。你可以在 LinkedIn 上與 Prasanna 聯繫。