百万级内容社区信息流（上）：技术架构全解

信息流系统既要回答“这次返回哪些内容”，也要回答“这些内容现在是否允许被这个用户看到”。召回和排序决定相关性，内容状态、权限、用户选择与失败恢复决定系统能否正确交付。只画一条模型漏斗，容易遗漏后面这些约束。

本文以一个假设的百万级用户内容社区为规划背景，沿内容发布、特征更新、候选筛选到页面交付展开。规模和预算用于解释设计，不代表某个平台的内部实现或本文实测结果。运营、商业化与数据治理见下篇《百万级内容社区信息流（下）：运营体系与商业化》。

从负载与目标开始，而不是先列组件

注册用户数不能直接换算成服务器数量。至少需要估计活跃用户、请求频率、峰值分布、候选数量、内容类型和模型开销。

例如，假设 100 万 DAU，每人每天发起 20 次 Feed 请求，则日请求量为 2000 万，全天平均约 231 QPS。若把峰值系数暂定为 8，峰值规划约为 1852 QPS；这只是待流量数据验证的假设。一次请求返回 20 条内容，也不等于用户产生了 20 次有效曝光。

如果先给模型决策链路分配 200ms 预算，还要说明起止位置，并为排队、特征访问、序列化和网络另留空间。多个阶段各自的 P99 不能简单相加得到整体 P99；最终需要在真实负载分布下测量整条链路。

可用性同样要有明确口径：返回 200 状态码但内容不可见、列表已过期或全部无法播放，不应自动算成功。服务端响应、客户端首屏和视频首帧是不同指标。

把异步生产与在线交付分开观察

内容发布不必等待全部检索索引和统计特征同步完成。可以先持久化内容及处理任务，再异步审核、转码与构建索引。在线请求使用可用候选和特征，完成召回、排序与最终可见性校验。

两条链路分开，可以减少重处理直接阻塞请求的机会；它们仍共享资源与数据契约，不能称为完全解耦。索引积压会影响新鲜度，删除传播过慢会影响正确性，需要分别监控。

消息、数据库、搜索、向量与流计算产品应按这些责任选型，不能因为图里列了 Kafka、Flink、Redis 和 Milvus，就认为每个阶段都必须部署它们。

发布流水线：不同任务可以并行，放行条件必须明确

发布时生成 content_id 与内容版本，持久化正文、媒体引用和待处理记录。重复提交用业务幂等键识别。若使用主库与消息队列，需处理双写失败，例如采用事务 Outbox。

审核、媒体准备和内容理解可以并行；但它们的结果必须绑定同一内容版本。旧版本的“审核通过”不能让刚修改过的正文直接上线。

“疑似违规进人工队列，不阻塞”只能表示不阻塞其他处理任务，不能默认表示允许推荐分发。理解超时也不能绕过审核门禁。

主库、搜索索引与向量库不是一个天然的原子事务。可以由状态机记录各投影进度，以版本条件更新防止旧任务覆盖新状态；删除或下架发布带版本的失效事件，并在分发入口再次校验，避免索引尚未更新时继续展示。

短视频需要单独定义处理与播放指标

上传时间取决于文件大小和网络，应与“上传完成到首个可播放版本就绪”分开统计。多码率转码、封面、字幕与质量检查可以有不同优先级；先交付合格的基础版本，再补充其他清晰度，是一种可选策略。

内容哈希可以辅助去重，但不能代替对象访问授权；知道哈希不应使用户取得他人私有媒体。CDN 预热也不是保证所有边缘节点都有副本，应按实际服务支持与热点选择执行。

播放使用统一时间轴和兼容的分片格式，码率档位要依据终端与网络；这些细节见《视频分片技术全解》。在没有固定分辨率、时长、编码设置和硬件测试前，不承诺所有视频两分钟转码完成。

特征工程先保证时间和版本正确

内容标签、用户行为、实时计数与请求上下文具有不同更新频率。每个特征应定义计算口径、数据版本、事件时间、可用时间、缺省值和过期策略。

LLM 可以尝试同时提取标签与摘要，但多个任务合并到一次推理，不意味着评估、监控和成本都从 N 自动降到 1。其准确性与成本要按模型、输入长度、图片数量、失败重试及质量要求测量。日成本可以用“新增内容数 × 每条平均处理成本”估算，但每条价格需要来自实际选型或账单。

训练与服务一致，指相同语义下的时点对应

训练数据不能看到预测发生后才产生的点击与反馈，也不能不加区分地使用事后回补的特征。需要按样本时点重建当时可获得的信息，并核对线上离线计算逻辑。

Feast 的时点关联文档说明了历史特征对齐，也区分事件时间与创建/可用时间的处理。这类工具提供机制，仍需正确配置时间字段、保留历史版本并监控数据新鲜度。训练样本来自过去、在线预测发生在现在，两者不可能始终具有完全相同的数值。

