大型電子商務:一位軟體工程師如何整理數百萬個雜亂的產品屬性

大多數有關電子商務擴展的討論都圍繞著性話題:分散式搜尋系統、即時庫存管理、推薦演算法。然而,背後潛藏著一個較為沉默但更棘手的問題:屬性值的管理。這是一種在每個大型線上商店中都存在的技術雜訊。

靜默問題:為何屬性值會讓一切變得複雜

產品屬性對於用戶體驗至關重要。它們推動篩選、比較與搜尋排名。理論上這很簡單,但現實中:原始值卻是雜亂無章的。

一個簡單的例子可能是:「XL」、「Small」、「12cm」、「Large」、「M」、「S」。顏色?「RAL 3020」、「Crimson」、「Red」、「Dark Red」。材質?「Steel」、「Carbon Steel」、「Stainless」、「Stainless Steel」。

單獨看這些不一致性似乎無害,但當你將其擴展到超過300萬個SKU,每個有數十個屬性時——問題就成系統性了。篩選器行為變得難以預測。搜尋引擎的相關性下降。客戶會遇到較慢且令人沮喪的瀏覽體驗。而在後端,團隊成員則陷入手動資料清理的泥沼。

Zoro的一位軟體工程師正面臨這個挑戰:一個容易被忽視,但卻影響每個產品頁面的問題。

通往智能自動化而不失控的路徑

第一個原則很明確:不要黑箱式AI。這類系統難以信任、除錯或擴展。

因此,開發出一個混合流程,該流程:

  • 保持可解釋性
  • 可預測運作
  • 真正具備擴展性
  • 可由人員控制

結果是將現代語言模型的情境思考與固定規則與控制相結合。讓AI在導引下運作,而非失控。

架構概述:它們如何相互連結

整個處理流程在離線背景作業中運行,而非即時處理。這不是妥協——而是架構上的必要。

即時流程聽起來誘人,但會導致:

  • 不可預測的延遲
  • 脆弱的依賴關係
  • 高昂的計算峰值
  • 操作上的脆弱性

相反,離線處理能提供:

  • 高吞吐量:處理數百萬資料而不影響線上系統
  • 韌性:錯誤不會影響用戶流量
  • 成本控制:在低流量時段安排計算
  • 隔離:語言模型的延遲不會影響產品頁
  • 一致性:更新原子性且可預測

架構流程如下:

  1. 產品資料來自PIM系統
  2. 提取作業抓取原始值與上下文
  3. 傳送至AI排序服務
  4. 更新後的文件存入MongoDB
  5. 出站同步更新原始系統
  6. Elasticsearch與Vespa同步排序資料
  7. API將所有內容連結到客戶界面

四層解決方案

第一層:資料預處理

在應用智慧前,先進行明確的前置處理:去除空白、去重、將類別麵包屑轉成結構化字串、移除空值。

這看似基本,但大幅提升AI表現。垃圾進,垃圾出——在此規模下,小錯誤可能演變成大問題。

第二層:帶有上下文的智能排序

語言模型不僅是排序工具,它會思考值的意義。

服務端收到:

  • 清洗過的屬性值
  • 類別元資料
  • 屬性定義

利用這些上下文,模型能理解:

  • 「電壓」在電動工具中應為數值
  • 「尺寸」在服飾中遵循已知的序列
  • 「顏色」可能遵循RAL標準
  • 「材質」具有語義關聯

模型回傳:

  • 按邏輯排序的值
  • 精煉的屬性名稱
  • 一個決策:是用確定排序還是依上下文排序

第三層:確定性備援

並非所有屬性都需要智慧。數值範圍、單位值與簡單集合適合用:

  • 更快的處理速度
  • 可預測的輸出
  • 更低的成本
  • 無歧義

流程會自動識別這些情況,並採用確定性邏輯,避免不必要的LLM調用。

第四層:人工覆蓋

每個類別都可以標記為:

  • LLM_SORT:由模型決定
  • MANUAL_SORT:由人決定

這個雙軌系統讓人員可以做最終決策,同時讓智慧負責繁重工作,也建立信任——商家可以隨時覆蓋模型。

從混亂到清晰:實務成果

流程將雜亂的原始資料轉換為:

屬性 輸入值 排序後輸出
尺寸 XL, Small, 12cm, Large, M, S Small, M, Large, XL, 12cm
顏色 RAL 3020, Crimson, Red, Dark Red Red, Dark Red, Crimson, Red (RAL 3020)
材質 Steel, Carbon Steel, Stainless, Stainless Steel Steel, Stainless Steel, Carbon Steel
數值 5cm, 12cm, 2cm, 20cm 2cm, 5cm, 12cm, 20cm

這些範例展現了情境理解與明確規則的結合。

全鏈條的持久化與控制

所有結果都直接存入產品的MongoDB。MongoDB成為唯一資料來源,用於:

  • 排序屬性值
  • 精煉屬性名稱
  • 類別專屬排序標籤
  • 產品專屬排序順序

這讓檢查、覆蓋、重新處理類別與同步變得更容易。

排序後,資料流入:

  • Elasticsearch,用於關鍵字搜尋
  • Vespa,用於語義與向量搜尋

確保篩選器按邏輯排序,產品頁面呈現一致屬性,搜尋引擎能更精確地排名。

為何不用即時處理?

即時處理意味著:

  • 直播請求的延遲不可預測
  • 需要更高的計算成本來即時產出
  • 系統間的依賴更脆弱
  • 操作複雜且易出錯

離線作業則提供:

  • 超大規模的高效能
  • 非同步LLM調用,不影響線上
  • 強健的重試邏輯
  • 人工檢查的空間
  • 可預測的計算結果

唯一的折衷是資料傳遞與顯示之間的微小延遲,但這在大規模上帶來的資料一致性,遠勝於即時的便利。

可衡量的成效

此方案帶來:

  • 超過300萬SKU的屬性排序一致性
  • 透過確定性備援實現數值排序的可預測性
  • 商業控制:手動標記
  • 更乾淨的產品頁與直觀篩選
  • 改善搜尋相關性與排名
  • 提升用戶信任與轉換率

這不僅是技術上的勝利,更是用戶體驗與商業成果的提升。

給電商軟體工程師的關鍵啟示

  • 混合流程超越純AI,規模更大。智慧需要導引。
  • 上下文大幅提升語言模型的準確性。
  • 离線作業是高吞吐與韌性的關鍵。
  • 人工覆蓋建立信任與接受度。
  • 整潔的輸入是可靠輸出的基礎。

總結

屬性值排序聽起來很簡單,但當涉及數百萬產品時,卻是一個真正的挑戰。

結合語言模型智慧、明確規則、上下文理解與人工控制,將一個複雜且隱藏的問題轉化為一個乾淨且可擴展的系統。

這提醒我們,最大的成功往往來自解決那些乏味、容易被忽視的問題——那些在每個產品頁面都會出現的細節。

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