---
title: "開發 AI 購物商城搜尋前應先決定的5項營運政策"
locale: zh-hant
category: how_to
category_name: "操作教學"
translation_status: machine
license: cc_by
author: "Injoys Admin"
source_url: https://injoys.com/en/articles/five-policies-before-ai-ecommerce-search-development
published_at: 2026-07-21T10:05:48+09:00
---

# 開發 AI 購物商城搜尋前應先決定的5項營運政策

> AI 可以快速寫出購物商城搜尋程式碼，但商品曝光標準與例外處理必須由營運者先行決定。本指南將排序、商品狀態、列表方式、搜尋範圍、日誌政策整理到實際實作與測試層級。

## Key Points

- 預設排序應以文件化的公式結合搜尋相關度與銷售、品質訊號，廣告曝光則必須與自然排序分離。
- 缺貨、暫時停售、銷售結束、召回應建模為不同狀態，並在搜尋、詳情、購物車、結帳中一致處理。
- 大型商品列表應依目的選擇分頁、載入更多或無限捲動，並確保 URL 狀態與返回時的復原。
- 不只商品名稱，也應將品牌、類別、屬性、同義詞、型號納入搜尋範圍，並將無結果畫面設計成獨立陳列區。
- 搜尋日誌可作為需求資料使用，但應最小化個人識別碼與敏感搜尋詞，並區分原文保存與彙總保存。

AI 可以快速製作商品列表 API、搜尋框、排序按鈕。然而，**要展示哪些商品、隱藏哪些商品，以及把什麼稱為「推薦」**，不是程式碼，而是營運政策。購物商城搜尋不是單純的查詢功能，而是貨架配置、廣告版位、庫存處理、顧客體驗、資料收集結合在一起的決策系統。

如果沒有提供政策，只指示「幫我做商品搜尋功能」，AI 可能會任意填入最新上架順、商品名稱部分一致、簡單分頁等熟悉的範例。即使程式碼可以執行，也可能不符合店鋪營運。代表性問題包括最新商品已售罄卻曝光在第一列、停售商品仍可加入購物車，以及顧客搜尋「蘋果」卻找不到「青松富士」等。

## 搜尋排名不是技術功能，而是營運政策

商品陳列順序可以由業者設計。不過，如果畫面傳達給消費者的意義與實際排名計算方式不一致，或是讓具有經濟利害關係的曝光看起來像一般推薦，法律與信任上的風險就會提高。

公平交易委員會於 2024年 6月針對 Coupang 與 CPLB 的搜尋排名營運及員工撰寫購買評價等問題，宣布暫定 1,400億韓元的罰鍰，同年 8月依決議書基準確定罰鍰為 1,628億韓元。業者方面不服處分，而依 2026年 4月報導基準，相關撤銷訴訟仍在進行中。這個案例的實務教訓並不是「優待自家商品永遠違法」這種簡單命題。重點是必須在設計階段檢討：**標示為推薦究竟代表什麼、是否明確揭露廣告與自家利害關係、是否能用資料與文件說明排名變更**。

法律適用可能會依服務結構與標示方式而有所不同，因此實際上線前，另行確認相關法令與最新執法案例會比較安全。

## 一行提示詞造成的「快速完成版」失敗點

| 未定政策 | AI 可能任意填入的實作 | 實際營運風險 |
|---|---|---|
| 預設排序 | `created_at DESC` | 最近上架但售罄或尚未審核的商品曝光在上方 |
| 銷售狀態 | 只確認是否刪除 | 暫停銷售或召回商品被搜尋到或可下單 |
| 列表載入 | 全量查詢或簡單無限捲動 | 回應緩慢、返回時遺失位置、難以比較 |
| 搜尋範圍 | 只對商品名稱部分一致 | 品牌、品種、型號、同義詞搜尋失敗 |
| 無結果 | 只回傳空陣列 | 購買意圖高的顧客立即離開 |
| 日誌 | 原樣儲存搜尋字詞與會員、IP | 目的外收集、過度保存、敏感搜尋字詞曝光風險 |

AI 可以補上需求的空白，但無法判斷該選擇是否符合店鋪策略與法律責任。因此在實作前，至少必須以文件確定以下五項政策。

## 1. 排序預設值：什麼可以稱為「推薦順」

預設排序是顧客最先看到的貨架。多數使用者不會更改排序選項，因此預設值會直接影響營收、庫存去化、新品培育、顧客滿意度。

