炒股就看金麒麟分析师研报，权威，专业，及时，全面，助您挖掘潜力主题机会！

（来源：科技行者）

你有没有想过一个问题：当你打开淘宝首页,刷到的那些商品,到底是谁在替你做决定？

答案通常是一条流水线。系统先从几十亿商品里捞出几千个可能你感兴趣的（这叫召回），然后用模型给它们打分排序（这叫排序），最后再微调一下顺序,把广告和自然内容穿插好（这叫重排）。这套流程跑了十几年,效率很高,但有个致命的问题:每个环节都是各自为战的。

召回模块不知道排序模块在优化什么,排序模块也不知道重排环节会怎么处理它给出的结果。更麻烦的是,你今天是随便逛逛,还是正在纠结买哪个牌子的养生壶,还是马上就要下单了,这种实时变化的心思,系统压根感知不到。它只会用一套相对固定的规则对待所有人。

这就好比一个餐厅,点菜的、炒菜的、上菜的分属三个部门,谁也不跟谁通气。你说要清淡点,点菜的记下了,但炒菜的根本看不到这张字条,只会按照菜谱的标准做法下重油重盐。如果没有一个统一的信息中枢,再厉害的分工也会在信息断层的地方失灵。

阿里巴巴这次拿出的方案,叫DREAM（Developing Recommender Engine with Agentic Methods）。它没有把整条流水线推倒重来,而是在上面加了一层"智能管理层"，用AI Agent的方式去感知用户此刻的真实意图,然后统一协调召回、排序、重排这几个环节该怎么配合。这篇论文管这个思路叫"agentic meta-control"（智能体元控制），说白了就是让一个更聪明的大脑,去指挥原本互不通气的各个部门。

传统流水线的四个老毛病

在讲DREAM怎么解决问题之前,得先说清楚问题到底出在哪。论文里总结了四条:信息碎片化(上下游看不到彼此的结果)、目标割裂(点击率、转化率、增长、体验这些指标各自优化,从不互相协调)、策略僵化(大量依赖人工规则和固定的用户分群)、以及最要命的实时意图感知缺失。

这最后一条尤其关键。你在淘宝上逛街的时候,状态是会变的:一开始可能只是随便看看,看着看着突然对某类商品来了兴趣,反复比较几个品牌,最后可能下定决心要买。这几种状态之间的转换,叫做"session级别的意图迁移"。

Session：指用户从打开App到关闭之间的一整段连续行为,这段时间内的浏览、点击、搜索都算在一个会话里。

传统系统很难捕捉到这种转换,因为它依赖的信号太滞后、太粗糙。等系统反应过来你想买东西了,你可能已经关掉App了。

这个问题在业界其实早就有人尝试解决,用大语言模型（LLM）做推荐Agent的研究这两年也不少。论文里提到,已有的工作大致分三类:一类是让Agent帮用户选商品(靠记忆和工具调用),一类是用Agent模拟用户行为做训练评估,还有一类是让Agent去调整推荐系统本身的架构。但这些工作有个共同的软肋,就是意图感知和策略生成是脱节的。要么只看到用户的历史记录,看不到设备端那些细微的实时信号;要么策略规划得很长远,但完全不知道用户此刻到底想干嘛。

DREAM想解决的,正是这个"脱节"问题。它的整体思路可以概括成三块:一个负责感知用户意图的Intent Engine（意图引擎）,一个负责决策和执行的Meta Engine（元引擎）,还有一个让整个系统持续自我优化的Reward Dual Loop（奖励双循环）。

意图引擎:把用户的心思拆成三层

先说意图引擎。它的任务是把用户杂乱的行为信号,变成结构化、可理解的"意图"。这里最有意思的设计,是把意图分成了三层,分别叫L0、L1、L2。

L0（Physical层）：记录的是相对稳定的用户画像,比如年龄段、长期兴趣、身份标签,这些不会因为你今天刷了十分钟猫粮就突然改变。

