更多技術(shù)交流、求職機(jī)會，歡迎關(guān)注字節(jié)跳動數(shù)據(jù)平臺微信公眾號，回復(fù)【1】進(jìn)入官方交流群

隨著LLM技術(shù)應(yīng)用及落地，數(shù)據(jù)庫需要提高向量分析以及AI支持能力，向量數(shù)據(jù)庫及向量檢索等能力“異軍突起”，迎來業(yè)界持續(xù)不斷關(guān)注。簡單來說，向量檢索技術(shù)以及向量數(shù)據(jù)庫能為 LLM 提供外置的記憶單元，通過提供與問題及歷史答案相關(guān)聯(lián)的內(nèi)容，協(xié)助 LLM 返回更準(zhǔn)確的答案。

不僅僅是LLM，向量檢索也早已在OLAP引擎中應(yīng)用，用來提升非結(jié)構(gòu)化數(shù)據(jù)的分析和檢索能力。ByteHouse是火山引擎推出的云原生數(shù)據(jù)倉庫，近期推出高性能向量檢索能力，本篇將結(jié)合ByteHouse團(tuán)隊對向量數(shù)據(jù)庫行業(yè)和技術(shù)的前沿觀察，詳細(xì)解讀OLAP引擎如何建設(shè)高性能的向量檢索能力，并最終通過開源軟件VectorDBBench測試工具，在 cohere 1M 標(biāo)準(zhǔn)測試數(shù)據(jù)集上，recall 98 的情況下，QPS性能已可以超過專用向量數(shù)據(jù)庫（如milvus）。

向量檢索現(xiàn)狀分析

向量檢索定義

對于諸如圖片、視頻、音頻等非結(jié)構(gòu)化數(shù)據(jù)，傳統(tǒng)數(shù)據(jù)庫方式無法進(jìn)行處理。目前，通用的技術(shù)是把非結(jié)構(gòu)化數(shù)據(jù)通過一系列 embedding 模型將它變成向量化表示，然后將它們存儲到數(shù)據(jù)庫或者特定格式里。在搜索過程中，通過相同的一個模型把查詢項轉(zhuǎn)化成對應(yīng)的向量，并進(jìn)行一個近似度的匹配就可以實(shí)現(xiàn)對非結(jié)構(gòu)化數(shù)據(jù)的查詢。

在技術(shù)原理層面，向量檢索主要是做一個 K Nearest Neighbors (K最近鄰，簡稱 KNN) 計算，目標(biāo)是在N個D維的向量的庫中找最相似的k個結(jié)果。

在數(shù)據(jù)量較大場景，KNN 計算通常代價比較大，很難在較短時間內(nèi)返回結(jié)果，此外，在很多場景，用戶并不需要絕對精確的相似結(jié)果。因此，在真正在使用向量檢索時，通常會使用相似最近鄰搜索，即 ANN 的方式來替代 KNN，從 k 個絕對最近似結(jié)果變成 K 個近似最優(yōu)結(jié)果，以犧牲一定準(zhǔn)確度的前提，得到更短的響應(yīng)時間。

LLM與向量檢索

由于大模型的訓(xùn)練數(shù)據(jù)有限，在針對一些最近的消息或者特定領(lǐng)域信息的查詢來說，通常結(jié)果不準(zhǔn)確。為了提升檢索的準(zhǔn)確性，一種比較常見的處理方式是將想搜索的信息的相關(guān)文檔進(jìn)行文本處理，并通過 embedding 模型將向量寫入到向量數(shù)據(jù)庫里后，把問題通過相同的 embedding 模型轉(zhuǎn)化為向量進(jìn)行近似度搜索，得到問題的相似知識作為 prompt，連同問題一起提交給大模型處理，最終得到更準(zhǔn)確的答案。

向量檢索的四種算法（索引）

向量檢索算法基于其存儲結(jié)構(gòu)大致可分為四種。