### 先拆分排名計算階段

搜尋結果與其一次混合計算，不如依照以下順序拆分會更安全。

1. **曝光資格判定：** 只將可銷售、可公開、非法律或營運阻擋對象的商品納入候選。
2. **搜尋相關度計算：** 計算商品名稱、品牌、類別、屬性、同義詞與搜尋字詞有多相符。
3. **自然排名計算：** 結合銷售速度、轉換率、評分可信度、配送品質等訊號。
4. **套用商業規則：** 套用售罄扣分、新品探索機會、多樣性限制等。
5. **結合廣告版位：** 廣告商品與自然排名分離插入，並明確標示。
6. **穩定處理同分：** 分數相同時，用 `product_id` 等固定鍵決定順序。

### 推薦分數必須是文件化的公式

以下只是用來說明結構的範例，不是適用於所有購物商城的正解。

```text
organic_score =
  0.45 × query_relevance
+ 0.20 × conversion_rate_28d
+ 0.15 × sales_velocity_14d
+ 0.10 × rating_confidence
+ 0.10 × fulfillment_quality
```

每個訊號都應正規化到相同範圍，並明示期間與彙總對象。單純平均星等可能會讓 1 則評論的 5 分商品高於 1,000 則評論的 4.8 分商品，因此最好使用同時反映評論數的校正分數。若只使用銷量，長期銷售的商品可能會永久占優，因此應同時查看最近期間的銷售速度與轉換率。

### 必須決定的細項

- 推薦順的目標是搜尋適配度、購買可能性、顧客滿意、庫存效率中的哪一項
- 各訊號的彙總期間與更新週期
- 取消率、退貨率、配送延遲、售罄可能性等扣分訊號
- 給評論較少新品的探索機會與最高加分
- 避免同一品牌或同一賣家過度占據上方的多樣性規則
- 分數同分時使用的固定排序鍵
- 留下排名公式版本、變更原因、套用時間、核准者的稽核紀錄
- A/B 測試的成功指標與中止條件

### 不要混合廣告與自然推薦

可以反映廣告費、自家商品與否、高毛利等經濟利害關係，但若讓其被誤認為一般的「人氣順」或「推薦順」，就會有風險。公平交易委員會在 2025年高價商品銷售平台案件中，也針對購買付費選項的賣家商品會在預設排序中優先曝光的結構及相關標示提出問題。廣告商品應以獨立候選群與版位管理，並在卡片單位提供可識別的「廣告」或「贊助」標示，這是基本做法。管理員畫面應分開顯示廣告曝光規則與自然排名公式。

## 2. 異常狀態商品：售罄與暫停銷售是不同狀態

若只用 `is_sold_out` 處理所有例外，搜尋、詳情、購物車、訂單驗證會彼此不一致。至少必須分離**銷售狀態、庫存狀態、公開狀態、法規狀態**。

### 建議狀態模型

| 狀態 | 搜尋、列表 | 直接 URL 詳情 | 購物車、訂單 | 建議處理 |
|---|---|---|---|---|
| 銷售中且有庫存 | 正常曝光 | 正常顯示 | 可行 | 基本候選 |
| 銷售中但暫時售罄 | 可顯示但扣分或後排 | 顯示售罄、補貨通知 | 不可 | 保留補貨可能性 |
| 暫時停止銷售 | 預設隱藏 | 暫停說明 | 不可 | 恢復時復原 |
| 銷售結束 | 從搜尋與類別隱藏 | 結束說明與替代商品 | 不可 | 保留既有連結與 CS 脈絡 |
| 草稿、審核中 | 完全隱藏 | 僅有權限的管理員 | 不可 | 公開前審核 |
| 召回、法律阻擋 | 完全隱藏 | 必要時安全公告 | 不可 | 安全說明優先於替代推薦 |

售罄商品對補貨通知與掌握搜尋需求有價值，因此不必一律刪除。相反地，銷售結束商品應從一般列表排除，但可以向透過既有書籤或外部連結進入的顧客提供「銷售已結束」的說明與相似商品。是否保留詳情 URL 或以 `410 Gone` 結束，應依搜尋流入、法律公告必要性、替代內容價值決定。

### 搜尋索引不是可下單與否的最終權限

搜尋索引可能產生同步延遲。因此即使搜尋結果顯示有庫存，也必須在下一階段再次驗證。

