1. 项目概述当推荐系统拥有“自主意识”最近在折腾一个老项目一个传统的电商推荐模块效果一直不温不火。CTO扔过来一篇论文标题是“Entropy Guided Diversification and Preference Elicitation in Agentic Recommendation Systems”。初看这标题又是“熵”又是“智能体”还有“偏好诱导”感觉又是一堆学术黑话。但静下心来拆解再结合最近业界在讨论的“智能体”热潮我发现这玩意儿指向了一个非常实际且前沿的问题如何让推荐系统从一个被动的“信息过滤器”转变为一个主动的、能与用户进行策略性交互的“智能助手”。传统的推荐系统无论是协同过滤还是深度学习模型其核心逻辑是“猜你喜欢”。它基于历史行为数据努力拟合用户的静态偏好然后推送它认为相关性最高的内容。这带来了两个经典难题信息茧房和冷启动。前者让用户越看越窄后者让新用户或新物品难以被有效推荐。而“Agentic Recommendation Systems”智能体化推荐系统的提出正是为了解决这些痛点。它不再把用户视为被动的数据源而是将推荐系统本身建模为一个具有目标导向行为的“智能体”Agent。这个智能体的目标不是单纯地预测点击率而是在与用户的多次交互中主动探索用户未知的偏好平衡短期满意度与长期兴趣发现最终实现用户整体体验的最优化。在这个框架下标题中的两个核心概念就变得至关重要了Entropy Guided Diversification熵引导的多样化这里的“熵”借鉴自信息论是衡量系统不确定性的指标。在推荐场景中它可以理解为用户兴趣的“混乱度”或“未知度”。一个高熵的状态意味着系统对用户偏好知之甚少或者用户兴趣本身非常广泛、难以捉摸。“熵引导”意味着系统主动利用这种不确定性作为信号来决定何时应该进行探索推荐一些新颖、多样的内容而非一味地利用推荐最保险、最相关的内容。这直接对抗信息茧房。Preference Elicitation偏好诱导这指的是系统主动设计交互比如询问问题、提供对比选项、设置小游戏等以更高效、更少干扰的方式从用户那里获取偏好信息。这不同于被动收集点击数据而是一种主动的学习策略特别适用于冷启动或用户意图模糊的场景。将这两者结合就构成了一个动态的、有策略的推荐智能体它通过计算当前对用户认知的“熵”来判断不确定性水平当熵值高时倾向于执行多样化推荐或发起偏好诱导对话来降低不确定性当熵值低即系统对用户偏好很有把握时则专注于利用已知偏好提供精准推荐。这形成了一个**“探索-利用”的平衡闭环**并且这个平衡是由数据驱动、动态调整的。2. 核心架构与设计思路拆解要构建这样一个系统不能只停留在算法层面需要一套完整的架构设计。它本质是一个交互式决策支持系统Interactive Decision Support System, IDSS在推荐领域的具象化。下面我结合自己的理解拆解一下核心的设计思路。2.1 从“预测模型”到“决策智能体”的范式转变传统推荐系统的核心是一个“预测模型”输入是用户和物品特征输出是点击率、转化率等预估分数。而智能体化推荐系统的核心是一个“决策智能体”其输入是当前的系统状态包括用户画像、历史交互、会话上下文等输出是一个动作。这个动作可以是“推荐物品A”也可以是“询问用户问题B”甚至是“暂时不推荐等待更多信号”。这个范式转变带来了几个关键设计点状态空间定义我们需要明确用什么来描述系统在任一时刻的“认知状态”。这至少包括用户偏好分布不是单一标签而是一个概率分布例如用户对“科幻”、“喜剧”、“纪录片”的喜好概率各是多少。这个分布的“方差”或“熵”直接反映了不确定性。会话历史当前会话中已发生的交互序列。用户实时反馈最近几次推荐的正面/负面反馈强度。上下文信息时间、地点、设备等。动作空间定义智能体可以做什么动作空间需要精心设计推荐动作从候选池中选择一个或多个物品进行推荐。这里的选择策略不再是简单的Top-K而是需要考虑多样性、新颖性。询问动作设计一组问题或选择来诱导偏好。例如“您更喜欢《星际穿越》还是《盗梦空间》”基于物品的属性对比或者“您正在寻找放松的还是刺激的内容”基于抽象维度。混合动作结合推荐与询问例如“推荐一部电影并询问评分”。奖励函数设计这是驱动智能体学习的指挥棒。奖励不能仅仅是点击或购买因为那会鼓励智能体变得“短视”和“保守”。一个设计良好的奖励函数应包含即时满意度点击、观看时长、评分等。长期兴趣发现用户探索了新品类后的正向反馈。会话活跃度用户在整个交互过程中的参与深度。信息增益通过询问动作获得的、能有效降低用户偏好熵的信息价值。2.2 “熵”作为核心调控器在我们的架构里“熵”不是一个事后评估指标而是一个实时的调控信号。我们可以为用户偏好分布的每一个维度如品类、主题、风格计算熵值。假设我们将用户偏好建模为一个多项式分布例如用户对K个品类的偏好概率为P (p1, p2, ..., pK)那么其熵H(P)的计算公式为H(P) - Σ (pi * log(pi))其中求和i从 1 到K。这个值越大说明系统越不确定用户到底喜欢哪个品类值越小说明系统越确信用户的偏好集中。如何用熵来指导决策我们可以设定一个或多个熵阈值高熵区间当H(P) θ_high系统处于“迷茫”状态。此时决策应倾向于探索。具体动作可以是多样化推荐从多个高熵不确定的品类中选取物品组成一个多样性列表。主动询问针对熵值最高的那几个维度设计对比性问题直接获取用户反馈。低熵区间当H(P) θ_low系统处于“自信”状态。此时决策应倾向于利用。具体动作是精准推荐从用户偏好概率最高的品类中选取质量最优的物品进行推荐。中熵区间介于两者之间可以采用汤普森采样或上置信界等算法平衡探索与利用。注意这里的熵计算是基于系统当前的“信念”而非用户真实的、不可知的偏好。我们的目标是让系统的信念熵通过对用户真实偏好的学习而降低。2.3 偏好诱导的策略设计偏好诱导是降低熵、解决冷启动的利器。但糟糕的询问会惹恼用户。设计的关键在于效率和用户体验。基于物品对比的询问这是最直观的方式。系统选择两个在属性空间上差异较大、且各自在某些维度上具有代表性的物品让用户选择。例如对比“硬核科幻”与“浪漫科幻”。用户的选择能直接更新对应属性维度的偏好概率信息增益高。基于抽象属性的询问直接询问用户对抽象维度如“节奏快慢”、“剧情复杂度”的偏好。这需要系统建立物品属性到抽象维度的映射模型。渐进式诱导不要一次性问太多问题。采用“推荐-反馈-再询问”的循环。例如先推荐一个物品无论用户喜欢与否都可以跟进一个针对性的问题“您不喜欢它是觉得太冗长了吗”。隐式诱导将询问融入自然交互。例如在推荐卡片上增加“为什么推荐这个”的按钮用户点击后展示推荐理由基于其历史偏好并提供一个“调整此偏好”的微调选项。实操心得在真实产品中显式的询问动作一定要克制频率要低且问题要设计得极其精炼、有价值。通常将其作为冷启动或用户主动触发“探索模式”时的专用流程。大部分时候依赖隐式的、基于多样推荐的探索更为友好。3. 系统实现的关键模块与技术选型纸上谈兵终觉浅我们来聊聊具体怎么搭。一个原型系统至少包含以下模块我会结合当前主流的技术栈谈谈选型。3.1 用户状态管理模块这是系统的“记忆中枢”。它需要实时维护和更新用户的状态表示。技术选型向量数据库用于存储和快速检索用户和物品的嵌入向量。Milvus、Pinecone或Weaviate是不错的选择。它们擅长处理高维向量的相似性搜索对于基于向量计算多样性至关重要。键值存储/内存数据库用于存储实时更新的用户状态如本次会话的交互序列、临时计算的偏好分布。Redis是绝佳选择性能极高支持丰富的数据结构。传统数据库用于存储永久的用户画像、长期偏好模型。PostgreSQL或MongoDB均可。状态更新流程用户执行一个动作点击、跳过、回答询问。事件被发送到实时流处理平台如Apache Kafka。状态管理服务消费事件根据预定义的规则更新 Redis 中的用户实时状态。同时事件也被写入长期存储用于离线更新深度用户画像模型。3.2 熵计算与决策引擎这是系统的“大脑”。它接收当前用户状态计算熵并根据策略选择动作。技术选型决策引擎可以使用轻量级的规则引擎如Drools处理基于阈值的简单策略。但对于更复杂的、基于学习的策略需要一个强化学习框架。强化学习框架Ray RLlib是一个强大的工业级选择它集成了多种强化学习算法支持分布式训练非常适合推荐智能体这类场景。你可以将用户状态作为状态推荐/询问作为动作用户反馈作为奖励来训练一个策略网络。在线服务决策引擎需要以毫秒级延迟响应。通常用PythonFastAPI/Flask或Go编写高性能API服务内部调用训练好的模型或执行规则逻辑。熵计算服务这是一个独立的微服务它从状态管理模块获取当前用户的偏好分布向量P计算香农熵H(P)。计算本身很简单关键在于分布P的估计要准确。这个服务需要被决策引擎高频调用。3.3 候选生成与排序模块当决策引擎决定“推荐”时它需要候选物品。这里通常分为召回和排序两阶段。召回阶段目标是从百万级物品库中快速找出几千个相关候选。基于向量的召回使用用户状态向量或当前兴趣向量在向量数据库中进行近似最近邻搜索。这是实现多样化的关键。我们不仅可以搜索最相似的还可以有策略地搜索“次相似”但在某些维度上不同的物品。基于规则的召回当熵高时可以强行加入一些流行新品、多品类混合的召回通道。排序阶段对召回后的候选列表进行精排。模型深度学习排序模型是主流如DeepFM、DIN、SIM等。输入特征需要加入本次决策的上下文例如“本次请求的探索权重”、“目标多样性分数”。多样化重排在精排分数的基础上使用MMR、DPP等算法进行重排在相关性和多样性之间取得平衡。熵值可以直接作为多样化权重的输入熵越高重排时多样性权重越大。3.4 偏好诱导接口模块当决策引擎决定“询问”时该模块负责生成具体的问题。问题生成基于物品池从物品库中选择一对“好问题”物品。选择标准是它们之间的“期望信息增益”最大。这需要计算不同物品对被用户选择后能多大程度降低偏好分布的熵。基于知识图谱如果拥有丰富的物品知识图谱可以生成基于属性对比的问题如“您更看重导演还是演员”。接口设计询问的交互形式需要前端紧密配合。可以是弹窗、卡片对比、滑动选择器等。后端API需要返回问题类型、选项内容、以及每个选项对应的预期状态更新逻辑。4. 核心算法流程与实操示例让我们串联起上述模块看一个具体的用户会话流程并附上一些伪代码级别的实现思路。4.1 新用户会话启动流程状态初始化新用户U123进入系统。状态管理模块为其创建一个初始状态。# 伪代码初始化用户状态 user_state { ‘user_id‘: ‘U123‘, ‘preference_distribution‘: [1/K, 1/K, ..., 1/K], # K个品类均匀分布熵最高 ‘session_history‘: [], ‘entropy‘: calculate_entropy([1/K]*K) # 高熵值 } redis.set(f‘user_state:{U123}‘, user_state)首次决策决策引擎获取状态计算熵H(P) ≈ log(K)高于阈值θ_high。决策进入“高熵”模式优先进行偏好诱导。动作生成偏好诱导模块从物品库中选取一对在“科幻”与“喜剧”维度上对立的代表性物品I_a和I_b生成问题。用户反馈与状态更新用户选择了I_a科幻。# 伪代码基于选择更新偏好分布 (简化版贝叶斯更新) # 假设I_a属于“科幻”品类I_b属于“喜剧” choice ‘科幻‘ # 更新概率这里alpha是学习率 for category in all_categories: if category choice: new_prob old_prob[category] * (1 alpha) else: new_prob old_prob[category] * (1 - alpha/(K-1)) # 归一化 user_state[‘preference_distribution‘] normalize(new_prob) # 重新计算熵 user_state[‘entropy‘] calculate_entropy(user_state[‘preference_distribution‘]) # 保存状态 redis.set(f‘user_state:{U123}‘, user_state)更新后“科幻”的概率提升“喜剧”的概率下降整体熵值H(P)降低。4.2 稳态推荐流程经过几轮交互用户偏好熵降至中等水平。决策引擎工作熵值处于(θ_low, θ_high)区间。决策引擎调用强化学习策略网络该网络以用户状态向量为输入输出一个探索概率ε。候选生成以1-ε的概率进行利用性召回使用用户当前最偏好的“科幻”类向量进行ANN搜索。以ε的概率进行探索性召回除了“科幻”还混合使用“动作”、“悬疑”等次偏好品类的向量进行搜索并将结果合并。排序与重排精排模型对召回结果打分。重排算法根据当前的熵值计算多样性权重λ。一个简单的线性映射可以是λ (H(P) - θ_low) / (θ_high - θ_low)。熵越高λ越接近1多样性越重要。使用score_final (1-λ)*score_relevance λ*score_diversity进行最终排序生成推荐列表。推荐与反馈循环用户对推荐列表产生反馈点击、忽略、长时间观看。这些反馈事件再次触发状态更新从而影响下一轮的熵值和决策。4.3 关键参数调优经验熵阈值θ_high和θ_low这是最重要的调控旋钮。没有银弹必须通过A/B测试确定。通常可以先根据经验设定例如θ_high设为初始均匀分布熵的80%θ_low设为20%。然后观察用户在不同熵区间的行为数据如探索后的长期满意度、会话长度进行动态调整。探索概率ε如果使用强化学习它会自动学习。如果使用简单策略可以设计一个与熵值正相关的函数例如ε min(ε_max, β * H(P))其中β是缩放系数。学习率alpha在更新偏好分布时学习率决定了系统对单次反馈的敏感程度。太高会导致偏好震荡太低则学习缓慢。建议从较小的值开始如0.1并考虑让学习率随时间或交互次数衰减。5. 常见陷阱、问题排查与效果评估在实际部署中我们踩过不少坑这里分享一些核心的注意事项和排查思路。5.1 常见陷阱与规避策略陷阱表现根源规避策略过度探索用户体验受损用户总是看到不相关的内容点击率骤降用户流失。熵阈值θ_high设置过低或探索性推荐的权重过大。1. 将探索动作的“成本”纳入奖励函数如用户跳过探索项会产生负奖励。2. 探索内容需保证一定的质量底线不能是冷门劣质内容。3. 采用渐进式探索在用户已有偏好的基础上进行小幅拓展。偏好诱导惹人烦用户反感被频繁提问直接跳过或离开。询问频率过高问题设计生硬。1. 将询问动作的触发条件设得极其严格仅用于绝对冷启动或长期兴趣衰减时。2. 优化问题UI使其更像游戏或互动而非考试。3. 提供“跳过”或“不再询问”选项并尊重用户选择。“熵”计算失真系统熵值很低自以为很懂用户但推荐效果很差。偏好分布模型过于简单无法捕捉用户复杂、多变的兴趣。1. 采用更复杂的表示如多兴趣向量如DIN、MIND模型为用户学习多个兴趣分布分别计算熵。2. 引入上下文感知区分用户在周末和工作日的兴趣偏好。3. 定期加入兴趣衰减因子让长期不接触的品类熵值缓慢回升。强化学习训练不稳定线上策略效果波动大有时甚至崩溃。推荐环境是部分可观测、非平稳的且奖励延迟严重。1. 采用离线强化学习或模仿学习先利用历史日志数据训练一个基线策略再进行在线微调。2. 使用稳定算法如PPO、SAC。3. 设计更稠密、更合理的奖励信号避免稀疏奖励问题。5.2 线上问题排查清单当线上监控发现推荐效果指标如CTR、观看时长下跌时可以按以下步骤排查检查用户状态流抽样一批效果差的用户会话查看其状态更新日志。确认偏好分布P的更新是否符合预期熵值变化曲线是否正常检查决策日志对于这些会话决策引擎输出了什么动作是探索为主还是利用为主这个决策在当前熵值下是否符合策略规则检查候选生成当决策是“推荐”时召回和排序模块返回了什么样的列表多样性是否异常高或低精排模型的输入特征特别是熵相关特征是否正常传递检查实时特征确保用于计算熵和决策的所有实时特征如用户实时点击序列的 pipeline 没有延迟或中断。进行A/B测试回溯如果最近有策略上线立即进行回溯分析对比实验组和对照组在核心指标上的差异。5.3 效果评估指标体系评估这样一个系统不能只看短期点击率。需要一套综合指标短期满意度指标CTR、转化率、平均观看时长、评分。探索与多样性指标品类覆盖率推荐列表中覆盖的品类数。基尼系数/辛普森指数衡量列表集中度。惊喜度用户实际喜欢但历史未接触过的物品比例。长期价值指标用户留存率7日、30日留存。兴趣广度用户长期交互的品类数变化。会话深度平均单次会话的交互次数。系统健康度指标平均用户熵全体用户平均熵值的变化趋势。理想情况下随着系统学习平均熵应缓慢下降并稳定在一个合理水平而非降至零那意味着茧房。探索动作占比探索性推荐和询问动作占总请求的比例。我个人最看重的是“长期价值指标”和“平均用户熵”。一个健康的智能体化推荐系统应该能在保持用户满意度的同时逐步、温和地拓宽其兴趣边界将平均熵维持在一个“既非一无所知也非固步自封”的活跃水平上。这就像一位优秀的向导既知道你的主要喜好又总能在合适的时候给你带来一点意想不到的、却又合情合理的风景。实现这个平衡就是这项技术最大的魅力和挑战所在。