企业官网建设流程全解析

外卖App首页的推荐，已经从“猜你想吃什么”的简单排序，变成了一场十几路业务同时争抢用户注意力的复杂调度。美团外卖能从送餐场景长出一套叫MTFM的统一推荐基座大模型，很大程度上是因为多业务场景的推荐需求，不可逆地走向了统一。我自己拆过不少推荐系统，也见过很多团队从多套模型并行维护，走到“必须有一个底座把公共能力沉淀下来”的阶段。今天这篇就围绕MTFM在西外卖多业务场景的落地实践，把为什么要做统一基座、基座模型的核心结构、多业务怎么逐个接入、工程上怎么保证不翻车，以及踩过的坑，一条条说清楚。

对推荐系统工程师、算法团队负责人，或者正在做业务规模扩张但模型体系依然“各自为战”的团队来说，这篇文章会很有参考价值。不聊花哨概念，只聊能落地的逻辑。

1. 外卖推荐为什么长不出一个大而全的模型：碎片化是根因

先说结论：外卖推荐系统之所以要搞“统一基座大模型”，不是因为大模型听起来更先进，而是因为它能解决真实存在的数据碎片化问题。

1.1 外卖业务的场景清单比看上去多很多

很多人理解外卖推荐，就是首页那一个Feed流。但真正上线之后你会发现，外卖场景是极度碎片化的：

• 首页信息流推荐，目标是让用户快速找到今天想吃的东西。
• 搜索排序，用户带着明确query进来，得把相关性、价格、配送时效、商家评分捏在一起。
• 金刚位和运营位场景，比如“天天特价”、“下午茶”、“夜宵”，每个都有独立的转化目标。
• 营销券场景，用户领了券之后，推荐哪些商家可用，直接影响核销率。
• 购物袋（购物车）推荐、下单后的再来一单，甚至用户差评之后的补偿推荐，都是不同的业务。

这些场景在看似的统一行动，用户行为上却高度纠缠：用户在首页逛了一圈，可能因为消费券跳到营销会场，然后又去搜索结果页比较了三个商家。如果每个场景各建各的模型，同一个用户的行为序列就被割裂在N套样本里，每套模型都只能看到局部。

1.2 单场景独立建模是“积木堆叠”，统一基座是“染色体重构”

过去外卖推荐主流做法是单场景独立建模：首页一套深树模型或深度排序模型，搜索一套，券场景一套，营销会场再一套。短期内上线快、迭代直接，看起来没什么问题。

但业务走到一定规模后，积木式堆叠的弊端越来越明显。第一是特征工程重复建设，用户历史点击、下单、加购这些核心行为特征，在每个场景的样本流水线里都要重复算一遍。第二是用户兴趣模型被拆碎，同一个用户在不同的模型里得到不同的embedding表达，各场景对用户的理解互相不共享，等于每个业务都在从零开始学用户的偏好。第三是运维和迭代成本陡增，新增一个业务场景，不是改一个配置，而是新招一组工程师、维护一套样本、一套模型、一套上线链路。

MTFM做的事情，通俗讲就是把原本一堆积木拆掉，重新设计成“一个底座+N个可插拔的脑袋”。底座负责学吃透用户兴趣和外卖场景的公共规律，业务脑袋负责适配各自的目标和约束。

这里需要补充一个关键认知：统一基座不代表一套模型硬跑全部场景。真正的统一，是底层特征、用户兴趣建模、样本口径的统一，而上层任务目标、排序策略依然可以分开。MTFM的落地思路，正好建立在这样一种“共享为主、独立为辅”的架构哲学上。

2. MTFM的基座长什么样：一个模型如何同时长出N个推荐脑袋

在真正进入结构细节之前，我想先讲一个朴素原则：统一基座大模型做得越深，共享参数越靠下，各业务的可插拔性就越强。这也是MTFM架构设计里最重要的主线。

2.1 底层特征全部收敛到一套Embedding体系

