大模型浪潮下，双塔架构的“守”与“进”：一份面向生产环境的架构选型指南

最近和几位负责推荐系统架构的朋友聊天，话题总绕不开一个核心焦虑：现在大模型这么火，我们团队花了好几年打磨的双塔召回体系，是不是快过时了？是不是应该立刻All in到BERT、GPT这类庞然大物上？这种困惑非常普遍，尤其是在技术决策层，一边是业界对“大模型”近乎狂热的追捧，另一边是线上系统对“高并发、低延迟、稳如狗”的硬性要求。今天，我们不谈空洞的概念，就从几个真实的业务场景和压测数据出发，聊聊双塔模型、BERT序列模型以及GPT类生成模型，在推荐系统的召回、排序等关键环节，究竟该如何权衡与选择。这篇文章不是劝你放弃什么，而是帮你厘清，在资源有限、业务目标明确的前提下，如何做出最务实的技术决策。

1. 重新审视基石：双塔模型的核心优势与不可替代性

在讨论任何新技术之前，我们必须先理解旧技术为何能长期存在。双塔模型，这个在深度学习推荐系统早期就被广泛采用的架构，其生命力远比你想象的顽强。它的核心设计哲学是“隔离与预计算”，这直接命中了大流量互联网服务的命门。

想象一下一个日活数千万的短视频平台。每当用户刷新一次首页，系统需要在毫秒级时间内，从数亿甚至数十亿的视频库中，筛选出数百个候选集送给后续的排序模块。如果对每个用户-物品对都进行复杂的实时交互计算，所需的计算资源将是天文数字。双塔的巧妙之处在于，它将问题分解了：

• 物品塔：可以离线、异步地运行。利用昨晚的全量数据，预先将所有物品（视频）的特征通过深度网络转化成一个固定长度的向量（例如128维），存入高性能向量数据库（如Faiss、Milvus）。
• 用户塔：在线实时运行。根据用户当前的行为序列、画像特征，实时计算出一个用户向量。
• 匹配阶段：线上服务只需要做一件事——用这个实时生成的用户向量，去向量数据库里做一次近似最近邻搜索。这个操作经过高度优化，延迟极低。

# 一个简化的双塔线上服务伪代码示例
def online_inference(user_features):
    # 1. 实时计算用户向量 (用户塔前向传播)
    user_embedding = user_tower_model.predict(user_features)

    # 2. 从向量数据库中检索最相似的K个物品向量
    # 这一步是高效的向量检索，而非复杂的模型计算
    item_ids, scores = vector_db.search(user_embedding, top_k=100)

    # 3. 返回候选物品ID
    return item_ids

这种架构带来的优势是压倒性的：

特性	双塔模型	说明
线上延迟	极低 (毫秒级)	核心是向量检索，计算复杂度与候选池大小对数相关。
吞吐量	极高	物品向量离线计算，线上负载只与用户请求量有关，易于水平扩展。
冷启动处理	相对友好	新物品只需离线过一次物品塔即可入库；新用户可通过实时行为快速生成向量。
系统复杂度	较低	架构清晰，离线/在线流程解耦，易于维护和调试。

注意：这里说的“低复杂度”是相对于需要在线进行复杂交互计算的模型而言。双塔本身在特征工程、负采样策略、损失函数设计上依然有很深的优化空间。

所以，当你听到“双塔过时”的论调时，首先要问：我的业务场景，是否已经不再受制于吞吐量和延迟这两个硬指标？对于绝大多数用户体量庞大、对响应速度有苛刻要求的消费级互联网产品，答案显然是否定的。双塔不是“落后”，而是在效率与效果之间，选择了优先保障效率这一侧。它是推荐系统大规模召回的“压舱石”。

2. 交互式模型的进击：BERT如何重塑排序阶段的认知

如果说双塔是负责“海选”的快速筛选机制，那么精排阶段就是“决赛圈”的精细比拼。这里，我们不再满足于用户和物品的独立表征，而是迫切需要捕捉二者之间细粒度的、动态的交互信号。这正是BERT等基于Transformer的交互式模型大放异彩的舞台。

BERT在推荐中的应用，通常不是替代整个双塔，而是接管精排环节。它的核心价值在于“深度理解”：

