番外一：電商搜尋技術三代拆解——從 BM25 到 LLM，一個麻瓜的學習筆記

2026 Mar 23 AI 實戰筆記

內容目錄

番外一：電商搜尋技術三代拆解——從 BM25 到 LLM，一個麻瓜的學習筆記

這篇是〈我們的搜尋無所獲，是平台的商業選擇〉的技術番外。主文聚焦商業分析，這篇把技術細節完整展開，包含搜尋系統的六步驟 Pipeline、三代演進的工程邏輯、以及一個能持續優化的搜尋系統需要的四層基礎建設。

搜尋系統的六步驟 Pipeline

說是技術，但以我麻瓜等級的理解來看，其實就是三步驟、六動作的 Pipeline：

輸入、理解：輸入到一半甚至還沒輸入，預測要查什麼、錯別字友善。
改寫、比對：錯字改對後，決定是品類還是品牌，跟商品或品牌關鍵字做比對。
召回、排列：吐出幾個比對結果，按照事先設計的權重排優先順序。

技術的三代演進

第一代：關鍵字比對 + 查詢理解層（BM25 + Query Understanding）

第一代搜尋的基礎是 BM25（一種機率式文字比對公式），這也是 Elasticsearch 最常用的預設演算法。

它的運作邏輯很直觀：把用戶的查詢詞拆成 token（詞根），在資料庫裡找包含這些 token 的商品，再根據詞頻打分。

BM25 有一個根本的數學假設：用戶輸入的詞，必須跟商品描述的詞一模一樣。

這個假設在英文有空白斷詞的環境下運作良好，但在繁體中文卻是一場災難。

為了應對中文，Elasticsearch 內建的 CJK 中日韓分析器通常採用 bi-gram（雙字節）切割法：把相鄰的字兩兩切開。

所以，「遙控器」會被切成「遙控」「控器」；而注音錯字「搖控器」則會被切成「搖控」「控器」。

從演算法的角度來看，「遙控」和「搖控」是兩個完全無關的 token。

這就解釋了為什麼搜「搖控器」跑不出原本的「遙控器」商品：因為這兩個 token 的比對分數落差極大。

陷入「維護地獄」的查詢理解層（QU）

為了彌補這個演算法的死板，工程師會在前面加上一層「查詢理解層（QU）」。

在標準的系統架構中，處理「搖控＝遙控」、「蘋果15＝iPhone 15」並不是什麼高深的 AI 技術，而是透過建立「同義詞字典（Synonym Dictionary）」與「正規化規則」來解決。

理論上，只要把這本字典建好，第一代搜尋也能做到很精準。但在台灣電商的落地實境中，這成了無解的困境：

