當零售商談論擴展時，他們想到的是搜尋引擎、即時庫存和結帳優化。這些是可見的問題。但在其下潛藏著更棘手的問題：**屬性值，簡單來說就是不搭配**。在真實的產品目錄中，這些值很少保持一致。它們的格式各異，語義多義，或只是錯誤。而當你將這些問題乘以數百萬的產品，每個產品又有數十個屬性時，小小的煩惱就會演變成系統性的災難。## 問題：微不足道，卻在規模上變得狂妄舉幾個具體例子：- **尺寸**：「XL」、「Small」、「12cm」、「Large」、「M」、「S」——全都混在一起- **顏色**：「RAL 3020」、「Crimson」、「Red」、「Dark Red」——部分是標準色碼，部分是口語- **材質**：「Steel」、「Carbon Steel」、「Stainless」、「Stainless Steel」——冗餘且不清楚這些例子單獨看起來都無害。但一旦你處理超過3百萬個SKU，每個有數十個屬性，就會出現真正的問題：- 篩選器行為難以預測- 搜尋引擎的相關性下降- 客戶搜尋變成挫折- 團隊陷入手動資料清理的泥淖這就是幾乎每個大型電子商務目錄背後的沉默痛苦。## 方法：用導引規範的AI，而非混亂的演算法我不想要一個神祕的黑盒解決方案，能排序卻沒人懂。相反，我追求一個**混合管線**，它：- 保持可解釋- 可預測運作- 真正擴展- 人類能掌控結果：一個聰明思考但始終透明的AI。## 架構：離線作業取代即時瘋狂所有屬性處理都在背景進行——不是即時的。這不是臨時應急方案，而是一個**策略性設計決策**。即時管線聽起來誘人，但會導致：- 難以預測的延遲- 高昂的計算峰值- 脆弱的依賴關係- 操作上的混亂相反，離線作業提供：- 大量吞吐量 (在不影響即時系統的情況下處理海量資料)- 容錯能力 (故障永不影響客戶)- 成本控制 (在流量低谷時進行計算)- 一致性 (原子性、可預測的更新)將面向客戶的系統與資料處理分離，在這個規模下至關重要。## 流程：從雜亂到乾淨資料在AI處理資料之前，一個關鍵的**清理步驟**：- 修剪空白字符- 刪除空值- 移除重複- 將分類上下文格式化為乾淨的字串這確保LLM使用乾淨的輸入。原則很簡單：**垃圾進，垃圾出。** 在這個數量級下的小錯誤，日後會演變成大問題。## LLM服務：比排序更聰明LLM不會愚蠢地按字母排序，它會根據語境思考。它會接收：- 已清理的屬性值- 類別麵包屑- 屬性元資料藉由這些上下文，模型理解：- 「電壓」在電動工具中是數值型- 「尺寸」在服飾中遵循已知的階梯- 「顏色」可能遵循RAL標準- 「材質」具有語義關聯它會回傳：- 有序的值- 精煉的屬性名稱- 一個決策：確定性排序或由AI引導的排序這讓系統能處理不同屬性類型，而不需為每個分類單獨編碼。## 確定性備援：不是所有都需要AI許多屬性在沒有AI的情況下效果更佳：- 數值範圍 (5cm、12cm、20cm 自動排序)- 單位值- 簡單數量這些屬性提供：- 更快的處理速度- 可預測的排序- 更低的成本- 無歧義管線會自動識別這些情況，並使用確定性邏輯。這樣可以保持系統高效，避免不必要的LLM調用。## 人與機器：雙重控制零售商需要對關鍵屬性保持控制。因此，每個分類可以標記為：- **LLM_SORT**——模型決定排序- **MANUAL_SORT**——由商家定義排序這個系統分工合作：AI負責大部分，人工做最後決定。也建立信任，團隊可以在必要時禁用模型。## 基礎架構：簡單、集中、可擴展所有結果都存放在MongoDB資料庫——唯一的操作存儲：- 已排序的屬性值- 精煉的屬性名稱- 類別標籤- 產品專屬排序這讓變更、覆蓋值、重新處理分類、與其他系統同步都變得容易。## 搜尋整合：品質展現的舞台排序完成後，值會流入兩個搜尋資產：- **Elasticsearch** 用於關鍵字搜尋- **Vespa** 用於語義和向量搜尋確保：- 篩選器按邏輯順序出現- 產品頁面顯示一致的屬性- 搜尋引擎排名更精確- 客戶更容易在分類中導航在搜尋中，良好的屬性排序展現出來。## 成果：從混亂到清晰| 屬性 | 原始值 | 排序後輸出 ||----------|----------|-------------------|| 尺寸 | 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 |成效明顯：- 超過3百萬SKU的排序一致性- 預測性數值序列- 商家完整控制（標記）- 更直觀的篩選與更乾淨的頁面- 改善搜尋相關性- 提升轉換率## 核心啟示1. **混合優於純AI**：導引規範在擴展中至關重要2. **語境是黃金**：大幅提升模型準確性3. **離線處理是必要**：確保吞吐量與可靠性4. **人類控制建立信任**：覆蓋機制不是缺陷，是特點5. **乾淨輸入是基礎**：資料清理不可省略屬性值排序看似微不足道，但在數百萬產品中卻是巨大挑戰。結合LLM智慧、明確規則與商家控制，打造出一個將看不見的混亂轉化為可擴展清晰的系統。
看不見的混亂：不一致的產品屬性如何大規模破壞電子商務
當零售商談論擴展時，他們想到的是搜尋引擎、即時庫存和結帳優化。這些是可見的問題。但在其下潛藏著更棘手的問題：屬性值，簡單來說就是不搭配。在真實的產品目錄中，這些值很少保持一致。它們的格式各異，語義多義，或只是錯誤。而當你將這些問題乘以數百萬的產品，每個產品又有數十個屬性時，小小的煩惱就會演變成系統性的災難。
問題：微不足道，卻在規模上變得狂妄
舉幾個具體例子：
這些例子單獨看起來都無害。但一旦你處理超過3百萬個SKU，每個有數十個屬性，就會出現真正的問題：
這就是幾乎每個大型電子商務目錄背後的沉默痛苦。
方法：用導引規範的AI，而非混亂的演算法
我不想要一個神祕的黑盒解決方案，能排序卻沒人懂。相反，我追求一個混合管線，它：
結果：一個聰明思考但始終透明的AI。
架構：離線作業取代即時瘋狂
所有屬性處理都在背景進行——不是即時的。這不是臨時應急方案，而是一個策略性設計決策。
即時管線聽起來誘人，但會導致：
相反，離線作業提供：
將面向客戶的系統與資料處理分離，在這個規模下至關重要。
流程：從雜亂到乾淨資料
在AI處理資料之前，一個關鍵的清理步驟：
這確保LLM使用乾淨的輸入。原則很簡單：垃圾進，垃圾出。 在這個數量級下的小錯誤，日後會演變成大問題。
LLM服務：比排序更聰明
LLM不會愚蠢地按字母排序，它會根據語境思考。
它會接收：
藉由這些上下文，模型理解：
它會回傳：
這讓系統能處理不同屬性類型，而不需為每個分類單獨編碼。
確定性備援：不是所有都需要AI
許多屬性在沒有AI的情況下效果更佳：
這些屬性提供：
管線會自動識別這些情況，並使用確定性邏輯。這樣可以保持系統高效，避免不必要的LLM調用。
人與機器：雙重控制
零售商需要對關鍵屬性保持控制。因此，每個分類可以標記為：
這個系統分工合作：AI負責大部分，人工做最後決定。也建立信任，團隊可以在必要時禁用模型。
基礎架構：簡單、集中、可擴展
所有結果都存放在MongoDB資料庫——唯一的操作存儲：
這讓變更、覆蓋值、重新處理分類、與其他系統同步都變得容易。
搜尋整合：品質展現的舞台
排序完成後，值會流入兩個搜尋資產：
確保：
在搜尋中，良好的屬性排序展現出來。
成果：從混亂到清晰
成效明顯：
核心啟示
屬性值排序看似微不足道，但在數百萬產品中卻是巨大挑戰。結合LLM智慧、明確規則與商家控制，打造出一個將看不見的混亂轉化為可擴展清晰的系統。