- 加入購物車時重新驗證銷售狀態與庫存
- 進入訂單頁時重新驗證價格、折扣、庫存
- 付款前進行庫存預留或原子性扣減
- 發生暫停銷售事件時緊急移除搜尋索引
- 監控索引延遲時間與失敗件數

如果沒有這些規則，就會反覆發生搜尋畫面正常、卻只在付款階段失敗的 CS 事故。

## 3. 列表曝光方式：分頁、載入更多、無限捲動要用哪一種

若商品有數千、數萬個，就不應一次全部傳下去。不過，斷定「購物商城永遠應該用數字分頁」也不準確。以比較為中心的搜尋重視位置與狀態復原，而在類別探索中，「載入更多」可能更方便。

| 方式 | 優點 | 缺點 | 適合情境 |
|---|---|---|---|
| 數字分頁 | 容易理解目前位置與結果規模，可重新造訪特定頁面 | 頁面切換中斷，跨頁比較麻煩 | 桌面搜尋、深度探索、可分享結果 |
| 載入更多 | 保留既有商品，同時由使用者控制載入 | 結果非常多時 DOM 與記憶體變大 | 行動裝置、類別探索、中等規模結果 |
| 無限捲動 | 連續探索自然 | 位置、結尾、整體規模不明確，返回復原困難 | 發現比比較更重要的動態牆型畫面 |

實務上，可以優先考慮**搜尋結果採用分頁或「載入更多 + 可復原的頁面 URL」**，發現型推薦動態牆採用無限捲動。即使使用純無限捲動，也必須滿足以下條件。

- 將搜尋字詞、排序、篩選、頁面或游標儲存在 URL 或可復原狀態中
- 從詳情頁返回時，復原先前商品與捲動位置
- 支援鍵盤探索、螢幕閱讀器、焦點移動
- 提供可存取頁尾與主要導覽連結的替代方案
- 提供載入失敗與重試 UI
- 為每個結果群組準備可存取的唯一 URL 或連結結構

### 偏移量與游標分頁

像 `OFFSET 5000 LIMIT 40` 這樣的深層偏移量，在資料量大且更新頻繁時會越來越慢，也容易產生重複與遺漏。淺層頁面與管理員畫面使用偏移量較單純，但大規模搜尋使用傳遞最後結果排序鍵的游標方式會更穩定。

```text
ORDER BY score DESC, product_id DESC
cursor = last_score + last_product_id
```

如果只用分數作為游標，同分商品可能會被遺漏，因此應同時使用唯一鍵。若推薦分數即時且頻繁變動，也需要在搜尋工作階段期間固定快照版本或排名基準時間的政策。

## 4. 搜尋範圍與無結果畫面：將顧客的表達連結到商品資料

顧客不知道營運者登錄的精確商品名稱。若要讓尋找「蘋果」的顧客看到「青松富士」、「紅露」、「家用蘋果」，就必須同時設計商品資料與搜尋詞典。

### 搜尋欄位優先順序

| 欄位 | 建議優先順序 | 範例 |
|---|---:|---|
| SKU、型號、條碼 | 非常高 | `SM-S928N`, `880...` |
| 商品名稱 | 高 | 青松富士蘋果 3kg |
| 品牌、製造商 | 高 | Samsung, Apple |
| 類別、商品類型 | 中等以上 | 水果、跑鞋 |
| 核心屬性 | 中等以上 | 容量、顏色、規格、相容機型 |
| 同義詞、別名、品種、標籤 | 中等以上 | 慢跑鞋↔跑鞋，蘋果↔富士 |
| 詳細說明 | 低 | 為降低長篇說明雜訊而降低權重 |
| 評論內文 | 選擇性 | 檢討品質、垃圾內容、個人資料後有限使用 |

韓文搜尋中也必須考慮空格差異、字母分離、英文與韓文品牌標記、數字與單位、複合名詞。例如應建立正規化規則，讓「에어팟프로2」、「에어팟 프로 2」、「AirPods Pro 2」連結到同一商品群。

### 建議搜尋流程

1. 驗證輸入長度與允許字元。
2. 正規化大小寫、空白、特殊字元、單位。
3. 先確認是否與商品代碼精確一致。
4. 套用斷詞與形態、拼字變形。
5. 擴展營運者管理的同義詞與類別詞典。
6. 以文字搜尋尋找候選。
7. 必要時將語意搜尋用於輔助候選生成。
8. 篩選銷售、公開、法規狀態。
9. 計算自然分數，並另行結合廣告。
10. 回傳結果與診斷資訊。

