Lakebase搜索实战：400万段落的容量规划经验

构建一个支撑400万段落检索的内部搜索系统，究竟需要多少资源？Databricks团队在开发内部应用Slide Hub时，完整经历了从原型验证到生产部署的全过程。Slide Hub服务于现场工程师，核心需求是快速查找和复用内部文档资料。当数据规模攀升至400万段落时，搜索系统的延迟、召回率和成本结构都发生了显著变化。本文基于Databricks工程团队的实践总结，拆解大规模搜索系统容量规划的关键决策与经验教训。

从Slide Hub看内部搜索的真实需求

Slide Hub的定位很明确：让现场工程师不必在成堆的文件夹和邮件中翻找，直接通过搜索定位可复用的技术方案和演示材料。这种内部工具的需求往往被低估——用户对搜索质量的容忍度远低于消费级产品，一次糟糕的检索结果就可能让他们放弃使用，回到手动翻找的老路。

在早期阶段，团队用较小规模的数据集验证了基本检索流程。但当文档库自然增长到400万段落量级时，原本够用的索引结构和查询策略开始暴露瓶颈。这个规模恰好处于一个微妙的区间：既不是百万级以下可以暴力扫描的小数据，也不是需要分布式集群的重型负载，但足以让容量规划失误的代价变得非常具体。

什么是"段落"（chunk/passage）级检索？ 在文档检索领域，直接对整篇文档建索引往往会导致检索粒度太粗——一篇长文档可能涵盖多个主题，整体嵌入后语义被稀释，命中后用户还得在文档里自行翻找。段落级检索将文档切分为数百字左右的片段（chunk），每个片段单独向量化并建立索引。这样做的好处是召回精度更高、返回结果可直接定位到具体内容，代价是索引条目数成倍膨胀——一篇几千字的文档可能被切成十几个段落，这正是Slide Hub数据量从"文档数"跃升到"400万段落"的原因，也是容量规划压力的直接来源。切分策略（固定长度、按标题、按语义边界）会显著影响召回质量与索引规模。

检索质量与延迟的平衡术

规模化搜索最棘手的部分在于，检索质量和响应延迟之间存在硬性约束。团队在Slide Hub上尝试了多种策略组合，发现向量检索在语义匹配上表现突出，但索引构建和查询开销随段落数增长呈非线性上升。

据Databricks工程博客的描述，当段落数达到400万时，简单的全量向量扫描已无法满足交互式搜索的延迟要求。团队必须在召回率、精确度和速度之间做出显式取舍。最终方案采用了分层检索策略——先用轻量级索引做候选筛选，再对候选集做精细排序。这种架构在保持可接受召回率的同时，将延迟控制在用户可感知的范围之内。

一个容易被忽视的教训是：搜索系统的容量规划不能只看存储和计算资源，用户对"够快"的心理预期同样是需要建模的硬约束。

分层检索（又称两阶段检索/召回-重排架构） 是当前大规模向量检索的主流范式。第一阶段用轻量级方法快速从全量语料中筛出候选集，常见手段包括倒排索引（BM25）加向量近似最近邻（ANN，如 HNSW、IVF-PQ）的混合召回，目标是在毫秒级内把候选缩到几十到几百条，此阶段牺牲部分精度换取速度。第二阶段对候选集用更重的模型（如交叉编码器 cross-encoder 重排）做精细打分，虽然单次计算成本高，但因候选量小，总开销可控。这种"粗筛+精排"的组合，使系统无需让昂贵的精确计算作用于全部400万段落，从而把 P95/P99 延迟压到交互可接受的范围。ANN 索引的核心权衡在于召回率与内存、构建时间的三角关系。

成本结构的隐性陷阱

400万段落规模下的搜索系统，成本大头往往不在查询本身，而在索引维护和更新管道上。Slide Hub团队发现，随着文档持续新增和修改，索引重建的频率和资源消耗成为运维负担的主要来源。

增量索引更新是缓解这一问题的关键手段，但它引入了索引一致性的复杂度。团队需要在"索引新鲜度"和"系统稳定性"之间找到平衡点：过于频繁的更新会推高资源消耗，更新间隔过长则会导致搜索结果滞后，影响用户体验。这种权衡在内部工具场景下尤为微妙——用户既期望搜到最新内容，又不会为搜索质量单独买单。

增量索引与索引一致性 是大规模检索系统运维中最容易被低估的环节。全量重建索引虽然逻辑简单、一致性有保证，但每次都要重新计算全部段落的向量，400万段落量级下这往往是小时级的批处理任务，资源消耗巨大且无法频繁执行。增量索引只对新入库或发生变化的文档做嵌入计算并追加到索引结构中，大幅降低更新成本，但引入了几个棘手问题：删除和更新旧段落时，ANN 索引（尤其是图结构的 HNSW）难以高效地做原地删除，通常采用"软删除+定期合并"的折中方案；同时，查询侧可能短暂读到新旧两个版本的段落，需要版本过滤或写时可见性控制来保证一致性。这些复杂度正是"新鲜度与稳定性"权衡的技术根源。

可复用的容量规划框架

从Slide Hub的实践中可以提炼出一套面向中等规模搜索系统的规划思路。第一，在原型阶段就要用接近真实分布的数据集做压力测试，合成数据的分布偏差会严重误导容量估算。第二，将检索质量指标（如召回率@K）和延迟指标（P95、P99）纳入同一评估框架，避免单维度优化导致的次优决策。第三，为索引更新管道预留独立的资源配额，不要让查询负载和索引维护争抢同一份计算资源。

Databricks团队的经验表明，400万段落级别的搜索系统并不需要过度工程化的分布式架构，但对细节的把握要求很高。选对检索策略、管好索引生命周期、控制住延迟尾部，比堆砌资源更能决定系统的实际可用性。对正在构建内部搜索工具的团队来说，Slide Hub的案例提供了一个务实的参照——规模不是问题，规模带来的隐性约束才是。

召回率@K 与 P95/P99 延迟 是评估检索系统的两个基础指标。召回率@K 指在前 K 个返回结果中包含相关文档的比例，K 通常取 5、10 或 20，它衡量的是"该找到的有没有找到"。延迟则不能只看平均值——平均值会被大量快查询拉低，掩盖少数用户遭遇的卡顿。P95 延迟表示95%的请求在此耗时以内完成，P99 则是99%的请求线，尾部延迟（tail latency）往往才是用户流失的真正原因：即便平均响应只有100毫秒，若每20次搜索就有一次卡顿2秒，体验就会被判定为"不稳定"。将召回率@K 与 P95/P99 放入同一评估框架，才能在调整切分粒度、索引参数或候选集大小时，避免"召回上去了但延迟崩了"的单维度次优决策。