• 第一種是 Table-based，典型算法如 LSH。
• 第二種是 Tree-based，是把向量根據(jù)相似度去構(gòu)造成一個樹的結(jié)構(gòu)。
• 第三種是 Cluster-based，也稱為 IVF（Inverted File），把向量先進(jìn)行聚類處理，檢索時首先計算出最近的 k 個聚類中心，再在這些聚類中心中計算出最近的 k 個向量。這種索引的優(yōu)點(diǎn)是構(gòu)建速度快，因為構(gòu)建時只需要多一個 training 的過程。相比于其他常用索引（主要是 Graph-based 索引），只需要額外存儲倒排表和聚類中心結(jié)構(gòu)，所以內(nèi)存額外占用比較少。但也存在相應(yīng)的缺點(diǎn)，由于每次查詢要把聚類中心里面所有的向量都遍歷一遍，所以它的查詢速度受維度信息影響較大且高精度查詢計算量比較大，計算開銷大。這類索引通常還會結(jié)合一些量化算法來使用，包括 SQ、PQ等。
• 第四種是Graph-based， 把向量按照相似度構(gòu)建成一個圖結(jié)構(gòu)，檢索變成一個圖遍歷的過程。常用算法是HNSW。它基于關(guān)系查詢，并以構(gòu)建索引時以及構(gòu)建向量之間的關(guān)系為核心，而主要技術(shù)則是highway和多層優(yōu)化方式。這種算法的優(yōu)點(diǎn)是查詢速度快、并發(fā)性能好；而缺點(diǎn)則表現(xiàn)為構(gòu)建速度慢、內(nèi)存占用高。

目前實(shí)際場景中，使用較多的方法主要是后面的兩種，即 Cluster-based 和 Graph-based。

如何構(gòu)建向量數(shù)據(jù)庫

首先，一個向量數(shù)據(jù)庫需要具備向量類型數(shù)據(jù)和向量索引的存儲與管理相關(guān)功能，包括增刪改查等數(shù)據(jù)維護(hù)功能，另外，對于向量檢索性能通常要求比較高。其次，向量檢索通常需要與屬性過濾等操作結(jié)合計算。最后，向量檢索通常會與其他屬性結(jié)合查詢，比如以圖搜圖等場景，最終需要的，是相似的圖片路徑或文件。

構(gòu)建向量數(shù)據(jù)庫時，一種思路是以向量為中心，從底向上構(gòu)建一個專用的向量數(shù)據(jù)庫，這樣的特點(diǎn)是，可以針對向量檢索做特定的優(yōu)化，能夠保證較高的性能，缺點(diǎn)為缺乏復(fù)雜的數(shù)據(jù)管理和查詢能力，通常需要結(jié)合其他數(shù)據(jù)庫來使用。

另一種設(shè)計思路是基于現(xiàn)有的數(shù)據(jù)庫和數(shù)據(jù)引擎增加向量檢索相關(guān)擴(kuò)展功能。優(yōu)勢是可以做到 all in one 的數(shù)據(jù)管理和查詢支持，缺點(diǎn)為受現(xiàn)有架構(gòu)的限制，很難做到較高的檢索性能。

向量數(shù)據(jù)庫的當(dāng)前進(jìn)展

向量數(shù)據(jù)庫目前還處于一個快速發(fā)展的階段，目前看有兩個趨勢，一個是以專用向量數(shù)據(jù)庫為基礎(chǔ)，不斷添加更多復(fù)雜的數(shù)據(jù)類型支持以及更多的數(shù)據(jù)管理機(jī)制，比如存算分離、一致性支持、實(shí)時導(dǎo)入等。此外，查詢上也在不斷添加前后置過濾等復(fù)雜查詢策略的支持。

第二種構(gòu)建思路是數(shù)據(jù)庫加向量檢索擴(kuò)展，繼續(xù)去支持更多的向量檢索算法，并且不斷按照向量檢索的需求，添加特殊的過濾策略、簡化對應(yīng)的執(zhí)行計劃。

以上兩種構(gòu)建思路都在向一個統(tǒng)一的目標(biāo)去匯合，即帶有高性能向量檢索，與完備數(shù)據(jù)管理和查詢支持的數(shù)據(jù)庫形態(tài)。這也是 ByteHouse 在設(shè)計向量檢索相關(guān)功能時，主要考慮的一個目標(biāo)。

