用AI解決大規模電商產品屬性混亂的實踐路徑

當人們討論電商規模化時,總是聚焦在分布式搜尋、庫存、推薦引擎這些看似宏大的技術挑戰。但真正讓每個電商平台頭疼的,往往是最基礎的問題:產品屬性值的不一致

屬性值驅動著整個產品發現體系。它們支撐著篩選、對比、搜尋排名和推薦邏輯。然而在真實的商品目錄中,屬性值很少是乾淨的。重複、格式混亂、語義模糊才是常態。

看看"尺寸"這樣看似簡單的屬性:[“XL”, “Small”, “12cm”, “Large”, “M”, “S”]

再看"顏色":[“RAL 3020”, “Crimson”, “Red”, “Dark Red”]

單看這些混亂似乎沒問題,但當你有300萬+ SKU,每個SKU包含數十個屬性時,問題就變成了系統級挑戰。搜尋變得混亂,推薦失效,運營被淹沒在手工修正中,使用者體驗一路下滑。

打破黑盒思維:混合智能系統的設計理念

面對這個難題,關鍵是避免陷入"黑盒AI"的陷阱——那種神祕地把東西排序,沒人能理解或控制的系統。

正確的做法是構建一個管道,具備這樣的特性:

  • 可解釋性強
  • 行為可預測
  • 能夠規模化運行
  • 接受人工干預

最終的解決方案是一個混合AI管道:LLM的上下文理解能力配合明確的規則和人工控制。它在必要時聰明運作,但始終保持可控。這是有護欄的AI,而非失控的AI。

離線處理:規模化的建築基礎

所有屬性處理都在後台離線任務中執行,不走即時路徑。這不是妥協,而是策略性的架構決策。

即時管道聽起來很誘人,但在電商規模下會導致:

  • 不可預測的延遲波動
  • 脆弱的依賴關係鏈
  • 計算成本尖峰
  • 運維的易碎性

而離線任務提供的是:

  • 高吞吐量:海量資料批次處理,客戶系統零影響
  • 抗擊能力:故障永遠觸及不了用戶流量
  • 成本可控:計算可在低谷期調度
  • 隔離保護:LLM延遲完全獨立於商品頁面
  • 原子一致性:更新完全可預測和同步

在處理千萬級SKU時,客戶系統和資料處理管道的隔離至關重要。

資料清洗:投入產出比最高的一步

在應用AI之前,需要進行嚴格的預處理,這一步看起來簡單但效果顯著。

清洗管道包括:

  • 剔除首尾空格
  • 移除空值
  • 去重
  • 將分類路徑簡化為結構化字串

這確保了LLM收到的是乾淨、清晰的輸入。在大規模系統中,即使小的噪音也會後期爆炸成大問題。垃圾進→垃圾出。這個基本法則在百萬級資料面前更顯殘酷。

LLM服務的上下文賦能

LLM不是簡單地字母排序屬性值。它真正理解它們的含義。

這個服務接收:

  • 清洗後的屬性值
  • 分類資訊(麵包屑)
  • 屬性元資料

有了這些上下文,模型可以理解:

  • 電動工具中的"電壓"應按數值排序
  • 衣服中的"尺寸"遵循可預測的遞進(S→M→L→XL)
  • 塗料中的"顏色"可能使用RAL標準(如RAL 3020這類編碼)
  • 硬體中的"材料"存在語義關係(鋼→不銹鋼→碳鋼)

模型返回的是:

  • 排序後的值序列
  • 完善的屬性名稱
  • 一個決策標記:使用確定性排序還是上下文感知排序

這讓管道能處理多種屬性類型,而無需為每個分類硬編碼規則。

確定性回退:知道什麼時候不需要AI

並非每個屬性都需要AI。事實上很多屬性用確定性邏輯處理效果更佳。

數值範圍、單位化的值、簡單集合往往受益於:

  • 更快的處理速度
  • 完全可預測的排序
  • 更低的成本
  • 零歧義

管道會自動識別這些情況並應用確定性邏輯。這保持了系統的高效,避免了不必要的LLM調用。

權力平衡:商家標籤系統

