公司商店選搜尋技術，不是把三個產品的功能數量排成名次。真正要決定的是：誰維護索引、誰定義可見商品、繁體中文查詢如何驗收、錯誤匯入如何回復，以及搜尋結果怎麼銜接到訂購與履約。Algolia、Elasticsearch、Meilisearch 都能搜尋商品，但營運責任、設定自由度與風險邊界不同。Giftpack 只應在核准的商品選擇之後，作為收件人選擇與履約的一種可評估執行層；它不是搜尋引擎，也不應被放進同一排名表。
先寫清楚搜尋可以做什麼、不能做什麼
搜尋可以在已核准的候選商品中檢索與排序，不能自行判斷員工是否符合資格、受限商品能否出境、缺貨時可否換成另一品項，也不能因為沒有結果就解除地區或身分限制。這些決定分別屬於公司商店應用、方案負責人、法務或資安、庫存與履約系統。搜尋服務收到的應是已縮限資料，或是無法由前端任意移除的權限條件。
把責任寫成資料契約。商品主檔負責料號、版本、上架狀態、語系名稱、顏色與尺寸、適用地區、庫存訊號、預算級距與受眾標籤；索引只保存經版本化的衍生欄位、可搜尋文字與排序訊號；商店後端負責登入、身分與方案權益；履約層負責再次確認庫存、必要收件資料、出貨、拒收、退回與對帳。只要其中一個責任無人承擔，較快的查詢速度也無法補上治理缺口。
驗收集必須同時包含「應找到」與「絕對不能出現」。前者可包括品牌別稱、錯字、台灣常用類別詞、尺寸寫法、價格區間與精確料號；後者應包括已下架商品、僅主管可見的組合、未開放台灣配送的品項、來源資料尚未完成同步的新品，以及不屬於此方案的贈品。負向測試若失敗，就是權限或資料生命週期事件，不是靠調低排名就可以掩蓋的相關性問題。
決策前先問五件事：團隊是否能長期維運；真實商品欄位與語言是否可被正確建模；權限是否在可信任端強制執行；每次設定變更能否用固定查詢集重現；錯誤索引能否在不暴露受限商品的前提下回復。費用要連同人力、值班、升級、監控、測試與供應商依賴一起估算，不能只比月費起價。
用相同營運軸比較三個選項
Algolia 是託管式搜尋服務，官方文件涵蓋可搜尋欄位、篩選、分面、排序、規則、同義詞、容錯與介面整合。託管模式能減少自營叢集工作，但不會替公司定義商品結構、權限範圍、金鑰管理、索引切換或繁中驗收。適合希望把搜尋基礎設施交由服務商管理，並能接受商業依賴、設計安全資料流與持續做相關性測試的團隊。
Elasticsearch 提供查詢語言、分析器、映射、同義詞、重建索引、排名評估與安全控制等廣泛能力。高度可調也代表更多責任：欄位映射、斷詞、索引範本、容量、部署、版本升級、備份、監控與事故回復都要有明確負責人。若組織本來就有成熟 Elastic 平台團隊，這些能力可能能重用；若沒有，不能把「可設定很多」誤當成「導入一定較好」。
Meilisearch 以較集中的搜尋引擎介面提供可搜尋、可篩選、可排序與可顯示欄位，另有排序規則、同義詞、拼字容錯與在地化欄位。較小的操作面可能有利於快速建立商品搜尋，但買方仍須查明選定版本或託管方案的備援、安全、規模、任務監控與語言行為。簡潔是一項適配特徵，不是多租戶隔離或所有中日韓文字（CJK）需求已自動完成的證明。
比較矩陣：呈現營運責任與所需證據，不是供應商實測分數；部署與商業條件須個別確認。
| 決策軸 | Algolia | Elasticsearch | Meilisearch | 必須保存的證據 |
|---|---|---|---|---|
| 維運模式 | 託管服務與供應商介面 | 自管或託管的廣泛平台 | 聚焦搜尋的引擎與託管選項 | 負責人、支援路徑、備份與回復實測 |
| 相關性 | 欄位、排序、規則、同義詞、容錯 | 分析器、查詢語言、同義詞、評估工具 | 排名規則、同義詞、容錯、欄位設定 | 固定查詢集與設定版本 |
| 權限 | 可篩選欄位與受限查詢設計 | 查詢篩選、角色與索引控制 | 可篩選欄位、金鑰與應用層控制 | 直接呼叫的負向測試 |
| 多語 | 依索引與設定驗證 | 可明確選擇分析器與斷詞 | 在地化欄位仍須實測 | 繁中、日文、韓文各自樣本 |
| 索引生命週期 | 託管介面與索引策略 | 映射、別名、刷新、重建與回復 | 非同步任務與設定需監控 | 錯誤匯入回復、資料新鮮度 |
| 適合條件 | 重視託管與快速整合 | 需要深度控制且有人才 | 重視界線清楚且能驗證限制 | 含人力的總持有成本 |
這張表不是分數表。每一列若尚未用真實商品與部署方式驗證，就應寫「未知」。不要因為某產品功能名稱多，就在未測試前給它高分；也不要因為介面簡單，就把資安、備援或語言風險視為不存在。
建立可重現的繁中商品搜尋評估矩陣
可重用查詢檢核表，版本日期二〇二六年十一月四日。以下是自行設計的假設樣本，不是供應商實測結果：商品代碼 SKU-001 為現售、一般員工可見的海軍藍加大連帽上衣；EXEC-001 僅主管可見；OLD-001 已下架。先由商品負責人確認實際目錄政策，再套用下列台灣一般員工情境。
| 原樣輸入的查詢 | 測試情境 | 預期允許結果 | 禁止結果 | 實際結果 |
|---|---|---|---|---|
| SKU-001 | 精確料號、現售目錄 | 僅 SKU-001 | 其他料號 | 未知，尚未執行 |
| 帽T 加大 | 已核准別稱與尺寸 | 符合資格的加大連帽上衣，包含 SKU-001 | 錯誤尺寸或隱藏商品 | 未知，尚未執行 |
| EXEC-001 | 台灣一般員工 | 不回傳主管限定紀錄 | EXEC-001 及其分面計數 | 未知，尚未執行 |
| OLD-001 | 已下架料號 | 安全的零結果說明 | 舊品或未核准自動替代 | 未知，尚未執行 |
每列由商品負責人確認允許集合，身分工程師記錄可信任的範圍，測試者保存索引與設定版本、時間及原始回應。允許與禁止條件都成立才可通過；負向測試失敗就暫停上線、回復已知良好索引，再跑原案例及固定回歸集。這四列只是起點，不代表完整資安或語言驗收。
先從一份有日期且去識別的商品樣本開始。樣本要含現售、缺貨、下架、受限與資料錯誤紀錄；至少納入多尺寸服飾、顏色別稱、繁中名稱與英文品牌並存、短英數料號、跨地區可見性不同、替代品已核准與未核准的情況。相關性測試通常不需要收件人姓名、地址或健康與人事資料，不要為了方便把它們放進索引。
每個查詢案例記錄語系、角色、地區、方案、預算或類別條件、允許結果集合、希望排序與禁止結果。把硬性限制與軟性偏好分開。「台灣一般員工不得看到主管限定商品」是硬性限制；「新版連帽外套應排在舊活動外套之前」是軟性偏好。若兩者混在同一個相關性分數，團隊很容易用排序調整錯誤地修補權限缺陷。
查詢至少分四組。精確辨識組測料號、正式商品名、品牌與型號；繁中語言組測台灣常用詞、全半形、英中混寫、顏色與尺寸；探索組測「新進員工五十美元內桌面組合」等寬廣意圖；回復組測錯字、零結果、舊名稱、下架料號與使用者開啟頁面後庫存改變。每組都要有可驗證預期，而不是只看畫面「感覺不錯」。
繁中同義詞必須由在地商品負責人核准。「連帽上衣」、「帽T」與原樣輸入的查詢詞「hoodie」可能在某個目錄屬於同類，也可能對應不同版型；「隨行杯」與「保溫瓶」更不該直接當成完全相等。每個同義詞要有來源、適用欄位、方向、建立者與複查日。料號、年份與數字尺寸通常應有更嚴格的容錯規則，避免一個數字錯置就匹配到另一商品。
測試工具要保存資料樣本指紋、索引版本、設定版本、查詢檔、執行時間、套用篩選、前幾名結果與審查意見。不同產品不必用完全相同設定，因為那會偏袒某種架構；但輸入契約、硬性限制與驗收定義要一致。延遲數字要說明環境、樣本大小、次數，以及是寫入完成、可搜尋或畫面顯示的哪一段，不能把小型本機測試寫成普遍性能結論。
審查角色也要分開。商品負責人判斷類別與檔期意圖；繁中審查者判斷用詞、斷詞與別稱；資安或平台人員驗證篩選是否可繞過；營運人員驗證回復、監控與支援。意見不同不是失敗，而是揭露商品資料、政策或需求尚未寫清楚的證據。
權限隔離必須比排名更硬
欄位、存取與保存的交接可參照企業贈禮資料治理指南，把已核准目的轉成作業欄位表；它不代替公司的合法依據判斷。
公司商店可能同時服務員工、約聘人員、經銷商、活動參加者、客戶與主管。商品也可能因授權、預算、任職狀態、庫存、配送地或方案規則而不可見。這些條件應是明確欄位，並在後端或受信任的存取機制中強制套用，不能只靠前端頁籤隱藏，也不能只讓受限商品排名較後。
使用 Algolia 時，要依官方文件確認可搜尋金鑰、受限條件與索引範圍的實際設計，再用自己的架構做直接請求測試。使用 Elasticsearch 時，文件層與欄位層安全、角色查詢、索引權限有具體限制，也可能受部署與授權條件影響；例如省略角色查詢可能使該權限項目不再套用文件層限制。使用 Meilisearch 時，可篩選欄位與應用程式介面（API）金鑰只是材料，仍要由公司後端決定使用者可以帶入的範圍。任何產品都不能用「有篩選參數」直接證明多租戶隔離成立。
負向測試要嘗試移除前端篩選、直接呼叫 API、修改國家、重用角色變更前的金鑰、搜尋已下架料號、要求過大結果集，以及利用分面或統計推測隱藏類別。通過代表在既定威脅模型中，禁止紀錄與敏感計數沒有外洩；不代表供應商替公司認證了整套權限架構。
索引也不應保存不必要的敏感理由。它可能需要不透明的權益代碼，卻不需要員工薪酬、績效敘述、病史或法務意見。姓名與配送地址應在核准方案需要時才交由後續流程收集。搜尋紀錄本身也可能透露未發布產品、活動計畫、人物或健康相關詞彙，必須設定存取、保留與刪除規則。
當權益來源逾時，系統要依事先決定的保守規則處理。高風險商店可暫停受限目錄；較低風險的內部商店可只顯示預設安全目錄。絕不能因為權限服務失敗，就顯示所有目錄的聯集。
把繁中、日文、韓文視為三個在地產品
英文測試清單翻譯成三種語言，無法完成 CJK 搜尋驗收。繁中要測台灣商品慣用詞、全半形、英文字母、單位與尺寸；日文要測漢字、平假名、片假名、長音、全半形與型號；韓文要測分寫、複合詞、品牌音譯與短代碼。三者的錯字與同義詞行為也不同。
索引應保存各語系的原生商品名、別稱與必要描述，不要只保留一個機器翻譯欄位。設定在地化欄位或分析器時，記錄實際版本、欄位與結果。產品文件寫「支援某語言」只代表有可用能力，不代表公司的商品命名、混合文字與權限條件已被驗收。
台灣案例可測「帽T／連帽上衣」、「馬克杯／陶瓷杯」、顏色俗稱、尺寸 S/M/L 與公分寫法，以及英文品牌加中文類別。日文案例要觀察同一商品在漢字、片假名與羅馬字的尋找方式。韓文案例要觀察空格有無與音譯差異。若容錯對短詞過寬，可能把不同料號或品牌混在一起；若過窄，使用者會頻繁得到零結果。最佳設定必須由固定案例與在地審查共同決定。
零結果設計不可偷偷解除限制。可以建議重新輸入、顯示核准類別、提供聯絡支援或顯示已核准的替代目錄，但不能為了讓畫面有商品就跨越受眾、國家、預算或庫存界線。分析零結果可幫助改善內容，新增同義詞前仍應由在地負責人核准。
用兩個假設案例完成選擇
案例甲是一個三百項商品的員工商店，含服飾、杯具、桌面用品與地區套組。三十項已下架，四個受眾群組與四個國家有不同可見性。團隊有兩位開發者，沒有專職搜尋工程師。輸入包括三百筆現售紀錄、三十筆下架紀錄、二十五組同義詞與六十個黃金查詢。負責人包括商店產品經理、商品經理、身分系統工程師、在地語言審查者與客服主管。
此團隊可把 Algolia 當成託管選項，Meilisearch 當成較聚焦選項；只有在組織已有 Elasticsearch 維運能力，或實測顯示需要更深分析與查詢控制時，才把後者視為合理候選。驗收要求是禁止結果零失敗、錯誤索引能回復、優先查詢獲得在地審查同意、零結果有安全路徑，以及成本估算含人力。若任何候選可在瀏覽器移除權限條件，即使排序漂亮也不通過。
案例乙是跨語言的贈品選擇目錄。商店索引繁中、日文與韓文名稱及權益欄位，核准後的收件流程才蒐集配送資料。搜尋只確認「可被看到並選擇」，不保留庫存，也不核准替代品。測試要涵蓋日文全半形、韓文空格、繁中別稱、下架料號、方案到期與庫存轉換。
若評估 Giftpack，介面邊界要寫明：商店或搜尋應用把已核准選項，或已縮限的選擇集合，交給經確認支援的 Giftpack 流程。公司仍負責資格、目的、預算與政策。Giftpack 可依實際方案設定支援收件人選擇與履約，但本文不主張它與 Algolia、Elasticsearch 或 Meilisearch 有原生連接器。導入前須直接確認支援的資料入口、欄位、驗證、錯誤處理與商業範圍。
案例乙的通過條件包括：三個市場結果正確、隱藏商品不外洩、舊索引有停止規則、承諾前再次確認庫存、收件人可拒絕，以及訂單到配送可對帳。搜尋有商品但後續無法配送時，要辨別是主檔過期、權益不一致、庫存時差、目的地不支援或未核准替代，而不是預設調整排名。
把切換、回復與日常營運列入決策
索引流程要定義建立、更新、下架與刪除；也要定義非同步任務如何監控、何時可啟用新版本、舊版本保留多久。每次匯入要有版本或冪等鍵、來源筆數、拒絕報告與完成回執。部分成功不能靜默變成正式目錄。
在產品能力允許時，先建立候選索引或等效的分段切換。載入後跑禁止結果、基本查詢、筆數與新鮮度檢查，再透過別名、移動索引、設定切換或該產品文件規定的方法啟用。保留上一個已知良好版本至回復窗口結束。三個產品的操作方式不同，正式手冊應引用當時官方文件，不能照抄通用指令。
監控至少包含索引延遲、失敗任務、紀錄數、零結果率、禁止結果探針、慢查詢、金鑰錯誤，以及索引可見與實際可履約狀態的落差。零結果率下降不一定是改善：若原因是同義詞過寬或受限商品外洩，反而是事故。
把事件分級。相關性事件是允許商品排序不佳，由商品團隊依受控流程修正；權限事件是禁止商品可見，應立即限制搜尋並保存證據；新鮮度事件是已下架或缺貨資訊過期，應回復已知良好版本或安全目錄；履約不一致則在核准商品無法交付時，對帳訂單並修正上游契約。每季複查負責人、版本、憑證、欄位、保留期、語言樣本與回復證據。
把評估矩陣變成可執行的採購與驗收文件
評估表的第一頁應先說明範圍，而不是先列產品。寫出目錄規模、每日更新次數、預估查詢量、使用市場、受眾群組、可接受中斷、資料保留與支援時段。若查詢量或成長未知，就以情境區間表示，不要用單一樂觀數字。供應商報價、雲端成本與自建人力都要使用相同期間與負載假設，並標註尚未納入的項目。
每個能力列要有「需求、設定、測試、證據、負責人、結果」六欄。需求描述商業與風險目標；設定記錄實際欄位、規則與版本；測試連到固定案例；證據保存回應、截圖以外的機器可讀輸出與審查意見；負責人承擔修正；結果只能是通過、不通過、有限制通過或未知。不要以產品簡報中的「支援」直接填成通過。
相關性驗收可採分層方式。第一層是禁止結果與精確料號，必須全部通過。第二層是優先查詢，由在地商品負責人判定前幾名是否可接受。第三層是探索與長尾查詢，記錄改善空間但不以主觀平均分掩蓋重大失敗。若採用數值指標，要保留判定集合、評審者與計算方式，並說明它不能取代權限驗收。
索引新鮮度要有端到端時間線。記錄主檔變更時間、匯出時間、接收時間、索引任務完成時間、搜尋可見時間與商店快取更新時間。這樣才能區分來源延遲、管線延遲、搜尋平台延遲與前端快取。只量測 API 回應速度會漏掉最常造成下架商品仍可見的問題。
供應商安全審查也要對應公司實際用法。確認管理者與查詢金鑰如何分離、祕密如何輪替、誰能改排序與同義詞、審計紀錄能否取得、非正式環境是否使用生產資料、離職帳號如何撤銷。若使用文件層或受限金鑰，保存直接請求的通過與拒絕樣本。合規認證可作為輸入，但不能替代架構測試與公司決定。
商業比較應分出固定費、用量費、額外環境、支援、資料傳輸、監控、人力與遷移成本。自建方案不是免費，託管方案也不是零人力。至少建立基準、成長與尖峰三個情境，並寫出超出上限時的降級策略。若價格資料屬於洽談條件，就標記日期與保密範圍，不在文章中推論普遍價格。
最終採購決定可附一份未解風險清單。例如：韓文查詢仍有五個低優先案例未達標、索引回復只在測試環境演練、某地區商品來源尚未提供可靠庫存時間戳。每一項都要有接受者、改善動作與期限。有限制通過不是把缺口藏起來，而是明確說明誰接受何種風險。
上線後三十天與九十天複查原來的假設。比較實際查詢分布、零結果、權限探針、索引延遲、客服案件與履約不一致。若資料與假設不同，更新規則並重跑回歸集。不要以點擊率單獨判定成功，因為高點擊可能來自被迫選擇、錯誤排序或受限商品曝光。
評估也要涵蓋變更治理。新增同義詞、調整排名、改可搜尋欄位與放寬容錯，都可能影響大量查詢。每次變更要有申請目的、影響語系、預期案例、禁止案例、核准者、部署時間與回復方法。緊急變更可縮短流程，但仍須保存前後設定與事後複查。不要讓商品團隊只能透過口頭請求，直接在正式環境修改規則。
對營運主管而言，供應商支援的可用性也需實測。確認什麼事件能開高優先案件、需要提供哪些診斷、回應時限從何時開始、公司內誰有權聯絡。演練一次非敏感的測試事件，確認日誌不會夾帶個資或未發布商品全文。供應商能回覆問題，不代表公司已完成自己的事故指揮與受眾通知決定。
資料退出也應在採購前驗證。確認商品紀錄、設定、同義詞、查詢分析與審計紀錄能否匯出，終止服務後的刪除時間與證據為何。不要追求不可能的完全可攜性，但要保留中立的商品主檔、查詢案例與決策證據，避免下一次選型只能從供應商特有畫面重新猜測。
最後，將「搜尋通過」與「商店通過」分開。搜尋通過只證明索引、查詢、資格篩選與回復達到定義；商店通過還包括登入、價格、庫存、選擇、訂單、拒絕、退回與客服。兩者可以由同一專案交付，但不可用搜尋示範取代端到端驗收，也不可因履約流程已存在，就假設搜尋權限沒有缺口。
驗收簽署時，商品、平台、資安、在地語言與營運負責人各自確認自己掌握的範圍。任何人都不應替其他專業領域作未查證的保證。簽署內容要連到確切測試版本，而不是只寫「系統已測試」。後續若變更商品欄位、權限模型、主要語言設定或索引切換方式，就重新打開受影響的驗收項目，避免沿用已不適用的舊通過紀錄。
若最終選擇暫緩，也要保存原因與重啟條件，例如缺少權限證據、語言樣本不足或沒有可承擔值班的團隊。暫緩不是失敗的空白狀態，而是有根據的採購結果；等條件改變時再從原測試資產續接，不必重新編造需求。
重啟時先確認原商品樣本、官方文件、價格與權限模型是否仍有效，再只重跑受影響與固定回歸案例。
複查結果同樣保存日期、版本、責任人與未解差異。
選擇能被證明、也能長期承擔的模式
Algolia 適合重視託管搜尋，且能管理安全索引、受限存取與持續測試的團隊；Elasticsearch 適合需要深度分析與查詢控制，並已有維運或治理能力的組織；Meilisearch 適合希望操作面較聚焦，並願意用真實目錄驗證語言、安全、規模與生命週期限制的團隊。這不是永久名次，同一公司在不同商店也可能作出不同選擇。
最後決策紀錄應附商品樣本指紋、查詢集、設定版本、硬性限制結果、三地語言審查、回復測試、維運負責人、成本假設、未解問題與複查日。未知就保持未知，不用虛構分數填滿表格。
公司商店先產生已核准且符合權益的選擇後，才可另外評估 Giftpack 作為收件人選擇與履約層。實際串接與商業範圍必須直接確認；Giftpack 不取代搜尋引擎、公司權益服務、資安控制或政策決定。