守株阁

上一篇把索引拆成了多个分片。分片解决了容量问题，但带来了新问题：一个分片进程挂了，那个分片上的文档就搜不到了。 本篇用只读副本实现读取冗余，用健康检查发现故障节点，用快照备份保证数据可恢复。目标：停一个进程后查询仍然可用（降级），从快照恢复后数据损失可量化（RPO/RTO）。 只读副本 为什么要副本 单个分片只有一个进程时： 进程挂了 → 该分片所有文档不可搜索 升级或重启 → 搜索服务中断 副本让同一个分片的数据存在于多个进程上。主节点负责写入，副本负责查询。 基于已提交快照的同步 主节点 writer.commit() 后，副本从共享目录打开新的 reader： 123456789101112131415161718192021222324252627282930class PrimaryNode { private final IndexWriter writer; private final Path indexDir; void indexAndCommit(Document doc) throws IOException {...

单机索引有容量天花板。内存装不下全部 HNSW 向量时，要么做量化压缩（第 22 篇），要么把索引拆到多个进程上。量化只能压缩 4 倍，而索引拆分没有理论上限。 本篇把索引拆成多个分片，用 scatter/gather 模式分发查询，在 coordinator 上合并全局 Top-K。重点处理分片内 BM25 统计偏差和跨分片评分可比性。 为什么要分片 单机瓶颈 文档数 倒排索引 HNSW(int8) Stored fields 合计 10K 50 MB 23 MB 20 MB ~93 MB 100K 500 MB 230 MB 200 MB ~930 MB 1M 5 GB 2.3 GB 2 GB ~9.3 GB 10M 50 GB 23 GB 20 GB ~93 GB 10M 文档需要 93 GB 内存——超出大多数单机配置。即使装得下，查询延迟也随文档数增长。 分片的收益 将 10M 文档拆成 10 个分片，每个分片 1M 文档： 每个分片只需 ~9.3 GB 内存 查询延迟接近 1M 文档的水平（各分片并行执行） 单个分片故障不影响其他分...

到目前为止，索引中的文档是一次性灌入的。真实搜索引擎的内容不断变化——新页面发布、旧页面修改、过期页面删除。搜索引擎需要持续追踪这些变化，保持索引的新鲜度。 本篇实现持续采集系统：条件请求避免无谓下载，自适应调度控制抓取节奏，有界队列和背压防止资源耗尽，幂等写入保证重试安全，状态持久化保证重启不丢进度。 条件请求 HTTP 条件请求机制 HTTP 协议内置了条件请求机制，避免重复下载未变化的内容。 Last-Modified / If-Modified-Since： 123456789101112131415161718192021222324record CrawlMetadata( String url, String etag, String lastModified, long lastCrawledAt, int consecutiveNotModified, int consecutive404) {}HttpResponse<String> conditionalFetch(CrawlMetada...

搜索系统的各阶段——查询解析、BM25 召回、向量召回、融合、重排——性能特征各不相同。不做测量就不知道瓶颈在哪里，不知道瓶颈就无法有效优化。 本篇为搜索请求建立端到端的性能剖面，用冷热缓存压测暴露真实延迟，用容量账本规划资源预算。 阶段计时 SearchTrace 一个贯穿请求生命周期的计时器，记录每个阶段的耗时： 12345678910111213141516171819202122232425class SearchTrace { private final long requestStartNanos = System.nanoTime(); private final Map<String, Long> stageStartNanos = new LinkedHashMap<>(); private final Map<String, Long> stageDurationMicros = new LinkedHashMap<>(); void stageStart(String sta...

embedding 模型会升级。Qwen3-Embedding-0.6B 今天够用，明天可能被更大或更准的版本替代。新模型产生的向量与旧模型不在同一空间——余弦相似度失去意义。 本篇解决一个工程问题：在不中断服务的前提下，用新模型重建整个向量索引，验证质量，原子切换，并在出问题时回滚。 为什么不能直接替换模型 向量空间不兼容 不同 embedding 模型（即使同一系列的不同版本）学到的向量空间不同。用模型 A 编码的文档向量和用模型 B 编码的查询向量做余弦相似度，结果无意义。 1234模型 A 空间: "搜索引擎" → [0.12, -0.34, 0.56, ...]模型 B 空间: "搜索引擎" → [0.78, 0.11, -0.22, ...]cosine(A_doc, B_query) = 无意义的数字 混用两个版本的向量等于在两套不同的坐标系之间算距离。 必须全量重建 局部替换不可行。如果只用新模型编码新文档，索引里就同时存在两个空间的向量。查询时无论用哪个模型编码查询，都只能正确匹配一半文档。 唯一正确的做法：用新模型对全...

第 18-19 篇用 float32 向量做 HNSW 搜索。512 维 float32 = 2KB/向量。1 万个 chunk 占 20 MB，尚可接受。但向量数增长到百万级时，内存开销达到 GB 级别——单机装不下，或者装得下但挤占了其他组件的内存预算。 本篇用量化减小向量体积，用缓存和批处理降低 embedding 推理的调用成本。 向量存储的成本账 内存占用 512 维 float32 向量的存储开销： 向量数 原始向量 含 HNSW 图 备注 10K 20 MB ~30 MB 教学语料 100K 200 MB ~300 MB 中等站点 1M 2 GB ~3 GB 大型站点 10M 20 GB ~30 GB 超出单机内存 HNSW 图的边（每节点 M 个邻居 × int32 node ID）增加约 50% 的额外开销。 推理成本 每次查询需要调用 embedding 服务编码查询文本。每次文档写入需要编码 chunk 文本。 操作 延迟（GPU） 延迟（CPU） 编码 1 条文本 ~5 ms ~50 ms 编码 100 ...

上一篇用 RRF 将 BM25 和向量检索的结果合并为一个排名。但 RRF 的融合依据只有排名位置——它不知道候选文档和查询的实际匹配程度。一篇排在 BM25 第 2 名的文档可能因为标题恰好包含查询词而得分高，但正文和查询主题完全无关。 本篇引入重排序模型（reranker），对 RRF 返回的 Top-N 候选逐一做精细评分，找出真正最相关的文档。 二阶段检索 为什么不用 reranker 做全量搜索 Cross-encoder reranker 对每个 (query, document) pair 做联合编码——query 和 document 的每个 token 之间做 full attention。这比 bi-encoder（第 18 篇）精确得多，但也慢得多。 方法 1 万文档耗时 10 万文档耗时 BM25 ~5 ms ~20 ms 向量 HNSW ~5 ms ~10 ms Cross-encoder ~5 s ~50 s Cross-encoder 对每个候选都要过一遍完整的 Transformer 前向传播。对 1 万文档逐个打分需...

BM25 擅长精确标识符和稀有术语，向量检索擅长语义匹配和跨语言。单独使用任何一种都会在对方擅长的查询类型上表现不佳。本篇把两路召回的结果合并为一个排名——混合检索。 两路召回各有盲区 在第 16 篇的评测集上分别运行 BM25 和向量检索，按查询类型统计 nDCG@10： 查询类型 BM25 向量检索 差距 精确标识符 高 低 BM25 胜出，向量空间对标识符区分度差 概念查询 中 高 向量胜出，语义匹配覆盖同义表达 中英混合 中 中高 向量稍好，跨语言 embedding 有优势 同义改写 低 高 向量大幅胜出 多条件 中 中 各有优劣 无答案 好 差 BM25 正确返回零结果，向量总会返回"最近"的 没有一路在所有类型上都最优。混合检索的目标：在每种类型上至少达到两路中较好的那个。 Reciprocal Rank Fusion 为什么不直接加分数 BM25 分数通常在 0-30 之间，向量相似度在 0-1 之间。直接加权求和 α × BM25 + β × cosine 有三个问题： 量纲不同——需要归一化，但归...

上一篇用精确扫描完成了向量检索的基线。精确扫描遍历所有向量计算点积，结果是精确的，但复杂度 O(N×D) 不可扩展。1 万个 chunk 只需 5 毫秒，10 万就要 50 毫秒，100 万要半秒——远超搜索服务的延迟预算。 本篇引入 HNSW（Hierarchical Navigable Small World），一种基于图的近似最近邻算法。Lucene 10.x 内置 HNSW 实现，可以直接通过 KnnFloatVectorField 使用。 为什么需要近似搜索 精确最近邻搜索保证找到真正最近的 K 个向量，但时间复杂度是线性的。搜索服务的延迟预算通常在 50 毫秒以内（整个搜索流程，不只是向量检索），线性扫描在大规模数据上无法满足。 近似最近邻（ANN）牺牲少量精度换取数量级的速度提升。具体来说：精确 Top-10 中的某些结果可能在 ANN 的 Top-10 中排到了第 11 或第 12——被遗漏了。但 ANN 返回的 Top-10 中 95% 以上是正确的，搜索质量几乎无损。 HNSW 的分层图结构 灵感来源：跳表 回忆第 11 篇的跳表：底层是完整链表，上层是稀疏...

前面十七篇的检索全靠词汇匹配——查询和文档必须共享相同的 term 才能产生分数。搜索"如何提高程序运行速度"，如果文档里写的是"性能优化"，BM25 给出的分数是零。同义词表能覆盖一部分，但不可能穷举所有语义等价关系。 本篇引入向量检索：用 embedding 模型将文本编码为高维向量，在向量空间中用距离衡量语义相似度。先做精确扫描建立基线，下一篇再用 HNSW 加速。 从词汇匹配到语义匹配 BM25 的语义鸿沟 查询 相关文档包含 BM25 匹配 “如何提高程序运行速度” “性能优化最佳实践” 零分——没有共同 term “machine learning” “机器学习入门” 零分——跨语言 “数据库挂了怎么办” “MySQL 故障恢复指南” 低分——只有"数据库"模糊相关 同义词表（第 16 篇）缓解了一部分问题，但维护成本高，且无法覆盖所有隐含的语义关系。 向量空间的思路 将文本映射为 D 维向量（D 通常是 512 或 1024）。映射由 embedding 模型完成——模型在大量...