Vector Database（向量資料庫）
又稱：向量資料庫 · 向量庫 · vector db · 向量搜尋 · embedding database
一種用「意思有多接近」來查的資料庫：你給它一個查詢向量，它回你最相似的幾筆，而不是找字面完全一樣的。
你會在什麼時候遇到它
這是 RAG 的檢索引擎。當你的知識庫大到塞不進一次 prompt，就得靠它從幾萬、幾十萬段裡挑出最相關的幾段。不懂它的運作，你無法判斷「為什麼明明有這段資料卻沒被撈到」。
打個比方
一般資料庫像字典的索引：查「蘋果」就翻到「蘋果」那一頁，一字不差。向量庫像一位懂主題的圖書管理員：你問「水果」，它會把蘋果、香蕉、梨這些意思相近的都端給你，即使你沒打出那個字。
最小範例
# 概念示意（不同向量庫的 API 名稱略有差異）
docs = ["報銷上限是三萬元", "出差要事先申請", "辦公室在十樓"]
db.add([embed(d) for d in docs]) # 建立索引：每段文字轉成向量存進去
hits = db.search(embed("差旅花費怎麼報"), top_k=2)
# → 最可能回：出差要事先申請 / 報銷上限是三萬元
# 注意查詢裡根本沒有「報銷」「三萬」這些字，靠的是意思接近有兩件要先懂的事。第一，存進去與查出來必須用同一個 embedding 模型，否則座標系不同，結果等於隨機。第二，它回的是「最像」，不是「最對」；所以實務上後面常會再接一個 rerank 重新排序，或用混合式檢索補上關鍵字。
最常搞錯的地方
- 以為向量庫能取代所有資料庫。它擅長「模糊的、看意思的」查詢，卻不擅長精確匹配：查一個確切的訂單編號、錯誤代碼、人名，傳統的關鍵字檢索反而更準。
- 一開始就上昂貴的大型託管服務。很多場景用本地的嵌入式向量庫（如 SQLite 的向量擴充、LanceDB、Chroma）就夠了，先本地跑通再考慮託管。