Real-Time Retail Intelligence: Building E-Commerce Recommendations with Lakebase and AI Search on Databricks
TL;DR · AI 摘要
Real-Time Retail Intelligence: Building E-Commerce Recommendations with Lakebase and AI Search on Databricks Databricks...
核心要点
- 主题聚焦:Real-Time Retail Intelligence: Building E-Commer
- 来源:Databricks,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
实时零售智能:在 Databricks 上使用 Lakebase 和 AI Search 构建电商推荐系统 | Databricks 博客
跳至主要内容
零售与消费品
2026年10月2日
实时零售智能:在 Databricks 上使用 Lakebase 和 AI Search 构建电商推荐系统
一家领先的时尚电商平台如何通过 Databricks 数据智能平台,为数百万用户实现低延迟的个性化产品推荐。
作者:Sunny Singh
摘要
- 一套完整的参考架构,用于在 Databricks 上构建多阶段推荐和排序引擎,从点击流数据摄入到实时个性化服务,用统一平台取代碎片化的机器学习基础设施。
- 该系统通过结合预计算的批量推荐与实时评分路径,使用 Databricks AI Search 进行候选检索、Lakebase 进行在线特征服务、Model Serving 进行低延迟推理,实现低延迟的个性化产品推荐。
- 通过在统一的治理平台上整合数据工程、特征管理、模型训练和实时服务,电商团队可以消除胶合代码,加速迭代周期,并实现从原始点击流到生产预测的端到端血缘追踪。
机遇:将个性化作为营收引擎
用户在时尚电商平台上的每一秒停留都会产生一系列意图信号——搜索、产品浏览、心愿单添加、购物车互动。能够实时将这些信号转化为相关产品推荐的平台才是赢家。行业基准显示,有效的个性化可将转化率提升10-30%,并显著提高平均订单价值。
然而,构建生产级推荐系统仍然是机器学习工程中最困难的挑战之一。它需要实时数据摄入、复杂的特征工程、多个机器学习模型协同工作,以及能在毫秒级响应的推理服务基础设施——同时还要确保库存、位置和业务规则保持同步。
本文基于亚洲一家领先时尚电商平台的实践(该平台月活跃用户超100万,商品目录SKU超10万),介绍了在 Databricks 上构建此类系统的完整参考架构。
系统概览:架构一瞥
该架构采用统一平台方法,从数据摄入到服务的所有组件均在 Databricks 上运行,并由 Unity Catalog 进行治理。
整体系统架构:
数据摄入:从点击流到湖仓一体只需数秒
该平台每秒摄入约1000个事件——产品浏览、搜索、加入购物车操作、购买和会话元数据。Lakeflow Connect 的 Zerobus Ingest 提供了摄入基础设施,可直接将事件写入 Unity Catalog Delta 表,无需自建消息代理。
重要的架构区别:点击流数据通过 Zerobus 流入湖仓一体用于离线特征计算和模型训练,但在实时推理(路径B)期间,会话中的用户信号(即用户当前浏览的内容)会作为API请求负载的一部分直接发送到 Model Serving 端点。这在推理路径中完全绕过了湖仓一体存储,确保实时上下文可用而不会产生摄入延迟。
Zerobus 通过简单的配置更改即可接收来自任何标准 Kafka 生产者客户端(Java、Python、Go)的数据——将引导服务器指向 Zerobus 端点,记录就会进入目标 Delta 表。对于已经运行 Kafka 基础设施的团队,结合声明式管道的结构化流处理提供了另一种采用相同下游架构的路径。
数据流入奖章架构:
青铜层 — 原始、仅追加的事件流加参考数据:
- 用户信号:
行为:浏览序列、搜索查询、停留时间模式、点击历史 交易:购买频率、平均订单价值、退货率、品类支出分布 偏好:收藏商品、保存的搜索、品牌偏好、尺码偏好 人口统计:年龄群体、地理位置聚类、设备类型、应用参与层级
- 物品信号:
目录:品类层级、品牌、价格区间、材质、颜色、季节性 表现:转化率、浏览到加购比率、退货率、平均评分 视觉:图像嵌入(捕捉超越文本属性的风格相似性) 新鲜度:上架天数、趋势速度、库存轨迹
- 上下文信号:
时间:一天中的时间、一周中的日期、发薪日前后、节日/促销期 地理:用户城市、最近的履约中心、区域风格偏好 环境:天气(驱动品类偏好)、本地活动 会话:当前浏览意图(通过会话内行为推断)
白银层 — 清洗、会话化和增强后的数据:
- 会话化用户行为(浏览序列、停留时间、交互模式)
- 清洗后的商品特征(标准化属性、品类层级)
- 聚合的参与信号(7 天浏览次数、趋势评分、流行度指数)
- 用户-商品交互矩阵(隐式反馈信号)
黄金层 — 模型可用的特征表和训练数据集:
- 用户特征向量(行为嵌入、偏好画像、人口统计聚类)
- 商品特征向量(产品嵌入、属性编码)
- 训练数据集(用于模型训练的标记交互对)
- 预计算的推荐列表(批量生成,存储以实现快速查询)
特征以不同频率刷新:行为聚合通过计划的 Databricks Workflows 每日更新,而完整的产品目录每周同步一次。用户和商品的嵌入向量每日重新计算,以捕捉不断变化的偏好和新库存。Databricks 特征存储管理离线特征(用于训练)和在线特征(用于服务),确保训练-服务一致性——模型训练期间使用的特征定义会通过 Lakebase 在线表在推理时自动可用。
Unity Catalog 管理每一层——提供从原始点击流事件到最终提供给应用的预测的血缘关系,通过细粒度的访问控制确保 PII 保持安全,同时聚合特征可自由流向模型训练。
Path A 服务于大多数推荐场景——首页轮播图、分类页排名、电子邮件营销和推送通知。这些场景有一个共同特点:用户身份和场景类型在推荐前已知,因此可以提前计算结果。
由 Databricks Workflows 协调的夜间批量作业,为每个活跃用户执行完整的 3 阶段漏斗离线处理。该作业获取最新的用户嵌入向量,通过 AI Search 商品索引执行批量近似最近邻(ANN)查询以生成候选商品,使用 Gold 层的特征通过 LightGBM 模型进行评分,并应用业务规则(库存评分、配送距离、多样性、促销加权)。输出结果——每个用户按场景类型排序的前 N 名商品列表(通常每个场景 50-100 个商品)——写入 Lakebase 在线表,以用户 ID 和场景类型作为键。
在服务阶段,应用只需执行简单的键值查询:用户 ID + 场景 → 排序后的商品列表。无需模型推理、无需向量搜索、无需特征组装,直接从 Lakebase 读取数据即可。
由于批量作业在夜间运行,Path A 反映的是前一天的信号和库存状态。对于大多数场景,这种新鲜度已足够——长期偏好和品牌亲和力是数天内演变的,而非分钟级变化——新商品在接收到初始嵌入向量后,将在 24 小时内出现在推荐列表中。
Path B — 实时会话感知评分(< 两位数毫秒)
当推荐上下文仅在请求时存在时,Path B 会被激活——例如商品详情页的“相似商品”、"搭配建议",或随着用户浏览动态重新排序的搜索结果。
电子商务应用通过 REST API 将当前会话信号——最近几分钟浏览的商品、活跃的搜索查询、购物车内容和停留时间模式——直接作为请求负载发送到 Model Serving 端点。端点在单个请求-响应周期内同步执行完整的 3 阶段漏斗:
- 第一阶段 — 实时候选商品检索
端点将会话信号转换为查询嵌入向量——要么是当前浏览商品的嵌入向量,要么是融合长期偏好画像(从 Lakebase 获取)与会话行为的混合用户嵌入向量,且近期信号权重更高。该嵌入向量发送至 Databricks AI Search,执行混合检索:近似最近邻相似度搜索结合硬性元数据过滤(分类资格、区域库存、最低库存阈值)。缺货或不符合条件的商品永远不会进入候选集。AI Search 在单次网络往返中返回 200-500 个候选商品。对于会话感知场景,端点计算混合查询嵌入向量——将用户预计算的长期偏好嵌入向量(从 Lakebase 获取)与基于最近浏览商品的会话嵌入向量结合,近期信号权重更高以捕捉即时意图。这种混合计算是端点内部的轻量级运算,而非单独模型调用。
- 阶段2 — 特征组装与评分 候选物品ID会触发对Lakebase在线表的点查询,获取预计算的用户特征(行为聚合数据、人口统计分组、价格敏感度)和物品特征(转化率、趋势得分、上架天数)。实时上下文特征(时间、设备、地理位置、活动促销)直接从请求负载中提取。接口端点为每个用户-候选物品对构建特征向量,包括交叉特征如用户-品类亲和力和品牌偏好重叠,并将这些向量传递给LightGBM评分模型。该模型通过单次批量推理调用(无需GPU资源)预测转化概率。
- 阶段3 — 业务规则与重排序 评分后的列表经过确定性重排序层处理:库存感知评分会降低库存减少商品的优先级,配送距离评分优先选择更近仓库以加快履约,多样性注入防止最终列表出现品牌或品类主导现象,促销加权会提升与活动营销匹配的商品曝光度。重排序后的列表会被截断至请求的尺寸(通常为10-20件商品),作为API响应返回。
业务规则采用配置驱动方式——促销权重、多样性阈值和库存截止值在服务时从托管配置表中读取,使商业团队无需重新部署模型即可调整规则。
接口端点实现为自定义MLflow PyFunc模型,内部协调多阶段流水线——查询AI搜索、执行Lakebase查询、运行LightGBM推理、在单次predict()调用中应用业务规则。
容错策略确保系统韧性:当实时路径超出延迟预算时,系统会优雅降级为提供缓存的热门商品或用户通过路径A预计算的推荐结果。
冷启动问题处理
每个推荐系统必须解决两种冷启动场景:
新用户(无浏览历史):当用户首次访问时,系统会从可用的人口统计信号(地理位置、设备类型、注册上下文、声明的偏好)构建默认用户嵌入向量。该嵌入向量用于对物品索引进行ANN搜索,实质上将新用户置于相似人口统计特征的行为聚类中。随着用户交互增加,其嵌入向量会迅速收敛至真实偏好。
新商品(无交互数据):当新SKU进入商品目录时,系统会根据其属性(标题、品类、品牌、价格区间、从商品图片中提取的视觉特征)生成物品嵌入向量。该嵌入向量用于在向量空间中查找相似现有物品,新商品会继承其最近邻的初始推荐得分。新商品将在下一次每日批量周期中出现在推荐结果中。
模型生命周期与持续优化
模型每周通过Databricks Workflows进行重新训练,实验跟踪和版本管理通过MLflow实现。平台支持冠军/挑战者部署——新模型版本与生产模型并行部署,根据在线性能指标逐步调整流量分配。
监控的关键ML指标包括:
- AUC-ROC — 衡量评分模型区分用户会与不会互动物品的能力
- NDCG@K(归一化折扣累计增益)——评估相关性最高的物品是否出现在排序列表的顶部
- Recall@K — 衡量候选生成阶段成功检索出的相关物品所占比例
- Log Loss — 跟踪预测校准情况,确保转化概率评分随时间保持良好校准
这些模型指标通过业务KPI进行补充——点击率、转化率和每会话收入——这些指标最终验证了模型改进是否真正产生实际影响。
自动化漂移检测会标记特征分布或预测评分分布偏离基线的情况,触发调查或加速再训练。通过请求级标识符将服务日志关联回训练流水线,确保反馈循环生成干净且无数据泄漏的训练数据用于下一次模型迭代。位置感知训练技术确保模型学习真实的用户偏好而非展示位置的伪影。
预期成果
该架构实现:
- 低至两位数毫秒的规模化个性化响应,满足现代以移动优先购物者的性能预期
- 每日更新的推荐内容,反映最新库存、热门产品和不断演变的用户偏好
- 从原始点击流到生产预测的统一治理,通过Unity Catalog实现完整的血缘关系和访问控制
- 快速实验 — 新模型变体可在数天内而非数月内完成训练、评估和部署
- 操作简洁性 — 单一平台取代了数据摄入、特征工程、训练和服务的碎片化系统组合
- 优雅扩展 — 从数千到数百万用户无需重新架构,利用无服务器计算和托管基础设施
结论
构建生产级推荐和排序引擎不再需要拼接十几个专用系统。通过在单一受控平台上统一实时数据摄入(Zerobus)、特征管理(Feature Store + Lakebase)、模型训练(MLflow + Workflows)、向量检索(AI Search)和低延迟服务(Model Serving),电商团队可以专注于真正重要的事情:理解客户并在恰当的时刻提供合适的产品。
其结果不仅是推荐引擎——它是一个完整的、生产就绪的个性化平台,可以作为任何电商体验的智能核心架构。
准备好构建自己的系统了吗?探索 Databricks 推荐引擎解决方案加速器,深入 AI Search 文档,或联系您的 Databricks 账户团队进行架构研讨会。
在邮箱中获取最新文章
订阅我们的博客,最新文章将直接发送到您的邮箱。
注册
查看所有博客
slice-start id="_gatsby-scripts-1"
slice-end id="_gatsby-scripts-1"