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

信息流是内容社区的中枢神经——它决定了创作者的内容能被谁看到，用户打开 App 会看到什么，平台的商业价值如何兑现。架构设计的每一个决策，最终都会反映在用户体验和业务指标上。

本文是信息流系列的上篇，聚焦技术架构——从内容生产 Pipeline、特征工程、召回排序引擎，到 Feed 分发、搜索、互动、审核、AB 实验，完整拆解"信息流系统怎么建"。目标读者是后端工程师、算法工程师和架构师。如果你更关心运营体系、商业化路径和团队建设，请阅读下篇《百万级内容社区信息流：运营体系与商业化（下篇）》。

全文结构：先从三方博弈理解问题本质（第 1 章），再看六层全景架构（第 2 章），然后逐层深入——内容怎么入库（第 3 章）、怎么理解和建特征（第 4 章）、怎么召回排序（第 5 章）、怎么分发到端（第 6 章），接着是搜索（第 7 章）和互动（第 8 章）两个关键子系统，最后是审核风控（第 9 章）和度量体系（第 10 章）。

1. 内容社区的核心问题

内容社区的本质是一个三方博弈系统：创作者生产内容、用户消费内容、平台在中间做分配和治理。

这三方的利益并不天然一致：

角色	核心诉求	典型矛盾
创作者	获得曝光、互动、收益	优质内容未必获得流量，标题党反而有效
用户	看到感兴趣的、高质量的内容	短期兴趣（猎奇）vs 长期价值（学习）
平台	用户增长、留存、商业化	过度商业化伤害体验，过度管控抑制供给

信息流是连接三方的核心枢纽——它决定了"谁看到什么"。 推荐做得好，三方共赢；做得差，劣币驱逐良币，生态崩塌。

从百万级用户向千万级迈进的过程中，信息流架构会遭遇三个关键转折点：

内容量爆炸：日均新增内容从千级到十万级，规则推荐失效，必须引入模型
兴趣分化：用户群体从同质化到多元化，"千人一面"变成"千人千面"
生态治理：低质内容、水军、搬运、擦边开始涌现，审核和调控成为刚需

这三个转折点，分别对应架构上的三次升级：从规则到模型、从离线到实时、从单链路到全链路治理。

2. 信息流系统全景架构

先看全局。一个完整的信息流系统分为六层：

层级	职责	核心组件	延迟要求
内容生产层	内容的创建、审核、处理、入库	审核服务、转码服务、特征提取、互动系统	图文 < 30s，视频 < 3min
内容理解层	对内容和用户做特征工程	NLP/CV/LLM、用户画像、Feature Store	离线 T+1，近线分钟级
召回排序层	从海量内容中筛选和排序	多路召回、粗排/精排/重排、搜索排序、AB 实验	模型链路 < 200ms
分发渲染层	将排好序的内容交付给用户	Feed 服务、搜索结果、CDN、Push、降级策略	端到端 P99 < 300ms
度量与治理层	效果度量、内容治理、合规保障	AB 实验指标、推荐 Trace、审核风控、隐私合规	近实时
基础设施层	存储、计算、网络	Kafka、Redis、MySQL/TiDB、ES、Milvus、Flink	—

需要区分两个"200ms"：召回排序层的 200ms 是模型链路延迟（从收到请求到排序完成），分发渲染层的 P99 < 300ms 是端到端延迟（包含模型链路 + Feed 服务逻辑 + 序列化 + 网络传输）。后文会分别讨论。

核心设计原则：

读写分离：内容写入链路（发布→审核→入库）和读取链路（请求→召回→排序→返回）完全解耦，写入慢不影响读取体验
三级流水线：离线（T+1 批量计算）、近线（Flink 分钟级流处理）、在线（请求级实时计算）各司其职
内容与分发解耦：内容的存储和理解独立于分发策略，同一份内容可以出现在推荐流、关注流、搜索结果等多个场景

一句话总结：信息流架构的本质是一条数据流水线——内容从创建到被用户看到，经过层层处理和筛选，每一层都在做"减法"和"排序"。

3. 内容生产 Pipeline

本节聚焦内容从发布到可分发的处理流程和 SLA 设计。

3.1 图文内容链路

一条图文内容从发布到出现在信息流中，经过以下处理阶段：

阶段	处理内容	延迟目标	失败处理
接收	参数校验、敏感信息脱敏、写入 Kafka	< 100ms	同步拒绝，返回错误
机器审核	文本敏感词 + NLP 语义 + 图片 CV 检测	< 3s	疑似违规进人工队列，不阻塞
内容理解	关键词提取、主题分类、情感分析、质量评分	< 5s	降级为默认标签，不阻塞入库
特征提取	生成 Embedding、打标签、计算初始质量分	< 5s	异步补算，延迟入召回池
入库	写入主库 + 搜索索引（ES）+ 向量库（Milvus）	< 2s	重试 + 补偿
状态变更	标记为"可分发"，进入召回池	即时	—

