企业官网建设流程全解析

1. 从“一个业务一套模型”到统一基座：多场景推荐系统的必然选择

1.1 外卖推荐的独特困境：场景多、时效强、约束复杂

做推荐系统的人都知道，外卖推荐和电商推荐、内容推荐有本质区别。电商推荐的核心是“人和商品的匹配”，内容推荐的痛点是“兴趣探索与信息茧房的平衡”，而外卖推荐的难题在于：它是在强LBS约束、强时效约束、双主体决策（商家+菜品）之下的复合匹配问题。

先拆解一下外卖推荐的几个典型业务场景。用户打开美团外卖App，看到的首页信息流是“综合推荐”，这里混排了商家、菜品、营销活动；搜索场景是“意图明确的检索推荐”，用户已经输入了“黄焖鸡”或“麻辣烫”，系统要给出排序结果；广告场景要在有限的展位里做商业化最优解；营销场景要结合满减、折扣、新客立减等券策略。这些场景的用户状态、决策成本、信息密度、约束条件完全不同。

更麻烦的是，外卖场景存在非常强的时间动态性。午餐高峰、晚餐高峰、夜宵时段，用户的诉求完全不一样；阴雨天、节假日、大型赛事直播时，订单结构和供给状态会剧烈波动；一个商家今天是否营业、当前是否爆单、出餐速度如何，直接影响推荐准确性。这意味着模型必须同时感知“用户的长期偏好”、“当下的短期意图”、“实时的供给状态”三个层次的信息。

我以前在电商场景做推荐时，模型最大的挑战是“点击率预估的精度”，而外卖场景最大的挑战是“多场景的一致性与多样性平衡”。如果你为一个场景单独建模，每个模型都要重新学习用户基础偏好、商家质量信号、菜品品类关系，这种重复建设在数据量充足时还能忍受，但在新场景冷启动、长尾商家推荐、跨场景联合优化时就非常吃力了。MTFM这种统一推荐基座大模型，本质上就是为了解决这个问题——它把“基础理解能力”抽出来做成共享底座，让各个业务场景专注做自己的精细化目标。

1.2 传统多模型架构的瓶颈：重复建设与协同缺失

在MTFM这种统一基座方案出现之前，外卖推荐系统的典型架构是：每个业务场景一套独立的模型体系。首页推荐有首页的深度模型，搜索排序有搜索的排序模型，广告竞价有广告的CTR/CVR模型，营销权益有营销的响应模型。每套模型从特征工程做起，用户特征、商家特征、菜品特征、上下文特征各自定义各自加工，模型结构各自设计各自调参，训练样本各自采集各自的日志。

这套架构在业务初期没有问题，甚至是最快的落地路径。但业务发展到一定规模后，问题就非常明显了。第一是特征工程的重复造轮子：用户的历史消费序列、商家的评分质量分、菜品的品类标签，这些基础特征在每个场景都要重新加工一遍，光是对齐口径就要花掉大量开发时间。第二是样本稀疏场景的冷启动困难：新上线的场景或新接入的流量位，如果只有几十万样本，训练出来的模型效果非常差，而统一基座可以用全场景的海量样本预训练出通用表示，新场景只需少量微调就能达到可用的效果。

第三点可能是最致命的：多模型之间缺乏协同，导致用户体感分裂。用户在首页看到了一个“高分商家”，点击进店之后，店内的“菜品推荐”却给他推了一个低分菜品，搜索同一个商家时排名又不一样。这些不一致本质上是不同模型对同一个商家的理解不同，而统一模型天然可以保证底层表示的一致性。

所以MTFM的出现不是偶然的炫技，而是多业务场景发展到一定阶段后，对“降本增效”和“体验一致性”双重诉求的回应。从技术路径上看，它不是推翻所有业务场景模型，而是重新规划了“主干模型与场景任务”的分工协作方式。

2. MTFM的架构设计思路：解耦、共享、可扩展

2.1 基座大模型的“底座”与“头”如何划分