L1（Demand层）：记录当下的需求类别和场景,比如你最近在搜"绞肉机",这就是L1层要捕捉的东西,包括你对这个品类的认知程度、目标受众(自用还是送人)、置信度有多高。

L2（Preference层）：记录更细粒度的偏好,比如你倾向哪个品牌、什么价位、现在处于什么决策阶段(是刚开始了解,还是已经在几个牌子之间反复横跳,还是马上要下单了),甚至包括你此刻的心理状态,比如"信息焦虑"或者"价格纠结"。

这三层叠在一起,构成了一个动态更新的用户画像。举个论文里的真实案例(经过匿名处理):某个用户同时挂着14个活跃的意图卡片,有一张显示他正在"竞品选择"阶段考虑运动鞋,另一张显示他对棒球帽和偏光墨镜处于"灵感探索"阶段,置信度中等,还带着"新手认知"、"夏季场景"、"夜间驾驶场景"这些细节标签。

这套分层设计的巧妙之处在于,它没有试图用一个笼统的标签去概括用户,而是允许多个意图并存,而且区分了哪些是长期稳定的、哪些是随时可能变化的。这就像给一个人建档案,不会把"性格内向"和"今天心情不好"写在同一栏里,因为前者是常量,后者是变量,搞混了这两者,你的判断就会全错。如果不做这种分层,系统很可能会把用户偶尔的一次冲动点击,误判成一个稳定的长期偏好,进而持续推送一些用户其实并不真正需要的商品,这种"用力过猛"的推荐反而会让人反感。

但这里有个现实问题:淘宝这种量级的平台,每秒钟产生的用户行为数据是海量的。如果每一次点击、每一次滑动都要触发一次云端的大模型推理,那服务器根本扛不住,延迟也会高到无法忍受。

于是论文提出了一套叫"Traffic Funnel"（流量漏斗）的机制,用设备端和云端协同的方式,把这个问题解决掉了。

流量漏斗:从"什么都收"到"精准触发"

这套机制被拆成了四个阶段,论文里叫F1到F4。前三个阶段跑在你的手机上,最后一个阶段才上传到云端。

F1阶段做的是信号编码,把你在App里的原始操作(停留时长、滑动速度、点击了什么)实时转换成结构化的特征,这一步让系统能识别的行为类型从原来的6种扩展到了60多种。

F2阶段是判断触发时机,用一个轻量级的GRU模型（一种时序神经网络,负责判断你的行为模式是不是发生了明显变化）来检测"意图变化点"。只有真正可能发生变化的时刻,才会触发上传,这一步直接把要处理的数据量压缩到了大约15%。

F3阶段是打包上传,把最近的行为序列打包成一个精简的、只带ID的数据包,不做任何语义解析,尽量省流量。

F4阶段则是在云端,把这些ID还原成有意义的信息(比如把商品ID还原成商品名称、类目),然后做第二次筛选,判断这次更新是不是真的值得触发大模型推理。

这套流水线跑下来,最终真正上报到云端需要处理的行为,只占全部原始行为的大约8.7%。

这个设计其实是在做一道取舍题。如果什么都不过滤,直接把所有行为都送到云端做大模型推理,系统会被海量低价值信号淹没,响应速度和成本都扛不住;但如果过滤得太狠,又可能把真正重要的意图变化信号也一并丢掉,导致系统对用户的理解出现偏差。这就像小区门口的安检,如果每个进出的人都要开箱翻包检查,排队能排到马路对面去;但如果完全不检查,安全隐患又是另一回事。流量漏斗要做的,就是找到那个既能拦住可疑信号、又不至于让正常流量堵死的临界点,而这个临界点是通过设备端GRU的实时判断动态找出来的,不是一刀切的固定规则。

除了实时处理,论文还设计了一个挺有意思的机制,叫"Dreaming Mechanism"（做梦机制）。

做梦机制:趁夜深人静把白天的记忆理一遍

