02 · 召回：先决定去哪里找

Twitter 2023 快照 + 自拟集合例子。例子里的数量不是业务数据。

“相似”不只一种

这一层先回答“哪些内容进入下一轮比较”，还没决定最后给你看什么。把召回和最终推荐混在一起，很容易要求一个模型同时承担覆盖、精细打分和整屏体验。

你可能想看一直关注的作者，也可能想看陌生人写的新教程。关系、共同互动和内容语义，提供的是不同线索。

Twitter 2023 的公开材料列出了 Earlybird、UTEG、Cr Mixer 等候选（candidate）入口。SimClusters ANN 则利用社区表示与候选集合做近似相似度检索（retrieval）；这里的社区主要来自互动结构，不应直接理解为人工标注的主题分类。Home Mixer · SimClusters ANN

双塔解决什么，没有解决什么

教学双塔（dual-encoder）把用户上下文编码成向量，把候选内容编码成另一个向量，再用点积（inner product）或余弦相似度找近邻。候选可以提前编码，所以不用为每个请求对全量内容做复杂交互。

但表示压缩、训练标签和索引覆盖都会限制能找到的东西。换成更强的 encoder，不会自动补回没被记录的反馈，也不会自动让全新内容进入索引。

想追问“为什么这种分解能省计算，代价又是什么”，可以接着读双塔设计拆解。这一篇先把多路召回的关系讲清楚。

flowchart LR
 U["用户上下文"] --> G["关系 / 互动来源"]
 U --> V["向量检索"]
 U --> N["新内容来源"]
 G --> M["去重 + 固定总预算"]
 V --> M
 N --> M
 M --> R["交给排序"]

加一路，到底多了什么

假设关系来源找到 A、B、C；向量来源找到 B、C、D。合起来有 4 条，不是 6 条。新增 D 是否有用，还要看它是不是相关；只数不重复候选是不够的。

graph = {"A", "B", "C"}
dense = {"B", "C", "D"}
judged_relevant = {"C", "D"}
union = graph | dense
unique_relevant = (dense - graph) & judged_relevant
print(len(union), sorted(unique_relevant))

输出是 4 ['D']。这是集合演示，不是检索实验。真正比较时，还要固定总预算：原来取 3 条，新方案合并后取 4 条，不能把预算增长的收益全部归给新模型。

该保留哪一路

阅读 SimClusters 时，重点看它怎样先缩小候选、再做更精细的相似度计算。近似检索是在省计算和访问成本，不是在证明被漏掉的内容不相关。

同样只有四个名额，新来源值不值得加？

再构造一个例子：基线（baseline）取 [A,B,C,D]，另一来源依次找到 [C,E,F]。固定人工标注的相关集合为 {B,E}，预算始终为 4。把新来源直接拼进去，会变成六个唯一候选；即使找回了 E，也不能据此说融合方法更好。

若我们给原来源 2 个名额、新来源 2 个名额，得到 [A,B,C,E]，命中从 1 个变 2 个。这个增量有清楚的来源：E 是新来源独有的相关内容。可是如果配额改成 1+3，得到 [A,C,E,F]，就丢了 B，命中又回到 1。

所以先看互补性（complementarity），再测预算分配，不能从“两个来源不一样”直接跳到“应该做复杂 router”。需要比较固定配额、简单规则和可学习路由；路由若依赖很薄的用户历史，也可能学到不稳定的判断。

重叠还会吃掉名额。合并后少于 4 条时，可以按确定顺序从后续候选补齐，并记录额外读取成本。来源分数不在同一尺度时，不要直接把 0.8 和 12 混排；RAG 实践中的 RRF 算例展示了一种只用排名的基线，它同样需要在当前任务上验证。

自测

下一期：怎样把候选排成一屏。