端到端目标：图文从发布到可分发 < 30 秒。

关键设计决策：审核和理解是异步并行的，而非串行。内容接收后同时进入审核队列和理解队列，审核通过 + 理解完成后才标记为可分发。如果审核通过但理解超时，先以降级标签入库，后续异步补算。

3.2 短视频额外处理

短视频在图文链路的基础上，增加几个重度处理步骤：

阶段	处理内容	延迟目标	关键技术
分片上传	大文件分片上传、服务端合并	取决于网络	断点续传、秒传（文件指纹去重）
转码	多码率（360p-1080p）、H.264 + H.265	< 2min	GPU 加速、并行多码率转码
智能封面	关键帧抽取、美学质量评估	< 30s	CV 模型评分 + 多帧候选
CDN 预热	推送到边缘节点	< 30s	热门内容优先预热

端到端目标：短视频从上传到可播放 < 3 分钟。

抖音在转码环节投入了大量工程优化——并行多码率转码 + 自研编码器，将转码时间压缩到分钟级。对于创作者来说，"发布后等 5 分钟才能看到"是不可接受的体验。

3.3 内容元数据模型

每条内容入库时，会生成一套结构化的元数据，这是后续召回和排序的基础：

@dataclass
class ContentMeta:
    content_id: str
    content_type: str           # "article" | "short_video" | "image_post"
    author_id: str

    # 内容理解结果
    category: str               # 一级类目（科技/美食/游戏...）
    sub_category: str           # 二级类目
    tags: list[str]             # 标签列表
    keywords: list[str]         # NLP 提取的关键词
    embedding: list[float]      # 768 维内容向量

    # 质量评估
    quality_score: float        # 0-1，综合质量分
    originality_score: float    # 原创度（与已有内容的去重比对）
    aesthetic_score: float      # 美学评分（图片/封面质量）

    # 运营属性
    freshness: float            # 时效性权重（随时间衰减）
    is_verified: bool           # 是否已通过人工审核
    distribution_status: str    # "pending" | "active" | "limited" | "removed"

数据质量直接决定推荐效果——垃圾进、垃圾出。 内容理解的准确率每提升 1%，下游推荐的相关性指标通常能提升 0.3-0.5%。

一句话总结：内容 Pipeline 的核心使命是"又快又准"——快速完成审核和处理，为下游推荐提供高质量的原材料。

4. 内容理解与特征工程

上一节聚焦"流程"，本节聚焦"能力"——如何理解内容和用户，如何组织和存储特征。

4.1 内容侧特征体系

特征类型	技术方案	产出	更新策略
文本理解	NLP 分类器 / LLM 多任务推理	类目、标签、关键词、摘要	入库时一次性
视觉理解	CV 模型（ResNet/ViT）	图片标签、封面质量分、OCR 文字	入库时一次性
视频理解	关键帧抽取 + ASR + 多模态模型	视频标签、字幕、BGM 识别	入库时一次性
内容 Embedding	双塔模型 / CLIP	768 维向量（存入 Milvus）	入库时 + 模型更新时批量重算
实时统计特征	Flink 实时聚合	CTR、完播率、互动率、分享率	分钟级更新

LLM 带来的变革：传统方案需要为分类、标签、摘要、质量评估分别训练多个模型，每个模型有独立的训练数据、部署、监控。现在用一次 LLM 推理就能完成所有任务，模型维护成本从 N 降到 1。小红书在内容理解环节已经大量使用 LLM 做多任务联合推理，效果优于传统 Pipeline。

落地要点：LLM 单次推理成本约 $0.001-0.01，适合在内容入库时使用（一次性开销）。如果日均新增 10 万条内容，月成本约 $3,000-$30,000。对于成本敏感的团队，可以用 LLM 蒸馏出轻量专用模型。

4.2 用户侧特征体系

特征类型	数据来源	存储	更新策略
基础画像	注册信息、设备信息	MySQL	低频更新
长期兴趣	全量行为日志聚合	HBase	T+1 离线更新
行为序列	最近 N 次交互	Redis（最近 50 条）	实时追加
实时兴趣	当前 Session 内的行为	请求上下文	请求级
用户 Embedding	双塔模型	Redis / Milvus	T+1 + 增量在线更新
社交关系	关注/粉丝/好友	图数据库 / Redis	事件驱动