ByteHouse的高性能向量檢索方案

ByteHouse是火山引擎研發(fā)的云原生數(shù)據(jù)倉庫產(chǎn)品，在開源ClickHouse引擎之上做了技術(shù)架構(gòu)重構(gòu)，實(shí)現(xiàn)了云原生環(huán)境的部署和運(yùn)維管理、存儲計算分離、多租戶管理等功能。在可擴(kuò)展性、穩(wěn)定性、可運(yùn)維性、性能以及資源利用率方面都有巨大的提升。

此外，ByteHouse還支持了向量檢索、全文檢索、地理空間數(shù)據(jù)檢索等功能。

ByteHouse 作為一款高性能向量數(shù)據(jù)庫的底座的優(yōu)勢在于，其具備比較完備的 SQL 語法支持，高性能的計算引擎，以及比較完備的數(shù)據(jù)管理機(jī)制和豐富的數(shù)據(jù)表引擎，能夠支持不同場景。

為了達(dá)到更高的向量檢索性能，ByteHouse 基于向量為中心的設(shè)計思路，構(gòu)建了一條高效的向量檢索的執(zhí)行路徑，同時，引入了多種常用的向量檢索算法，以滿足不同場景的向量檢索需求。

設(shè)計方案

主要設(shè)計思路

• 在 Query 執(zhí)行過程中，針對向量檢索相關(guān)查詢，從語法解析到執(zhí)行算子進(jìn)行了短路改造，同時，引入特殊的執(zhí)行算子，減少計算冗余與 IO 開銷。
• 添加了專用的 Vector Index 管理模塊，包含 向量檢索庫、向量檢索執(zhí)行器、緩存管理、元數(shù)據(jù)管理等組件。
• 存儲層添加 Vector Index 相關(guān)讀寫支持，每個 data part 維護(hù)一個 Vector Index 持久化文件。

基本使用方式

實(shí)際使用時，在建表時可以加一個 Index 的定義，包含索引名稱、向量列、以及索引類型信息。

數(shù)據(jù)導(dǎo)入支持多種方式，比如基于 Kafka 的實(shí)時導(dǎo)入，insert file，python SDK 等。

基本查詢是一個定式：select 需要的列信息，增加一個 order by + limit 的指令。查詢支持與標(biāo)量信息結(jié)合的混合查詢，以及針對 distance 的 range 查詢。

遇到的挑戰(zhàn)

在添加高性能向量檢索功能過程中，ByteHouse 主要克服以下三大難點(diǎn)：

讀放大問題

根本原因：ByteHouse 中，當(dāng)前最小的讀取單元是一個 mark，即便通過 Vector Index 查詢得到結(jié)果是有行號信息的，但是在真正讀取的時候仍需要轉(zhuǎn)成對應(yīng)的 mark id 傳給下層存儲層讀取。

優(yōu)化：

1.把向量檢索的計算進(jìn)行了前置處理。

最初的設(shè)計中，向量檢索計算時需要每個 data part 首先做 Vector Search 加上其他列信息的讀取，然后再去做后面的 order by + limit 得到最終的結(jié)果。這種做法相當(dāng)于每個data part 要取 top k，它的讀取的行數(shù)是 part 數(shù)量乘以 mark_size 乘以 top k。這里做的優(yōu)化是將 Vector Search 計算前置，上推到 data part 的讀取之前，首先執(zhí)行所有 data part 的 Vector Search，獲取全局的 topK 個結(jié)果，再分配到各個 data part 去做 read。這樣可以實(shí)現(xiàn) IO 從百萬減到千的級別的降低，實(shí)際使用中整體性能實(shí)現(xiàn)了兩倍以上的提升。

2.存儲層的過濾。

把 row level 的查詢結(jié)果往下推到存儲層讀 mark 的位置進(jìn)行一些過濾，減少了反序列化的開銷。

3.在 filter by range 場景進(jìn)行優(yōu)化。

