向量檢索與 embedding 是什麼?用企業語意搜尋的實例講清楚原理

一句話先講定義:向量檢索 (vector retrieval) 是把文字先用 embedding 模型轉成一串代表「語意座標」的數字向量,再靠計算向量之間的距離,找出「意思最接近」而非「字面最相同」的內容。 而 embedding,就是那個把一句話、一段文件、甚至一張圖翻譯成向量的過程。

這句話有點抽象。我們用一個真實踩過的場景把它攤開。

為什麼關鍵字搜尋會漏掉答案

去年一家保險客戶的內部知識庫,員工在搜尋框打「保單到期沒繳錢會怎樣」,系統回傳零筆。文件明明存在,標題叫「寬限期與契約停效處理原則」。

問題出在:傳統關鍵字搜尋 (keyword search) 比對的是「字」。使用者打的字裡沒有「寬限期」「停效」,文件裡也沒有「沒繳錢」,兩邊字面不重疊,引擎就認定不相關。它不懂「到期沒繳錢」和「寬限期停效」講的是同一件事。

這不是 bug,是關鍵字檢索的天花板。它靠 TF-IDF、BM25 這類演算法算「詞頻」,本質上是在數字面重合度。同義詞、口語、換句話說,它一律當陌生人。

向量檢索 embedding 是什麼:把語意變成可比對的座標

語意搜尋 (semantic search) 換了一條路。它不比字,比「意思」。

具體怎麼做?先讓 embedding 模型讀「保單到期沒繳錢會怎樣」,吐出一串向量,例如 1,536 個數字;再讓同一個模型讀那份「寬限期與契約停效」文件,也吐出一串向量。這兩串數字在一個高維空間裡的位置會非常接近,因為模型在海量語料裡學過:這些詞經常出現在相似的上下文,語意相關。

於是檢索就變成一道幾何題:算兩個向量的夾角 (餘弦相似度),角度越小、代表意思越近。使用者那句口語問題,即使一個關鍵字都沒對上,照樣能撈出正確文件。

這就是 embedding 的核心價值——它把「語意」這種模糊的東西,壓縮成電腦能直接做數學運算的座標。意思相近的內容,向量就靠得近;意思無關的,離得遠。搜尋從「找一樣的字」升級成「找一樣的意思」。

兩種檢索,並排看差異

看到最後兩列了嗎?向量檢索不是全面碾壓。查「料號 A-8837」或「勞基法第 84 條之 1」這種精確代號,關鍵字搜尋反而更穩,因為那本來就該一字不差。所以生產環境我們幾乎都跑混合檢索 (hybrid),語意向量負責理解意圖,關鍵字負責鎖定精確詞,再把兩邊分數融合排序。

為什麼這是 RAG 檢索品質的根本

講到這裡,得把 embedding 拉回 RAG (檢索增強生成) 的脈絡。

RAG 的運作是:使用者提問→系統從企業知識庫檢索相關片段→把片段連同問題塞給大型語言模型→模型根據這些真憑實據生成回答。很多人把注意力全放在後半段的模型多聰明,卻忽略一件事——模型只能根據「檢索階段撈給它的東西」作答。

檢索撈錯,模型再強也只是把錯的資料講得很通順。這就是所謂 garbage in, garbage out,在 RAG 裡尤其致命,因為它會生出一段自信、流暢、卻是錯的回答。

而檢索撈得準不準,第一道關卡就是 embedding 品質。用了不理解中文語意的模型、切文件 (chunking) 的方式把一個完整概念切兩半、或是沒針對產業術語微調,向量座標就會失真,語意相近的文件在空間裡反而離得老遠。前端問答再怎麼優化 prompt 都補不回來。所以我們常說:RAG 的天花板,在 embedding 這一層就先決定了大半。

實務上,我們接手一個知識系統,第一件事往往不是換更貴的生成模型,而是回頭盤 embedding 模型選型、重切 chunk、補上混合檢索,再用客戶真實的問句去量「該撈到的文件有沒有進前五名」。Demo 裡答對三題不算數,員工每天亂七八糟地問、系統還能穩定撈對,那條檢索管線才算真的上線。