检索与一致性：把写路径和索引接成读路径

前三章是零件，这一章是装配。读路径不是一个新机制，而是 01 的“没有整表大索引、每段各建索引”和 02 的“proxy 无状态、segment 是统一调度单元”两条事实的直接推论。把这条推论走完，一致性、过滤、归并代价就都落到同一张图上。代码片段只用来让概念落地，未在本机运行。

4.1读路径：一次 search 的扇出与归并

一次检索 = 把查询广播到所有相关 segment、各跑一次检索、再分两级把结果归并成最终 top-k。

比文档深一层的机制：一次 search 落到无状态的 proxy（02 §2.2 的入口），proxy 把它扇出到两类执行者——流式节点负责本分片的 growing 段（还没 sealed、没索引，只能暴力扫，回指 01 §1.4），query node 负责已加载的 sealed 段（走 03 的向量索引）。每个 segment 各自独立跑一次检索，吐出自己的局部 top-k。然后归并分两级：每个分片内部先 reduce，把该分片下所有 segment 的局部 top-k 合并成分片级 top-k；proxy 再跨分片 merge，把各分片结果合成全局 top-k 返回。proxy 做最终跨分片归并这件事来自 02 §2.2——proxy 无状态，归并是纯计算，不依赖本地数据，所以哪个 proxy 都能做。

4.2段扇出与归并的代价

段越多，扇出越宽、每层归并要重排的候选越多——这是 02 的 compaction 为什么重要、03 的查询旋钮在哪里起作用的交汇点。

比文档深一层的机制：扇出宽度 ≈ 相关 segment 总数。两个方向会把它推大。其一，sealed 段碎片化：手动 flush 过频（01 §1.5 的警告）或写入模式零碎，会留下大量小 sealed 段，每个都要被派去检索、都要贡献一份 top-k 进归并——这正是 02 §2.5 里 compaction 存在的理由：把小段合并成大段，直接削窄扇出。其二，growing 段堆积：写得快但 sealed + indexed 跟不上时，流式节点上挂着一批 growing 段，它们只能暴力扫（01 §1.4），段越多暴力扫的总量越大，直接拖慢这一路。

把 03 的旋钮接到这里：nprobe（IVF，扫多少个簇）和 ef（HNSW，候选队列多大）决定每个 segment 上检索的召回与延迟（03 §3.8）。它们是段级参数——调大 ef，是让每一个 segment 都搜得更狠，代价随段数线性放大。所以“调召回”和“控段数”是两件必须一起看的事：旋钮决定单段成本，compaction 决定段数，二者相乘才是这一路的总延迟。

4.3过滤与分区裁剪

标量过滤和 partition 裁剪都在“缩小要检索的数据”，但裁剪只在查询显式带上分区维度时才生效。

比文档深一层的机制：partition key 裁剪（01 §1.2）是最廉价的一层——查询带上分区维度，调度器直接不把无关 partition 的 segment 派给执行者，那些段连碰都不碰。标量 filter 表达式则在每个被检索的段内部生效。最反直觉的一点在这里:带过滤的 ANN 比纯 ANN 更难，不是更简单。图索引（HNSW）靠在邻接图上贪心游走找近邻；过滤会让游走踩空——途经的节点大量不满足条件，图的连通性被打断，要么走更多步、要么提前陷入候选不足。聚类索引（IVF）同理：簇内满足过滤的候选凑不满 topK，被迫去扫更多簇。过滤比（满足条件的占比）越低，这种打断越严重。

过滤比反过来左右索引选型，这是 03 §3.9 留下的前向引用，现在收回：图索引（HNSW）在过滤比 < 85% 时通常更优——它对“滤掉一部分”相对鲁棒，剩下的候选仍能在图上连通；而 IVF 在 85~95% 的高过滤比叠加大 topK（> 2000）时反而更优——此时几乎不滤，IVF 扫整簇的简单结构没有图游走被打断的损耗，大 topK 下吞吐占优。换句话说，“选哪个索引”不只看数据规模，还要看查询长什么样：过滤比和 topK 是和规模并列的输入。

4.4一致性机制：TSO 与 guarantee timestamp

