作者：Arm 基礎設施事業部 AI 解決方案架構師 Na Li 等

你是否好奇如何防止人工智能 (AI) 聊天機器人給出過時或不準確的答案？檢索增強生成 (Retrieval-Augmented Generation, RAG) 技術提供了一種強大的解決方案，能夠顯著提升答案的準確性和相關性。

本文將探討 RAG 的性能優勢，并分享如何在基于 Arm Neoverse 平臺的 Google Axion 處理器上構建 RAG 應用，以優化 AI 工作負載。在本文的測試中，Google Axion 處理器相較于 x86 架構處理器，性能提升了 2.5 倍，并節省了 64% 的成本。Google Axion 處理器通過更好的 RAG 性能加速推理過程，從而實現更快的知識檢索、更低的響應延遲和更高效的 AI 推理，這對于實時、動態 AI 應用至關重要。

了解 RAG：高效的 AI 文本生成方法

RAG 是一款主流 AI 框架，能夠實時檢索相關外部知識，從而提升大語言模型 (LLM) 生成文本的質量和相關性。與僅依賴靜態預訓練數據集的方法不同，RAG 動態集成了最新外部資源信息，能夠生成更精確且貼近上下文的輸出結果。這使得 RAG 在實際應用場景中表現出色，例如客服聊天機器人、智能體工具和動態內容生成等場景。

何時選擇 RAG 而非微調或重新訓練？

基礎 LLM 通過類似人類的文本生成功能徹底改變了 AI 領域，但其有效性取決于模型是否擁有企業所需的最新信息。對經過預訓練的 LLM 模型進行重新訓練和微調是集成額外知識的兩種常用方法。重新訓練 LLM 是一個資源密集型的復雜過程；而微調則能夠使用特定數據集對 LLM 進行訓練，調整模型的權重，以更好地完成目標任務。不過，模型仍然需要定期重新部署，以保持與時俱進。

通常，在將 LLM 納入 AI 戰略時，必須評估 LLM 的能力和局限性。主要考慮因素包括：

訓練數據集的局限性：對于訓練數據集未包含的主題，LLM 可能難以提供準確或最新的信息。

資源需求高：重新訓練這些大模型需要大量的算力和工程資源，使得頻繁更新難以實施。

對內部知識的訪問受到限制：由于企業的主要業務數據受到防火墻的保護，因此 LLM 無法通過定期重新訓練納入專有信息，這可能會限制 LLM 在企業內部使用時的相關性。

RAG 的優勢

RAG 無需修改 LLM，只需利用外部數據源更新知識庫，將動態信息檢索與語言模型的生成能力相結合。如果你所在的領域知識經常變化，那么 RAG 是保持準確性和相關性，并減少 LLM 幻覺的理想解決方案。

RAG 的實際應用：對比分析

在以下所舉的例子中，比較了通用 LLM（左）和經過 RAG（右）增強的聊天機器人。左圖中，由于信息過時或缺乏特定領域的知識，聊天機器人難以準確回答用戶的詢問；而 RAG 增強型聊天機器人能夠從上傳的文件中檢索最新信息，提供準確且相關的回復。

圖 1：通過 LLM 實現的聊天機器人（左）

和經過 RAG 增強的聊天機器人（右）

為何選擇 Axion 來實現 RAG 解決方案

基于 Arm Neoverse 平臺的 Google Axion 處理器為運行 LLM 的 AI 推理功能提供了理想平臺，該處理器能夠以高性能和高效率支持 RAG 應用的運行。

優化 AI 加速：基于 Neoverse 平臺的 CPU 具有高吞吐量向量處理和矩陣乘法功能，這對于高效處理 RAG 至關重要。

云計算的效率和可擴展性：基于 Neoverse 平臺的 CPU 可最大限度地提高每瓦性能，在高速處理和能效之間取得平衡。因此，特別適用于需要在云端快速推理并兼顧成本效益的 RAG 應用。基于 Neoverse 的處理器還可用于擴展 AI 工作負載，確保無縫集成各種 RAG 用例。

面向 AI 開發者的軟件生態系統：對于希望在基于 Arm 架構的基礎設施上利用最新 AI 功能的開發者，Arm Kleidi 技術能夠顯著提升 RAG 應用的性能和效率。Arm Kleidi 已經集成到 PyTorch、TensorFlow 和 llama.cpp 等開源 AI 和機器學習 (ML) 框架中，使開發者能夠實現開箱即用的默認推理性能，而無需使用供應商插件或進行復雜的優化。

