Pinterest：把「不上瘾」写进推荐系统的技术选择

先决定不要什么，才决定推荐系统做什么

Pinterest 是一个视觉搜索与发现平台，人们在这里寻找灵感、整理想法、完成购买，官方口径下有超过 6 亿月活用户。它 2010 年诞生于云上，从一个分享创意的初创公司长成今天的规模，中间没有经历过自建机房再上云的那种迁移。

但规模本身不是这家公司最难的部分。真正的分歧在产品目标上。首席架构师 Kartik Paramasivam 的说法是：「十多年来我们一直在用 AI 打造一种独特的积极线上体验，努力让 Pinterest 上的每一刻都是增益的，而不是让人上瘾的。」他把行业的另一条路径说得很直白——别人把 AI 调向病毒式趋势和最大化停留时长，Pinterest 选择优先考虑积极性，让用户容易找到真实的灵感时刻。

这句话听起来像品牌表述，落到系统里却是一个硬约束。如果优化目标不是时长，推荐系统就不能靠最容易拿到的强反馈信号（无限下滑、争议内容、情绪激发）来提升指标，它必须更依赖对内容本身的理解、对用户长期兴趣的建模，以及一层持续运行的内容过滤。这条路的计算代价明显更高：AI 早期只是根据用户保存的 Pin 生成相关想法，后来转向深度学习和多模态模型，去理解上传内容与用户兴趣、行为之间的关系，从数十亿 Pin 里挑出最相关的那一条。

于是「为什么现在必须改变」在这个案例里有一个不太常见的答案：不是旧流程崩了，而是平台想守住的产品原则，只有在算力和模型能力都到位之后才真的可执行。官方材料没有披露这个取舍是在哪一年、由哪一层决策确立的，也没有公布内部围绕目标函数的评估过程。

旧路径卡在哪里：实时性和体量必须同时成立

把「理解每张图 + 理解每个人 + 立刻给出结果」三件事叠在一起，是这个系统最难的地方。视觉平台的输入不是结构化字段，而是数十亿张图片；用户兴趣横跨家居装饰到时尚等差异极大的类目；而推荐必须实时返回，不能等批处理跑完。

Pinterest 的做法是在 AWS 上用微服务架构承接这三件事，官方描述里，它借此处理数十亿图片、理解跨类目的用户偏好、实时给出个性化推荐，同时维持那个让它区别于其他社交网络的安全环境。数据侧的量级是超过 500 PB 的处理、存储与分析，而推荐基础设施每天要分析的数据超过 18 TB——这两个数字口径不同，前者是平台整体的数据资产规模，后者是推荐链路每日实际吃进去的量，不该混着读。

吞吐上，官方给出的是每秒处理超过 1,000 万次 AI 推荐。这个数字支撑的不只是首页信息流，还包括内容审核和那些被官方称为「负责任」的产品特性，也就是说审核和推荐是同一套算力预算下的邻居，而不是事后加装的过滤器。

选择微服务而非单体，在这里的实际收益是各能力可以独立扩缩：训练和推理的资源形态不同，视觉理解和排序的延迟预算不同，安全模型的更新节奏也和推荐不同。官方材料未披露各服务之间的调用拓扑、降级策略和延迟目标，因此下面这张图只呈现官方点明的层次关系，不补齐链路细节。

三条能力线如何分工：谁在做判断，谁在做生成

Pinterest 的 AI 能力不是一个大模型包办所有事，而是按任务性质分成了三条线，各自的角色和人机边界不同。

第一条是推荐系统本体，完全建在 AWS 上，用 Amazon EKS 做快速部署，推理侧使用 10,000 多个 Amazon EC2 G5 实例，训练侧使用 600 多个 P4/P4de 实例。这里的训练与推理资源比例值得注意：推理规模远大于训练，说明系统的重心在持续服务而非频繁重训。

第二条是视觉理解。视觉搜索更新使用基于 Amazon SageMaker 构建的视觉语言模型，能快速识别超过 25 亿个对象，用户可以在一张图里挑出某个具体物件继续搜。这条线的人机分工最清楚：模型负责把图切成可检索的对象，最终「我想找的是哪一个」由用户点击决定，AI 不替用户下结论。

