Context Mode
阅读 Context Mode 搜索源码：RRF 融合、重排与空结果回退
追踪两个词法匹配器、排名融合键、有界重排及有条件模糊重试，不把实际实现误写成通用向量搜索。
你将学会
- RRF 累加 Porter 与 trigram 列表的位置贡献。
- 邻近性重排发生在有界截取之后。
- 初次过滤融合为空才会尝试模糊重试。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- RRF 累加 Porter 与 trigram 列表的位置贡献。
- 邻近性重排发生在有界截取之后。
- 初次过滤融合为空才会尝试模糊重试。
两个匹配器贡献基于位置的分数
ContentStore 的私有 rrfSearch 方法以 OR 模式请求 Porter 和 trigram 结果，候选数至少为十，或传入上限的两倍。每个匹配器按排名位置贡献倒数分数，常量为六十：第一名贡献 1/61，第二名贡献 1/62。两个列表都找到的项会累计贡献。这是列表位置度量，不是校准后的正确概率。
融合 Map 用 source 与 title 拼接标识一个项，而不是用唯一块行 ID。这给重复标题文档提供了明确审查方向：检查多个块是否共享该身份，以及融合后如何展示。本章指出键的语义，但没有宣称已经复现数据丢失缺陷，也没有声称执行过完整数据库管线。
过滤与重排的先后顺序很重要
searchWithFallback 查询前会刷新过期文件来源。启用会话允许集合时，它请求更大的有界候选池，应用会话过滤，将存活融合结果截到请求上限，然后才做邻近性重排。这个顺序意味着重排无法提升已被截掉的候选。提高候选预算与改变最终上限，是不同实验。
重排器结合标题命中、包含查询词的最紧跨度，以及有上限的短语频次信号；先按增强值排序，再参考原排名。代码形态块的标题权重高于正文形态块。不要把这些值全部统称为 BM25 分数，应记录匹配层，并通过样例观察究竟哪一步改变了顺序。
模糊纠错有条件，并非每次都追加投票
经过过滤的融合搜索只要有结果，函数就立即返回，并标记 rrf。只有空结果才进入词语纠错和第二次融合搜索。纠错成功结果标为 rrf-fuzzy，否则返回空数组。因此，一个较弱的初始匹配也可能让纠错不被尝试。应把这个情况与初次完全无匹配的拼写错误分开测试。
小段代码只计算位置贡献，是编辑编写的算术样例，不是 ContentStore 替代品，也不能证明 SQLite、词干处理、查询清理和权限整体有效。继续研究时应结合 store-bytecap 测试与检索测试：在任何排名公式运行前，块大小和边界就可能改变候选集合。
实施步骤
- 1
追踪 rrfSearch 及其 source/title 键。
- 2
按过滤、截取、重排的顺序阅读。
- 3
比较重复标题与唯一标题样例。
- 4
分别测试空结果拼写错误与较弱非空匹配。
可复制示例
// 编辑算术样例，不是上游搜索运行时。
const contribution = position => 1 / (60 + position);
console.log(contribution(1));
console.log(contribution(2) + contribution(2));常见问题
RRF 值高就表示答案正确吗？
不是。它衡量排名列表之间的共同支持，不是事实正确性或置信度。
拼写纠错会改进每个弱结果吗？
所查路径仅在初次过滤后的融合结果为空时，才尝试纠错重试。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07