第一层是特征embedding的统一。过去每个场景有自己的一套特征ID映射，从用户ID到商家ID、城市ID、品类ID、优惠券ID，都是各玩各的。MTFM的做法是把这些底层ID映射收敛成一套共享的词表（Vocabulary），无论哪个场景的样本进来，用户ID、商家、城市、品类、价格带、优惠方式，都映射到同一套低维向量空间。

这个动作的意义非常大。特征ID统一之后，一个用户在外卖首页的行为和她在搜索框下面的行为，会自然落到同一个embedding空间里做交互。跨场景的协同信号不需要靠人工特征组合，模型自己就能通过向量相似度学出来。比如用户领了一张奶茶券，券场景看到她在首页点过某家茶饮店，可以在向量空间里直接感知到这个偏好。

特征分层的概念也值得一提。MTFM在Embedding层之上还有一类“业务敏感层”：像商家配送范围、出餐时长、用户当前地理位置距离这类强外卖场景特征，会和用户ID一起被组合编码。这类特征不会因为场景切换而改变语义，天然适合放共享层，避免每个场景重复去学“距离越远转化率越低”这种常识。

2.2 用户兴趣建模放在主干网络里，业务感知放在任务头里

MTFM中用户兴趣建模的方式，核心是序列建模。外卖场景里用户的短期意图尤其重要：午饭想要快、晚饭可能想吃好、夜宵更偏重低客单价烤串奶茶。如果模型只看到用户过去30天的平均偏好，就无法区分她此刻是上班族午休还是周末在家点夜宵。

所以基座网络的recommendation主干会做两部分序列建模：

• 短期行为序列：最近几个小时到几天的点击、搜索、加购、下单行为，用注意力机制提取当前意图。这里的注意力权重不是死板的，会根据候选商家、当前时间、当前地理位置计算动态权值。
• 长期兴趣画像：过去90天甚至半年的品类偏好、价格带偏好、商家复购周期、优惠敏感度，形成稳定的用户画像向量。

为什么要放在主干网络而不是各业务tower里？因为短期意图和长期兴趣是用户全景信息，是每个场景都需要的公共能力。搜索场景需要，首页需要，营销会场也需要。把它放在共享主干里，意味着新增场景可以直接继承这份兴趣理解能力，不用重新训练。

2.3 MoE式专家网络与场景门控，解决“一碗水端平还是端不平”

光有共享主干还不够。不同业务虽然共用一套底层理解，但目标函数和排序约束差异很大。首页Feed更看重综合体验和下单转化，搜索结果更看重query相关性，券场景更看重优惠核销效率。

MTFM在架构上采取了专家网络加门控的组合思路：共享主干提取的特征会喂给一组场景专家网络，每个专家负责一部分行为模式，场景门控根据当前的业务场景，动态决定各个专家的权重组合。

打个比方，主干网络像一个会做所有菜的老师傅，专家网络是老师傅在不同菜系上的熟练度，场景门控就是客人点菜时的“今天主要吃辣还是吃淡”。同一个老师傅，可以根据不同客人的需求调整出菜风格，而不是每个菜系都雇佣一个独立的厨师。

门控机制放在外卖场景还有一个额外好处：新业务场景冷启动时，不需要从头训练整个模型，只需要初始化一组新的场景门控参数，先借用现有专家的能力初始化组合，再用少量业务数据微调即可。这个特性对外卖这种频繁上线新营销玩法、新频道页的业务形态，特别实用。

3. 多目标与多场景的平衡术：点击、下单、客单价不能互相打架

推荐系统里有一个永远绕不开的问题：模型要同时预测多个目标，但这些目标之间不总是正向关系。MTFM落地的过程中，多目标博弈是调整最多的部分。

3.1 外卖业务的目标拓扑比电商更依赖“核销闭环”

外卖并不止于点“下单”那一刻。用户点了，商家接单、骑手配送、用户最终吃上，才算完成闭环。所以外卖推荐的目标集合通常包含这几层：

多目标共同优化时最大的坑是“目标打架”。比如，提高下单率最简单的路径是疯狂推荐低价商家，但低价商家客单价低，不利于商家生态和运力效率。另一个极端是推高客单价，结果用户转化率下降，体验变差。

