作者：Arm 基礎(chǔ)設(shè)施事業(yè)部 AI 解決方案架構(gòu)師 Na Li 等

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

本文將探討 RAG 的性能優(yōu)勢(shì)，并分享如何在基于 Arm Neoverse 平臺(tái)的 Google Axion 處理器上構(gòu)建 RAG 應(yīng)用，以優(yōu)化 AI 工作負(fù)載。在本文的測(cè)試中，Google Axion 處理器相較于 x86 架構(gòu)處理器，性能提升了 2.5 倍，并節(jié)省了 64% 的成本。Google Axion 處理器通過(guò)更好的 RAG 性能加速推理過(guò)程，從而實(shí)現(xiàn)更快的知識(shí)檢索、更低的響應(yīng)延遲和更高效的 AI 推理，這對(duì)于實(shí)時(shí)、動(dòng)態(tài) AI 應(yīng)用至關(guān)重要。

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

RAG 是一款主流 AI 框架，能夠?qū)崟r(shí)檢索相關(guān)外部知識(shí)，從而提升大語(yǔ)言模型 (LLM) 生成文本的質(zhì)量和相關(guān)性。與僅依賴靜態(tài)預(yù)訓(xùn)練數(shù)據(jù)集的方法不同，RAG 動(dòng)態(tài)集成了最新外部資源信息，能夠生成更精確且貼近上下文的輸出結(jié)果。這使得 RAG 在實(shí)際應(yīng)用場(chǎng)景中表現(xiàn)出色，例如客服聊天機(jī)器人、智能體工具和動(dòng)態(tài)內(nèi)容生成等場(chǎng)景。

何時(shí)選擇 RAG 而非微調(diào)或重新訓(xùn)練？

基礎(chǔ) LLM 通過(guò)類似人類的文本生成功能徹底改變了 AI 領(lǐng)域，但其有效性取決于模型是否擁有企業(yè)所需的最新信息。對(duì)經(jīng)過(guò)預(yù)訓(xùn)練的 LLM 模型進(jìn)行重新訓(xùn)練和微調(diào)是集成額外知識(shí)的兩種常用方法。重新訓(xùn)練 LLM 是一個(gè)資源密集型的復(fù)雜過(guò)程；而微調(diào)則能夠使用特定數(shù)據(jù)集對(duì) LLM 進(jìn)行訓(xùn)練，調(diào)整模型的權(quán)重，以更好地完成目標(biāo)任務(wù)。不過(guò)，模型仍然需要定期重新部署，以保持與時(shí)俱進(jìn)。

通常，在將 LLM 納入 AI 戰(zhàn)略時(shí)，必須評(píng)估 LLM 的能力和局限性。主要考慮因素包括：

訓(xùn)練數(shù)據(jù)集的局限性：對(duì)于訓(xùn)練數(shù)據(jù)集未包含的主題，LLM 可能難以提供準(zhǔn)確或最新的信息。

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

對(duì)內(nèi)部知識(shí)的訪問(wèn)受到限制：由于企業(yè)的主要業(yè)務(wù)數(shù)據(jù)受到防火墻的保護(hù)，因此 LLM 無(wú)法通過(guò)定期重新訓(xùn)練納入專有信息，這可能會(huì)限制 LLM 在企業(yè)內(nèi)部使用時(shí)的相關(guān)性。

RAG 的優(yōu)勢(shì)

RAG 無(wú)需修改 LLM，只需利用外部數(shù)據(jù)源更新知識(shí)庫(kù)，將動(dòng)態(tài)信息檢索與語(yǔ)言模型的生成能力相結(jié)合。如果你所在的領(lǐng)域知識(shí)經(jīng)常變化，那么 RAG 是保持準(zhǔn)確性和相關(guān)性，并減少 LLM 幻覺的理想解決方案。

RAG 的實(shí)際應(yīng)用：對(duì)比分析

在以下所舉的例子中，比較了通用 LLM（左）和經(jīng)過(guò) RAG（右）增強(qiáng)的聊天機(jī)器人。左圖中，由于信息過(guò)時(shí)或缺乏特定領(lǐng)域的知識(shí)，聊天機(jī)器人難以準(zhǔn)確回答用戶的詢問(wèn)；而 RAG 增強(qiáng)型聊天機(jī)器人能夠從上傳的文件中檢索最新信息，提供準(zhǔn)確且相關(guān)的回復(fù)。

圖 1：通過(guò) LLM 實(shí)現(xiàn)的聊天機(jī)器人（左）

和經(jīng)過(guò) RAG 增強(qiáng)的聊天機(jī)器人（右）

為何選擇 Axion 來(lái)實(shí)現(xiàn) RAG 解決方案

基于 Arm Neoverse 平臺(tái)的 Google Axion 處理器為運(yùn)行 LLM 的 AI 推理功能提供了理想平臺(tái)，該處理器能夠以高性能和高效率支持 RAG 應(yīng)用的運(yùn)行。

優(yōu)化 AI 加速：基于 Neoverse 平臺(tái)的 CPU 具有高吞吐量向量處理和矩陣乘法功能，這對(duì)于高效處理 RAG 至關(guān)重要。

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