1. 序列建模能力：用户最近点击、观看、购买的一系列物品，构成一个行为序列。BERT能很好地捕捉这个序列中的模式、趋势和即时兴趣。例如，用户连续看了三个“露营装备”相关的视频，那么下一个视频是“帐篷搭建教程”的概率就远高于“美妆教程”。
2. 细粒度特征交叉：在精排阶段，我们可以将用户特征（画像、实时序列）和候选物品特征（标题、标签、统计信息）拼接成一个长的输入序列，送入BERT。模型中的多层Self-Attention机制会自动学习特征之间任意复杂的交叉关系，这是双塔顶层的简单点积或余弦相似度无法比拟的。

# 一个简化的BERT精排模型输入构造示例
# 假设我们有一个用户和待评分的物品
user_sequence = ["item_id_123", "item_id_456", "item_id_789"]  # 用户近期行为序列
item_feature = {
    "title": "便携式户外折叠椅",
    "tags": ["户外", "休闲", "便携"],
    "category": "运动户外"
}

# 构建模型输入： [CLS] + 用户序列 + [SEP] + 物品特征 + [SEP]
model_input = tokenizer.encode(
    "[CLS] " + " ".join(user_sequence) + " [SEP] " +
    item_feature["title"] + " " + " ".join(item_feature["tags"]) + " [SEP]",
    return_tensors="pt"
)
# 经过BERT模型，取[CLS]位置的输出作为匹配分
match_score = bert_model(model_input).pooler_output

然而，强大的能力伴随着显著的代价：

• 计算成本高昂：每个用户-物品对都需要进行一次完整的前向传播，计算量是O(用户序列长度 + 物品特征长度)的平方级（由于Attention机制）。这限制了它在召回阶段直接应用。
• 服务延迟挑战：即使只用于精排（从几百个候选里挑几十个），也需要精心优化（如模型蒸馏、量化、高性能推理引擎）才能满足线上要求。
• 数据与训练需求：需要大量高质量的序列标注数据，训练成本远高于双塔。

提示：在实际生产中，一种常见的混合架构是“双塔召回 + BERT精排”。双塔负责从十亿量级中快速召回一千个候选，BERT则在这一千个候选上进行精细打分和重排。这样既利用了双塔的效率，也获得了BERT的深度理解能力。

3. 生成式模型的颠覆性想象：GPT类模型是下一代推荐引擎吗？

当业界还在消化BERT带来的变革时，以GPT为代表的自回归生成式大模型，又打开了一扇新的大门。它不再满足于“匹配”或“排序”，而是试图“创造”推荐。这带来了根本性的范式转变。

传统的推荐是检索式或判别式的：从已有物品库中找最相关的。而生成式推荐，则可以是创造式的。例如：

• 生成个性化摘要：不是推荐一篇长文章，而是根据用户兴趣，直接生成这篇文章的个性化内容摘要。
• 生成购物清单：用户输入“为周末家庭烧烤做准备”，模型直接生成一个包含食材、工具、配料的购物清单，每个条目都可以链接到具体商品。
• 跨模态推荐与创作：用户说“我想要一首听起来像雨夜咖啡馆氛围的爵士乐”，模型可以生成一段符合描述的音乐旋律（或推荐现有音乐），甚至生成对应的封面图。

这种能力的背后，是模型对用户意图和世界知识的深度建模。它不再依赖于一个静态的物品库，而是从一个更广阔的“知识”或“内容”潜在空间中生成结果。

但是，将其应用于生产环境，目前面临巨大的鸿沟：

1. 可控性与安全性：生成的内容是否合规、准确、无偏见？如何确保推荐的商品是真实可购买的，而不是模型“幻觉”出来的？
2. 延迟与成本：生成一段文本或一个列表，所需的时间远超一次分类或匹配。API调用成本对于大规模C端业务目前难以承受。
3. 评估体系重构：如何评估生成推荐的质量？传统的CTR、CVR指标还适用吗？需要引入更多人工评估或基于内容的指标。

因此，当前GPT类模型在推荐系统中的落地，更多是辅助性和探索性的：

• 特征增强：用大模型为物品生成更丰富的语义描述标签（Tag），或为用户行为序列生成概括性兴趣标签，作为特征输入给传统的双塔或BERT模型。
• 查询理解与重写：在搜索推荐中，将用户简短的、模糊的查询，扩展或重写成更能表达其意图的、适合检索的语句。
• 对话式推荐探索：在客服、导购等交互深度较强的场景，进行小范围的试点。

