[选修] 搜广推的关联与差异

阅读提示：这是第一章的选修内容。如果你是第一次学习推荐系统，可以先跳过这一节，待学完主线内容后再回来阅读。

在互联网业务体系中，推荐（Recommendation）、广告（Advertising）、搜索（Search）常被并称为"搜广推"或"推广搜"。它们构成了互联网商业模式的"三驾马车"：推荐与搜索负责留住用户、制造流量，而广告负责将流量变现。

理解这三者的异同，不仅能让你看懂推荐系统在整个技术生态中的位置，也能帮你在面对复杂的业务场景时，迅速找到核心矛盾。

体验层：从用户视角看三者差异

我们先从最直观的用户体验出发。在同一个 APP 中，这三种形态往往同时存在，对应着三种完全不同的交互模式：

搜索 ：你明天要去健身房，急需一双跑步鞋，于是打开淘宝搜索框输入"男士跑步鞋 透气"。系统立刻返回几千个相关商品。你知道自己要什么，主动表达需求。系统的任务是理解你的 Query（查询词），从海量商品中找到最匹配的结果。

推荐：你周末无聊，打开淘宝首页"随便逛逛"。系统推了一双复古帆布鞋、一件卫衣——都是你最近浏览过的风格。你不知道自己要什么，系统主动猜测你的偏好。系统的任务是通过分析你的 History（历史行为），挖掘潜在兴趣。

广告：你在刷信息流时，看到一条标有"广告"标签的卡片——某品牌新款运动手表。它长得像推荐内容，但背后有明确的付费方。系统既要考虑你的兴趣，希望你在运动的同时可能有用运动手表来记录的需求，又要考虑相关商家的出价，考虑到双方对平台的变现。系统的任务是在 User Experience（用户体验） 和 Revenue（收益） 之间寻找平衡。

搜索、推荐、广告的典型界面对比

可以用一组简洁的公式来概括三者的表层差异：

• 搜索：User + Query → 相关性（满足即时意图）
• 推荐：User + Context → 兴趣度（挖掘潜在意图）
• 广告：User + Context + Ad → 商业收益（平衡体验与变现）

接下来，我们将视角深入到算法与业务逻辑的内核，看看这"三驾马车"在底层究竟有何不同。

逻辑层：推荐 vs. 搜索 —— 意图表达与集合逻辑

推荐与搜索虽然都是为了解决"人与信息匹配"的问题，但在意图处理和结果筛选的严格程度上，存在本质区别。

1. 显式意图 vs. 隐式猜想（Query 的 VIP 地位）

搜索和推荐的数学表达形式非常相似，但输入变量的权重完全不同。

搜索模型可以抽象为：

$$F_{search}(u,q,t)\to Score$$

其中 $u$ 是用户，$q$ 是查询语句，$t$ 是候选物品。 在搜索中，Query ($q$) 享受绝对的 VIP 待遇。最重要的特征往往是 $q$ 与 $t$ 的交叉特征（如文本匹配度）。如果用户输入"跑鞋"，系统必须返回跑步鞋，绝不能因为该用户喜欢打篮球就给他展示篮球鞋。

推荐模型可以抽象为：

$$F_{reco}(u,t)\to Score$$

这里没有显式的 $q$，系统完全依赖用户画像 $u$（包括历史行为序列）与物品 $t$ 的匹配。 在推荐中，最重要的特征通常是 $u$ 与 $t$ 的交叉特征（如"用户过去看过的类目"与"当前物品类目"的匹配）。

2. 交集 vs. 并集（严谨性 vs. 扩展性）

这是两者最深刻的差异。

搜索遵循"交集"逻辑（Intersection）： 假设用户搜索"马拉松 跑鞋 缓震"，用户的意图极其明确。搜索结果 $R_{search}$ 必须满足：

$$R_{search}=\text{Tag(马拉松)}\cap \text{Tag(跑鞋)}\cap \text{Tag(缓震)}$$

结果必须同时包含这三个要素。如果系统返回了"篮球 运动鞋 高帮"，会被认为是严重的 Bug（相关性错误）。搜索对准确性的要求是刚性的。

推荐遵循"并集"逻辑（Union）： 假设同一个用户的画像中包含"马拉松"、"跑鞋"、"缓震"这三个兴趣标签。推荐系统为了挖掘兴趣、增加多样性，其结果 $R_{reco}$ 往往是：

$$R_{reco}\approx \text{TopN}(\text{Tag(马拉松)}\cup \text{Tag(跑鞋)}\cup \text{Tag(缓震)})$$

