大规模电子商务:一位软件工程师如何整理数百万个混乱的产品属性

大多数关于电商扩展的讨论都围绕着性主题:分布式搜索系统、实时库存管理、推荐算法。然而,背后潜藏着一个更为隐秘但更为顽固的问题:属性值的管理。这是一种在每个大型在线商店中都存在的技术噪声。

静默的问题:为何属性值会让一切变得复杂

产品属性对用户体验至关重要。它们推动筛选、比较和搜索排名。从理论上看,这很简单。但在现实中:原始值往往混乱不堪。

一个简单的例子可能是:“XL”、“Small”、“12cm”、“Large”、“M”、“S”。颜色?“RAL 3020”、“Crimson”、“Red”、“Dark Red”。材质?“Steel”、“Carbon Steel”、“Stainless”、“Stainless Steel”。

单独来看,这些不一致似乎无害。但当你将其乘以超过300万的SKU,每个SKU拥有数十个属性时——问题就变成系统性的问题。筛选器表现得难以预测。搜索引擎的相关性下降。客户体验变得缓慢且令人沮丧。而在后台,团队成员被手动数据清理所困。

Zoro的一位软件工程师正面临着这个挑战:一个容易被忽视,但影响每个产品页面的问题。

通向智能自动化而不失控的路径

第一个原则很明确:不要使用黑箱AI。这类系统难以信任、调试或扩展。

因此,开发了一套混合管道,能够:

  • 保持可解释性
  • 具有可预测性
  • 实际可扩展
  • 可由人类控制

结果结合了现代语言模型的上下文理解能力与固定规则和控制措施。用引导框架的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方案,规模更大。智能需要引导框架。
  • 上下文极大提升语言模型的准确性。
  • 离线任务对吞吐量和鲁棒性至关重要。
  • 人工覆盖机制建立信任和接受度。
  • 干净的输入是可靠输出的基础。

结论

排序属性值看似简单,但当涉及数百万产品时,变成了真正的挑战。

通过结合语言模型的智能、明确的规则、上下文理解和人工控制,将一个复杂的隐藏问题转变为一个干净、可扩展的系统。

这提醒我们,许多最大的成功都源自解决那些乏味的问题——那些容易被忽视,但在每个产品页面上都存在的问题。

VON-10.63%
查看原文
此页面可能包含第三方内容,仅供参考(非陈述/保证),不应被视为 Gate 认可其观点表述,也不得被视为财务或专业建议。详见声明
  • 赞赏
  • 评论
  • 转发
  • 分享
评论
0/400
暂无评论
交易,随时随地
qrCode
扫码下载 Gate App
社群列表
简体中文
  • بالعربية
  • Português (Brasil)
  • 简体中文
  • English
  • Español
  • Français (Afrique)
  • Bahasa Indonesia
  • 日本語
  • Português (Portugal)
  • Русский
  • 繁體中文
  • Українська
  • Tiếng Việt