长期兴趣和实时兴趣的关系：长期兴趣是"你是谁"（喜欢科技、运动），实时兴趣是"你现在想看什么"（刚搜了世界杯，可能想看足球）。精排模型需要同时捕捉两种信号——DIN/DIEN 等序列模型的价值就在于此。

4.3 特征存储架构

特征按时效性分三层，在线推理时合并：

层级	存储	时效	典型特征	读取延迟
离线层	Hive → HBase	T+1	用户长期兴趣、内容静态标签	5-10ms（HBase）
近线层	Flink → Redis	分钟级	内容实时 CTR、用户最近行为	1-3ms（Redis）
在线层	请求上下文	毫秒级	Session 行为、位置、时间	0ms（内存）

Feature Store（如 Feast、Tecton）的核心价值是解决训练-服务一致性问题。一个经典的坑：训练时用的是 T-1 日的 CTR 特征，但推理时用的是实时 CTR——数据分布不同，模型效果打折。抖音的特征工程体系用 Feature Store 统一管理离线和在线特征的版本，保证训练和推理看到完全一致的数据。

4.4 Embedding 更新与模型迭代

Embedding 是召回和粗排的基础，但模型不是一成不变的。当双塔模型迭代升级后，新旧 Embedding 不在同一向量空间，不能混用。百万级内容库的全量重算是一个非平凡的工程问题。

全量重算的典型流程：

阶段	操作	耗时估算（百万级内容）
离线批量推理	新模型对全量内容跑 Inference	4-8 小时（GPU 集群）
写入影子索引	新 Embedding 写入 Milvus 的影子集合	1-2 小时
灰度切换	5% 流量切到新索引，对比效果	24-48 小时观察
全量切换	确认无退化后，全量流量切换	分钟级（索引别名切换）
旧索引下线	保留 7 天回滚窗口后删除	—

关键设计：用户侧 Embedding 的更新节奏和内容侧不同。内容 Embedding 可以离线批量重算（内容不变），但用户 Embedding 依赖实时行为序列，切换新模型后需要一段"预热期"——新模型初期只能用静态特征生成用户向量，等积累足够的新行为数据后，序列特征才逐步生效。这个预热期通常需要 3-7 天，期间推荐效果可能有轻微波动。

一句话总结：特征工程的核心挑战不是"提取什么特征"，而是"如何在毫秒级延迟内把正确版本的特征送到模型面前"。

5. 召回与排序

召回和排序是信息流的核心引擎。它的任务是从百万级内容池中，在 200ms 内选出最适合当前用户的 20-50 条内容。

5.1 整体链路

整个过程是一个逐层收窄的漏斗：

阶段	输入规模	输出规模	延迟预算	模型复杂度
召回	全量内容池（百万级）	10,000+	< 50ms	轻量（倒排索引 / ANN）
粗排	10,000+	1,000~2,000	< 30ms	中等（双塔模型）
精排	1,000~2,000	100~300	< 80ms	重型（DIN/DIEN/多目标）
重排	100~300	20~50	< 30ms	规则 + 轻量模型

总延迟预算 < 200ms（模型链路），这对每个阶段的模型推理速度都有硬性要求。

5.2 多路召回

召回的目标是"不漏"——用多种策略尽可能覆盖用户可能感兴趣的内容。

召回路	策略	适用场景	典型量级
协同过滤	User-CF（看了又看）、Item-CF（相似内容）	有历史行为的用户	2,000~3,000
向量召回	用户 Embedding × 内容 Embedding，ANN 检索	语义匹配，跨类目发现	2,000~3,000
热度召回	按时间窗口内的互动量排序	全体用户（保底策略）	500~1,000
关注流	用户关注的创作者最新内容	有关注关系的用户	100~500
地域召回	同城/附近的内容	本地化内容（如小红书的"附近"）	500~1,000
标签召回	用户兴趣标签匹配内容标签	兴趣明确的用户	1,000~2,000
探索性召回	随机 / 低曝光优质内容	冷启动 + 多样性	500~1,000

各路召回的结果合并后去重，进入粗排。关键设计：每路召回返回的内容要带上"召回来源"标记，方便后续分析各路召回对最终效果的贡献。

向量召回的工程选型：

方案	适用规模	延迟	特点
Faiss	千万级	< 10ms	单机内存，适合中小规模
Milvus	亿级	< 20ms	分布式，支持标量过滤
Elasticsearch + kNN	千万级	< 30ms	已有 ES 集群可复用

B站的向量召回系统已做到亿级内容库、10ms 级延迟、支持多种索引（IVF、HNSW）动态切换。

5.3 内容侧冷启动

新内容没有任何互动数据，是召回和排序的"盲区"。如果冷启动做不好，新内容得不到曝光，创作者流失，供给端萎缩——这是百万级社区最常遇到的实际问题。