系统不仅可以推缓震跑鞋，还可以推"跑步 训练 技巧"（宽泛兴趣），甚至基于关联规则推"篮球 运动鞋 高帮"（相关兴趣扩展）。这种扩展在推荐中不仅不是 Bug，反而是惊喜（Serendipity）。

商业层：推荐与搜索 vs. 广告 —— 利益博弈与精度要求

如果说推荐和搜索关注的是"流量生产"，那么广告关注的就是"流量变现"。这一目标的变化，导致技术侧重点发生了巨大偏移。

1. 三方博弈 vs. 单方体验

推荐和搜索的目标相对单纯：服务好用户 ($u$)。只要用户点击、观看、感到满意，模型的目标就达成了。

广告系统则必须同时服务三个主体的利益。用户要求广告相关、不干扰体验，广告主要求花钱能带来真实的转化（ROI），平台要求最大化收益（Revenue）。

这种复杂性直接体现在排序公式上。广告的核心指标是 eCPM（千次曝光有效收益）：

$$\text{eCPM}=\text{CTR}\times \text{Bid}\times 1000$$

甚至在 oCPC（以转化目标出价）场景下，公式变得更加复杂：

$$\text{eCPM}=\text{CTR}\times \text{CVR}\times \text{Target\_CPA}\times 1000$$

系统必须在用户兴趣（CTR/CVR）和商业价值（Bid）之间走钢丝。

2. 相对准确 vs. 绝对准确（校准的重要性）

这是算法工程师从推荐组转岗到广告组时，最容易踩的坑。

推荐与搜索只需要"相对准确"： 假设有两个物品 A（缓震跑鞋）和 B（复古帆布鞋），用户对 A 的真实点击率是 10%，对 B 是 5%。

• 模型预测：$P(A)=0.9,P(B)=0.8$。
• 虽然预测值偏高得离谱（0.9 远大于 0.1），但只要 $P(A)>P(B)$，排序结果就是 A 排在 B 前面。对于推荐系统，这种保序性（Order Preserving）就足够了。

广告必须追求"绝对准确"： 广告涉及真金白银的扣费。如果模型把真实的 1% 点击率预测成了 10%，根据 eCPM 公式，这会导致预估价值虚高 10 倍，平台会向广告主过度扣费，或者在竞价中错误地让低价值广告胜出。

因此，广告模型在预测后，必须进行校准（Calibration），强制让预测概率分布对齐真实的后验概率。

3. 深层转化与延迟反馈

推荐通常关注浅层指标（点击、播放）。而广告（尤其是效果广告）关注深层指标：转化（Conversion）。

一条转化链条可能是：曝光 -> 点击 -> 下载APP -> 激活 -> 注册 -> 下单付款。

这带来了两个棘手问题：

• 样本极度稀疏：点击率可能有 2%，但最终下单率可能只有 0.01%。正样本少得可怜。
• 延迟反馈（Delayed Feedback）：用户今天点击广告，可能一周后才下单。模型训练时，当天的负样本可能在几天后变成了正样本，这种数据回流的延迟对实时更新的模型是巨大挑战。

架构层：从分裂到统一

尽管在业务逻辑上有上述差异，但在工程实现上，搜广推正变得越来越像。

1. 统一的技术范式

无论是"推广搜"中的哪一个，目前都普遍遵循 Lambda 数据架构 和 漏斗型处理流程：

1. 召回（Recall）：从千万级候选中海选出数千个。
2. 粗排（Pre-ranking）：轻量级模型筛选出数百个。
3. 精排（Ranking）：复杂深度模型（DeepFM/DIN 等）打分。
4. 重排（Re-ranking）：加入业务规则（去重、打散、强插）。

广告系统的另一点不同

广告系统由于候选集（在线广告库）通常比全量商品库小一个数量级（百万级 vs 十亿级），有时会简化甚至省略粗排环节，直接让精排模型处理更多候选。

2. 技术栈与人才的通途

由于底层技术高度重合——都在用 Embedding 做表征，用双塔做召回，用 Transformer/Attention 做特征交叉——技术栈是通用的。

• 算法通用：Youtube 的 DNN 推荐论文，由于效果好，很快就会被应用到搜索排序中；阿里的 DIN/DIEN 虽源于广告场景，但在推荐系统中同样是标配。
• 人才通用：在互联网大厂，搜广推三个部门的工程师往往可以低成本互相转岗。底层的特征工程系统、训练平台、推理引擎往往也是由同一个中台部门支持的。

理解了这些"同与不同"，你就掌握了贯穿本项目的核心脉络：我们在后续章节讨论的召回、排序、评估方法，虽然以推荐系统为主线，但其思想在搜索和广告领域往往是即插即用的。