16｜检索在线链路：召回、融合、重排与证据充足性

术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。

在线阶段的目标不是“找出看起来最像问题的五段话”，而是找到足以支持当前结论或行动的证据。相关性、完整性、时效和可用性必须分别检查。

继续看相关机制：F28 · 检索先找候选，再判断能否回答F35 · 读指标，先问它的分母是谁F37 · 资料能影响模型，不代表获得了权限

Q061｜BM25与向量检索怎样融合？RRF为什么不直接相加原始分数？

核心回答

不同检索器的分数尺度不一致，直接相加可能让一个检索器主导。RRF根据候选在各榜单中的名次累加1/(k+rank)，减少对原始分数标度的依赖。它是一种排序融合方法，不是概率校准。[RRF]

算一个三文档例子

BM25排序为A、B、C，向量排序为B、C、A。取常数k=60：

A = 1/(60+1) + 1/(60+3) = 0.03226646
B = 1/(60+2) + 1/(60+1) = 0.03252247
C = 1/(60+3) + 1/(60+2) = 0.03200205

融合后B第一。这里B不是任一单榜都第二，而是一个榜第一、另一个榜第二，因此获得一致支持。k较大时名次差异更平缓，较小时顶端名次更重要。未出现在某榜的候选一般不获得该榜贡献，具体实现还可能有权重和窗口大小。

融合前要按稳定文档/块身份去重。若同一段内容以三个不同chunk ID出现，可能占满候选；若只按文本去重，又可能误合并不同版本或不同权限的相同文字。身份、版本与内容相似度应分别处理。

追问：为什么融合后仍可能比单一路径差？

一个低质量检索器会引入噪声；两个检索器也可能高度相关，增加的不是独立信息。候选窗口、权重和去重方式影响结果。应做BM25-only、dense-only、fusion的消融，而不是假定hybrid必然更好。

追问：查询改写在融合之前还是之后？

通常在召回前生成不同查询，再得到多个候选榜；但改写要保留原始精确键和用户约束。对问题“不能重试哪些写操作”，改写成“重试机制”可能漏掉否定条件。保留原查询路径能降低改写漂移风险。

追问：Top-k越大是否越不容易遗漏？

召回集合通常增大，但后续上下文预算固定，更多噪声可能挤掉关键证据，也增加rerank与模型成本。应区分召回k、重排k和最终阅读k，并通过任务质量选择，而不是统一设置一个大数字。

Q062｜Cross-encoder Reranker和ColBERT为什么比简单余弦更细？

核心回答

双塔检索把query和doc独立压成向量，便于全库搜索；cross-encoder把query与候选文档联合编码，能做细粒度交互，但每个候选都要计算。ColBERT保留Token级表示，通过late interaction在效率和精细匹配之间折中。[DPR][COLBERT]

比较三种信息交互位置

双塔：q→q_vec，d→d_vec，最后一个点积。文档预计算成本低，但许多细节已被压进单向量。Cross-encoder：[query,document]→联合模型→相关性分数，query词能与文档不同位置交互，更容易检查“旧版本/禁止/例外”等，但不适合直接对百万文档逐篇运行。

ColBERT的简化MaxSim评分是：对每个query Token向量q_i，在文档Token向量d_j里找最大相似度，再对query Token求和：score=Σ_i max_j q_i·d_j。这样保留多点匹配，文档Token向量可离线计算。代价是存储和索引比单向量更大，且MaxSim本身仍不是事实推理器。

工程管线常先廉价召回若干候选，再用reranker筛选较小集合，最后读取原文必要范围。重排输入也应先做权限过滤，不能把敏感候选发给一个未获授权的外部服务。

追问：Reranker能找回召回阶段漏掉的文档吗？

不能从不存在的候选中选中正确文档。它改善排序，不直接扩大全库召回。若正确证据根本没进入候选，应修复切块、查询、索引或召回，而不是换更强reranker。

追问：Reranker分数0.9就是90%相关吗？

通常不能这样解释。模型输出可能是logit或未校准分值；训练分布、候选来源和领域变化都会影响尺度。若需要阈值，应用标注数据校准，并在变更模型或索引后复核。

追问：为什么相邻片段要在重排后扩展？

重排小片段能更准确定位，但完整答案可能需要标题、前置条件和后一段例外。扩展后要重新去重并检查预算。如果所有候选扩成整篇文档，仍会失去检索聚焦的收益。

Q063｜检索到了相关资料，如何判断已经足够回答？引用怎样与结论绑定？