这名字起得挺有画面感。它的逻辑是,实时处理只能基于当下这一小段行为做判断,视野是有限的,容易出现三种问题:意图重复创建(同一个需求被拆成好几条记录)、意图判断不准(证据还不够就下了结论)、意图遗漏(一些零散但持续出现的信号,单独看都不起眼,凑在一起其实是个明显的需求,但实时系统没能把它们串起来)。

与此同时,深夜时段用户请求量会大幅下降,服务器算力大量闲置。

于是系统会在夜间用一个更大的模型(4B参数,相比实时用的0.8B模型大了5倍),把用户白天一整天的行为轨迹重新梳理一遍,对当天积累的意图列表做一次彻底的"复盘"。这个复盘动作用了六种操作:保留、纠正、补全、合并、新增、清除。

这个设计像极了人类睡眠中大脑对白天记忆的整理过程,神经科学里确实有研究支持睡眠有助于记忆巩固这个说法,论文也是这么类比的。但我觉得更值得琢磨的一点是,这背后其实是对"计算资源"和"信息完整性"之间矛盾的一次巧妙化解。白天你没法用大模型处理每一条信号,因为太贵太慢;但如果永远不做全局复盘,那些被实时系统漏掉或误判的信息就永远沉没了。晚上闲置的算力,恰好给了系统一个"回头看"的窗口。

论文用683个用户的真实数据做了对比测试,复盘前后的意图判断准确率变化很说明问题:意图类型的判断准确率从58.3%涨到68%,优先级判断从52.4%涨到57.1%,细分品类的判断从47.7%涨到52.3%。这些数字看着不算惊天动地,但对于一个每天服务数以亿计用户的推荐系统来说,几个百分点的提升,乘以巨大的用户基数,意味着数百万次更精准的推荐。

元引擎:让大模型学会"分层思考"再下指令

有了意图引擎输出的结构化信息,接下来的问题是,谁来把这些信息变成具体的推荐策略?这就是Meta Engine（元引擎）要干的事。

元引擎的核心是一个叫MetaModel的大模型,基于阿里自研的Qwen3模型构建。它的推理过程被设计成三层,分别叫M1、M2、M3,论文管这个流程叫"layered reasoning"（分层推理）。

M1（意图总结）：把意图引擎输出的一堆结构化信息,浓缩成一个战略方向,比如判断这次应该偏向"IPV导向"(让用户多点开商品详情页)还是"GMV导向"(直接促成交易)。

M2（策略规划）：在M1定的大方向下,生成一个具体的策略组合,包含六个模块:排序权重怎么调、哪些商品需要重点保护曝光、类目偏好如何设置、卡片类型(视频、直播、图文)怎么取舍、体验约束如何设定、以及要不要在特定页面开启"纯点击率优先"的排序模式。这一步还会参考一个叫Strategy Memory（策略记忆库）的东西,里面存的是历史上验证过有效或无效的策略,相当于给决策提供"前车之鉴"。

M3（参数翻译）：把M2那些相对抽象的策略描述,翻译成具体的、可以直接喂给排序系统和重排系统的数字参数。

为什么要分这三层,而不是让大模型一步到位直接输出参数?这里面藏着一个很实际的工程考量。M1和M2这两步涉及复杂推理,对响应速度要求没那么苛刻,可以放在"nearline"（近线,介于实时和离线之间的处理路径）上跑;而M3是纯粹的确定性映射,不需要大模型再临时思考,可以放在对延迟极其敏感的实时链路上。这种设计相当于把"想清楚要干什么"和"立刻执行"这两件事分开处理,想的时候可以慢一点、深一点,做的时候必须快、必须稳。

这套机制还有个安全网叫"default fallback + personalized override"（默认兜底+个性化覆盖）。简单说就是,系统始终保留一套默认配置作为兜底,MetaModel生成的策略只是在默认配置基础上做局部的、有边界限制的覆盖调整,而不是把整个配置推翻重写。每一次覆盖都会经过参数范围检查、白名单校验这些"安全护栏"，一旦某个策略生成出错或者超出安全边界,系统立刻退回默认配置,绝不会让一个有问题的策略直接影响到线上用户。

