AI-LECTURER 速報課|2026-08-19|約 26 分鐘

向量資料庫也能瘦身:這顆 Rust 引擎把千萬筆向量塞進 4GB 記憶體,搜尋還比 FAISS 快

取材:Turbovec – Google's TurboQuant for vector search in Rust(Hacker News(AI 高人氣))
📍 真實場景
阿凱,一人接案的獨立開發者,正在幫一間小型法律事務所架設內部文件檢索系統

他把事務所十年來的案例卷宗、判決書全部轉成向量,餵進自己架設的 RAG(檢索增強生成)系統,讓律師可以用白話問問題就找到相關案例

😖 卡住的地方:案子越接越多,向量資料庫吃掉的記憶體從幾百 MB 暴增到十幾 GB,租的雲端主機規格被迫一直往上升,客戶的預算撐不住;而且這些是敏感的訴訟資料,不能丟去別人的雲端服務做壓縮
💡 這篇會告訴他一套完全在自己電腦上就能跑、把記憶體用量砍到七分之一、搜尋還更快的向量索引工具,資料完全不用離開事務所

🧭 這到底是什麼(白話版)

先講最基本的概念:向量搜尋把文字、圖片這些內容轉換成一串數字(向量),意思相近的內容數字會很接近,透過比對數字之間的距離就能找到相關內容,這是很多智慧檢索系統的底層技術。而 RAG(檢索增強生成)讓 AI 回答問題之前,先去資料庫裡撈出相關資料,再根據這些資料生成答案,而不是憑空亂猜 就是靠向量搜尋去撈資料,阿凱幫事務所做的系統就是這一類。

問題出在:向量一多,記憶體就爆炸。素材裡提到,一千萬筆文件轉成向量,用最原始的方式存(float32)要吃掉 31GB 記憶體,這對一般公司甚至個人接案者都是很沉重的雲端主機費用。turbovec 這個開源工具,靠的是 量化把每個向量裡精細的小數字,用比較粗略、佔用空間更小的數字去近似表示,犧牲一點點精準度換取大量省下的空間 技術,把同樣的資料壓到 4GB,還宣稱搜尋比知名的 FAISS 更快。

turbovec 用的壓縮演算法叫 TurboQuant,是 Google 研究團隊做出來的。它的特別之處在於是 資料無關(data-oblivious)不需要先看過你的資料、學習資料的分布規律再決定怎麼壓縮,任何一批向量丟進來都能直接套用同一套規則去壓,不用重新訓練 的量化器,這代表你隨時加新資料進去,都不用停下來重新訓練或重建整個索引。

速度那端,turbovec 靠的是 SIMD讓 CPU 一個指令同時處理好幾筆數字運算,而不是一筆一筆算,同樣的工作量可以用更少時間做完 這種底層硬體加速技巧,針對 ARM 跟 Intel/AMD 分別手寫了加速核心,這也是它能同時做到「更省空間」又「搜更快」的原因。

🎯 為什麼值得你花時間

記憶體就是錢雲端主機常常是依記憶體規格計費,向量資料庫從 31GB 降到 4GB,代表原本要租一台大記憶體機器,現在中小型機器就夠了。對阿凱這種獨立開發者、或預算有限的小型專案來說,這種等級的省錢是決定案子能不能接的關鍵差異。
不用訓練,資料來了就能用傳統的量化方法通常要先用一批樣本資料「訓練」出一套壓縮規則,資料分布一改變或量一直長大,就得重新訓練、重建索引。TurboQuant 不需要訓練階段,加進去就能直接用,對資料持續在成長的系統(像不斷累積的案件卷宗)特別友善,不用三不五時停機重建。
完全地端,資料不出門對法律、醫療、金融這類極度重視資料隱私的場景,能在自己機器上把資料壓縮到負擔得起的大小,比丟去雲端 API 做壓縮重要太多。素材裡強調的「Pure local,沒有 managed service,資料不會離開你的機器或 VPC」,正是這類場景最在意的賣點。

⚙️ 它是怎麼運作的