即使導入生成式 AI 或向量搜尋，也不應弱化 SKU、品牌、型號等精確一致。在購物搜尋中，結合**精確搜尋 + 文字相關度 + 選擇性語意搜尋**的混合方式通常較安全。為避免 AI 編造目錄中不存在的商品、價格、庫存，所有回應都必須連結到實際商品 ID 與目前資料。

### 無結果畫面是第二個貨架

搜尋結果為零時，不要只顯示空白畫面。不過，也不應把無關的人氣商品混入並看起來像搜尋結果。

建議構成如下。

- 原樣顯示使用者輸入的搜尋字詞，並明確告知沒有一致商品
- 錯字修正候選與同義詞建議
- 若因篩選導致 0 筆，提示可移除的篩選條件
- 以獨立標籤呈現擴大範圍後的結果
- 區分並曝光相關類別、替代商品、整體人氣商品
- 補貨、上架請求或連接客服中心
- 將無結果搜尋事件記錄到管理員分析

「無結果」與「套用篩選後無結果」是不同問題。如果原本有候選，但因價格、顏色篩選而變成 0 筆，放寬篩選最有用；如果目錄本身沒有商品，則應作為採購資料使用。

## 5. 搜尋紀錄：同時管理市場調查資料與個人資料

無結果搜尋字詞顯示顧客尋找但無法購買的需求。人氣搜尋字詞有助於陳列與庫存計畫，而搜尋後點擊、購物車、購買流程會成為評估搜尋品質的核心指標。

然而，不能斷定「只儲存搜尋字詞與次數就永遠不是個人資料」。搜尋字詞本身可能包含電話號碼、訂單號碼、姓名、健康、宗教、性生活等敏感內容，若與帳號、IP、裝置資訊結合，識別或追蹤個人的可能性就會提高。

### 建議收集項目

| 類別 | 建議處理 |
|---|---|
| 正規化搜尋字詞 | 以日、時間單位彙總，並將原文保存期間最小化 |
| 結果數 | 儲存是否 0 筆與區間值 |
| 套用篩選、排序 | 只儲存搜尋品質分析所需範圍 |
| 點擊、購物車、購買 | 盡可能以搜尋字詞單位彙總指標儲存 |
| 工作階段連結 | 只有必要時使用短生命週期的隨機識別碼 |
| 會員 ID、IP、精確位置 | 若沒有明確目的與依據，從搜尋分析日誌排除 |
| 原文中的個人資料 | 遮罩或廢棄電子郵件、電話號碼、訂單號碼模式 |

雜湊後的會員 ID 也不會自動變成匿名資訊。如果能重新連結到特定使用者，就必須作為假名資訊或個人資料處理。保存期間也不要一律決定，而應以目的、分析週期、安全風險為基準，分別設定原文與彙總資料。

### 管理員儀表板需要的指標

- 搜尋量與唯一搜尋字詞數
- 無結果比例
- 搜尋結果點擊率
- 搜尋後購物車率與購買轉換率
- 搜尋字詞修改率與篩選解除率
- 售罄商品曝光比例
- 上位結果集中度與品牌多樣性
- 區分廣告與自然結果成果的指標
- 搜尋索引新鮮度與索引失敗件數

低頻原文搜尋字詞可能包含個人資料，因此只將超過最低彙總基準的項目曝光在營運者畫面，也是一種有用方法。

## 實戰提示詞：將政策轉換為程式碼的方法

比起大量使用開發術語，清楚寫出營運規則更重要。可以依服務情境填寫以下模板並提供給 AI。

