Databricks 实时推荐：Lakebase 与 AI Search

机遇：个性化作为收入引擎

购物者在时尚电商应用上花费的每一秒都会产生一连串意图信号——搜索、商品浏览、加入愿望清单、购物车交互。那些能够将这些信号实时转化为相关商品推荐的平台才是赢家。行业基准显示，有效的个性化可以将转化率提升10–30%，并显著提高平均订单价值。

然而，构建生产级推荐系统仍然是最困难的机器学习工程挑战之一。它需要实时数据摄取、复杂的特征工程、多个协同工作的机器学习模型，以及能在毫秒内响应的服务基础设施——同时还要保持库存、位置和业务规则同步。

本篇博客呈现了一套在 Databricks 上构建此类系统的完整参考架构，基于为亚洲一家领先时尚电商平台的实际落地实现，该平台拥有超过 100 万月活跃用户，覆盖 100,000+ 个 SKU 的商品目录。

系统概览：架构一览

该架构采用统一平台方案，从摄取到服务的每个组件都在 Databricks 上运行，并由 Unity Catalog 进行治理。

整体系统架构：

数据摄取：从点击流到湖仓只需数秒

该平台每秒摄取约 1,000 个事件——商品浏览、搜索、加入购物车操作、购买以及会话元数据。 Lakeflow Connect 的 Zerobus Ingest提供摄取骨干，将事件直接落入 Unity Catalog Delta 表，无需自管理消息代理。

一个重要的架构区别：点击流数据通过 Zerobus 流入湖仓，用于离线特征计算和模型训练，但在实时推理期间（路径 B），会话内用户信号——购物者当前正在浏览什么此刻——会直接作为 API 请求负载的一部分发送到模型服务端点。这在推理路径中完全绕过了湖仓存储，确保实时上下文可用，而不引入摄取延迟。

Zerobus 可通过简单的配置更改接受来自任何标准 Kafka 生产者客户端（Java、Python、Go）的数据——将引导服务器指向 Zerobus 端点，记录就会落入目标 Delta 表。对于已经运行 Kafka 基础设施的团队，使用声明式管道的结构化流提供了一条具有相同下游架构的替代路径。

数据流入奖章架构：

铜层——原始、仅追加的事件流加参考数据：

• 行为：浏览序列、搜索查询、停留时间模式、点击历史
• 交易：购买频率、平均订单价值、退货率、品类支出分布
• 偏好：加入愿望清单的商品、保存的搜索、品牌偏好、尺码偏好
• 人口统计：年龄分组、位置聚类、设备类型、应用参与层级

商品信号：

• 目录：品类层级、品牌、价格层级、材质、颜色、季节性
• 表现：转化率、浏览到加购比、退货率、平均评分
• 视觉：图像嵌入（捕捉文本属性之外的风格相似性）
• 新鲜度：上架天数、趋势速度、库存轨迹

情境信号：

• 时间：一天中的时段、星期几、距发薪日的远近、节日/促销期
• 地理：用户城市、最近履约中心、区域风格偏好
• 环境：天气（驱动品类偏好）、本地活动
• 会话：当前浏览意图（从会话内行为推断）

银层——清洗、会话化并丰富：

• 会话化用户行为（浏览序列、停留时间、交互模式）
• 清洗后的商品特征（规范化属性、品类层级）
• 聚合参与信号（7 天浏览次数、趋势分数、热门指数）
• 用户-商品交互矩阵（隐式反馈信号）

金层——可供模型使用的特征表和训练数据集：

• 用户特征向量（行为嵌入、偏好画像、人口统计聚类）
• 商品特征向量（商品嵌入、属性编码）
• 训练数据集（用于模型训练的带标签交互对）
• 预计算推荐列表（批量生成，存储以便快速查找）

特征按不同节奏刷新：行为聚合每日通过计划 Databricks Workflows 更新，而完整商品目录每周同步。用户和商品的嵌入每天重新计算，以捕捉不断变化的偏好和新库存。Databricks Feature Store管理离线特征（用于训练）和在线特征（用于服务），确保训练-服务一致性——模型训练期间使用的相同特征定义，在推理时通过 Lakebase 在线表自动可用。

Unity Catalog 治理每一层——提供从原始点击流事件到最终服务于应用的预测的血缘关系，并通过细粒度访问控制确保 PII 受到保护，同时聚合特征自由流向模型训练。

实时服务：两条通往低延迟响应的路径

服务架构提供两条互补路径，各自针对不同的交互模式进行优化。路径 A 处理高流量、可预测的界面，预计算既可行又最优。路径 B 处理动态的、会话感知的界面，用户的即时意图必须实时塑造响应。

路径 A——预计算批量推荐（低于两位数毫秒）

路径 A 服务于大多数推荐界面——首页轮播、品类页排名、电子邮件营销和推送通知。这些界面有一个共同特点：用户身份和界面类型提前已知，因此结果可以提前计算。