把一次互动写进在线特征，只表示特征更新；模型参数是否更新，取决于训练流程。请求上下文也有读取与计算开销，不应在延迟表中写成严格的 0ms。

向量迁移要同时切换两侧模型与索引

用户向量和内容向量需要处于相容空间。模型升级时，即使维度相同，也不能直接假定新旧向量可比较。

可以先构建新内容索引，同时接收新增内容、修改和删除事件；用新用户塔生成查询向量，在同一实验版本下访问新索引。灰度验证候选质量、过滤和延迟后，再扩大流量，并保留可用的旧版本回退路径。

如果历史行为仍可用，新用户塔可以重新编码这些行为，不必等待固定的 3—7 天积累“新行为”。重算耗时和观察期则取决于内容规模、模型、算力、增量速度与实验所需样本。

召回与排序：每一阶段都要有明确收益

大规模候选通常分阶段处理。YouTube 的公开推荐论文采用候选生成与排序两阶段；具体系统是否再加入粗排和复杂重排，取决于规模、效果与成本，不是四阶段缺一不可。

一个说明性预算可以是：召回 50ms、粗排 30ms、精排 80ms、重排 30ms，合计 190ms，剩余 10ms 并不一定足够覆盖所有开销。它只是初始预算，必须通过并行调用、排队与尾延迟测试修正，不能作为实测 SLA。

多路召回与候选融合

候选来源可以包括协同过滤、向量、关注、热度、标签和受控探索。User-CF 按相似用户的偏好找内容，Item-CF 按内容间的行为关联找候选；“看了又看”更接近后者的常见用途。

不同召回路可能返回同一内容，合并时保留全部来源、版本和原始分数，以便解释结果。各路分数不一定在同一尺度，不能不经校准就相加。候选还要满足可见范围和内容状态要求，不能让权限过滤只存在于客户端。

Faiss 是相似检索库，应用需要自己承担相应的服务与数据生命周期；向量数据库或现有搜索系统则提供不同的集成能力。Faiss 文档也包含 CPU/GPU 等实现，不能简单定义为“小规模单机内存方案”。选型应使用自己的向量维度、更新率、过滤条件、召回率和并发负载测试，不能只套用“某产品固定 10ms”的表格。

冷启动是带约束的探索

新内容可以利用内容特征和有限的作者历史获得初始候选机会，但内容相似度不是原创权属证明，美学分也不能独立代表价值。探索预算还需要治理门禁、曝光人群与样本量约束。

可以分阶段扩大曝光，用实验调整策略；不把固定播放量、完播率和观察小时数标成“抖音模式”。仅靠 Boost 不能保证实际曝光配额，还需要检查候选供给、过滤、排序竞争和真实展示。

粗排、精排与多目标

粗排使用较低成本的模型筛选候选；双塔是选项之一，也常用于召回。用户塔可以使用实时信号，能否缓存取决于允许的陈旧程度。精排也可以批量推理，不必逐条串行执行。

FP32 向量改为 INT8，单看元素载荷约缩小到四分之一，并非减半；实际内存还包含尺度参数、索引与其他元数据。速度是否变快需要硬件、算子与质量测试，不能默认提升若干倍。

粗排与精排的训练数据都受曝光选择影响。召回后但未展示的候选没有自然获得真实点击标签；需要明确负采样、蒸馏或纠偏方法，不能把它们直接当作用户不喜欢的负例。

多目标可以组合点击、消费质量、互动和负反馈。加权前先定义事件与时间窗口，校准预测，并说明权重的业务含义。点击率提升不必然意味着用户受益，完播率升高也可能只是内容变短。需要联合评估，而不是从某一个指标直接推导标题党或信息茧房。

重排控制的是整张列表

重排可以加入同作者限频、类目多样性、新内容探索和广告约束。但应区分软目标与硬门禁：缺少候选时可以放宽某些多样性偏好，不能因此忽略下架、访问权限或用户屏蔽。

布隆过滤器适合近似筛掉已看内容，但存在误判，会把部分未看内容排除。它不是精确曝光账本，普通布隆过滤器也不支持任意删除；可以使用按时间分桶轮换的结构控制保留窗口。记录“已返回”和“已实际曝光”要分开，否则预取但未看的内容也会被长期排除。

Feed 分发：关注流与推荐流不必使用同一策略

关注流可以在发布时向粉丝收件箱扇出，也可以读取时合并作者发件箱，或混合两者。推荐流通常按当前请求生成候选，也可以使用预计算列表和短期缓存。

写时扇出的代价与粉丝数、发帖频率、活跃比例和保留窗口有关；读时合并仍有发布存储与索引成本，不能称为写入零成本。切换阈值应来自测量，不是固定的一万或十万粉丝。

