2026/5/16 建立『你可能會有興趣的文章』的AI自動化檢索

在別的網站上看到，一直很想要做一個類似的功能，因為WORDPRESS內建的相關功能出來的結果都不精確，還是得透過向量化搜尋的方式，才有辦法產生出更精確的模組。

這個功能比較難處理，但丟給AI處理並且分析架構完畢之後，整體架構已經相對簡單，架構上就是丟主要核心內容，讓AI產生向量化的資料，但因為MYSQL沒辦法進行這樣的搜尋，所以直接在雲端處理，後續搜尋的時候則是丟給AI，讓他找到語意上最接近的文章。主要是透過以下兩個模型產生。

AI 向量模型：Google Gemini API (gemini-embedding-2 或 text-embedding-004)，輸出 768 維度的浮點數向量。

向量資料庫：Google Cloud Firestore (支援原生 Vector Search / KNN 查詢)。

• 好險寫了這一篇文章，發現有一個很大的漏洞，就是如果加入到網站搜尋結果，因為不可控制的變因太大，費用會被爬蟲給灌爆炸。目前放在文章尾巴，成本執行我再來繼續觀察。
• 目前只能放在文章尾巴的關聯顯示，因為可控變數只有三千上下，加上快取機制，成本才可以有效控制，到搜尋結果的話可以會有破萬，因為目前爬蟲都會亂丟資料，為了要控制成本，還是得縮小一下功能。

基於 WordPress x Gemini x Firestore 的 AI 關聯文章與向量搜尋架構指南
這套系統旨在為 WordPress 網站提供高精準度的 AI 關聯文章推薦與語意搜尋功能。透過 Google Gemini API 提取文章特徵向量，並使用 Google Cloud Firestore 作為向量資料庫（Vector Database）進行 KNN（K-Nearest Neighbors）相似度比對。

以下提供系統的核心架構與開發實作指南，供有意開發類似系統的開發者參考。

1. 核心技術棧 (Tech Stack)
後端框架：WordPress (PHP 8.x)
AI 向量模型：Google Gemini API (gemini-embedding-2 或 text-embedding-004)，輸出 768 維度的浮點數向量。
向量資料庫：Google Cloud Firestore (支援原生 Vector Search / KNN 查詢)。
快取機制：WordPress Transients API + 伺服器級快取 (如 LiteSpeed Cache)。

2. 系統運作流程 (Workflow)
A. 向量化與同步機制 (Vectorization & Sync)
文章發佈/更新觸發：掛載 WordPress 的 save_post Hook。為了不卡住編輯器儲存速度，應將實際處理邏輯排程到 WP-Cron 非同步執行。
特徵萃取：將文章的「標題、分類、標籤、摘要、內文前 N 個字」組合成一段有意義的 Prompt（例如：task: clustering | query: 標題: [Title]。分類標籤: [Tags]。...）。
呼叫 Gemini API：將組裝好的文字送交 Gemini API，取得 768 維的 Embedding Vector。
雙重儲存：
儲存一份在 WordPress wp_postmeta (作為本地備份與 K-Means 數據分析用)。
同步 Upsert 到 Google Cloud Firestore，存入設定好的 Collection 中。
B. 前台關聯文章推薦 (Related Posts)
前端 AJAX 延遲載入：為避免影響網頁初次渲染速度（LCP），前台顯示骨架屏（Skeleton），並發送 AJAX 請求。
Firestore 相似度比對：後端取得當前文章的本地向量後，向 Firestore 發送 KNN 查詢，尋找距離最近（Cosine Similarity）的 4~5 篇文章 ID。
結果快取：將查詢到的關聯文章 ID 快取在 Transient 中（例如設定 7 天），避免重複消耗 Firestore 讀取額度。
C. 前台 AI 語意搜尋 (Semantic Search)
攔截原生搜尋：掛載 WordPress 的 the_posts Filter，攔截原生的 /?s=keyword 查詢。
搜尋詞向量化：將使用者的搜尋詞即時打給 Gemini API 轉換成向量。
混合搜尋結果：用該向量向 Firestore 查詢最相關的文章，並將 AI 推薦結果安插在原生搜尋結果的最前面。
3. 關鍵架構防護與避坑指南 (Critical Best Practices)
若未做好成本與效能控管，這類系統極易因為爬蟲 (Bot) 導致 API 費用暴增或資料庫超出配額。

⚠️ API 費用與惡意消耗防護 (Cost Control)
搜尋字串長度限制：前台 AI 搜尋必須限制字元長度（例如 mb_substr($query, 0, 50)）。若無限制，惡意 Bot 送出 10,000 字的隨機搜尋詞將會瞬間吃光您的 Token 額度。

全域 Token 記錄：不要只將 Token 消耗紀錄在單篇文章上。必須在 API 請求的底層 (Wrapper) 攔截每次請求的 usageMetadata，並累加到全域（如 wp_options），確保前台搜尋、背景排程的花費都能精準監控。

頻率限制 (Rate Limiting)：針對 AI 搜尋端點實作 IP 頻率限制，防止被當作免費的 Embedding API 節點濫用。

手動降級開關：保留一個能在後台一鍵關閉「前台 AI 搜尋」的總開關，當面臨攻擊或預算超支時，可以退回只保留文章內推薦，藉此快速止血。

⚡ 效能與快取優化 (Performance)
非同步化 (Async Processing)：任何呼叫外部 API 的動作，絕對不能放在同步的 Request 生命週期中（尤其是 save_post）。
動態快取穿透：如果您的網站有使用 LiteSpeed 或 Cloudflare，AI 關聯文章的 AJAX 端點必須明確回傳 No-Cache Header，否則快取伺服器可能會快取到錯誤的文章推薦。
清除陳舊快取：當文章內容更新且重新同步向量後，記得利用 Hook 主動清除該文章對應的 Transient 快取。