我如何利用AI大规模修复电子商务中不一致的属性值

当人们谈论扩展电子商务时,他们关注的是重大的工程挑战:分布式搜索、实时库存、推荐引擎和结账优化。但在所有这些之下,存在着一个更安静、更持久的问题,几乎每个零售商都在与之斗争:属性值。

属性是产品发现的支柱。它们支持筛选器、比较、搜索排名和推荐逻辑。但在实际目录中,属性值很少是干净的。它们不一致、重复、格式错误或语义模糊。

以简单的尺寸为例。你可能会看到:

代码

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

或颜色:

代码

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

单独来看,这些不一致看起来无害。但将它们乘以超过300万个SKU,每个都有数十个属性,问题就变成了系统性的。筛选器的行为不可预测,搜索引擎失去相关性,商品专员淹没在手动清理中,产品发现对客户来说变得更慢、更令人沮丧。

这就是我作为Zoro的全栈软件工程师所面临的挑战,一个容易被忽视但影响每个产品页面的问题。

我的方法:混合AI遇上确定性

我不想要一个神秘的黑盒AI,它只是简单地对事物进行排序。这样的系统难以信任、调试或扩展。相反,我的目标是建立一个这样的管道:

• 可解释
• 可预测
• 可扩展
• 可由人控制

结果是一个混合AI管道,将LLM的上下文推理与明确的规则和商品专员控制相结合。它在需要时智能行动,但始终保持可预测性。这是带有护栏的AI,而不是失控的AI。

后台作业:为吞吐量而构建

所有属性处理都在离线后台作业中进行,而不是实时进行。这不是妥协;这是一个战略性的架构选择。

实时管道听起来很吸引人,但在电子商务规模上,它们会带来:

• 不可预测的延迟
• 脆弱的依赖关系
• 昂贵的计算峰值
• 操作脆弱性

另一方面,离线作业为我们提供了:

• 高吞吐量:在不影响实时系统的情况下处理大批量
• 弹性:故障从不影响客户流量
• 成本控制:可以在低流量时段安排计算
• 隔离:LLM延迟从不影响产品页面
• 一致性:更新是原子的和可预测的

在处理数百万个SKU时,将面向客户的系统与数据处理管道分开是至关重要的。

清理和规范化

在对数据使用AI之前,我运行了一个清晰的预处理步骤来消除噪音和混乱。这一步可能听起来简单,但它大大改善了LLM的推理。

清理管道包括:

• 修剪空格
• 删除空值
• 去重值
• 将类别面包屑扁平化为上下文字符串

这确保了LLM接收到干净、清晰的输入,这是获得一致结果的关键。垃圾进,垃圾出。在这种规模下,即使是小错误也可能导致更大的问题。

带上下文的LLM服务

LLM不仅仅是按字母顺序对值进行排序。它在对它们进行推理。

该服务接收:

• 清理后的属性值
• 类别面包屑
• 属性元数据

有了这个上下文,模型可以理解:

• 电动工具中的"电压"是数字
• 服装中的"尺寸"遵循已知的进程
• 油漆中的"颜色"可能遵循RAL标准
• 硬件中的"材料"具有语义关系

模型返回:

• 排序的值
• 精炼的属性名称
• 一个决策:确定性或上下文排序

这让管道可以处理不同的属性类型,而无需为每个类别硬编码规则。

确定性后备

并非每个属性都需要AI。

事实上,许多属性通过确定性逻辑处理得更好。

数字范围、基于单位的值和简单集合通常受益于:

• 更快的处理
• 可预测的排序
• 更低的成本
• 零歧义

管道自动检测这些情况并对它们使用确定性逻辑。这保持了系统的效率并避免了不必要的LLM调用。

手动与LLM标记

商品专员仍然需要控制,特别是对于业务敏感的属性。

因此,每个类别可以标记为:

• LLM_SORT — 让模型决定
• MANUAL_SORT — 商品专员定义顺序

这种双标签系统让人们做出最终决定,而AI完成大部分工作。它还建立了信任,因为商品专员可以在需要时覆盖模型,而不会破坏管道。

持久性和控制

所有结果都直接存储在产品MongoDB数据库中,保持架构简单和集中。

MongoDB成为单一的操作存储:

• 排序的属性值
• 精炼的属性名称
• 类别级排序标签
• 产品级sortOrder字段

这使得审查更改、覆盖值、重新处理类别以及与其他系统同步变得容易。

搜索集成

一旦排序,值流入:

• Elasticsearch用于关键字驱动的搜索
• Vespa用于语义和基于向量的搜索

这确保了:

• 筛选器以逻辑顺序出现
• 产品页面显示一致的属性
• 搜索引擎更准确地对产品进行排名
• 客户可以更轻松地浏览类别

搜索是属性排序最明显的地方,也是一致性最重要的地方。

架构概述

为了在数百万个SKU上实现这一点,我设计了一个围绕后台作业、AI推理和搜索集成构建的模块化管道。下面的架构图捕获了完整的流程:

• 产品数据从产品信息系统进入
• 属性提取作业提取属性值和类别上下文
• 这些被传递给AI排序服务
• 更新的产品文档被写入产品MongoDB
• 出站同步作业用排序顺序更新产品信息系统
• Elasticsearch和Vespa同步作业将排序后的数据推送到各自的搜索系统
• API服务将Elasticsearch和Vespa连接到客户端应用程序

这个流程确保每个属性值,无论是由AI排序还是手动设置,都反映在搜索、商品推销和客户体验中。

解决方案的实际应用

以下是杂乱值如何转换的:

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

这些例子展示了管道如何将上下文推理与明确的规则相结合,以创建干净、易于理解的序列。

为什么使用离线作业而不是实时处理?

实时处理会带来:

• 不可预测的延迟
• 更高的计算成本
• 脆弱的依赖关系
• 操作复杂性

离线作业为我们提供了:

• 批处理效率
• 异步LLM调用
• 重试逻辑和错误队列
• 人工审查窗口
• 可预测的计算支出

权衡是数据摄取和显示之间的小延迟,但好处是规模上的一致性,这是客户更看重的。

影响

结果是显著的:

• 超过300万个SKU的一致属性排序
• 通过确定性后备实现可预测的数字排序
• 通过手动标记实现商品专员控制
• 更干净的产品页面和更直观的筛选器
• 改进的搜索相关性
• 更高的客户信心和转化率

这不仅是技术上的胜利;它也是用户体验和收入的胜利。

经验教训

• 混合管道在规模上优于纯AI。护栏很重要。
• 上下文显著提高LLM准确性
• 离线作业对于吞吐量和弹性至关重要
• 人工覆盖机制建立信任和采用
• 干净的输入是可靠AI输出的基础

最后的想法

对属性值进行排序听起来很简单,但当你必须为数百万种产品做这件事时,它就成为了一个真正的挑战。

通过将LLM智能与明确的规则和商品专员控制相结合,我将一个复杂的、隐藏的问题转变为一个干净的、可扩展的系统。

它提醒我们,一些最大的胜利来自解决无聊的问题,那些容易被忽视但在每个产品页面上都会出现的问题。

\n \n \n