相关性推荐落地：item-to-item相似度与召回排序实践

做内容站或电商站的技术同学大概都遇到过这种场面运营在群里甩来一张截图说首页那个“相关性推荐”模块推出来的东西驴唇不对马嘴点进去一看一篇讲咖啡器具的文章底下挂着三款手机壳。开发觉得委屈——相似度明明算出来了分数也不低运营觉得开发不懂业务。这类扯皮在很多网站上都发生过根子往往不在算法写得好不好而在于一开始就没搞清楚相关性推荐到底是为了解决什么问题。如果目标模糊后面所有的分词、向量、召回、排序都是在错误的方向上加精度。相关性推荐说白了就是“你看的这个东西跟另外哪些东西是一路的”。它要回答的问题非常朴素用户当前正在看的这个页面接下来最有可能愿意看什么、买什么、点什么。它不猜用户是什么人也不管用户昨天看过什么只看眼前这一件“东西”和库里其他“东西”的关系。能做的事很实在把用户从“看完就走”变成“再看一个”把无人问津的库存内容重新推到台前把纯靠人肉排的运营位从重复劳动里解放出来。适合谁看我建议三类人认真读一读一是刚接手推荐模块、不知道怎么定指标的后端和算法同学二是被“推荐不准”反复投诉、想知道问题出在哪个环节的产品和运营三是技术负责人需要判断这个模块值不值得投入、投入多少合适。1. 先把问题说清楚相关性推荐到底在跟什么较劲1.1 信息过载下的选择瘫痪是怎么形成的一个正常运营两三年的内容站SKU 或文章量级通常在几万到几十万之间。这个数量级有个尴尬之处它已经远远超出人工编排的覆盖范围但又没有大到必须上复杂推荐系统的程度。人工运营位一天能维护的条目往多了算几十条而站内可分发的内容有几万条覆盖率不到千分之一。剩下的内容基本靠自然流量碰运气碰上的继续涨碰不上的永远躺着。用户侧的困境同样明显。类目导航的层级越做越深因为内容越来越多运营只能不断加分类但用户点进三级类目之后面对的是一个几十条甚至上百条的平铺列表没有任何筛选和引导。这时候用户的真实状态不是“我要挑一个”而是“我看不过来随便点一个或者直接关掉”。选择瘫痪的本质不是选项太多而是选项之间没有区分度用户无法在短时间内判断哪个更符合自己的需求。相关性推荐介入的正是这个环节。它不改变供给总量而是改变供给的呈现顺序把跟当前内容最相关的那几条提到最前面让用户在有限注意力里看到最可能感兴趣的东西。这个动作听起来简单但它把“用户自己在一堆东西里找”变成了“系统替用户先筛一遍”决策成本直接降下来了。1.2 它和“猜你喜欢”根本不是一回事很多团队在这个地方栽跟头把相关性推荐当个性化推荐做一上来就要用户画像、要长期兴趣建模、要跨端打通。方向没错但顺序错了成本也完全不是一个量级。我把两者的差别列成一张表方便对照维度相关性推荐个性化推荐输入信号当前物品的标签、内容、行为共现用户历史行为、画像、上下文计算粒度物品到物品item-to-item用户到物品user-to-item冷启动表现新用户来了就能用新用户几乎无解可解释性强能说清“因为你看的是A”弱经常说不清为什么推这个缓存友好度高相似度矩阵可离线算好低每个用户一套结果工程成本中小团队一周能跑通需要特征平台和实时链路理解这张表的关键在最后两行。物品到物品的相似度是离线可预计算的十万条内容两两算一遍看着吓人但实际只需要为每条内容保留 Top 50 个邻居存储量是可控的。算完之后在线只需要一次键值查询响应时间能做到个位数毫秒。而个性化推荐要为每个用户实时算一遍链路长、依赖多、出故障的概率高得多。所以我的建议很明确先把相关性推荐做扎实再考虑个性化。相关性推荐是地基它产出的物品相似关系后面做个性化召回时照样要用。跳过这一步直接上个性化大概率会得到一个既不准也不好维护的系统。1.3 什么样的网站真的需要它什么样的不需要不是所有网站都值得投入。判断标准其实就一条站内是否存在“内容量超出人工编排能力且内容之间存在可被描述的关系”的情况。典型需要的情况电商站的商品详情页、内容站的文章详情页、视频站的播放页、文档站的词条页、课程平台的课程页。这些页面的共同特征是用户到达时已经表达了一个明确的兴趣点此时给他“关于这个兴趣点的更多选择”接受度天然就高。不太需要的情况单页工具型产品、内容量在几百条以内且关系很弱的站点、用户停留时间本身就以秒计的落地页。给这类站点硬上推荐模块收益覆盖不了维护成本还容易拖慢首屏。还有个容易被忽略的判断依据看跳出率的结构。如果详情页的跳出率明显高于站内其他页面且跳出用户的行为路径高度集中于“看完当前页就离开”那基本可以确认是“下一跳缺失”导致的流失相关性推荐能直接对上这个症状。反之如果跳出主要发生在首页或者落地页那是入口和分发的问题得先解决那边。2. 相关性推荐解决的六类具体问题2.1 找得到搜索意图与内容供给之间的错位站内搜索有个经典现象用户搜的词站内没有完全匹配的内容但有一堆语义相近的。比如用户搜“降噪耳机续航”站内商品标题写的是“无线蓝牙耳机 长待机”关键词对不上搜索结果空空如也。用户不会认为是自己搜错了只会觉得这个站没有他要的东西然后离开。相关性推荐在这个场景里扮演的是兜底角色。搜索无结果或者结果很少的时候用当前查询的语义向量去物品库里做最近邻检索把语义相近的内容补上来。同样搜索结果页的排序也可以引入相关性分数让“标题含关键词但内容不搭”的条目往下沉。这里有个实操细节值得说搜索兜底不要直接用热门填充。搜“降噪耳机续航”给推一堆手机壳用户不但不会点还会对站点的专业度产生怀疑。宁可只给三条真相关的也不要给十条凑数的。2.2 留得住跳出率背后的“下一跳”断档详情页跳出率高很多时候不是内容不好而是用户看完之后没有明确的下一步。人的注意力是有惯性的刚看完一篇讲某款相机镜头的评测此时他对“同价位镜头对比”“该镜头的实拍样张”“配套机身推荐”这类内容的接受度是最高的。如果页面上什么都没有这个惯性就断了用户切走的成本几乎为零。相关性推荐模块在这里的作用是在注意力惯性的窗口期内给一个低成本的继续动作。这个窗口很短我的经验是要让模块在首屏或次屏可见且点击路径不超过一次。有些站把它放在页面最底部用户得滚三屏才能看到效果自然差——滚到底部的用户本来就已经准备离开了。衡量的指标不能只看模块本身的点击率还要看二跳率和人均页面浏览深度。模块点击率高但二跳之后立刻跳出说明推荐的东西吸引力够但承接不住问题在下游页面而不是推荐本身。2.3 卖得动关联购买与客单价的提升逻辑电商场景下相关性推荐最直接的商业价值体现在关联购买上。用户看一台咖啡机配套的滤纸、清洁片、咖啡豆就是天然的关联项。这类推荐的说服力来自使用场景的连贯性而不是价格促销。用户不是因为便宜才买滤纸是因为他意识到“买了机器还得有耗材”。这里必须提醒一个常见误区把“同类商品”当成“关联商品”。用户看 A 品牌的入门款咖啡机你给他推 B 品牌的同价位咖啡机这是替代关系等于在把他往外送。真正该推的是互补品和上下游。这个判断靠内容标签能做出六七成剩下靠共购买数据补如果两个商品在历史订单里高频出现在同一笔交易中那它们就是互补的如果高频出现在不同订单里但同一个人前后买过那更可能是替代关系。这两种关系的推荐策略完全相反。客单价的提升不是靠硬推贵的而是靠凑单逻辑。用户买一件 89 元的商品包邮门槛 99 元此时推荐 15 元的配件转化率远高于推荐 300 元的升级款。这个逻辑在相关性推荐里体现为“价格带约束”需要在重排阶段就把不符合当前价格区间的候选过滤掉。2.4 冷启动新内容如何拿到第一批曝光新上线的商品或文章没有点击、没有收藏、没有共现数据纯行为驱动的推荐系统对它完全无感。这就是马太效应的源头头部内容因为有点击所以获得更多曝光新内容因为没曝光所以永远没有点击。相关性推荐的内容侧信号恰好能解决这个问题。新文章一上线就有标题、标签、正文、类目这些信息不依赖任何用户行为可以直接算出它跟已有内容的相似度从而挂到相应的详情页下面。也就是说新内容从第一天起就有位置可去只是位置的好坏需要靠后续行为数据来调。我做过一个观察在中型内容站纯行为信号驱动的推荐新内容平均要 7 到 10 天才能获得稳定的曝光量引入内容相似度兜底之后这个周期能压缩到 1 到 2 天。对于有时效性的内容比如节气、活动、热点解读这个时间差基本决定了内容有没有价值。2.5 长尾沉睡的腰部内容怎么被重新激活站内内容通常呈金字塔分布头部 5% 拿走 80% 的流量腰部和尾部大量内容几乎无人问津。但这些内容不是没价值是没有被发现的路由。用户不会主动去翻三年前的旧文章但如果他在看一篇相关主题的新文章时旁边恰好挂着那篇旧文的链接他是有可能点进去的。相关性推荐提供的正是这种“路由”能力。它把内容之间的语义关系建成一张图任何一次访问都可能成为某个长尾节点的入口。这个过程不需要额外生产成本纯粹是存量价值的再分配。不过要注意长尾内容被激活之后质量参差的问题会暴露出来。有些旧文的内容已经过时标题还写着“最新”用户点进去发现信息陈旧反而损伤信任。我的处理办法是在候选集里加一条时效过滤规则超过一定时限的内容在进入推荐池之前先做一次人工或半自动的复核不符合当前情况的直接排除而不是让它靠相似度混进来。2.6 省人力把运营从重复编排里解放出来这一条经常被低估但对中小团队来说可能是最实际的价值。人工维护“相关推荐”这类模块本质是在做一件高度重复的事每上新一批内容就得手动去配关联。内容量一大运营根本配不过来最后要么放弃要么用一套固定的通用列表糊弄过去。把这部分工作交给相关性计算运营的角色就从“逐条配置”变成“定规则、抽查、处理异常”。人力从 O(内容量) 降到 O(规则数)这个量级变化对小团队来说是决定性的。我一般的做法是保留人工干预的口子系统自动生成候选运营可以对特定条目做置顶、屏蔽、替换。既不失去自动化带来的效率也不至于完全失控。关键是干预要有记录哪些条目被人工改过、改的原因是什么这些数据积累下来反过来能帮你发现算法的系统性偏差。3. 相关性是怎么算出来的核心链路的拆解3.1 三路信号内容、行为、上下文相关性计算本质上是在定义“两个东西有多像”而“像”这件事可以从三个角度看每一路信号解决不同的问题。内容信号标题、正文、标签、类目、属性。这路信号的优势是覆盖全、不依赖行为数据新内容一上线就能算劣势是无法表达“语义之外的用户偏好”比如两篇文章字面很像但读者群体完全不同。行为信号共点击、共收藏、共购买、同一次会话内的先后访问。这路信号直接反映真实偏好效果好得多但有严重的冷启动和稀疏性问题新内容没数据小众内容数据太少算出来的共现频次全是噪声。上下文信号时间、位置、设备、来源渠道。比如早上推的内容和深夜推的内容用户接受度不一样从搜索引擎来的用户和站内老用户行为路径也不一样。这路信号通常不参与相似度计算而是在重排阶段做调整。我的经验配比是内容信号占四到五成作为基础行为信号占三到四成作为修正上下文占一到两成做微调。这个比例不是固定的行为数据积累得越多行为信号的权重可以越高数据稀疏的业务线内容信号的权重就得往上提。3.2 从词袋到向量相似度算法的取舍最朴素的做法是词袋加余弦相似度。原理不复杂把每条内容表示成一个词频向量两两算夹角余弦值越接近 1 越相似。优点是实现简单、可解释、算得快缺点是完全丢失语序和语义“手机壳”和“手机”在词袋模型里可能因为共享一个词而算出很高的相似度。我拿一个真实的小例子演示一下这个过程也顺带说明为什么纯内容相似度往往不够用。假设语料只有三篇内容要算 A 和 B 的相似度A轻薄 / 笔记本 / 续航B笔记本 / 电池 / 续航先算 IDFN3轻薄出现 1 次IDF ln(3/1) ≈ 1.099笔记本出现 3 次IDF ln(3/3) 0续航出现 2 次IDF ln(3/2) ≈ 0.405电池出现 1 次IDF ≈ 1.099。A 的向量轻薄 1.099笔记本 0续航 0.405 B 的向量笔记本 0电池 1.099续航 0.405余弦 (0.405×0.405) / (1.171×1.171) ≈ 0.12这个 0.12 说明了两个问题。第一“笔记本”这个词因为在三篇里都出现IDF 被压成了 0完全失去了区分度——它恰恰是 A 和 B 最该共享的核心词。第二最终相似度低得离谱而人类一眼就能看出这两篇讲的是同一件事。这就是词袋模型的局限它只能捕捉字面重合捕捉不到语义。改进方向有几个。用 BM25 替代 TF-IDF能缓解长文本的权重失衡引入词向量或句向量做语义相似度能解决同义不同词的问题代价是需要模型和额外的推理开销引入行为共现作为主信号内容相似度只做兜底这是工程上最务实的方案。算法选型上我的建议是不要追求单一路径的极致。内容相似度负责召回广度行为共现负责精度两路结果合并去重效果通常比单独优化任何一路都好。3.3 召回、排序、重排的三段式落地在线服务不可能每次都全库扫描必须拆成三段。召回阶段要快目标是从几十万条里捞出几百条候选。常见做法是离线把每条内容的 Top N 邻居算好存到键值存储里在线一次查询直接拿到。N 一般取 50 到 200取决于后续排序环节的算力。这个阶段的评价指标是召回率真正相关的内容有没有被捞进来。捞不进来的后面再怎么排都没用。排序阶段要对候选打分。基础分可以来自离线相似度再叠加实时特征当前内容的实时热度、候选内容的近期点击率、类目匹配度、时效性。这阶段可以上模型也可以先用加权规则跑起来看效果再决定要不要升级。重排阶段处理业务约束去重同一作者、同一品牌最多出两条、打散避免连续三条都是同一类目、过滤下架、缺货、违规内容、位置分配。很多推荐效果差问题不在排序分数而在重排规则写得太粗暴。3.4 权重融合与打分公式的实操配置给一个可以直接拿来改的配置示例权重值只是起点实际要按业务调# 候选打分权重融合示例 WEIGHTS { content_sim: 0.45, # 内容相似度0~1 co_click: 0.30, # 行为共现归一化分0~1 category: 0.15, # 类目匹配1 或 0 freshness: 0.10, # 时效衰减0~1 } def score(cand, ctx): s ( WEIGHTS[content_sim] * cand.content_sim WEIGHTS[co_click] * cand.co_click_norm WEIGHTS[category] * (1.0 if cand.cate ctx.cate else 0.0) WEIGHTS[freshness] * decay(cand.publish_ts, ctx.now) ) # 价格带约束偏离当前页商品价格带超过 2 倍的直接降权 if ctx.price_band and not in_band(cand.price, ctx.price_band, 2.0): s * 0.3 return sdecay函数用指数衰减就够exp(-λ * days)λ 取 0.02 到 0.05 之间。0.02 意味着 35 天衰减到一半适合内容更新慢的站点0.05 意味着 14 天衰减一半适合资讯类。这个参数不要拍脑袋定去看站内内容点击量的半衰期对齐着设就行。排序之后的最终展示分还要考虑位置偏差校正。同一个条目放在第一位和第五位点击率能差三到五倍。如果训练或调参时不做校正模型会学成“位置越靠前越好”而不是“内容越相关越好”。简单的做法是用历史数据统计各位置的基准点击率把实际点击率除以基准得到归一化的相关性反馈。4. 实操把一个最小可用的相关性推荐跑起来4.1 数据准备与埋点设计上线之前先把数据打点确认清楚这一步偷懒后面所有分析都是空中楼阁。最少要采四个字段曝光事件模块 ID、请求 ID、条目 ID、位置序号、时间戳。没有曝光数据你连点击率的分母都算不出来。点击事件请求 ID、条目 ID、位置、时间戳。用请求 ID 关联曝光才能确认这次点击来自哪一次曝光。停留/转化事件点击后的停留时长、是否发生目标行为加购、下单、读完、收藏。上下文来源页面 ID、设备类型、是否登录。有个细节必须一开始就定好请求 ID 要贯穿一次页面渲染的全部曝光。否则同一屏里出了五条推荐你分不清用户点的是哪一条对应的哪一次曝光。注意曝光打点不要只在服务端返回时打用户没滚动到模块位置就不算真正看到。比较稳妥的做法是前端做可见性判定模块进入视口超过一定时长再上报曝光。否则算出来的点击率会系统性偏低。4.2 离线相似度矩阵的构建流程离线任务一般每天跑一次数据量大的话按类目分片跑。流程是固定的几步拉取全量内容元数据ID、标题、标签、类目、正文摘要。文本清洗去 HTML 标签、去停用词、繁简统一、全半角统一。分词并构建词表计算每条内容的 TF-IDF 向量。按类目分桶桶内两两计算余弦相似度。分桶能把计算量从 O(n²) 降到 Σ O(ni²)效果非常显著。每类目取 Top 100 邻居按阈值过滤分数低于 0.15 的直接丢弃避免噪声。融合行为共现分数把过去 30 天的共点击矩阵按同一套 ID 对齐做归一化后加权合并。结果写入键值存储键为内容 ID值为邻居列表含分数。# 离线相似度计算的骨架 import math from collections import defaultdict def build_similarity(docs, top_k100, min_score0.15): # docs: {item_id: [term, term, ...]} df defaultdict(int) for terms in docs.values(): for t in set(terms): df[t] 1 n len(docs) idf {t: math.log(n / c) for t, c in df.items()} vecs {} for iid, terms in docs.items(): tf defaultdict(int) for t in terms: tf[t] 1 vecs[iid] {t: (1 math.log(c)) * idf[t] for t, c in tf.items()} result {} ids list(vecs) for i in range(len(ids)): a vecs[ids[i]] norm_a math.sqrt(sum(v * v for v in a.values())) or 1.0 sims [] for j in range(len(ids)): if i j: continue b vecs[ids[j]] norm_b math.sqrt(sum(v * v for v in b.values())) or 1.0 dot sum(v * b.get(t, 0.0) for t, v in a.items()) s dot / (norm_a * norm_b) if s min_score: sims.append((ids[j], s)) sims.sort(keylambda x: -x[1]) result[ids[i]] sims[:top_k] return result这段代码在几十万条内容上跑会慢生产环境要用矩阵运算或者分片并行。但用它验证逻辑、跑小数据集完全够用我一般先用它把效果跑通再考虑性能优化。4.3 在线服务的缓存与降级策略在线接口的要求很简单快、稳、有兜底。展开说三层。第一层是本地缓存。相似度结果变化不频繁可以在服务进程内做一层 LRU 缓存命中率通常能到 90% 以上单次查询几百微秒就能返回。第二层是共享缓存。本地没命中就去查共享的键值存储响应在个位数毫秒。这里要注意设置合理的超时别让一次慢查询拖垮整个页面渲染。第三层是降级。缓存全部失效、上游不可用时不能返回空白。降级策略按优先级排同类目热门 同标签热门 全站热门。降级一定要有监控埋点否则你会长期在降级状态下运行而毫不知情。注意降级用的“热门池”要按类目细分不能用全站一个大热门池。全站热门池在垂直类目页面上的相关性极差属于典型的“模块还在但等于没有”。还有一个容易踩的坑相似度矩阵是每天更新的但内容是有增删的。如果新内容当天入库但矩阵还没刷新它作为“被推荐方”没问题矩阵里有它但作为“当前页面”去查邻居就会查空。处理方式是给新内容做一个临时的兜底查询用它的标签实时去检索同类目内容等第二天矩阵刷新后自动切回正常链路。4.4 效果验证A/B 实验怎么设才不算白做上线前先想清楚衡量什么。至少准备三层指标层级指标说明模块层曝光点击率、人均点击次数判断模块本身有没有吸引力站外层页面停留时长、二跳率、人均浏览页数判断推荐有没有带动整体消费业务层转化率、客单价、次留判断商业价值样本量要提前算别跑两天看数据差不多就下了结论。用这个简化公式估算每组的曝光需求n 16 × p(1-p) / Δ²假设基线点击率 3%希望检测出 0.3 个百分点的绝对提升Δ 0.003代入得 16 × 0.03 × 0.97 / 0.000009 ≈ 51700。也就是每组大概需要 5.2 万次曝光两组加起来 10 万出头。日曝光一万的站点实验要跑十天以上。很多团队跑到第三天觉得数据“明显更好”就全量了后面大概率会被打回原形。实验期间要锁住变量不要同时改版式、不要同时调价格、不要同时上大促。如果有不可避免的变化就在分流时做分层把影响控制在小范围内。5. 踩坑记录与排查速查表5.1 用热门冒充相关性短期好看长期伤这是最常见的偷懒做法模块标题写着“相关推荐”实际返回的是全局销量榜。上线初期数据往往还不错因为热门内容本身点击率就高但过一两周就会看到问题——用户在任何一个页面看到的都是同一批内容模块的边际点击率会快速衰减而且用户会逐渐形成“这个位置是广告”的认知直接无视。判断方法很简单统计模块内条目的重复曝光率。如果同一批内容在 80% 的页面里都出现那它就不是相关性推荐是换了个位置的热门榜。健康的分布应该是长尾的Top 100 条目覆盖的曝光不超过总量的 30%。5.2 相似度分数很漂亮点击率却很难看这种情况我遇到过好几次原因通常有三类。第一类是相似但无用。两篇文章主题确实一样但一篇是入门科普一篇是深度技术分析用户看完入门篇之后对深度篇的接受度并不高。这说明“内容相似度”不等于“消费递进关系”。解决办法是引入用户行为序列统计“看完 A 之后实际看 B”的频次用它修正内容相似度。入门到入门、入门到进阶、进阶到实战这些路径的强度是不一样的。第二类是同质化过重。推出来的五条都是同一款商品的不同颜色或者同一作者的三篇文章。用户觉得“没得选”。这要在重排阶段加规则同品牌、同作者、同主图的内容最多出一条。第三类是位置和展示形式不匹配。同样的内容用纯文字列表展示和用带图卡片展示点击率能差一倍以上。如果模块本身视觉上不吸引人再准的推荐也没人点。这种情况优化算法是南辕北辙得回去改样式。5.3 数据侧的几个隐蔽陷阱位置偏差前面提过不做校正会让模型误以为位置靠前就是相关。表现是模型上线后总是把同一批内容排在前面形成自我强化。数据泄漏用全量历史数据训练包含了实验期之后的数据线下指标虚高。做时间切分训练集一定在测试集之前。反馈闭环失真推荐系统只给用户看候选池里的内容池子外的内容永远拿不到反馈于是池子外的内容永远被认为“不相关”。这就是所谓的曝光偏差。缓解办法是在候选里强制掺入一定比例的非热门内容作为探索位。ID 对齐失败内容侧和行为侧用的是两套 ID或者中间做过迁移导致 ID 变更共现矩阵算出来全是零。这个坑非常隐蔽表现是“行为信号完全不起作用”。上线前一定要抽样核对两边的 ID 能不能对上。5.4 问题排查速查表现象可能原因排查动作模块全程返回同一批内容降级策略触发或相似度矩阵未更新查降级监控、查离线任务最近一次成功时间新内容从不出现矩阵未刷新或内容未进入召回池核对新内容的入库时间与矩阵刷新时间点击率骤降上游内容变更、过滤器误杀对比变更前后候选集数量与分布推荐结果与当前页完全无关ID 对齐错误、类目映射错误抽样打印当前页 ID 与其邻居 ID某些类目永远无推荐该类目内容太少走不到阈值查类目内容量考虑跨类目召回线上效果远差于离线评估位置偏差未校正、数据泄漏用线上日志重算离线指标做对比6. 一些容易被忽略的边界与取舍6.1 相关性和多样性之间的拉扯纯粹追求相关性结果一定是同质化。用户的兴趣是有宽度的连续看五条一模一样的东西从第三条开始就疲劳了。所以实际系统里必须人为引入多样性。常见做法是在重排阶段做 MMR最大边际相关式的贪心选排每选一条就把它和已选条目的相似度作为惩罚项扣减剩余候选的分数。公式大致是score_i - λ × max_sim(i, 已选集合)λ 取 0.2 到 0.4 之间。λ 越大越多样但相关性损失也越大。这个参数没有普适最优值得看场景。商品详情页的关联推荐λ 要小一点因为用户在这个位置就是奔着强关联去的资讯流的推荐位λ 可以大一些用户对新鲜感的容忍度更高。6.2 它解决不了的问题别硬让它解决这点必须说清楚否则会导致对系统能力的错误预期。相关性推荐解决不了供给质量问题。站内内容本身写得差、商品本身评价低推荐得再准也只是把差东西更快地送到用户眼前反而加速用户流失。这类问题得回到生产端解决。它解决不了用户的探索需求。“我也不知道想看什么随便逛逛”这种状态本质上需要的是多样性探索和惊喜感而相关性推荐的逻辑是收敛而不是发散。这类需求要靠榜单、专题、编辑精选去承接。它也替代不了搜索。用户明确知道自己要什么的时候搜索的效率远高于推荐。相关性推荐的正确定位是搜索的补充不是替代。6.3 一个容易被低估的投入评估与标注大部分团队在算法和工程上投入很多在评估上投入很少最后陷入“上线了但不知道好不好、改了也不知道有没有变好”的状态。我的建议是项目一开始就留出 10% 到 15% 的精力做评估体系。最基础的是抽样人工标注随机抽 200 个页面看每个页面推荐出的内容是否真的相关打三档分相关、勉强、不相关。这个动作一次只要几个小时但它能给你一个不依赖点击数据的客观基线也能在线上指标异常时快速定位是数据问题还是内容问题。稍微进阶一点可以做离线评估集固定一批查询和对应的正确结果每次算法迭代都在这批数据上跑一遍看召回率和准确率的变化。这套东西建起来之后迭代速度会明显加快因为你有了一个不用等线上数据的快速反馈通道。我在实际项目里的体会是相关性推荐这个模块的成败八成取决于前期有没有把“解决什么问题”想清楚两成取决于算法选得好不好。见过太多团队花三个月调模型最后发现真正的问题是新内容进不了召回池、或者降级策略一直在生效。先把数据链路打通、把降级和监控做扎实、把评估基线建起来再回头优化算法顺序反了就是白费力气。另外分享一个很实用的小技巧给模块加一个内部调试参数在 URL 上带上就能看到每条推荐的来源、分数构成和命中的规则。运营报问题的时候让他带上这个链接能省掉大量来回沟通。