推荐系统案例

一、项目背景

该项目为一个全球级流量入口的新闻推荐系统，核心目标是：

• 在高并发场景下提供稳定、低延迟的推荐服务
• 同时保证推荐效果（点击率、用户参与度）持续优化

系统规模如下：

• DAU：3000 万
• 峰值 QPS：30,000
• 内容规模：< 100 万
• 延迟：P95 < 300ms
• Error Rate：< 0.1%

---

二、核心问题

在系统设计与演进过程中，主要面临以下典型问题：

1. 高并发与低延迟的平衡

• 请求规模大（30k QPS）
• 推荐链路复杂（召回 + 排序 + 多阶段处理）
• 延迟预算严格（<300ms）

2. 推荐效果与系统复杂度的权衡

• 多路召回提升覆盖，但引入噪声
• 排序模型越复杂，延迟越高

3. 新内容与冷启动问题

• 新闻时效性强
• 新内容需要快速获得曝光

4. 系统稳定性与可扩展性

• 高峰流量波动明显
• 多模块协同（召回 / 排序 / 广告 / 编辑规则）

---

三、核心设计思路

系统整体采用：

离线 + 在线分层架构 + 多路召回 + 精排决策

1. 离线系统：构建高质量特征基础

离线部分拆分为两条核心 pipeline：

• UPP（用户画像）
• CPP（内容处理）

关键设计

• 内容特征：keyword / category / topic / entity / sentiment
• 行为特征：CTR / 停留时长 / 完成率
• 用户兴趣：多维偏好建模（category / topic 等）

架构选择

• Batch + NRT 混合架构
• 内容存储：HBase（Content Base）
• 用户特征：KV 系统（UDS）

用 Batch 保证稳定性，用 NRT 提升实时性

2. 在线系统：多路召回 + 精排

多路召回设计

系统采用多路召回组合：

• 相关性召回（索引系统）
• 热门召回（Redis）
• 协同过滤（User-based / Item-based）
• Exploration（探索机制）

不依赖单一召回，而是通过多视角覆盖用户兴趣

Exploration（探索机制）

• 随机注入新内容
• 达到一定数据后自动退出

解决问题：

• 冷启动
• 内容曝光不均

3. 精排系统设计

技术选型

• 模型：GBDT
• 实现：C++ 高性能服务

性能

• 输入：600 ~ 1000 条候选
• 延迟：< 50ms

在模型复杂度与延迟之间选择"最优可用解"

4. 在线引擎与后处理

排序之后执行：

• Variety（打散同类内容）
• 编辑规则（人工干预）
• Exploration 插入
• 广告接入

推荐系统不仅是算法系统，也是"业务控制系统"

---

四、关键优化点

1. 召回阶段优化

• 多路并行执行
• 过滤已读内容
• 控制整体耗时在 ~150ms

2. 排序阶段优化

• 控制候选规模（600~1000）
• 使用高性能 C++ 推理服务

3. 延迟控制

整体链路控制：

• 召回：~150ms
• 排序：<50ms
• 后处理：<100ms

P95 延迟稳定在 300ms 内

4. 稳定性设计

• 模块解耦
• 缓存（Redis）
• 定时任务 + 离线兜底
• 多层降级策略

---

五、关键设计权衡（Trade-off）

1. 精度 vs 延迟

• 更复杂模型 → 更高延迟
• 采用 GBDT + C++ 平衡性能与效果

2. 覆盖 vs 噪声

• 多路召回 → 覆盖提升
• 排序模型控制噪声

3. 实时性 vs 稳定性

• NRT 提升响应速度
• Batch 保证稳定

4. 探索 vs 利用

• Exploration 提供新内容机会
• 主流程保证效果稳定

---

六、结果与效果

该系统在实际运行中实现：

• 支撑 3000 万 DAU
• 峰值 QPS 达 30k
• 推荐延迟稳定在 P95 < 300ms
• 错误率 < 0.1%

同时：

• 推荐效果稳定提升
• 新内容能够获得合理曝光
• 系统具备良好扩展性

---

七、可复用经验

从该系统中，可以总结出几个关键经验：

1. 推荐系统是工程系统，而不是算法系统

• 算法只是其中一部分
• 架构设计决定系统上限

2. 多路召回是基础能力

• 单一召回无法覆盖真实需求

3. 排序系统必须受延迟约束

• 不存在"无限复杂模型"

4. Exploration 是长期效果的关键

• 没有探索，就没有增长

---

八、总结

该案例的核心不在于某个具体技术点，而在于：

如何在效果、性能与系统复杂度之间建立可持续演进的架构。