你在公司的文件庫搜尋「離職後還能不能拿到年終」,結果真正相關的規則寫的是「獎金發放基準日仍具在職身分」。兩段文字幾乎沒有共用關鍵字,但人一看就知道它們在談同一件事。傳統全文搜尋不是完全做不到,只是如果系統主要依賴字詞重合,這種改寫、同義詞和不同表達方式就比較容易漏掉。

Semantic Search,可以先理解成:根據查詢和資料在語意上的相關程度來排序結果,而不是只看字面是否相同。 現代 AI 應用裡,常見做法是先用 embedding model 把文件和查詢轉成向量,再比較它們的距離或相似度,找出最接近的內容。

先記一句:Keyword search 比較在意「有沒有出現這些字」;semantic search 比較在意「這些內容是不是在講相近的事情」。

它不是把一句話交給 AI,然後讓 AI 猜答案

很多人第一次聽到「語意搜尋」,會想像成每次搜尋都把整個資料庫交給大型語言模型,叫它逐筆判斷哪一篇最相關。這當然可以做,但在大量資料上通常很慢,也很貴。更常見的架構,是先在資料進系統時產生 embeddings,把每筆內容表示成一串數字;搜尋時只需要把新的 query 也轉成向量,接著做向量相似度搜尋。

文件 → Embedding → 文件向量
查詢 → Embedding → 查詢向量 → 相似度搜尋 → 候選結果

因此 semantic search 跟 Vector Database 很常一起出現,但兩者不是同一件事。Semantic search 是搜尋方式;Vector Database 是可以幫你儲存、索引與快速搜尋向量的資料系統。資料量不大時,你甚至可以不用獨立的向量資料庫,也照樣做 semantic search。

「語意相近」其實是模型學出來的距離

假設 embedding model 把「筆電沒電了」和「我的 notebook battery is dead」映射到向量空間裡相近的位置,搜尋系統就有機會在沒有完全相同字詞的情況下把兩段內容配在一起。實務上常用 cosine similarity、dot product 或其他距離函數衡量兩個向量的接近程度。

但要小心一個重要邊界:相似度不是理解程度,也不是正確性的分數。 一段文字跟問題很像,不代表它就是正確答案;更不代表它符合目前版本、使用者權限或特定市場的規則。Embedding 提供的是一個搜尋訊號,後面仍然需要 metadata filter、版本控制、權限檢查或其他規則。

為什麼不能全部改成 Semantic Search?

因為很多搜尋根本不需要猜意思。你找訂單編號 AB-90317、錯誤碼 ERR_CONNECTION_RESET、產品型號或某個人名時,精確字詞本身就是最重要的訊號。如果 dense semantic retrieval 太強調整體意思,反而可能把「看起來很像」但代碼完全不同的結果排上來。

反過來,單靠 keyword search 也有弱點。文件寫「取消訂閱」,使用者搜尋「停止續費」;文章寫「顯示卡記憶體不足」,使用者輸入「VRAM 爆掉」。字面可能不同,但意圖非常接近。這就是 semantic search 最有價值的地方:它能補上純字詞匹配對改寫、同義詞與自然語言表達的不足。

Hybrid Search:不要硬選一邊

所以很多搜尋系統最後不是在 keyword 與 semantic 之間二選一,而是兩個都跑。常見的 hybrid search 會同時做 sparse/keyword retrieval 和 dense/vector retrieval,再把兩邊的候選結果合併或融合排序。這樣一來,精確代碼和專有名詞仍能靠字詞匹配被抓到,自然語言改寫則由向量搜尋補足。

同一個 Query → Keyword Search ┐
          ├→ 合併候選 → 排序
      → Vector Search ┘

這個「合併」也不是把兩個分數直接相加就一定合理。不同檢索方法的分數尺度可能完全不同,因此系統可能用 reciprocal rank fusion(RRF)、加權融合或其他 ranking 方法整合候選。真正好的搜尋品質,通常是檢索策略、資料品質與評估一起調出來的,不是換上一個 embedding model 就結束。

Reranking 又是在做什麼?

第一階段搜尋通常要快,所以先從幾萬、幾百萬筆資料裡找出一小批候選,例如前 20 或前 100 筆。接著可以再用比較昂貴、但判斷相關性更細緻的模型,重新看 query 與候選文件之間的關係,把真正最相關的結果排到前面。這一步就是 reranking。

Semantic reranker 和最初的 vector search 不完全一樣。向量搜尋通常把 query 和 document 分別編碼成向量,先快速找近鄰;reranker 則可以在較少的候選上直接比較 query 與文件內容,因此能用更多計算換取更細的排序。Elastic 的文件也把 semantic reranking 定位成早期 retrieval 之後、針對小型 top-k 候選集進行的後段步驟。

它在 RAG 裡其實就是「找資料」那一段

RAG 不會因為用了 LLM 就自動知道整個知識庫。模型回答以前,系統得先從外部資料找出這次可能有用的內容。Semantic search、hybrid search、metadata filter 和 reranking,都是在改善這個 retrieval 階段。

問題 → 搜尋候選 → Filter / Hybrid / Rerank → 相關文件 → Context Window → LLM 回答

也因此,RAG 回答錯誤不一定是 LLM 本身的問題。如果檢索階段根本沒有找到真正的規則,後面的模型就只能根據錯的或不完整的 context 作答。做 RAG 評估時,把「有沒有找對資料」和「拿到正確資料後有沒有回答好」分開看,通常會比只盯著最後答案更有用。

Semantic Search 不是「更聰明的 Ctrl+F」

它真正改變的是搜尋的表示方式:從比對字詞,變成比較 query 與資料在模型表示空間裡的關聯。但這不會讓精確搜尋、資料欄位、權限、時間條件突然失去價值。很多成熟系統最後都會混合多種信號,而不是迷信單一技術。

所以如果只記住最後一句:Semantic Search 的核心不是讓 AI「讀懂整個資料庫」,而是把查詢和資料轉成可以比較的表示,利用語意相似度找候選;真正可靠的搜尋,往往還會和關鍵字、條件過濾與 reranking 一起工作。

接著讀

Embedding 是什麼?Semantic search 為什麼能比較「意思」,核心就在 embedding。→ Vector Database 是什麼?有了向量之後,下一步就是怎麼快速把相近的資料找出來。→

參考資料

Qdrant — Hybrid Search in Qdrant

Elastic — Semantic reranking