Databricks发布时尚电商推荐系统参考架构，日处理约100万活跃用户
该架构基于Databricks平台为亚洲一家时尚电商构建，每秒摄取约1000个事件，覆盖10万以上SKU、月活超100万用户，提供两条毫秒级推荐响应路径。
AI解读：Databricks博客公开了一套面向时尚电商的实时推荐系统参考架构，基于为亚洲一家头部时尚电商的真实实现——该平台月活用户超过100万，商品目录超过10万个SKU。
这套架构的特点是所有环节都跑在Databricks上，用Unity Catalog统一治理。推荐服务分两条路：一条夜间批量预计算，适合首页轮播、分类页排名等场景；另一条在用户请求时实时算，适合“相似商品”“搭配推荐”这类依赖当前浏览行为的场景。
对电商团队来说，参考价值在于它给出了一个完整、可落地的技术路线，而不是只停留在算法层面——从数据摄取、特征管理、模型训练到低延迟服务都给出了具体组件和延迟目标。但博客只给了架构描述，没有披露这套系统实际带来的转化率提升数据，行业基准的10%–30%提升来自第三方统计，不是该案例的实测结果。
Databricks博客发布了一套用于时尚电商的实时推荐与排序系统参考架构，该架构基于为亚洲一家头部时尚电商平台的实际实现，该平台月活跃用户超过100万，商品目录超过10万个SKU。
系统每秒摄取约1000个事件，包括商品浏览、搜索、加购、购买和会话元数据。所有组件——从数据摄取到模型服务——均运行在Databricks平台上，并由Unity Catalog统一治理。
数据摄取与分层
平台通过Lakeflow Connect的Zerobus Ingest将事件直接写入Unity Catalog的Delta表，无需自管理消息代理。Zerobus接受任何标准Kafka生产者客户端（Java、Python、Go），只需将bootstrap server指向Zerobus端点即可，记录会落进目标Delta表。
一个关键架构区分：点击流数据通过Zerobus进入湖仓用于离线特征计算和模型训练；但在实时推理路径中，会话内的用户信号——即购物者当前正在浏览的内容——会直接作为API请求负载的一部分发送到Model Serving端点，完全绕过湖仓存储，以避免摄取延迟。
数据按Bronze、Silver、Gold三层组织。Bronze层保存原始追加型事件流和参考数据，涵盖用户信号（行为、交易、偏好、人口统计）、商品信号（目录、表现、视觉、新鲜度）以及上下文信号（时间、地理、环境、会话）。Silver层完成会话化、清洗和增强。Gold层存放模型就绪的特征表和训练数据集。
特征按不同频率刷新：行为聚合每日通过Databricks Workflows更新，完整商品目录每周同步一次。用户和商品的嵌入向量每日重新计算。Databricks Feature Store同时管理离线特征和在线特征，确保训练-服务一致性。
- Zerobus Ingest直接落地Delta表，无需自建Kafka消息代理
- 实时推理路径绕过湖仓存储，会话信号随API请求直接发送到Model Serving端点
- 行为聚合特征每日刷新，商品目录每周同步，嵌入向量每日重算
- Unity Catalog提供从原始点击流到最终预测的完整血缘和细粒度访问控制
两条毫秒级服务路径
服务架构提供两条互补路径。Path A处理高并发、可预测的界面，采用预计算方式。一个由Databricks Workflows编排的夜间批处理任务为每个活跃用户离线运行完整的三阶段漏斗：获取最新用户嵌入，对AI Search商品索引执行批量ANN查询生成候选，用LightGBM模型结合Gold层特征打分，再应用商业规则（库存评分、配送距离、多样性、促销加权）。输出是按用户和界面类型键控的top-N排名商品列表，通常每个界面 50–100 个商品，写入Lakebase在线表。服务时只需做键值查询，无模型推理、无向量搜索、无特征组装。
Path B在推荐上下文仅存在于请求时激活，适用于商品详情页的“相似商品”、“搭配推荐”或随浏览动态重排的搜索结果。电商应用将当前会话信号——最近几分钟浏览的商品、当前搜索查询、购物车内容、停留时长模式——通过REST API直接作为请求负载发送到Model Serving端点。端点在一个请求-响应周期内同步执行完整三阶段漏斗。
Path B的第一阶段是实时候选检索：端点将会话信号转化为查询嵌入——可以是正在浏览商品的嵌入，也可以是将长期偏好画像（来自Lakebase）与近期行为融合的混合用户嵌入，近期信号权重更高。该嵌入发送至Databricks AI Search，执行混合检索：ANN相似度搜索结合硬性元数据过滤（品类资格、区域库存、最低库存阈值）。缺货或不符合条件的商品不会进入候选集。AI Search在一次网络往返中返回 200–500 个候选。
第二阶段是特征组装与打分：候选商品ID触发对Lakebase在线表的点查询，获取预计算的用户特征和商品特征。实时上下文特征从请求负载直接推导。端点构建每个用户-候选商品对的特征向量，送入LightGBM模型，在一次批量推理中预测转化概率，无需GPU。
第三阶段是商业规则与重排：库存感知评分降低库存下降商品的优先级，配送距离评分偏向更近的仓库，多样性注入防止品牌或品类独占最终列表，促销加权突出与活动一致的商品。重排后列表截断到请求数量，通常 10–20 个商品，作为API响应返回。商业规则由配置驱动，促销权重、多样性阈值和库存截止值在服务时从管理配置表读取，商业团队可以调整规则而无需重新部署模型。
- Path A夜间批处理，服务时仅做键值查询，返回预计算的top-N列表
- Path B端点内同步执行三阶段漏斗：候选检索、特征组装与打分、商业规则重排
- Path B中混合查询嵌入融合长期偏好和实时会话行为，近期信号权重更高
- AI Search返回 200–500 个候选，最终响应通常 10–20 个商品
- 降级策略：若实时路径超出延迟预算，系统回退到缓存热门商品或Path A的预计算推荐
冷启动与模型迭代
新用户没有浏览历史时，系统用可用的人口统计信号——位置、设备类型、注册上下文、已声明偏好——构建默认用户嵌入，用于对商品索引做ANN搜索，将新用户置于相似人口统计的行为聚类中。随着用户交互，嵌入会快速收敛到真实偏好。
新商品没有交互数据时，系统从标题、品类、品牌、价格点和商品图片提取的视觉特征生成商品嵌入，用于在向量空间中找到相似的已有商品，新品从最近邻继承初始推荐分数，会在下一个每日批处理周期出现在推荐中。
模型每周使用Databricks Workflows重新训练，实验跟踪和版本管理由MLflow负责。平台支持冠军/挑战者部署，新模型版本与生产模型并行运行，根据在线表现逐步切换流量。
监控的ML指标包括AUC-ROC、NDCG@K、Recall@K和Log Loss。这些指标与业务KPI——点击率、转化率、每会话收入——互为补充。自动漂移检测在特征分布或预测分数分布偏离基线时标记，触发调查或加速重训。服务日志通过请求级标识符关联回训练管道，确保反馈循环产生干净、无泄漏的训练数据。
- 新用户用人口统计信号构建默认嵌入，交互后快速收敛到真实偏好
- 新品从商品属性生成嵌入，从最近邻继承初始推荐分数
- 模型每周重训，支持冠军/挑战者部署和逐步流量切换
- 自动漂移检测监控特征分布和预测分数分布
- 位置感知训练技术确保模型学习真实用户偏好而非展示位置假象
架构预期效果
博客列出的预期效果包括：大规模下的两位数毫秒级个性化响应，匹配现代移动优先购物者的性能预期；每日更新的推荐反映最新库存、趋势商品和演变的用户偏好；从原始点击流到生产预测的统一治理，提供完整血缘和访问控制；快速实验——新模型变体可在数天而非数月内完成训练、评估和部署；运维简化——单一平台替代摄取、特征工程、训练和服务的多个独立系统；优雅扩展——从数千用户到数百万用户无需重新架构，利用无服务器计算和托管基础设施。