摘要
2026年1月，埃隆·马斯克宣布将X平台（原Twitter）的For You推荐算法完全开源，这一举措在社交媒体行业引发了前所未有的关注。作为全球首个将核心推荐系统开源的主流社交平台，X的这一决定不仅展示了其技术自信，更为推荐系统领域的研究者和从业者提供了宝贵的学习素材。本文基于X官方GitHub开源代码、技术文档以及相关深度分析文章，从资深推荐系统专家的视角，对X推荐算法进行全面、系统的深度解析。文章涵盖系统架构设计、核心技术组件、评分排名机制、过滤筛选策略等多个维度，旨在帮助读者快速熟悉掌握X推荐算法的技术细节，并从中获取对推荐系统设计与优化的深刻洞察。
第一章 引言与背景
1.1 X平台推荐算法开源事件概述
2026年1月11日，一个注定要载入推荐系统发展史册的日子。埃隆·马斯克在社交平台上宣布，X平台将在七天内开源其全新推荐算法，并承诺每四周进行一次开源更新。这一消息瞬间引爆了全球科技圈的关注。在随后不到24小时内，X工程团队（@XEng）正式在GitHub上发布了名为"x-algorithm"的开源项目，采用与xAI旗下Grok模型相同的Transformer架构来驱动推荐系统。
根据GitHub仓库显示，该项目在发布后仅6小时内就斩获了1600颗Star，截至本文撰写时已获得超过15.7k颗Star和2.7次Fork，充分说明了业界对这一开源项目的极高关注度。项目采用Apache-2.0许可证开放，代码主要使用Rust（62.9%）和Python（37.1%）编写，涵盖了从数据处理、特征工程到模型推理的完整推荐系统链路。
这次开源的深远意义在于，它是迄今为止主流社交平台首次将核心推荐算法完完整整地暴露在阳光之下。在此之前，Facebook的News Feed、Instagram的推荐系统、YouTube的算法、字节跳动的推荐引擎，这些被业界认为是最先进的推荐系统，都如同黑箱一般运作，外界只能通过猜测和逆向工程来推断其工作原理。X的开源决定，犹如在推荐系统领域投下了一枚“深水炸弹”，让无数研究者和工程师得以第一次如此清晰地窥见一个顶级社交平台推荐系统的内部运作机制。
1.2 推荐系统发展历程与X算法的演进
推荐系统作为人工智能在互联网领域最成功应用之一，其发展历程可以追溯到上世纪九十年代。从最初的协同过滤算法，到后来的矩阵分解技术，再到深度学习时代的神经网络推荐，推荐系统的技术架构经历了数次重大革新。然而，无论技术如何演进，推荐系统的核心目标始终如一：在信息过载的环境中，帮助用户从海量内容中快速发现有价值、与自身兴趣相关的信息。
X平台作为全球最具影响力的社交媒体之一，其推荐系统的演进历程几乎就是推荐技术发展的缩影。早期，X（即当时的Twitter）采用相对简单的 chronology 时间线模式，按照发布时间倒序展示关注者发布的推文。随着用户规模爆炸式增长和信息过载问题日益严重，X开始引入基于规则和简单机器学习模型的推荐系统，试图在时间线中穿插用户可能感兴趣的“非关注”内容。
在这次开源版本之前，X的推荐系统据业界推测采用了复杂的手工特征工程和人工规则体系。运营团队可能设计了成百上千条规则来处理各种推荐场景：用户点赞过科技类内容就多推荐科技类推文，转发率高的内容获得加权曝光，某个话题热度上升时增加相关推文的推荐权重等等。这种基于人脑设计的逻辑规则体系虽然能够快速响应业务需求，但也带来了维护成本高、难以规模化、容易陷入局部最优等诸多问题。
而全新开源的X推荐算法代表了一次范式级别的转变。根据官方README文档的明确说明：“我们已经移除了所有手工设计的特征和大多数人工规则。”这一声明背后蕴含着深刻的技术哲学：与其依赖人工设计规则，不如让机器学习模型从用户的真实行为数据中自动发现推荐规律。一个基于Grok架构的Transformer模型，通过学习用户历史互动行为（点赞、回复、转发、在某条推文上的停留时长等）来决定推荐内容，整个过程几乎不需要人工干预。
1.3 开源的决定因素与行业影响
马斯克选择在此时开源X推荐算法，背后有着多重考量。首先是技术自信。X使用的推荐系统建立在xAI自研的Grok大语言模型基础之上，而Grok模型本身已经开源。在模型架构已经公开的情况下，基于模型构建的推荐系统藏着掖着意义不大。更重要的是，即使竞争对手获得了X的推荐算法代码，他们也无法复制出一个同等水平的推荐系统——因为没有X如此庞大的用户行为数据作为训练素材，数据才是推荐系统的核心壁垒。
其次是建立信任。近年来，社交平台推荐算法被广泛质疑，用户普遍感觉算法在“操控”他们的信息获取，但又无法证实这一猜测。X将代码开源，让任何人都可以验证算法是否存在暗箱操作，这本身就是一种建立用户信任的策略。正如X工程团队在项目描述中所说：“系统完全移除了手工设计的特征和启发式规则，由Grok-based transformer理解用户的参与历史并确定相关内容。”这种透明度本身就是对“算法偏见”指控的最好回应。
最后是吸引人才。在当今科技行业，人才竞争日益激烈，复杂工程的开源是展示团队技术实力的最佳方式。代码就是最好的简历，当全世界优秀工程师看到X团队能够构建如此复杂的推荐系统时，对X的技术认可度自然会提升。这对于正在大力招兵买马的xAI来说，无疑是一举多得的妙招。
从行业影响来看，X开源推荐算法将产生深远而持久的影响。对于学术研究者而言，这是第一次有机会深入了解工业级推荐系统的完整实现，很多之前只能从论文中推测的技术细节现在可以验证。对于业界的工程师而言，这是学习顶级推荐系统设计的绝佳机会，可以借鉴其架构设计思路来优化自己的系统。对于普通用户而言，了解推荐算法的工作原理有助于更理性地使用社交平台，避免被算法“牵着鼻子走”。
第二章 X推荐系统整体架构
2.1 系统架构概览
X推荐系统的整体架构可以用“简洁优雅”来形容。根据开源代码和官方文档的描述，整个For You推荐流程可以划分为几个关键阶段，每个阶段职责明确、接口清晰，共同构成了一个高效、可扩展的推荐pipeline。
当用户打开X应用并进入For You页面时，会向服务器发送一个推荐请求。这个请求首先到达Home Mixer——一个承担编排层角色的核心服务。Home Mixer如同乐队的指挥，负责协调整个推荐流程的有序进行：它需要获取用户的上下文信息（包括最近的参与历史、关注列表、用户特征等），调用不同的数据源获取候选推文，对候选进行丰富、过滤和评分，最终将排序后的结果返回给用户。
从数据流的角度来看，一个完整的For You推荐请求会经历以下步骤：首先，Query Hydration阶段会获取用户的行为序列和用户画像；然后，系统会从两个不同的候选源——Thunder和Phoenix——分别获取网络内（In-Network）和网络外（Out-of-Network）的推文候选；接着，Hydration阶段会为每个候选推文补充丰富的元数据（推文内容、作者信息、媒体信息等）；之后，Filtering阶段会移除不符合展示条件的推文；Scoring阶段会对剩余候选进行深度学习模型打分；最后，Selection阶段会按照分数排序并选择Top K条推文，在经过最终的Post-Selection Filtering之后返回给客户端。
这种架构设计体现了推荐系统设计的几个重要原则：模块化（每个阶段职责单一）、可扩展（可以方便地添加新的候选源或过滤规则）、可观测（每个阶段的输入输出都可以被监控和分析）。更重要的是，这种架构允许系统在不同阶段并行执行独立任务，从而最大化计算效率。
2.2 Home Mixer编排层详解
Home Mixer是X推荐系统的核心编排层，类似于推荐系统的大脑和中枢神经。它位于整个pipeline的中心位置，负责协调各个组件之间的协作，确保推荐请求能够高效、准确地完成。根据代码结构，Home Mixer的功能可以划分为以下几个关键阶段：
Query Hydrators是整个流程的起点，负责获取用户的上下文信息。这个阶段会收集用户最近参与（点赞、回复、转发等）的推文序列，用户关注的账户列表，以及其他用户偏好信息。这些信息将作为后续推荐的基础——模型需要了解用户过去喜欢什么，才能预测用户未来可能喜欢什么。在X的系统中，用户的行为序列被编码为一个高维向量，这个向量将直接参与后续的候选评分。
Sources阶段负责从不同数据源获取候选推文。X采用了著名的“双引擎”架构：一路是Thunder，负责从用户关注账户中获取最新推文；另一路是Phoenix，负责通过机器学习在全球范围内发现用户可能感兴趣的推文。这两路候选的来源和获取方式完全不同，但最终会被整合到同一个pipeline中进行统一处理。
Hydrators阶段负责为每个候选推文补充丰富的元数据。原始的推文ID本身信息量有限，系统需要“补水”——获取推文的完整内容（文本、媒体链接）、作者信息（用户名、认证状态、账户创建时间）、视频信息（时长、封面）等。这些补充信息对于后续的评分模型至关重要，因为模型需要根据这些特征来预测用户的参与概率。
Filters阶段负责移除不符合展示条件的推文。这个阶段会执行一系列预定义的过滤规则，比如移除用户已经看过的推文、移除来自被屏蔽账户的推文、移除包含用户静音关键词的推文等。过滤操作通常在评分之前进行，这样可以减少不必要的计算开销。
Scorers阶段是整个系统的核心，负责预测每个候选推文的参与概率。X使用Phoenix模型（基于Grok的Transformer）来生成预测，模型会输出该推文可能引发各种用户行为的概率（如点赞、回复、转发等）。这些概率随后会被加权组合，生成最终的相关性分数。
Selector阶段负责按照分数排序并选择Top K候选。由于候选数量可能非常庞大（从全球数十亿推文中筛选），系统需要高效地完成排序和选择操作。这个阶段通常会使用堆排序或类似的高效算法。
Post-Selection Filters阶段负责对最终选择的候选进行最终验证。比如在最终展示前再次检查推文是否违规（可能在这个窗口期被举报），确保返回给用户的内容一定是安全合规的。
Side Effects阶段负责执行一些异步的副作用操作，比如缓存本次请求的信息供将来使用、记录日志用于后续分析等。
Home Mixer通过gRPC接口对外提供服务，名为ScoredPostsService，返回排序后的推文列表。这种服务化设计使得推荐系统可以轻松扩展以应对海量请求。
2.3 候选内容双引擎架构：Thunder与Phoenix
X推荐系统最核心的设计特色在于其“双引擎”候选获取架构。系统从两个完全不同的来源检索候选推文：Thunder负责处理网络内（In-Network）内容，即用户关注账户发布的推文；Phoenix负责处理网络外（Out-of-Network）内容，即通过机器学习从全球语料库中发现的推文。这种设计确保了推荐结果既包含用户“主动选择”关注的内容，又包含算法“智能发现”可能感兴趣的内容。
Thunder：关注圈内容的实时引擎
Thunder是X推荐系统中负责处理网络内内容的组件，其名称寓意“雷霆万钧”的速度——它需要在毫秒级别甚至亚毫秒级别内返回用户关注账户的最新推文。根据官方文档的描述，Thunder是一个内存中的推文存储和实时摄取管道，追踪所有用户的最近推文。
Thunder的技术实现体现了对实时性的极致追求。它从Kafka消息队列消费推文的创建和删除事件，将这些事件实时写入内存存储。对于每个用户，Thunder维护着一个推文存储，包含该用户关注账户的原创推文、回复/转发以及视频推文。当用户请求For You推荐时，Thunder可以快速返回其关注账户最近发布的推文候选。
这种内存存储的设计使得Thunder能够提供极快的查询速度。在传统的推荐系统中，数据通常存储在分布式数据库中，每次查询都需要走网络通信，延迟较高。而Thunder将热点数据全部加载到内存中，查询直接在内存中进行，避免了磁盘IO和网络开销，从而实现了亚毫秒级的响应时间。
然而，内存存储也带来了容量限制的问题。系统无法在内存中保留无限多的推文，因此Thunder会自动清理超过保留期的推文。通常来说，推文的生命周期比较短，大多数用户只关心最近几天甚至几个小时内的内容，这使得内存存储策略是合理的。
Thunder的核心价值在于它确保了用户能够及时看到自己关注账户的最新动态。即使算法再先进，如果用户关注的重要账户发布了重要信息却无法及时看到，这将严重影响用户体验。因此，Thunder在X推荐系统中扮演着“保底”的角色——它确保了用户关注的内容不会因为算法选择而“丢失”。
Phoenix：全球发现引擎
如果说Thunder是“守门员”，确保用户能看到关注内容；那么Phoenix就是“探险家”，在全球范围内寻找用户可能感兴趣但尚未发现的内容。Phoenix是X推荐系统中负责网络外内容发现的机器学习组件，其名称寓意“凤凰涅槃”——从海量信息中涅槃重生，发现有价值的內容。
Phoenix的核心功能可以分为两个阶段：检索（Retrieval）和排名（Ranking）。
在检索阶段，Phoenix采用经典的两塔（Two-Tower）模型架构。这种架构得名于其神经网络结构——一个“用户塔”（User Tower）用于编码用户特征，另一个“候选塔”（Candidate Tower）用于编码推文特征。两个塔分别将用户和推文映射到同一个高维向量空间，然后通过向量相似度检索来找出与用户最匹配的推文。
用户塔的输入包括用户的画像特征（兴趣标签、账户属性等）和用户的历史参与行为序列。模型会将这些信息编码为一个用户向量，表示用户的兴趣偏好。候选塔的输入是推文的各种特征（文本内容、作者信息、发布时间等），输出一个推文向量。
在推理时，系统首先计算用户向量，然后在一个预先构建好的推文向量库中进行相似度搜索。由于推文数量可能达到数十亿级别，传统的精确向量检索效率太低，X采用了基于近似最近邻（ANN）的高效检索算法，通过点积相似度快速找出Top K个最匹配的推文候选。
在排名阶段，Phoenix使用一个带有候选隔离机制的Transformer模型来预测每个候选推文的参与概率。这个模型与普通Transformer的区别在于：它在推理时会使用特殊的attention mask，确保候选推文之间不能互相“看到”彼此，只能关注用户上下文。这解决了推荐系统中一个经典问题：同时评估多个候选时，候选之间不应该互相影响分数。
Phoenix的检索和排名模型都基于Grok架构——xAI自研的大语言模型。这使得X的推荐系统能够利用大语言模型在自然语言理解和生成方面的强大能力，深度理解推文内容和用户意图。
Thunder和Phoenix两路候选最终会在Home Mixer中汇合，经过统一的评分和排序后，展示给用户。根据一些分析，X的推荐中大约50%的内容来自非关注账户，这说明Phoenix在全球发现方面发挥着重要作用。
2.4 管道处理流程详解
X推荐系统的管道处理流程是一个精心设计的流水线，每个阶段承担特定的功能，阶段之间通过标准化的接口连接。这种设计使得系统易于维护、扩展和调试。
第一步：Query Hydration（查询补水）
这是整个pipeline的起点。系统需要获取当前请求用户的上下文信息，包括：用户最近参与的推文序列（最近点赞、回复、转发的推文）、用户关注的账户列表、用户的基本画像特征（如兴趣标签、语言偏好等）。这些信息将作为后续候选检索和评分的基础。
第二步：Candidate Sourcing（候选获取）
系统从两个来源并行获取候选推文：一路是从Thunder获取用户关注账户的最近推文（网络内）；另一路是从Phoenix的检索模型获取通过向量相似度发现的推文（网络外）。两路候选的数量可能不同，系统通常会为每路设置配额，确保最终推荐中既有用户关注的内容，也有新发现的内容。
第三步：Candidate Hydration（候选补水）
获取候选推文ID之后，系统需要为每个ID补充丰富的元数据。这个阶段会并行获取多种信息：推文的核心数据（文本内容、媒体链接、发布时间等）、作者信息（用户名、头像、认证状态、账户年龄等）、视频信息（时长、是否包含视频等）、用户与作者的社交关系（是否关注、是否已互动过等）。这些信息将作为评分模型的输入特征。
第四步：Pre-Scoring Filters（预评分过滤）
在正式评分之前，系统会先过滤掉一批明显不符合展示条件的候选。这个阶段会执行以下过滤操作：
- DropDuplicatesFilter：移除重复的推文ID（同一推文可能同时从Thunder和Phoenix获取）
- CoreDataHydrationFilter：移除无法获取核心元数据的推文（数据不完整）
- AgeFilter：移除超过时间阈值的旧推文（通常为7天左右）
- SelfpostFilter：移除用户自己发布的推文（用户不需要在自己的推荐中看到自己发的东西）
- RepostDeduplicationFilter：对相同内容的转发进行去重
- IneligibleSubscriptionFilter：移除用户无法访问的付费内容
- PreviouslySeenPostsFilter：移除用户已经看过的推文
- PreviouslyServedPostsFilter：移除本次会话中已经服务过的推文
- MutedKeywordFilter：移除包含用户静音关键词的推文
- AuthorSocialgraphFilter：移除来自用户屏蔽或静音账户的推文
第五步：Scoring（评分）
这是整个pipeline最核心的阶段。评分系统包含多个 scorer 组件：
- Phoenix Scorer：调用机器学习模型获取每个候选的参与概率预测
- Weighted Scorer：将多个参与概率加权组合为最终的相关性分数
- Author Diversity Scorer：衰减同一作者的得分以确保多样性
- OON Scorer：调整网络外（非关注）内容的分数
每个候选会获得一个最终得分，这个分数将决定其在最终列表中的排名。
第六步：Selection（选择）
系统按照分数从高到低排序，选择Top K个候选。K的值可以根据客户端请求或系统配置动态调整，通常在几十到几百之间。
第七步：Post-Selection Processing（后选择处理）
在最终返回结果之前，系统会对已选择的候选进行最终验证和处理。这个阶段包括：
- VFFilter（Visible Filter）：移除已删除、垃圾信息、暴力血腥内容等违规推文
- DedupConversationFilter：对同一对话线程的多个分支进行去重
- 可见性检查：确保推文在最终展示时仍然符合展示条件
经过这一系列处理后，排序后的推文列表最终返回给客户端。
第三章 核心技术组件深度解析
3.1 Thunder内存数据库系统
Thunder是X推荐系统中负责实时内容存储和检索的关键组件。它的设计目标非常明确：在极低的延迟下，为用户提供其关注账户的最新推文。为了实现这一目标，Thunder采用了全内存存储的架构设计，这在业界是一种相对激进的方案，但也正是这种设计使得Thunder能够提供亚毫秒级的查询性能。
从技术实现角度来看，Thunder的核心工作机制可以分为三个层面：数据摄取、数据存储和数据查询。
在数据摄取层面，Thunder作为一个流消费者，持续从Kafka消息队列中获取推文事件。每当有用户发布新推文、删除推文或修改推文时，相应的消息会被发送到Kafka，Thunder消费这些消息并更新其内存存储。这种基于事件驱动的架构确保了数据的新鲜度——新推文可以在发布后几毫秒内就进入推荐候选池。
在数据存储层面，Thunder为每个用户维护独立的推文存储。这个存储包含该用户关注账户的原创推文、回复推文、转发推文以及视频推文。存储结构经过精心设计，支持快速的范围查询和时间序遍历。由于推文具有很强的时间敏感性，通常用户只关心最近发布的内容，因此Thunder会定期清理超过保留期的推文，释放内存空间。
在数据查询层面，Thunder提供了一套简洁而高效的查询接口。当Home Mixer请求某个用户的网络内候选时，Thunder可以快速返回该用户关注账户最近发布的推文列表。由于所有数据都在内存中，查询操作不需要任何磁盘IO或外部数据库访问，这使得查询延迟极低。
Thunder的设计哲学体现了几个重要的工程考量。首先是延迟优先：对于用户刚刚刷新页面就希望看到新内容的场景，任何超过几百毫秒的延迟都是不可接受的。内存存储是实现极低延迟的最直接方案。其次是数据新鲜度：通过流式摄取方式，Thunder可以保持数据的实时更新，用户关注账户发布的内容几乎可以立即进入推荐系统。第三是简化架构：与传统的多级缓存架构相比，Thunder不需要复杂的缓存失效机制，数据在内存中始终是最新的。
然而，全内存存储也带来了挑战。最明显的是容量限制——服务器内存是有限的，无法存储无限多的推文。X的解决方案是设置合理的保留期策略，只存储最近几天的推文，超时推文自动淘汰。这对于推荐场景来说是合理的，因为大多数用户确实只关心最近的内容。
Thunder在X推荐系统中扮演着“基础设施”的角色。它不负责复杂的算法决策，只专注于高效地返回用户关注账户的最新推文。这种职责分离的设计使得系统更易于理解和维护——当推荐效果出现问题时，工程师可以清晰地定位问题是在Thunder（数据问题）还是在Phoenix（算法问题）。
3.2 Phoenix检索与排名系统
Phoenix是X推荐系统中最为复杂的组件，它承担着双重职责：一是从全球海量推文中检索出用户可能感兴趣的内容，二是对这些候选进行深度学习评分，预测用户的参与概率。Phoenix的名称取自希腊神话中的凤凰，寓意着从海量信息中涅槃重生、发现精品的能力。
Phoenix的第一个核心功能是检索（Retrieval） 。在X平台上，每天有数亿条新推文产生，用户不可能浏览所有推文，推荐系统需要帮助用户筛选出最相关的内容。Phoenix的检索采用经典的两塔（Two-Tower）模型架构，这是一种在工业推荐系统中广泛使用的向量化检索方案。
两塔模型的名称来源于其网络结构：两个独立的神经网络塔——用户塔（User Tower）和候选塔（Candidate Tower）——分别将用户和推文编码为高维向量。用户塔的输入是用户的各种特征，包括用户画像（兴趣标签、账户年龄、活跃度等）和用户的历史参与行为序列。模型会处理这些输入，输出一个固定维度的用户向量。候选塔的输入是推文的特征，包括文本embedding、作者信息、发布时间、媒体类型等，输出一个推文向量。
在训练阶段，两塔模型通过对比学习的方式进行优化：让正样本（用户真实参与的推文）的向量相似度尽可能高，让负样本（用户未参与的推文）的向量相似度尽可能低。这种训练方式使得模型学会将用户和与其相关的推文映射到向量空间中相近的位置。
在推理阶段，系统首先计算当前用户的向量，然后在预先构建好的推文向量库中进行相似度搜索。由于推文数量可能达到数十亿级别，精确的全量向量比较效率太低，X采用了基于近似最近邻（ANN）算法的高效检索方案。系统通过点积相似度计算，快速找出与用户向量最接近的Top K个推文候选。
Phoenix的第二个核心功能是排名（Ranking） 。检索阶段返回的候选数量可能仍然很大（从几百到几千不等），而且检索模型的精度有限——它只能大致筛选出用户可能感兴趣的内容，但无法精确预测用户对每条具体推文的参与概率。排名阶段的任务就是对这些候选进行更精细的评估。
排名模型同样基于Grok架构的Transformer，但做了专门的适配。最关键的设计是候选隔离机制（Candidate Isolation） 。在传统的Transformer推荐模型中，所有候选会在同一个批次中进行推理，候选之间可以通过attention机制互相“看到”彼此。这会带来一个问题：候选A的分数可能受到候选B的影响，如果B是特别吸引人的内容，A的分数可能会被衬托得较低。这种依赖关系使得分数不稳定，难以缓存。
X采用了特殊的attention mask来解决这个问题。在推理时，每个候选推文只能“看到”用户上下文（用户的历史行为、用户画像等），不能看到其他候选推文。这就像让每个候选单独接受评估一样——候选之间互不干扰，各自根据与用户的匹配程度获得独立的分数。这种设计有两个重要优势：一是分数更加稳定和一致；二是分数可以缓存起来重复使用，因为不受其他候选的影响。
排名模型的输出不是单一的分数，而是15种用户行为的预测概率。这些行为包括正向行为（点赞、回复、转发、点击、视频观看、停留等）和负向行为（点不感兴趣、屏蔽作者、静音作者、举报等）。每个行为都有一个独立的输出头，预测用户采取该行为的概率。
Phoenix的检索和排名功能共同构成了X推荐系统的“智能发现”能力。通过两塔检索，X可以在数十亿推文中快速找到与用户兴趣匹配的内容；通过Transformer排名，X可以精细预测用户对每条推文的参与概率。这种两阶段设计在推荐系统中非常经典——召回阶段追求覆盖率，确保不遗漏相关内容；精排阶段追求精度，确保推荐的内容真正符合用户兴趣。
3.3 两塔模型原理与实现
两塔模型（Two-Tower Model）是现代推荐系统中最成功的深度学习架构之一，尤其在大规模检索场景中应用广泛。X的Phoenix系统采用了这一架构来进行网络外内容的检索，其设计既体现了经典两塔模型的精髓，又针对X的具体场景做了优化。
两塔模型的核心思想是将用户和候选内容映射到同一个向量空间，使得相似的用户和相关内容在向量空间中距离较近。这样，推荐问题就转化为向量空间中最近的邻搜索问题——给定一个用户向量，找出与之最接近的内容向量。
用户塔（User Tower）的设计与输入
用户塔的任务是将用户的多维度信息编码为一个向量。这个向量应该捕捉用户的关键特征，使得与用户向量相似的内容向量对应的推文就是用户可能感兴趣的推文。
用户塔的输入可以分为几大类。第一类是用户画像特征，包括用户的兴趣标签（如科技、体育、娱乐等类别偏好）、用户的账户属性（账户年龄、认证状态、活跃度等）、用户的语言偏好和地区设置等。这些特征相对稳定，定义了用户的基本画像。
第二类是用户的行为序列，这是用户塔最重要的输入。用户过去的行为是预测未来兴趣的最强信号。用户塔会接收用户最近参与的推文序列——包括点赞的推文、回复的推文、转发的推文、在上面停留时间较长的推文等。每个行为不仅记录了推文ID，还可能记录了行为类型和参与深度（如停留时长）。
在X的实现中，用户塔使用Transformer架构来处理行为序列。Transformer的自注意力机制能够捕捉行为之间的复杂关系，比如用户点赞了两条关于科技的推文，系统会学习到用户对科技领域感兴趣。行为序列的encoding会与用户画像特征的encoding进行融合，最终生成用户向量。
候选塔（Candidate Tower）的设计与输入
候选塔的任务是将推文编码为向量。与用户塔不同，候选塔只需要处理单条推文，不需要考虑序列关系。
候选塔的输入包括推文的多种特征。文本特征是最重要的输入——推文的文字内容经过embedding处理后送入神经网络。X可能使用了预训练的language model来生成文本embedding，这使得模型能够理解推文的语义内容。除了文本，候选塔还会接收推文的元数据，包括作者信息（作者的关注者数、认证状态、历史推文表现等）、推文的发布时间（用于考虑时效性）、推文类型（是否包含视频、图片、链接等）、推文的互动历史（已有多少点赞、回复、转发等）。
候选塔通常也采用Transformer架构来编码文本特征，但结构相对简单——不需要处理长序列，只需要编码单条推文的文本。
检索过程与向量索引
训练完成后的两塔模型可以用于线上推理。推理时，系统首先计算当前用户的向量（用户塔的前向传播），然后在一个预先构建好的向量索引中进行搜索。
向量索引的构建是离线完成的。系统会定期将最新的推文通过候选塔编码为向量，然后将向量存入高效的向量索引结构（如FAISS、HNSW等）。在线检索时，用户向量作为查询向量，系统在索引中找出与之点积相似度最高的Top K个向量，对应的推文就是检索结果。
这种设计的一个重要优势是计算效率。用户塔只需要在线执行一次（为当前用户计算向量），候选塔的推理可以完全离线完成（预先编码所有推文）。在线部分只涉及用户向量计算和向量索引检索，计算量相对较小，可以支持高并发的推荐请求。
两塔模型的优势与局限
两塔模型在X的推荐系统中表现出色，具有多个优势。首先是计算效率高——检索阶段的计算可以离线完成，在线只需要做向量检索，容易扩展到数十亿规模的候选。其次是泛化能力强——基于语义embedding的检索不依赖于精确的关键词匹配，能够发现语义相似但表述不同的相关内容。第三是支持多模态——候选塔可以轻松纳入图像、视频等多模态特征的embedding。
当然，两塔模型也有其局限性。向量检索的精度有限——它只能保证大致筛选出相关候选，无法精确排序。为此，X采用了两阶段架构——先用两塔模型召回候选，再用更精细的Transformer模型进行精排。
3.4 Transformer在推荐系统中的创新应用
Transformer架构最初是为自然语言处理任务设计的，在机器翻译、文本生成等领域取得了巨大成功。近年来，研究者开始探索将Transformer应用于推荐系统，X的Phoenix排名模型就是这一趋势的典型代表。X的创新之处在于，它不仅将Transformer用于处理用户行为序列，还专门设计了候选隔离机制来解决推荐场景中的独特问题。
Transformer处理用户行为序列
推荐系统中的一个核心挑战是如何有效建模用户的历史行为。用户过去的互动行为——点赞、回复、转发、在某些内容上的停留——是预测用户未来兴趣的最重要信号。传统的推荐模型通常使用简单的embedding聚合（如平均池化）来处理行为序列，这种方式无法捕捉行为之间的复杂关系。
Transformer的自注意力机制（Self-Attention）能够解决这一问题。在Transformer中，每个行为token都可以attend到序列中的其他行为token，自动学习哪些行为对预测当前兴趣更重要。例如，如果用户最近连续点赞了几条关于人工智能的推文，Transformer可以学习到这种模式，赋予这些行为更高的权重，从而推断出用户对AI领域感兴趣。
X的Phoenix模型使用Transformer来处理用户的行为序列。用户最近参与的推文（连同行为类型信息）被编码为一个序列，送入Transformer网络。Transformer的输出是一个融合了所有行为上下文信息的用户表示向量，这个向量将被用于后续的候选评分。
候选隔离机制：解决推荐中的批次偏差问题
X在Transformer应用中最具创新性的设计是候选隔离机制（Candidate Isolation）。要理解这个机制的意义，需要首先了解推荐系统中一个经典问题：批次偏差（Batch Bias）。
在传统的推荐模型推理中，为了提高效率，系统通常会批量处理多个候选推文。这些候选被组织成一个批次，一起送入神经网络进行打分。在这种设置下，候选之间可以通过注意力机制互相“看到”彼此。问题在于，这种互相可见会导致分数不稳定——同一个候选，在不同批次中可能获得不同的分数，因为它旁边的“邻居”不同。
例如，假设候选A是一个中等质量的推文。当它与一些高质量推文放在一起时，可能得分较低；但当它与一些低质量推文放在一起时，可能得分较高。这种分数波动不仅影响推荐效果，还使得分数难以缓存和复用——同一个推文在不同时间查询可能得到不同的分数。
X的解决方案是在Transformer推理时使用特殊的attention mask。这个mask的设计非常巧妙：每个候选可以attend到用户上下文（这是必要的，因为评分需要考虑用户兴趣），但不能attend到同一批次中的其他候选。换句话说，每个候选只能“看到”用户，看不到其他候选。
这种设计的效果是：每个候选的评分是独立的、稳定的不管批次中还有其他什么候选，候选的分数只取决于它与用户的匹配程度。这解决了批次偏差问题，使得分数更加一致和可缓存。
从工程角度来看，候选隔离机制还带来了另一个好处：分数的可解释性。当某个推文获得高分时，工程师可以清晰地知道这是因为它与用户兴趣匹配，而不是因为它“傍大款”——与高质量候选混在一起获得的虚假提升。
多行为预测输出
X的Transformer模型还有一个显著特点：它不是预测单一的“相关性”分数，而是同时预测15种用户行为的概率。这些行为包括：
正向行为：
- P(favorite)：收藏
- P(reply)：回复
- P(repost)：转发
- P(quote)：引用
- P(click)：点击
- P(profile_click)：点击作者主页
- P(video_view)：视频观看
- P(photo_expand)：展开图片
- P(share)：分享
- P(dwell)：停留
- P(follow_author)：关注作者
负向行为：
- P(not_interested)：不感兴趣
- P(block_author)：屏蔽作者
- P(mute_author)：静音作者
- P(report)：举报
这种多行为预测的设计比单一点击率预测更加精细。单一预测只关心用户是否点击，而多行为预测可以捕捉用户参与的各种形式。更重要的是，负向行为的预测使得系统能够主动避免推荐用户可能反感的内容——即使某条推文点击率很高，但如果预测到大量用户会点击“不感兴趣”或“举报”，系统会降低其推荐权重。
第四章 评分与排名机制
4.1 多行为预测模型详解
X推荐系统的评分核心是Phoenix模型的多行为预测能力。与传统推荐系统只预测单一点击率不同，X的模型同时预测15种不同的用户行为概率。这种设计更加精细地建模了用户与内容的交互模式，使得推荐结果不仅考虑用户是否“会点”，还考虑用户是否“会喜欢”。
从模型结构来看，Phoenix的排名模型接收两类输入：用户上下文和候选推文。用户上下文包括用户的历史行为序列、用户画像、用户与作者的关系等。候选推文包括推文的文本内容、作者信息、发布时间、媒体信息等。这些输入被送入基于Grok的Transformer网络，输出15个行为概率。
每个输出头对应一种用户行为。模型使用sigmoid激活函数，输出值在0到1之间，表示用户采取该行为的预测概率。例如，P(like)=0.8表示模型预测用户有80%的概率会点赞这条推文。
多行为预测的设计背后有着深刻的用户行为学洞察。在传统的点击率模型中，“点击”被视为最主要的目标。但点击行为本身是有欺骗性的——用户可能因为标题党而点击，但点击后发现内容不怎么样，并没有真正“喜欢”这个内容。X的多行为预测模型可以区分这种差异：如果一条推文点击率很高，但P(dwell)（停留）很低，说明用户点开后很快离开，并不是真正喜欢；如果P(not_interested)、P(block_author)等负向概率很高，即使点击率不错，也说明内容让用户反感。
这种设计还带来了另一个好处：更丰富的训练信号。传统的点击率模型只有“是否点击”这一个标签，而X的模型可以从15种行为中学习。每种行为都提供了额外的监督信息，使得模型能够更全面地理解什么样的内容是“好的”。
正向行为预测详解
在X模型预测的11种正向行为中，每种行为都反映了用户对内容的不同程度的认可。
P(favorite)和P(like)代表最基本的认可——用户觉得这条推文值得保存或点赞。这是推荐系统最常优化的目标。
P(reply)和P(repost)代表更高层次的参与。用户不仅看了内容，还产生了回复或转发的行为，这意味着内容激发了用户表达或传播的欲望。在社交网络语境下，回复和转发是内容传播的关键节点——它们不仅是用户认可的标志，还能触发二次传播，带来更多曝光。
P(quote)是一种特殊的转发形式，用户在转发时还会添加自己的评论。这种行为的门槛比普通转发更高，需要用户有表达欲，通常意味着内容的讨论价值很高。
P(click)和P(profile_click)代表用户对内容背后的作者感兴趣。前者是点击推文本身，后者是点击推文后进一步点击作者头像查看主页。这种行为意味着推荐不仅内容相关，还帮助用户发现了可能感兴趣的新账号。
P(video_view)和P(photo_expand)是针对多媒体内容的专门预测。如果推文包含视频或图片，系统需要预测用户是否会点开观看。这些多媒体内容通常是用户停留时间的重要来源。
P(dwell)是一个独特的行为指标，它衡量用户在推文上的停留时间。在推荐系统中，停留时间是一个比点击更有说服力的信号——用户可能因为各种原因点击某条推文（比如误触），但如果用户愿意在推文上停留，说明内容确实吸引了用户。X明确将P(dwell)作为独立的预测项，体现了其对用户真实参与度的关注。
P(follow_author)是预测用户是否会关注内容作者。这代表了推荐系统不仅推荐了内容，还帮助用户扩展了社交图谱。如果系统频繁推荐某账号的内容，而用户也经常关注这些账号，说明推荐在帮助用户发现有价值的新声音。
负向行为预测详解
X模型预测的4种负向行为是其推荐系统的特色之一。这些负向行为让系统能够主动识别和避免用户可能反感的内容。
P(not_interested)是用户对内容不感兴趣的最直接表达。当用户点击这个按钮时，意味着之前的推荐失败了——系统推荐了用户不想要的内容。这个信号对于模型学习什么内容“不该推荐”非常有价值。
P(block_author)和P(mute_author)代表用户对内容创作者的负面态度。屏蔽作者意味着用户完全不想再看到这个账号的内容；静音作者意味着用户不想看到这个账号的推文出现在时间线中，但不一定是永久的。这两个信号帮助系统识别哪些账号的内容应该减少推荐。
P(report)是用户主动举报内容违规。虽然大多数用户不会主动举报，但这个信号对于识别违规内容、低质量内容非常重要。如果某条推文被大量举报，系统应该降低其推荐权重，甚至从候选池中移除。
负向行为预测的一个关键设计是它们的权重是负数。在最终的加权评分中，正向行为会加分，负向行为会减分。这意味着，如果模型预测某条推文有较高的不感兴趣、屏蔽或举报概率，即使它的点击率预测很高，最终得分也会被拉低。这种设计体现了X推荐系统的一个重要理念：避免让用户反感比追求高点击率更重要。
4.2 加权评分系统
X的最终推荐得分是通过加权评分系统计算的。这个系统将模型预测的15种行为概率组合成一个最终的相关性分数，决定推文在推荐列表中的排名。
加权评分的基本公式是：
Final Score = Σ (weight_i × P(action_i))
其中，weight_i是第i种行为的权重，P(action_i)是模型预测的该行为概率。
权重的设计反映了推荐系统的价值取向。正向行为的权重是正数，表示这些行为对推荐有正面贡献；负向行为的权重是负数，表示这些行为对推荐有负面贡献。
具体的权重数值并未在开源代码中完全公开，但根据相关分析，可以推测权重设计遵循以下原则：
首先，不同行为的权重差异很大。互动深度越深的行为，权重通常越高。例如，点赞的权重可能相对较低，因为它的门槛最低；而回复作者并获得回应的权重可能极高，因为这是深度互动的标志。根据一些分析，“回复+作者回应”的权重可能是单纯点赞的75倍。这种设计鼓励创作者积极回复评论——当创作者回复某条评论后，该推文更可能被推荐给更多人。
其次，时效性内容可能有额外的加权。新发布的推文通常比旧推文有更高的时效性权重，因为用户更关心“现在发生了什么”。这种机制确保推荐内容不会过度陈旧。
第三，作者多样性会被考虑。如果同一个作者的推文在短时间内占据过多推荐位置，系统会对其后续推文进行降权。这是为了避免信息茧房——如果用户只看某个大V的内容，眼界会越来越窄。
第四，网络外内容可能有单独的调整。网络外（Out-of-Network）内容——即用户未关注账户发布的推文——可能有一个基础权重调整。这个调整确保推荐中既有用户关注的内容，也有新发现的内容。根据分析，X的推荐中大约50%来自非关注账户。
加权评分系统的一个关键优势是其灵活性。通过调整不同行为的权重，推荐系统可以快速响应业务需求变化。例如，如果运营团队希望提高视频内容的曝光，可以提高P(video_view)的权重；如果希望减少争议内容的传播，可以提高负向行为的权重。
这种基于学习的评分（模型预测概率）加上基于规则的权重调整的混合方法，在工业推荐系统中非常常见。它既利用了机器学习模型的预测能力，又保留了人工干预的空间来处理业务考量。
4.3 候选隔离机制深度分析
候选隔离机制（Candidate Isolation）是X推荐系统中最具技术创新性的设计之一。这个机制解决了推荐系统中一个长期存在的难题：如何在批量推理中保证每个候选评分的独立性和一致性。
要理解候选隔离的意义，需要首先理解传统推荐模型在批量推理时遇到的问题。在实际部署中，为了提高吞吐量，降低推理成本，推荐模型通常不会逐个处理候选，而是一次性处理一批候选（batch）。在这个批次内部，候选之间可以通过注意力机制互相交互。
这种设计的初衷是好的——它允许模型在评估某个候选时参考其他候选的信息。例如，在视频推荐中，模型可能想知道“用户已经在这个batch中看到了几个视频A类内容，再推荐一个视频A类内容是否合适”。这种跨候选的信息共享可以帮助模型做出更智能的决策。
然而，这种设计也带来了严重的副作用：批次偏差（Batch Bias）。由于候选之间存在交互，同一个候选在不同的批次中可能获得不同的分数。举例来说，假设候选A的质量中等，候选B的质量很高。如果A和B在同一个批次中，A的分数可能会被B衬托得偏低（因为模型发现B更好）；如果A和C（质量很低）在同一个批次中，A的分数可能会被衬托得偏高（因为矮子里拔将军）。
这种分数不稳定性会带来多个问题。首先是推荐结果不稳定——同一个用户刷新两次相同的推荐请求，可能得到完全不同的推荐列表。其次是难以缓存——缓存的分数下次可能不再准确。第三是难以调试——工程师很难判断某个候选的真实质量，因为分数受太多外部因素影响。
X的候选隔离机制完美解决了这个问题。其核心实现是在Transformer推理时使用特殊的attention mask。这个mask的设计非常精妙：每个候选可以attend到用户上下文（User Context），这是评分所必需的；但不能attend到同一批次中的其他候选。
这种设计的工程实现可以这样理解：在标准的Transformer中，每个token的attention计算包括所有其他token。但在X的候选隔离设置中，当计算候选token的attention时，只有用户上下文token被纳入计算，其他候选token被mask掉。这确保了每个候选的评分完全基于其与用户的匹配程度，不受批次中其他候选的影响。
候选隔离机制带来了几个重要的实际优势。第一是分数稳定性：同一个候选在任意批次中获得相同的分数，使得分数变得可缓存、可信赖。第二是可解释性：当某个候选获得高分时，工程师可以确信这是因为它与用户匹配，而不是因为它“傍大款”。第三是工程简化：不需要担心候选批次的选择对结果产生影响。
从更深层次来看，候选隔离机制体现了X推荐系统的设计哲学：追求的是“每个候选的独立价值”，而不是“候选之间的相对比较”。这种设计使得推荐更加公平——每条推文都凭借自身的质量参与竞争，而不是依赖于竞争对手的质量。
4.4 多样性评分与作者多样性
推荐系统面临的一个经典挑战是如何在相关性和多样性之间取得平衡。如果系统只推荐用户最感兴趣的内容，短期内用户可能满意度很高，但长期来看会导致“信息茧房”——用户的视野越来越窄，只看到自己已经喜欢的内容。这种模式虽然在短期内提高了点击率，但损害了平台的长期健康。
X的推荐系统通过多个机制来解决多样性问题，其中最重要的两个是作者多样性（Author Diversity） scorer 和网络外内容（Out-of-Network） scorer。
Author Diversity Scorer：避免同一作者刷屏
Author Diversity Scorer的设计目的是确保推荐列表中不会过度集中于少数几个作者。如果一个用户在短时间内已经看到了某个大V的多条推文，系统会降低该作者后续推文的得分，避免“刷屏”现象。
这个机制的工作原理可以这样理解：当候选推文来自某个作者时，scorer会检查该作者在最近推荐中已经出现的次数或频率。如果出现频率超过阈值，系统会对该候选的得分进行衰减——出现次数越多，衰减越严重。
这种设计有几个重要效果。首先，它防止少数头部账号垄断推荐流量。即使某个账号有大量高质量推文，也不能一次性全部推荐给用户，而是需要分散在不同时间。其次，它为长尾内容创作者提供了更多曝光机会。当大V的内容被降权后，中小账号的内容就有了更多的展示空间。第三，它提升了用户体验——如果推荐列表被同一个人刷屏，用户会感到审美疲劳。
当然，Author Diversity Scorer也需要谨慎调参。如果过度强调多样性，可能会降低推荐的相关性——用户可能更想看到某个大V的推文，但系统为了多样性而故意不推荐。X的设计似乎在相关性和多样性之间找到了平衡点。
OON Scorer：调整网络外内容分数
OON（Out-of-Network）Scorer负责调整非关注账户内容的推荐权重。Recall，X的推荐候选来自两个来源：Thunder（关注账户的推文）和Phoenix（发现的新内容）。OON Scorer的任务是确保这两类内容在最终推荐中有合理的比例。
根据相关分析，X的推荐中大约50%来自非关注账户。这个比例反映了系统的设计理念：一方面，用户需要看到自己关注账户的内容，这是社交平台的基础价值；另一方面，用户也需要发现新的内容和账号，这是平台保持活力的来源。
OON Scorer通过调整网络外候选的分数来实现这个目标。如果非关注内容在当前推荐中的占比低于目标比例，系统会提高OON候选的分数；反之则降低。这种动态调整确保了推荐的多样性。
多样性机制的整体效果
通过Author Diversity Scorer和OON Scorer的协同工作，X的推荐系统能够在保持高相关性的同时提供足够的多样性。用户既能看到自己关注的内容，也能发现新的兴趣点；既能看到头部大V的观点，也能听到长尾创作者的声音。这种设计有助于打破信息茧房，让用户接触到更加多元化的信息。
第五章 过滤与筛选机制
5.1 预过滤规则详解
在推荐系统的pipeline中，过滤（Filtering）是一个至关重要的环节。它位于评分（Scoring）之前，负责在昂贵的机器学习推理之前就移除明显不符合条件的候选，从而节省计算资源，提高系统效率。X的推荐系统设计了多层次的预过滤规则，这些规则覆盖了内容质量、用户偏好、合规性等多个维度。
DropDuplicatesFilter：重复推文过滤
同一个推文可能同时从Thunder和Phoenix两路候选中出现——例如，用户关注的某个账户发布了推文，这推文既会被Thunder检索到，也可能因为质量高而被Phoenix检索到。DropDuplicatesFilter的任务就是识别并移除这些重复的推文ID，确保每个推文在推荐中只出现一次。
这个过滤操作非常简单高效——只需要维护一个已见推文ID的集合，在遍历候选时检查是否已存在。但它对推荐体验的影响很大：如果不进行去重，用户可能在同一次推荐刷新中看到同一条推文两次，这是不可接受的。
CoreDataHydrationFilter：核心数据补水检查
这个过滤器确保候选推文能够成功获取完整的基本数据。如果推文的核心元数据（文本内容、发布时间、作者ID等）无法获取，说明数据存在问题，应该被过滤掉。
这个过滤器的作用是保证后续评分阶段的数据完整性。评分模型需要推文的文本内容、作者信息等作为输入，如果这些数据缺失，评分无法进行。
AgeFilter：推文时效性过滤
用户通常对近期发布的推文更感兴趣，过时的推文即使质量很高，其推荐价值也会大幅下降。AgeFilter负责移除超过特定时间阈值的推文。
具体的阈值并没有在代码中公开，但通常可能是几天到一个星期不等。时效性阈值的设计需要平衡——太短会让很多有价值的历史内容失去曝光机会，太长会让推荐列表显得陈旧。
SelfpostFilter：用户自己发布的推文过滤
在For You推荐中，用户通常不需要看到自己刚刚发布的推文——用户当然知道自己发了什么。SelfpostFilter负责从候选中移除用户自己发布的推文。
这个过滤规则看似简单，但它对于推荐体验很重要。如果用户在自己主页能看到自己刚发的推文，但在For You推荐中又看到，会感到困惑和重复。
RepostDeduplicationFilter：转发去重
有时候，用户会转发同一条内容多次（可能是不同时间或通过不同方式）。RepostDeduplicationFilter负责识别并去重这些内容相同的转发，确保推荐中不会重复出现相似的转发内容。
IneligibleSubscriptionFilter：付费内容过滤
X平台可能有一些付费内容或仅对特定用户开放的内容。IneligibleSubscriptionFilter负责确保这些内容不会推荐给不符合访问条件的用户。这个过滤器维护了一套订阅规则，确保推荐的内容是用户有权限查看的。
PreviouslySeenPostsFilter：已看过的推文过滤
用户通常不希望在推荐中重复看到自己已经看过的内容。PreviouslySeenPostsFilter负责维护用户已经看过的推文记录，并从候选中过滤掉这些推文。
这个过滤器的实现需要谨慎——它维护的用户历史不能太长，否则会占用过多内存；同时也要考虑“看过”的定义——是点开看过，还是仅仅在推荐中看到但没点开？不同的定义会影响过滤结果。
PreviouslyServedPostsFilter：会话内去重
除了用户历史，X还会维护本次会话中已经推荐给用户的推文列表。PreviouslyServedPostsFilter确保在同一次会话（可能是同一次刷新或连续几次刷新）中，推荐列表不会重复出现相同推文。
这解释了用户经常观察到的一个现象：刷新一次推荐后，有些内容消失了，有些新内容出现了。这可能不是因为算法“调整”了评分，而可能是因为这些内容已经在上一次会话中服务过，被这个过滤器移除了。
MutedKeywordFilter：静音关键词过滤
用户可以设置自己不想看到的关键词（可能是某些话题、某些词汇等）。MutedKeywordFilter负责扫描候选推文的内容，移除包含用户静音关键词的推文。
这个功能赋予用户一定的内容控制权。如果用户对某个话题不感兴趣，可以通过设置静音关键词来减少相关内容的曝光。
AuthorSocialgraphFilter：社交图谱过滤
这个过滤器负责根据用户的社交关系进行过滤。具体来说，它会移除来自用户屏蔽账户或静音账户的推文。
用户主动屏蔽或静音某个账户，代表着明确的“不感兴趣”信号。推荐系统应该尊重用户的这个选择，不应该推荐这些账户的内容给用户。
5.2 后过滤规则与可见性过滤
除了预过滤（Pre-Scoring Filters），X的推荐系统还设计了后过滤（Post-Selection Filters）环节。这套过滤在评分和选择之后进行，负责对最终推荐的候选进行最终验证和处理。
VFFilter：可见性过滤（Visibility Filter）
VFFilter是X推荐系统中最重要的后过滤组件之一。它的全称是Visibility Filter，负责确保最终展示给用户的内容是安全、合规、适合展示的。
VFFilter会检查推文的多种状态：
- 是否已被删除：如果推文在推荐给用户之前被作者删除，应该移除
- 是否被大量举报：如果推文被多个用户举报，系统会审核并可能下架
- 是否包含违规内容：暴力、血腥、垃圾信息等
- 是否处于审核状态：某些推文可能正在接受审核，暂不展示
VFFilter在最终推荐结果生成之后、返回给客户端之前执行。这解释了用户经常遇到的一个现象：正在刷推荐时，某条推文突然消失。这可能不是因为算法降低了它的分数，而是因为在用户看到它之前，VFFilter刚刚检测到它违规。
这种“事后过滤”机制是必要的，因为违规检测需要时间——一条推文刚发布时可能没有举报，系统让其通过初筛；但随着时间推移，如果多个用户举报它，系统审核后会决定下架。在用户刷新推荐时，这个决定生效，推文就消失了。
DedupConversationFilter：对话去重
当推荐中涉及某个话题的多个讨论时，可能会出现来自同一对话线程的多个回复。DedupConversationFilter负责对同一对话中的多个分支进行去重，只保留最相关的一个或几个。
这个过滤器的作用是避免推荐列表被同一事件的多个版本或讨论分支占据，保持推荐的多样性。
5.3 内容安全与合规机制
在社交媒体平台上，内容安全是一个永恒的话题。推荐系统作为内容分发的主要渠道，其在内容安全中扮演着关键角色。X的推荐系统通过多层次的安全机制来确保推荐内容的合规性。
多层次的内容审核
X的内容安全不是单一环节，而是贯穿整个推荐pipeline。
在候选获取阶段，系统会尽量避免将已知违规账号的内容纳入候选。如果某个账号因为违规被处罚，系统可能会降低其内容在检索阶段的权重。
在预过滤阶段，AuthorSocialgraphFilter会根据用户的屏蔽和静音设置来过滤内容。如果用户主动屏蔽了某个账号，系统不会推荐该账号的内容。
在评分阶段，负向行为预测中的P(report)会考虑推文的举报历史。如果某条推文有大量举报，模型会预测其有较高的被举报概率，在最终评分中降低其得分。
在后过滤阶段，VFFilter会最终审核即将展示的内容，确保没有违规内容漏网。
用户反馈闭环
推荐系统在内容安全中的另一个作用是收集用户反馈。用户对内容的举报、不感兴趣、屏蔽等行为，不仅影响当前推荐的评分，还会反馈到系统中用于未来优化。如果某个账号或某类内容持续引发负面反馈，系统会逐渐减少其推荐。
这种基于用户反馈的闭环机制使得推荐系统能够自适应地调整内容分发策略。当新的违规形式出现时，用户反馈可以帮助系统快速识别和处理。
第六章 关键设计决策分析
6.1 零手工特征工程的设计哲学
X推荐系统最革命性的设计决策是“完全移除手工设计的特征和启发式规则”。这个决定在推荐系统领域是相当大胆的，因为它摒弃了工业推荐系统中长期依赖的“特征工程”环节。
在传统的推荐系统中，特征工程是至关重要的一步。工程师需要根据业务理解，设计各种能够预测用户兴趣的特征。例如：
- 用户特征：年龄、性别、地理位置、兴趣标签等
- 物品特征：类别、标签、热度、发布时间等
- 交互特征：用户历史点击率、历史收藏率等
- 上下文特征：时间、设备、位置等
这些特征需要人工设计、提取、组合，然后输入到机器学习模型中。特征设计的好坏直接决定了推荐效果。这种方法虽然有效，但有几个显著的缺点。
首先，特征工程需要大量的人工投入。优秀的特征工程师需要深入理解业务和数据，才能设计出有效的特征。而且，随着业务发展，可能需要不断设计新特征、调整旧特征。
其次，手工特征难以捕捉复杂的非线性关系。人工设计的特征通常是简单的统计量或规则，难以表达用户兴趣的复杂性。
第三，手工特征容易陷入局部最优。由于人的认知有限，工程师可能遗漏一些有效的特征模式，导致系统性能无法达到理论最优。
X的设计哲学是：与其依赖人工设计特征，不如让模型自己从数据中学习特征。X使用基于Grok的Transformer模型来处理用户的行为序列，模型可以自动学习什么样的历史行为模式预示着用户什么样的兴趣。这种“端到端”的方法不需要人工干预特征设计，模型自己会找到最有效的特征表示。
这种设计的优势是深远的。首先，它大大简化了系统的工程复杂度。不再需要维护复杂的特征管道，不再需要担心特征缺失或特征异常，一切都由模型自动处理。其次，它能够捕捉更复杂的模式。Transformer的自注意力机制可以学习行为序列中的长程依赖，这是手工特征很难表达的。第三，它使得系统更加灵活。当业务需求变化时，不需要重新设计特征，模型可以通过微调来适应新需求。
当然，这种设计也带来了新的挑战。Transformer模型的训练需要大量的计算资源和数据；模型的可解释性不如手工特征——当推荐效果不好时，更难诊断问题所在。但X似乎认为，这些挑战是可以克服的，而手工特征的局限性是根本性的。
6.2 基于哈希的Embedding策略
在X的推荐系统中，无论是检索阶段的向量相似度计算，还是排名阶段的特征输入，都大量使用了embedding技术。Embedding将高维的离散特征（如推文ID、用户ID、词汇等）映射为低维的连续向量，使得机器学习模型能够有效处理这些特征。
X的一个独特设计选择是使用基于哈希（Hashing）的embedding，而不是传统的查表式embedding。
传统的embedding方法需要维护一个巨大的embedding表，存储每个ID对应的向量。例如，如果有10万个词汇，就需要存储10万个向量。这种方法的问题在于，当ID集合很大时，embedding表会占用大量内存；当遇到新ID时，需要额外的机制来处理（通常是用随机向量或零向量代替）。
基于哈希的embedding使用哈希函数将任意ID映射到一个固定范围的索引。例如，对于任何输入ID，使用哈希函数h(ID) mod N得到一个0到N-1之间的索引，然后查表得到对应的向量。这种方法的优势在于：内存占用是固定的（只需要N个向量），新ID可以自动映射到某个向量（不需要额外处理）。
X使用多个哈希函数（multi-hash）来减少哈希冲突的影响。每个ID会通过多个不同的哈希函数得到多个索引，然后将这些索引对应的向量组合起来（通常是拼接或平均）。这种方法在大幅减少内存占用的同时，保持了接近传统查表方法的性能。
基于哈希的embedding策略使得X的系统更加轻量级和高效。在处理数十亿级别的推文时，如果使用传统查表式embedding，内存占用将是一个天文数字。而使用哈希embedding，内存占用可以控制在可接受的范围内。
6.3 可组合管道架构
X的推荐系统代码中，有一个专门的candidate-pipeline crate，定义了推荐管道的通用框架。这个框架将推荐流程分解为多个标准化的组件（trait），每个组件有明确的职责和接口。
这个设计体现了“可组合”的架构哲学。整个推荐pipeline被分解为以下组件：
- Source：从数据源获取候选
- Hydrator：用额外特征丰富候选
- Filter：移除不符合条件的候选
- Scorer：计算排名分数
- Selector：排序并选择顶部候选
- SideEffect：运行异步副作用
每个组件都有标准化的接口定义，可以独立开发、测试和替换。这种设计带来了几个重要优势。
首先是模块化。开发者可以单独开发和测试每个组件，不需要理解整个系统的运作。例如，可以单独开发一个新的Filter来移除特定类型的内容，而不需要改动其他组件。
其次是可扩展性。当需要添加新的候选源或新的过滤规则时，只需要实现相应的trait并插入pipeline，不需要重构整个系统。
第三是并行化。框架在可能的情况下并行运行独立的sources和hydrators，充分利用计算资源。
第四是错误处理。框架提供了可配置的错误处理机制。当某个组件出错时，可以选择是跳过（fail-open）还是中断（fail-close），满足不同场景的需求。
candidate-pipeline框架使得X的推荐系统像乐高积木一样可以拼搭组合。这种架构对于大型工程团队来说非常重要——不同团队可以负责不同组件的开发，通过标准化的接口集成。
6.4 推荐系统的价值观与设计理念
从X推荐系统的设计中，我们可以一窥其背后隐含的价值观和设计理念。
追求真正的喜欢，而非简单的点击
X的推荐系统不是简单地追求用户“点击”。如果是那样，标题党、猎奇内容会大行其道——它们有很高的点击率，但用户点开后可能并不喜欢。
X的做法是同时预测多种行为，特别是负向行为。如果一条推文点击率很高，但“不感兴趣”、“屏蔽作者”的预测概率也很高，系统会降低其推荐权重。这体现了“让用户真正喜欢”的价值观。
避免信息茧房
推荐系统有一个天然的“回声室”效应：越喜欢什么就越推荐什么，导致用户只能看到自己认同的观点。X通过Author Diversity Scorer和OON Scorer来对抗这种效应。
- Author Diversity Scorer防止同一个作者的推文过度集中
- OON Scorer确保推荐中有一定比例的非关注内容
这反映了X的信念：一个健康的社交平台应该帮助用户发现新事物、新观点，而不是将用户困在信息茧房中。
透明与可解释
X将推荐算法开源的决定本身就体现了对透明的追求。用户不再需要猜测算法是如何工作的——代码就在那里，任何人都可以阅读和验证。
这种透明带来了信任。当用户了解算法的工作原理后，可以更好地理解为什么某些内容被推荐，为什么某些内容没有被推荐。这种理解本身就是一种赋能。
第七章 对内容创作者的建议与启示
7.1 基于算法机制的内容优化策略
理解X推荐系统的工作原理后，内容创作者可以针对性地优化自己的内容策略，以提高在平台上的曝光和影响力。
创作值得停留的内容
X的评分系统特别关注P(dwell)——用户在推文上的停留时间。这意味着，即使某条推文没有获得很多点赞，但如果用户愿意在推文上停留较长时间阅读，系统会认为这是一条高质量内容，并推荐给更多人。
如何提高用户停留时间？以下几点值得关注：
- 内容要有深度：简单的口水话无法让用户停留，有深度、有见解的内容才能吸引用户仔细阅读
- 叙事技巧：讲故事的方式比罗列事实更能吸引人，使用悬念、转折等叙事技巧可以延长用户阅读时间
- 适度的长度：太短的内容无法产生停留，但太长可能导致用户失去兴趣。最优长度取决于内容类型和目标受众
- 多媒体元素：图片、视频等多媒体内容可以增加视觉吸引力，提高停留时间
积极回复评论
根据相关分析，“回复+作者回应”的权重可能是单纯点赞的75倍。这意味着，积极回复用户评论是获得算法推荐的最有效方式之一。
当某条推文有评论时，创作者应该尽量回复。回复会触发“作者回复”这一高权重行为，显著提升该推文以及后续推文的推荐权重。忽视评论等于放弃流量——这在X的算法体系下是非常不划算的。
避免刷屏行为
Author Diversity Scorer会对同一作者的高频推文进行降权。如果一个账号在短时间内发布大量推文，系统会逐渐降低每条推文的推荐权重。
对于内容创作者来说，这意味着一方面要保持一定的发布频率以维持活跃度，另一方面要避免在短时间内发布过多内容。质量比数量更重要——与其一天发十条平庸的内容，不如精心创作一条优质内容。
优化负面反馈
负面行为（P(not_interested)、P(block_author)、P(mute_author)、P(report)）对推荐有严重的负面影响。创作者应该避免以下行为：
- 标题党：标题与内容不符会导致用户反感
- 引战内容：引发争议可能带来流量，但也会带来大量负面反馈
- 低质量内容：重复、无价值的内容会让用户感到厌烦
- 敏感话题：在边界试探的内容可能被举报
善用外链策略
虽然X允许在推文中包含外链，但外链可能不是最优选择。根据分析，将外链放在个人简介或置顶评论中可能是更好的策略——这样既能引导感兴趣的用户找到更多信息，又不会影响推文本身的算法评分。
7.2 理解用户行为对算法的影响
对于普通用户而言，理解X推荐系统的工作机制也有重要价值——它可以帮助用户更好地“训练”自己的推荐，让算法更懂自己的真实需求。
用户行为在“训练”算法
每个用户的每次互动——点赞、评论、转发、在某条推文上停留的时长——都在告诉算法用户的兴趣偏好。这些行为数据会被用于构建用户的行为序列，进而影响未来的推荐。
这意味着，用户实际上在“塑造”自己的信息世界。如果用户经常点赞某类内容，算法会认为用户喜欢这类内容，并推荐更多类似内容；如果用户经常举报某类内容，算法会认为用户不喜欢这类内容，并减少推荐。
理解这一点可以帮助用户更主动地管理自己的推荐。例如，如果用户发现自己被推荐了太多不感兴趣的内容，可以通过以下方式“纠正”算法：主动搜索感兴趣的话题、更多点赞真正喜欢的内容、对不感兴趣的内容使用“不感兴趣”功能等。
算法不是完美的
即使是最先进的Transformer模型，即使能预测15种用户行为，X的推荐系统仍然会出错。算法无法100%准确预测用户的兴趣，有时候会推荐不相关的内容，有时候会遗漏用户真正想看的内容。
用户应该意识到，推荐算法是一种辅助工具，而不是决定信息获取的唯一途径。当推荐无法满足需求时，主动搜索是更有效的方式。
理解为什么某些内容没有获得推荐
了解了过滤规则后，用户可以理解为什么某些内容没有出现在推荐中。可能的原因包括：
- 推文太旧：超过7天的推文可能被AgeFilter过滤
- 推文已看：PreviouslySeenPostsFilter会过滤用户已看过的内容
- 关键词静音：如果用户静音了某些关键词，相关内容不会被推荐
- 作者被屏蔽：被用户屏蔽或静音的账户内容不会推荐
- 违反规则：VFFilter可能检测到违规内容
理解这些机制可以帮助用户诊断推荐问题，而不是简单地归结为“算法偏见”。
第八章 行业影响与未来展望
8.1 开源对推荐系统领域的影响
X开源推荐算法的决定，将在学术研究和工业实践两个层面产生深远影响。
学术研究层面
对于推荐系统研究者来说，X的开源提供了前所未有的学习机会。在此之前，工业级推荐系统的内部运作机制对外界来说是一个黑箱。研究者只能通过论文、专利、博客等间接渠道了解一二，而且往往只能了解皮毛，无法深入细节。
X的开源代码改变了这一切。研究人员可以：
- 深入理解工业级推荐系统的完整架构
- 学习两塔检索模型的实际实现细节
- 研究Transformer在推荐场景中的应用
- 探索候选隔离机制的实现
- 验证论文中提出的各种技术在实际系统中的效果
这种透明度将推动学术研究的进步。研究人员可以更准确地评估自己提出的方法在实际系统中的潜力，而不是仅仅在实验数据集上测试。
工业实践层面
对于业界工程师来说，X的开源同样价值巨大。推荐系统是互联网公司的核心技术之一，但相关人才的学习资源有限。很多工程师只能通过阅读论文、参开源码来学习，但开源的工业级系统很少。
X的开源代码提供了宝贵的学习素材。工程师可以：
- 学习大型推荐系统的架构设计
- 理解候选生成、排序、过滤的完整pipeline
- 掌握Rust和Python混合编程的实践
- 了解如何构建高效、可扩展的推荐服务
这些经验对于构建自己的推荐系统非常有帮助。当然，直接复制X的代码并不现实——X的代码依赖于其特定的基础设施和数据。但其中的设计思想和工程实践是可以借鉴的。
推动行业透明度
除了技术和知识层面的影响，X的开源还可能推动整个行业向更透明的方向发展。当用户看到领先的社交平台愿意开源算法时，可能会对其他平台产生压力，要求类似的透明度。
当然，并不是所有公司都愿意开源自己的核心算法。推荐算法往往是公司的核心竞争力，涉及大量商业机密。X愿意开源，主要是因为其推荐系统建立在开源的Grok模型之上，而且马斯克似乎更看重透明带来的信任而非技术保密。
但无论如何，X的开源决定为行业树立了一个标杆。它证明了一个主流社交平台可以在保持竞争力的同时保持透明度。这种实践可能会激励更多公司考虑开源他们的算法。
8.2 技术发展趋势展望
从X推荐系统的设计中，我们可以一窥推荐系统领域的几个重要技术发展趋势。
大语言模型与推荐系统的深度融合
X推荐系统最显著的特点是使用基于Grok（xAI的大语言模型）的Transformer来驱动推荐。这是大语言模型在推荐系统中应用的典型案例。
传统的推荐系统通常使用简单的embedding模型来处理用户和物品，模型参数量有限。而大语言模型具有强大的语义理解能力，能够更准确地理解用户意图和内容语义。
X的实践表明，大语言模型可以被成功地应用于推荐系统，而且能够带来显著的效果提升。可以预见，未来会有更多推荐系统采用类似的技术路线。
从单一目标到多目标优化
X的推荐系统不是简单地优化点击率，而是同时预测15种用户行为，进行多目标优化。这反映了推荐系统设计理念的转变。
传统的推荐系统通常以点击率（CTR）或转化率（CV）为主要优化目标。但点击率并不能完全代表用户满意度——用户可能点击但不喜欢，或者不点击但实际上会喜欢。
多目标优化通过同时考虑多种用户行为，更全面地评估推荐效果。这种方法能够更好地平衡短期指标（如点击率）和长期指标（如用户留存）。
个性化与多样性的平衡
X通过Author Diversity Scorer和OON Scorer来平衡推荐的相关性和多样性。这反映了推荐系统面临的一个核心挑战：如何在满足用户当前兴趣的同时，帮助用户发现新的兴趣。
过度个性化的推荐会导致信息茧房，损害平台的长期健康。X通过多种机制来对抗这种趋势，确保推荐内容的多样性。
这种平衡艺术是推荐系统设计的难点之一。未来的推荐系统可能会引入更多机制来提升多样性，如引入推荐解释、展示不同观点等。
实时性与个性化的统一
X的Thunder组件使用全内存存储来实现亚毫秒级的推文检索。这反映了推荐系统对实时性的追求。
在社交媒体场景中，内容更新极其快速。用户希望看到最新发布的内容，而不是几个小时前的“旧闻”。这要求推荐系统具备极强的实时性。
另一方面，实时推荐又需要考虑用户的个性化偏好。如何在保证实时性的同时提供个性化推荐，是未来推荐系统需要解决的重要工程问题。
第九章 技术深度解析
9.1 两塔检索模型的工程实现
X的Phoenix系统采用两塔模型进行大规模检索。这个模型在工程实现上有几个关键的技术点值得深入分析。
用户塔的实现
用户塔的目标是将用户的多维信息编码为固定长度的向量。这个向量应该能够代表用户的兴趣偏好，使得与用户向量相似的推文向量对应的推文就是用户可能感兴趣的。
用户塔的输入可以分为两大类：用户画像特征和行为序列特征。
用户画像特征通常是相对稳定的属性，如用户的兴趣标签、账户年龄、活跃度、地区、语言偏好等。这些特征经过embedding处理后，送入神经网络进行特征变换。
行为序列特征是用户塔的核心输入。用户的历史行为（点赞、回复、转发的推文）被组织成一个序列。每个行为由推文ID和行为类型组成。这个序列经过embedding处理后，送入Transformer网络。
Transformer的自注意力机制能够捕捉行为之间的复杂关系。例如，如果用户连续点赞了几条关于人工智能的推文，Transformer可以学习到这种模式，赋予这些行为更高的权重，从而推断出用户对AI领域感兴趣。
用户塔的输出是融合了所有输入信息的用户向量。这个向量将被用于后续的向量检索。
候选塔的实现
候选塔的任务是将推文编码为向量。与用户塔不同，候选塔只需要处理单条推文，不需要考虑序列关系。
候选塔的输入包括推文的多种特征。文本特征是最重要的——推文的文字内容经过embedding处理后，送入Transformer网络。与用户塔类似，候选塔也可能使用多层的Transformer来编码文本。
除了文本，候选塔还会接收推文的元数据特征，包括：作者信息（作者的关注者数、认证状态、历史表现等）、发布时间（用于考虑时效性）、推文类型（是否包含视频、图片、链接等）、推文的已有互动数据（点赞数、回复数等）。
候选塔的输出是一个推文向量。这个向量与用户向量处于同一个向量空间，可以进行相似度计算。
向量化检索的实现
检索阶段的目标是：从数十亿推文中快速找出与用户最匹配的Top K个。
这个问题的挑战在于计算量太大。如果对每个推文都计算一次与用户向量的相似度，需要数十亿次计算，在实时场景中是不可接受的。
X采用的方案是近似最近邻（ANN）检索。这种方法不追求精确找到最近的邻居，而是在可接受的误差范围内快速找到“差不多近”的邻居。
常用的ANN算法包括：
- HNSW（Hierarchical Navigable Small World）：一种基于图的方法，构建多层的近邻图，支持高效的近似搜索
- FAISS（Facebook AI Similarity Search）：Facebook开发的向量检索库，支持多种索引类型
这些算法可以将搜索复杂度从O(N)降低到O(log N)甚至O(1)，使得在数十亿规模上的实时检索成为可能。
两塔模型的训练
两塔模型通常使用对比学习的方式进行训练。对于每个训练样本，系统会有一个正样本（用户实际参与的推文）和多个负样本（用户未参与的推文）。
训练目标是让正样本的向量相似度尽可能高，让负样本的向量相似度尽可能低。通过大量的训练样本，模型学会将用户和与其相关的推文映射到向量空间中相近的位置。
训练过程需要大量的计算资源——需要在数十亿级别的样本上进行训练。这就是为什么数据是推荐系统核心壁垒的原因之一。
9.2 候选隔离机制的深入探讨
候选隔离机制（Candidate Isolation）是X推荐系统中最重要的技术创新之一。这个机制解决了推荐系统中一个经典而重要的问题：如何在批量推理中保证评分的独立性和一致性。
问题的来源
在传统的深度学习推荐模型中，为了提高推理效率，系统通常会批量处理多个候选。这些候选被组织成一个batch，一起送入神经网络进行打分。
在这个batch内部，候选之间可以通过注意力机制互相“看到”彼此。每个候选在计算自己的表示时，可以attend到其他候选的信息。这种设计在某些场景下是有益的——例如，模型可以学习到“同一batch中已经有类似的候选，这个候选的独特价值不大”。
然而，这种设计也带来了严重的问题：批次偏差。由于候选之间存在交互，同一个候选在不同的batch中可能获得不同的分数。候选A在batch X中可能得分较低（因为同batch中有更优秀的候选B衬托），但在batch Y中可能得分较高（因为同batch中的候选都比较差）。
这种分数不稳定性会带来多个问题：
- 推荐结果不稳定：同一个用户刷新两次相同的推荐请求，可能得到不同的推荐列表
- 分数难以缓存：缓存的分数下次可能不再准确，因为batch组成可能不同
- 难以调试：当推荐效果出现问题时，很难判断是候选本身的问题还是batch组成的影响
- 公平性问题：候选的分数应该基于其自身质量，而不是依赖于同batch中的其他候选
X的解决方案
X的候选隔离机制通过在Transformer推理时使用特殊的attention mask来解决这个问题。
在标准的Transformer中，每个token可以attend到序列中的所有其他token（除了自己）。但在X的候选隔离设置中，当计算候选token的attention时，只有用户上下文token被纳入计算，其他候选token被mask掉。
这意味着，每个候选只能“看到”用户上下文，不能看到同一batch中的其他候选。候选的评分完全基于其与用户的匹配程度，不受batch中其他候选的影响。
这种设计的实现需要仔细处理attention mask。具体来说，attention mask矩阵需要被设计为：候选token与用户context token之间的attention是允许的，候选token与其他候选token之间的attention是被禁止的。
候选隔离的效果
候选隔离机制带来了几个重要的改进：
第一是分数稳定性：同一个候选在任意batch中获得相同的分数，因为它只受用户上下文影响，不受batch中其他候选的影响。这使得分数变得可信赖、可缓存。
第二是可解释性：当某个候选获得高分时，工程师可以确信这是因为它与用户匹配，而不是因为它与batch中的其他候选比较起来更好。
第三是公平性：每个候选都凭借自身的质量参与竞争，候选之间是独立的。这符合推荐的本质——推荐应该基于内容与用户的匹配度，而不是内容之间的相对比较。
第四是工程简化：不需要担心batch的选择策略——无论batch如何组成，每个候选的分数都是稳定的。
候选隔离的代价
当然，候选隔离机制也有一定的代价。禁止候选之间的attention意味着模型失去了在batch内部学习相对比较的能力。在某些场景下，这种信息可能是有用的。
例如，如果一个batch中同时有一个长视频和一个短视频，模型可能想基于“用户已经看了很多短视频”来调整对长视频的推荐。但如果使用候选隔离，这种跨候选的信息共享就被禁止了。
X的设计选择是：放弃这种能力，换取分数的稳定性和一致性。这是一个权衡，X认为这个权衡是值得的。
9.3 排序模型的训练与推理
X的Phoenix排名模型需要进行大量的训练和推理工作。理解这个过程的细节，对于理解整个推荐系统至关重要。
训练数据
排序模型的训练需要大量标注数据。在X的场景中，标注数据来自于用户的真实行为。每当一条推文被展示给用户，并且用户产生了某种行为（点赞、回复、转发等），就形成了一个训练样本。
训练样本通常包含：用户特征、推文特征、以及最终的用户行为标签。例如，一条被用户点赞的推文形成了一个正样本（标签为“点赞=1”），一条被用户忽略的推文形成了负样本（标签为“点赞=0”）。
多行为预测意味着模型需要同时学习多种行为。因此，训练数据中需要包含每种行为的标签。例如，对于同一个展示，模型需要学习预测：用户是否点赞了（标签0/1）、是否回复了（标签0/1）、是否转发了（标签0/1）等等。
训练目标
X的排序模型使用多任务学习的方式进行训练，同时优化多个行为预测任务。每个输出头（对应一种行为）使用交叉熵损失函数进行训练。
最终的损失函数是各任务损失函数的加权求和。权重可以通过手工设定，也可以通过自动学习得到。多任务学习的好处是：不同任务之间可以共享特征表示，提高模型的泛化能力。
在线推理
训练好的模型需要部署到线上进行实时推理。当用户请求For You推荐时，系统需要：
- 1.获取用户的上下文信息（用户画像、行为序列）
- 2.准备候选推文的特征
- 3.调用模型进行推理，获取每种行为的预测概率
- 4.将预测概率加权组合