游标需要绑定稳定的分页语义

实时变化的列表直接用 offset 容易重复或跳过；游标也不能自动解决重新排序。可以让游标绑定一次候选快照或明确的排序键、并列打破键、版本与有效期，并检查其用户作用域和完整性。

搜索分页采用 search_after 时也要考虑索引变化与稳定排序；Elasticsearch 的分页文档讨论了与 PIT 配合的方式。游标不是可让客户端任意修改的数据库查询条件。

降级必须保留正确性门禁

没有安全可交付的内容时，应返回明确的暂不可用或空状态，不能为了“永不空列表”展示被删除或无权访问的内容。预缓存列表不是 100% 可用性保障，治理状态服务本身也要设计降级约束与传播时限。

播放体验需要在客户端测量

预加载可以降低感知等待，也可能浪费带宽和电量。应按用户网络、流量偏好、设备能力及实际观看概率控制预取，而不是固定播放到 50% 就加载若干条。

分别测量列表返回、资源请求、解码准备与首帧，按网络和终端分组。封面占位不等于视频已播放，CDN 命中也不等于首帧达到目标。自适应码率和连接复用的收益需要用具体媒体与网络验证。

搜索与互动共享数据，但保留各自语义

搜索有显式查询，推荐主要从当前上下文与已允许使用的行为推断需求。两者可以共享内容处理和索引，但不同任务仍需不同的候选与相关性判断。

混合检索时，BM25 与向量相似分数不能未经处理直接相加；可使用合适的分数归一化、排名融合或学习排序。LLM 改写需保留原查询语义，精确名称、否定词和限制条件不能被改没。

跨场景行为是否共享，要符合已说明的处理目的和用户选择。“不推荐这类内容”不一定意味着用户主动搜索时也不愿看到，负反馈应保留作用范围。热点词与联想词也需要治理，不能只按计数直接公开。

互动关系与计数分开维护

点赞是“某用户对某内容处于点赞状态”，不是收到一次请求就执行一次 incr。需要幂等地记录点赞与取消，再把状态变化传播到计数、通知与特征。

可以以可靠持久化的关系或事件为依据异步维护 Redis 计数，并定期核对。若只更新 Redis 后周期性落库，应明确故障窗口内可能丢失的变化，不能当作天然可靠账本。

客户端乐观更新要在服务端拒绝时回退。评论发布成功也不一定立即公开，可能仍在审核状态。评论排序可考虑相关性、质量与多样性，但文本更长、点赞更多都不是质量证明；弹幕与评论也不能混成同一种排序机制。

审核是状态与证据流程，不只是分类器

发布前机器判断、人工复核与发布后举报巡查可以组合，关键是每次处置都能说明对象版本、证据、规则与处理结果。

待审、拒绝、限制可见与撤销限制需要明确状态转换。下架后的索引、缓存、关注收件箱和 CDN 访问策略也要随之处理；对申诉成功的内容恢复分发时，应使用当前有效版本。

敏感词命中可以用于候选线索，不能把字符串算法匹配正确率等同于违规判断准确率。评估模型时应区分类别基线、精确率、召回率与误伤率，并记录标注规范。抽取少量视频帧也不等于完整覆盖全部画面。

刷量和搬运检测需要相应证据与复核。相似指纹可以发现重复候选，不能单独判定版权；设备信号也需要按必要范围使用。人工处理时效取决于到达量、优先级和处理能力，不应凭空保证固定覆盖比例或统一处理分钟数。

让实验和 Trace 能解释一次变化

一次推荐决策至少关联请求 ID、模型与索引版本、实验分组、召回来源、过滤原因、最终列表和各段耗时。敏感特征不宜无差别全量落日志，可保留受控快照或版本引用，并设置采样、权限与保留策略。

实验分流应稳定且可复现，记录实验盐值或版本，检查样本比例异常和跨组污染。用户级分流也不一定适合所有问题：创作者供给或社交传播可能影响其他用户，需要考虑实验单元与相互干扰。

在实验开始前确定主指标、体验约束、最小关注效果和分析方式。不要反复查看 p 值，一旦小于 0.05 就宣称胜出；固定观察窗口或采用适当的序贯方法，并处理多指标、多次比较。用户级实验的分析不能把同一用户每次曝光都当成独立样本。

Trace 能说明哪个版本产生了哪些结果，不能单独证明某项改动造成业务增量。离线评估、线上对照、错误分析和长期观察分别提供不同证据，结果应保留其适用范围。

信息流架构的主线是让内容、特征、决策与交付共享明确的版本和状态约束。先用可靠的数据与可解释的流程完成这个闭环，再根据实际瓶颈增加模型阶段和基础设施。运营如何利用这些能力，继续见下篇。