4. 架构选型实战：如何根据你的业务场景做决策？

理论聊完了，我们来点实在的。面对这些技术选项，技术负责人该如何拍板？下面这个决策框架或许能给你一些启发。

首先，问自己四个核心问题：

1. 业务阶段与规模：你是从0到1的创业公司，还是日活千万以上的成熟产品？你的物品库是百万级、千万级还是十亿级？
2. 核心优化目标：当前业务的瓶颈是召回多样性不足（需要更多优质候选），还是排序精度不够（用户对推荐结果不满意）？是追求用户体验的极致个性化，还是保障系统稳定的不宕机？
3. 团队与资源：团队有多少算法工程师？他们的经验主要集中在哪个领域？公司的计算预算（训练/推理）是否充足？
4. 可接受的技术债务：你愿意为了潜在的效果提升，承担多高的系统复杂度和运维成本？

基于这些答案，我们可以勾勒出几条典型的路径：

路径A：稳定优先，效率至上的成熟业务

• 特征：DAU高，物品库巨大，线上延迟要求严苛（<50ms），团队资源主要投入在业务迭代而非前沿探索。
• 推荐架构：强化双塔召回 + 轻量级精排。
  • 召回侧：持续优化双塔模型。这不是“躺平”，而是深挖。重点方向包括：
    • 引入更复杂的负采样策略（如基于流行度的采样、Hard Negative Mining）。
    • 尝试多目标学习（同时优化点击、点赞、完播、分享等多个目标）。
    • 使用知识蒸馏，用更复杂的精排模型（教师模型）来指导双塔（学生模型）的训练，将精排模型的知识“压缩”到双塔中。
  • 精排侧：采用复杂度可控的模型，如 Wide&Deep、DeepFM，或轻量级的Transformer变体（如线性Attention）。核心是稳定和快速。
  • 为什么不用BERT/GPT？ 不是不想用，是成本收益比在当前阶段不划算。线上服务稳定压倒一切。

路径B：效果驱动，有一定容错空间的成长型业务

• 特征：DAU中等，物品库百万-千万级，愿意用稍高的延迟（100-200ms）换取用户体验的显著提升，有专门的算法团队进行模型优化。
• 推荐架构：双塔召回 + BERT级精排。
  • 这是当前业界效果与效率平衡的“甜点区”。在召回阶段，依然依赖双塔的效率保障。在精排阶段，引入BERT或类似结构的序列模型。
  • 关键挑战与优化：
    • 模型压缩：必须对BERT进行蒸馏、剪枝、量化，将其参数量和服务延迟降低到可接受范围。
    • 工程优化：使用 TensorRT、OpenVINO 或厂商专用的推理加速库，优化模型在线推理性能。
    • 缓存策略：对高频用户或热门物品的中间计算结果进行缓存。

路径C：创新探索，寻求差异化体验的业务

• 特征：业务本身具有强交互、强内容属性（如AI社交、创意工具、高端导购），用户对新颖性接受度高，团队有较强的研究和工程能力。
• 推荐架构：传统链路 + 生成式增强。
  • 保留原有的召回-排序链路作为基础保障。
  • 在特定场景开辟“实验田”：
    • 用大模型生成个性化的推荐理由（“为你推荐，因为你看过XX”）。
    • 在用户搜索无结果或结果不满意时，用生成式模型创造或组合新的内容选项。
    • 构建对话式推荐机器人，用于提升用户粘性和探索兴趣。
  • 核心是小步快跑，快速验证价值，而不是全盘替换。

在我经历的一次系统升级中，我们团队选择了路径B。初期直接上线全尺寸BERT导致精排服务延迟飙升。后来通过对BERT进行知识蒸馏，训练了一个参数量仅为原模型1/4但性能保留95%的小模型，同时结合请求聚合和动态批处理，最终将端到端延迟控制在了120ms以内，而线上点击率提升了8%。这个过程中，最大的体会是：没有最好的模型，只有最合适的工程化方案。大模型的能力令人兴奋，但让它能在生产环境的钢丝上稳定奔跑，需要的不仅是算法智慧，更是深刻的工程洞察。双塔模型远未到谢幕之时，它或许不再是舞台上唯一的主角，但无疑是支撑整场演出最坚实的地板。未来的推荐系统，必然是多种模型协同、分层决策的混合智能体，而理解每一块“积木”的特性和代价，是构建这个智能体的第一步。