Meilisearch 不只是搜尋框：用 Hybrid Search 把 RAG 的檢索層做成可維護服務

Meilisearch 不只是搜尋框：用 Hybrid Search 把 RAG 的檢索層做成可維護服務

我最近在挑選適合 AI 應用的開源基礎工具時，常遇到一個很實際的問題：團隊想做知識庫問答、文件搜尋或自然語言查詢，第一個念頭通常是「先接一個向量資料庫，再把 LLM 串上去」。但真正開始做之後，問題很快從模型選擇轉成資料索引、關鍵字命中、過濾、排序、權限與延遲。

這也是我認為 Meilisearch 值得重新看的原因。它不是只提供向量搜尋的 AI 元件，而是一個以 API 為核心的搜尋引擎：原本就有全文搜尋、容錯、篩選、排序、同義詞與地理搜尋，現在再把 semantic search、hybrid search、conversational search 與 MCP 整合放進同一個產品脈絡裡。對 AI Chain 這類需要把模型接進既有產品的團隊來說，這個定位比「又一個向量資料庫」更有意思。

我的結論先講在前面：如果你的產品需要同時處理精確詞彙與自然語言意圖，Meilisearch 很適合先扮演檢索層；如果你只是要儲存 embedding，或需要極度專門化的向量索引與分散式控制，則不應該因為它有 AI 功能就直接替換現有架構。

真正的問題不是「要不要用向量」，而是兩種相關性怎麼共存

純全文搜尋擅長處理產品名稱、錯誤碼、訂單編號、專有名詞與使用者明確輸入的關鍵字。假設使用者搜尋「RAG chunk overlap」，搜尋引擎應該要能找到包含這串術語的文件，而不是只因為語意相近就把它改寫成另一個概念。

純 semantic search 則擅長處理「怎麼降低文件問答的幻覺」這種不一定包含原文關鍵詞的問題。它比較在意句子的意思，而不是字面是否完全相同。但若搜尋內容包含 SKU、版本號、API 參數或人名，單靠語意相似度又可能把看起來相近、實際上不能互換的結果排在前面。

Hybrid search 的價值，就在於把這兩種訊號放進同一次搜尋。Meilisearch 官方文件把它描述成全文關鍵字搜尋與語意搜尋的組合：查詢送進去後，兩條路徑可以並行處理，再透過評分機制合併結果。這不是把兩份結果粗暴串接，而是讓系統依查詢內容判斷精確匹配與語意匹配各自應該占多少比重。

文件目前以 semanticRatio 表示語意結果的比例，預設值是 0.5，但它不是一個必須盲調的神奇旋鈕。真正重要的是先建立一組代表性的查詢集，包含錯字、縮寫、精確術語、自然語言問題與帶條件的查詢，然後觀察兩種結果在真實任務上的差異。搜尋品質應該用資料與使用者任務驗證，而不是只看 demo 裡一個漂亮的回答。

Meilisearch 把 embedding pipeline 收進索引流程，降低整合複雜度

很多 RAG 專案早期會自己處理這條管線：讀取文件、切 chunk、呼叫 embedding provider、儲存向量、處理重試、文件更新時重新計算，最後再把向量查詢結果交給應用程式。每一個步驟都不難，但加在一起就會出現大量需要維護的邊界條件。

Meilisearch 的做法是讓使用者在 index 上設定 embedder。設定完成後，系統可以為文件產生 embedding、保存結果，並在文件內容變更時重新處理；官方文件也提到，它會以批次方式送出 embedding 請求，遇到 provider rate limit 時自動重試。這種設計讓應用程式可以把注意力放在「哪些欄位該被搜尋」與「搜尋結果如何服務產品」，而不是維護另一條平行的向量同步服務。

但這裡有一個不能忽略的成本：改變 embedder 的模型、provider 或 document template，可能觸發整個 index 的重新 embedding。資料量一大，這不只代表等待時間，也可能代表外部 embedding API 的費用。因此我會把 embedder 設定視為資料 schema 的一部分，和 index mapping、欄位權限一樣納入版本控管，不會把它當成可以隨時在 production 手動切換的普通參數。

另一個實務判斷是：不是所有欄位都適合送進 embedding。文件標題、正文、產品分類與版本資訊可能需要不同處理；像 ID、價格、狀態或租戶欄位，通常更適合交給 filter 與排序，而不是期待 embedding 理解它們的精確語意。Hybrid search 的完整價值，正是讓這些不同類型的訊號分工，而不是把所有資料都壓成一個向量。

從零開始：先用 Docker 建一個可驗證的搜尋服務

