Dify 混合检索与重排序：知识库答不准时先查哪一层

知识库回答不准确，不能下意识就提高召回数量或更换模型。一个问题要经历查询表达、过滤、关键词与向量召回、候选合并、重排序、上下文拼装和生成，任何一层都可能丢失证据。混合检索和重排序只解决其中一部分：前者扩展候选来源，后者重新判断相关性。实施前先保留每层结果，才能避免靠调参碰运气。

判断这个场景是否适合

混合检索适合同时存在精确词和语义表达的资料。产品编号、法规条款、错误码和人名需要关键词命中，用户口语、同义词与描述性问题更依赖向量。若资料规模很小、标题清楚，简单关键词可能已经足够；若文档解析错误或目标内容根本没有入库，增加检索方式也不会创造正确证据。

重排序适合初始召回能找到目标片段，但目标常排在后面或被相似却无关的段落挤掉。判断依据应来自标注问题集：记录目标片段是否进入候选、所在位置和最终选择，而不是只看回答听起来是否顺畅。候选中完全没有目标时，应修正切分、元数据过滤、查询或召回；目标已居前却仍答错时，排查上下文拼装与生成指令。

还需评估延迟、成本与依赖。混合检索会带来合并与去重，重排序增加一次模型或服务调用。在响应时间严格、网络不稳定或请求量较大的入口，应先测真实文档长度下的尾部延迟，并准备不经过重排序的降级路径。涉及部门权限时，过滤必须在召回前可靠执行，不能指望排序器把无权内容放到后面。

实施时怎么拆

先建立最小诊断记录。每个测试问题保存原始查询、改写查询、过滤条件、各路候选的片段标识与分数、合并结果、重排结果、送入模型的上下文和最终引用。业务审核人标记目标证据、可接受证据、干扰片段和应拒答情况。这样一次失败可以定位到具体层，而不是笼统归因于 RAG。

配置混合检索时，先分别运行关键词和向量基线。检查关键词分词是否保留编号与缩写，向量是否能覆盖同义表达。合并要按片段标识去重，并避免同一文档的相邻重复片段占满候选。权重调整依据问题类型分组：编号查询、概念解释、故障描述和跨章节查询可能需要不同策略，不能用一组总体平均掩盖某类明显退化。

加入重排序后，比较目标片段的名次变化、错误干扰是否上升以及额外耗时。候选数量不是越大越好，过多内容会增加排序负担，也可能把弱相关段落带入上下文。上线配置要固定模型或服务版本、超时和最大候选，并定义失败处置：重排序超时就使用合并结果，检索服务异常则提示暂不可查，不允许无证据自由回答。

发布时采用可切换配置，保留旧检索策略。先让内部人员在影子流量中对比引用，再逐步开放。人工确认重点不是偏好哪个答案，而是证据是否来自有效版本、是否完整支持结论、是否越权。若新策略在关键问题上漏召回、延迟突破业务上限或依赖频繁失败，立即切回旧配置，再用记录离线排查。

不要忽略的限制

不同检索分数通常不可直接比较，合并前要理解各自含义；重排序分数也不代表事实正确，只表示候选与查询的相关判断。短问题存在歧义时，最好的改进可能是追问用户，而不是强行选一个高分片段。跨文档推理还需验证多个证据能否同时进入上下文，并在回答中分别引用。

评测集会随着内容和用户表达变化而老化。应保留线上失败样本，经脱敏和人工确认后加入回归，但不能直接把用户输入当正确标签。索引、嵌入模型或排序器变化都要单独发布，避免同时改多层导致无法归因。回滚包至少包含旧数据集引用、检索配置、重排开关和测试结果；恢复后重新跑关键问题，确认不是只恢复了页面设置。

参考资料

• Dify 官方文档