核心回答

把用户问题拆成需要支持的声明或行动条件，逐项检查证据是否直接、当前、完整且允许使用。相关片段存在不等于全部问题已得到回答；引用链接存在也不等于它支持旁边的结论。

一个“是否可自动重试”的证据表

问题包含三个子条件：接口是否幂等、当前版本默认重试行为、生产环境是否允许自动重试。文档A只说明接口幂等，配置B说明重试三次，权限策略C说明生产写操作需批准。缺C时不能推导“可以自动重试生产写操作”。

教学证据表可记录：claim、evidence_id、support_type、version、missing_condition。support_type区分直接支持、间接推断、矛盾和无证据。最终回答中的事实句应绑定支持它的来源；推断明确标注，并说明依据。原始文档没有说的内容，不得因“很合理”而写成已确认。

多文档冲突先查是否不同版本、不同环境、不同日期或不同定义，而不是立即投票。两个转载不是两份独立证据；一个配置值与一份设计意图也不一定矛盾，可能是实现偏离设计。回答应保留这些差别。

追问：为什么“只根据提供资料回答”仍可能产生幻觉？

模型可能用背景知识补空缺，误连因果、忽略否定或引用错误。Prompt是约束，不是证明器。需要充分证据、允许缺失状态、关键断言检查和适当确定性验证；对代码行为可运行测试，对数值可重新计算。

追问：资料不足时是继续搜索还是停止？

看缺口是否可通过已授权来源补齐，以及搜索的边际价值。能明确定位配置就继续读；没有权限或来源不存在应说明边界。无限搜索会增加成本并可能捡到低质量支持，不能为得到肯定答案而搜索到满意为止。

追问：如何评估引用质量？

至少检查引用存在、目标可访问、范围正确、内容支持声明、版本适用。可以用自动规则加模型辅助判定，但高风险声明需人工或确定性核验。引用数量多不是质量高，最小充分支持更易审查。

Q064｜HyDE、RAPTOR、GraphRAG、Self-RAG分别解决哪个失败环节？什么时候不该用？

核心回答

这些方法针对不同问题：HyDE改善查询表达与文档空间的匹配；RAPTOR构造层次摘要检索；GraphRAG利用实体关系与社区摘要回答全局问题；Self-RAG把检索与自我评价纳入模型行为；Corrective RAG关注检索质量评估和纠正。它们不是必须全部串联的标准生产管线。[HYDE][RAPTOR][GRAPHRAG][SELFRAG][CRAG]

用故障类型选择，而不是背名称

用户只有一句模糊问题、语料却是详细技术叙述，HyDE先生成假设文档再编码，可能缩小表达差距。假设文档允许包含不真实细节，因此只能作为检索线索，不能引用为证据。若查询已有精确错误码，生成一段假设内容反而可能稀释它。

需要理解长文档多个层次时，RAPTOR递归聚类和摘要形成树，查询可命中不同抽象层。摘要便于跨段概览，但更新源文档需要更新派生结构，摘要错误可能传递。精确查一个函数参数时，直接源码检索通常更简单。

面向“整个资料集有哪些主要趋势”这种全局归纳，GraphRAG的实体关系与社区摘要可能比几个局部Top-k片段更合适。代价是抽取、实体消歧、关系错误、建索引成本和更新复杂度。它不是把所有文本变成图后就自动得到因果知识。

Self-RAG原始研究包含训练与反思标记等机制，不等同于在任意模型后追加一句“请检查”。Corrective RAG也需要质量判断组件；若这个判断本身不可靠，可能触发无意义网络搜索或错误丢弃好证据。

追问：如何验证一种高级RAG方案有实际收益？

先按问题类型建立测试集：精确事实、跨段、跨文档、全局归纳、时效冲突。与简单baseline在同预算下对照，分别看召回、答案正确、引用支持、延迟和建库成本。不能只用最适合新方法的题型评价全系统。

追问：图里的关系可以直接当业务规则执行吗？

不能。LLM抽取的关系可能缺少条件、时间或否定；“A提到B”不是“A依赖B”，更不是“A导致B”。执行规则应有明确权威证据和验证，图用于导航与候选关联更稳妥。

追问：为什么基础检索做不好时不宜立刻上复杂框架？

解析丢信息、权限错、索引旧的问题会被复杂管线继承并放大。先保证原文、元数据、精确检索和简单混合检索可用，再针对剩余具体失败引入新机制。方法名字不能代替故障定位。