開源字典水土不服：最常用的 jieba 斷詞庫偏重簡中語料；中研院的 CKIP 是學術語料訓練出來的，根本不懂什麼是「神仙水」或「老爹鞋」。
詞典維護是勞力密集的人力活：電商語言是活的，每週都有新造詞、新品牌、特殊規格出現。要維持第一代搜尋的精準度，平台必須養一組專職團隊，天天分析 user log，手動更新同義詞與錯字庫。(現在也可以靠Agent, 但還是要有人去寫需求，磨內容）

台灣各平台的搜尋之所以難用，往往不是卡在演算法的極限，而是卡在維運的貧窮。

當平台不願意投入資源去持續維護、擴充專屬的「繁中電商詞典」時，最基礎的同義詞轉換就會失效，最終把演算法斷詞的數學結果（搜出毫不相干的商品），赤裸裸地丟給消費者承擔。

第二代：向量語意搜尋（Dense Retrieval）——向量搜尋不是萬靈丹，混合搜尋（Hybrid Search）才是及格線

第二代技術引入了向量語意搜尋（Dense Retrieval），將查詢詞與商品轉化為高維度向量，透過計算空間距離（餘弦相似度）來判斷相關性。

這確實帶來了突破：系統不再死守字面一致，模型能自動從語料中學到「想吃辣的」與「麻辣鍋」在語意上高度重疊。

然而，若盲目迷信 AI，純向量搜尋在電商場景會引發災難。它有一個關鍵弱點：「語意相近」絕對不等於「規格相同」。

當消費者精準搜尋「iPhone 15 Pro Max 256G 深空黑」時，純向量模型會因為 512G 或原色鈦的款式在「語意上極度相似」而將其大量召回，這對想買特定型號的用戶來說完全是干擾。

在這種強烈依賴精確匹配的查詢上，第一代的 BM25 反而具備不可替代的優勢。因此，當今工程界的最佳實踐（Best Practice）是實施 Hybrid Search（混合搜尋）：

讓 BM25 與向量搜尋雙軌並行，各自召回候選商品。系統在重新排序（Re-ranking）階段，透過權重融合來決定最終版面：

精確型號拉高 BM25 的權重；
面對「送媽媽的禮物」這類模糊意圖，則拉高向量信號的權重。

這並不是遙不可及的黑科技，韓國電商巨頭 Coupang 也是基於此思路打造搜尋引擎。

真正的卡點：繁中電商語料的在地化微調

架構可以買，但「領域認知」買不到。

市面上通用的中文向量模型大多基於簡體語料訓練，且通用語意與電商語意存在巨大鴻溝。例如，在美妝購物的語境裡，「奶油」指的是保養品的乳霜質地，而不是食材。

台灣平台若只套用開源的向量架構，卻不投入資源與算力，拿自己獨有的「繁中電商語料」去對模型進行領域微調（Domain Fine-tuning），其向量召回的品質必然大打折扣。

說穿了，混合搜尋的框架只是骨架，那顆經過百萬筆台灣真實交易數據微調過的向量腦，才是別人偷不走的護城河。

第三代：LLM 查詢理解 + 對話式商務——後台的苦工與前台的革命

許多人對第三代搜尋的幻想，是在 App 裡放一個無所不知的 AI 助理。但現實是，大型電商的第三代技術發展，目前必須走向截然不同的「雙軌制」：

軌道一：隱身後台的 LLM 基礎設施（以淘寶 BEQUE 為例）

在百萬級流量的電商首頁，每一次搜尋都呼叫 LLM 進行即時推理，不僅會輕易擊穿 P99 < 200ms 的延遲防線，消耗的 API Token 成本更會直接吃掉已經很微薄的訂單毛利。

真正具備商業可行性的做法，是把 LLM 當作「離線的資料工人」。

如淘寶的 BEQUE 框架，是利用大模型在「離線端」大量閱讀 user log，清洗並提煉出「長尾查詢 → 精準關鍵字」的改寫規則（例如把「送媽媽的實用禮物」轉譯為「肩頸按摩儀、保養品套組」），再將這些輕量化的規則部署回第一、第二代的檢索系統中。

這才是兼顧 AI 語意理解，同時死守維運成本的工業級最佳實踐。

軌道二：徹底顛覆 UI 的對話式商務（以 inline 為例）

當 AI 走向前台，它改變的就不再是「搜尋框」，而是徹底消滅搜尋框。

台灣本土最接近這個型態的案例是 inline 的 AI 訂位小助手。用戶的真實需求往往不是「輸入關鍵字找結果」，而是「描述情境，讓 AI 幫我決定」。當用戶輸入「週五晚上兩人聚餐有什麼推薦？」，AI 必須同時處理意圖理解、即時空位資料整合，並在對話中直接完成交易。

這揭示了一個殘酷的現實：傳統電商的「關鍵字搜尋框」是建立在「用戶知道自己要找什麼」的假設上。當 LLM 普及，消費者越來越習慣用自然語言表達模糊需求時，固守傳統搜尋框的平台，將會連用戶的真實意圖都接不住。

基礎建設：一個能持續優化的搜尋系統需要什麼

站內搜尋不是寫 demo 做開心的 vibe coding，而是一個需要 24 小時不斷水不斷電、持續優化的維運系統。一個能運作的工業級搜尋，必須具備四層基礎建設。

資料層

商品索引管道（Ingestion Pipeline）：從商品資料庫到搜尋索引的持續同步機制。台灣電商每天商品異動量以百萬計，索引延遲是基礎中的基礎。
用戶行為日誌（Behavioral Log）：每一次搜尋、點擊、購買、放棄，都必須被完整記錄：這是 Learning-to-Rank 模型的訓練資料來源，也是為什麼 Google 搜尋有登入後會越來越準（雖然很多人不喜歡）。沒有行為日誌就沒有辦法讓排名模型學習哪個結果相關、哪個不相關。