MTFM在多目标问题的处理上，绕不开主任务与辅助任务的分层设计。下单和GMV这类主目标放在任务塔的顶层，加购、收藏这类辅助目标嵌入到多任务学习的中间层。辅助目标不直接参与最终排序，但它们为兴趣建模提供更多的监督信号，尤其对新用户和新商家的冷启动帮助巨大。

3.2 从单目标换多目标的实操细节

这里值得展开讲讲实操细节。很多团队从单目标模型升级到多目标模型时，最容易犯的错是把所有目标直接加权求和当成一个loss。MTFM落地的过程中，应该做的是分阶段处理：

• 第一阶段，先把弱相关目标（收藏、加购）作为辅助loss挂到中间层，让主干网络学习到更丰富的用户意图表征。
• 第二阶段，把下单率与体验类目标用uncertainty（不确定性加权）或pareto调参方式组合，而不是拍脑袋给固定权重。
• 第三阶段，针对特定业务场景，在最终排序层再叠加一套业务规则，比如“新客转化任务”可以在基座输出的基础上，对新人专享价商家做加权。

每一步都必须盯住离线指标差和在线实验变化。很多目标之间的冲突在线下指标根本看不出来，只有上了小流量实验，看到真实用户在行为路径上的反馈，才能确定权重方向是否合理。

3.3 负样本与样本权重的那些坑

多目标模型更依赖样本质量。单场景模型时代，曝光未点击做成负样本是很自然的逻辑。但外卖场景里一个用户可能因为配送超时放弃下单，这不代表她对商家没兴趣。

MTFM在样本层面的处理有几个值得抄作业的点：

• 负样本不能只取“曝光未点击”。要把点击后长时间不转化、下单后取消都拆分成独立样本类型，让模型学到“有兴趣但被价格和配送劝退”与“完全没兴趣”之间的区别。
• 正样本要按时间衰减加权。一个月前和昨天的下单行为，对当前推荐结果的影响完全不同，时间衰减权重可以避免长期偏好淹没短期意图。
• 跨场景样本要统一拼接。用户在一个Session里的搜索、点击、下单行为要按时间线组织成一条完整序列，而不是每个场景单独截取一段。这直接决定了基座能不能学到“用户在多个场景间跳跃的真实动机”。

4. 逐个场景落地的推进节奏：先跑通边角，再啃硬骨头

MTFM这种统一基座如果一上来直接替换首页Feed流，很容易因为模型体量大、延迟高、目标复杂而翻车。合理的推进节奏是先用低风险场景完成框架验证，再逐步冲击核心场景。

4.1 先用低流量的营销会场做小规模验证

外卖平台通常会有大量频道页、运营位、营销会场，有的流量不大但业务目标清晰，比如某个新品类推广页、某个城市的周末促销专场。这类场景的特点是目标纯粹、样本相对稀疏、出问题影响面小。

把这类场景作为MTFM首批接入对象，是性价比很高的选择。接入方式也相对简单：基座模型保留共享主干，只新增一组营销场景专用的门控和任务塔，用该会场的历史数据微调几个迭代。由于共享主干已经具备丰富的用户行为理解能力，即使营销会场只有少量样本，模型也能快速学到该场景特有的促销偏好。

在这个阶段最重要的是验证两件事：一是基座加载到线上后，特征服务、模型推理、延迟是否可控；二是新场景在样本不足的情况下，能不能通过共享参数明显提升初始效果。我拆过的类似项目里，这个阶段通常能拿到5%到15%的离线指标提升，是给团队信心的关键一步。

4.2 首页Feed流上量的扩容过程

首页Feed是外卖App的主战场，流量大、目标复杂、对延迟极度敏感。MTFM切首页Feed的关键是前置优化工程链路，而不是只盯模型效果。

第一要解决的是特征时效性。首页推荐极度依赖实时信号，最近10分钟内的点击、加购、券领取行为，必须能够在几百毫秒内进入特征服务。MTFM的特征体系从离线批量切到在线实时流式更新时，必须保证共享Embedding的刷新速度和一致性。我的实操经验是，实时特征接入初期，要重点盯特征延迟分布，而不是平均延迟。少数用户的特征延迟，会害得整个排序结果看起来严重过时。

