一句話說明

語意搜尋（Semantic Search）是一種讓電腦理解「你想問什麼」而不只是「你打了什麼字」的搜尋技術。

什麼是語意搜尋？

傳統搜尋的運作方式是比對關鍵字。你輸入「蘋果手機維修」，搜尋引擎就去找包含這幾個字的文件。問題是，如果文件裡寫的是「iPhone 螢幕碎裂處理方式」，傳統搜尋可能找不到，因為字面上完全不一樣。

語意搜尋解決的就是這個問題。它不看字面，而是理解你這句話的意思，然後去找意思相近的內容。就像你問一個懂行的朋友，他不會只聽你說的字，而是理解你真正想知道什麼。

這個技術背後靠的是 Embedding，也就是把文字轉換成數字向量。意思相近的文字，轉換出來的向量會靠在一起。搜尋的時候，就是去找向量空間中離你的問題最近的那些內容。

語意搜尋怎麼運作？

整個流程可以拆成兩個階段：建立索引和執行搜尋。

建立索引階段：

  1. 把你的文件資料透過 Embedding 模型轉換成向量
  2. 如果文件很長，先做 Chunking 把它切成適當的小段落
  3. 每個段落各自轉換成一個向量
  4. 把這些向量存進 向量資料庫

執行搜尋階段：

  1. 使用者輸入查詢問題
  2. 把問題也轉換成向量
  3. 在向量資料庫中找出最接近的向量（用餘弦相似度或其他距離計算）
  4. 回傳對應的原始文字段落

這裡的關鍵是 Embedding 模型的品質。好的模型能夠理解同義詞、上下文關係，甚至跨語言的對應。目前常用的模型包括 OpenAI 的 text-embedding-3-small、Cohere 的 embed-multilingual-v3.0，以及開源的 BGE、E5 系列。

關鍵字搜尋 vs 語意搜尋

比較項目 關鍵字搜尋 語意搜尋
匹配方式 字面比對 意思理解
同義詞處理 需要手動設定同義詞表 自動理解同義詞
錯字容忍度 低，打錯字就找不到 中等，看 Embedding 模型能力
建置成本 低，現成工具多 中高，需要 Embedding 模型和向量資料庫
搜尋速度 非常快 稍慢，需要向量計算
適合場景 精確查找、已知關鍵字 模糊查詢、自然語言問答
可解釋性 高，知道為什麼匹配 低，向量距離不直觀

實務上，很多系統會把兩種搜尋結合在一起，叫做混合搜尋（Hybrid Search）。先用關鍵字搜尋快速縮小範圍，再用語意搜尋重新排序，取兩者的優點。

實際應用場景

語意搜尋已經在很多地方被使用：

RAG 系統：這是目前最熱門的應用。當你問 AI 一個問題，RAG 系統會先用語意搜尋從你的文件中找到相關段落，再把這些段落餵給 LLM 產生回答。這樣 AI 的回答就能根據你自己的資料，而不只是靠模型訓練時學到的知識。

企業內部知識庫：台灣很多公司開始用語意搜尋來改善內部知識管理。以前員工要找一份 SOP，必須記得正確的文件名稱或關鍵字。有了語意搜尋，員工可以直接用自然語言問「客戶退貨流程怎麼走」，系統就能找到相關文件。

客服系統：客戶的問題五花八門，同一個問題可能有十種不同的問法。語意搜尋能把這些不同的問法都對應到正確的解答，大幅提升自動客服的準確率。

電商搜尋：使用者搜「適合夏天穿的透氣上衣」，語意搜尋能找到標籤是「涼感」「吸濕排汗」「短袖」的商品，而不只是標題裡有「透氣」的。

程式碼搜尋：開發者可以用自然語言描述功能，例如「處理使用者登入的函式」，語意搜尋能在程式碼庫中找到相關的程式碼片段。

台灣使用情境

台灣企業在導入語意搜尋時，有一個特殊的挑戰：中英文混用。台灣的技術文件常常中文夾雜英文術語，例如「請確認 API endpoint 的 timeout 設定」。

好消息是，目前主流的多語言 Embedding 模型對這種混合語言的處理能力越來越好。如果你的資料以繁體中文為主，建議測試幾個模型的效果再決定。OpenAI 的 Embedding 模型對中文支援不錯，BGE-M3 等開源模型也有針對中文優化的版本。

另外，台灣的法規文件搜尋也是一個實際場景。法律條文用語和一般人的說法差很遠，語意搜尋能幫助使用者用白話去找到對應的法條。

