企業搜尋平台採購完整指南：Algolia / Elasticsearch / Typesense / Meilisearch / 自架 5 條路徑——中小企業老闆 6 個決策、5 條合約紅線、3 個報價區間

2026 年中小企業老闆——尤其是電商、SaaS 平台、內容站——基本繞不開一個問題：搜尋框打字三秒沒結果，使用者直接離開。資料庫 LIKE 撐不過 10 萬筆、Postgres 全文搜尋的中文斷詞爛、要不要花錢上 Algolia 變成這年該回答的題。我們最近在客戶評估會議上連續被問三次「站內搜尋到底要怎麼選」，乾脆把整套採購邏輯拆開來寫。

這篇不打算停在工具介紹——核心是 B2B 採購視角的完整框架。會走完 5 條主流路徑（Algolia / Elasticsearch / OpenSearch / Typesense / Meilisearch / 自架 Postgres FTS）的 TCO、6 個老闆會卡住的決策、5 條合約紅線、3 個報價區間。寫完後你可以直接拿去開廠商評估會議，不會再被工程主管的「之後再說」拖一季。順帶提一下，這套思路跟我們之前寫的資料倉儲選型框架、Headless CMS 採購指南 是同一條 SaaS 老闆採購系列的延伸，可以一起看。

為什麼 2026 中小企業電商與 SaaS 老闆繞不開站內搜尋採購

先看一個數字。Algolia 2024 Site Search Report 統計：使用站內搜尋的訪客成交率比沒搜尋的高 1.8–4.6 倍，且 43% 的電商使用者第一個動作就是找搜尋框。也就是說，搜尋框的體驗直接決定你 40% 以上流量的轉換命運——但多數中小企業官網的搜尋還停在 SQL LIKE 拼接，超過 5 萬筆商品 / 文章後查詢回應時間就破 800ms，使用者根本不會等。

第二個壓力來自 AI 搜尋。Gartner 2025 Hype Cycle for Search 把「Generative Search / RAG」放在期望膨脹高峰——老闆會被 ChatGPT、Perplexity 教育成「我網站怎麼還在用關鍵字比對」，採購壓力會從工程部往上倒。同時 Baymard Institute 2024 搜尋研究 持續指出大型電商站內搜尋有 70% 表現比 Google Image Search 還差，使用者期待值被 Google 拉高、自架實作跟不上。

第三件事，是中文。Postgres 內建的 tsvector 對中文斷詞基本沒用——它會把「資料庫管理系統」當成一個 token，搜「資料」搜不到。要解決得自己接 jieba 或 zhparser 擴充，再加 trigram 索引處理錯字容忍。三個小時可以裝起來，但維護下去發現「為什麼搜『冰箱』找不到『電冰箱』」這種長尾問題會吃掉工程部三個月。中文 + 容錯 + 同義詞 + 自動補全這四件事疊起來，自架成本就跟商業 SaaS 打平了。

五條路徑全景：Algolia / Elasticsearch / Typesense / Meilisearch / 自架 Postgres FTS

市場上能用的方案大致分五條路徑。先把它們的定位、技術棧、適合的 doc 規模、上手難度、月成本級距一次攤開——這張表是後面所有決策的基礎，建議拍下來開會用。

這張表只看技術面，老闆視角還缺三件事：合約鎖定、AI 排序能力、出場彈性——這三件後面分區段拆。先把每條路徑的「人設」記下來：

• Algolia：站內搜尋的 Stripe。API 漂亮、文件世界級、上線最快。代價是按查詢量計費，月查詢破 100 萬次帳單就會嚇人。
• Elasticsearch / OpenSearch：搜尋界的 Linux。功能最深、最自由，但沒有 SRE 不要碰——叢集 split brain、shard rebalance、JVM heap 調校這些坑等著你。
• Typesense：被嚴重低估的中段選項。比 Algolia 便宜 10 倍、比 Elastic 簡單 100 倍、繁中分詞內建就能用。
• Meilisearch：法國團隊出品，相容 Algolia API、100% 開源、< 50 萬 doc 規模絕配。
• 自架 Postgres FTS：< 5 萬 doc 的最佳解。已經有 Postgres 就免費，只是要花心思接中文斷詞。

老闆會卡住的 6 個決策

採購會議跑過 20 場以上，老闆真正會卡關的點永遠是這六個。工程部給的技術比較表多半在 talking past the boss——以下這張表是給老闆視角寫的，直接拿去當決策框架。

決策 1：Doc 規模成長曲線