冷启动的核心思路是 Exploration-Exploitation 平衡：既要给新内容试探机会（Exploration），又不能让大量低质新内容冲击用户体验（Exploitation）。

初始分数的来源：新内容没有互动数据，但有内容理解产出的特征——质量分、原创度、美学评分、作者历史表现。用这些特征构建一个冷启动评分模型，为新内容分配初始排序分。

信号	权重	说明
内容质量分	高	来自 3.3 节的 quality_score
作者历史表现	高	作者过往内容的平均 CTR、互动率
原创度	中	搬运内容初始分更低
内容完整度	中	图文长度、视频时长是否合理
美学评分	低	封面/配图质量

流量池赛马机制（抖音模式）：新内容进入分级流量池，每一级通过数据表现决定是否晋级：

流量池级别	曝光量	观察窗口	晋升条件	淘汰后果
初始池	300-500	2-4 小时	完播率 > 15%，互动率 > 3%	停止分发，沉入长尾
二级池	3,000-5,000	6-12 小时	完播率 > 20%，互动率 > 5%	回退到初始池曝光水平
三级池	30,000-50,000	24-48 小时	综合分 Top 20%	维持二级池水平
推荐池	全量分发	持续	由精排模型决定	自然衰减

工程实现要点：流量池的分级不是物理隔离，而是在重排阶段通过 Boost 因子控制。新内容在初始池阶段获得一个正向 Boost，数据达标后 Boost 系数增大（进入下一级池），未达标则 Boost 归零。这个机制可以和 AB 实验平台联动——不同的晋升阈值作为实验参数调优。

一句话总结：冷启动不是"给新内容更多流量"那么简单，而是一套"小范围试探→数据验证→逐级放大"的风控机制。

5.4 粗排

粗排的目标是"快速筛选"——用轻量模型从万级候选中选出千级。这是性能瓶颈最敏感的环节——候选量大（万级），但延迟预算只有 30ms。

双塔模型是粗排的标准方案：用户塔和内容塔分别生成 Embedding，用内积或余弦相似度打分。

为什么双塔适合粗排：

设计选择	原因
用户塔和内容塔独立计算	用户 Embedding 可缓存，同一用户短时间内不需要重复计算
只用静态特征	粗排不加入实时交叉特征，避免实时计算开销
内积打分	简单向量运算，万级候选打分 < 5ms

粗排的工程优化：

优化手段	效果
用户 Embedding 缓存	缓存周期 10-30 分钟，避免每次请求都过用户塔
批量推理	万级候选一次性批量打分，GPU 利用率更高
量化压缩	Embedding 从 FP32 量化到 INT8，内存减半，计算加速 2-3x
异步预计算	新内容入库时提前过内容塔，存储 Embedding，请求时直接读取

粗排和精排的核心差异：

维度	粗排	精排
候选量	万级	千级
特征	静态特征（Embedding、类目、标签）	静态 + 实时特征（行为序列、上下文）
模型	双塔，参数量小	DIN/DIEN/多目标 MTL，参数量大
推理方式	向量内积，批量打分	逐条精细打分
延迟	< 30ms	< 80ms

训练数据差异：粗排用全量曝光数据训练（正负样本充足），精排用粗排后的数据训练（更接近真实分布）。一个常见错误是用精排的训练数据训练粗排——这会导致粗排"只认识精排筛过的内容"，丢失多样性。

5.5 精排

精排是整个推荐链路中最"重"的环节——它直接决定用户看到的内容顺序。

模型演进路径：

阶段	模型	特点	代表产品
早期	LR / GBDT	手工特征，可解释	早期微博
中期	Wide & Deep / DeepFM	自动特征交叉	小红书早期
当前主流	DIN / DIEN / SIM	捕捉用户行为序列中的兴趣变化	抖音、B站
前沿	多目标 MTL + 在线学习	同时优化多个目标，实时更新	抖音推荐

多目标优化是当前精排的核心技术点。单目标优化 CTR 会导致"标题党泛滥"，单目标优化完播率会导致"信息茧房"。

实际的优化目标是多个指标的加权组合：

# 多目标融合公式（简化版）
final_score = (
    w_ctr * predict_ctr          # 点击率
    + w_finish * predict_finish   # 完播率（视频）/ 完读率（图文）
    + w_like * predict_like       # 点赞概率
    + w_comment * predict_comment # 评论概率
    + w_share * predict_share     # 分享概率
    + w_follow * predict_follow   # 关注概率
    - w_dislike * predict_dislike # 负反馈概率
)