这就像给一个刚拿到驾照的新手司机配了个带辅助刹车的教练车。他可以自己开、自己做判断,但方向盘转得太猛或者刹车踩得不对,教练那边的备用装置会立刻介入纠正。如果没有这层保护,一旦大模型某次生成了一个有问题的策略,后果可能直接影响到线上千万级别的用户体验,这个代价是系统绝对承受不起的。这也是为什么论文反复强调,DREAM是"在现有流水线上加一层控制,而不是替换掉任何一个现有模型"，稳妥永远排在效果提升前面。

强化学习怎么在不冒险的前提下训练策略

MetaModel这个决策大脑要变聪明,离不开训练。但这里有个特别现实的问题:你总不能拿真实用户当小白鼠,让一个还没训练好的策略随便在线上瞎试吧?一旦生成的策略很糟糕,用户体验直接受损,这个成本谁来承担?

DREAM给出的方案是,整个强化学习训练过程完全放在离线环境里做,但走的是"生产环境路径重放"（production-path replay）这套机制,而不是简单的历史数据拟合。

具体做法是,拿真实的历史请求日志,针对同一条请求,分别跑两遍完整的生产流水线:一遍用默认配置(基线),一遍套用MetaModel生成的策略(处理组)。因为线上的模型状态和特征会随时间波动,同一个请求跑多次结果也可能有细微差异,所以每种配置都会重复跑K次,取平均分来减少噪声干扰。

奖励机制被设计得非常朴素,论文管它叫"Binary Evaluator Reward"（二元评估奖励）:只要策略组的平均评分比基线组高,就给1分的奖励,否则就是0分。没有复杂的排序损失,没有分数差值加权,就是简单的"赢了就是赢了"。

这个设计乍一看有点"傻",毕竟很多强化学习论文都在琢磨怎么设计更精细的奖励函数。但换个角度想,推荐系统这种场景里,不同请求之间的评分尺度天差地别,直接比较分数的绝对差值意义不大,反而是"赢没赢"这个二元判断更稳健、更不容易被极端值带偏。用一个简单粗暴但可靠的信号,有时候比一个精巧但脆弱的信号更管用,这也是工程实践里经常要面对的取舍。

整个训练和验证过程还有一层隔离设计:所有的重放请求走的是隔离的压测流量通道,输出结果不会展示给真实用户,也不会写入任何曝光、归因或者业务统计记录。只有通过了离线的胜率检验、策略有效性检验、执行成功率检验这几道关卡的策略,才有资格进入线上灰度测试,接受随机分流的A/B实验的最终检验。

论文里给出的一组4B模型强化学习后的离线对比数据也印证了这套机制确实管用:点击率相关指标提升2.42%,商品详情页访问提升1.38%,GMV提升0.37%,而最亮眼的是策略有效性从80.86%涨到98.85%,提升了近18个百分点。这说明经过强化学习训练,模型生成的策略"能顺利执行"的比例大幅提高了,这对于一个需要在生产环境实时运行的系统来说,是个相当实际的进步。

大规模A/B测试:数字说话

说了这么多设计理念,最终还是要看真金白银的效果。DREAM在淘宝首页的"猜你喜欢"场景做了大规模线上A/B测试,分两个阶段验证。

第一阶段只让元引擎控制重排环节,结果显示IPV（商品详情页访问量）提升2.06%，核心IPV提升2.39%，GMV（成交总额）提升0.88%，页面曝光量PV也提升了1.03%。

第二阶段把控制范围扩展到精排环节,效果进一步放大:IPV提升到2.71%，核心IPV提升到3.06%，GMV提升到1.31%，点击率PCTR也从0.76%涨到了1.25%。

