用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)