由 Databricks Workflows 编排的每夜批处理作业，为每个活跃用户离线运行完整的三阶段漏斗。它检索最新的用户嵌入，对 AI Search 物品索引执行批量 ANN 查询以生成候选，使用来自 Gold 层的特征通过 LightGBM 模型对其进行打分，并应用业务规则（库存评分、配送就近性、多样性、促销加权）。输出——每个用户的 top-N 排序商品列表（每个展示面通常 50–100 个商品）——写入 Lakebase 在线表，以用户 ID 和展示面类型为键。

在服务时，应用执行简单的键值查找：user_id + surface → 排序商品列表。无模型推理、无向量搜索、无特征组装——只是从 Lakebase 直接读取。

由于批处理作业每夜运行，路径 A 反映前一天的信号和库存状态。对大多数展示面而言，这种新鲜度绰绰有余——长期偏好和品牌亲和力以天而非分钟为单位演变——而获得初始嵌入的新商品将在 24 小时内出现在推荐中。

路径 B——实时会话感知打分（< 两位数毫秒）

当推荐上下文仅在请求时存在时，路径 B 激活——"相似商品"（在商品详情页上）、"完善搭配"建议，或随着用户浏览而动态调整的重新排序搜索结果。

电商应用将当前会话信号——过去几分钟内浏览的商品、活跃搜索查询、购物车内容以及停留时间模式——作为请求负载直接通过 REST API 发送到 Model Serving 端点。该端点在单个请求-响应周期内同步执行完整的三阶段漏斗：

• 阶段 1——实时候选检索 该端点将会话信号转换为查询嵌入——要么是正在浏览的商品的物品嵌入，要么是一个混合用户嵌入，融合长期偏好画像（来自 Lakebase）与会话内行为，并更侧重近期信号。该嵌入被发送到 Databricks AI Search，后者执行混合检索：ANN 相似性搜索与硬性元数据过滤（类别资格、区域库存、最低库存阈值）相结合。缺货或不符合资格的商品绝不会进入候选集。AI Search 在单次网络往返中返回 200–500 个候选。对于会话感知展示面，该端点计算一个混合查询嵌入——将用户预先计算的长期偏好嵌入（从 Lakebase 检索）与源自最近浏览商品的会话嵌入相结合，并侧重近期信号以捕捉即时意图。这种混合是在端点内执行的轻量级计算，而不是单独的模型调用
• 阶段 2——特征组装与打分 候选商品 ID 触发对 Lakebase 在线表的点查找，检索预先计算的用户特征（行为聚合、人口统计细分、价格敏感度）和商品特征（转化率、趋势评分、上架天数）。实时上下文特征（一天中的时间、设备、位置、活跃促销）直接从请求负载中导出。该端点为每个用户-候选对构建特征向量——包括诸如用户-类别亲和力和品牌偏好重叠之类的交叉特征——并将它们传递给 LightGBM 打分模型，后者在无需 GPU 资源的单次批量推理调用中预测转化概率。
• 阶段 3——业务规则与重排序 打分后的列表经过一个确定性的重排序层：库存感知评分降低库存下降商品的优先级，配送就近性评分偏向更近的仓库以实现更快履约，多样性注入防止品牌或类别在最终列表中占据主导，促销加权让与活跃活动一致的商品获得曝光。重排序后的列表被截断到请求的大小（通常 10–20 个商品），并作为 API 响应返回。

业务规则由配置驱动——促销权重、多样性阈值和库存截断值在服务时从受管配置表中读取，允许商业团队调整规则而无需重新部署模型。

该端点实现为一个自定义的 MLflow PyFunc 模型，它在内部编排多阶段流水线——在单次 predict() 调用中查询 AI Search、执行 Lakebase 查找、运行 LightGBM 推理并应用业务规则。

一个 回退策略确保韧性：如果实时路径超出其延迟预算，系统会优雅降级为提供缓存的流行商品或来自路径 A 的用户预先计算的推荐。

处理冷启动问题

每个推荐系统都必须解决两种冷启动场景：

新用户（无浏览历史）： 当用户首次到达时，系统根据可用的人口统计信号——位置、设备类型、注册上下文以及任何声明的偏好——构建一个默认用户嵌入。该嵌入用于对物品索引进行 ANN 搜索，实际上将新用户置于相似人口统计的行为聚类中。随着用户交互，其嵌入会迅速向其真实偏好收敛。

新商品（无交互数据）： 当新 SKU 进入目录时，系统根据其属性——标题、类别、品牌、价格点以及从商品图片中提取的视觉特征——生成一个物品嵌入。该嵌入用于在向量空间中查找相似的现有商品，新商品从其最近邻继承初始推荐分数。新商品会在下一个每日批处理周期出现在推荐中。

模型生命周期与持续改进

模型使用 Databricks Workflows 每周重新训练，实验跟踪和版本管理通过 MLflow 进行。该平台支持冠军/挑战者部署——新模型版本与生产模型一起部署，并根据在线性能指标逐步转移流量。

监控的关键机器学习指标包括：

• 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 客户团队获取架构研讨会。