基于主鍵查找如按天查找或者按 label 查找等場景，只對首尾 mark 進(jìn)行了一個讀取和過濾，降低過濾語句的執(zhí)行開銷。

構(gòu)建資源消耗大

根本原因：相比于其他比較簡單的索引，如 MinMax 等，向量索引構(gòu)建時間更長，并且消耗資源更多。

優(yōu)化：

1. 在 Build Threads 和 Background Merge Tasks 做了并發(fā)限制。
2. 構(gòu)建過程中內(nèi)存使用優(yōu)化，把一些完全在內(nèi)存里面進(jìn)行的計算做成了 Disk-based，增加了 memory buffer 的機(jī)制。此優(yōu)化主要是對 IVF 類型的索引進(jìn)行的。

冷讀問題

原因：使用索引需要 Index 結(jié)構(gòu)載入內(nèi)存，載入到內(nèi)存后才能進(jìn)行一些檢索加速。

優(yōu)化：

加入Cache Preload 支持。在服務(wù)啟動和數(shù)據(jù)寫入以及后臺數(shù)據(jù) merge 的場景可以自動地把新的 index load 到內(nèi)存。另外，自動的 GC 會把 Cache 中過期數(shù)據(jù)自動回收。

最終效果

ByteHouse 團(tuán)隊基于業(yè)界最新的 VectorDBBench 測試工具進(jìn)行測試，在 cohere 1M 標(biāo)準(zhǔn)測試數(shù)據(jù)集上，recall 98 的情況下，可以達(dá)到與專用向量數(shù)據(jù)庫同等水平的性能。在 recall 95 以上的情況下，QPS 可以達(dá)到 2600 以上，p99 時延在 15ms 左右，具備業(yè)界領(lǐng)先優(yōu)勢。

性能評測

• QPS：即評測在不斷擴(kuò)大并發(fā)度的前提下，它的QPS最終能達(dá)到多少。在同時用HNSW索引情況下，ByteHouse可以達(dá)到甚至超過 Milvus
• Recall：在精確度同等都是98的recall下，QPS才有意義
• Load duration：即評測數(shù)據(jù)從外部添加到系統(tǒng)的時間，包括數(shù)據(jù)寫入和 vector index built 的時間。整個過程包括數(shù)據(jù)寫入和整體時間 ByteHouse 都比 Milvus 好一些。
• Serial Latency P99：串行執(zhí)行 1萬條查詢，P99 latency。這個 case 下 ByteHouse 要比 Milvus 性能差一些。主要原因是 ByteHouse IO 和 query 解析上仍有一些額外的開銷，有很多需要優(yōu)化的地方，對于小的查詢還沒有達(dá)到一個比較理想的狀態(tài)。

不同索引評測

評測對象：IVFPQFS＋Refine(SQ8)和HNSW。

IVFPQFS＋Refine(SQ8) 優(yōu)點(diǎn)：

• 在 recall 要求不高的前提下，內(nèi)存占用資源比較少。（是HNSW的三分之一）
• 可以降低 refine 的精度，進(jìn)一步減少內(nèi)存占用
• 內(nèi)存資源受限，寫入場景頻繁

痛點(diǎn)：

很難在高精度的場景下替換HNSW

未來計劃

• 構(gòu)建資源需求更少、性能更好的索引結(jié)構(gòu)，比如 on-disk indices 的索引接入以及更好的壓縮算法策略。
• 怎樣更好地將向量檢索和其他查詢結(jié)果操作進(jìn)行融合。比如：復(fù)雜過濾語句、基于UDF的Embedding計算融合以及全文檢索支持
• 性能優(yōu)化。如何與優(yōu)化器結(jié)合，以及點(diǎn)查場景優(yōu)化
• 易用性與生態(tài)。目前正在接入 langchain 等 LLM 框架，后續(xù)會進(jìn)一步思考怎么樣在大模型場景以及其他向量檢索場景中做到更好的易用性。

點(diǎn)擊跳轉(zhuǎn)ByteHouse了解更多

總結(jié)

以上是生活随笔為你收集整理的OLAP引擎也能实现高性能向量检索，据说QPS高于milvus！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。