我如何使用AI大規模修正電子商務中不一致的屬性值

當人們談論電子商務的規模化時,他們關注的是重大工程挑戰:分散式搜尋、即時庫存、推薦引擎和結帳最佳化。但在這一切之下,存在著一個更安靜、更持久的問題,幾乎每個零售商都在為之掙扎:屬性值。

屬性是產品發現的骨幹。它們驅動篩選器、比較、搜尋排名和推薦邏輯。但在實際目錄中,屬性值很少是乾淨的。它們不一致、重複、格式錯誤或語義模糊。

以簡單的尺寸為例。你可能會看到:

Code

["XL", "Small", "12cm", "Large", "M", "S"]

或顏色:

Code

["RAL 3020", "Crimson", "Red", "Dark Red"]

單獨來看,這些不一致似乎無害。但將它們乘以超過300萬個SKU,每個SKU都有數十個屬性,問題就變得系統性了。篩選器行為變得不可預測,搜尋引擎失去相關性,商品管理人員淹沒在手動清理工作中,產品發現對客戶來說變得更慢、更令人沮喪。

這就是我作為Zoro的全端軟體工程師所面臨的挑戰,一個容易被忽視但影響每個產品頁面的問題。

我的方法:混合AI結合確定性

我不想要一個神秘的黑盒子AI來簡單地分類事物。這樣的系統難以信任、除錯或擴展。相反,我的目標是建立一個具有以下特點的流程:

• 可解釋的
• 可預測的
• 可擴展的
• 可由人類控制的

結果是一個混合AI流程,它將LLM的情境推理與清晰的規則和商品管理人員控制相結合。它在需要時表現得很聰明,但始終保持可預測性。這是有護欄的AI,而不是失控的AI。

背景作業:為吞吐量而建

所有屬性處理都在離線背景作業中進行,而不是即時進行。這不是妥協;這是一個策略性的架構選擇。

即時流程聽起來很吸引人,但在電子商務規模下,它們會帶來:

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

另一方面,離線作業為我們帶來了:

• 高吞吐量:在不影響線上系統的情況下處理大量批次
• 韌性:失敗永遠不會影響客戶流量
• 成本控制:可以在低流量時段安排運算
• 隔離:LLM延遲永遠不會影響產品頁面
• 一致性:更新是原子性和可預測的

在處理數百萬個SKU時,將面向客戶的系統與資料處理流程分開是至關重要的。

清理與標準化

在對資料使用AI之前,我執行了一個清晰的預處理步驟來消除雜訊和混亂。這一步驟聽起來很簡單,但它大大改善了LLM的推理能力。

清理流程包括:

• 修剪空白
• 移除空值
• 去重複值
• 將類別麵包屑扁平化為情境字串

這確保了LLM接收到乾淨、清晰的輸入,這是獲得一致結果的關鍵。垃圾進,垃圾出。在這種規模下,即使是小錯誤也可能導致更大的問題。

帶情境的LLM服務

LLM不僅僅是按字母順序排序值。它在對它們進行推理。

該服務接收:

• 清理後的屬性值
• 類別麵包屑
• 屬性元資料

有了這個情境,模型可以理解:

• 電動工具中的「Voltage」是數字
• 服裝中的「Size」遵循已知的進程
• 油漆中的「Colour」可能遵循RAL標準
• 五金中的「Material」具有語義關係

模型返回:

• 排序後的值
• 精煉的屬性名稱
• 一個決定:確定性或情境排序

這使流程可以處理不同的屬性類型,而無需為每個類別硬編碼規則。

確定性回退

並非每個屬性都需要AI。

事實上,許多屬性由確定性邏輯處理會更好。

數字範圍、基於單位的值和簡單集合通常受益於:

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

流程自動檢測這些情況並對它們使用確定性邏輯。這使系統保持高效並避免了不必要的LLM調用。

手動與LLM標記

商品管理人員仍然需要控制權,特別是對於業務敏感的屬性。

因此每個類別可以被標記為:

• LLM_SORT — 讓模型決定
• MANUAL_SORT — 商品管理人員定義順序

