多数知识库插件的文档只说「支持混合检索」不讲混合在哪一步发生、失败时退到哪一层。dsh-knowledge 的 README 把链路拆得较细Query Planner → 双路召回 → RRF 融合 → MMR 去冗余 → 可选 cross-encoder 重排 → Context Composer。这篇顺链走下去重点看两个最容易被误解的地方——RRF 为什么只融合名次以及「锚点续读」从哪里读。想看别的插件的实现形态可先参考 完整插件清单与汉化避坑指南。Query Planner主查询始终来自当前消息Query Planner 同时产出主查询和可选的查询变体。一条容易被忽略的规则主查询始终来自当前消息而不是拼接历史对话——既避免多轮历史把当前问题带偏也靠变体提高「换一种说法」时的召回覆盖率。多查询不是把变体拼成一个大查询而是先分别召回再统一融合。多查询的代价被压在最末端变体只在召回阶段展开到重排阶段最终只重排一次成本与延迟跟候选池大小相关而不随变体数量线性增长。自动检索的预算更紧首 Token 路径不启动本地 reranker远程 rerank 最多调用一次共享 4 秒总预算。双路召回词法走 FTS5向量走余弦词法路FTS5 trigram 与 CJK 二元组词法召回基于SQLite FTS5 trigram 索引排序用BM25查询侧识别CJK 二元组与拉丁词。它的价值是兜底无 embedding、模型未下载或远程服务不可用时仍可搜索。覆盖边界也清楚trigram 和 CJK 二元组本质是字面匹配中文同义不同词如「报销标准」与「差旅费用上限」大概率对不上。向量路先校验维度向量召回对查询做 embedding 后执行余弦检索执行前校验向量维度维度对不上说明模型和索引不配套报错比返回一堆乱序结果好。分块保存在独立 SQLite 文件knowledge-chunks.sqlite可用chunkStorePath调整词法检索用 FTS5 trigram向量用 Float32Array 常驻缓存并精确失效。目录来源以「知识库 规范化真实路径」确定身份遗留的重复树会报ambiguous_source——不猜测、不合并、不自动删除。RRF 融合只融合名次不混合量纲rankᵢ(d)是文档 d 在第 i 路召回里的名次wᵢ是这一路的权重向量路权重由rrfVectorWeight控制。关键在「只融合名次」。BM25 分数和 cosine 相似度是两套量纲前者理论上无上界后者在特定区间取值直接相加等于让其中一路隐性主导。换成倒数名次后第 1 名与第 2 名的差距固定与原始分数尺度无关。常数 60 与同分处理分母的 60 是平滑常数压低头部名次差距避免第 1 名吃掉全部候选。同分结果保留原召回顺序——同样的输入得到同样的输出顺序方便复现。MMR 与 rerank先减冗余再重排MMR在「相关度」与「和已选结果的向量相似度」之间取舍减少 Top K 里语义重复的片段。再往后是可选的 cross-encoder 重排可走远程 API 或本地模型——rerankModel: local:Xenova/bge-reranker-base就是本地写法它在另一个独立 child process中运行与 embedding process 的生命周期完全隔离。重排的降级语义失败、超时或分数无效时保留原始召回顺序是静默降级不是报错中断。rerank 必须返回与候选一一对应、有限且落在 [0, 1]的分数缺失、越界、数量不一致或协议不匹配都被视为降级而不是成功。搜索不会隐式下载 rerank 模型模型必须先在本地模型页下载并通过健康检查否则重排就是空转。所以「配置了 rerank」和「rerank 真的生效了」是两件事判断依据是召回测试里显示的重排状态。Context Composer 与锚点续读Context Composer 为每个命中动态生成有序的ContextWindow按before → anchor → after组织证据。桥接文本不会写入索引或 embedding只在组装时临时拼进来contextWindow默认不跨标题路径不会把相邻章节误当成本章节的延续。anchorChunkId 与 anchorIndex续读入口是knowledge_get_document支持chunkOffset/chunkLimit分页也支持用anchorChunkId或anchorIndex进入锚点模式可控before、after、maxTokens、focus、crossHeading。另外SearchHit.text始终保留完整的 canonical anchor超长锚点围绕命中位置按句子边界裁剪相邻 chunk 的重复前后缀会被移除。旧字段siblingContext在 0.3.x 继续兼容新调用方应优先用contextWindow。阈值只作用在可比分数上阈值只对可比较的 vector 或 rerank relevance 分数应用BM25 分数与 RRF 融合分不在其列。拿阈值去过滤 RRF 排名分数过滤掉的往往是你最想要的结果。总结这条链路的取向可概括成三句融合只比名次不比量纲所以 RRF 用倒数名次加权重重排宁可静默降级也不打断失败、超时、分数不合规都保留原始顺序证据只在组装时拼装桥接文本不入库。理解这三点召回测试里的「分数」「重排状态」才读得懂。想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。适合与不适合适合正在用 dsh-knowledge、想搞清召回顺序成因的人要调rrfVectorWeight、阈值或 MMR、需要知道各自作用范围的开发者基于anchorChunkId做二次开发的人需要解释「重排没生效但不是报错」的技术负责人。不适合只想照抄安装步骤、不关心内部机制的读者把 RRF 当成「分数加权平均」、以为调权重就能显著改变语义排序的人不愿先在本地模型页下载并做健康检查、却指望 rerank 自动生效的人资料高度依赖跨章节长距离语义关联、又只开词法路的场景。标签dsh-knowledge、DeepSeek Harness、混合检索、RRF 融合、检索机制本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。
拆开 dsh-knowledge 的检索链路，看 RRF 融合与锚点续读
多数知识库插件的文档只说「支持混合检索」不讲混合在哪一步发生、失败时退到哪一层。dsh-knowledge 的 README 把链路拆得较细Query Planner → 双路召回 → RRF 融合 → MMR 去冗余 → 可选 cross-encoder 重排 → Context Composer。这篇顺链走下去重点看两个最容易被误解的地方——RRF 为什么只融合名次以及「锚点续读」从哪里读。想看别的插件的实现形态可先参考 完整插件清单与汉化避坑指南。Query Planner主查询始终来自当前消息Query Planner 同时产出主查询和可选的查询变体。一条容易被忽略的规则主查询始终来自当前消息而不是拼接历史对话——既避免多轮历史把当前问题带偏也靠变体提高「换一种说法」时的召回覆盖率。多查询不是把变体拼成一个大查询而是先分别召回再统一融合。多查询的代价被压在最末端变体只在召回阶段展开到重排阶段最终只重排一次成本与延迟跟候选池大小相关而不随变体数量线性增长。自动检索的预算更紧首 Token 路径不启动本地 reranker远程 rerank 最多调用一次共享 4 秒总预算。双路召回词法走 FTS5向量走余弦词法路FTS5 trigram 与 CJK 二元组词法召回基于SQLite FTS5 trigram 索引排序用BM25查询侧识别CJK 二元组与拉丁词。它的价值是兜底无 embedding、模型未下载或远程服务不可用时仍可搜索。覆盖边界也清楚trigram 和 CJK 二元组本质是字面匹配中文同义不同词如「报销标准」与「差旅费用上限」大概率对不上。向量路先校验维度向量召回对查询做 embedding 后执行余弦检索执行前校验向量维度维度对不上说明模型和索引不配套报错比返回一堆乱序结果好。分块保存在独立 SQLite 文件knowledge-chunks.sqlite可用chunkStorePath调整词法检索用 FTS5 trigram向量用 Float32Array 常驻缓存并精确失效。目录来源以「知识库 规范化真实路径」确定身份遗留的重复树会报ambiguous_source——不猜测、不合并、不自动删除。RRF 融合只融合名次不混合量纲rankᵢ(d)是文档 d 在第 i 路召回里的名次wᵢ是这一路的权重向量路权重由rrfVectorWeight控制。关键在「只融合名次」。BM25 分数和 cosine 相似度是两套量纲前者理论上无上界后者在特定区间取值直接相加等于让其中一路隐性主导。换成倒数名次后第 1 名与第 2 名的差距固定与原始分数尺度无关。常数 60 与同分处理分母的 60 是平滑常数压低头部名次差距避免第 1 名吃掉全部候选。同分结果保留原召回顺序——同样的输入得到同样的输出顺序方便复现。MMR 与 rerank先减冗余再重排MMR在「相关度」与「和已选结果的向量相似度」之间取舍减少 Top K 里语义重复的片段。再往后是可选的 cross-encoder 重排可走远程 API 或本地模型——rerankModel: local:Xenova/bge-reranker-base就是本地写法它在另一个独立 child process中运行与 embedding process 的生命周期完全隔离。重排的降级语义失败、超时或分数无效时保留原始召回顺序是静默降级不是报错中断。rerank 必须返回与候选一一对应、有限且落在 [0, 1]的分数缺失、越界、数量不一致或协议不匹配都被视为降级而不是成功。搜索不会隐式下载 rerank 模型模型必须先在本地模型页下载并通过健康检查否则重排就是空转。所以「配置了 rerank」和「rerank 真的生效了」是两件事判断依据是召回测试里显示的重排状态。Context Composer 与锚点续读Context Composer 为每个命中动态生成有序的ContextWindow按before → anchor → after组织证据。桥接文本不会写入索引或 embedding只在组装时临时拼进来contextWindow默认不跨标题路径不会把相邻章节误当成本章节的延续。anchorChunkId 与 anchorIndex续读入口是knowledge_get_document支持chunkOffset/chunkLimit分页也支持用anchorChunkId或anchorIndex进入锚点模式可控before、after、maxTokens、focus、crossHeading。另外SearchHit.text始终保留完整的 canonical anchor超长锚点围绕命中位置按句子边界裁剪相邻 chunk 的重复前后缀会被移除。旧字段siblingContext在 0.3.x 继续兼容新调用方应优先用contextWindow。阈值只作用在可比分数上阈值只对可比较的 vector 或 rerank relevance 分数应用BM25 分数与 RRF 融合分不在其列。拿阈值去过滤 RRF 排名分数过滤掉的往往是你最想要的结果。总结这条链路的取向可概括成三句融合只比名次不比量纲所以 RRF 用倒数名次加权重重排宁可静默降级也不打断失败、超时、分数不合规都保留原始顺序证据只在组装时拼装桥接文本不入库。理解这三点召回测试里的「分数」「重排状态」才读得懂。想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。适合与不适合适合正在用 dsh-knowledge、想搞清召回顺序成因的人要调rrfVectorWeight、阈值或 MMR、需要知道各自作用范围的开发者基于anchorChunkId做二次开发的人需要解释「重排没生效但不是报错」的技术负责人。不适合只想照抄安装步骤、不关心内部机制的读者把 RRF 当成「分数加权平均」、以为调权重就能显著改变语义排序的人不愿先在本地模型页下载并做健康检查、却指望 rerank 自动生效的人资料高度依赖跨章节长距离语义关联、又只开词法路的场景。标签dsh-knowledge、DeepSeek Harness、混合检索、RRF 融合、检索机制本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。
