百萬token上下文視窗也殺不死向量數據庫？CPU笑了

今天小編分享的科學經驗：百萬token上下文視窗也殺不死向量數據庫？CPU笑了，歡迎閲讀。

"Claude 3、Gemini 1.5，是要把 RAG（檢索增強生成）給搞死了嗎？"

随着新晉大語言模型們的上下文視窗（Context Window）變得越發得長，業界人士針對"RAG 終将消亡 "觀點的讨論也是愈演愈烈。

之所以如此，是因為它們二者都是為了解決大模型的幻覺問題（即那種一本正經地胡説八道），可以説是屬于兩種不同頂尖技術流派之間的對峙。

一方面，以 Claude 3、Gemini 1.5 為代表的流派，陸續支持 200K 和 100 萬 token 的上下文視窗，用大力出奇迹的方式讓大模型能夠精準檢索到關鍵信息來提供準确答案。

另一方面，RAG 則是一種外挂知識庫，無縫集成外部資源，為大語言模型提供了準确和最新的知識，以此來提高生成内容的質量。

誠然有很多人在體驗過超長上下文視窗大模型後，覺得這種方式已經讓 AI 在回答的準确性上做到了突破，無需再用 RAG：

而且從 Claude、Gemini 等玩家在測評榜單的數據來看，在回答準确性上的成績也是屢創新高。

但事實真是如此嗎？不見得。

因為在此期間，與 "RAG 要消亡了 "背道而馳的聲音也是越發堅定：

從各種評價和讨論來看，這派的觀點可以概括為——你（長上下文視窗）強任你強，但缺點也是蠻明顯的。

有網友便列舉了長上下文視窗的四大通病（四個 V）：

Velocity（速度）：基于 Transformer 的大型模型，在檢索長上下文時要想達到亞秒級的速度響應仍然具有挑戰性。

Value（價值）：長上下文視窗畢竟屬于大力出奇迹，但它高支出的特點對于日常應用來説，在成本上是不切實際的。

Volume（體量）：即使上下文視窗越發得長，但和全網龐大的非結構化數據相比就是小巫見大巫；尤其是企業級動辄 GB、TB 這種體量，還涉及眾多私有數據的情形。

Variety（多樣性）：現實世界的用例不僅涉及非結構化數據，還包括各種結構化數據，它們可能不容易被 LLM 捕獲用來訓練；而且企業場景中往往知識是需要實時變化的。

相反，RAG 因為得益于其關鍵結構之一的向量數據庫，反倒是可以較好地規避上述的 "4V" 缺陷。

向量數據庫讓大模型能夠快速有效地檢索和處理大量的向量數據，從而增強了模型的整體性能和應用範圍。

一言蔽之，關鍵看能不能 " 快好省 " 地用起來。

△圖源：由 DALL · E 3 生成

那麼以 RAG、向量數據庫為代表的這一派技術，在現實場景中到底用得如何呢？

為了解答這個問題，我們找到了剛剛發布相關創新成果的騰訊雲，了解了一下向量數據庫以全新構建模式，作為 AI 知識庫能為大模型等帶來哪些收益？

向量數據庫，已成大模型時代數據中樞

正如我們剛才提到的，RAG 的重要組成部分就是外挂的專業知識庫，因此這個知識庫中需得涵蓋能夠精準回答問題所需要的專業知識和規則。

而要構建這個外挂知識庫，常見的方法包括向量數據庫、知識圖譜，甚至也可以直接把 ElasticSearch 數據接入。

但由于向量數據庫具備對高維向量的檢索能力，能夠跟大模型很好地匹配，效果也是較好的那個，所以成為了目前主流的形式。

△各類數據轉化為向量後存入向量數據庫

向量數據庫可以對向量化後的數據進行高效的存儲、處理與管理。

如上圖展示的那樣，數據向量化過程利用了諸如詞向量模型和卷積神經網絡等人工智能技術。

通過 Embedding 過程，這些技術能夠将文本、影像、音視頻等多種形式的數據轉換成向量形式，并将其存儲在向量數據庫中。

至于向量數據庫的查詢功能，則是通過計算向量間的相似度來實現的。

而騰訊雲的創新成果，就是騰訊雲向量數據庫（Tencent Cloud VectorDB），它能為多維向量數據提供高效的存儲、檢索和分析能力。

其主要特點包括：

Embedding 功能：數據寫入 / 檢索自動向量化，無需關注向量生成過程，這意味着使用門檻被狠狠地打了下去。

高性能：單索引支持千億級向量數據規模，可支持百萬級 QPS 及毫秒級查詢延遲。

低成本：只需簡單操作就可以創建向量數據庫實例，全流程平台托管，不需要額外的開銷成本。

簡單易用：不僅向量檢索能力豐富，而且通過 API 就能快速操作和開發。