安全考量與限制

語意搜尋也有它的限制和安全風險：

搜尋結果不可解釋：關鍵字搜尋很清楚告訴你為什麼這個結果被找到（因為包含某個關鍵字）。語意搜尋靠的是向量距離，使用者很難理解為什麼某個結果排在前面。在需要稽核的場景，這是個問題。

Embedding 偏見：Embedding 模型是從大量文字資料訓練出來的，裡面可能包含偏見。例如某些族群或性別相關的詞彙，模型可能會給出有偏差的相似度。

資料外洩風險：如果你用雲端的 Embedding API，你的文件內容會被送到外部伺服器。機敏資料需要評估是否適合使用雲端服務，或者改用本地部署的 Embedding 模型。

準確度不穩定：語意搜尋在處理專業術語、縮寫、或非常特定的查詢時，效果可能不如關鍵字搜尋。例如搜尋特定的錯誤代碼「ERR_CONNECTION_REFUSED」，關鍵字搜尋反而更可靠。

成本考量：每次搜尋都需要呼叫 Embedding 模型做向量轉換，大量搜尋的情況下 API 費用會累積。向量資料庫本身也需要額外的基礎設施成本。

怎麼開始？

如果你想在自己的專案中加入語意搜尋，以下是建議步驟：

  1. 準備資料：把你的文件整理好，決定要怎麼做 Chunking（切段落）。一般建議 200-500 個 token 一段，段落之間保留一些重疊。

  2. 選擇 Embedding 模型：先用 OpenAI 的 text-embedding-3-small 試試效果。如果有隱私考量，可以用開源的 BGE 或 E5 模型在本地跑。

  3. 選擇向量資料庫：小規模可以用 ChromaDB 或 FAISS（免費）。中大規模可以考慮 Pinecone、Weaviate 或 Qdrant。

  4. 建立搜尋管道：把上面的元件串起來。可以用 LangChain 等框架來簡化開發。

  5. 測試和調校：準備一組測試查詢，檢查搜尋結果的品質。調整 chunk 大小、試不同的 Embedding 模型、加入 hybrid search。

一個最簡單的 Python 範例用 ChromaDB：

import chromadb

client = chromadb.Client()
collection = client.create_collection("my_docs")

# 加入文件
collection.add(
    documents=["台灣的 AI 產業正在快速發展", "人工智慧在醫療領域的應用越來越廣"],
    ids=["doc1", "doc2"]
)

# 語意搜尋
results = collection.query(query_texts=["AI 在台灣的發展狀況"], n_results=1)
print(results["documents"])

ChromaDB 會自動幫你處理 Embedding 的部分，很適合用來快速原型開發。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

語意搜尋可以完全取代關鍵字搜尋嗎？

不行。兩種搜尋各有適合的場景。精確查找（例如搜尋特定的產品編號、錯誤代碼）用關鍵字搜尋更可靠。模糊查詢、自然語言問答用語意搜尋效果更好。目前業界的最佳做法是混合搜尋（Hybrid Search），結合兩者的優勢。

語意搜尋需要 GPU 嗎？

Embedding 模型的推論（把文字轉成向量）在 CPU 上也能跑，只是速度比較慢。如果你的資料量很大，需要一次轉換大量文件，有 GPU 會快很多。搜尋階段（向量比對）本身不需要 GPU，向量資料庫用 CPU 就能處理。

語意搜尋支援中文嗎？

支援，但效果取決於你用的 Embedding 模型。OpenAI 的 text-embedding-3 系列對繁體中文的支援不錯。開源模型方面，BAAI 的 BGE-M3 和 Cohere 的 embed-multilingual-v3 都有不錯的中文效果。建議用你自己的中文資料實際測試，不要只看公開的英文 benchmark 排名。

語意搜尋和 RAG 有什麼關係？

語意搜尋是 RAG 的核心元件之一。RAG 的流程是：語意搜尋找到相關文件 → 把文件餵給 LLM → LLM 根據文件生成回答。沒有好的語意搜尋，RAG 的回答品質就會很差，因為 LLM 拿到的參考資料不對。

總結

語意搜尋讓搜尋從「比對文字」進化到「理解意思」。它靠 Embedding 把文字轉成向量，用向量距離來判斷相關性。最常見的應用是在 RAG 系統中幫 AI 找到正確的參考資料。

實際導入時，建議從小規模開始測試，注意中文支援的品質，考慮隱私和成本問題，並且善用混合搜尋來彌補純語意搜尋的不足。

參考資料