商家需要保留控制權,特別是對關鍵屬性。因此每個分類可以被標記為:

  • LLM_SORT — 讓模型決策
  • MANUAL_SORT — 商家手工定義順序

這個雙標籤系統讓人類掌握最終話語權,同時AI負責大部分工作。它還建立了信任——商家知道自己可以隨時覆蓋模型決策而無需中斷管道。

資料持久化:MongoDB作為單一事實源

所有結果直接寫入Product MongoDB,架構保持簡潔集中。MongoDB成為以下內容的唯一運營存儲:

  • 排序後的屬性值
  • 完善的屬性名稱
  • 分類級排序標籤
  • 商品級排序欄位

這使得變更審計、值覆蓋、分類重處理和與其他系統的同步都變成了直接操作。

搜索層的閉環:從資料到發現

排序完成後,值流向:

  • Elasticsearch — 關鍵詞驅動搜尋
  • Vespa — 語義和向量化搜尋

這確保了:

  • 篩選選項以邏輯順序出現
  • 商品頁面顯示一致的屬性
  • 搜索引擎更精準地排序結果
  • 使用者瀏覽分類變得直觀流暢

屬性排序的威力最直觀地體現在搜尋中,一致性在這裡最關鍵。

系統全景:從原始資料到使用者介面

為了在數百萬SKU上運行這套系統,我設計了一條圍繞後台任務、AI推理和搜尋整合的模組化管道:

資料流向

  • 商品資料源自商品資訊系統
  • 屬性提取任務拉取屬性值和分類上下文
  • 這些被送往AI排序服務
  • 更新後的商品文件寫入Product MongoDB
  • 出站同步任務將排序結果回寫到商品資訊系統
  • Elasticsearch和Vespa同步任務分別更新各自的搜尋索引
  • API服務連接搜尋引擎與客戶端應用

這個流程確保每個屬性值——無論來自AI排序還是手工設定——都反映在搜尋、貨架管理和最終的客戶體驗中。

轉換的實際效果

混亂的原始值是如何被轉化的:

屬性 原始混亂值 排序輸出
尺寸 XL, Small, 12cm, Large, M, S Small, M, Large, XL, 12cm
顏色 RAL 3020, Crimson, Red, Dark Red Red, Dark Red, Crimson, RAL 3020
材料 Steel, Carbon Steel, Stainless, Stainless Steel Steel, Stainless Steel, Carbon Steel
數值 5cm, 12cm, 2cm, 20cm 2cm, 5cm, 12cm, 20cm

這些例子展示了管道如何將上下文思維與清晰規則結合,生成乾淨、易理解的序列。

為什麼選擇離線而非即時?

如果採用即時處理,會引入:

  • 不可預測的延遲波動
  • 更高的計算成本
  • 脆弱的依賴鏈
  • 運維複雜度爆炸

而離線任務帶來的是:

  • 批次處理效率
  • 非同步LLM調用
  • 重試邏輯和死信佇列
  • 人工審核窗口
  • 完全可預測的計算成本

代價是資料攝入到顯示間的輕微延遲,但收益是大規模的一致性——這是客戶真正看重的。

業務成效

結果相當顯著:

  • 300萬+SKU的屬性排序達到一致性
  • 透過確定性回退的可預測數值排序
  • 商家透過手工標籤的細粒度控制
  • 更乾淨的商品頁面和直觀的篩選
  • 搜索相關性提升
  • 使用者信任度和轉化率上升

這不僅是技術勝利,更是用戶體驗和收入的勝利。

核心啟示

  • 混合管道在規模下優於純AI方案。護欄很重要。
  • 上下文顯著提升LLM準確性
  • 離線任務是吞吐量和容錯能力的基石
  • 人工覆蓋機制建立信任和接納度
  • 乾淨輸入是可靠AI輸出的基礎

結語

屬性值排序聽起來很簡單,但當需要為百萬級商品處理時,就成了真正的難題。透過將LLM的智能與清晰規則和商家控制相結合,把這個隱形但普遍的問題轉化為一個乾淨、可擴展的系統。

這是一個提醒:最大的勝利往往來自解決那些容易被忽視的無聊問題——那些每天出現在每個商品頁面上的問題。

查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)