基于AI的电子商务属性管理:我如何协调数百万产品数据

大多数电商平台都在谈论巨大的技术挑战:大规模搜索、实时库存、个性化推荐。但隐藏着一个几乎困扰每个零售商的问题:属性值的一致性。这些表面上看似无关紧要,但实际上是产品发现、筛选、比较和搜索相关性的基础。

在实际的产品目录中,状态非常混乱。尺寸信息如“XL”、“Small”、“12cm”、“Large”混杂在一起。颜色则以“RAL 3020”、“Crimson”、“Red”和“Dark Red”等多种方式记录。将这些不一致性乘以数百万个SKU和每个产品数十个属性,系统就会变得无法使用。筛选器表现得不可预测,搜索引擎的质量下降,客户在导航时感到沮丧。

大规模问题

作为Zoro的全栈工程师,我面临的正是这个任务:构建一个不仅管理这些属性,还能智能地结构化它们的系统。目标很简单,但实现复杂:提供超过300万SKU,具有一致、可追溯的属性值。

挑战在于:不能为每个类别都手动编写规则。需要一种既能“思考”,又能保持可控的方案。于是引入AI——不是作为黑箱解决方案,而是作为确定性逻辑的合作伙伴。

混合策略:AI与引导

我的方法截然不同:一种混合管道,将大型语言模型(LLM)智能与明确规则和交易控制结合起来。结果:可解释、可预测、可扩展且由人控制。

系统不在实时处理属性,而是在后台离线作业中处理。这听起来像妥协,但实际上是经过深思熟虑的架构决策,具有诸多优势:

  • 高吞吐量:处理海量数据,不影响实时系统
  • 可靠性:故障不会影响客户流量
  • 成本效益:在低峰时段进行计算
  • 隔离性:LLM延迟绝不影响产品页面
  • 一致性:更新原子性强、可预测

实时处理会带来不可预知的延迟、更高的成本和脆弱的依赖关系。离线作业提供了批量效率、异步调用和人工审核点。

准备工作:清洗优先

在让LLM处理属性之前,我会进行一个清洗步骤:

  • 去除空白字符
  • 删除空值
  • 去重
  • 将类别上下文转化为结构化字符串

这样,LLM获得的是干净、清晰的输入。垃圾输入,垃圾输出——在这个规模下,小错误也可能引发大问题。清洗是后续一切的基础。

AI服务:带有上下文的思考

LLM服务不仅仅接受原始值,还会提供:

  • 清洗后的属性
  • 类别面包屑(Breadcrumbs)
  • 属性元数据

借助这些上下文,模型能理解“Spannung”在电动工具中是数值型,“尺寸”在服装中遵循已知的递增关系,“颜色”可能符合RAL标准。模型返回:排序后的值、优化的属性名,以及是否需要确定性排序或上下文排序的决策。

这使得管道可以处理不同类型的属性,而无需为每个类别编写新规则。

智能回退:不是所有都用AI

并非所有属性都需要AI。数值范围、单位值和简单的数量更适合用确定性逻辑处理:

  • 处理速度快
  • 排序可预测
  • 成本低
  • 无歧义

管道会自动识别这些情况,优先使用规则,避免不必要的模型调用。这保证了系统的高效性。

商家控制

每个类别可以标记为:

  • LLM_SORT:由模型决定排序
  • MANUAL_SORT:由商家手动定义顺序

这种双重机制实现了真正的人为控制。AI完成大部分工作,最终决策由人做出。这增强了信任——商家可以覆盖模型,而不会中断整个流程。

持久化与同步

所有结果存入MongoDB的产品数据库——这是核心神经中枢,用于:

  • 排序属性
  • 优化的属性名
  • 类别相关的排序标签
  • 产品相关的sortOrder字段

然后,出站作业将数据同步到:

  • Elasticsearch,实现关键词搜索
  • Vespa,支持语义和向量搜索

筛选器按逻辑顺序出现,产品页面显示一致的属性,搜索引擎能更准确地排名产品。

从混乱到秩序:转变的过程

以下是系统在实际中的表现:

属性 原始输入 排序输出
尺寸 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

混乱的输入变成了逻辑清晰、一致的序列。

架构流程

整个管道遵循以下流程:

  1. 产品数据从PIM系统流入
  2. 提取作业收集属性和类别上下文
  3. AI排序服务智能处理
  4. MongoDB存储结果
  5. 出站作业同步回PIM
  6. Elasticsearch和Vespa同步任务将数据分发到搜索系统
  7. API服务连接搜索与客户页面

确保每个属性值都被保存——无论是由AI排序还是手动设置,都能在各处反映。

为什么不用实时?

实时管道虽然吸引人,但会带来:

  • 不可预知的延迟
  • 更高的计算峰值
  • 脆弱的依赖关系
  • 运营复杂性

离线作业提供了吞吐效率、容错能力和可预见的成本。唯一的缺点是数据采集到展示之间会有轻微延迟,但带来的好处是规模化的一致性,客户真正看重。

影响

该系统带来了可衡量的成果:

  • 超过300万SKU的排序一致性
  • 规则驱动的数值属性可预测性
  • 商家控制机制(手动标签)
  • 更清晰的产品页面,更直观的筛选
  • 改善的搜索相关性和转化率
  • 增强的客户信任

这不仅是技术上的胜利,更提升了用户体验和销售额。

关键启示

  • 混合优于纯AI:在大规模场景中,规则引导比单纯依赖智能更有效
  • 上下文为王:正确的环境极大提升LLM的准确性
  • 离线优于在线:追求吞吐和可靠性,而非实时
  • 人类掌控:覆盖机制建立真正的信任
  • 干净输入是基础:Garbage In,Garbage Out——先行清洗

结论

排序属性值看似简单,但在数百万产品中却是个真正的挑战。通过结合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)