成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

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

人工智能
隨著新晉大語言模型們的上下文窗口(Context Window)變得越發得長,業界人士針對“RAG終將消亡”觀點的討論也是愈演愈烈。之所以如此,是因為它們二者都是為了解決大模型的幻覺問題(即那種一本正經地胡說八道),可以說是屬于兩種不同頂尖技術流派之間的對峙。

“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倍!

圖片

△英特爾軟硬件產品與技術帶來的性能提升(歸一化)

還有,在使用第五代至強可擴展處理器的算力平臺上,如果使用英特爾AMX 加速數據格式為 INT8的測試場景,相比使用英特爾AVX-512加速數據格式為 FP32的測試場景,性能提升可達約5.8倍。

圖片

△英特爾? AMX 優化加速暴力檢索的吞吐性能(歸一化)

AI走向平臺化,模型不是唯一主角

了解過騰訊云與英特爾的具體實踐和優化成果,再來看我們最開始的討論,答案也就明晰了。

即使AI模型能力不斷加速進化,向量數據庫以及整個RAG技術也沒到消亡的時候。

究其原因,便是單純的模型能力本身已經難以滿足日益深入的應用落地需求,AI在落地時必須會走向復雜系統,或者說平臺化。

向量數據庫承載著外部知識,會在這個AI系統或平臺時發揮自己的價值,但也只是其中的組件之一。

站在這個層面上看,AI系統或平臺的綜合能力已不只單看模型自身,還要與整個系統中其他組件相互配合。

AI系統或平臺的性能效率也需要從整體考量,不僅僅取決于模型的準確性和速度。

在騰訊云VectorDB的業務實踐中,最終能發現CPU是與向量數據庫業務很契合,就綜合性能、可擴展性、功耗、成本等因素而言是很登對的搭檔,這就讓CPU在直接加速一些AI應用之余,也能成為承載AI系統或平臺中更多組件的基礎。

這個故事的另一個主角英特爾,也在順應這一趨勢不斷深入優化,既在微觀上用一顆顆芯片給大模型加速,又在宏觀上用CPU相關技術給整個AI系統或平臺的落地、應用及實踐加速。

更多CPU支持向量數據庫的解決方案內容,請點擊“閱讀原文”獲取。

參考鏈接:

[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。

責任編輯:姜華 來源: 量子位
相關推薦

2021-07-26 07:47:36

Cpu上下文進程

2022-04-24 15:37:26

LinuxCPU

2019-05-06 14:36:48

CPULinux寄存器

2017-05-11 14:00:02

Flask請求上下文應用上下文

2022-04-25 11:27:34

LinuxCPU

2022-09-26 23:36:33

Linux系統CPU

2025-06-11 04:25:00

上下文窗口系統

2023-08-10 14:04:15

代碼模型

2024-02-19 13:46:04

多模態信息LWMtoken

2024-01-29 08:49:36

RAG模型檢索

2012-12-31 10:01:34

SELinuxSELinux安全

2022-09-14 13:13:51

JavaScript上下文

2025-05-09 07:50:30

2025-04-14 09:00:00

模型AI數據

2022-09-15 08:01:14

繼承基礎設施基礎服務

2024-02-20 13:31:46

模型數據

2023-07-11 10:02:23

2022-10-28 16:24:33

Context上下文鴻蒙

2024-09-30 14:10:00

2025-03-18 08:14:05

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 亚洲久久一区 | 天天拍天天操 | 麻豆亚洲 | 视频一区在线观看 | 日韩视频区| 国产91久久久久 | 蜜桃毛片| 亚洲 欧美 另类 综合 偷拍 | 亚洲一区二区三区免费在线观看 | 久久免费国产 | 久久久入口 | 精品福利在线 | 四虎最新 | 热99精品视频 | 97人人澡人人爽91综合色 | 日本成人福利视频 | 日本在线视频一区二区 | 99热首页 | 91久久综合亚洲鲁鲁五月天 | 成人av电影在线 | 国产黄色在线观看 | 一区二区三区av | 国产精品一码二码三码在线 | 久久性av | hdfreexxxx中国妞| 婷婷丁香在线视频 | 免费九九视频 | 午夜精品久久久久久久久久久久久 | 亚洲精品日韩在线 | 色综合99| 在线观看黄视频 | 黄网站免费在线看 | xxxxx黄色片| 国产成人99久久亚洲综合精品 | 午夜视频在线 | 日本三级网站在线 | 天天看天天爽 | 中文在线一区二区 | 成人h电影在线观看 | 色综合区| 爱爱综合网 |