Recommender Systems：YouTube DNN、Wide & Deep、Two-Tower
一句话:
Recommender Systems 解读
面向对象: AI PM / Product Architect / Data Product / Risk Product / Personalization Platform Owner。 核心问题: 推荐系统为什么不是“猜你喜欢”的单点模型，而是一套候选召回、排序、重排、策略治理、反馈闭环和风险控制组成的产品架构？ 学习目标: 理解 YouTube DNN、Wide & Deep、Two-Tower retrieval 和多阶段推荐系统，并把它们映射到金融零售 next-best-action、财富产品推荐、信贷预审批、客服引导和合规边界。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Google Recommendation Systems course | https://developers.google.com/machine-learning/recommendation | 建立推荐系统从 candidate generation 到 scoring 的整体框架 |
| TensorFlow Recommenders | https://www.tensorflow.org/recommenders | 理解 retrieval/ranking 多任务推荐建模的工程抽象 |
| YouTube DNN paper | https://research.google/pubs/deep-neural-networks-for-youtube-recommendations/ | 理解候选生成和排序两阶段架构 |
| Wide & Deep paper | https://research.google/pubs/wide-deep-learning-for-recommender-systems/ | 理解 memorization + generalization 的产品价值 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把个性化系统纳入风险治理、监控和影响管理 |
一句话:
推荐系统是企业 AI 决策系统的一种形态: 它在大量候选动作中，为某个用户、上下文和业务目标选择“下一步最合适的行动”。
1. 为什么推荐系统是高级 AI 产品能力
推荐系统不是低阶增长工具。它直接影响:
- 用户看到什么。
- 员工优先处理什么。
- 客户下一步被引导做什么。
- 哪个产品、内容、优惠、风险动作被排在前面。
- 哪些群体被持续强化或排除。
在金融零售中，推荐系统经常改名出现:
| 常见叫法 | 推荐系统视角 | 风险边界 |
|---|---|---|
| Next-best-action | 在候选行动中排序 | 不能绕过 suitability、consent、complaint 和 advice boundary |
| 客户经营策略 | 对优惠、沟通、产品、渠道排序 | 不能诱导不适当产品或造成差别待遇 |
| 财富产品推荐 | 对基金、组合、教育内容排序 | 不能把推荐伪装成个性化投资建议 |
| 信贷预审批 | 对产品资格、额度、引导路径排序 | 必须区分营销推荐、资格判断和正式信贷决定 |
| 欺诈/AML 优先级 | 对告警、案件、实体排序 | 高风险结果需要解释、复核和审计 |
高级 PM/架构师要问的不是“模型准确率是多少”，而是:
- 候选从哪里来，是否合规。
- 排序目标是什么，是否与客户利益冲突。
- 反馈信号是否偏置。
- 哪些策略不能由模型覆盖。
- 重排层如何注入公平、合规、库存、风险和业务约束。
- 如果系统持续优化一个短期指标，会不会伤害长期信任。
2. 多阶段推荐架构
生产推荐系统通常不是单模型端到端完成，而是多阶段流水线:
User / Context
-> candidate generation
-> retrieval
-> ranking
-> re-ranking / policy layer
-> explanation / UX rendering
-> feedback capture
-> offline training + online monitoring
2.1 Candidate Generation
候选生成解决的是规模问题:
从百万级内容、商品、产品、动作或案件中，快速找出几百到几千个可能相关候选。
常见来源:
- 协同过滤候选。
- 内容相似候选。
- Two-tower embedding retrieval。
- 热门/趋势候选。
- 业务规则候选。
- 风险或运营优先级候选。
- 人工 curated 候选。
产品问题:
- 候选池是否包含不应被推荐的内容或产品。
- 冷启动用户是否只能看到热门项。
- 业务团队是否可以注入 campaign，但不能绕过风险规则。
- 候选召回不足是否导致排序模型再强也无效。
2.2 Retrieval
Retrieval 的目标是快速缩小候选集合。Two-Tower 是常见结构:
user tower: user profile + behavior + context -> user embedding
item tower: item/product/content features -> item embedding
ANN search: nearest items to user embedding
它适合:
- 大规模召回。
- 实时低延迟候选。
- 用户和物品分别离线/在线编码。
- 推荐、搜索、广告、next-best-action 的统一召回底座。
局限:
- 点积相似度表达能力有限。
- 对复杂交叉特征和策略约束不够。
- embedding 难解释。
- 权限、适用性和合规约束不能只靠向量相似。
2.3 Ranking
Ranking 对候选进行精排，通常使用更多特征和更复杂模型:
- 用户长期偏好。
- 最近会话行为。
- 内容/产品属性。
- 价格、库存、渠道、时段。
- 风险、合规、适用性。
- 交叉特征。
- 历史反馈和转化。
YouTube DNN 论文的经典启发是:
- 候选生成和排序分工明确。
- 候选生成更关心 recall 和规模。
- 排序更关心精细化目标和上下文。
- 线上 serving latency 是架构一等约束。
2.4 Re-ranking / Policy Layer
重排层是高级产品架构的关键。它不是模型附属品，而是业务和治理控制面:
| 控制类型 | 例子 |
|---|---|
| Diversity | 不让首页全是同类内容或同类产品 |
| Freshness | 平衡历史偏好和新内容 |
| Fairness | 避免某些群体长期被低质量推荐 |
| Risk | 移除高风险、未授权、不适当推荐 |
| Suitability | 财富、信贷、保险产品必须匹配资格和风险承受能力 |
| Consent | 只使用客户同意范围内的数据和触达渠道 |
| Frequency cap | 控制过度营销 |
| Business constraint | 库存、地区、活动、合约义务 |
一个成熟推荐系统通常是:
ML score
+ business constraints
+ policy constraints
+ customer protection constraints
+ diversity/freshness controls
+ explanation and appeal path
3. Wide & Deep 的产品直觉
Wide & Deep 的核心直觉:
Wide 部分记住已知有效的交叉规则，Deep 部分学习可泛化的表示。
映射到产品:
| 能力 | Wide | Deep |
|---|---|---|
| 记忆已知模式 | 强 | 弱 |
| 泛化到新组合 | 弱 | 强 |
| 可解释性 | 相对高 | 相对低 |
| 冷启动 | 取决于特征 | 可利用语义/属性 |
| 业务策略注入 | 容易 | 间接 |
金融零售例子:
- Wide: “已有工资账户 + 过去 90 天稳定现金流 + 无逾期”触发某类理财教育内容。
- Deep: 从更丰富行为和产品语义中发现相似人群或相似需求。
- Policy layer: 如果用户不满足适用性、同意或风险要求，即使分数高也不能展示。
高级判断:
- Wide & Deep 不是老模型，而是产品架构思想。
- 高监管场景经常需要可解释、可审核的 memorized rules 与可泛化模型组合。
- 不能把 deep score 当成最终推荐理由。
4. Feedback Loop 与指标陷阱
推荐系统最危险的地方是反馈闭环:
model recommends
-> user sees
-> user clicks / ignores
-> system treats behavior as preference
-> model learns more of the same
典型偏差:
| 偏差 | 说明 | 控制 |
|---|---|---|
| Position bias | 排在前面的更容易被点击 | 随机探索、position debiasing、counterfactual eval |
| Exposure bias | 用户没看到的无法反馈 | 记录曝光、构造负样本要谨慎 |
| Popularity bias | 热门项持续更热门 | diversity、long-tail guardrail |
| Short-termism | CTR 高不代表长期价值 | 长期留存、投诉率、客户价值、信任指标 |
| Selection bias | 只从被推荐人群学 | holdout、探索流量、slice eval |
| Strategic behavior | 商户/内容方操纵信号 | abuse detection、quality review |
指标不能只看点击率:
| 指标层 | 推荐指标 | 金融零售补充 |
|---|---|---|
| Offline | recall@k、NDCG、MAP、AUC | slice fairness、policy violation rate |
| Online | CTR、conversion、dwell、task success | complaint、opt-out、mis-selling proxy |
| Business | revenue、retention、cost-to-serve | customer outcome、risk-adjusted value |
| Trust | hide/report、appeal、escalation | over-targeting、advice boundary breach |
| Ops | latency、freshness、coverage | manual override、exception queue |
5. 金融零售架构映射
5.1 Next-Best-Action Platform
Customer 360
-> consent and eligibility filter
-> candidate action generation
-> two-tower / rule candidates
-> ranking model
-> suitability and risk re-ranking
-> channel decision
-> agent/customer UX
-> feedback and complaints loop
必须区分:
- 推荐教育内容。
- 推荐产品了解路径。
- 推荐申请入口。
- 判断资格。
- 做正式审批。
- 提供个性化建议。
这些不是同一风险等级。
5.2 财富和保险推荐
控制点:
- 客户风险承受能力。
- 投资目标和期限。
- 产品复杂度。
- 适当性规则。
- advice vs guidance。
- 解释、披露和人工顾问升级。
推荐系统可以辅助排序，但不能把“相似用户买过”当成适当性理由。
5.3 信贷和支付
推荐可以用于:
- 预审批入口排序。
- 补件提醒。
- 还款辅助。
- 欺诈告警优先级。
- 支付争议下一步动作。
但正式信贷决定需要:
- 明确 decision authority。
- reason code。
- adverse action 边界。
- 模型风险管理。
- 公平借贷评估。
6. Product Architecture Checklist
| 设计项 | 高级问题 |
|---|---|
| Candidate source | 候选来自模型、规则、业务活动还是人工配置，谁负责质量 |
| Eligibility | 哪些候选必须在排序前过滤 |
| Objective | 优化点击、转化、长期价值、客户结果还是风险调整收益 |
| Label | 反馈信号是否代表真实偏好，是否有位置/曝光偏差 |
| Exploration | 如何探索新内容、新产品、新用户，而不伤害客户 |
| Policy layer | 哪些规则不可被模型覆盖 |
| Explanation | 展示给用户/员工的理由是否真实、可审计 |
| Monitoring | 按用户群、产品、渠道、风险等级监控 |
| Intervention | 出现投诉、偏差、过度营销时如何降级或关闭 |
| Governance | 哪些变更需要业务、风险、合规、数据 owner 审批 |
7. 推荐系统 PRD 骨架
| Section | 内容 |
|---|---|
| Problem | 要改善的决策或体验，不写“做个推荐系统” |
| Decision boundary | 推荐影响哪些行动，哪些行动不能自动化 |
| Candidate inventory | 候选类型、来源、owner、eligibility |
| User/context model | 可用特征、同意状态、实时上下文 |
| Ranking objective | 主指标、护栏指标、长期指标 |
| Policy controls | suitability、consent、fairness、risk、frequency |
| UX | 推荐理由、拒绝/隐藏、升级、申诉 |
| Evaluation | offline、online、slice、policy violation、customer outcome |
| Rollout | shadow、limited traffic、A/B、rollback |
| Evidence | model card、data card、decision log、approval record |
8. 面试表达
30 秒版本
推荐系统不是一个排序模型，而是候选生成、召回、排序、重排、策略治理和反馈闭环的组合系统。在金融零售里，我会先定义推荐是否影响客户权益，再设计 eligibility、suitability、consent、fairness 和 human escalation。模型分数只能是输入，不能替代产品责任和治理边界。
2 分钟版本
我会把推荐系统拆成四层: candidate generation、retrieval、ranking、policy re-ranking。Two-Tower 适合大规模召回，Wide & Deep 适合把已知规则记忆和泛化能力结合，YouTube DNN 的两阶段架构说明推荐系统必须把规模、延迟和目标拆开处理。真正的产品风险在 feedback loop 和目标函数，如果只优化 CTR，会放大位置偏差、热门偏差和短期行为。在金融零售场景，我会把客户同意、适用性、建议边界、投诉和公平性放进重排层和发布门禁，并用 offline eval、online experiment、slice monitoring 和政策违规率管理上线。
CTO / CPO 版本
推荐平台是企业 AI decisioning layer。它应该沉淀为可复用能力: candidate service、embedding retrieval、ranking service、policy engine、experiment platform、feature store、consent filter、monitoring 和 audit log。业务团队可以配置目标和候选，但不能绕过 eligibility、risk、privacy 和 suitability 控制。
9. 作品集任务
用一个金融零售 next-best-action 场景做作品集:
- 画出候选生成、排序、重排、反馈架构。
- 写一个推荐 PRD。
- 设计指标树: CTR / conversion / complaint / opt-out / policy violation / long-term value。
- 设计 20 条 offline eval cases。
- 设计 A/B 实验和探索策略。
- 写一页治理评审: suitability、consent、fairness、explainability、rollback。