权重 w_* 的调整直接影响社区生态走向。抖音团队在公开分享中提到，他们根据业务阶段动态调整权重——拉新期加大 CTR 权重促进增长，成熟期加大完播和互动权重提升留存。

短视频精排的特殊性：短视频流（类似抖音的沉浸式上下滑）和图文信息流在排序目标上有关键差异。图文流的核心指标是 CTR（点击率），用户通过标题和封面决策是否点击，决策时间 1-2 秒；短视频流的核心指标是完播率和播放时长，用户看前 3 秒决定是否继续，完播是非常强的正向信号，3 秒内划走是强烈的负信号。此外，短视频有独特的召回维度——很多热门视频共享同一首 BGM 或同一个模板，BGM/模板 ID 是有效的 Item-CF 信号。多模态理解也更难，需要同时处理画面、声音、字幕、BGM 四个通道。

5.6 重排

重排是排序链路的最后一关，负责"生态调控"——在精排结果的基础上做全局优化。

重排策略	目的	实现方式
多样性打散	避免连续出现同类内容	滑动窗口内同类目 / 同作者限频
频控去重	避免用户重复看到相同内容	布隆过滤器记录已曝光内容
新内容加权	保证新内容有曝光机会	发布 N 小时内的内容给予 Boost
创作者保底	保证活跃创作者的内容有基础流量	每个创作者每天至少 N 次曝光
运营置顶	热点事件、活动推广	运营后台配置干预位
广告混排	信息流广告插入	固定位置或动态竞价

小红书的重排策略特别强调多样性——同一屏内不会出现两条同品类的笔记，这是其"逛街感"体验的技术保障。

一句话总结：召回负责"不漏"，粗排负责"快筛"，精排负责"排准"，重排负责"调生态"。四个阶段各有分工，缺一不可。

6. Feed 分发与高可用

Feed 服务是用户端直接感知的入口——用户下拉刷新看到的每一条内容，都是 Feed 服务返回的。

6.1 Push vs Pull vs 混合

模式	原理	优势	劣势	适用场景
Push	创作者发布时，写入所有粉丝的 Inbox	读取极快	大 V 一条写入百万次	关注流 + 粉丝 < 1 万
Pull	用户请求时，实时拉取并排序	写入零成本	读取延迟高	推荐流、发现页
混合	大 V 用 Pull，小 V 用 Push	平衡读写	实现复杂	粉丝 > 10 万

百万级用户下的选型：

关注流：Push 模式。粉丝量 < 1 万的创作者发布时直接写入粉丝 Inbox（Redis Sorted Set）。粉丝量 > 10 万的走混合模式
推荐流：Pull 模式。每次请求触发实时召回和排序
热点/同城流：Pull + 缓存。候选列表分钟级刷新，用户请求时个性化重排

微博是 Push 模式的经典案例——曾因大 V 发微博导致写入风暴而多次宕机，后来改为混合模式。

6.2 分页与去重

分页策略：不能用传统的 offset/limit（内容实时变化会导致重复或跳过）。推荐流用 cursor-based 分页——每次返回一个不透明的 cursor token，包含上次请求的状态。

去重策略：服务端用布隆过滤器记录每个用户近期已曝光的内容 ID（过期时间 7 天），召回结果经过滤后再进入排序。

6.3 短视频流的特殊处理

短视频流（类似抖音的沉浸式上下滑）和图文信息流在分发层有几个关键差异：

维度	图文信息流	短视频流
浏览方式	双列/单列瀑布流，扫标题和封面	全屏沉浸，上下滑切换
加载策略	列表一次加载 10-20 条	预加载前后 2-3 条视频
核心体验指标	列表加载速度	首帧时间（< 300ms）

短视频的核心体验指标是首帧时间——用户滑到下一条，画面必须立即出现。

策略	实现	效果
视频预加载	当前视频播放到 50% 时，开始加载下一条	首帧时间 < 300ms
封面占位	视频未加载完成时先展示高清封面	消除白屏感
自适应码率	根据网络状况动态选择 360p-720p	弱网下流畅播放
CDN 边缘预热	热门视频提前推送到边缘节点	回源率 < 5%
TCP 预连接	App 启动时预建立与 CDN 的连接	减少首个请求的 RTT

抖音的首帧优化做到了极致——4G 网络下首帧时间 < 200ms，背后是客户端预加载、CDN 调度、编码优化的全链路工程。

6.4 高可用与降级

Feed 服务是用户体验的最后一道防线。推荐链路任何一个环节出问题，Feed 服务必须有 fallback，不能返回空列表。

多级降级策略：

