當前的混合搜尋方案：穩妥之選，但仍有局限

目前，我的導航站採用的是一種混合搜尋方案，主要由以下三部分組成：

1. 分詞 + 正規表示式： 這是最基礎的搜尋方式，透過對使用者輸入的關鍵詞進行分詞，然後利用正規表示式匹配網站標題、描述等欄位。這種方案優點是簡單快捷，成本低，對於簡單的關鍵詞搜尋效果還不錯。但缺點也很明顯，無法理解語義，容易出現誤判，比如搜尋「蘋果手機」，可能會匹配到包含「蘋果」的食譜。
2. MongoDB 文檔搜尋： MongoDB 本身就提供了強大的文字搜尋能力，我利用它對網站數據進行全文索引。相比簡單的分詞正規，它可以支援更複雜的搜尋，並提供一定的相關性排序。但它仍然基於關鍵詞匹配，無法真正理解使用者的意圖。
3. AI 語義匹配類別 (DeepSeek 模型)： 這是我為了解決語義理解問題引入的方案。我使用 DeepSeek 模型對網站進行類別劃分，然後將使用者搜尋的關鍵詞也進行語義分析，匹配到最相關的類別，最終返回該類別下的網站。這在一定程度上提升了搜尋的準確性，但仍然不夠精細，而且DeepSeek模型存在一定的成本。

這種混合方案在現階段算是比較穩妥的選擇，兼顧了成本和效果。但隨著網站內容的增長，以及使用者對搜尋體驗要求的提高，我意識到這種方案仍然存在不少局限性，比如：

• 語義理解不足： 關鍵詞匹配始終無法準確理解使用者的真實意圖，例如，使用者搜尋「有什麼好用的線上協作工具」，我們的搜尋很可能找不到最佳答案。
• 結果排序不夠智慧： 結果的排序往往基於簡單的相關性，而不是使用者可能真正需要的程度。
• 維護成本較高： 三種方案需要分別維護，隨著數據量增大，維護成本也會越來越高。

嘗試過的其他方案：成本與複雜度的權衡

在探索的過程中，我也考慮過其他一些方案，但都因為各種原因沒有採用：

• 資料庫語義搜尋： 這是理想中的方案，利用語義向量技術，將網站數據和使用者搜尋都轉化為向量，然後透過計算向量相似度來匹配。但這個方案的成本太高，需要大量的計算資源和儲存空間，特別是對於我這種小網站來說，難以承受。
  • 中間方案： 為了降低成本，我還考慮過一個中間方案，即在網站數據結構中增加一個語義向量欄位，在儲存數據時調用免費的語義模型得到網站描述的語義向量。搜尋時，再調用免費的語義模型得到搜尋的語義向量，最後選擇合適的計算方式匹配。這個方案雖然降低了一些成本，但仍然需要大量的開發工作，而且維護起來比較麻煩。
• 服務商提供的站內搜尋 API (Algolia): 這種方案非常省心，能夠提供專業的搜尋服務，但價格太貴了，免費額度只有 10000 次搜尋/月，對於我來說遠遠不夠用。

這些嘗試讓我更加清楚地認識到，選擇合適的搜尋方案需要綜合考慮成本、效果、複雜度和維護成本等多個因素，找到一個適合自己的平衡點。

未來的暢想：AI 知識庫 + 語義搜尋

雖然目前的方案基本滿足需求，但我心中一直有一個更理想的方案： 將所有網站數據做成一個 AI 知識庫，然後直接調用 AI 語義搜尋。

這個方案的優勢顯而易見：

• 更強大的語義理解能力： AI 模型可以理解使用者的真實意圖，返回更精準的結果。
• 更智慧的排序： 基於 AI 的排序演算法可以更好地根據使用者需求和網站品質來排序結果。
• 更靈活的搜尋方式： 使用者可以像和 AI 對話一樣搜尋，比如「我想找一個可以免費畫流程圖的線上工具」
• 更低的維護成本： 只需要維護一個 AI 模型和一個知識庫即可。

當然，這個方案也面臨一些挑戰，比如：

• AI 知識庫的建構： 如何高效地將網站數據轉化為 AI 可以理解的知識？
• AI 模型選擇： 選擇哪個模型更適合我的需求？
• AI 快取： 如何高效地快取搜尋結果，避免重複計算？

目前我對這些挑戰的理解還比較淺顯，很多東西都是我的知識盲區。但我堅信，隨著 AI 技術的不斷發展，建構基於 AI 知識庫的站內搜尋將成為未來的趨勢。

總結與展望

站內搜尋是一個不斷進化的過程，沒有一勞永逸的解決方案。我們需要根據自身的情況，不斷嘗試、調整和優化。

我希望透過這篇文章，能夠和大家分享我的探索之路，也希望能夠拋磚引玉，引發更多關於站內搜尋方案的討論。如果你也有關於站內搜尋的經驗或想法，歡迎在評論區留言，一起學習進步！

未來，我將繼續探索基於 AI 知識庫的站內搜尋方案，並期待能與大家分享更多實踐經驗。感謝大家的閱讀！