这里有个细节值得琢磨。两个阶段的PV几乎没有变化(1.03%对1.04%)，但IPV、GMV、点击率这些指标都明显提升了。这说明第二阶段带来的增益,主要不是靠给用户看了更多商品,而是让本来就展示出来的商品,被用户点击和购买的比例更高了。换句话说,DREAM没有靠增加曝光量来"注水",而是真正提升了推荐的精准度,让同样的曝光机会产生了更高的转化。这在推荐系统的效果评估里,是一个相对更扎实、更难刷出来的成绩。

论文还专门列了两张表格,展示意图引擎在不同下游应用场景的独立效果。比如在"认知推荐"场景里接入意图信号后,IPV提升0.80%，核心IPV提升0.91%；而在"启发式推荐"场景(就是那种在信息流里插入的、主动询问你需求的卡片)里,PV提升了5.06%，卡片点击量提升了7.17%；配合文案优化后,卡片点击量的提升幅度进一步冲到10.64%。这些平台级和场景级的数据放在一起看,基本能确认这套架构不是纸上谈兵,而是真的在多个环节都产生了实打实的业务价值。

写在后面

读完这篇论文,我印象最深的其实不是那些百分比数字,而是DREAM在架构选择上表现出的克制。它完全有机会讲一个更炫的故事,比如"用大模型端到端重构整个推荐系统"，但它没有这么做,而是坚持"在现有流水线上加一层可控、可回滚的策略层"。这种克制背后,其实是对工业级系统复杂性的深刻理解:一个服务数亿用户的系统,任何一次激进的重构都可能带来无法预估的连锁反应,而渐进式的、带着安全护栏的改造,才是真正能落地的路径。

另一个让我意外的细节是"做梦机制"这个设计。很多AI系统论文喜欢强调实时性、强调越快越好,但DREAM反其道而行之,专门设计了一个利用夜间闲置算力做离线复盘的模块。这提醒我,系统设计有时候不是比谁跑得更快,而是比谁能把资源用在刀刃上,该快的地方快,该慢下来沉淀的地方就该慢下来。

论文里那个二元奖励函数的设计也值得多想一层。学术界很多强化学习工作追求奖励信号的精细度,但工业场景下,一个足够稳健、不容易被噪声带偏的简单信号,反而比一个理论上更优雅但工程上脆弱的复杂信号更靠谱。这大概是学术研究和工业落地之间一个挺典型的分野。

这套系统目前只在淘宝首页的一个场景里验证过,论文里也提到未来会逐步扩展到更多场景。一个自然的疑问是,当控制的范围继续扩大,比如从重排、精排一路扩展到召回环节,这种"分层控制"的复杂度会不会开始出现管理上的瓶颈?毕竟现在的架构已经涉及意图引擎、元引擎、策略记忆库、双循环奖励机制这么多组件,继续叠加下去,会不会有一天,协调这套系统本身的成本,反而超过了它带来的收益?这是个值得留意的问题。

Q&A

Q1：DREAM是什么？

A：DREAM是阿里巴巴淘宝团队提出的一套推荐系统智能控制架构,全称Developing Recommender Engine with Agentic Methods。它不替换现有的召回、排序、重排流水线,而是在上面加一层能感知用户实时意图、自主决策、持续自我优化的策略控制层。

Q2：DREAM上线后效果怎么样？

A：在淘宝首页猜你喜欢场景的大规模A/B测试中,仅控制重排环节时IPV提升2.06%,GMV提升0.88%;扩展到精排环节后IPV提升2.71%,GMV提升1.31%,页面曝光量始终保持1%以上增长,且没有替换任何原有模型。

Q3：意图引擎的L0、L1、L2分别是什么意思？

A：L0记录用户长期稳定的画像信息,比如年龄、职业这类不常变的属性;L1记录当下的需求类别和场景,比如你最近在搜什么品类;L2记录更细的偏好,比如品牌倾向、价格区间和当前所处的决策阶段。三层结合能更准确地捕捉用户实时变化的购物心思。