第二要解决的是推理延迟。全量基座大模型如果每个请求都完整计算一遍所有专家网络，延迟会很高。MTFM在首页落地时，会采用“分层延迟放行”的思路：先基于召回结果和轻量特征，过滤掉大部分不相关的候选商家；只有进入排序阶段的小候选集，才运行完整的共享主干和场景门控。这个修剪过程直接决定线上性能和模型效果的平衡点。

首页Feed上量之后，验证的主要看三点：曝光点击率、下单转化率和客单价是否齐涨；首页推荐与搜索场景之间是否存在互相抢夺流量的负向效应；共享模型对腰部商家、新开商家有没有明显的偏置。

4.3 搜索排序场景的额外约束：query意图不能被共享参数稀释

在所有外卖业务场景里，搜索排序是最容易“被基带拖垮”的场景。因为搜索场景用户意图明确，query带来的相关性信号非常强，如果基座模型一味强调共享用户兴趣，很可能把用户对过往商家的历史偏好强加到本次搜索上，结果“我想吃麻辣烫”却推荐了一堆用户喜欢的日料店。

MTFM在搜索场景落地时，会做一道关键隔离：query相关性特征不与共享embedding做全局融合，而是通过一个专门的搜索语义分支进入排序网络。共享主干提供用户的长期画像与场景上下文，搜索分支提供本次查询的即时意图，两部分向量汇合后，再进入搜索场景的任务塔。

这个设计听起来简单，但实际落地过程中，如何让共享模型“知道”自己进入搜索场景且必须以上次query为第一优先级，需要大量的场景ID特征和注意力门控调优。这一步很考验工程团队的联调能力，因为线上搜索日志和静态用户行为日志经常是两套系统，样本拼接本身就是脏活累活。

搜索场景的验证思路也和首页不同。首页盯着整体转化，搜索场景首先要盯相关性指标，比如搜索点击率、query意图满足率、无结果率、过滤率。只要相关性不崩，再用基座带来的兴趣个性化去提升排序和转化。

4.4 营销券场景：优惠敏感度特征需要被公共化

外卖券场景和首页、搜索都不太一样，它的核心不是“吃什么”，而是“怎么买更划算”。同一个用户，面对同店铺，发券前后下单概率可以差出好几倍。

MTFM会把优惠券敏感度作为一个公共能力建在基座里，而不是只在券场景局部建模。具体做法是把用户在历史行为中表现出的领券率、券后下单率、券核销周期这些信号，纳入长期兴趣画像向量。这样所有场景在排序时，都能感知到用户当前的优惠敏感状态。

这个设计对多业务协同尤其有意义。比如用户刚在券场景领了一张大额满减券，转头在首页Feed流看到同一个商家，如果首页推荐模型感知不到这张券的存在，很可能错过一次高转化机会。共享基座让这种跨场景的信息传导成为可能，这也是统一基座大模型相比单场景模型的又一个核心优势。

5. 工程侧的三个关键保障：延迟、回退和实验口径

模型结构再先进，落地时工程侧的保障跟不上，照样会被业务骂下线。MTFM实践里最容易被低估的三个工程问题是延迟、回退和实验口径。

5.1 共享模型变大之后，延迟是第一个被质疑的点

统一基座模型一大，所有人都会自然质疑：外卖这种毫秒级实时请求场景，能扛得住吗？实际情况是，共享基座并不等于每个请求都要全量跑一遍大模型。工程上可以拆分：

• 召回阶段用基座生成的用户向量和商家向量做最近邻检索，这部分用ANN（近似最近邻）索引解决，通常只需个位数毫秒级。
• 排序阶段要跑完整模型，但输入的特征已经提前做好embedding查找和向量缓存，模型计算只针对候选集进行。

这套多级架构之下，基座大模型本身并不会成为吞吐瓶颈。真正的瓶颈反倒容易出现在特征环节：共享模型需要更多维度的特征，特征服务的QPS压力会急剧上升。我的经验是，提前做好特征缓存和预热，把热门用户、热门商家高频请求的embedding结果缓存起来，可以显著降低推理延迟的P99分位值。