要理解MTFM的设计，先看名字：MTFM，可以理解为Meituan Takeout Foundation Model，也就是美团外卖的基座模型。它不是一个单一大模型包打天下，而是一个“共享底座+多任务自适应头”的体系。这种架构理念和业界熟知的BERT、GPT的“预训练+微调”范式一脉相承，但落地的技术细节要复杂得多。

核心设计思路有三个关键词：解耦、共享、可扩展。

先看解耦。模型被拆成三层：最底层是统一的特征表示层（Embedding层），负责把用户ID、商家ID、菜品ID、品类ID、地理位置ID等离散特征映射成稠密向量；中间层是共享的语义理解层（主干网络），负责捕捉用户偏好、商家质量、菜品关联等通用知识；上层是场景任务层（Task Layer），每个场景都有自己的输出头和Loss设计。举个例子，首页推荐的头可能输出“点击概率”和“下单概率”，搜索排序的头输出“相关性得分”和“转化得分”，广告场景的头还会增加“竞价价值评估”。

再看共享。所谓共享，不只是参数的共享，更重要的是样本的共享。MTFM在预训练阶段用全场景的样本联合训练主干网络，这样首页场景的样本可以帮助搜索场景学习用户偏好，餐饮场景的样本可以帮助零售场景学习品类迁移。对于数据稀疏的场景，这种跨场景知识迁移带来的是“从0到1”的突破。

最后看可扩展。新场景接入时，不需要从零搭建一套模型，只需要在基座之上新增一个任务头，用该场景的相对少量样本微调即可。这种可扩展性在业务快速迭代时期的价值怎么强调都不为过——以前新场景冷启动的模型开发周期是按月计的，统一基座方案能做到按周甚至按天。

2.2 主干网络选型：为什么不是“越大越好”

做推荐的人容易被“大模型”三个字带偏，觉得参数规模越大越好。但在真实的在线推荐系统里，模型的参数量和推理延迟是硬约束。外卖首页推荐流的一次请求，要处理的候选商家和菜品可能是数千级别，后端给模型的推理时间预算通常只有几十毫秒到一百毫秒。如果基座模型的单次推理要跑几十毫秒，线上根本扛不住。

所以MTFM的设计逻辑是：基座模型不是去替代线上实时排序的最终模型，而是通过“预训练知识蒸馏+场景自适应微调”的方式赋能各场景。主干网络的规模设计折中了表达能力和在线耗时，通常选择中量级规模的深度模型架构，比如多层Transformer或DCN类模型，结合MMoE、PLE这类多任务学习结构。这既是工程约束的选择，也是业务效率的选择。

选型时还要考虑一个实际问题：多任务之间的冲突。不同场景的目标函数差异很大，首页推荐希望用户多逛多看，搜索希望快速匹配意图，广告希望提升商业收入。如果简单地把这些目标塞到一个模型的输出层，会互相干扰。所以要引入任务门控机制，比如每个任务都有独立的Gate网络，根据输入特征动态调整对共享表示的利用权重，这样模型能学习到“什么场景应该更看重什么信号”。

2.3 特征体系设计：统一的ID映射与分场景特征入口

特征体系是统一基座模型最容易被低估的部分。很多团队以为统一模型就是把所有特征堆在一起训练，结果往往是“数据穿串、训练崩溃、效果负向”。

MTFM的特征设计讲究“统一底座、场景入口、动态接入”。所谓统一底座，是指用户ID、商家ID、菜品ID、城市ID、品类ID这些核心对象全部使用统一映射和统一Embedding。这样同一个用户在不同场景中进入模型时，他对应的用户向量是在同一个语义空间里的，这从根本上解决了“场景间用户理解不一致”的问题。

场景入口是指每个业务场景可以在此之上接入自己特有的特征。比如广告场景需要接入“出价”、“广告主预算”等商业特征；搜索场景需要接入“query文本特征”；营销场景需要接入“券类型”、“门槛”等权益特征。这些特征通过场景任务头输入模型，不会污染共享表示层。这种“共享骨架+局部肌肉”的方式，既保证了模型的统一性，又保留了各场景的灵活性。

提示：在实际落地中，特征接入的规范和校验非常重要。我见过不止一个项目因为“某个场景往共享特征里塞了一个异常字段”导致整体模型效果波动。所以落地统一基座时，一定要建立特征准入清单和上线回归机制。