1
把資料變成向量先用一個 embedding 模型(負責把文字轉成向量的模型)把每份文件轉成一串固定長度的數字,例如 1536 維。這一步不是 turbovec 做的,是前置作業。
2
邊加邊壓縮進索引呼叫 index.add(vectors) 把向量丟進 TurboQuantIndex,函式庫會即時用 TurboQuant 演算法把每個向量壓縮成 4-bit 或 2-bit 的精簡表示法,沒有等待訓練、也不用手動調參數。
3
用硬體指令加速比對搜尋時,程式會利用 CPU 內建的向量運算指令(ARM 上叫 NEON、Intel/AMD 上叫 AVX-512),一次比對一大批數字,而不是一筆一筆算距離,這是它比 FAISS 快的關鍵之一。
4
先過濾、再排序呼叫 search() 時可以附上一份「允許名單」(例如只搜某個客戶的卷宗),引擎會在計算相似度的同時直接套用這個篩選,不會浪費力氣算完全部候選才丟掉不符合的結果。
5
隨手存檔,不怕當機sync() 只會把「上次存檔後有變動的部分」寫回硬碟,一次系統呼叫就搞定,就算存到一半跳電,索引也不會壞掉;要整份重新存檔才用 write()。
turbovec 與 FAISS IndexPQFastScan 效能比較(素材中的實測數據)
比較項目turbovecFAISS(IndexPQFastScan)
記憶體(1000 萬筆向量)4 GB31 GB(未壓縮 float32 為基準)
4-bit 量化搜尋速度平均快 3.4 倍基準
2-bit 量化搜尋速度平均快 23%基準
是否需要訓練階段不需要通常需要

🛠️ 動手做:在你的電腦上,用 turbovec 建立索引、搜尋、存檔再重新載入

這是一個真實小專案:下載(或複製)檔案,照步驟在你電腦上跑起來。

📄 demo_turbovec.py ⬇ 下載
# demo_turbovec.py
# 這支程式示範:建立向量索引、加入資料、搜尋、以及刪除與存讀檔
import numpy as np
from turbovec import IdMapIndex

DIM = 128  # 示範用維度,真實 RAG 常見用 1536,這裡縮小方便電腦馬上跑完


def make_fake_vectors(n, dim, seed):
    rng = np.random.default_rng(seed)
    return rng.standard_normal((n, dim)).astype(np.float32)


def main():
    index = IdMapIndex(dim=DIM, bit_width=4)

    vectors = make_fake_vectors(1000, DIM, seed=1)
    ids = np.arange(1001, 2001, dtype=np.uint64)
    index.add_with_ids(vectors, ids)
    print(f"已加入 {len(ids)} 筆向量,索引維度 {DIM}")

    query = vectors[0:1]  # 拿第一筆當查詢,理論上應該搜得到自己排第一名
    scores, found_ids = index.search(query, k=5)
    print("查詢結果(最相近的 5 筆 id):", found_ids)
    print("對應相似度分數:", scores)

    index.remove(1002)
    print("已刪除 id=1002,之後搜尋不會再找到這筆")

    index.write("demo_index.tvim")
    print("索引已完整存檔為 demo_index.tvim")

    loaded = IdMapIndex.load("demo_index.tvim")
    scores2, found_ids2 = loaded.search(query, k=5)
    print("重新載入後再搜一次,結果應該一致:", found_ids2)