「我們現在才 3 萬筆，用什麼都行」——這句話是陷阱。搜尋系統的真正成本不在裝起來，在於三年後資料量翻 5 倍時要不要重做。Postgres FTS 在 5 萬筆內表現很穩，破 10 萬筆會開始看到查詢時間從 100ms 跳到 500ms+，要做 partitioning、調 work_mem、加 GIN 索引。等你發現「該換了」通常已經晚了——使用者跳出率早就拉高，再換系統得從零調 ranking 與同義詞表。

決策 2：查詢量規模

Algolia 收費是 doc 數 × 查詢次數的階梯式定價。免費方案 1 萬筆 doc、1 萬次查詢/月——電商基本一上線就破。Build 方案 $0.50 / 1k 次查詢——月 10 萬次查詢 = $50，月 100 萬次 = $500，月 500 萬次 = $2,500。聽起來不貴，但加上 Premium SLA、地理多區、客製排序模型，中型電商月帳單 $3,000–$8,000 是常態。

決策 3：中文斷詞品質

這是台灣老闆最容易踩的坑。所有 SaaS demo 都用英文，老闆看不出差別。真上線後用戶搜「無印良品」搜不到「MUJI」、搜「iPhone 15 Pro Max」搜不到「i15PM」這種同義詞與品牌簡寫問題會炸。Typesense 與 Meilisearch 的 CJK 內建 tokenizer 算堪用，但同義詞表還是要自己維護。Algolia 在中文上多了一層 ML 自動補全與打字錯誤容忍，是少數能買到「免維護」的選項。

決策 4：AI 排序與向量搜尋

2026 年的搜尋系統採購不討論向量搜尋是失職。RAG 應用（內部知識庫 chatbot、產品推薦、語意客服）幾乎都需要 hybrid search——關鍵字搜尋 + 向量相似度同時用。Algolia 有 NeuralSearch（額外加價）、Elasticsearch 8.x 後內建 vector 欄位、Typesense 0.25+ 也支援。如果你已經在用 Postgres，pgvector 是最便宜的入門路徑，這部分跟我們之前談 AI PoC 30 天執行框架 是同一條鏈——搜尋是 RAG 的地基。

決策 5：資料合規邊界

如果你索引的內容包含客戶 PII（姓名、電話、訂單記錄），SaaS 路徑會卡在「資料出境」問題。Algolia 主機在美 / 歐，Typesense Cloud 有 GCP / AWS 區域選擇，Meilisearch Cloud 主機在歐盟。台灣個資法雖然沒明文禁止跨境，但金融、醫療、政府標案幾乎強制要求資料留在境內——這種就只能走自架 Elasticsearch 或 OpenSearch。

決策 6：IT 配置實況

最現實的問題。沒有 SRE 就不要碰 Elasticsearch 自架——叢集出事的凌晨三點誰修？這條鐵律 90% 的老闆會違反，原因是工程主管覺得「我們能搞定」。實情是：Elasticsearch 自架前 6 個月會吃掉 0.5–1 個 SRE 的時間，後續每月也要 5–10% 工時做 capacity planning、版本升級、安全 patch。算成本時要把這個算進去，否則 TCO 估錯一個量級。

合約必看的五條紅線

SaaS 採購最痛的部分從來不在首年費用——真正壓力是第二年談續約時的籌碼差距。下面這五條紅線是我們在實際採購會議跟客戶一起踩過的——拿去當合約 review checklist 用，能省掉 50% 的後悔。

第三條 SLA 特別容易被忽略。Algolia 的 free tier 沒 SLA、Build tier 99.9%（年停機 8.76 小時），只有 Premium tier 才是 99.99%（年停機 52 分鐘）。中小企業電商在 Build tier 跑了三年沒事不代表沒風險——一次黑五大促掛 3 小時，三年省下的訂閱費全還回去。

第四條資料所有權更隱蔽。Elasticsearch 自架你的 mapping 與 ranking 配置都在自己手上，搬家不過是換主機；Algolia 與 Typesense Cloud 的 ranking 模型是平台專有，匯出時只有 raw doc 帶不走 ranking 邏輯。簽約前要求廠商書面承諾「ranking 配置可匯出」，這是離婚協議書。這個邏輯跟我們之前在 合約 AI 審閱採購指南 提到的 SaaS 出場條款是同一套思路。

三個報價區間的實算

用三個真實規模的中小企業案例試算 TCO（含人力時間成本），讓你直接對標自家狀況。所有數字都是 2026 上半年定價，已含人力時間估算（工程師時薪以台灣中位 $800 / 小時計）。

情境 A：小型電商（< 5 萬商品、月查詢 < 50 萬次）

