wen aidev
Published on

Azure AI Search（一）：Keyword vs Vector 與 SQL DB 抉擇

Table of Contents

當我們終於把 OpenAI API 串好，興沖沖地把公司的幾萬份 PDF 倒進資料庫，做成了今年最夯的 Retrieval-Augmented Generation (RAG) 系統後，滿心期待老闆的誇獎。

但老闆試用的第一句話卻是：「這東西是不是壞了？為什麼我搜尋『請假規定』，它卻回答我『請採購設備規定』？而且我明明放了今年的『特休辦法』，它怎麼一篇都沒找出來？」

歡迎回到現實世界。這就是單純依賴 Keyword Search (關鍵字搜尋) 所面臨的極限。

在這個《Azure AI Search 全面解析》三部曲中，我們將從最基礎的檢索底層原理開始，一路探討到微軟在 2024/2025 拋出的震撼彈：Azure SQL Database 原生支援向量搜尋！ 到底我們該把向量存在熟悉的 SQL 裡，還是該花錢開一台專屬的 Azure AI Search？

為什麼你的 RAG 總是找不到資料？

在理解 Azure 的服務之前，我們必須先釐清「名詞的顆粒度」。當我們說「搜尋」，其實底層分為截然不同的兩大流派：

1. Keyword Search (Lexical / BM25 演算法)

這就是傳統資料庫和搜尋引擎（如早期的 Elasticsearch 或 SQL 的 LIKE、Full-text search）在做的事。它的核心邏輯是字詞比對。

  • 優點：找「料號 (AB-1234)」、「特定人名 (王小明)」或「錯誤代碼 (Err-500)」時，神準無比。
  • 痛點：它不懂同義詞也缺乏上下文理解。你搜尋「請假」，它就只會找文件裡剛好有「請假」兩個字的文章。如果 HR 寫的是「特休申請辦法」，即使語意完全符合，它也絕對找不到。更慘的是，它可能會找到「如果設備壞掉，『請假』設一台新機器」這種毫無關聯的文件，只因為關鍵字命中了。

2. Vector Search (Semantic / KNN 演算法)

這就是 Generative AI 時代的救星。我們透過 Embedding 模型（如 text-embedding-3-small），把人類的每一句話轉換成高維度空間中的座標點（浮點數陣列）。

  • 優點：它懂語意和上下文。在向量座標系中，「請假」、「特休」、「休假」這三個詞的距離會非常靠近。所以當你搜尋「請假」，它能幫你把附近那些寫著「特休申請」的文件一把抓回來。
  • 痛點：它是算「距離相似度」，所以有時候會因為過度迷信語意，反而錯過了需要這兩個字「完全精準命中」的特定料號查詢。
傳統 Keyword Search 與 Vector Search 檢索邏輯對比

圖說：Keyword 就像是嚴格的守門員，只認通行證上的字；而 Vector 就像是個能聽懂你弦外之音的管家。

2025 開發者最痛抉擇：向量存在哪？

既然知道 Vector Search 是 RAG 的必備品，那下一個問題就是：這些由浮點數組成的向量，我要存在哪裡？

過去，你可能必須去架設 Pinecone, Weaviate 或是專屬的 Azure AI Search。但在 2024 年底到 2025 年，微軟投下了一顆震撼彈：Azure SQL Database 開始原生支援 VECTOR 型別與距離計算！

這讓許多架構師與開發團隊瞬間得了選擇困難症：「我本來資料就存在 SQL DB 裡，現在它也支援向量了，那我還需要買 Azure AI Search 嗎？」

選手一：Azure SQL Database (向量融入現有資料庫)

微軟在 SQL DB (以及 SQL Server 2025) 引入了專屬的 VECTOR 資料型別，並且提供了 VECTOR_DISTANCE 這樣的原生 SQL 函數，讓你直接算 Cosine Similarity (餘弦相似度)。

-- 實戰中，你可以用這樣一句 SQL，同時撈出員工資料跟向量相似度！
SELECT top 5
    EmployeeID,
    DocumentName,
    VECTOR_DISTANCE('cosine', DocumentVector, @UserQueryVector) AS SimilarityScore
FROM HRDocuments
ORDER BY SimilarityScore;

Azure SQL DB 適合什麼情境？

如果你有強烈的「資料即時一致性 (ACID)」與「 多表 Join (關聯查詢) 」需求。例如：你不只要找「相似的訂單」，你還要當場 Join 會員表，過濾掉「已停權的會員」，而且資料庫發生 Update 時，向量檢索必須在毫秒內同步生效。

選手二：Azure AI Search (建立強大獨立檢索大腦)

Azure AI Search (前身為 Cognitive Search) 則是徹頭徹尾、為了「大規模搜尋引擎」與「RAG 檢索」而生的 PaaS 服務。它不只存向量，它給你的是一整套端到端的 AI 檢索管線 (Pipeline)。

Azure AI Search 適合什麼情境？

如果你要打造企業級的知識庫對答機器人 (Chatbot)、各種爬蟲聚合而來的文檔中心。因為它內建了爬取 PDF / Blob 的 Indexer，最重要的是：它擁有 開箱即用的 Hybrid Search 與 Semantic Ranker （我們下一篇的重點）。

架構選型大哉問：Azure SQL Database vs Azure AI Search

圖說：在極簡架構與極致檢索效能之間的決策。如果只是想實驗 Vector，SQL DB 最快；如果要做完美的 RAG，AI Search 才是歸宿。

下一步：小孩子才做選擇

如果你仔細看上面第一張 Keyword vs Vector 的圖，你會發現一個致命的問題：Vector 懂語意，但常常錯過最精準的關鍵字；Keyword 懂精準關鍵字，卻對同義詞一無所知。

如果老闆就是同時要搜「特定料號 (Keyword)」加上「請假規定 (Vector)」，怎麼辦？

這正是為什麼 Azure SQL Database 雖然支援向量，但在頂級 RAG 體驗中，很多團隊仍會選擇 Azure AI Search 的原因。因為我們需要把Keyword 與 Vector 結合成 Hybrid Search，並且利用 RRF (Reciprocal Rank Fusion) 演算法來做完美的分數融合。

具體怎麼做？原理是什麼？我們在下一篇文章中，為您揭曉 2025 年搜尋系統的標配：混合檢索大揭密！

留言討論