面向 AI 開發(fā)者的軟件生態(tài)系統(tǒng)：對(duì)于希望在基于 Arm 架構(gòu)的基礎(chǔ)設(shè)施上利用最新 AI 功能的開發(fā)者，Arm Kleidi 技術(shù)能夠顯著提升 RAG 應(yīng)用的性能和效率。Arm Kleidi 已經(jīng)集成到 PyTorch、TensorFlow 和 llama.cpp 等開源 AI 和機(jī)器學(xué)習(xí) (ML) 框架中，使開發(fā)者能夠?qū)崿F(xiàn)開箱即用的默認(rèn)推理性能，而無(wú)需使用供應(yīng)商插件或進(jìn)行復(fù)雜的優(yōu)化。

這些特性的結(jié)合帶來(lái)了顯著的性能提升，首個(gè)基于 Google Axion 的云虛擬機(jī) C4A 與 x86 同類方案相比，大幅提升了基于 CPU 的 AI 推理和通用云工作負(fù)載的性能，使 C4A 虛擬機(jī)成為在 Google Cloud 上運(yùn)行 RAG 應(yīng)用的理想選擇。

Google Axion 性能基準(zhǔn)測(cè)試

使用 RAG 系統(tǒng)進(jìn)行推理涉及兩個(gè)關(guān)鍵階段：信息檢索和生成響應(yīng)。

信息檢索：系統(tǒng)搜索向量數(shù)據(jù)庫(kù)，根據(jù)用戶的查詢找到相關(guān)內(nèi)容。

生成響應(yīng)：檢索到的內(nèi)容與用戶查詢相結(jié)合，生成與上下文相關(guān)的準(zhǔn)確回復(fù)。

一般來(lái)說(shuō)，檢索速度取決于數(shù)據(jù)庫(kù)的大小和搜索算法的效率。在基于 Neoverse 平臺(tái)的 CPU 上運(yùn)行時(shí)，經(jīng)優(yōu)化的算法可在幾毫秒內(nèi)返回結(jié)果。然后，將檢索到的信息與用戶的輸入相結(jié)合，構(gòu)建新的提示詞，并將其發(fā)送給 LLM 進(jìn)行推理和生成響應(yīng)。相較于檢索階段，生成響應(yīng)階段耗時(shí)更長(zhǎng)，RAG 系統(tǒng)的整體推理延遲在很大程度上受 LLM 推理速度的影響。

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

Google Axion (C4A, Neoverse V2): 在 c4a-standard-48 實(shí)例上進(jìn)行了評(píng)估。

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

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

Axion 處理器實(shí)現(xiàn)更快處理與更高效率

推理性能根據(jù)提示詞處理速度和詞元生成速度來(lái)測(cè)定。圖表 1 的基準(zhǔn)測(cè)試結(jié)果表明，與當(dāng)前一代 x86 實(shí)例相比，基于 Google Axion 的 C4A 虛擬機(jī)在提示詞處理和詞元生成方面實(shí)現(xiàn)了高達(dá) 2.5 倍的性能提升。

圖表 1：運(yùn)行 Llama 3.1 8B/Q4 模型時(shí)，提示詞處理（左）

和詞元生成（右）與當(dāng)前一代 x86 實(shí)例的性能比較

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

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

圖表 2 中的結(jié)果表明，基于 Axion 的虛擬機(jī)可節(jié)省高達(dá) 64% 的成本，處理每次請(qǐng)求所需的成本僅為當(dāng)前一代 x86 實(shí)例的三分之一左右。

圖表 2：使用 RAG 處理推理請(qǐng)求的歸一化成本對(duì)比注

注：成本計(jì)算基于截至 2025 年 3 月 5 日公布的實(shí)例定價(jià)，可參見

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

快速入門：基于 Arm 平臺(tái)構(gòu)建 RAG 應(yīng)用

以 Neoverse 平臺(tái)為核心，Google Axion 賦能的實(shí)例能以更低的成本提供高性能，助力企業(yè)構(gòu)建可擴(kuò)展且高效的 RAG 應(yīng)用，同時(shí)與 x86 方案相比顯著降低了基礎(chǔ)設(shè)施開支。

為了幫助開發(fā)者快速入門，Arm 開發(fā)了分步演示和 Learning Path 教程，以便開發(fā)者使用自己選擇的 LLM 和數(shù)據(jù)源構(gòu)建基本的 RAG 系統(tǒng)。

以下資源能夠幫助剛接觸 Arm 生態(tài)系統(tǒng)的開發(fā)者順利踏上開發(fā)旅程：

通過(guò) Arm Learning Path 遷移到 Axion：依照詳細(xì)的指南和最佳實(shí)踐，簡(jiǎn)化向 Axion 實(shí)例的遷移進(jìn)程。

Arm Software Ecosystem Dashboard：及時(shí)了解 Arm 平臺(tái)上支持的最新軟件信息。

Arm 開發(fā)者中心：無(wú)論你是剛接觸 Arm 平臺(tái)，還是正在尋找資源來(lái)開發(fā)高性能軟件解決方案，Arm 開發(fā)者中心應(yīng)有盡有，可以幫助開發(fā)者構(gòu)建更好的軟件，為數(shù)十億設(shè)備提供豐富的體驗(yàn)。在 Arm 不斷壯大的全球開發(fā)者社區(qū)中，開發(fā)者可以訪問(wèn)資源、交流學(xué)習(xí)和提問(wèn)探討。

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