百萬(wàn)token上下文窗口也殺不死向量數(shù)據(jù)庫(kù)?CPU笑了
“Claude 3、Gemini 1.5,是要把RAG(檢索增強(qiáng)生成)給搞死了嗎?”
隨著新晉大語(yǔ)言模型們的上下文窗口(Context Window)變得越發(fā)得長(zhǎng),業(yè)界人士針對(duì)“RAG終將消亡”觀點(diǎn)的討論也是愈演愈烈。
之所以如此,是因?yàn)樗鼈兌叨际菫榱私鉀Q大模型的幻覺(jué)問(wèn)題(即那種一本正經(jīng)地胡說(shuō)八道),可以說(shuō)是屬于兩種不同頂尖技術(shù)流派之間的對(duì)峙。
一方面,以Claude 3、Gemini 1.5為代表的流派,陸續(xù)支持200K和100萬(wàn)token的上下文窗口,用大力出奇跡的方式讓大模型能夠精準(zhǔn)檢索到關(guān)鍵信息來(lái)提供準(zhǔn)確答案。
另一方面,RAG則是一種外掛知識(shí)庫(kù),無(wú)縫集成外部資源,為大語(yǔ)言模型提供了準(zhǔn)確和最新的知識(shí),以此來(lái)提高生成內(nèi)容的質(zhì)量。
誠(chéng)然有很多人在體驗(yàn)過(guò)超長(zhǎng)上下文窗口大模型后,覺(jué)得這種方式已經(jīng)讓AI在回答的準(zhǔn)確性上做到了突破,無(wú)需再用RAG:
而且從Claude、Gemini等玩家在測(cè)評(píng)榜單的數(shù)據(jù)來(lái)看,在回答準(zhǔn)確性上的成績(jī)也是屢創(chuàng)新高。
但事實(shí)真是如此嗎?不見(jiàn)得。
因?yàn)樵诖似陂g,與“RAG要消亡了”背道而馳的聲音也是越發(fā)堅(jiān)定:
從各種評(píng)價(jià)和討論來(lái)看,這派的觀點(diǎn)可以概括為——你(長(zhǎng)上下文窗口)強(qiáng)任你強(qiáng),但缺點(diǎn)也是蠻明顯的。
有網(wǎng)友便列舉了長(zhǎng)上下文窗口的四大通病(四個(gè)V):
- Velocity(速度):基于Transformer的大型模型,在檢索長(zhǎng)上下文時(shí)要想達(dá)到亞秒級(jí)的速度響應(yīng)仍然具有挑戰(zhàn)性。
- Value(價(jià)值):長(zhǎng)上下文窗口畢竟屬于大力出奇跡,但它高支出的特點(diǎn)對(duì)于日常應(yīng)用來(lái)說(shuō),在成本上是不切實(shí)際的。
- Volume(體量):即使上下文窗口越發(fā)得長(zhǎng),但和全網(wǎng)龐大的非結(jié)構(gòu)化數(shù)據(jù)相比就是小巫見(jiàn)大巫;尤其是企業(yè)級(jí)動(dòng)輒GB、TB這種體量,還涉及眾多私有數(shù)據(jù)的情形。
- Variety(多樣性):現(xiàn)實(shí)世界的用例不僅涉及非結(jié)構(gòu)化數(shù)據(jù),還包括各種結(jié)構(gòu)化數(shù)據(jù),它們可能不容易被LLM捕獲用來(lái)訓(xùn)練;而且企業(yè)場(chǎng)景中往往知識(shí)是需要實(shí)時(shí)變化的。
相反,RAG因?yàn)榈靡嬗谄潢P(guān)鍵結(jié)構(gòu)之一的向量數(shù)據(jù)庫(kù),反倒是可以較好地規(guī)避上述的“4V”缺陷。
向量數(shù)據(jù)庫(kù)讓大模型能夠快速有效地檢索和處理大量的向量數(shù)據(jù),從而增強(qiáng)了模型的整體性能和應(yīng)用范圍。
一言蔽之,關(guān)鍵看能不能“快好省”地用起來(lái)。
△圖源:由DALL·E 3生成
那么以RAG、向量數(shù)據(jù)庫(kù)為代表的這一派技術(shù),在現(xiàn)實(shí)場(chǎng)景中到底用得如何呢?
為了解答這個(gè)問(wèn)題,我們找到了剛剛發(fā)布相關(guān)創(chuàng)新成果的騰訊云,了解了一下向量數(shù)據(jù)庫(kù)以全新構(gòu)建模式,作為AI知識(shí)庫(kù)能為大模型等帶來(lái)哪些收益?
向量數(shù)據(jù)庫(kù),已成大模型時(shí)代數(shù)據(jù)中樞
正如我們剛才提到的,RAG的重要組成部分就是外掛的專業(yè)知識(shí)庫(kù),因此這個(gè)知識(shí)庫(kù)中需得涵蓋能夠精準(zhǔn)回答問(wèn)題所需要的專業(yè)知識(shí)和規(guī)則。
而要構(gòu)建這個(gè)外掛知識(shí)庫(kù),常見(jiàn)的方法包括向量數(shù)據(jù)庫(kù)、知識(shí)圖譜,甚至也可以直接把ElasticSearch數(shù)據(jù)接入。
但由于向量數(shù)據(jù)庫(kù)具備對(duì)高維向量的檢索能力,能夠跟大模型很好地匹配,效果也是較好的那個(gè),所以成為了目前主流的形式。
△各類數(shù)據(jù)轉(zhuǎn)化為向量后存入向量數(shù)據(jù)庫(kù)
向量數(shù)據(jù)庫(kù)可以對(duì)向量化后的數(shù)據(jù)進(jìn)行高效的存儲(chǔ)、處理與管理。
如上圖展示的那樣,數(shù)據(jù)向量化過(guò)程利用了諸如詞向量模型和卷積神經(jīng)網(wǎng)絡(luò)等人工智能技術(shù)。
通過(guò)Embedding過(guò)程,這些技術(shù)能夠?qū)⑽谋?、圖像、音視頻等多種形式的數(shù)據(jù)轉(zhuǎn)換成向量形式,并將其存儲(chǔ)在向量數(shù)據(jù)庫(kù)中。
至于向量數(shù)據(jù)庫(kù)的查詢功能,則是通過(guò)計(jì)算向量間的相似度來(lái)實(shí)現(xiàn)的。
而騰訊云的創(chuàng)新成果,就是騰訊云向量數(shù)據(jù)庫(kù)(Tencent Cloud VectorDB),它能為多維向量數(shù)據(jù)提供高效的存儲(chǔ)、檢索和分析能力。
其主要特點(diǎn)包括:
- Embedding功能:數(shù)據(jù)寫(xiě)入/檢索自動(dòng)向量化,無(wú)需關(guān)注向量生成過(guò)程,這意味著使用門(mén)檻被狠狠地打了下去。
- 高性能:?jiǎn)嗡饕С智|級(jí)向量數(shù)據(jù)規(guī)模,可支持百萬(wàn)級(jí) QPS 及毫秒級(jí)查詢延遲。
- 低成本:只需簡(jiǎn)單操作就可以創(chuàng)建向量數(shù)據(jù)庫(kù)實(shí)例,全流程平臺(tái)托管,不需要額外的開(kāi)銷成本。
- 簡(jiǎn)單易用:不僅向量檢索能力豐富,而且通過(guò)API就能快速操作和開(kāi)發(fā)。
從這些特性不難看出,它恰好補(bǔ)齊了我們剛才提到的上下文窗口方式的一些短板。
也正是憑借這些優(yōu)勢(shì),騰訊云向量數(shù)據(jù)庫(kù)能夠和大語(yǔ)言模型無(wú)縫對(duì)接:
用戶可以將私有數(shù)據(jù)經(jīng)過(guò)文本處理和向量化后,存儲(chǔ)至騰訊云向量數(shù)據(jù)庫(kù),從而創(chuàng)建一個(gè)定制化的外部知識(shí)庫(kù)。
在后續(xù)的查詢?nèi)蝿?wù)中,這個(gè)知識(shí)庫(kù)也能為大模型提供必要的提示,從而輔助AGI和AIGC等應(yīng)用產(chǎn)生更精確的輸出。
由此可見(jiàn),站在大模型時(shí)代之下,向量數(shù)據(jù)庫(kù)已然不僅僅是一種技術(shù)工具,更是連接數(shù)據(jù)與AI的橋梁,是大模型時(shí)代的數(shù)據(jù)中樞,是整個(gè)AI平臺(tái)不可或缺的一部分。
借助這一項(xiàng)項(xiàng)突破,騰訊云VectorDB不僅支持多種索引類型和相似度計(jì)算方法,還具有單索引支持千億級(jí)向量規(guī)模、百萬(wàn)級(jí)每秒查詢率(Queries-per-second,QPS)及毫秒級(jí)查詢時(shí)延等優(yōu)勢(shì)。
不過(guò)這樣的向量數(shù)據(jù)庫(kù)又是如何搭建起來(lái)的呢?
騰訊云還有一個(gè)殺手锏——
與英特爾合作,以至強(qiáng)CPU平臺(tái)為基礎(chǔ),通過(guò)軟、硬件兩方面的并行優(yōu)化,為向量數(shù)據(jù)庫(kù)提供顯著的性能加速。
CPU,向量數(shù)據(jù)庫(kù)的好搭檔
向量數(shù)據(jù)庫(kù)搭配CPU,其實(shí)不只是騰訊云一家的選擇,而是整個(gè)行業(yè)現(xiàn)階段的主流共識(shí):
只有面臨海量高并發(fā)需求時(shí),使用GPU查詢向量數(shù)據(jù)庫(kù)才更劃算。
究其原因,還要從向量數(shù)據(jù)庫(kù)和CPU各自的特點(diǎn),以及實(shí)際業(yè)務(wù)流程分開(kāi)來(lái)看。
首先從向量數(shù)據(jù)庫(kù)的角度分析,其原理上屬于密集型計(jì)算負(fù)載,需要大量訪問(wèn)內(nèi)存中加載的向量。
向量數(shù)據(jù)庫(kù)與傳統(tǒng)數(shù)據(jù)庫(kù)最大的區(qū)別在于不是精確匹配,而是依靠各種相似度度量方法來(lái)找到與給定查詢最相近的向量,這就涉及大量的相似度計(jì)算,如點(diǎn)積、歐式距離、余弦相似度等。
如此一來(lái),除了運(yùn)算速度之外,內(nèi)存訪問(wèn)速度也很容易成為向量數(shù)據(jù)庫(kù)運(yùn)行中的瓶頸所在。
帶著這個(gè)背景來(lái)看,CPU不但性能夠用,還占據(jù)了內(nèi)存訪問(wèn)快的優(yōu)勢(shì)。
對(duì)于中等或更少并發(fā)請(qǐng)求來(lái)說(shuō),雖然GPU單論運(yùn)算速度更快,但CPU較低的內(nèi)存訪問(wèn)時(shí)間足以抵消這個(gè)差距。
接下來(lái),再?gòu)腃PU的角度來(lái)看,它是如何來(lái)滿足向量數(shù)據(jù)庫(kù)運(yùn)算性能需求的。
前面提到向量數(shù)據(jù)庫(kù)屬于密集型計(jì)算負(fù)載,談到CPU上相關(guān)的加速技術(shù),就不得不提我們的老朋友——從2017年第一代至強(qiáng)? 可擴(kuò)展處理器開(kāi)始就內(nèi)置在這個(gè)CPU產(chǎn)品家族中的英特爾? AVX-512指令集。
這是一種單指令多數(shù)據(jù)(Single Instruction Multiple Data,SIMD)指令集,擁有512位的寄存器寬度,可以在一次操作中處理高維向量的所有數(shù)據(jù)。
△英特爾? SSE、英特爾? AVX2和英特爾? AVX-512之間的寄存器大小和計(jì)算效率的差異說(shuō)明
另一項(xiàng)可為向量數(shù)據(jù)庫(kù)帶來(lái)顯著性能提升的是英特爾? AMX (高級(jí)矩陣擴(kuò)展)加速引擎,它是從第四代至強(qiáng)? 可擴(kuò)展處理器開(kāi)始內(nèi)置的加速技術(shù),在剛剛發(fā)布的第五代至強(qiáng)? 可擴(kuò)展處理器上也是加速器的“C位”,是大家熟悉的CPU用來(lái)加速AI應(yīng)用,尤其是推理應(yīng)用的核心技術(shù)。
AMX引入的用于矩陣處理的新框架,也能高效地處理向量數(shù)據(jù)庫(kù)查詢所需的矩陣乘法運(yùn)算,并在單詞運(yùn)算中處理更大矩陣。
△英特爾? AMX 架構(gòu)由2D 寄存器文件 (TILE) 和 TMUL 組成
在這基礎(chǔ)上,英特爾還與騰訊云合作,針對(duì)騰訊云VectorDB常用的計(jì)算庫(kù)做了專門(mén)的優(yōu)化方案。
例如針對(duì)流行的FAISS相似度搜索(Facebook AI Similarity Search ),借助英特爾? AVX-512為其中不同的索引提出不同的優(yōu)化方案,包括面向IVF- FLAT算法的ReadOnce(單次讀?。?/span>和Discretization(離散化)兩種優(yōu)化思路,來(lái)執(zhí)行用英特爾? AVX-512加速I(mǎi)VF- PQFastScan算法和IVF-SQ索引的優(yōu)化方案。
針對(duì)另一種流行代碼庫(kù)HNSWlib,使用英特爾? AVX-512不僅能加速向量檢索性能,同時(shí)還能使召回率保持平穩(wěn)。
實(shí)地測(cè)試表明,在第三代至強(qiáng)? 可擴(kuò)展處理器平臺(tái)上啟用英特爾? AVX-512優(yōu)化后,相比沒(méi)有啟用優(yōu)化時(shí),使用IVF-PQFastScan算法執(zhí)行向量檢索時(shí)的QPS性能提升了約一倍;而把計(jì)算平臺(tái)升級(jí)到目前最新的第五代至強(qiáng)? 可擴(kuò)展處理器平臺(tái)后,性能更是會(huì)提升2.3倍!
△英特爾軟硬件產(chǎn)品與技術(shù)帶來(lái)的性能提升(歸一化)
還有,在使用第五代至強(qiáng)? 可擴(kuò)展處理器的算力平臺(tái)上,如果使用英特爾? AMX 加速數(shù)據(jù)格式為 INT8的測(cè)試場(chǎng)景,相比使用英特爾? AVX-512加速數(shù)據(jù)格式為 FP32的測(cè)試場(chǎng)景,性能提升可達(dá)約5.8倍。
△英特爾? AMX 優(yōu)化加速暴力檢索的吞吐性能(歸一化)
AI走向平臺(tái)化,模型不是唯一主角
了解過(guò)騰訊云與英特爾的具體實(shí)踐和優(yōu)化成果,再來(lái)看我們最開(kāi)始的討論,答案也就明晰了。
即使AI模型能力不斷加速進(jìn)化,向量數(shù)據(jù)庫(kù)以及整個(gè)RAG技術(shù)也沒(méi)到消亡的時(shí)候。
究其原因,便是單純的模型能力本身已經(jīng)難以滿足日益深入的應(yīng)用落地需求,AI在落地時(shí)必須會(huì)走向復(fù)雜系統(tǒng),或者說(shuō)平臺(tái)化。
向量數(shù)據(jù)庫(kù)承載著外部知識(shí),會(huì)在這個(gè)AI系統(tǒng)或平臺(tái)時(shí)發(fā)揮自己的價(jià)值,但也只是其中的組件之一。
站在這個(gè)層面上看,AI系統(tǒng)或平臺(tái)的綜合能力已不只單看模型自身,還要與整個(gè)系統(tǒng)中其他組件相互配合。
AI系統(tǒng)或平臺(tái)的性能效率也需要從整體考量,不僅僅取決于模型的準(zhǔn)確性和速度。
在騰訊云VectorDB的業(yè)務(wù)實(shí)踐中,最終能發(fā)現(xiàn)CPU是與向量數(shù)據(jù)庫(kù)業(yè)務(wù)很契合,就綜合性能、可擴(kuò)展性、功耗、成本等因素而言是很登對(duì)的搭檔,這就讓CPU在直接加速一些AI應(yīng)用之余,也能成為承載AI系統(tǒng)或平臺(tái)中更多組件的基礎(chǔ)。
這個(gè)故事的另一個(gè)主角英特爾,也在順應(yīng)這一趨勢(shì)不斷深入優(yōu)化,既在微觀上用一顆顆芯片給大模型加速,又在宏觀上用CPU相關(guān)技術(shù)給整個(gè)AI系統(tǒng)或平臺(tái)的落地、應(yīng)用及實(shí)踐加速。
更多CPU支持向量數(shù)據(jù)庫(kù)的解決方案內(nèi)容,請(qǐng)點(diǎn)擊“閱讀原文”獲取。
參考鏈接:
[1]https://zilliz.com/blog/will-retrieval-augmented-generation-RAG-be-killed-by-long-context-LLMs。
[2]https://www.reddit.com/r/hypeurls/comments/1b9dfo5/gemini_and_claudes_are_killing_rag/。
[3]https://cloud.tencent.com/product/vdb。