我建議第一次試用不要先從複雜的 agent 或聊天 UI 開始，而是先完成三個可驗證任務：啟動服務、寫入文件、用 API 搜尋。這樣才能分辨問題是在 Meilisearch、資料格式、權限，還是上層 LLM。

官方自託管安裝文件提供 cURL、Docker、Homebrew、APT 與 source build 等方式。以下用 Docker 示範；版本標籤應以官方文件與 release page 為準，範例採用文件目前展示的 v1.37：

docker pull getmeili/meilisearch:v1.37

docker run --name meilisearch --rm \\
  -p 7700:7700 \\
  -e MEILI_MASTER_KEY='replace-with-a-long-random-key' \\
  getmeili/meilisearch:v1.37

這個 master key 只是示範值，實際環境不要把密鑰直接寫進 shell history、公開的 compose 檔或文章範例後照抄。啟動後，先準備一個 movies.json：

[
  {
    "id": 1,
    "title": "The Matrix",
    "overview": "A computer hacker discovers that reality is not what it seems.",
    "genres": ["Action", "Science Fiction"],
    "year": 1999
  },
  {
    "id": 2,
    "title": "Arrival",
    "overview": "A linguist works to communicate with visitors from another world.",
    "genres": ["Drama", "Science Fiction"],
    "year": 2016
  }
]

接著建立 movies index 並加入文件：

curl \\
  -X POST 'http://localhost:7700/indexes/movies/documents' \\
  -H 'Content-Type: application/json' \\
  -H 'Authorization: Bearer replace-with-a-long-random-key' \\
  --data-binary @movies.json

Meilisearch 的寫入與索引處理是非同步任務。API 回應中的 task 資訊應該保存下來，並用官方 Tasks API 或 SDK 確認任務完成，再把搜尋結果拿來做測試。不要因為 HTTP request 回傳成功，就假設文件已經能被查到；這是初次整合很常見的誤判。

curl \\
  'http://localhost:7700/indexes/movies/search?q=computer+hacker' \\
  -H 'Authorization: Bearer replace-with-a-long-random-key'

完成這一步後，再接入你的應用程式 SDK。Meilisearch 官方文件提供多種語言與框架的整合入口；我會先用最小 API client 驗證索引契約，再把它包進服務層，避免前端直接依賴搜尋引擎的細節。

把一般搜尋升級成 Hybrid Search 時，應該先做哪些設計

第一步是定義搜尋任務，而不是先選模型。至少準備以下五類查詢：

1. 精確術語：錯誤碼、產品型號、API 名稱、版本號。
2. 自然語言描述：使用者不知道正確關鍵字，只能描述想完成的事情。
3. 混合查詢：同時包含專有名詞與意圖，例如「如何修正 v2 API 的 timeout」。
4. 帶條件查詢：需要搭配日期、分類、價格、權限或租戶範圍。
5. 負面案例：看起來語意相近，但業務上不能算正確的文件。

第二步是整理可檢索欄位與 metadata。正文可以進 embedding，但 tenant_id、visibility、language、version 與狀態等欄位，應明確設計成 filter 或權限層條件。搜尋引擎能找到某份文件，不代表目前使用者有權看到它；RAG 最危險的錯誤之一，就是檢索層沒有把資料邊界一起帶進來。

第三步才是設定 embedder 與 hybrid options。先從官方支援的 provider 開始，記錄模型、版本、document template 與成本，再用固定查詢集比較不同 semanticRatio。如果每次改參數都只靠人工點幾次搜尋框，最後很難知道品質變好是因為索引變了、模型變了，還是剛好換了一組問題。

第四步是把評估指標拆開。搜尋結果可以看 recall、precision、排序位置與空結果率；如果再接 LLM，則另外評估回答是否引用正確文件、是否超出來源、是否在沒有答案時誠實拒答。不要把「LLM 回答看起來通順」當成檢索成功的證據。

Conversational Search 可以做什麼，又不能承諾什麼

Meilisearch 目前也提供 conversational search 的能力。官方文件把它定位成建立在搜尋引擎上的 AI 功能：使用者提出自然語言問題後，系統先從 index 取回相關文件，再讓 LLM 根據這些結果產生回答；文件也強調回答可以附上來源文件，讓使用者核對依據。

這個設計對產品團隊有吸引力，因為它把「查詢理解、hybrid retrieval、回答生成」串成較短的路徑。若你的目標是快速驗證一個內部知識庫或文件問答入口，這比自行拼出整套 orchestration 更快看見結果。

但我不會把它直接描述成「不會幻覺的 RAG」。官方文件明確提醒 conversational search 仍在早期開發階段，LLM 即使拿到正確的來源文件，仍可能產生不正確或誤導性的內容。正式環境至少要做三件事：顯示引用來源、設定 guardrails 限制回答範圍、以及針對空結果、LLM 失敗、rate limit 與不支援問題設計 fallback。

