先这样答
这两者是 RAG 检索阶段分别负责召回和精排的核心模型架构。Bi-Encoder 也就是双塔模型，负责从海量库中快速捞出相关文档；Cross-Encoder 也就是交叉编码器，负责对捞出的少量文档进行精准重排。
Bi-Encoder 的机制是将查询和文档分别独立输入编码器得到句向量，然后通过余弦相似度等几何指标比较。它的核心优势是文档的向量可以离线预计算，并构建 ANN 索引。在生产中，像 DPR 这类稠密检索器就是典型的双塔形态，能在毫秒级完成全库扫描。
Cross-Encoder 的机制则是把查询和文档拼接成一个序列，同时输入 Transformer，让自注意力机制在两段文本间进行充分的词级别交互，直接输出相关性分数。因为它不产生句向量，无法预先建索引，每个查询对每篇文档都要实时跑一次前向传播。如果对全库逐对计算，算力开销超出常规预算。对一万句话做聚类打分，双塔算完向量只要五秒，而交叉编码器全量逐对计算需要约六十五小时。
因此，Rerank 必须存在且只能放在召回之后。标准做法是先用双塔或混合检索召回前一百个粗筛候选，再用交叉编码器对这一百对进行精准打分，最后截取前几条送入大模型的上下文。这是工程上兼顾延迟与高检索精度的标准范式。
面试官会怎么追问
-
「既然 Cross-Encoder 这么慢，能不能直接在召回阶段用它？」 绝对不行。因为它无法离线预计算文档特征，也没有索引结构可建。如果用它做召回，每次请求都需要把查询和库里的上亿篇文档逐一拼接跑模型前向传播，延迟和算力成本在工程上是不可接受的。
-
「Rerank 阶段的候选数量一般怎么定？延迟怎么估算？」 典型的召回数量在二十到一百之间，精排后再取最相关的三到五条。交叉编码器的延迟随候选数量呈线性增长，工程上通常先确定 RAG 链路留给检索阶段的延迟预算，用预算除以单次推理耗时，反推计算出系统能承受的最大候选数量。
-
「除了这两种，ColBERT 这种 late-interaction 架构处于什么位置？」 它介于双塔和交叉编码器之间。文档 token 级别的向量可以离线算好并存下来，运行时计算查询的 token 向量，两者做最大相似度交互再汇总。它比双塔准，比交叉编码器快，在实际业务中既可以做高质量召回，也可以做轻量级精排。
回答的坑
把 Cross-Encoder 描述成一种可以产出更高质量向量的模型，实际上它根本不输出句向量，只输出相关性分数。
误以为引入 Rerank 只是为了增加检索准度，没有讲透它无法预计算建索引这一底层物理限制，忽略了算力与延迟约束才是两阶段架构的根本动因。
同系列的题