混合式AI架構如何一致管理數百萬個產品屬性

隱藏的電商擴展問題

大多數人在談論電商擴展時，會提到分散式搜尋和推薦引擎。但在表面之下，潛藏著一個更棘手、常被忽視的問題：產品目錄中屬性值的管理。當SKU超過300萬時，這很快就會變成系統性問題。

屬性值是產品發現的基礎。它們推動篩選、比較和搜尋排名。但在實務中，它們是碎片化的：「XL」、「Small」、「12cm」和「Large」混雜在一個欄位中。或是顏色如「RAL 3020」、「Crimson」、「Red」和「Dark Red」沒有一致的結構。將這些不一致性乘以每個產品數十個屬性，問題就呈指數級擴大。

篩選行為變得難以預測，搜尋的相關性降低，客戶導航變得令人沮喪。同時，商家也陷入手動資料清理的泥淖。

解決方案：具有控制機制的智慧混合管線

不是用一個隨意排序資料的黑箱式AI，而是建立一個由三個支柱支撐的架構：

• 可解釋性：每個決策都可追溯
• 可預測性：系統行為一致
• 人為控制：商家可以手動設定關鍵屬性

結果是一個結合LLM智慧、明確規則和資料持久化的混合管線。它能智能運作，但仍可控——是有導引的AI，而非失控的AI。

離線處理取代即時管線

一個關鍵的設計決策是選擇在背景作業中處理，而非用即時系統。這聽起來像是折衷，但卻是策略性地合理：

即時處理意味著：

• 不可預測的延遲
• 脆弱的系統依賴
• 高昂的運算峰值
• 操作上的複雜性

而離線作業則提供：

• 大量吞吐量，不影響用戶流量
• 韌性：故障不會影響即時系統
• 成本控制：可排程處理
• 與LLM延遲隔離
• 原子性、可預測的更新

在百萬SKU規模下，將用戶相關系統與資料處理管線分離是關鍵。

具有持久性與一致性的架構

整個資料持久化透過MongoDB作為中心操作存儲：

• 屬性提取：第一個作業提取原始值和類別上下文
• AI服務：LLM接收清理後的資料與上下文資訊(類別麵包屑、元資料)
• 確定性備援：數值範圍和簡單集合自動識別並依規則排序
• 持久化：排序後的值、優化的屬性名稱和排序標籤存入MongoDB
• 搜尋整合：更新後的資料流入Elasticsearch (關鍵字搜尋)和Vespa (語意搜尋)

這種持久化結構方便進行檢查、覆蓋和與其他系統的同步。

混合控制：AI與商家決策的結合

並非所有屬性都需要AI智慧。因此，每個類別都可以標記為：

• LLM_SORT：模型決定排序
• MANUAL_SORT：商家手動設定順序

這個雙標籤系統建立了信任。人類保持對關鍵屬性的控制，而AI則負責例行工作——且不影響管線運作。

資料清理作為基礎

在應用AI之前，進行一個關鍵的預處理步驟：

• 修剪空白
• 移除空值
• 去除重複
• 標準化類別上下文

這些看似簡單的清理，大幅提升了LLM的準確性。乾淨的輸入帶來一致的結果——這是在大規模運作中一個基本原則。

實務中的轉換

該管線將混亂的原始資料轉換為結構化輸出：

商業影響

結果相當顯著：

• 超過3M+ SKU的屬性排序一致
• 透過確定性邏輯實現數值排序
• 改善搜尋相關性
• 產品頁面篩選更直觀
• 提升用戶信任與轉換率

這不僅是技術勝利，更是用戶體驗與營收的提升。

核心結論

• 混合系統勝過純AI：導引規則在大規模運作中至關重要
• 上下文為王：更好的上下文大幅提升LLM效果
• 離線架構創造韌性：背景作業是吞吐量的基石
• 持久化不失控：人為覆蓋機制建立信任
• 乾淨資料=可靠輸出：資料品質決定AI成敗

總結

排序屬性值聽起來很簡單，但在數百萬產品中卻成為真正的挑戰。結合LLM智慧、明確規則、持久化與商家控制，建立了一個能優雅解決複雜、隱藏問題的系統。這提醒我們，最大的成功往往來自解決那些乏味、被忽視的問題——那些在每個產品頁面都會產生影響的問題。