揮別「查無此字」的跳出率夢魘！2026 實戰：導入 LLM 徹底翻轉 WordPress 搜尋的意圖識別與結果重排架構
☰ 目錄 table-of-contents.md
WordPress 搜尋該怎麼變聰明？
訪客只是換了個說法描述商品，LIKE %keyword% 字面比對就回他一句「查無此商品」，然後人就走了——站內搜尋是使用者流失最快、卻最少被檢討的破口。解法是把搜尋從關鍵字比對升級為混合搜尋（Hybrid Search）＋語意重排（Reranking）：詞法與向量搜尋先撈出候選，再用重排模型依使用者真正的意圖重新排序。本文示範這套架構如何在 WordPress 上落地。
本文用浪花科技實戰的角度，從原理、WordPress 實作流程、PHP 攔截範例，到成本與延遲的取捨，一次說清楚這套架構該怎麼落地。
為什麼傳統的 WordPress 搜尋在 2026 年已經是「票房毒藥」？
在談 LLM 之前，先拆解一下傳統 WordPress 搜尋的死穴。預設的 WordPress 搜尋邏輯非常單純，它依賴 MySQL 的 LIKE 語法在 wp_posts 上做字串比對。這會產生兩個致命問題：
- 同義詞盲區：使用者搜尋「MacBook Type-C 轉接頭」，但你的商品標題寫的是「蘋果筆電 Type C 擴充 Hub」，因為關鍵字沒有完全命中，使用者就會得到「查無此商品」。
- 無法理解語意與意圖：當使用者輸入「抗藍光 護眼 螢幕」，他想要的是一台顯示器，但傳統搜尋可能會把標題帶有「螢幕保護貼」的配件排在最前面，因為它命中了更多字眼。
更根本的問題在於：LIKE 比對只看「字串有沒有出現」，完全不理解詞與詞之間的關係。它不知道「筆電」等於「筆記型電腦」，也不知道「安靜」對鍵盤而言指的是軸體。在 2026 年，習慣了和對話式 AI 聊天的使用者，早就習慣用「自然語言」下指令。如果你還逼著他們去「猜」你的商品關鍵字，他們會毫不猶豫地關掉網頁，轉向你的競爭對手。
什麼是混合搜尋與語意重排？兩個核心引擎拆解
要解決上述痛點，我們必須把搜尋架構從「關鍵字比對（Lexical Search）」升級為「混合搜尋（Hybrid Search）＋ 語意重排（Semantic Reranking）」。這裡面有兩個核心引擎在運作。
1. 意圖識別（Intent Recognition）
這一步的目標是「聽懂人話」。當使用者輸入一段冗長的句子時，我們透過輕量級的 LLM（例如本地端部署的小型模型 SLM，或 API）將這段文字轉換為向量（Embeddings）或提取出核心意圖。模型會理解「適合打遊戲的安靜鍵盤」背後代表的是「機械鍵盤、紅軸／靜音軸、電競」等屬性，而不是真的去資料庫裡找「打遊戲」這三個字。
這裡的關鍵概念是向量（Embeddings）：嵌入模型會把一段文字壓縮成一串數字座標，語意相近的內容在向量空間中的距離也相近。於是「安靜的鍵盤」和「靜音軸機械鍵盤」即使一個字都沒重疊，向量距離卻很接近——這正是字面比對永遠做不到的事。
2. 結果重排（Result Reranking）
這是整套架構最核心的一環。我們先用傳統搜尋或基礎的向量搜尋（Vector Search）快速抓出 Top 50 的潛在結果，接著把這 50 筆資料交給專門的重排模型（Cross-Encoder Reranker）。模型會根據使用者的「原始搜尋意圖」與「這 50 篇文章／商品的內容」進行深度交叉比對，並重新打分數，把最符合語境的結果推到前幾名。
這裡值得補充一個很多人忽略的原理差異：
- Bi-Encoder（用於第一階段檢索）：查詢和文件「各自」獨立轉成向量，事先就能把所有文件的向量算好存進資料庫，查詢時只比對距離，所以非常快、可規模化，但精準度有上限。
- Cross-Encoder（用於第二階段重排）：把「查詢」和「單一文件」成對一起餵進模型，做深度交叉注意力比對，精準度高很多，但慢、無法事先預算。
正因為 Cross-Encoder 慢，我們才不會拿它去掃全站，而是只用它精修第一階段撈出來的那 50 筆。這種「先廣撈、再精排」的兩段式設計，正是兼顧速度與品質的關鍵。
為什麼要「混合」，而不是純向量？
純向量搜尋擅長理解語意，卻有個弱點：碰到精準的字串（例如產品型號、料號、專有名詞）反而容易失準，因為這些字串的「語意」很薄弱。傳統詞法搜尋（如 BM25）則剛好相反——對精確字串又快又準。混合搜尋的價值，就是讓兩者互補：詞法負責「字面精準命中」，向量負責「語意模糊匹配」，再把兩條管線的候選合併後送進重排。這樣不管使用者打的是「iPhone 17 Pro 256GB」還是「拍夜景很強又不重的手機」，系統都接得住。
如何在 WordPress 實作 Hybrid Search ＋ Reranking 工作流？
聽起來很玄，但實作起來其實很有邏輯。在經典編輯器時代，我們通常會透過 Hook 攔截 WordPress 的搜尋請求。以下是浪花科技常用的輕量級架構流程：
- 攔截
pre_get_posts：當判斷是主搜尋時，暫停原生的 MySQL 查詢。 - 第一階段檢索（Retrieval）：透過 API 呼叫向量資料庫（如 Pinecone 或 Qdrant），或是結合 ElasticSearch，快速拉出前 50 筆相關文章 ID。
- 第二階段重排（Reranking）：將這 50 筆資料的摘要與使用者的 query 送入 Cohere Rerank API 或自建的重排模型，取得重新排序後的 ID 陣列。
- 回傳結果給 WordPress：使用
post__in參數與orderby => post__in強制 WordPress 依照 LLM 給的順序輸出。
前置作業：你得先把內容「向量化」
上述流程能跑起來，前提是你的文章或商品內容已經被嵌入模型轉成向量並存進向量資料庫。實務上這通常是一個獨立的「索引」工作：在文章發布或更新時（例如掛在 save_post 上），把標題與內容送去產生 Embeddings，再寫入 Pinecone 或 Qdrant，並記下對應的 WordPress 文章 ID。第一階段檢索能不能撈到對的東西，幾乎全看這份索引夠不夠完整、夠不夠新。
核心：攔截搜尋查詢的 PHP 範例
下面是一段示意用的 PHP 程式碼，支援經典編輯器直接寫入外掛或 functions.php（溫馨提醒：正式上線前記得做好快取與錯誤處理喔！）：
<?php
// 攔截 WordPress 主搜尋
add_action('pre_get_posts', 'roamer_llm_rerank_search');
function roamer_llm_rerank_search($query) {
if ($query->is_search() && $query->is_main_query() && !is_admin()) {
$search_term = $query->query_vars['s'];
// 1. 這裡假設你已經封裝好了一個取得第一階段 Top 50 ID 的函數
$initial_results = get_vector_search_top_50($search_term);
if(!empty($initial_results)) {
// 2. 呼叫 LLM 進行意圖識別與結果重排 (Reranking)
$reranked_ids = call_llm_reranker_api($search_term, $initial_results);
if(!empty($reranked_ids)) {
// 3. 覆寫 WP_Query 的查詢條件
$query->set('s', ''); // 清除傳統關鍵字，避免 MySQL 再次過濾
$query->set('post__in', $reranked_ids);
$query->set('orderby', 'post__in'); // 嚴格遵守 LLM 排序
}
}
}
}
?>實作時最容易踩到的三個細節
- 清掉
s參數再塞post__in：如果不把原始關鍵字清空，WordPress 仍會用 MySQL 再過濾一次，可能把你辛苦排好的結果又砍掉。範例中$query->set('s', '')就是在做這件事。 orderby一定要設成post__in：否則 WordPress 會用預設排序（多半是發布日期）把重排結果打亂，前面的功夫全白費。- 外部 API 失敗要能「優雅降級」：向量資料庫或重排 API 一旦逾時或回傳空值，程式碼裡的
if(!empty(...))守門就會讓查詢退回 WordPress 原生搜尋，而不是讓整個搜尋頁開天窗。這是上線前務必補齊的錯誤處理。
工程師的踩坑筆記：效能與成本的黃金平衡
引入 LLM 做重排的確很香，轉化率通常會肉眼可見地提升，但這背後隱藏著「成本」與「延遲」的魔鬼。每一次的 Rerank API 呼叫都是運算資源，如果你的網站流量很大，API 帳單會讓你老闆拿著報表來敲你的門。
在實戰中，我們必須加入智慧快取層（Smart Caching Layer）。對於熱門的搜尋詞彙（例如電商的「防曬乳」），我們應該把重排後的結果 ID 存入 Redis 中，並設定合理的 TTL（存活時間）。只有遇到長尾的、口語化的罕見搜尋（例如「去海邊玩不會黏膩的防曬」）時，才即時觸發 LLM 重排引擎。這樣不僅能把搜尋延遲從 1.5 秒壓回 200 毫秒內，還能省下高達 80% 的 API 成本。
快取設計的小提醒
快取要發揮效果，命中率是關鍵。把使用者輸入做基本正規化（例如去除前後空白、統一大小寫）再當成快取鍵，可以讓「防曬乳 」和「防曬乳」共用同一筆快取。另一個常被忽略的點是：內容更新時要讓相關快取失效，否則使用者可能搜到一筆已經下架或改名的舊結果。在重排成本與內容新鮮度之間，TTL 要怎麼抓，往往得依你的內容更新頻率來調。
結語：迎向懂人心智的搜尋新紀元
WordPress 作為全球市佔率最高的 CMS，其底層架構雖然古老，但只要懂得靈活運用 API 與現代化的 AI 工作流，依然能爆發出強大的生命力。從字面比對到語意理解，從「廣撈」到「精排」，這不僅是技術的升級，更是對「使用者體驗」的極致追求。
如果你希望由專業團隊為你的企業網站量身打造這套 LLM 搜尋重排系統，徹底終結高跳出率，歡迎透過下方連結與我們聯繫，浪花科技的資深工程師團隊隨時準備為您的業務注入最新的 AI 動力：
延伸閱讀
常見問題
為什麼 WordPress 預設的站內搜尋常常查不到東西？
什麼是混合搜尋（Hybrid Search），為什麼不直接用純向量搜尋？
Bi-Encoder 與 Cross-Encoder 在搜尋架構中扮演什麼角色？
在 WordPress 實作 LLM 重排搜尋的流程是什麼？
導入 LLM 重排後，如何控制 API 成本與搜尋延遲？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。