推荐系统概述：目标、架构与常用算法
做推荐系统这些年，我经常被问到一句话：「推荐不就是猜用户喜欢什么吗？」
嗯，这话没错，但只说对了一半。推荐系统真正的目标，其实是在信息过载的环境里，帮用户做决策。
推荐系统的核心目标
我习惯把推荐系统的目标拆成三层来看：
- 用户侧：降低信息筛选成本，让用户更快找到感兴趣的内容
- 平台侧：提升留存、转化、时长等业务指标
- 系统侧：在延迟、吞吐、资源消耗之间找到平衡
你想想看，如果一个推荐系统只盯着点击率优化，结果推的全是标题党，用户点完就走了。这其实是个失败的推荐。
我在项目中遇到过类似情况——CTR 涨了 15%，但用户次日留存掉了 8%。后来我们加上了长期价值预估，才把指标拉回来。
推荐系统的本质：在正确的时间，把正确的内容，以正确的方式，推给正确的人。
经典架构：三层分离
说到架构，我见过不少团队一上来就想搞端到端深度学习。但说实话，工业级推荐系统最稳的架构，还是召回→排序→重排这个三层结构。
这个架构的好处是解耦。每一层可以独立优化，互不干扰。我见过最夸张的一个项目，召回层用了 7 路不同的策略，排序层换了 3 版模型，重排层加了 5 条业务规则——架构没动，照样跑得稳。
各层职责
| 层级 | 输入规模 | 输出规模 | 延迟要求 | 典型技术 |
|---|---|---|---|---|
| 召回层 | 百万级 | 千级 | < 50ms | 协同过滤、向量检索、图召回 |
| 排序层 | 千级 | 百级 | < 100ms | DeepFM、DIN、多目标模型 |
| 重排层 | 百级 | 几十级 | < 20ms | MMR、DPP、规则引擎 |
注意：召回层不是越全越好。我曾经把召回路数从 5 路加到 12 路，覆盖率确实涨了，但排序层延迟直接翻倍。后来发现 80% 的优质推荐来自前 4 路，果断砍掉了冗余的召回通道。
常用算法简介
算法这块，我不打算列一堆公式。咱们挑几个工业界真正用得多的，说说它们解决什么问题。
协同过滤
这是最经典的算法，没有之一。核心思想很简单：物以类聚，人以群分。
User-based CF 找相似用户，Item-based CF 找相似物品。我在做电商推荐时，Item-based CF 的效果往往比 User-based 好——因为用户的兴趣会变，但物品的属性相对稳定。
矩阵分解
说白了就是把用户和物品映射到同一个隐空间里。SVD、ALS 这些都属于这个范畴。
我记得有一次做视频推荐，数据稀疏到 99.8% 的矩阵都是空的。用 ALS 训练完后，召回率从 12% 提到了 31%。
但要注意：矩阵分解无法处理冷启动。新用户、新物品进来，你得靠别的方法兜底。
深度学习模型
这几年最火的当属 DeepFM 和 DIN。
- DeepFM：把 FM 的低阶特征交互和 DNN 的高阶特征学习结合起来。训练快，效果好，适合 CTR 预估场景。
- DIN：引入了注意力机制，根据候选物品动态调整用户历史行为的权重。适合用户兴趣多样化的场景，比如电商、短视频。
我的经验：别一上来就上深度模型。先跑通协同过滤 + LR 的基线，把数据链路、特征工程、评估体系都搭稳了，再上深度模型。否则你根本分不清是模型好，还是数据好。
多目标排序
现实中的推荐很少只看一个指标。点击率、转化率、时长、满意度……这些目标之间往往存在冲突。
常用的方法有：
- Shared-Bottom：底层共享，上层分塔。简单但容易互相干扰。
- MMOE：多个专家网络 + 门控机制。灵活，但参数量大。
- PLE：腾讯提出的渐进式分层结构。我在广告推荐中试过，效果比 MMOE 稳定不少。
推荐系统与 CEP 的关联
看到这里你可能会问：这些跟复杂事件处理有什么关系？
嗯，关系其实很大。我举两个例子：
- 实时特征计算：用户刚点击了一个商品，这个事件需要立刻进入特征管道，更新用户实时兴趣向量。CEP 正好擅长处理这种流式事件。
- 规则触发：比如「用户 5 分钟内连续点击 3 次同品类但未下单」，CEP 可以识别这个模式，触发一个优惠券推送。这在传统推荐架构里很难优雅实现。
后面的章节，我会详细讲 CEP 如何嵌入推荐系统的各个层级。今天先把基础打牢。