5.2 多场景AB实验与回退方案

多业务场景共享一个基座模型，最大的工程复杂度在于“牵一发动全身”。原来首页模型升级，只影响首页实验；现在MTFM升级，所有接入场景会同时受到影响。

所以MTFM落地时要建立一套多场景AB实验体系。每一轮基座模型升级，不是只看整体大盘涨跌，而是分别观察每个接入场景的关键指标，并设置独立的护栏指标。比如首页可以允许点击率小幅波动，但搜索相关性指标一旦低于阈值，该场景就立即切回旧模型应用层策略。

回退方案也需要做细。为了防止一个场景出问题把模型整体回退、导致其他正常场景流量波动，建议按场景维度配置回退开关。也就是说，基座模型的参数是共享的，但线上接入层要能做到“热切换”，让每个场景都能独立决定走新模型还是旧模型路径。

这种“共享模型、独立开关”的设计，在实际故障处理中救过我不止一次。有一次升级推进过程中，券场景出现了核销率下降，如果是整体回退，首页那批已验证的收益也会丢掉。但因为开关独立，我们只把券场景回退到上一版本，其余场景继续观察，很快定位到了是券场景任务头对样本权重的敏感度过高，而不是基座主干出了问题。

5.3 样本口径的统一才能让离线评测变得可信

最后说一个最不性感但最容易翻车的工程点：样本口径。

MTFM这种多业务共享模型，对样本拼接的依赖远高于单场景模型。如果几个业务团队各自产出样本，A团队把“点击后下单”当作正样本，B团队把“点击后加购”也当作正样本，C团队又把“曝光未点击”的正样本权重调得很高，那么共享参数会从第一天起就开始学错。

所以在MTFM建设过程中，必须把样本口径收敛成全平台统一的标准，包括但不限于：

• 行为时间戳以服务端日志为准，不以App端上报时间为准。
• 曝光、点击、加购、下单、取消必须通过统一的Session ID串联。
• 负样本采样比例和采样方式全场景统一，场景特例只能通过样本权重体现。
• 训练集和验证集按天切分，禁止随机切分，避免同一天行为跨集合造成数据泄漏。

样本口径统一之后，离线评测指标才真正具备跨场景可比性。否则你看到“基座在券场景提升了转化率”很可能只是样本生成逻辑不同带来的幻觉，不是模型真变强了。

6. 踩过几个坑之后，我对统一推荐基座落地这件事的真实体会

最后聊点个人的主观感受，这部分不写方法论，写代价。

第一个感受是，建立统一推荐基座，至少有一半的工作是组织层面的，而不是算法层面的。MTFM这种项目能不能推进，取决于团队愿不愿意把手里的独立模型、独立样本、独立特征让出来。如果你的组织和考核方式还是按业务线切分，每个业务线都对“共享主干”没有充分信任，那么统一基座即使技术上做出来了，也很难在线上全量推开。

第二个感受是，不要高估离线指标，更不要高估第一次上线效果。统一基座在离线评测上的提升，往往比单场景模型的提升更好看，因为它整合了更多跨场景信息。但上线后会面临实时性、特征服务稳定性、策略叠加等一系列损耗，最终在线收益可能是离线收益的1/3甚至更少。这个心理建设一定要提前做，否则团队很容易在第一次大规模实验效果不及预期时退回去。

第三个感受是，基座大模型不是一劳永逸。MTFM上线之后，日常依然是持续迭代：新业务场景接入、新特征维度扩展、样本权重调整、专家网络容量扩充。它解决的真正问题，不是让模型一次性做到最好，而是让每一次后续迭代都能沉淀在全平台共享的能力层上，而不是散落在各业务各自为战的角落。

对还在犹豫要不要做统一推荐基座大模型的团队，我的建议是：如果业务场景超过三个、数据规模和团队人数都明显增长，越早做这个沉淀越省钱。但一定要想清楚，你建的不是一个更贵的模型，而是一套能让业务快速复用公共能力的基础设施。从这个角度说，MTFM在外卖多业务场景的落地实践，本质上是把推荐系统从“项目制”转向“基建制”的一次完整示范。