```text
請設計並實作我們購物商城的商品搜尋功能。

1. 曝光資格
- 只將銷售中、公開狀態且沒有法規阻擋的商品納入搜尋候選。
- 暫時售罄仍顯示，但排在相同條件的有庫存商品之後。
- 銷售結束與暫時停止銷售從搜尋、類別隱藏。
- 銷售結束商品的直接 URL 顯示結束說明與替代商品，並移除購買按鈕。

2. 預設排序
- 最大程度反映搜尋字詞相關度。
- 反映最近 28日轉換率、最近 14日銷售速度、校正評分、配送品質。
- 各權重可透過設定檔或管理員政策變更。
- 同分時以 product_id 降冪穩定排序。
- 廣告商品不要混入自然分數，而是放入獨立版位並標示為「廣告」。

3. 列表探索
- 一次回傳 40個。
- 讓搜尋字詞、排序、篩選、頁面或游標可從 URL 復原。
- 從詳情頁返回時，復原列表與捲動位置。
- 大規模結果使用游標分頁。

4. 搜尋範圍
- SKU 與型號精確一致列為最高優先。
- 搜尋商品名稱、品牌、類別、屬性、同義詞標籤。
- 處理韓文空格與英文、韓文品牌變形。
- 無結果時，區分顯示錯字建議、放寬篩選、相關類別、替代推薦。

5. 搜尋日誌
- 預設只儲存正規化搜尋字詞、時間區間、結果數、篩選、彙總點擊與購買指標。
- 會員 ID 與 IP 不儲存在搜尋分析日誌。
- 電子郵件、電話號碼、訂單號碼形式要遮罩。
- 將原文保存期間與彙總保存期間分離為設定值。

6. 技術需求
- 一併設計資料模型、API 合約、搜尋索引、同步方式、例外處理、管理員指標。
- 提出符合實際查詢模式的索引，並說明確認執行計畫的方法。
- 即使在搜尋索引延遲情況下，也要在購物車與付款階段重新驗證狀態、價格、庫存。
- 撰寫單元測試、整合測試、效能測試、可及性測試情境。

開始實作前，如果有我尚未決定且會影響結果的政策，請先提問；若有任意決定的假設，請以獨立清單標示。
```

最後一句是將 AI 從單純程式碼生成器轉變為需求檢討夥伴的核心裝置。不過，不應只停留在接收問題，而必須將確定的答案反映到政策文件與測試條件中。

## 實作設計：將政策固定到資料與 API

### 資料模型範例

```text
products
- product_id
- sales_status
- stock_status
- visibility_status
- compliance_status
- brand_id
- category_id
- searchable_name
- search_tags
- price
- inventory_quantity
- ranking_feature_version
- updated_at
```

不要在一個欄位中放入多個意義。例如若只有 `status = 1`，就無法知道它代表可銷售、可公開、有庫存、通過法規中的哪一種。狀態轉移也應以表格管理，定義從草稿移動到銷售中、從銷售中移動到結束時所需的審核與事件。

### API 回應中應包含的資訊

- 正規化搜尋字詞
- 已套用的排序與篩選
- 結果群組與下一個游標
- 結果數或近似結果數
- 售罄、銷售狀態徽章
- 是否為廣告與廣告標示文案
- 是否進行錯字修正、搜尋範圍擴大
- 搜尋政策版本與追蹤用請求 ID

內部除錯資訊如原始分數與商業上敏感的權重，沒有必要原樣曝光在顧客 API 中。相反地，營運者應能以請求 ID 重現排名計算路徑。

### 索引應依實際查詢模式設計

一般而言，狀態篩選與排序使用的欄位應檢討 B-tree 系列索引，全文搜尋文件則檢討倒排索引系列。如果是 PostgreSQL，可以使用 `tsvector` 與 GIN 索引；若需要相似字串搜尋，可以使用 `pg_trgm`。即使使用外部搜尋引擎，原則也相同。

```sql
CREATE INDEX idx_products_visibility
ON products (visibility_status, sales_status, compliance_status);

CREATE INDEX idx_products_search_document
ON products USING GIN (search_document);
```

索引越多，寫入成本與儲存空間也會增加。不要只靠預估決定，而應以實際查詢與資料分布確認 `EXPLAIN ANALYZE`、慢查詢日誌、負載測試。商品數增加時，應同時查看 p95、p99 延遲、逾時率、索引新鮮度，而不只是平均回應時間。

### 接上生成式 AI 時要增加的安全裝置

- 商品是否存在、價格、庫存、配送日只使用目錄 API 結果
- 記錄模型產生的搜尋字詞擴展與原文，並限制過度擴展
- 精確 SKU、型號搜尋優先於語意搜尋
- 暫停銷售、召回篩選同樣套用於 AI 搜尋候選
- 追蹤回應中曝光的商品 ID 與依據欄位
- 模型失敗時回退到一般文字搜尋
- 即使商品說明或評論中有提示詞注入性句子，也要分離，避免作為系統指示執行

## 上線前驗收測試

