重排器微调零提升，实验能说明什么

微调跑完、权重变了、模型也能重新加载，能不能证明 RAG 变好了？作者做了一次小实验，答案是：不能。合成留出集只有 3 个问题，其中 2 个可回答；原始与微调后的重排器，在这 2 题上的 nDCG@5 都是 1.0，排名收益为零。

这篇值得读的地方，是它把「代码跑通」「训练发生」和「业务有效」分开了。对正在给知识库问答接检索、加重排、做微调的程序员，这比一张漂亮的训练曲线更有参考价值。

先说清楚，你到底微调了哪个组件

RAG 的回答质量涉及几道工序：检索负责找候选材料，重排负责调整候选顺序，生成模型根据选中的上下文组织答案。任何一步出错，都可能让最终回答失真。

作者只调整了一个预训练的多语言交叉编码器（cross-encoder），也就是重排器。它把问题和候选段落一起输入模型，判断两者的相关程度。嵌入模型和答案生成模型保持固定，实验没有微调负责写答案的语言模型。

作者设置了四组比较：

• A 不接检索，用来与接入检索的 B 比较。
• B 接入检索，用来与增加预训练重排器的 C 比较。
• C 使用预训练重排器，是微调效果的直接基线。
• D 使用调整过权重的重排器，与 C 比较。

混合检索最多返回 20 个候选，C 和 D 必须处理同一批材料，包括候选中根本没有正确材料的情况。只给其中一组塞入标准答案段落，会破坏比较条件。

生成端也要固定。作者把提示词、聊天模板版本、解码设置都纳入生成器身份，并关闭了 thinking。否则，回答变化可能来自提示词，而非重排权重。

这里有一处信息缺口：提供的原文在引出具体模型身份后，没有列出名称和版本，因此无法据此确认用了哪些模型。作者明确报告的是官方权重已下载并在本地 CPU 上运行，没有经核验的 CUDA 执行结果。

权重更新，只能证明训练确实发生了

合成训练集包含 40 对样本，作者分别使用 42、314、2026 三个随机种子，各训练 1 个 epoch，有效批大小为 16。

验证并不止于命令执行成功。作者检查了权重实际发生变化、保存的权重属于预期检查点，以及独立重新加载后能否得到预期预测。这些检查能抓出模型被冻结、保存错状态、重新加载了原始权重等实现错误。

训练发生了，不等于学到了对任务有用的东西。

结果要分两份看。合成验证集有 3 个可回答问题，调整前后的 nDCG@5 都约为 0.6667；另行封存的合成留出集有 3 题，其中 2 题可回答、1 题不可回答，两个重排器在可回答题上的 nDCG@5 都是 1.0。这是不同数据上的结果，分母和分数不能混用。

nDCG@5 衡量前 5 个结果的排序质量，越接近 1，越接近理想顺序。留出集上的原始模型已经满分，这个指标自然没有展示提升的空间。但两道题也远不足以证明原始模型已经适合上线。

三个训练种子同样不能把两道评估题变成六个独立样本。种子观察的是训练随机性，题目变化观察的是不同输入下的表现。

作者还冻结了语料、数据划分、配置、模型身份和实际权重哈希，并在推理前核验。一次性执行凭据与冻结记录关联：相同输入的已完成请求返回保存且经过哈希校验的结果；中断和输入变化也留下记录，减少反复试测后挑选结果的空间。

这套机制能约束流程，但无法阻止本地操作者同时修改全部文件。真实实验还要求只用验证集选择检查点，保留三个种子的验证结果，并在查看测试结果前确定最终比较方案。

检索满分，答案仍然可能胡说

四个变体对三道留出题共生成 12 个答案，但作者尚未完成这些答案的人工质量评估。因此，当前没有证据说明生成答案更准确、更有用。

作者把评估分成三层。

第一层是检索相关性，使用 Recall@20、MRR@5 和 nDCG@5，分别观察召回覆盖、首个相关结果的位置和排序质量。这些指标只统计可回答问题。不可回答题的检索指标记为 null，单独计数，因为不存在的相关段落无法被召回。

第二层是引用完整性：引用标识是否存在，是否属于允许使用的上下文。这能查出虚构来源，却无法判断来源是否支持回答中的具体断言。

原文用下面这个虚构例子说明两者的差别：

Source: "This material supports engraving. Delivery timing depends
on the order and must be confirmed separately."

Answer: "Engraving is available, and delivery takes two days. [S1]"

要看的是 Answer 中的 delivery takes two days：来源只说交付时间需要另行确认，并没有承诺两天。即使 [S1] 有效，引用解析器通过检查，这个交付结论仍然没有依据。

第三层才是人工事实与实用性审查：回答是否得到材料支持，引用是否正确，是否有用，以及该追问或转人工时有没有做对。作者准备了打乱分组和答案顺序的盲审材料，未审评分保持待完成，也不让生成器自己批准自己的事实正确性。

真实语料仍处于准备阶段。事实来源已经审阅、索引已经建立，相关性标注还在进行。接下来需要正例段落、合适的负例、明确的可回答性和隐私审查。

等价问题也不能随意分到训练集和测试集两边。作者计划先把关联客户、对话和近重复问题分组，再划分数据；复用标注可以省工，但复用的判断不是独立证据。事实来源获准使用，也不代表相关对话自动通过隐私审查。

我的判断

我认同作者对证据边界的处理。检查权重、保存和重载，解决的是实现可信度；固定候选和生成配置，解决的是比较是否公平。两者都是必要工作，但都不能替代效果验证。

当前结果支持「实验管线能运行」，不支持「微调让 RAG 更好」。

不过，「零收益」也不能被解释成微调无效。留出集只有两个可回答问题，而且基线已经满分，这个测试对改进的区分能力很弱。它能支持的决定更窄：暂时没有理由因为测得收益而保留微调组件。

与直接比较最终答案相比，隔离重排器更容易定位差异；但最终是否值得上线，还需要回到答案质量和运行成本。作者计划加入相近产品尺寸、材质与雕刻混淆、事实冲突、价格或交期缺失、模糊请求及提示注入等难例，也准备区分加载时间与预热后的推理时间。这些目前是后续方案，没有对照数据，不能当成已经验证的收益。

公开材料的能力也有限。原文说案例仓库没有导出训练包、检查点、私有来源和逐条预测；聚合检查器只能核验统计数字的算术关系，不能重跑训练，也不能独立证明答案质量。

能拿来做什么

• 给知识库问答增加重排器时，先固定检索候选、提示词和生成设置，比较预训练与微调版本。若正确段落根本没被召回，优先排查检索环节。
• 在 Node 或其他服务端评估脚本中，将检索指标、引用合法性和人工事实评分分别记录。不可回答题单独统计，不要让一次引用检查通过代替答案验收。
• 微调后检查权重更新、检查点保存和独立重载，再用验证集选择版本。不要查看测试结果后挑种子，否则测试集也参与了选择。
• 扩充评估集时，优先补充容易混淆、信息缺失和应当转人工的问题，并把近重复问题放在同一划分中。上线判断同时看失败类别、答案质量与实测耗时。