先分清：Embedding 和 Rerank 各自对什么结果负责
RAG 的检索链路可以先想成一场两阶段筛选。
第一阶段面对的是整座知识库。系统把用户问题编码成向量，再从大量文档片段里快速找出一小批候选。Embedding 模型的任务不是直接判断最终答案，而是把可能包含答案的片段尽量送进候选集。它如果漏掉了正确证据，后面的模型再聪明也无从补救。
第二阶段只看这批候选。Rerank 模型把问题和每个候选片段放在一起判断相关性，然后重新排列顺序。它更擅长处理“关键词很像，但并没有回答问题”“同一个术语出现在规则和例外条款里”“问题带有否定含义”等细粒度差别，但代价是每个候选都要参与推理，因此不能像向量检索那样直接面对全库。
这也决定了两个模型的验收问题不同：
- 验收 Embedding，要问“正确证据有没有进入前 K 个候选”；
- 验收 Rerank，要问“在候选已经包含正确证据的前提下，它有没有把证据排到更适合生成模型使用的位置”；
- 验收整条链路，还要问“最终提供给生成模型的上下文是否完整、互补，而不是重复堆叠”。
如果不先拆开职责，常见的误判是：正确证据根本没召回，却把责任归给 Rerank；或者召回已经够好，只因为最终回答不准就不断更换 Embedding。面试官追问模型选型，本质上是在看你能不能把故障定位到正确的一层。
本题不重复讨论“为什么 Rerank 不能对整个知识库逐条运行”，重点放在候选模型怎样筛选、如何做公平对照、何时值得微调，以及版本升级怎样迁移和回退。
公开榜单只能缩小范围，不能替你做项目决策
公开榜单有价值，因为它能快速排除明显不适合的模型，也能提供一个可比较的起点。但榜单分数通常来自固定数据集和固定任务，它不知道你的知识库里是中文制度文档、中英混合技术文档，还是包含大量表格、代码和内部缩写；也不知道你的 Query 是完整问题，还是只有几个字的客服口语。
因此，榜单适合回答“哪些模型值得进入候选池”，不适合直接回答“哪个模型应该上线”。候选筛选至少要过下面几道门。
第一，语言和真实文本形态是否匹配
只写“支持中文”还不够。要抽样检查真实数据里有没有中英混写、型号、数字、缩写、专业术语、否定句和长列表。一个模型在通用中文问答中表现不错，不代表它能区分企业内部两个非常相近的流程名称。
还要看 Query 和 Chunk 的长度分布。用户问题可能只有十几个字，候选片段却可能包含一个完整章节。模型声明的最大输入长度只是上限，不代表长文本一定处理得更好。如果 Rerank 的输入超过限制被截断，而答案恰好在片段后半段，模型能力再强也看不到证据。
第二，部署边界是否允许
有些团队可以调用外部 API，有些数据必须留在内网；有些环境有 GPU，有些只能使用 CPU；有些服务追求单请求低延迟，有些离线任务更关心批量吞吐。选型时要把这些约束写成明确条件，而不是在模型选完后才发现无法部署。
许可证、模型体积、运行时依赖、是否支持批量推理、是否有稳定版本和回滚方式，也属于选型条件。它们可能不会出现在检索排行榜上，却直接决定项目能否长期维护。
第三，升级成本能否承担
更换 Embedding 不是替换一个配置项这么简单。文档向量和查询向量必须处在同一个向量空间，模型、维度或编码方式发生变化后，旧索引通常不能继续与新查询向量混用。知识库越大，重新编码、建立新索引、校验数据完整性和切换流量的成本越高。
Rerank 的替换相对不需要重建文档向量，但仍要核查输入格式、最大长度、分数分布和阈值。不同模型输出的分数并不天然可比较，旧模型上的固定阈值不能直接照搬到新模型。
所以，模型候选表不应只有“名称”和“榜单分数”，还应记录语言、输入长度、向量维度、许可证、运行方式、单条与批量延迟、资源峰值、版本和迁移成本。只有这些条件满足，候选才值得进入项目评测。
公平评测的关键，是一次只改变一个变量
很多所谓“模型对比”其实没有可比性：换 Embedding 的同时改了 Chunk 大小、Top-K 和相似度阈值；换 Rerank 的同时又换了召回模型和提示词。最后指标变化了，却无法判断究竟是哪一步造成的。
一套可复现的对比应先冻结其余链路。对 Embedding 候选，使用同一份原始文档、同一套解析和分块结果、同一批测试 Query、同一套正确证据标注，并保持索引类型和 Top-K 一致。对 Rerank 候选，则进一步冻结粗召回产生的候选集合，让每个模型对完全相同的 Query 与 Chunk 对打分。
测试集不能只准备“答案原句就出现在文档里”的简单问题。至少要覆盖：
- 用户口语与文档正式术语不同；
- 中文和英文缩写混合；
- 两个流程名称或产品名称非常相近；
- 问题包含“不能、除外、无需”等否定表达；
- 答案需要两段证据共同支持；
- 文档中存在多个近重复片段；
- 正确证据靠近长 Chunk 的末尾；
- 知识库中确实没有答案，需要系统拒答。
每个问题都要标注参考答案和支持证据，至少保存文档 ID、片段 ID 或页码。没有证据标注，只看最终回答是否“像对的”，就无法判断模型到底找到了正确内容，还是生成模型凭自身知识碰巧答对。
评测还要把训练、开发和测试问题隔开。开发集可以用来选 Top-K、候选数量和阈值，测试集只用于最终比较。如果反复盯着测试集调参数，测试集就会逐渐变成开发集，得到的分数不能代表新问题上的表现。
Embedding 不能只看一个 Recall 数字
Recall@K 是 Embedding 选型的核心指标之一：人工标注的正确证据中，有多少出现在前 K 个候选里。但它不是唯一指标。
首先要同时看不同 K 值。某个模型可能在较大的 K 下能找回证据，但在较小的 K 下排序很差，这意味着后续需要更大的候选集，Rerank 成本也会随之增加。反过来，如果 K 很小就能稳定覆盖正确证据，整条链路会更轻。
其次要看证据覆盖和冗余。一个复杂问题可能需要两段不同证据，模型只找到其中一段，表面上“命中过”却不足以回答。另一个常见问题是前 K 个候选几乎是同一段文字的不同切片，候选数量很多，实际信息增量却很少。
还要把数据按问题类型切片，而不是只看平均分。平均 Recall 相同的两个模型，可能一个擅长普通问句却经常漏掉否定条款，另一个在专业缩写上更稳定。业务风险不同，模型选择也会不同。
工程指标同样不能缺席：单条 Query 编码延迟、并发下的 P95/P99、批量吞吐、CPU/GPU 占用、向量存储体积、索引构建时间和 API 成本。Embedding 会参与在线 Query 编码，也参与离线全量入库，这两类负载要分别测。
下面是一个只展示记录结构的评测伪代码，不是可以直接运行的项目实现。重点是保证每个模型读取同一批问题和同一份证据标注：
for model in embedding_candidates:
index = build_index(chunks, model=model)
for case in test_cases:
results = index.search(case.query, top_k=case.top_k)
record(
model=model.name,
case_id=case.id,
hit=contains_any(results, case.evidence_ids),
covered=count_covered(results, case.evidence_ids),
latency_ms=results.latency_ms,
)
这里记录的是事实：返回了哪些片段、覆盖了哪些证据、耗时多少。模型名称和结果版本也要进入日志，才能在出现 bad case 时复现。
Rerank 的评测前提，是固定同一批候选
Rerank 不能从候选集外创造证据。因此比较两个 Rerank 时，第一步不是直接看最终答案，而是确认粗召回候选里本来就有正确证据。对于候选缺失的问题，应归入召回失败，不应拿来评价重排模型。
在固定候选集上，可以看正确证据的首个排名、MRR、NDCG，或直接看它是否进入最终交给生成模型的前几条。若问题需要多段证据，还要看相关证据是否一起保留下来，不能只把其中一段排到第一就算完成。
同时记录输入截断。Rerank 通常把 Query 与候选拼在一起读取，候选过长时会发生截断。评测日志至少应保存原始长度、实际输入长度和截断方向，否则“模型把正确证据排低了”可能只是正确段落根本没有进入模型输入。
性能评测要覆盖单条、批量和并发。批量推理常能提升吞吐，但请求可能需要等待凑批，单请求尾延迟不一定下降。候选数量增加也可能提高证据排序的上限，却会线性放大打分次数。最终要在项目的延迟预算内比较质量，而不是把质量和成本拆成两个互不相关的表。
这里不需要重新展开 Cross-Encoder 为什么更慢，也不需要把 Top-N 设定成某个通用数字。面试回答的重点应放在：我怎样控制变量、怎样证明排序改善，以及当收益不足以覆盖延迟时如何退回较轻的方案。
什么时候该微调，什么时候只该修数据和链路
微调不是模型选型的默认下一步。一个 bad case 出现后，先检查证据是否正确解析、Chunk 是否切坏、正确片段是否入库、Query 是否被错误改写、过滤条件是否挡住结果。上游数据有问题时，用微调掩盖只会让错误更难解释。
只有满足以下条件，微调才有清晰目标：
- 通用模型在一类问题上持续、稳定失败，而不是偶发波动；
- 错误确实发生在语义匹配或候选排序层，不是解析、权限或索引问题；
- 已经有足够的人工确认正样本，以及“看起来很像但实际不回答”的难负样本；
- 有未参与训练的独立测试集，可以证明改进能够泛化；
- 团队能够承担训练、版本管理、部署、监控和回滚成本。
在训练与教学示例中，Embedding 微调可以用 Query、正确 Chunk 和负样本构成训练对。随机挑一个完全无关的片段作为负样本很容易，模型学不到细微边界；更有价值的难负样本来自当前系统高排名却被人工判定为不相关的片段。例如，它包含同一个产品名，却讲的是另一个流程；或者关键词重合很多，却是规则的相反条件。
Rerank 的训练也需要 Query、候选和标签，并应保留粗召回真实产生的混淆样本。用户点击日志可以提供线索，但“没点击”不等于“不相关”，点击还会受展示位置影响，不能未经校验就直接当标签。
微调后的验收不能只汇报一个总体分数。要同时比较通用问题是否退化、原 bad case 是否真正改善、难负样本是否被正确压低、延迟和资源是否变化。若只在训练相似问题上进步，却让其他问题变差，就不应直接上线。
上线时最容易漏掉的，是版本与迁移
Embedding 升级需要新旧索引并存一段时间。从工程实施角度，更稳妥的做法是：用新模型重算一份独立索引，跑完离线回归和数据完整性检查，再让少量或影子流量同时查询新旧链路，确认质量、延迟和资源符合预期，最后切换读流量。旧索引在回滚窗口结束前保留，不能覆盖式重建后才发现新模型有问题。
向量记录要带模型版本、维度、分块版本和文档版本。Query 缓存的键也应包含模型版本，否则模型更新后可能读取旧向量。在线服务若发现查询模型与索引模型不一致，应直接告警或拒绝混用，而不是悄悄返回看似正常的结果。
Rerank 上线则要关注分数漂移。新模型的相关性分数分布可能变化，基于旧分数设置的过滤阈值需要重新校准。若系统支持降级，可以在模型超时或资源过载时返回粗召回排序，但必须在日志中标记“未执行重排”，避免把降级结果混入正常模型评测。
一套最低限度的发布记录应包括：模型版本、运行时和量化方式、索引版本、测试集版本、离线结果、线上延迟、候选参数、切换时间和回滚入口。这样面试官问“模型升级后出了问题怎么办”，回答才不是一句“切回旧模型”。
四类 bad case，能检验你是否真的会选模型
第一类：同义表达找不到，但关键词检索能找到
先确认 Chunk 中确实包含答案，再对比多个 Embedding 的候选结果。如果问题集中在口语与正式术语映射，模型适配或难负样本可能有价值；如果文档本身解析缺失，换模型无效。
第二类：相关证据进入候选，却被相似的错误条款压住
这更接近 Rerank 的职责。要查看候选原文、截断位置和标签，而不是笼统说“Embedding 不行”。若多个 Rerank 都错，可能需要补充更贴近业务的难负样本。
第三类：离线指标提高，线上延迟和队列恶化
模型可能在固定小批量测试里表现很好，却在真实并发下产生排队。此时应把质量收益和 P95/P99、吞吐、显存峰值放到同一张决策表里，而不是只保留离线分数。
第四类：新模型整体更好，但关键风险问题退化
平均分会掩盖少数高风险类别。应按否定问题、权限相关问题、专业术语和多证据问题分别统计，并为关键集合设置发布门槛。只要关键类别退化到不可接受，就不能用平均提升覆盖过去。
面试官继续追问，怎么接
为什么不直接选公开榜单第一？
榜单用于筛候选，但项目里的语言、专业术语、Chunk 长度和部署约束不同。我会在自己的证据标注集上冻结其他变量做对比，并把召回、排序、延迟和迁移成本一起评估。
Embedding 和 Rerank 能不能只选同一家、同一系列？
可以作为候选，但没有必须绑定。两者任务不同，评测指标和运行成本也不同。是否组合使用要由同一条项目链路上的实验决定。
更换 Embedding 为什么通常要重建索引？
因为文档向量和查询向量必须来自同一编码空间。模型或向量维度变化后，旧文档向量不能默认与新查询向量直接比较，所以应建立版本化新索引并完成迁移。
什么时候才值得做领域微调？
当错误稳定发生在语义匹配或排序层，已经排除解析、分块和权限问题，并且有人工确认的正样本、难负样本与独立测试集时。没有这些条件，先修数据和评测体系更可靠。
为什么随机负样本不够？
完全无关的文本太容易区分，训练价值有限。当前检索高排名但实际不回答问题的片段，才暴露模型真正容易混淆的边界。
Rerank 评测为什么必须固定候选集？
否则候选变化和重排变化混在一起，无法判断收益来自哪里。Rerank 只能重新排列已经进入候选集的证据，不能补回未召回内容。
如果新模型效果更好但延迟超预算呢？
先确认收益集中在哪些问题，是否能通过候选控制、批量或较轻模型保留主要收益；如果仍超预算，就不应因为榜单或单一离线指标强行上线。
模型升级还会改变索引与分数语义。Embedding 维度、归一化方式或分词器变化时，旧向量通常不能与新查询向量混用；Rerank 版本变化也可能让原阈值失效。因此我会把模型、索引、阈值和评测报告绑定成一个发布版本，先建立新索引并做影子查询，再切换读流量。回滚时恢复整套版本，避免出现“模型回去了，索引没回去”的隐性错误。
影子验证还要同时记录新旧模型各自未召回与误排的样本，而不是只比较平均分。若新模型只改善常见问题，却让权限、否定或专业缩写类问题退化，就需要按风险切片决定是否上线。
Embedding 与 Rerank 选型，先固定候选再比较
我不会先从模型品牌开始，而是先拆清 Embedding 与 Rerank 的职责。Embedding 负责让正确证据进入候选集，我会看 Recall@K、证据覆盖、问题类型切片、编码延迟和重建索引成本；Rerank 负责候选内部排序，我会在固定候选集上看正确证据名次、MRR 或 NDCG、输入截断、批量与并发成本。
公开榜单只用来筛出候选。正式比较时，我会固定文档、分块、测试 Query、证据标注和检索参数，一次只改变一个模型，并保留 bad case。只有通用模型在专业术语、内部缩写或否定表达上稳定失败，而且已经有高质量正样本、难负样本和独立测试集，才考虑微调。
上线前还要处理模型版本、索引重建、缓存失效、分数阈值、影子验证和回滚。最终应选择能在当前知识库、风险类别和延迟预算下稳定提供正确证据，并且团队能维护和回退的组合；脱离这些约束谈“最强模型”没有项目决策价值。