3. 从训练到部署：MTFM落地的核心实操环节

3.1 全场景样本融合与样本权重策略

统一基座模型的训练数据来自所有业务场景的日志。这里第一个坑就是样本量级的差异。首页的曝光样本可能是搜索的10倍以上，如果直接混合训练，模型会被首页样本“带偏”，搜索场景的知识就学不到了。

解决思路是设定场景采样比例和样本权重。比如定义每个场景的目标训练占比，首页流量大但占比控制在30%，搜索占25%，广告占20%，其他场景分配剩下的25%。具体比例需要根据业务重要性和场景间知识共享价值反复调优。另一个有效做法是给样本设置权重系数，对目标场景的核心行为（如下单）提高权重，对辅助场景的间接信号（如曝光）降低权重。

样本融合还要解决时间窗口一致性问题。不同场景的日志延迟不一样，广告日志可能要延迟几分钟，搜索日志相对实时。如果特征拼接时用了不同时间点的数据，模型学到的可能就是“错位的因果”。实操上建议为每条样本都打好统一的事件时间戳，并且特征拼接采用“样本行为发生时刻之前最近可用的特征”，避免未来信息泄漏。

我自己做这类多场景模型时，还有一个习惯：把样本按场景写入独立的TFRecord文件，训练时动态采样，而不是把所有样本物理混合成一个文件。这样既灵活调整采样比例，也能在排查问题时按场景回溯数据质量。

3.2 任务头设计与Loss加权组合

MTFM的多任务头设计，可以参考多任务学习里经典的MMoE/PLE结构。核心思路是：共享底层表示之后，每个任务一个Tower，Tower之上是任务特定的输出层。每个Tower可以有不同的特征输入、不同的网络深度、不同的激活函数。比如搜索场景的任务头需要更关注文本语义特征，广告场景的任务头需要更关注商业信号。

Loss设计是这个环节的关键。多任务模型最怕的就是“跷跷板效应”——提升一个任务的效果而损害另一个任务。常用的缓解手段是不确定性加权，为每个任务的Loss学习一个权重参数，让模型自动平衡各任务的量级和难度。另一个手段是阶梯式训练：预训练阶段只训练共享层和主任务头，让主干网络先学到通用表示；微调阶段再解锁全部任务头，用小学习率场景化精调。

注意：多场景Loss的权重不要太“贪心”。我见过一个项目，为了提升商业化收入，把广告任务的权重调得过高，结果首页的整体点击率和转化率明显下滑，最终用户体验变差，商业收入反而因为流量大盘下降而回落。多目标优化的结果是看“全局产出”，而不是看“单场景指标”。

3.3 预训练与微调范式的落地节奏

基座模型的训练分两步走。第一步是全场景预训练：用几周的融合样本，训练一个包含全部任务头的完整模型。这个阶段的训练量很大，通常需要在分布式训练集群上跑数天。预训练产出的不只是模型参数，还包括一套共享的Embedding表和特征标准化参数，这些也要存下来供后续复用。

第二步是场景微调与在线部署：各业务场景基于预训练的基座参数，用自己的近期样本做少量epoch微调。微调后的模型体积通常明显小于全量基座，在线推理耗时可控。这就是MTFM的“统一下游赋能”模式——基座模型是“母版”，场景微调是“衍生版”。

实际操作中，有时候为了极致性能，会把基座模型的知识蒸馏成各场景的小模型。蒸馏的好处是小模型可以针对场景做结构搜索（NAS），在保证效果接近大模型的情况下把推理时延再压低一半。不过蒸馏会带来信息损失，需要反复验证收益与损失是否划算。

3.4 在线推理的服务化架构与性能控制

在线推理环节，统一基座模型最大的挑战是QPS和时延。外卖业务的高峰时段，推荐接口的QPS是数万级别，每一次用户刷新都需要在极短时间内完成候选召回、特征拼接、模型打分、排序截断的全流程。如果基座模型直接上线，单条推理耗时可能达到几百毫秒，这完全不可接受。