故障场景	降级方案	用户感知
精排服务不可用	跳过精排，用粗排分数排序	推荐质量略降，几乎无感
召回服务不可用	使用预计算的热度列表兜底	退化为热门内容流
Feature Store 超时	跳过实时特征，仅用静态特征	推荐个性化程度下降
整个推荐链路不可用	返回预缓存的编辑精选内容	所有用户看到相同内容
Redis 故障	本地缓存兜底（LRU，容量有限）	短暂可用，需快速恢复

缓存架构（三级缓存）：

层级	存储	容量	命中率	用途
L1 本地缓存	进程内内存（Caffeine/Guava）	1-5 万条	30-40%	热门内容、高频用户画像
L2 Redis	Redis Cluster	百万级	50-60%	用户 Feed 缓存、特征缓存
L3 兜底策略	预计算热度列表	固定	100%（最终兜底）	全链路不可用时

6.5 SLA 设计

Feed 接口的 SLA 需要区分模型链路延迟和端到端延迟：

指标	目标	说明
模型链路 P99	< 200ms	召回 + 粗排 + 精排 + 重排
Feed 接口 P50	< 80ms	含模型链路 + 服务逻辑 + 序列化
Feed 接口 P99	< 300ms	长尾主要来自 Feature Store 读取和网络抖动
可用性	99.95%	月度停机 < 22 分钟
降级可用性	99.99%	含降级后的兜底可用性

容量规划：按峰值 QPS 的 2 倍预留资源。百万 DAU 的社区，Feed 接口峰值 QPS 通常在 5,000-20,000（取决于用户活跃度和刷新频率），需要 10-30 台应用服务器（按单机 1,000 QPS 估算）。

一句话总结：Feed 分发层的核心是"快"和"稳"——正常情况下要快，异常情况下不能挂。

7. 搜索系统

搜索是信息流之外的第二大流量入口。小红书的搜索流量占比已超 30%，抖音搜索的日均使用次数超过 5 亿。搜索和推荐共享内容理解和特征基础设施，但在召回和排序上有本质差异。

7.1 搜索和推荐的关系

维度	推荐	搜索
用户意图	隐式（系统猜测用户想看什么）	显式（用户主动表达需求）
召回逻辑	多路召回，覆盖面优先	关键词匹配 + 语义匹配，相关性优先
排序目标	点击率、完播率、互动率	相关性 > 质量 > 时效性
共享组件	内容理解、用户画像、Feature Store、Embedding	← 同左
独有组件	协同过滤、行为序列模型	Query 理解、倒排索引、相关性模型

7.2 跨场景意图传递

搜索行为是推荐的强意图信号——用户搜了"露营装备"，推荐流应该在接下来的 Session 中增加户外类内容的权重。反过来，用户在推荐流中持续消费美食内容，搜索联想也应优先展示美食相关词。

实时联动的技术实现：搜索系统把用户的 Query 关键词实时写入行为序列（Kafka → Flink → Redis），推荐的精排模型通过 DIN/DIEN 的 Attention 机制自动捕捉这些跨场景信号。关键是延迟——从用户搜索到推荐流感知到这个意图，需要控制在分钟级。

跨场景一致性的另一面是负反馈共享：用户在推荐流对某类内容点了"不感兴趣"，搜索结果中同类内容也应降权。这需要统一的用户偏好存储，而非各场景维护独立的负反馈列表。

7.3 搜索链路

阶段	处理内容	技术方案
Query 理解	分词、纠错、同义词扩展、意图识别	Jieba/HanLP + NLP 分类器
Query 改写	将口语化查询改写为检索友好形式	LLM 改写 / 同义词表
召回	关键词召回（ES 倒排）+ 语义召回（向量检索）	ES BM25 + Milvus ANN
粗排	相关性初筛	BM25 分数 + 向量相似度加权
精排	综合排序	相关性 × 质量分 × 时效性 × 个性化
展示优化	高亮、摘要、聚合	关键词高亮 + LLM 生成摘要

Query 理解是搜索和推荐的核心差异。用户输入"怎么让猫不掉毛"，系统需要理解：意图是宠物护理（非"猫毛大衣"）；关键词扩展为猫掉毛、猫脱毛、猫毛护理、猫梳毛；内容类型偏好是教程类 > 种草类。

7.4 搜索词推荐

搜索词推荐（Search Suggest / 热搜）是搜索流量的重要来源：

功能	数据来源	实现方式
搜索联想	用户输入前缀	Trie 树 + 热度加权
热搜榜	全站搜索量实时聚合	Flink 滑动窗口 + 人工审核
猜你想搜	用户画像 + 最近行为	个性化推荐模型

一句话总结：搜索是用户主动找内容的通道，和推荐形成互补——推荐解决"不知道看什么"，搜索解决"想看特定的东西"。两者共享基础设施，但通过实时意图传递实现联动。