一致性级别不是“强/弱”开关，而是给检索的 guarantee timestamp 取哪个值——一条连续的光谱。

比文档深一层的机制：02 §2.2 里 MixCoord 兼任时间戳预言机（TSO oracle）——它派发全局单调递增的 TSO 时间戳。02 §2.4 的写路径里，每条写入都带一个 TSO。读路径这边，每次检索带一个 guarantee timestamp，语义是:“返回结果前，必须看到所有 TSO ≤ 这个时刻的写入”。执行者（query node / 流式节点）会等到本地已消费的数据追上 guarantee ts 才开始检索。于是四个一致性级别，本质是给 guarantee timestamp 选四个不同的值：

• Strong = guarantee ts 取最新时刻（向 MixCoord 要当前 TSO）。要求看到此刻为止的全部数据 → 执行者得等本地数据完全对齐，最慢。
• Bounded = guarantee ts 取最新时刻减一个容忍窗口（默认）。允许漏掉最近这个窗口内的写入 → 不必等最新，有界滞后。
• Session = guarantee ts 取本 client 最后一次写入的 TSO。只保证看到自己这个会话写过的东西 → read-your-writes，但不保证看到别人刚写的。
• Eventually = 不卡 guarantee ts（取 0 / 最早）。执行者拿到什么就搜什么，不等待 → 最快，无新鲜度保证。

4.5四个级别的代价对比

同一条光谱上,越靠“看到最新”越慢、越靠“不等待”越快——按场景对新鲜度的真实需求来选。

把四个采样点摊成一张对照表。默认是 Bounded（不是 Strong）——这是从关系库迁移过来最反直觉的一点（01 §1.7 已埋）：默认给的是有界滞后，不是 read-your-writes。

# 一致性级别按次设置:同一 collection 不同查询可用不同级别
# 不指定则用 collection 默认(Bounded) —— 注意默认不是 Strong
res = client.search(
    collection_name="docs",
    data=[query_vector],
    limit=10,
    filter='tenant == "acme" and date >= "2026-05-27"',  # 标量过滤 + 可触发 partition 裁剪
    search_params={"metric_type": "COSINE", "params": {"ef": 64}},  # ef 是段级旋钮(03)
    consistency_level="Session",   # 写后要自查 → Session;要绝对最新 → Strong(付延迟)
)

4.6跨概念综合：一个 RAG 场景同时拍三个板

真实选型不是孤立调一个参数,而是一致性、索引、partition 三者在同一个场景里相互牵制。

场景:一个企业知识库 RAG。文档块持续增量写入（每天新增、偶尔重灌某个空间的文档），同时在线检索（用户提问 → 召回相关块喂给大模型）。数据按空间/租户天然分组,规模到千万级向量。把前面所有零件摊开,同时拍三个板:

板一:一致性级别 → Bounded

RAG 召回容忍秒级滞后——用户提问时,刚灌进去几秒的某个块晚一点可见,不影响答案质量。Bounded（默认）正合适:用有界滞后换检索吞吐。例外:如果产品要“刚上传的文档立刻能被同一用户问到”,那条交互路径单独用 Session——按次设置,不必整个 collection 改默认（呼应 4.5 的“一致性级别按次设”）。

板二:索引 → 看过滤比和 topK，不只看规模

千万级规模两种主流索引都扛得住,真正的决定因素是查询形态（4.3 收回的 03 §3.9）。RAG 召回通常带过滤(按空间、按文档类型)但过滤比不会太低,且 topK 一般不大(几十)。这落在图索引(HNSW)更优的区间——过滤比 < 85% 且小 topK,HNSW 对过滤鲁棒、延迟低。只有当某些查询变成“几乎不过滤 + 超大 topK(>2000)”时,IVF 才反超。

板三:partition → 用空间/租户做 partition key

数据天然按空间分组,且检索几乎总带空间条件——这正是 partition key 的理想场景(01 §1.2)。按空间设 partition key,查询带上空间维度就段级裁掉其他空间的全部 segment(4.3 图 4.2),把扇出宽度从“全库段数”压到“本空间段数”。