常见的解法有两种：一种是模型裁剪，把共享层做得足够轻，只保证在线推理所需的表示能力；另一种是蒸馏部署，用离线大模型蒸馏出在线小模型，在线只跑小模型。很多团队会组合使用：平时跑蒸馏小模型，同时线上用大模型做离线批量打分补充——比如只在用户冷启动时或特定活动场景下，才动用大模型的复杂计算。

性能优化还可以从工程侧入手。特征计算可以提前做成分层缓存：用户静态特征按天缓存，商家动态特征按分钟缓存，上下文特征实时计算。模型推理可以借助GPU/CPU混合调度，把高耗时的Transformer层放到GPU，把轻量的Embedding查询放到CPU，让计算资源各司其职。这些细节看似不起眼，但在大流量场景下，每节省10毫秒都能带来明显的成本收益。

4. 多业务场景落地中的常见问题与排查实录

4.1 场景间知识冲突：共享表示被“带偏”怎么办

统一基座模型实践中，我遇到过最典型的问题就是场景间知识冲突。比如用户在外卖首页点击了很多“高客单价”商家，但在广告场景里却对“低客单价”的竞价商品更敏感。共享Embedding层如果学到一个“高客单价偏好”的强信号，在广告场景就会被错误复用，导致广告推荐不精准。

排查这个问题的方法是分场景观察共享层的输出分布。具体来说，把预训练好的基座模型对每个场景的样本分别计算用户Embedding，然后做聚类或可视化。如果发现某个场景的用户向量分布显著偏移其他场景，说明共享层被这个场景的特殊行为主导了。解决办法要么是在主干网络中加入场景偏置项（即每条样本都输入“当前场景ID”作为特征），让模型学会“根据场景调整表示”；要么是调整采样比例，限制这个场景的样本量级。

实操经验：场景ID作为特征的方式，虽然是“偷懒”的做法，但在工程上极其有效。模型会自己学到不同场景下的表示差异，问题就从一个架构问题变成一个调参问题，后者可控得多。

4.2 新场景/长尾商家冷启动效果不佳

统一基座模型在数据充足的主流场景效果很好，但在新场景或长尾商家上仍然会失灵。原因是：基座模型学到的是“平均规律”，对于分布外（OOD）的样本，它的泛化能力依然有限。

针对新场景冷启动，我的建议是分级处理。首先用基座模型做零样本推理，看效果基线；然后收集该场景的小批量样本做轻量微调；如果样本量实在太小，可以考虑从相似场景迁移特征或使用“场景级先验”。长尾商家的冷启动相对复杂，因为它们几乎没有行为数据。基座模型的商家Embedding只能依赖商家属性（品类、价格带、评分）来初始化。这个问题的解法之一是引入商家画像增强特征，把商家的经营数据（销量、转化率、客单价）和属性特征结合起来，让模型在缺乏用户行为时能通过经营者信息做更合理的预估。

还有一个踩过的坑：新场景接入时，不要一开始就追求“场景个性化”。先让基座模型“裸跑”几天，把场景数据积累起来，同时把场景的基线指标（点击率、转化率、GTM时长）打好底，再用微调模型逐步替代。一上来就微调，容易过拟合到少量样本上，效果甚至不如预训练模型。

4.3 线上效果与离线评估不一致：评审与回归体系怎么搭

统一模型最容易引发团队争执的就是“离线指标涨了，线上却跌了”。推荐系统的线上线下不一致是多方面因素造成的：特征分布漂移、采样偏差、评估口径不同、模型激进度的差异等等。

结合MTFM落地实践，我建议搭建三层评估体系。第一层是离线评估：用最近7～14天的历史日志做离线评测，重点关注分场景的AUC、GAUC和业务指标（加购率、下单率）。第二层是影子评估：新模型和线上模型同时接收真实流量，但不改变线上结果，只记录打分差异，用“如果上线会怎样”来复盘。第三层是小流量实验：选择1%～5%的低风险流量做A/B实验，观察分场景指标和用户反馈。