結論：這個規模 Meilisearch / 自架 Postgres FTS 是最划算的。Algolia 在這個尺寸過殺。

情境 B：中型 SaaS（30 萬 doc、月查詢 200 萬次、要中英搜尋）

結論：中型 SaaS 選 Typesense Cloud Pro 最划算，CP 值贏 Algolia 一倍以上。

情境 C：大型內容站（500 萬 doc、月查詢 1,000 萬次、要 RAG）

結論：到這個規模沒有「便宜」選項，差別只在你想把錢花在訂閱還是人力。Elastic Cloud + 內部 SRE 配置通常最划算。

30 / 60 / 90 天的落地節奏

採購決策做完，導入節奏一樣會卡。下面是我們建議的 90 天 roadmap——比多數廠商給的 demo timeline 慢一倍，但能避免上線後三個月內全部重做的命運。

第 0–30 天：PoC 與 baseline

• 選定 2 條候選路徑（不要超過 2 條，否則 PoC 永遠跑不完）
• 匯入 10% 真實資料、跑 baseline 查詢延遲與召回率
• 拉 10–20 個內部使用者做盲測：搜尋 30 個真實 query、紀錄滿意度
• 把 PoC 結論做成 1 頁 memo 給老闆，不是 30 頁簡報

第 30–60 天：合約與整合

• 簽約前過合約 5 條紅線 checklist
• 完成資料 ETL 管線（CDC + 增量同步、不要再用每晚全量重建）
• 做完中文同義詞表初版（80 個高頻 query 對應）
• 上 staging 環境，前端整合 InstantSearch / 自製 UI

第 60–90 天：灰度上線與調優

• 10% 流量灰度上線、跑 A/B 測試對照舊系統
• 監控四個 KPI：搜尋成交率、零結果率、平均查詢延遲、使用者重新搜尋率
• 根據 search analytics 補 30–50 個同義詞 / 排除詞
• 100% 流量切換、舊系統保留 30 天熱備

我們自己怎麼用：恆遠官網與客戶系統的搜尋實況

這篇講了五條路徑，那我們自己用哪一條？老實說我們是「分層使用者」——不同產品線用不同搜尋方案，因為需求差太多。

恆遠官網的部落格搜尋目前用的是 Postgres 全文搜尋 + 自寫的中文 tokenizer 處理。理由很簡單：站內文章 500+ 篇、月查詢量低於 5,000 次，這規模上 Algolia 是殺雞用牛刀，每月白付 $300+。Postgres 在這個 doc 規模查詢延遲 < 50ms，完全沒理由換。我們做客戶 Headless CMS 採購 時也常給同樣建議：< 5,000 篇內容站，Postgres FTS 是最佳解。

但我們在客戶 系統開發專案 中導入過 Typesense 與 Meilisearch 兩條路徑。一個是工程材料 B2B 平台，商品約 8 萬筆、要支援部品編號模糊搜尋與中文同義詞，跑 Typesense Cloud；另一個是補習班學員後台，文件 + 影片約 3 萬筆，跑 Meilisearch 自架。兩個案子都沒用 Algolia，原因是中型客戶在意「離開廠商的能力」勝過「最頂的搜尋品質」——開源 + 可遷移性是真實的採購標準。

RAG 整合那塊我們目前的標準棧是 pgvector + Postgres FTS 做 hybrid search，這套用在我們內部知識庫已經跑了一年。為什麼不上 Elasticsearch？因為 90% 的中小企業 RAG 真實 query 量低於 10 萬次/月，Postgres + pgvector 就吃得下，多開一套 Elastic 是工程債的開始。這個原則我們在做 客戶啟用 Onboarding 時的內建搜尋也是同樣思路。

恆遠怎麼幫客戶把搜尋平台導入到系統裡

我們處理客戶站內搜尋升級的 SOP 是這樣：

• 第一步：從 search log 抓三個月的 query 樣本，跑 zero-result 分析。多數客戶會發現 20% 的 query 帶來 80% 的零結果——這份名單比廠商 demo 重要 10 倍。
• 第二步：建議 1–2 條最匹配的路徑（看 6 個決策框架），不會默認推 Algolia。
• 第三步：一週 PoC：實際匯入 10% 真實資料、跑 30 個高頻 query 盲測，給老闆一頁 memo。
• 第四步：如果走客製化整合（hybrid search、自製 ranking、RAG 整合），會走 4–8 週開發 sprint。
• 第五步：上線後 30 天觀察期，每週調整同義詞與 ranking weight，把零結果率壓到 < 3%。

我們怎麼看

企業搜尋平台採購常見問題