做推荐系统这几年我最深的感触是单一目标优化很多时候是自欺欺人。你盯着CTR调了一版模型离线涨了2%上线后人均时长反而降了用户点完就走。多目标优化及偏好策略推荐算法本质上是在解决“多个指标互相打架时到底听谁的”这个问题——这不只是算法题更是产品策略题。这篇文章我会从问题拆解、偏好建模、算法选型、代码实现到踩坑复盘完整讲一遍我在模拟项目X里的落地过程里面所有代码都是可以直接跑的轻量版本不是那种贴个框架调用就完事的演示代码。1. 为什么推荐系统一定要做多目标优化1.1 单一目标的“赢家”往往是整体体验的输家早期做推荐的时候很多人习惯把模型训练目标定成点击率预估因为点击是最容易拿到、也最容易定义正负样本的行为。我见过不止一个团队把CTR模型调得特别漂亮离线AUC一路涨上线之后首页确实“活”了但细看数据就会发现用户点得多了停留时间却短了收藏和分享反而少了。原因是模型学到了“吸引点击”的模式而吸引点击最廉价的方式是标题党、封面党甚至故意制造认知缺口。用户被吸引进来发现内容不符合预期很快就退出了。这会带来一个恶性循环用户行为数据里“点击后快速退出”的比例越来越高模型以为用户喜欢这类内容继续加量推送最后整个推荐流变成“高点击、低质量、低留存”的垃圾场。所以在真实的推荐系统里唯一目标几乎不存在。哪怕业务方嘴上说“我们只看CTR”你往下拆一层也会发现他们同时在意时长、留存、互动、转化。多目标优化要做的不是把几个目标简单缝在一起而是把推荐系统的“好坏”真正还原成多维度的、互相牵制的整体。1.2 推荐场景里最常见的4组冲突目标想落地多目标优化先要知道哪些目标会打架。我在模拟项目X里整理过一张内部清单最典型的四组冲突是目标A目标B冲突点点击率消费时长点击高的内容往往不“耐看”用户点完就走消费时长内容多样性一直推同类内容时长会涨但用户很快疲劳商业收益用户体验广告和商品穿插越多短期收益越高留存越差老内容利用率新内容探索老内容行为数据充足模型给高预估新内容容易被系统性埋没这些冲突不是某个算法能“消灭”的它们是业务本身的张力。比如时长和多样性如果你只优化时长推荐流会越来越窄用户每天看到的都是同一种套路可能一周后就开始流失如果你只优化多样性用户又会觉得“推荐的都是我不关心的”。多目标优化就是在这些互相拉扯的目标之间找一条可接受的折中曲线而不是找“最优”。这条曲线在数学上的名字叫帕累托前沿。1.3 多目标优化不是“加权平均”而是集合与排序说到“多目标”很多人第一反应是把几个指标加权求和比如分数 0.4×CTR预估 0.3×时长预估 0.3×多样性分。这种做法不是不能用但它本质上把多目标问题压缩成了单目标问题权重一旦定错结果会非常偏。更关键的是加权平均天然假设了“目标之间可以线性互换”——你会愿意用1个点击换0.5个小时时长吗不同用户可能给出完全不同的答案。多目标优化更通用的做法是先找到一组各目标做得都不算差的候选解这些解互相之间没有绝对优劣即A在点击率上更好B在时长上更好谁也无法支配谁。然后在推荐时根据当前用户的偏好从这组候选里挑一个最合适的。也就是说多目标优化负责“生产候选”偏好策略负责“做选择”。这两件事必须分开合在一起就容易变成拍脑袋定权重。2. 偏好策略的核心把“用户想要什么”变成可计算的方向2.1 偏好不是一种感觉而是目标向量上的权重前面提到推荐时要根据用户偏好从帕累托集合里选解。那么用户偏好怎么表达最直接的方式是一个权重向量比如w (w_click, w_duration, w_diversity, w_novelty)每个分量对应一个优化目标的方向。用户的“喜欢”不是一个抽象感觉而是“更愿意点击”“更愿意长时间阅读”“喜欢尝鲜”这些可量化的倾向。在模拟项目X里我把偏好来源分成两类。一类是显式反馈包括用户点“不喜欢”、拉黑作者、收藏、分享这些信号含义明确可以直接变成对某个目标的惩罚或奖励另一类是隐式反馈比如停留时长、滚动速度、是否看到最后、隔多久回访这些信号噪声大需要做归一化和平滑。比如停留时长不能直接当“喜欢”看一篇长文章的停留60秒和一篇短视频的停留60秒意义完全不同得先除以内容的预期时长。2.2 时间衰减用户的偏好会漂移用户不是静止的。上个月天天看长文的人这个月可能只有通勤时间刷刷短视频上周喜欢美妆话题这周可能迷上户外露营。如果偏好向量永远用历史全量统计推荐结果必然滞后。我做了一个时间衰减的偏好统计模块核心思路是给行为数据加指数衰减权重。距离当前时间越近的行为对偏好向量的贡献越大。计算公式大概是weight exp(-lambda * days_since)lambda控制衰减速度一般按目标兴趣的半衰期来设。比如短内容消费行为衰减快lambda可以大一些长期内容偏好衰减慢lambda小一些。如果一个用户近三天频繁划走视频他的“短视频偏好权重”就会明显下降如果一个用户连续七天都在某个话题下收藏那么“深度阅读偏好”就会上升。这个模块不需要很复杂但比直接取均值实用得多。2.3 个体偏好与群体偏好如何协同偏好策略不能只靠用户个人历史。新用户没有足够行为数据老用户的短期行为又可能受热点影响而失真。所以我在项目里把偏好分成两层群体偏好层用所有用户最近一段时间的整体行为分布刻画当前平台的内容风向比如“本周大家更爱看轻松内容”个体偏好层根据单个用户的近期行为计算个性化权重。最终使用的偏好向量是个体偏好和群体偏好的加权融合。当个体行为数据稀疏时群体偏好占大头数据充足时个体偏好权重逐步提高。同时我给个体偏好设了上下限防止某个极端行为把向量带偏。比如连续看了十篇王者荣耀攻略不代表用户就只能看游戏内容他只是这一周刚好在补课。3. 算法选型为什么我选择偏好向量引导的分解式多目标优化3.1 加权和方法的失效Case刚开始做模拟项目X时我试过最简单的加权和方法。当时业务给了三个目标点击率、人均时长、多样性。我们人工调了一版权重离线评测表现不错上线后却发现一个奇怪现象推荐列表里出现了大量“点击率极高但内容非常轻量”的短视频。原因是点击率目标和时长目标互斥时加权和会把矛盾直接“平均”掉解不是落在帕累托前沿上而是落在某个目标特别差、另一个目标特别好的极端区具体落在哪完全看权重数值。后来做了个实验把点击率权重从0.4调到0.5离线指标里的“平均单次时长”波动超过10%。这就说明加权和的解对权重过于敏感产品侧改一个小数点线上推荐结果可能全变了。权重的微小扰动被目标之间的冲突放大最后团队光调权就调了两周。那时候我意识到靠人肉调权重的“伪多目标”走不远。3.2 非支配排序与帕累托解集真正进入多目标优化的思路以后第一步是理解非支配排序。一个解a支配另一个解b需要满足a在所有目标上都不比b差并且至少在一个目标上严格优于b。如果两个解各有胜负谁也不支配谁它们就都在同一个非支配层共同组成帕累托前沿。这个思路启发了一个很重要的改变我们不再直接给用户推荐“唯一最优解”而是离线用进化算法跑一批尽量逼近帕累托前沿的候选解推荐时再按偏好挑。这样点击率、时长、多样性就不是你死我活的关系而是可以并行存在的多个候选。用户喜欢什么口味就选哪个方向的解。3.3 偏好向量引导的MOEA/D实现思路在候选解生成阶段我最终选了基于分解的多目标进化算法MOEA/D的轻量实现而不是NSGA-II。原因有三点第一我们的目标函数都是轻量的预估分数评估代价低适合进化算法反复迭代第二MOEA/D天然支持“偏好方向”的概念每个子问题就是一组权重向量正好可以对应不同用户偏好第三它实现起来比NSGA-II简单调参空间也更可控。具体思路是预先生成一组均匀分布的权重向量每个权重向量代表一种“可能的用户偏好方向”。每个权重向量对应一个子问题子问题的目标是让“当前个体的加权切比雪夫距离最小”。进化过程中每个个体都往自己子问题的方向优化同时相邻子问题之间互相交换信息整个种群最终会分布在帕累托前沿附近的多个方向。推荐时把用户的当前偏好向量映射到最近的子问题权重上取该子问题对应个体再结合具体物品做排序。4. 代码落地一个可运行的轻量级Demo4.1 数据准备与偏好矩阵构造为了讲清楚实现我写了一个极简的模拟环境。假设有60个用户、200个物品每个物品有三个“真实属性”点击吸引力、内容深度、话题多样性。这三个属性就是我们要优化的三个目标。用numpy随机生成数据import numpy as np np.random.seed(42) n_users 60 n_items 200 click_attr np.random.beta(2, 5, sizen_items) # 点击吸引力多数偏低 depth_attr np.random.beta(5, 2, sizen_items) # 内容深度多数偏高 diversity_attr np.random.uniform(0, 1, sizen_items) # 话题多样性 item_matrix np.vstack([click_attr, depth_attr, diversity_attr]).T用户的偏好向量也随机生成三个分量分别代表对点击、深度、多样性的重视程度。为了保证对比可控我让每个用户偏好向量在三维空间中尽量分散覆盖不同的倾向。4.2 三个目标函数与多目标进化主循环这里不追求性能只求逻辑清楚。每个候选解是一个长度为n_items的二进制向量1表示这个物品被推荐。推荐列表长度固定为10。目标函数有三个推荐列表的平均点击吸引力、平均内容深度、平均话题多样性。由于三个目标都要最大化可以直接进入非支配排序。我之前实现的进化主循环如下def evaluate(individual): selected item_matrix[individual 1] if len(selected) 0: return (0, 0, 0) return ( selected[:, 0].mean(), selected[:, 1].mean(), selected[:, 2].mean() ) def dominates(a, b): return all(x y for x, y in zip(a, b)) and any(x y for x, y in zip(a, b)) def non_dominated_sort(population): # 简化版只返回第一前沿 first_front [] for i, ind in enumerate(population): dominated False for j, other in enumerate(population): if i j: continue if dominates(evaluate(other), evaluate(ind)): dominated True break if not dominated: first_front.append(ind) return first_frontnon_dominated_sort实现得很朴素真实项目里会做分层排序和拥挤距离但核心逻辑就是这段代码的逻辑一个解如果没被任何其他解支配就进第一前沿。这里有个很重要的点每个候选解的评估结果不能只存一次然后在排序时重复计算否则复杂度会高得离谱实际工程里要把评估结果缓存下来。4.3 偏好策略如何从帕累托集里挑TopN进化算法迭代若干代之后会得到一个帕累托近似前沿。这时候轮到偏好策略上场。我把用户的偏好向量标准化然后给前沿里的每个候选解打分得分等于候选解三个目标值的加权和权重就是用户偏好。这里你可以看到加权和并没有被抛弃只是把“定唯一权重”变成“按用户偏好动态算权重”并且它作用在帕累托集合上而不是作用在整个解空间上。def recommend_for_user(user_pref, pareto_front): pref user_pref / np.sum(user_pref) best_ind None best_score -np.inf for ind in pareto_front: obj evaluate(ind) score pref[0] * obj[0] pref[1] * obj[1] pref[2] * obj[2] if score best_score: best_score score best_ind ind return best_ind这里可以加业务约束。比如多样性目标低于某个阈值的候选直接过滤掉或者当用户连续多天跌幅超过5%时给多样性权重额外加0.1。每次推荐时先查用户当前偏好向量再做上述映射不需要重新跑进化算法线上延迟完全可控。4.4 工程化优化向量化、缓存和多进程评估上面这段教学代码在真实场景里肯定不能直接用但优化方向是明确的。首先是评估向量化不要用Python循环逐个算目标值而是用numpy的矩阵乘法一次性算出所有候选解的点击均值、深度均值、多样性均值。其次帕累托前沿不需要每次推荐都重新生成离线定时跑一次缓存起来半小时或一小时更新一次就够了。第三如果候选解数量很大评估可以用multiprocessing.Pool做并行每个进程处理一个子种群。我见过很多推荐项目死在“算法好但工程太慢”上。多目标优化最容易被吐槽的地方就是进化算法迭代慢。实际上离线生成帕累托前沿根本不需要在线实时计算只要把它和在线排序解耦性能完全不是问题。我当时用一万个候选解做测试回收时长不到200毫秒而前沿更新频率只要5分钟一次完全够用。5. 实验复盘离线涨了线上却没跑赢基线5.1 离线指标上涨但线上不动问题出在哪模拟项目X里第一版多目标推荐上线后离线评测全面上涨点击率、时长、多样性综合得分提升了12%。但线上AB实验一跑核心指标几乎没有显著提升甚至有一组实验留存轻微下降。复盘了很久发现最大的问题是模拟环境里的目标函数和线上真实目标不一致。离线评估用的三个属性是随机生成的平滑函数而线上真实的点击率预估、时长预估、多样性分本身就有噪声模型误差在10%以上。进化算法在“预测目标”上找到的帕累托前沿一旦换成真实在线打分可能根本不在真实的帕累托前沿附近。这说明离线模拟只能用来验证算法逻辑不能代替线上数据反馈。后来我改成先把多目标候选生成器接入线上打分器用真实打分重新评估目标值再返回帕累托前沿问题才缓解。5.2 偏好权重扰动测试算法稳不稳拉出来遛遛还有一个教训是关于偏好策略的鲁棒性。用户偏好向量是通过行为统计算出来的统计本身有误差如果算法对偏好误差太敏感实际使用中就会忽左忽右。我做了一组扰动实验把每个用户的偏好向量三个分量分别加±5%的噪声然后看推荐结果的变化程度。扰动方式推荐列表平均变化率点击目标变化深度目标变化无扰动0%0%0%点击权重5%7.3%1.2%-0.8%深度权重5%6.1%-0.5%0.9%多样性权重5%8.8%-0.7%0.4%可以看到偏好权重微调会导致推荐列表变化6%-9%这个波动对排序场景来说可以接受但如果变化率超过15%线上用户会明显感觉到“推荐不准”。后来我加了平滑机制偏好向量采用滑动窗口均值同时给每个分量加一个最小步长限制避免单次行为导致剧烈跳变。5.3 还没解决的冷启动与在线学习问题现阶段的多目标偏好策略框架最难啃的还是冷启动和在线学习。新用户几乎没有行为数据个体偏好向量基本靠群体偏好兜底推荐结果比较平庸。新物品也一样没有行为反馈它的点击和深度预估都不准进化算法很难把它推上帕累托前沿。我们尝试过给新物品加探索系数在推荐列表里强行插入一个随机候选它的目标值按历史相似物品估算相当于人为制造一个探索方向的解。这个方法能把新物品曝光量提升不少但会牺牲少量整体目标分数。在线学习方面我目前的做法是定期更新偏好向量和帕累托前沿间隔在分钟级没有做逐请求的实时更新。如果要把在线多目标框架做彻底下一方向是把用户反馈直接变成偏好向量的梯度用bandit的思路在每个目标之间做自适应分配。这种融合会让整个系统更“有手感”但工程复杂度也会上一个台阶目前还在迭代中。最后分享一个调试小技巧多目标推荐算法调优时不要只看最终推荐结果把每次用户的偏好向量和当时帕累托前沿上选中的解都打成日志出问题的时候能很清楚地看到是“前沿没生成好”还是“偏好算歪了”。这个习惯帮我避掉了至少三次线上事故。