這種雙標記系統讓人們做出最終決定,而AI完成大部分工作。它還建立了信任,因為商品管理人員可以在需要時覆蓋模型而不破壞流程。

持久性與控制

所有結果直接儲存在Product MongoDB資料庫中,保持架構簡單和集中。

MongoDB成為以下內容的單一操作儲存:

• 排序後的屬性值
• 精煉的屬性名稱
• 類別級別的排序標籤
• 產品級別的sortOrder欄位

這使得審查更改、覆蓋值、重新處理類別和與其他系統同步變得容易。

搜尋整合

排序後,值流入:

• Elasticsearch用於關鍵字驅動的搜尋
• Vespa用於語義和向量搜尋

這確保了:

• 篩選器按邏輯順序出現
• 產品頁面顯示一致的屬性
• 搜尋引擎更準確地對產品進行排名
• 客戶可以更輕鬆地瀏覽類別

搜尋是屬性排序最明顯的地方,也是一致性最重要的地方。

架構概述

為了使這在數百萬個SKU中運作,我設計了一個圍繞背景作業、AI推理和搜尋整合建立的模組化流程。下面的架構圖捕捉了完整的流程:

• 產品資料從產品資訊系統進入
• 屬性提取作業提取屬性值和類別情境
• 這些被傳遞到AI排序服務
• 更新後的產品文件被寫入Product MongoDB
• 出站同步作業使用排序順序更新產品資訊系統
• Elasticsearch和Vespa同步作業將排序後的資料推送到各自的搜尋系統
• API服務將Elasticsearch和Vespa連接到客戶端應用程式

此流程確保每個屬性值,無論是由AI排序還是手動設定,都反映在搜尋、商品銷售和客戶體驗中。

解決方案實踐

以下是混亂值如何被轉換的:

| Attribute | Raw Values | Ordered Output | |----|----|----| | Size | XL, Small, 12cm, Large, M, S | Small, M, Large, XL, 12cm | | Color | RAL 3020, Crimson, Red, Dark Red | Red, Dark Red, Crimson, Red (RAL 3020) | | Material | Steel, Carbon Steel, Stainless, Stainless Steel | Steel, Stainless Steel, Carbon Steel | | Numeric | 5cm, 12cm, 2cm, 20cm | 2cm, 5cm, 12cm, 20cm |

這些範例展示了流程如何將情境推理與清晰規則相結合,以創建乾淨、易於理解的序列。

為什麼選擇離線作業而不是即時處理?

即時處理會帶來:

• 不可預測的延遲
• 更高的運算成本
• 脆弱的依賴關係
• 操作複雜性

離線作業為我們帶來:

• 批次效率
• 非同步LLM調用
• 重試邏輯和錯誤佇列
• 人工審查視窗
• 可預測的運算支出

權衡是資料擷取和顯示之間的小延遲,但好處是規模上的一致性,這是客戶更看重的。

影響

結果是顯著的:

• 超過300萬個SKU的一致屬性排序
• 通過確定性回退實現可預測的數字排序
• 通過手動標記實現商品管理人員控制
• 更乾淨的產品頁面和更直觀的篩選器
• 改善的搜尋相關性
• 更高的客戶信心和轉換率

這不僅僅是技術上的勝利;它也是使用者體驗和收入的勝利。

經驗教訓

• 混合流程在規模上優於純AI。護欄很重要。
• 情境顯著提高LLM準確性
• 離線作業對吞吐量和韌性至關重要
• 人工覆蓋機制建立信任和採用
• 乾淨的輸入是可靠AI輸出的基礎

最後的想法

排序屬性值聽起來很簡單,但當你必須為數百萬個產品執行時,它就成為一個真正的挑戰。

通過將LLM智慧與清晰規則和商品管理人員控制相結合,我將一個複雜、隱藏的問題轉化為一個乾淨、可擴展的系統。

這提醒我們,一些最大的勝利來自解決無聊的問題,那些容易被忽視但出現在每個產品頁面上的問題。

\n \n \n