| 情境 | 預期結果 |
|---|---|
| 昨天上架的售罄商品與持續銷售的有庫存商品同時存在 | 售罄商品不會占據預設上方 |
| 搜尋銷售結束商品 | 列表中不存在，直接 URL 顯示結束說明與不可購買狀態 |
| 廣告商品曝光在第 1 位版位 | 可在卡片上立即識別為廣告 |
| 套用篩選後 0 筆 | 提示移除篩選建議與原本是否存在候選 |
| 搜尋「러닝화」、「조깅화」 | 依同義詞政策一致曝光相關商品群 |
| 開啟詳情後返回 | 搜尋字詞、篩選、排序、列表、捲動位置復原 |
| 多個商品分數相同 | 即使反覆切換頁面，也以固定順序維持無重複、無遺漏 |
| 搜尋索引中仍有庫存 | 在購物車、付款階段以最新庫存阻擋 |
| 搜尋字詞包含電子郵件、電話號碼 | 儲存日誌前遮罩或廢棄 |
| 大量同時搜尋 | 符合已定義的 p95 延遲與錯誤率基準 |
| 管理員搜尋字詞儀表板 | 低頻原文與敏感模式不會原樣曝光 |
| 變更排名權重 | 記錄政策版本、核准者、套用時間、前後指標 |

## 營運階段應重複進行的工作

搜尋不是開發一次就結束的功能。商品組成、季節、促銷、顧客表達都會改變，因此應將以下週期納入營運流程。

1. 每週檢討無結果搜尋字詞與暴增搜尋字詞。
2. 透過核准程序更新同義詞與類別對應。
3. 一併查看售罄曝光率、點擊率、轉換率、搜尋字詞修改率。
4. 權重變更應在離線評估與受限 A/B 測試後再擴大。
5. 分別稽核廣告、自家商品、自然結果的曝光比重。
6. 定期檢查搜尋日誌的保存期間、存取權限、遮罩失敗。
7. 以實際流量重新檢討索引使用率與慢查詢。

## 結論

AI 可以快速製作搜尋 API 與畫面，但無法決定哪些商品有資格站到顧客面前。實戰型購物商城搜尋，必須先將**排序預設值、商品狀態、列表探索、搜尋範圍與無結果處理、搜尋日誌**確定為政策，並在資料模型、API、索引、測試、管理員指標中一致反映該政策時，才算完成。

即使程式撰寫可以自動化，陳列原則與責任也不會自動產生。最好的 AI 提示詞不是冗長困難的開發術語，而是清楚區分營運者已決定的政策與尚未決定問題的文件。

## FAQ

### 為什麼將購物商城搜尋的預設排序設為依最新登錄排序會有問題？
依最新登錄排序只反映登錄時間，因此缺貨、尚未審核、銷售性較低的商品可能佔據上方。先確保搜尋詞相關度與可銷售狀態，再組合轉換率、銷售速度、評分可信度等信號會比較安全。

### 推薦排序的權重可以讓 AI 自動決定嗎？
AI 可以提出候選公式並製作模擬程式碼，但目標與允許範圍必須由營運者決定。權重應使用歷史資料進行離線評估，並經過有限制的 A/B 測試與中止條件後再變更。

### 缺貨商品應該從搜尋結果中完全隱藏嗎？
如果有補貨可能性，且顧客可以使用補貨通知，比起完全刪除，顯示缺貨標籤並排在後段會更有用。長期缺貨或停止供應的商品應依另行標準隱藏，而是否可購買則必須在購物車與結帳階段再次驗證。

### 銷售結束商品的詳細頁面用 404 移除才是正確的嗎？
不一定總是如此。如果既有連結、訂單紀錄、安全公告、替代商品介紹具有價值，可以保留詳細頁面，同時明確標示銷售結束與不可購買狀態。如果完全沒有內容價值且適合永久移除，則可檢討 404 或 410 政策。

### 分頁與無限捲動之中，哪種方式對購物商城更好？
對於比較與回訪很重要的搜尋結果，數字分頁或載入更多的方式通常較容易管理。若要使用無限捲動，必須完善 URL 狀態、返回、捲動位置、無障礙性、錯誤復原，且更適合探索型動態消息。

### 導入 AI 搜尋或向量搜尋後，就不需要既有的文字搜尋了嗎？
需要。像 SKU、型號、品牌、規格這類精確匹配很重要的購物搜尋，必須以文字搜尋為基礎。語意搜尋應作為擴大不同表述候選項的輔助層使用，並且必須連接到實際商品 ID 與庫存資料。