第三条是生成与安全。Pinterest Canvas 是自研的潜在扩散视觉基础模型，支持高分辨率图像生成与编辑，跑在 EC2 GPU 实例上以获得所需的速度和成本效率。它的具体用途很具体：把商品图的背景改造得更有灵感感，让广告主做出更吸引人的广告，同时省掉裁图、排版这些耗时工序。这里 AI 承担的是素材生产，广告主仍然是投放内容的决定者。另一项较新的产品 Pinterest Assistant 是支持语音的生成式对话体验，被定位为视觉优先的协作者，通过开放式提问帮用户找东西。

安全侧同样由 AI 打底。Paramasivam 的表述是「对我们来说，信任不只是一个功能，它是 Pinterest 的基础」，团队构建、训练并使用 AI 过滤不适合平台的内容与行为，同时把 AI 调向让用户更容易找到自己想探索的东西。

需要说明的是，官方材料没有披露审核环节的人工复核比例、升级路径、误报处理流程，也没有公布模型上线前的评审机制或回退方案。想复现这类项目的团队，应当自行确认三件事：安全模型误判后的申诉与恢复链路、生成素材投放前的广告主确认环节、以及推荐目标调整时的离线评估口径。这是 DataHub 给出的验证清单，不是 Pinterest 已披露的做法。

结果怎么读：哪一个数字能落到 AI 头上

官方案例把结果放在一组里呈现，包括营收同比增长 17%、月活用户增加 11%、搜索满足度改善 230 个基点、通过策略性资源管理实现显著成本优化，以及 70% 的用户发现已由 AI 驱动。这五项的口径完全不同，混在一起读会得出错误结论。

其中与 AI 关系最直接的是 70% 那一项，它描述的是产品内发现行为的构成比例——多少发现来自 AI 给出的推荐或搜索结果。但官方没有说明这个比例的统计窗口，也没有说明「AI 驱动」的判定方法：一次发现要满足什么条件才被计入。缺了这两项，这个数字能说明 AI 已进入主路径，却不能用来估算 AI 带来了多少增量发现。

营收增长 17% 和月活增长 11% 属于 Pinterest 的整体业务指标。这类指标同时受推荐质量、广告产品、市场环境和竞争格局影响，官方材料也没有给出拆分。案例自身的表述是「使用 AWS，Pinterest 取得了显著的业务成果」，这是一种时间上的伴随关系，不是把营收变化归因给某一套模型或某一家云厂商的因果结论。DataHub 判断：这组数字适合用来说明这套技术投入没有以牺牲商业表现为代价，不适合用来做 AI 投资回报测算。

搜索满足度改善 230 个基点是四项里最贴近功能效果的一个，但官方没有披露它的定义、基线和测量周期，因此也无法判断它对应的是视觉搜索更新、推荐调整，还是两者叠加。至于成本优化，官方只用了「显著」这一定性描述，没有给出金额或比例，不能当作量化结果引用。

什么条件下这套做法可以搬走

可迁移的部分是顺序，不是配置。Pinterest 先把数据处理和实时推理的底座做扎实，再往上叠视觉理解、图像生成和内容安全，三者共享同一套基础设施。任何内容量大、需要实时响应、并且已经在同一批数据上叠加多个模型任务的团队，都可以照这个顺序检查自己的瓶颈在哪一层——大多数卡点出现在底座而不是模型选型。

不可迁移的部分同样明确。每秒千万级推理和万台量级 GPU 实例，对应的是 6 亿月活的流量分布，规模差两个数量级时，这些数字不构成参照。同样，Pinterest 用自研扩散模型做广告素材，前提是它握有商品图和投放场景两端，没有这个闭环的团队自建生成模型很难摊平成本。

真正值得抄的是那个前置动作：先把产品要什么、不要什么定下来，再让技术选型去服务这个定义。Pinterest 放弃时长最大化后，付出的代价是更重的计算和更复杂的安全体系，收益则是一套目标明确、不需要反复摇摆的优化方向。做同类决策前，先确认自己能否承担这份代价，再谈架构。