8. 互动系统

点赞、评论、收藏、转发、关注——这些互动行为既是独立的产品功能，也是推荐系统最重要的输入信号。

8.1 互动数据的双重角色

角色	说明	示例
产品功能	用户操作的直接反馈	点赞后心形变红、评论出现在列表中
推荐信号	作为正/负反馈输入推荐模型	点赞 = 正信号，"不感兴趣" = 负信号
生态指标	衡量内容质量和社区活跃度	互动率用于内容质量评分

8.2 高并发互动架构

热门内容的点赞/评论会产生瞬间流量高峰（如热搜事件），需要专门的高并发设计：

挑战	方案	说明
点赞计数风暴	Redis 计数器 + 异步落库	先更新 Redis，定时批量写入 MySQL
热门内容写放大	写缓冲 + 合并写入	1 秒内多次点赞合并为一次 DB 操作
评论排序	热度排序 + 时间排序双模式	热度 = 点赞数 × 时间衰减
互动通知	消息队列 + 聚合推送	"XX 等 5 人赞了你" 而非 5 条独立通知

8.3 评论排序的多目标优化

评论区是社区氛围的缩影。不同平台的评论排序策略直接影响社区文化：B 站的弹幕文化靠实时密度+情感共鸣排序支撑，小红书的评论区是"二次种草"阵地，抖音的"神评论"置顶制造了大量二次传播。

评论排序不是简单的"点赞数倒排"，而是多目标平衡：

目标	信号	权重策略
相关性	评论内容与主帖的语义相似度	基础权重，保证评论"说的是这个话题"
质量	评论长度、点赞数、点赞/点踩比	高权重，优质评论优先
多样性	评论观点的聚类标签	避免前 N 条都在说同一个观点
时效性	发布时间	新评论需要曝光机会，否则"先发优势"过强
作者互动	内容作者的回复	强 Boost，作者回复的评论优先展示

"神评论"发现：抖音用一个轻量分类模型识别有"传播力"的评论（幽默、共鸣、信息增量），给予额外的排序加权。这类评论的点赞率通常是普通评论的 5-10 倍，对内容的二次传播有显著贡献。

8.4 互动数据的实时流转

互动行为产生后，需要在多个系统间实时流转：

数据流向	延迟要求	实现方式
用户端即时反馈	< 100ms	客户端乐观更新 + 服务端异步确认
互动计数更新	< 1s	Redis incr + 异步落库
推荐特征更新	< 1min	Kafka → Flink → Redis（用户行为序列）
内容质量分更新	< 5min	Flink 聚合 → 更新内容特征
离线模型训练数据	T+1	Kafka → Hive（全量行为日志）

一句话总结：互动系统是连接用户行为和推荐引擎的桥梁——用户的每一次点赞、评论、划走，都在实时训练推荐系统。

9. 审核与风控系统

内容社区的"免疫系统"。没有审核风控，社区会迅速被垃圾内容和违规信息淹没。

9.1 三级审核架构

级别	触发时机	处理时效	覆盖率	典型场景
一级：机器审核	内容发布时	< 5 秒	100%	敏感词、鉴黄、涉政、广告
二级：人工复审	机器不确定时	< 30 分钟	10-15%	擦边内容、隐喻讽刺、争议话题
三级：事后巡查	举报 / 定期扫描	< 24 小时	抽检	水军行为、搬运内容、低质洗稿

9.2 机器审核技术栈

审核维度	技术方案	准确率目标	误伤率控制
文本敏感词	Trie 树 / AC 自动机	> 99.9%	< 0.01%
文本语义	NLP 分类模型（BERT 级别）	> 95%	< 2%
图片鉴别	CV 分类模型	> 98%	< 1%
OCR 审核	OCR + 敏感词检测	> 95%	< 2%
视频审核	关键帧抽取 + ASR + 帧级 CV	> 93%	< 3%

核心矛盾：准确率和召回率的平衡。实际操作中一级审核倾向于"宁严勿松"——疑似违规先限流，进入人工复审队列。

9.3 行为风控

风控类型	检测对象	技术方案	处罚措施
刷量	异常点赞/收藏/转发	行为频率 + 设备指纹 + 社交网络分析	数据回滚 + 账号降权
水军	批量注册的虚假账号	注册行为分析 + 设备聚类	批量封禁
搬运	复制其他平台内容	内容指纹（SimHash / pHash）	限流 + 标注"疑似搬运"
低质	标题党、无意义内容	质量评分模型	降低分发权重
营销	软广告、导流外链	NLP 意图识别	限流 + 提示