### 只儲存搜尋詞和搜尋次數，就不會有個人資料問題嗎？
不能視為自動安全。搜尋詞中可能包含電子郵件、電話號碼、訂單號碼或敏感內容，若與其他識別資訊結合，可能追蹤到個人。需要目的最小化、遮蔽、存取控管，以及將原文與彙整資料分開保存。

### 可以把廣告商品放在推薦排序的上方嗎？
比起廣告曝光本身，更重要的是設計成不會被誤認為一般的自然推薦。必須分離廣告候選與自然候選，在商品卡片上提供可立即識別的標示，並且分別管理廣告曝光規則與成效指標。

### 商品搜尋需要哪些資料庫索引？
正確答案會依實際查詢與資料分布而不同。狀態篩選與排序可檢討 B-tree 系列，全文搜尋可檢討 GIN 等倒排索引，相似字串搜尋可檢討 trigram 系列，並且必須透過執行計畫與負載測試確認效果。

### 搜尋品質應該用哪些指標評估？
應同時觀察無結果比例、搜尋結果點擊率、搜尋後加入購物車率與購買轉換率、搜尋詞修改率、缺貨曝光率。再結合 p95 延遲、逾時率、索引新鮮度，才能同時評估品質與效能。

### 搜尋日誌應該保存多久？
沒有適用於所有服務的單一期限。原文搜尋詞只應保留分析所需的最短期間，而長期趨勢最好以降低個人資料風險的彙整資料保存。保存目的、刪除週期、存取權限必須與個人資料處理方針及內部政策一致。

### 讓 AI 在實作前先提問，最重要的句子是什麼？
可以指示：「在開始實作之前，如果有我尚未決定且會影響結果的政策決定，請先提問；你自行設定的假設請另列清單標示。」之後必須將回答反映到政策文件、API 契約、測試條件中，才會有效果。

## Sources

- [公平交易委員會：對酷澎及CPLB以欺瞞方式招攬顧客行為的制裁](https://www.ftc.go.kr/www/selectBbsNttView.do?bordCd=3&key=12&nttSn=43448&pageIndex=1&pageUnit=10&rltnNttSn=46624&searchCnd=all&searchViolt=0604)
- [法律新聞：酷澎－公平交易委員會訴訟，Naver Shopping事件成為爭點](https://www.lawtimes.co.kr/news/articleView.html?idxno=218796)
- [國家法令資訊中心：關於標示、廣告公平化之法律](https://www.law.go.kr/LSW/lsInfoP.do?lsId=002011)
- [公平交易委員會線上案件處理：關於關鍵字廣告標示的議決2014-103](https://case.ftc.go.kr/ocp/co/openDocView.do?docCnvrMnNo=12808&docId=20221229104156671154&docTy=LTFR&id=OCPLTFR20140759018192)
- [公平交易委員會：對高價知名商品銷售平台違反標示廣告法及電子商務法行為的制裁](https://www.ftc.go.kr/www/selectBbsNttView.do?bordCd=3&key=12&nttSn=46006&pageIndex=2&pageUnit=10&rltnNttSn=37048&searchCnd=all&searchCtgry=01%2C02&searchKrwd=%EA%B4%91%EA%B3%A0&searchViolt=0609)
- [國家法令資訊中心：個人資料保護法](https://www.law.go.kr/LSW/lsInfoP.do?ancYnChk=0&lsId=011357)
- [Baymard Institute：資料驅動的電子商務UX最佳實務](https://baymard.com/learn/ecommerce-ux-best-practices)
- [Google Search Central：分頁與增量式頁面載入](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
- [PostgreSQL Documentation：全文搜尋](https://www.postgresql.org/docs/current/textsearch.html)
- [PostgreSQL Documentation：文字搜尋的偏好索引類型](https://www.postgresql.org/docs/current/textsearch-indexes.html)
- [PostgreSQL Documentation：pg_trgm](https://www.postgresql.org/docs/current/pgtrgm.html)

## Images

![結合AI網路、商品搜尋介面、政策檢查卡與分析儀表板的電商搜尋規劃圖](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjM1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--6c0b755d9bc5bce8a57d0306acd05a2302fe176e/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2021%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2002_29_49.webp)
![結合商品語意關聯、替代推薦與安全資料儲存的AI購物搜尋架構](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjM2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--7aa0dfb3a548f3bdfe5cf4f73b74b387fe8da178/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2021%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2002_32_48.webp)