更重要的是，要把「檢索層」與「生成層」的責任分開。Meilisearch 可以負責查詢理解與 hybrid retrieval，但應用程式仍可以自行控制 prompt、模型、輸出格式、審計與安全策略。這讓它不必取代整個 RAG stack，而是可以先成為其中一個可靠、可觀測、可替換的模組。

我會把它放進哪些 AI Chain 場景

企業知識庫是最直接的場景。企業文件往往同時有精確詞彙、版本差異與自然語言描述，使用者希望像搜尋引擎一樣快，又希望能用問句找到答案。Meilisearch 可以處理 keyword、semantic、filter 與租戶邊界，LLM 再負責把結果整理成可讀回答。

客服與產品搜尋也適合。客服問題通常包含產品名、錯誤訊息與口語描述；電商搜尋則需要語意理解、faceting、價格排序與庫存條件。這些場景不只要「相似」，也要讓使用者能縮小範圍，因此全文、filter、sorting 與 semantic search 的組合比單一向量查詢更貼近產品需求。

AI agent 的工具層則要更謹慎。Meilisearch 官方 README 提到 MCP 與 LangChain 整合，代表它可以接入更大的工具生態。但 agent 能呼叫搜尋，不等於 agent 應該看到所有 index，也不等於搜尋結果可以直接變成對外動作。需要在 API key、tenant token、filter、輸入清理與輸出驗證上建立邊界。

哪些地方不適合直接採用

第一，如果需求是超大規模向量檢索、特殊硬體加速或高度客製化的 ANN 索引策略，應先和專門的向量資料庫或搜尋平台比較，不要只因為 Meilisearch 的開發體驗友善就忽略規模條件。

第二，如果資料更新頻率極高，或 embedder 變更會頻繁觸發大規模重建，必須先估算 re-index 時間、provider API 費用與服務可用性。官方文件對這類重新 embedding 成本有明確提醒，這不是上線後才處理的優化項目。

第三，若團隊需要完整的企業功能，要看 Community Edition 與 Enterprise Edition 的授權差異。專案 README 說明 Community Edition 以 MIT license 開源，Enterprise Edition 則包含部分進階能力並受商業授權或 Business Source License 1.1 約束；採用前應直接閱讀當前 LICENSE 與商業條款，不要用「這是開源專案」一句話概括全部功能。

第四，self-hosting 也不等於零治理。Meilisearch 官方文件說明會收集匿名 telemetry，並提供停用方式。對有合規要求的團隊，應在部署檢查表中確認 telemetry 設定、網路出口、API key 輪替、snapshot 備份與資料刪除流程，而不是等資安審查才臨時補文件。

我的導入順序：先把搜尋做對，再把回答做漂亮

我會把導入拆成四個階段。第一階段只部署全文搜尋，建立文件 schema、filter、排序與權限測試。第二階段加入 semantic search，固定 embedder 與評估資料集，觀察語意結果是否真的改善任務成功率。第三階段才開啟 hybrid search，對不同查詢類型調整 semanticRatio，並保留可以回退到純全文搜尋的路徑。第四階段才把結果交給 LLM，加入來源顯示、guardrails、fallback 與成本監控。

這個順序看起來比較慢，卻能避免把搜尋品質問題偽裝成 prompt 問題。如果使用者拿到錯的文件，LLM 再會寫也只是在更流暢地放大錯誤。相反地，一個能被測試、能被過濾、能被追蹤的檢索層，才是 RAG 應用長期維護的地基。

因此，我對 Meilisearch 的評價不是「它能不能取代所有向量資料庫」，而是它能不能在一個真實產品裡，把全文搜尋、語意檢索、metadata 條件與 API 整合放在同一個可操作的服務中。答案是：在中小型 AI 應用、企業文件搜尋、客服與產品搜尋等場景，它很值得先做一個小型 PoC；但 PoC 的驗收標準應該是相關性、權限與可維運性，而不是只截一張聊天回答的畫面。

如果你今天要開始，我建議先完成 Docker 啟動、文件寫入與 API 搜尋，再拿一小組真實查詢比較全文與 hybrid 結果。當你能回答「哪些查詢需要語意」、「哪些欄位必須 filter」、「重新 embedding 的成本是多少」這三個問題，Meilisearch 才真正從熱門 GitHub 專案變成可被負責任導入的 AI 基礎元件。

參考資料

• Meilisearch GitHub Repository
• Meilisearch 官方文件：Install Meilisearch locally
• Meilisearch 官方文件：Hybrid and semantic search
• Meilisearch 官方文件：Conversational search
• Meilisearch 官方文件：Telemetry