向量資料庫讓 AI 用語意找資料，是 RAG 知識庫的核心。本文從嵌入向量、近似最近鄰索引、混合檢索到重排序拆解運作機制，附上記憶體與命中率的實測級數字，並給出中小企業選型、切塊與地端部署的工程判斷準則。
先搞懂：向量到底存了什麼
向量資料庫存的不是文字，是「嵌入向量」（embedding）。你把一段文字丟進一個嵌入模型，它會吐回一串幾百到上千個數字，這串數字等於把那句話的語意壓成了一個高維空間裡的座標。關鍵在於：意思相近的句子，座標自然就靠得近。所以「出貨要多久」跟「交期說明」哪怕一個字都沒重疊，在向量空間裡卻是鄰居，系統照樣撈得出來。這種用「意思」而不是「字面」去找的能力，就叫語意檢索，也是 RAG 能聽懂人話的根本。
檢索當下發生的事其實很單純：系統先把使用者的問題也轉成一個向量，再去資料庫裡找「離它最近」的那幾段。衡量遠近通常用餘弦相似度（cosine similarity），說穿了就是比兩個向量指的方向像不像。方向越接近，語意越相關。理解到這一層，你就會發現向量資料庫的本質，是一台專門做「最近鄰搜尋」的機器，剩下的工程難題全都圍繞著一件事：資料一多，這個「找最近」要怎麼又快又準。
為什麼一定要「近似」：ANN 索引的工程取捨
不同模型、資料集、提示、判分方式與正式流量，結果可能差很多。公開 benchmark 只能用來理解方法，不能直接當成專案承諾；驗收應使用公司自己的題庫，分別記錄正確率、引用支持率、拒答、延遲、成本與人工覆核量。
目前主流的做法大致三種，各有脾氣，選錯了成本會差很多：
- 圖索引（HNSW）：把向量連成一張多層的小世界圖，查詢時像在社群網路裡「找朋友的朋友」快速逼近目標。命中率高、支援動態新增，是 2026 年多數線上場景的預設選擇，代價是它得整份長駐在記憶體裡，比較吃 RAM。
- 叢集索引（IVF）：先用分群把向量切成一塊塊，查詢時只掃相關的幾塊。記憶體省、建索引快，特別適合資料量極大又不太更動的靜態庫。
- 量化壓縮（PQ）：把向量切段後各自用碼本編碼，用少量位元近似原始座標，能把記憶體壓掉一個數量級，代價是精度略降，常拿來搭配前兩者。
為什麼單靠語意還不夠：混合檢索與重排序
語意檢索很強，但它有個罩門：碰到料號、型號、零件代碼這種「差一個字就是另一顆東西」的場景，它反而會被自己的「語意近似」害到，把 A203 跟 A230 當成很像。這不是猜的——有金融、生醫領域的檢索實測就發現，在專有名詞、代碼密集的文件上，老派的關鍵字演算法 BM25 命中率反而贏過純語意檢索。這也解釋了那位台南老闆的另一半煩惱：客人有時打的就是精確料號，這時候你要的是「一字不差」，不是「意思相近」。
嵌入模型與切塊：品質其實在這裡就定生死
很多人把力氣全花在挑資料庫，卻忘了檢索品質的上限，早在嵌入模型和切塊策略這一步就被鎖死了。
嵌入模型：中文友善與維度的取捨
切塊：一段切多長，直接決定撈得到撈不到
選型該看什麼：把採購與資安一起算進去
市面上的向量資料庫從嵌入式輕量方案到雲原生服務一大票。對中小企業，我通常從這幾個面向逐一過：
- 資料量級：幾萬段跟幾億段是兩個世界，決定你走 HNSW 還是得動用 IVF 與量化。先老實估自己三年後的量，別為用不到的規模超前投資。
- 過濾與權限是不是「先過濾再搜」：這點最常被漏掉，卻最要命。好的向量庫把中繼資料過濾當成第一級能力（pre-filter），在搜尋當下就只在「這個部門有權看」的範圍裡找；差的做法是先全庫搜完再事後砍掉沒權限的，不只慢，還可能把不該露出的內容先算進相似度。要做部門級的存取控管，這條是硬指標。
- 部署形態：雲端託管上手快，但在意資料不外流的公司，地端自管或私有部署往往才是重點——尤其牽涉客戶名單、報價、財務的知識庫。
- 維運人力：這是採購最容易低估的一筆。自建一套正式環境的向量庫，業界抓的維運人力大約要半個到一個工程師的量能去顧擴充、備援與監控。算總成本時，把這筆人力一起放進去，才不會上線後才發現帳對不起來。
常見誤區與務實起步
最後講幾個我在現場最常勸退的坑。第一，別一開頭就追求最大規模、最炫的架構，結果連第一個場景都遲遲上不了線；先挑單一場景、把資料量控制住，把檢索品質驗起來，再慢慢擴。第二，別急著評論「模型答得好不好」，回答品質的天花板是檢索給的——先量召回率，撈不對，後面模型再強也是巧婦難為無米之炊。第三，別把向量檢索當萬靈丹，料號、法條號、日期這種要精確的欄位，老實搭上關鍵字與過濾，混合著用才穩。
廷皓科技在高雄，長期協助南台灣企業規劃向量資料庫與 RAG 知識庫，從嵌入模型挑選、切塊策略、混合檢索與重排序調校，到部門權限控管與地端／私有部署都能一起把關，也會把記憶體、儲存與維運人力的總帳算給你看，不讓你為用不到的規模多花錢。想讓 AI 真正聽懂你公司的行話，歡迎找我們聊聊。