B站在社区治理上的经验值得借鉴——弹幕审核结合机器审核和社区自治（用户举报 + "风纪委员"志愿者审核），在保持氛围的同时降低人工成本。

一句话总结：审核风控是内容社区的生命线——做得好用户感知不到它的存在，做不好整个生态崩溃。

10. 数据指标与 AB 实验

没有度量体系，架构演进就没有方向。推荐系统的每一次优化都需要 AB 实验验证，否则就是"凭感觉调参"。

10.1 核心指标体系

层级	指标	定义	用途
北极星指标	人均使用时长	用户每日在 App 内的总停留时间	衡量整体产品价值
一级指标	DAU、留存率	日活跃用户、次日/7日/30日留存	衡量用户增长和粘性
二级指标（推荐）	人均内容消费条数、人均互动次数	用户每日消费和互动的内容数量	衡量推荐效果
三级指标（模型）	CTR、完播率、互动率、负反馈率	各项预估指标的线上表现	衡量模型质量
四级指标（生态）	内容供给量、创作者活跃率、多样性	供给侧健康度	衡量生态平衡

指标之间的博弈：CTR 提升不一定是好事——如果 CTR 涨了但人均使用时长降了，说明标题党增多，用户点了但很快退出。必须看指标组合，不能只看单个指标。

短视频场景的补充指标：

指标	目标	行业基准
首帧时间	< 300ms	抖音 < 200ms，B站 < 400ms
卡顿率	< 1%	抖音 < 0.5%
清晰度	720p+（WiFi）	自适应码率
播放成功率	> 99.5%	含弱网降级

这些播放体验指标不直接进入推荐模型，但会显著影响完播率和留存——首帧慢 100ms，完播率下降 2-3%。

10.2 AB 实验平台

AB 实验是推荐系统迭代的基础设施——每一次召回策略调整、模型升级、重排规则变更都必须通过 AB 实验验证。

核心架构：

组件	职责	实现方案
分流服务	将用户随机分到实验组/对照组	用户 ID Hash 取模，保证分流一致性
实验配置	管理实验参数、流量比例、互斥域	配置中心 + 管理后台
指标收集	收集各实验组的行为数据	Kafka → Flink → 实时指标聚合
效果分析	计算显著性、置信区间	T 检验 / Mann-Whitney U 检验
看板	实验效果可视化	自建 Dashboard 或 Grafana

分流设计要点：

要点	说明
用户级分流	同一用户在同一实验中始终在同一组
互斥域隔离	同时进行的多个实验不能相互干扰
流量复用	非互斥的实验可以共享流量（正交分层）
小流量验证	新策略先上 1-5% 流量，确认无负面影响后逐步放量

实验评估方法论：

步骤	内容	关键判断
1. 看核心指标	CTR、完播率、互动率变化	是否有统计显著性（p < 0.05）
2. 看护栏指标	负反馈率、退出率是否恶化	有显著恶化则终止实验
3. 看长期指标	留存率（需要 7-14 天观察）	短期增长是否以长期留存为代价
4. 看分群效果	新用户 / 老用户 / 不同兴趣群体	是否对某个群体有负面影响

10.3 推荐 Trace（全链路追踪）

推荐系统的每一次请求，需要记录完整的决策过程，用于效果归因和问题排查。

一条推荐 Trace 应包含：

字段	内容	用途
request_id	唯一请求标识	全链路关联
user_features	请求时使用的用户特征快照	排查特征问题
recall_sources	各路召回返回的内容列表和来源标记	分析召回贡献
rank_scores	粗排/精排/重排的打分结果	分析排序合理性
final_list	最终返回的内容列表	与用户行为对比
latency_breakdown	各阶段耗时	性能优化
experiment_groups	用户所在的实验组	AB 实验归因

Trace 数据量大（每次请求一条，日均可达数亿条），通常存储在列式数据库（ClickHouse）中，保留 7-30 天。

一句话总结：没有 AB 实验和全链路 Trace，推荐优化就是盲人摸象——你不知道改了什么导致了什么结果。

总结

信息流的技术架构是一条端到端的数据流水线——内容从创建、理解、召回、排序到分发，每一层都在做减法和排序。这条流水线的质量取决于各环节的协同效率，而非某个组件有多厉害。

三个核心原则：读写分离保证写入慢不影响体验，三级流水线（离线/近线/在线）平衡效果和延迟，度量驱动优化确保每一次迭代都有数据支撑。

技术架构解决的是"能不能"——系统能不能在 200ms 内返回用户感兴趣的内容。而"好不好"——生态是否健康、商业化是否可持续、团队如何演进——这些问题，留给下篇《百万级内容社区信息流：运营体系与商业化（下篇）》。