1. 项目概述召回在搜索推荐系统中的核心定位如果你在电商平台搜索“运动鞋”瞬间出现的成千上万商品列表背后第一个关键动作就是“召回”。这听起来像是个工业术语但它的本质就是系统从海量商品库可能是数亿甚至数十亿规模中快速、初步地筛选出一个相对较小的候选集合比如几千到几万个供后续的排序模型进行精细打分和排列。你可以把它想象成一场大型选秀的海选阶段评委召回模型需要在极短时间内从上百万报名者中快速挑出几百位看起来有潜力的选手进入下一轮而不是对每个人都进行长达一小时的深度面试。召回就是这个“海选”环节它决定了后续排序阶段的天花板——如果好商品压根没被召回那么再精妙的排序模型也无能为力。召回的核心挑战在于“效率”与“效果”的极致平衡。一方面它必须在几十毫秒内完成因为用户无法忍受搜索结果的长时间等待另一方面它又必须尽可能准确不能漏掉那些用户真正可能感兴趣的高质量物品。这就引出了召回率Recall这个关键评估指标在所有用户可能喜欢的物品中有多大比例被成功召回了。高召回率意味着“宁可错杀不可放过”为后续排序提供了丰富的优质素材但过高的召回也会引入大量噪声增加排序阶段的负担。因此设计一个高效的召回系统是构建一流搜索推荐体验的基石。2. 召回系统的核心设计思路与架构拆解一个成熟的召回系统绝非单一模型或策略而是一个由多种召回通道也称为召回源组成的“组合拳”。每种通道针对不同的用户意图和场景从不同维度进行筛选最终将结果融合去重形成统一的候选集。这种设计思路源于一个朴素的认识用户的兴趣是多元的触发方式也是多样的。2.1 多路召回构建立体的筛选网络主流的工业级系统通常会部署以下几路核心召回基于内容的召回Content-Based Recall这是最直观的一路。系统分析用户历史行为点击、购买、浏览过的物品内容特征如标题中的关键词、品类、品牌、价格段然后从全量库中寻找特征相似的其他物品。例如用户经常点击“轻薄便携笔记本电脑”那么系统就会召回所有带有“轻薄”、“便携”标签的笔记本。它的优势是结果可解释、冷启动友好新物品只要有内容特征就能被召回但容易陷入“信息茧房”缺乏惊喜感。协同过滤召回Collaborative Filtering Recall这是推荐系统的经典算法核心思想是“物以类聚人以群分”。它又分为基于物品的协同过滤Item-CF如果你喜欢物品A而很多喜欢物品A的人也喜欢物品B那么系统就可能把物品B召回给你。这非常适合“看了又看”、“买了又买”的场景。基于用户的协同过滤User-CF找到和你兴趣相似的一群用户把他们喜欢而你没看过的物品召回给你。这有助于发现潜在的新兴趣点。 协同过滤不依赖物品内容能挖掘深层次的关联关系但对数据稀疏性和冷启动问题比较敏感。基于向量的召回Vector-Based / Embedding Recall这是当前的主流和核心技术。其核心是将用户和物品都映射到一个高维的向量空间称为嵌入向量Embedding。在这个空间里相似的用户或物品距离更近。召回时计算用户向量与全量物品向量的相似度常用内积或余弦相似度取最相似的Top-K个物品。这种方法能融合非常复杂的行为和特征信息表达能力强。常见的模型有YouTube DNN、DSSM、双塔模型以及更复杂的SDMSequential Deep Matching和MINDMulti-Interest Network with Dynamic Routing。热点/流行度召回直接召回当前最热门、销量最高、趋势上升最快的物品。这保证了结果的时效性和大众性是保障结果基础体验的重要一环尤其对新用户或行为较少的用户至关重要。地理位置召回对于本地生活服务如外卖、到店至关重要召回用户附近可触达的商家或服务。业务规则召回根据特定业务目标强制召回某些物品例如新品扶持、特定促销活动的商品、需要清库存的商品等。注意多路召回不是简单的堆砌。每一路召回都需要精心调校其数量和权重。例如向量召回可能提供1000个候选内容召回提供500个热点召回提供200个。如何分配这些名额如何在合并时去重和权衡本身就是一个重要的策略问题。2.2 系统架构从离线计算到在线服务一个完整的召回系统在工程上分为离线、近线和在线三个部分形成数据闭环。离线层负责“慢工出细活”。在这里训练庞大的深度学习模型如双塔模型、MIND生成和更新所有物品的向量Item Embedding并存入向量数据库如Faiss, Milvus。同时计算物品间的协同过滤相似度矩阵、挖掘热门榜单等。这些计算耗时较长通常是天级别或小时级别更新。近线层负责“快速反应”。监听用户的最新行为如最近一次点击在分钟甚至秒级内更新用户的兴趣向量User Embedding。这使得系统能捕捉用户的实时意图变化比如用户刚刚搜索了“情人节礼物”接下来的推荐就应该立刻体现出这个意图。在线服务层负责“闪电响应”。当用户请求到来时在线服务快速从近线层获取最新的用户向量然后从向量数据库中检索最相似的物品向量近似最近邻搜索ANN。同时并行触发其他召回通道如规则召回、热门召回的逻辑。最后将多路结果融合、过滤如去掉已曝光、已购买的返回给排序阶段。整个过程必须在百毫秒内完成。3. 核心模型技术深度解析从双塔到多兴趣建模向量召回模型是当前召回效果的天花板其演进体现了对用户兴趣建模不断深化的过程。3.1 基石双塔模型DSSM范式双塔模型是向量召回的经典架构顾名思义它有两个“塔”。一个塔用户塔输入用户特征用户ID、历史行为序列、画像标签等输出一个用户向量。另一个塔物品塔输入物品特征物品ID、内容属性等输出一个物品向量。训练时将正样本用户点击/购买的物品的用户向量和物品向量做内积使得结果尽量大同时进行负采样随机选择一些用户未交互的物品作为负样本使得负样本对的内积尽量小。损失函数常用交叉熵或对比学习损失。它的优势在于结构清晰、线上服务效率高。物品向量可以全部离线计算好存入索引线上只需要计算一次用户向量然后做高效的向量检索即可。但它的一个核心局限在于将用户丰富的兴趣压缩成了单个向量。这好比用一句话来概括一个人的全部喜好难免会丢失细节导致召回不够精准。3.2 演进多兴趣提取网络MIND为了克服单向量表示的局限阿里巴巴提出了MINDMulti-Interest Network with Dynamic Routing模型。MIND认为一个用户可能同时拥有多个不同的兴趣维度。例如一个年轻妈妈可能同时关注“母婴用品”、“美妆护肤”和“职场通勤装”。MIND的核心是动态路由Dynamic Routing机制它借鉴了胶囊网络的思想。模型将用户的历史行为序列作为输入通过多兴趣抽取层动态地将这些行为聚类到几个不同的兴趣胶囊中。每个兴趣胶囊输出一个向量代表用户的一个独立兴趣维度。线上服务对于同一个用户MIND会产出多个兴趣向量例如K个。在召回时用这K个向量分别去向量库中检索每个兴趣召回Top-N个物品最后将K*N个结果合并去重。这样召回结果就能同时覆盖用户多个方面的兴趣大大提升了召回的多样性和覆盖率。实操心得K值的选择是个关键超参。太小可能无法分离兴趣太大则可能引入噪声并增加计算开销。通常需要根据平台用户行为的丰富度通过AB实验来确定一般在3-8之间。3.3 深化序列深度匹配模型SDM如果说MIND关注的是用户并行的多兴趣那么SDMSequential Deep Matching则更关注用户序列化的兴趣演变。它认为用户近期行为和长期行为具有不同的意义且行为间的顺序关系蕴含重要信息。SDM将用户行为序列分为两个部分短期会话行为最近一段时间内如一小时的连续点击序列。这部分行为反映了用户当前的即时意图和情境例如连续浏览多款跑步鞋可能正打算购买。长期历史行为过去较长时间内如一周的所有行为。这部分代表了用户稳定的兴趣偏好。模型分别用不同的网络如Transformer或GRU对短期序列和长期序列进行建模得到短期兴趣向量和长期兴趣向量。然后通过一个门控网络Attention来融合二者生成最终的用户向量。这个门控网络能自适应地决定在当前请求下是更依赖短期意图还是长期偏好。SDM的强大之处在于对时序信号的捕捉。例如用户刚搜索了“手机”然后浏览了几款“手机壳”SDM能更好地理解这种序列依赖从而在召回时不仅召回手机也能精准召回匹配的手机壳实现了类似“购物车”的联想召回。3.4 模型选型与融合的考量在实际生产中我们很少只使用单一模型而是采用分层、分场景的策略主流流量可能采用MIND SDM结合的方式。用MIND保证兴趣的多样性覆盖用SDM捕捉实时和序列意图。两者召回的结果再进行融合。冷启动场景对于新用户或新物品深度模型可能失效这时需要内容召回CB和热门召回扛起大梁。效率优先场景对于实时性要求极高的场景如信息流刷不停经典的双塔模型因其计算效率高依然是不可或缺的保底选择。注意模型越复杂线上服务的成本计算、内存、延迟就越高。MIND需要计算K次向量检索SDM需要维护和实时更新用户行为序列。工程师必须在效果和效率之间做出精心的权衡通常会对高频用户使用复杂模型对低频用户使用轻量模型。4. 工程实现与核心环节剖析有了好的模型还需要坚实的工程实现才能发挥威力。这里重点剖析向量召回线上服务的关键环节。4.1 向量索引构建与近似最近邻搜索ANN全量物品向量可能高达数十亿对每个用户向量进行精确的全局计算暴力搜索耗时是不可接受的。因此必须使用近似最近邻搜索ANN技术在可接受的精度损失下将检索耗时从线性降低到亚线性甚至对数级。常用的ANN库和算法有算法/库原理简介适用场景注意事项Faiss (Facebook)提供了多种索引如IVF倒排文件、HNSW分层可导航小世界图、PQ乘积量化。HNSW在速度和精度上平衡较好是目前主流。十亿级别向量库高精度要求。需要将向量全部加载到内存内存消耗大。调参复杂efConstruction, efSearch, M等参数。Annoy (Spotify)基于随机投影树构建森林进行搜索。千万级别内存敏感简单易用。索引是只读的更新需要重建。精度通常比HNSW稍差。SCANN (Google)结合了分区、量化等技术的先进ANN库。超大规模向量检索对精度和速度有极致要求。配置相对复杂社区资源较Faiss少。Milvus / Weaviate开源向量数据库封装了底层ANN索引提供增删改查的数据库服务。需要动态更新向量、进行多条件过滤标量向量混合查询的场景。引入数据库开销纯检索性能可能低于直接使用Faiss。实操步骤示例以Faiss HNSW为例离线索引构建import faiss import numpy as np # 假设 item_embeddings 是 numpy 数组形状为 [num_items, embedding_dim] embedding_dim 128 num_items 1000000 # 创建 HNSW 索引 index faiss.IndexHNSWFlat(embedding_dim, 32) # 32 是 HNSW 的“M”参数影响连接数 index.hnsw.efConstruction 200 # 构建时的搜索深度影响构建质量和速度 # 添加向量需要先转换为float32 item_embeddings item_embeddings.astype(float32) index.add(item_embeddings) # 保存索引到磁盘 faiss.write_index(index, item_vectors_hnsw.index)在线服务加载与查询# 在线服务启动时加载索引 index faiss.read_index(item_vectors_hnsw.index) index.hnsw.efSearch 100 # 搜索时的深度越大越准越慢 # 收到用户请求计算用户向量 user_vec (shape: [1, embedding_dim]) user_vec user_vec.astype(float32) k 1000 # 需要召回的数量 distances, indices index.search(user_vec, k) # indices 就是召回物品的ID列表4.2 用户实时向量更新为了捕捉用户实时兴趣用户向量不能只用离线天级别数据计算。主流做法是部署一个用户向量实时更新服务。触发与计算当用户发生关键行为点击、搜索、下单时将行为事件用户ID 物品ID 时间戳 类型发送到消息队列如Kafka。流处理流计算引擎如Flink消费这些消息获取用户最新的行为序列例如最近50次点击并调用一个轻量级的实时模型可能是简化版的SDM或RNN来快速计算新的用户向量。这个模型通常比离线模型小只使用最近的数据。存储计算出的新用户向量立即写入高速缓存如Redis键为用户ID值为向量数据。过期时间设置为几小时到一天平衡实时性和存储成本。在线服务读取当召回服务收到请求时首先尝试从Redis中读取该用户的实时向量。如果存在且未过期则使用它否则回退到使用离线计算的长期向量。4.3 多路召回的结果融合与过滤各召回通道返回的结果需要经过合并、过滤、截断才能形成最终的候选集。去重不同通道可能召回相同的物品需要根据物品ID进行去重。过滤应用业务规则过滤掉不应出现的物品例如用户已购买或已明确不喜欢的物品。当前用户不可见如下架、无库存、地区限制的物品。质量分过低或违规的物品。融合与截断这是策略核心。简单做法是“按路截断全局混排”每路召回固定数量如向量召回1000协同过滤500合并去重后可能得到一个2000条的集合再随机或按简单规则如发布时间打乱取前N条如1500条送给排序。更复杂的做法会引入粗排模型用一个非常轻量级的模型如逻辑回归、浅层神经网络对合并后的几千个候选进行快速打分按分数取Top确保送入精排的都是“潜力股”。5. 效果评估、常见问题与调优实战召回系统的好坏不能凭感觉必须建立科学的评估体系并在实践中持续调优。5.1 核心评估指标召回率Recall这是最直接的指标。定义是召回率 系统召回的相关物品数 / 全量相关物品数。但在线上无法获取“全量相关物品”所以通常用离线测试集来近似评估。在A/B测试中更关注下游排序后核心业务指标的提升如点击率CTR、转化率CVR、人均停留时长等。召回优化最终要服务于这些业务指标。覆盖率Coverage指被召回系统“触及”过的物品占总物品库的比例。高的覆盖率意味着系统能挖掘长尾物品促进生态健康。如果覆盖率过低说明系统总是推荐热门物品不利于新品和中小商家。新颖性/多样性衡量推荐结果是否千篇一律。可以通过计算推荐列表中物品品类、品牌的熵或者两两物品之间的相似度来度量。线上服务指标延迟Latency和吞吐量QPS是生命线。必须严格监控P99延迟确保满足业务要求如100ms。5.2 常见问题与排查技巧实录问题1线上效果波动大时好时坏。排查思路检查数据管道首先确认离线特征生成、模型训练的数据源是否稳定、一致。是否存在数据缺失、特征计算逻辑变更检查模型更新模型是否按预期定时更新新模型版本上线后离线评估指标是否正常线上向量索引是否同步更新检查实时链路用户实时向量更新服务是否正常Redis缓存是否满或延迟高实时行为数据流是否中断查看业务波动是否与节假日、大促活动相关可能是正常业务波动。实操心得建立完善的监控大盘涵盖从数据源-特征工程-模型训练-索引构建-在线服务的全链路关键指标。一旦波动能快速定位环节。问题2召回结果总是偏向热门物品长尾物品出不来。原因与对策样本偏差训练数据中热门物品的曝光和点击本就多模型自然学得更好。需要在训练时进行纠偏例如对热门物品进行降采样Down Sampling或对长尾物品进行过采样Up Sampling。损失函数问题标准的交叉熵损失容易让模型“偷懒”只学好预测热门物品就行。可以尝试加权交叉熵给长尾样本更高权重或使用对比学习损失InfoNCE它通过构造正负样本对更能拉大同类与不同类样本的距离有利于学习长尾特征。增加专门的长尾召回通道设计一路基于“探索”策略的召回例如UCB置信上界算法主动召回那些曝光少但有潜力的物品。问题3ANN检索精度下降导致线上效果劣化。排查与调优确认索引参数检查HNSW的efSearch参数。线上查询时为了速度可能设置得过低如16适当调高如64或128能提升精度但会增加延迟。需要在效果和延迟间做权衡测试。检查向量质量离线评估模型在新数据上的表现是否下降可能是模型本身需要重新训练或调整。向量维度是否对齐确保在线服务加载的索引其向量维度与模型输出的维度完全一致。这是一个低级但一旦发生就是致命的问题。考虑量化误差如果使用了乘积量化PQ来压缩索引以节省内存会引入误差。可以尝试减少量化段数或使用更高精度的量化方式。问题4新用户/新物品冷启动推荐效果差。解决方案对于新用户在用户向量不可用或很稀疏时果断降级到非个性化召回如热门榜、趋势榜、地域热门、注册时选择的兴趣标签召回等。同时可以设计“探索性”问题或交互快速收集用户反馈。对于新物品利用内容特征在物品塔中除了ID类特征一定要加入丰富的内容特征标题、类目、属性、图片嵌入向量等。这样即使物品ID是新的其内容特征也能让它被相关用户召回。流量扶持策略在召回阶段为新物品设置一个保量规则例如在召回结果中强制插入一定比例的新品给予初始曝光机会。迁移学习使用在大量数据上预训练好的物品内容编码器如BERT for Title来初始化新物品的向量表示。召回系统是一个复杂的系统工程它连接着数据、算法和产品。没有一个一劳永逸的银弹持续的数据分析、敏锐的业务洞察、严谨的AB实验和精细的工程优化才是让这个“海选官”越来越聪明的唯一路径。在实际工作中我深刻体会到召回策略的调整往往能带来排序阶段无法获得的巨大收益因为它决定了赛道的宽度。很多时候花时间深入理解业务场景设计更贴合场景的召回通道例如针对“找同款”的以图搜物召回针对“补货”的周期性购买召回比单纯优化模型参数来得更有效。 搜索推荐系统召回技术：从多路召回到向量检索与工程实践
1. 项目概述召回在搜索推荐系统中的核心定位如果你在电商平台搜索“运动鞋”瞬间出现的成千上万商品列表背后第一个关键动作就是“召回”。这听起来像是个工业术语但它的本质就是系统从海量商品库可能是数亿甚至数十亿规模中快速、初步地筛选出一个相对较小的候选集合比如几千到几万个供后续的排序模型进行精细打分和排列。你可以把它想象成一场大型选秀的海选阶段评委召回模型需要在极短时间内从上百万报名者中快速挑出几百位看起来有潜力的选手进入下一轮而不是对每个人都进行长达一小时的深度面试。召回就是这个“海选”环节它决定了后续排序阶段的天花板——如果好商品压根没被召回那么再精妙的排序模型也无能为力。召回的核心挑战在于“效率”与“效果”的极致平衡。一方面它必须在几十毫秒内完成因为用户无法忍受搜索结果的长时间等待另一方面它又必须尽可能准确不能漏掉那些用户真正可能感兴趣的高质量物品。这就引出了召回率Recall这个关键评估指标在所有用户可能喜欢的物品中有多大比例被成功召回了。高召回率意味着“宁可错杀不可放过”为后续排序提供了丰富的优质素材但过高的召回也会引入大量噪声增加排序阶段的负担。因此设计一个高效的召回系统是构建一流搜索推荐体验的基石。2. 召回系统的核心设计思路与架构拆解一个成熟的召回系统绝非单一模型或策略而是一个由多种召回通道也称为召回源组成的“组合拳”。每种通道针对不同的用户意图和场景从不同维度进行筛选最终将结果融合去重形成统一的候选集。这种设计思路源于一个朴素的认识用户的兴趣是多元的触发方式也是多样的。2.1 多路召回构建立体的筛选网络主流的工业级系统通常会部署以下几路核心召回基于内容的召回Content-Based Recall这是最直观的一路。系统分析用户历史行为点击、购买、浏览过的物品内容特征如标题中的关键词、品类、品牌、价格段然后从全量库中寻找特征相似的其他物品。例如用户经常点击“轻薄便携笔记本电脑”那么系统就会召回所有带有“轻薄”、“便携”标签的笔记本。它的优势是结果可解释、冷启动友好新物品只要有内容特征就能被召回但容易陷入“信息茧房”缺乏惊喜感。协同过滤召回Collaborative Filtering Recall这是推荐系统的经典算法核心思想是“物以类聚人以群分”。它又分为基于物品的协同过滤Item-CF如果你喜欢物品A而很多喜欢物品A的人也喜欢物品B那么系统就可能把物品B召回给你。这非常适合“看了又看”、“买了又买”的场景。基于用户的协同过滤User-CF找到和你兴趣相似的一群用户把他们喜欢而你没看过的物品召回给你。这有助于发现潜在的新兴趣点。 协同过滤不依赖物品内容能挖掘深层次的关联关系但对数据稀疏性和冷启动问题比较敏感。基于向量的召回Vector-Based / Embedding Recall这是当前的主流和核心技术。其核心是将用户和物品都映射到一个高维的向量空间称为嵌入向量Embedding。在这个空间里相似的用户或物品距离更近。召回时计算用户向量与全量物品向量的相似度常用内积或余弦相似度取最相似的Top-K个物品。这种方法能融合非常复杂的行为和特征信息表达能力强。常见的模型有YouTube DNN、DSSM、双塔模型以及更复杂的SDMSequential Deep Matching和MINDMulti-Interest Network with Dynamic Routing。热点/流行度召回直接召回当前最热门、销量最高、趋势上升最快的物品。这保证了结果的时效性和大众性是保障结果基础体验的重要一环尤其对新用户或行为较少的用户至关重要。地理位置召回对于本地生活服务如外卖、到店至关重要召回用户附近可触达的商家或服务。业务规则召回根据特定业务目标强制召回某些物品例如新品扶持、特定促销活动的商品、需要清库存的商品等。注意多路召回不是简单的堆砌。每一路召回都需要精心调校其数量和权重。例如向量召回可能提供1000个候选内容召回提供500个热点召回提供200个。如何分配这些名额如何在合并时去重和权衡本身就是一个重要的策略问题。2.2 系统架构从离线计算到在线服务一个完整的召回系统在工程上分为离线、近线和在线三个部分形成数据闭环。离线层负责“慢工出细活”。在这里训练庞大的深度学习模型如双塔模型、MIND生成和更新所有物品的向量Item Embedding并存入向量数据库如Faiss, Milvus。同时计算物品间的协同过滤相似度矩阵、挖掘热门榜单等。这些计算耗时较长通常是天级别或小时级别更新。近线层负责“快速反应”。监听用户的最新行为如最近一次点击在分钟甚至秒级内更新用户的兴趣向量User Embedding。这使得系统能捕捉用户的实时意图变化比如用户刚刚搜索了“情人节礼物”接下来的推荐就应该立刻体现出这个意图。在线服务层负责“闪电响应”。当用户请求到来时在线服务快速从近线层获取最新的用户向量然后从向量数据库中检索最相似的物品向量近似最近邻搜索ANN。同时并行触发其他召回通道如规则召回、热门召回的逻辑。最后将多路结果融合、过滤如去掉已曝光、已购买的返回给排序阶段。整个过程必须在百毫秒内完成。3. 核心模型技术深度解析从双塔到多兴趣建模向量召回模型是当前召回效果的天花板其演进体现了对用户兴趣建模不断深化的过程。3.1 基石双塔模型DSSM范式双塔模型是向量召回的经典架构顾名思义它有两个“塔”。一个塔用户塔输入用户特征用户ID、历史行为序列、画像标签等输出一个用户向量。另一个塔物品塔输入物品特征物品ID、内容属性等输出一个物品向量。训练时将正样本用户点击/购买的物品的用户向量和物品向量做内积使得结果尽量大同时进行负采样随机选择一些用户未交互的物品作为负样本使得负样本对的内积尽量小。损失函数常用交叉熵或对比学习损失。它的优势在于结构清晰、线上服务效率高。物品向量可以全部离线计算好存入索引线上只需要计算一次用户向量然后做高效的向量检索即可。但它的一个核心局限在于将用户丰富的兴趣压缩成了单个向量。这好比用一句话来概括一个人的全部喜好难免会丢失细节导致召回不够精准。3.2 演进多兴趣提取网络MIND为了克服单向量表示的局限阿里巴巴提出了MINDMulti-Interest Network with Dynamic Routing模型。MIND认为一个用户可能同时拥有多个不同的兴趣维度。例如一个年轻妈妈可能同时关注“母婴用品”、“美妆护肤”和“职场通勤装”。MIND的核心是动态路由Dynamic Routing机制它借鉴了胶囊网络的思想。模型将用户的历史行为序列作为输入通过多兴趣抽取层动态地将这些行为聚类到几个不同的兴趣胶囊中。每个兴趣胶囊输出一个向量代表用户的一个独立兴趣维度。线上服务对于同一个用户MIND会产出多个兴趣向量例如K个。在召回时用这K个向量分别去向量库中检索每个兴趣召回Top-N个物品最后将K*N个结果合并去重。这样召回结果就能同时覆盖用户多个方面的兴趣大大提升了召回的多样性和覆盖率。实操心得K值的选择是个关键超参。太小可能无法分离兴趣太大则可能引入噪声并增加计算开销。通常需要根据平台用户行为的丰富度通过AB实验来确定一般在3-8之间。3.3 深化序列深度匹配模型SDM如果说MIND关注的是用户并行的多兴趣那么SDMSequential Deep Matching则更关注用户序列化的兴趣演变。它认为用户近期行为和长期行为具有不同的意义且行为间的顺序关系蕴含重要信息。SDM将用户行为序列分为两个部分短期会话行为最近一段时间内如一小时的连续点击序列。这部分行为反映了用户当前的即时意图和情境例如连续浏览多款跑步鞋可能正打算购买。长期历史行为过去较长时间内如一周的所有行为。这部分代表了用户稳定的兴趣偏好。模型分别用不同的网络如Transformer或GRU对短期序列和长期序列进行建模得到短期兴趣向量和长期兴趣向量。然后通过一个门控网络Attention来融合二者生成最终的用户向量。这个门控网络能自适应地决定在当前请求下是更依赖短期意图还是长期偏好。SDM的强大之处在于对时序信号的捕捉。例如用户刚搜索了“手机”然后浏览了几款“手机壳”SDM能更好地理解这种序列依赖从而在召回时不仅召回手机也能精准召回匹配的手机壳实现了类似“购物车”的联想召回。3.4 模型选型与融合的考量在实际生产中我们很少只使用单一模型而是采用分层、分场景的策略主流流量可能采用MIND SDM结合的方式。用MIND保证兴趣的多样性覆盖用SDM捕捉实时和序列意图。两者召回的结果再进行融合。冷启动场景对于新用户或新物品深度模型可能失效这时需要内容召回CB和热门召回扛起大梁。效率优先场景对于实时性要求极高的场景如信息流刷不停经典的双塔模型因其计算效率高依然是不可或缺的保底选择。注意模型越复杂线上服务的成本计算、内存、延迟就越高。MIND需要计算K次向量检索SDM需要维护和实时更新用户行为序列。工程师必须在效果和效率之间做出精心的权衡通常会对高频用户使用复杂模型对低频用户使用轻量模型。4. 工程实现与核心环节剖析有了好的模型还需要坚实的工程实现才能发挥威力。这里重点剖析向量召回线上服务的关键环节。4.1 向量索引构建与近似最近邻搜索ANN全量物品向量可能高达数十亿对每个用户向量进行精确的全局计算暴力搜索耗时是不可接受的。因此必须使用近似最近邻搜索ANN技术在可接受的精度损失下将检索耗时从线性降低到亚线性甚至对数级。常用的ANN库和算法有算法/库原理简介适用场景注意事项Faiss (Facebook)提供了多种索引如IVF倒排文件、HNSW分层可导航小世界图、PQ乘积量化。HNSW在速度和精度上平衡较好是目前主流。十亿级别向量库高精度要求。需要将向量全部加载到内存内存消耗大。调参复杂efConstruction, efSearch, M等参数。Annoy (Spotify)基于随机投影树构建森林进行搜索。千万级别内存敏感简单易用。索引是只读的更新需要重建。精度通常比HNSW稍差。SCANN (Google)结合了分区、量化等技术的先进ANN库。超大规模向量检索对精度和速度有极致要求。配置相对复杂社区资源较Faiss少。Milvus / Weaviate开源向量数据库封装了底层ANN索引提供增删改查的数据库服务。需要动态更新向量、进行多条件过滤标量向量混合查询的场景。引入数据库开销纯检索性能可能低于直接使用Faiss。实操步骤示例以Faiss HNSW为例离线索引构建import faiss import numpy as np # 假设 item_embeddings 是 numpy 数组形状为 [num_items, embedding_dim] embedding_dim 128 num_items 1000000 # 创建 HNSW 索引 index faiss.IndexHNSWFlat(embedding_dim, 32) # 32 是 HNSW 的“M”参数影响连接数 index.hnsw.efConstruction 200 # 构建时的搜索深度影响构建质量和速度 # 添加向量需要先转换为float32 item_embeddings item_embeddings.astype(float32) index.add(item_embeddings) # 保存索引到磁盘 faiss.write_index(index, item_vectors_hnsw.index)在线服务加载与查询# 在线服务启动时加载索引 index faiss.read_index(item_vectors_hnsw.index) index.hnsw.efSearch 100 # 搜索时的深度越大越准越慢 # 收到用户请求计算用户向量 user_vec (shape: [1, embedding_dim]) user_vec user_vec.astype(float32) k 1000 # 需要召回的数量 distances, indices index.search(user_vec, k) # indices 就是召回物品的ID列表4.2 用户实时向量更新为了捕捉用户实时兴趣用户向量不能只用离线天级别数据计算。主流做法是部署一个用户向量实时更新服务。触发与计算当用户发生关键行为点击、搜索、下单时将行为事件用户ID 物品ID 时间戳 类型发送到消息队列如Kafka。流处理流计算引擎如Flink消费这些消息获取用户最新的行为序列例如最近50次点击并调用一个轻量级的实时模型可能是简化版的SDM或RNN来快速计算新的用户向量。这个模型通常比离线模型小只使用最近的数据。存储计算出的新用户向量立即写入高速缓存如Redis键为用户ID值为向量数据。过期时间设置为几小时到一天平衡实时性和存储成本。在线服务读取当召回服务收到请求时首先尝试从Redis中读取该用户的实时向量。如果存在且未过期则使用它否则回退到使用离线计算的长期向量。4.3 多路召回的结果融合与过滤各召回通道返回的结果需要经过合并、过滤、截断才能形成最终的候选集。去重不同通道可能召回相同的物品需要根据物品ID进行去重。过滤应用业务规则过滤掉不应出现的物品例如用户已购买或已明确不喜欢的物品。当前用户不可见如下架、无库存、地区限制的物品。质量分过低或违规的物品。融合与截断这是策略核心。简单做法是“按路截断全局混排”每路召回固定数量如向量召回1000协同过滤500合并去重后可能得到一个2000条的集合再随机或按简单规则如发布时间打乱取前N条如1500条送给排序。更复杂的做法会引入粗排模型用一个非常轻量级的模型如逻辑回归、浅层神经网络对合并后的几千个候选进行快速打分按分数取Top确保送入精排的都是“潜力股”。5. 效果评估、常见问题与调优实战召回系统的好坏不能凭感觉必须建立科学的评估体系并在实践中持续调优。5.1 核心评估指标召回率Recall这是最直接的指标。定义是召回率 系统召回的相关物品数 / 全量相关物品数。但在线上无法获取“全量相关物品”所以通常用离线测试集来近似评估。在A/B测试中更关注下游排序后核心业务指标的提升如点击率CTR、转化率CVR、人均停留时长等。召回优化最终要服务于这些业务指标。覆盖率Coverage指被召回系统“触及”过的物品占总物品库的比例。高的覆盖率意味着系统能挖掘长尾物品促进生态健康。如果覆盖率过低说明系统总是推荐热门物品不利于新品和中小商家。新颖性/多样性衡量推荐结果是否千篇一律。可以通过计算推荐列表中物品品类、品牌的熵或者两两物品之间的相似度来度量。线上服务指标延迟Latency和吞吐量QPS是生命线。必须严格监控P99延迟确保满足业务要求如100ms。5.2 常见问题与排查技巧实录问题1线上效果波动大时好时坏。排查思路检查数据管道首先确认离线特征生成、模型训练的数据源是否稳定、一致。是否存在数据缺失、特征计算逻辑变更检查模型更新模型是否按预期定时更新新模型版本上线后离线评估指标是否正常线上向量索引是否同步更新检查实时链路用户实时向量更新服务是否正常Redis缓存是否满或延迟高实时行为数据流是否中断查看业务波动是否与节假日、大促活动相关可能是正常业务波动。实操心得建立完善的监控大盘涵盖从数据源-特征工程-模型训练-索引构建-在线服务的全链路关键指标。一旦波动能快速定位环节。问题2召回结果总是偏向热门物品长尾物品出不来。原因与对策样本偏差训练数据中热门物品的曝光和点击本就多模型自然学得更好。需要在训练时进行纠偏例如对热门物品进行降采样Down Sampling或对长尾物品进行过采样Up Sampling。损失函数问题标准的交叉熵损失容易让模型“偷懒”只学好预测热门物品就行。可以尝试加权交叉熵给长尾样本更高权重或使用对比学习损失InfoNCE它通过构造正负样本对更能拉大同类与不同类样本的距离有利于学习长尾特征。增加专门的长尾召回通道设计一路基于“探索”策略的召回例如UCB置信上界算法主动召回那些曝光少但有潜力的物品。问题3ANN检索精度下降导致线上效果劣化。排查与调优确认索引参数检查HNSW的efSearch参数。线上查询时为了速度可能设置得过低如16适当调高如64或128能提升精度但会增加延迟。需要在效果和延迟间做权衡测试。检查向量质量离线评估模型在新数据上的表现是否下降可能是模型本身需要重新训练或调整。向量维度是否对齐确保在线服务加载的索引其向量维度与模型输出的维度完全一致。这是一个低级但一旦发生就是致命的问题。考虑量化误差如果使用了乘积量化PQ来压缩索引以节省内存会引入误差。可以尝试减少量化段数或使用更高精度的量化方式。问题4新用户/新物品冷启动推荐效果差。解决方案对于新用户在用户向量不可用或很稀疏时果断降级到非个性化召回如热门榜、趋势榜、地域热门、注册时选择的兴趣标签召回等。同时可以设计“探索性”问题或交互快速收集用户反馈。对于新物品利用内容特征在物品塔中除了ID类特征一定要加入丰富的内容特征标题、类目、属性、图片嵌入向量等。这样即使物品ID是新的其内容特征也能让它被相关用户召回。流量扶持策略在召回阶段为新物品设置一个保量规则例如在召回结果中强制插入一定比例的新品给予初始曝光机会。迁移学习使用在大量数据上预训练好的物品内容编码器如BERT for Title来初始化新物品的向量表示。召回系统是一个复杂的系统工程它连接着数据、算法和产品。没有一个一劳永逸的银弹持续的数据分析、敏锐的业务洞察、严谨的AB实验和精细的工程优化才是让这个“海选官”越来越聪明的唯一路径。在实际工作中我深刻体会到召回策略的调整往往能带来排序阶段无法获得的巨大收益因为它决定了赛道的宽度。很多时候花时间深入理解业务场景设计更贴合场景的召回通道例如针对“找同款”的以图搜物召回针对“补货”的周期性购买召回比单纯优化模型参数来得更有效。