從這些特性不難看出，它恰好補齊了我們剛才提到的上下文視窗方式的一些短板。

也正是憑借這些優勢，騰訊雲向量數據庫能夠和大語言模型無縫對接：

用户可以将私有數據經過文本處理和向量化後，存儲至騰訊雲向量數據庫，從而創建一個定制化的外部知識庫。

在後續的查詢任務中，這個知識庫也能為大模型提供必要的提示，從而輔助 AGI 和 AIGC 等應用產生更精确的輸出。

由此可見，站在大模型時代之下，向量數據庫已然不僅僅是一種技術工具，更是連接數據與 AI 的橋梁，是大模型時代的數據中樞，是整個 AI 平台不可或缺的一部分。

借助這一項項突破，騰訊雲 VectorDB 不僅支持多種索引類型和相似度計算方法，還具有單索引支持千億級向量規模、百萬級每秒查詢率（Queries-per-second，QPS）及毫秒級查詢時延等優勢。

不過這樣的向量數據庫又是如何搭建起來的呢？

騰訊雲還有一個殺手锏——

與英特爾合作，以至強 CPU 平台為基礎，通過軟、硬體兩方面的并行優化，為向量數據庫提供顯著的性能加速。

CPU，向量數據庫的好搭檔

向量數據庫搭配 CPU，其實不只是騰訊雲一家的選擇，而是整個行業現階段的主流共識：

只有面臨海量高并發需求時，使用 GPU 查詢向量數據庫才更劃算。

究其原因，還要從向量數據庫和 CPU 各自的特點，以及實際業務流程分開來看。

首先從向量數據庫的角度分析，其原理上屬于密集型計算負載，需要大量訪問内存中加載的向量。

向量數據庫與傳統數據庫最大的區别在于不是精确匹配，而是依靠各種相似度度量方法來找到與給定查詢最相近的向量，這就涉及大量的相似度計算，如點積、歐式距離、餘弦相似度等。

如此一來，除了運算速度之外，内存訪問速度也很容易成為向量數據庫運行中的瓶頸所在。

帶着這個背景來看，CPU 不但性能夠用，還占據了内存訪問快的優勢。

對于中等或更少并發請求來説，雖然 GPU 單論運算速度更快，但 CPU 較低的内存訪問時間足以抵消這個差距。

接下來，再從 CPU 的角度來看，它是如何來滿足向量數據庫運算性能需求的。

前面提到向量數據庫屬于密集型計算負載，談到 CPU 上相關的加速技術，就不得不提我們的老朋友——從 2017 年第一代至強 ® 可擴展處理器開始就内置在這個 CPU 產品家族中的英特爾 ® AVX-512 指令集。

這是一種單指令多數據（Single Instruction Multiple Data，SIMD）指令集，擁有 512 位的寄存器寬度，可以在一次操作中處理高維向量的所有數據。

△英特爾 ® SSE、英特爾 ® AVX2 和英特爾 ® AVX-512 之間的寄存器大小和計算效率的差異説明

另一項可為向量數據庫帶來顯著性能提升的是英特爾 ® AMX （高級矩陣擴展）加速引擎，它是從第四代至強 ® 可擴展處理器開始内置的加速技術，在剛剛發布的第五代至強 ® 可擴展處理器上也是加速器的 "C 位 "，是大家熟悉的 CPU 用來加速 AI 應用，尤其是推理應用的核心技術。

AMX 引入的用于矩陣處理的新框架，也能高效地處理向量數據庫查詢所需的矩陣乘法運算，并在單詞運算中處理更大矩陣。

△英特爾 ® AMX 架構由 2D 寄存器檔案 ( TILE ) 和 TMUL 組成

在這基礎上，英特爾還與騰訊雲合作，針對騰訊雲 VectorDB 常用的計算庫做了專門的優化方案。

例如針對流行的 FAISS 相似度搜索（Facebook AI Similarity Search ），借助英特爾 ® AVX-512 為其中不同的索引提出不同的優化方案，包括面向 IVF- FLAT 算法的 ReadOnce（單次讀取）和 Discretization（離散化）兩種優化思路，來執行用英特爾 ® AVX-512 加速 IVF- PQFastScan 算法和 IVF-SQ 索引的優化方案。

針對另一種流行代碼庫 HNSWlib，使用英特爾 ® AVX-512 不僅能加速向量檢索性能，同時還能使召回率保持平穩。

實地測試表明，在第三代至強 ® 可擴展處理器平台上啓用英特爾 ® AVX-512 優化後，相比沒有啓用優化時，使用 IVF-PQFastScan 算法執行向量檢索時的 QPS 性能提升了約一倍；而把計算平台更新到目前最新的第五代至強 ® 可擴展處理器平台後，性能更是會提升 2.3 倍！