在评估体系中还要注意指标口径的统一。不同场景关注的核心指标不同，但必须有一个统一的“综合健康度指标”。在线实验时，既要看单场景的“效果”，更要看整体大盘的“收益净变化”。统一基座模型的优势就是改动一个底层表示可以影响所有场景，但这也意味着“风险也被放大了”。所以灰度节奏要稳，尤其要监控“负向场景”的出现：一旦发现某个场景指标明显下滑，应该立刻回滚或缩小实验流量。

4.4 模型迭代与版本管理的工程化支撑

基座模型一旦启动，迭代就不再是“一个模型一个模型地上线”，而是“一个模型体系一个模型体系地升级”。版本的升级意味着所有场景的微调模型都要重新生成并验证。这需要很强的工程化支撑。

第一是自动化训练流水线。从样本生成、特征拼接、模型训练、模型评估到导表上线，全链路自动化。特别是预训练模型的“启动文件”（包括特征Column、模型结构、超参数、训练脚本）必须版本化管理，任何改动都要走代码评审。

第二是模型版本的管理。我强烈建议搭建一个“模型档案库”，记录每个版本的训练数据、特征版本、模型结构、训练耗时、离线指标、实验效果、回滚原因等。后期排查问题时，没有这些记录几乎寸步难行。

第三是可解释性与可视化。统一基座模型是个“大黑盒”，出了问题很难定位。实操上可以针对重点样本做归因分析，比如输出某个用户对某个商家打分时，各特征的贡献值排序。留好这些debug工具，对多场景问题排查非常有帮助。

5. 复盘与展望：MTFM这类统一基座模型的后续演进

5.1 从“统一模型”到“统一决策大脑”

MTFM落地到现在，已经证明统一基座大模型在外卖多业务场景中是可行的、高效的。但站在一个从业者的角度看，这还只是起点。

下一步值得探索的方向，是让基座模型从“排序打分器”进化成“决策大脑”。所谓决策大脑，就是模型不只是给出一个点击率预估值，而是能综合判断“该给用户推什么”、“什么时候推”、“以什么形式推”、“怎么配合券和活动策略”。这种决策能力需要打通的不只是推荐系统内部的数据，还涉及营销、定价、供给调度等多个链路。MTFM的底层能力——统一特征、共享表示、多任务学习——正是承载这种综合决策的最佳底座。

5.2 从离线模型到在线持续学习

另一个值得关注的方向是在线持续学习。当前主流的推荐模型还是“离线训练+定时上线”的状态，模型的更新频率以天或小时计。外卖场景的时效性很强，商家营业状态变化、天气突变、节假日活动，都要求模型能更快地适应环境变化。MTFM这类基座模型因为有强大的共享表示层，理论上可以支撑“在线增量学习”，即模型上线后持续用新产生的行为数据进行实时更新。这个方向对训练框架、模型服务、数据管道的挑战都很大，但一旦跑通，推荐系统的实时性会再上一个台阶。

我自己对这个方向的体会是：不要一上来就想“全量在线学习”，风险太大。先从“基座参数定期更新+场景头实时更新”的混合模式做起，验证效果后再逐步扩大在线更新的范围，这样的路径更稳健。

5.3 关于落地节奏与团队组织的一点建议

最后给准备做统一基座模型团队的同行一点组织建议。统一基座模型不是一个纯粹的算法项目，它需要算法、工程、数据、产品多条线的深度配合。落地过程中最大的阻力往往不是技术，而是“各场景团队对统一模型的不信任”——大家会觉得“我用自己场景的模型不是更可控吗？”。

应对这个问题，我的经验是：不要强推统一，而是先把“统一后明显受益的场景”做出标杆，比如冷启动场景、新业务场景，用实际效果说话。同时保持“统一基座+场景微调”的灵活性弹性，让各场景保留一定的自主调参空间。这种“在统一中保留灵活”的模式，比绝对的一刀切更容易在复杂的组织环境中落地成功。

做MTFM这类系统的过程中，我最深的体会是：推荐系统的本质从来不只是“算法模型”，而是对用户、平台、商家多方价值的平衡。统一基座模型提供了一个很好的协作框架，让这种平衡可以从一个场景的局部最优，走向全局更优。这条路还很远，但方向是对的。