這些特性的結合帶來了顯著的性能提升，首個基于 Google Axion 的云虛擬機 C4A 與 x86 同類方案相比，大幅提升了基于 CPU 的 AI 推理和通用云工作負載的性能，使 C4A 虛擬機成為在 Google Cloud 上運行 RAG 應用的理想選擇。

Google Axion 性能基準測試

使用 RAG 系統進行推理涉及兩個關鍵階段：信息檢索和生成響應。

信息檢索：系統搜索向量數據庫，根據用戶的查詢找到相關內容。

生成響應：檢索到的內容與用戶查詢相結合，生成與上下文相關的準確回復。

一般來說，檢索速度取決于數據庫的大小和搜索算法的效率。在基于 Neoverse 平臺的 CPU 上運行時，經優化的算法可在幾毫秒內返回結果。然后，將檢索到的信息與用戶的輸入相結合，構建新的提示詞，并將其發送給 LLM 進行推理和生成響應。相較于檢索階段，生成響應階段耗時更長，RAG 系統的整體推理延遲在很大程度上受 LLM 推理速度的影響。

本次測試使用 llama.cpp 基準和 Llama 3.1 8B 模型（Q4_0 量化方案）評估了多個 Google Cloud 虛擬機的 RAG 推理性能。使用 48 個線程進行了所有測試，輸入詞元 (token) 大小為 2058，輸出詞元大小為 256。以下是測試配置：

Google Axion (C4A, Neoverse V2): 在 c4a-standard-48 實例上進行了評估。

Intel Xeon (C4, Emerald Rapids): 在 c4-standard-48 上進行了性能測試。

AMD EPYC (C3D, Genoa): 在啟用 48 個核心的 c3d-standard-60 上進行了測試。

Axion 處理器實現更快處理與更高效率

推理性能根據提示詞處理速度和詞元生成速度來測定。圖表 1 的基準測試結果表明，與當前一代 x86 實例相比，基于 Google Axion 的 C4A 虛擬機在提示詞處理和詞元生成方面實現了高達 2.5 倍的性能提升。

圖表 1：運行 Llama 3.1 8B/Q4 模型時，提示詞處理（左）

和詞元生成（右）與當前一代 x86 實例的性能比較

成本效益：降低 RAG 推理成本

為了評估推理任務的實例成本，還測量了從提交提示詞到生成響應的延遲。有幾個因素會影響延遲，包括檢索速度、提示處理效率、詞元生成速率、輸入和輸出詞元大小以及用戶批處理規模。由于信息檢索延遲通常在毫秒級，與其他因素相比可以忽略不計，因此未納入計算。批次大小選擇為 1，以確保在單個用戶級別進行公平的比較。為了與基準測試保持一致，測試中將輸入和輸出詞元大小分別設置為 2048 和 256。首先通過提示詞編碼速度和詞元生成速度計算提示詞處理和詞元生成的延遲，然后根據 Google Cloud 上的實例定價圖表[3]計算每次請求的成本，再將這些數字歸一化為所有三個實例的最大成本。

圖表 2 中的結果表明，基于 Axion 的虛擬機可節省高達 64% 的成本，處理每次請求所需的成本僅為當前一代 x86 實例的三分之一左右。

圖表 2：使用 RAG 處理推理請求的歸一化成本對比注

注：成本計算基于截至 2025 年 3 月 5 日公布的實例定價，可參見

https://cloud.google.com/compute/vm-instance-pricing

快速入門：基于 Arm 平臺構建 RAG 應用

以 Neoverse 平臺為核心，Google Axion 賦能的實例能以更低的成本提供高性能，助力企業構建可擴展且高效的 RAG 應用，同時與 x86 方案相比顯著降低了基礎設施開支。

為了幫助開發者快速入門，Arm 開發了分步演示和 Learning Path 教程，以便開發者使用自己選擇的 LLM 和數據源構建基本的 RAG 系統。

以下資源能夠幫助剛接觸 Arm 生態系統的開發者順利踏上開發旅程：

通過 Arm Learning Path 遷移到 Axion：依照詳細的指南和最佳實踐，簡化向 Axion 實例的遷移進程。

Arm Software Ecosystem Dashboard：及時了解 Arm 平臺上支持的最新軟件信息。

Arm 開發者中心：無論你是剛接觸 Arm 平臺，還是正在尋找資源來開發高性能軟件解決方案，Arm 開發者中心應有盡有，可以幫助開發者構建更好的軟件，為數十億設備提供豐富的體驗。在 Arm 不斷壯大的全球開發者社區中，開發者可以訪問資源、交流學習和提問探討。

還等什么？即刻開啟你的遷移之旅，利用 Arm Neoverse 平臺釋放云和 AI 工作負載的全部潛力！