if __name__ == "__main__":
    main()
  1. 開啟「命令提示字元」或 PowerShell,切換到你想放這個示範的資料夾,例如:cd D:\turbovec_demo
  2. 建立虛擬環境(避免弄亂系統 Python):python -m venv .venv
  3. 啟動虛擬環境:PowerShell 打 .venv\Scripts\Activate.ps1(如果出現「不允許執行指令碼」的錯誤,改用命令提示字元執行 .venv\Scripts\activate.bat)
  4. 安裝 turbovec:pip install turbovec
  5. 把上面的 demo_turbovec.py 存到同一個資料夾裡
  6. 執行示範:python demo_turbovec.py
  7. 觀察輸出:你會看到剛剛加入的 1000 筆向量裡,拿第一筆去搜尋時,找回自己排在第一名、分數最高;接著看到刪除、存檔、重新載入、再搜一次結果一致,代表這個索引真的『存檔存到一半也不怕壞』

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 TurboQuant 標榜『不用訓練』,跟傳統的乘積量化(PQ)比,資深工程師會怎麼看這個取捨?
傳統的乘積量化要先拿一批樣本資料『訓練』出一套壓縮字典,好處是能針對你的資料分布量身訂做、壓得更精準;壞處是資料後續分布一旦改變(例如事務所開始接了新的案件類型),舊字典就可能失準,得重新訓練、重建整個索引,這對持續在長大的系統是很痛的維運成本。TurboQuant 選擇犧牲一點點『針對特定資料的最佳化空間』,換來『資料怎麼長都不用回頭重建』的維運簡單性——這是典型的『犧牲一點峰值效能、換取系統可維運性』的工程判斷,特別適合資料會持續增長、不能常常停機重建的場景。
🔭 同樣壓到 4-bit,turbovec 為什麼能比 FAISS 快,而不是『壓得更小但變慢』?
素材提到 turbovec 針對不同 CPU 硬體手寫了 SIMD 核心(ARM 的 NEON、Intel/AMD 的 AVX-512),代表團隊沒有只在演算法層面做文章,而是一路優化到『怎麼用一個 CPU 指令同時算很多筆資料』這麼底層的地方。這提醒了一個常被忽略的分工:壓縮率是演算法問題,但『壓完之後比對速度』常常是硬體指令使用效率的問題,兩者要分開優化。只優化演算法、不往下優化到指令集,很可能得到『省了記憶體、卻沒有真的變快』的結果。
🔭 search() 支援直接帶 id 允許名單去過濾,這個設計解決了什麼常見的架構痛點?
很多 RAG 系統的真實需求是『先用其他條件(租戶、權限、時間區間)縮小範圍,再做語意搜尋』。如果向量引擎不支援搜尋時過濾,工程師常常得『先搜出一大批候選、再事後用程式碼濾掉不符合的』——要嘛搜的數量得故意抓很大以免濾完不夠,要嘛精準度就打折。turbovec 把允許名單直接餵進搜尋核心,讓過濾在計算相似度的當下就發生,這是把『業務邏輯的過濾條件』跟『底層搜尋效能』綁在一起設計,而不是分成兩層各自為政,能同時省算力又不犧牲召回率,是值得留意的設計思路。

📝 隨堂考(點選答案,立即回饋)

Q1. 為什麼 turbovec 能把 31GB 的向量資料壓縮到 4GB,還能維持不錯的搜尋品質?
✅ 量化是犧牲一點點數字精準度、換取大量空間節省的技術,turbovec 用的 TurboQuant 就是這類壓縮方法,素材中提到它把 31GB 壓到 4GB 還搜得比 FAISS 快。
Q2. TurboQuant 跟傳統量化方法最大的操作差異是?
✅ 素材明確指出 TurboQuant 是「data-oblivious」(資料無關)的量化器,沒有獨立的訓練階段,加入新向量不用重新訓練或重建索引。
Q3. 如果阿凱的法律事務所很重視訴訟資料隱私,turbovec 素材裡哪個特性對他最重要?
✅ 素材強調 turbovec 是 Pure local,沒有 managed service、資料不會離開你的機器或 VPC,這對重視隱私、不能把敏感資料丟出去的場景(如法律、醫療)特別有價值。
Q4. search() 支援的『id 允許名單過濾』解決了什麼問題?
✅ 素材提到 filter at search time,允許名單會被核心直接套用,你可以精準拿到 k 筆結果,不會有『過度抓取』或事後濾掉導致召回不足的問題。
Q5. SIMD 加速在 turbovec 裡扮演什麼角色?
✅ SIMD(單一指令多筆資料)讓 CPU 一次處理一整批數字運算,turbovec 針對 ARM 與 x86 分別手寫了 SIMD 核心,這是它搜尋速度打贏 FAISS 的關鍵之一。

🃏 翻牌記憶卡(先想答案,再點開對答)

量化(Quantization)點我翻面
把精細的數字,用比較粗略、佔空間更小的數字近似表示,犧牲一點精準度換取大量省下的儲存空間。
data-oblivious(資料無關)量化器點我翻面
不用事先拿樣本資料訓練壓縮規則,任何一批向量丟進來都能直接套用同一套規則壓縮,不用重新訓練。
SIMD點我翻面
CPU 的單一指令多筆資料運算能力,讓一個指令同時處理很多筆數字,加快大量向量比對的速度。
RAG(檢索增強生成)點我翻面
AI 回答問題前,先從資料庫撈出相關資料,再根據這些資料生成答案,而不是憑空瞎猜。
IdMapIndex vs TurboQuantIndex點我翻面
TurboQuantIndex 用內部流水號管理向量;IdMapIndex 讓你用自己的 id(例如資料庫主鍵)管理向量,刪除後查詢也對得上,適合資料會增刪的場景。
增量存檔 sync()點我翻面
只把『上次存檔後有變動的部分』寫回硬碟,一次系統呼叫完成,就算存到一半當機索引也不會壞,比每次都整份重寫(write)快很多。

✅ 離開前自測(全勾=這課真的學會了)

0%