带过滤的检索：RAG 真正的难处

4.1planner 的三选一

回到那条贯穿全教程的查询。它把关系过滤和向量排序焊在一起：

SELECT id, content
FROM   doc_chunks
WHERE  tenant_id = 42 AND lang = 'zh'   -- 关系过滤：B-tree 的活
ORDER  BY embedding <=> $1               -- 向量排序：HNSW 的活
LIMIT  10;

向量索引只管 ORDER BY 距离 + LIMIT（§1.4），WHERE 得在别处解决——于是 planner 必须在三条计划里选一条。

§1.4 那条契约（向量索引是 amcanorderbyop 排序索引，不碰 WHERE）在这里第一次产生真实后果。既然一个索引管排序、另一种手段管过滤，planner 就得决定谁先谁后：

4.2post-filter 为何欠返：预算用完，不是数据不够

HNSW 先按距离取 ef_search 个候选（固定预算），WHERE 在之后才筛——筛剩的未必够 k 条。

4.3三条出路：按选择性选

欠返的解法不止一个，选哪个取决于 WHERE 的选择性（命中行占比）和过滤值的多样性（有多少种不同的 tenant）。

出路一：iterative scan（0.8.0，推荐默认）

让索引"边扫边补"：取满后若不足 k 条，继续往外扩，直到够 k 或撞上上限。

底层机制（比文档深一层）：iterative scan 把"取一次 ef_search"变成"不够就再取一轮"，直到过滤后的幸存数达到 LIMIT，或扫描量撞到 hnsw.max_scan_tuples（默认 20000）、内存撞到 hnsw.scan_mem_multiplier × work_mem（默认 1×）。两种顺序模式：strict_order 重新按精确距离排序后返回；relaxed_order 按找到的顺序返回（略微乱序，但更快，质量约 95–99%）。默认是 off——必须显式打开，这是 0.8.0 之后欠返仍然普遍存在的唯一原因：很多人升级了版本却没开这个开关。

-- 会话级打开（relaxed 更快，多数 RAG 够用）
SET hnsw.iterative_scan = relaxed_order;
SET hnsw.max_scan_tuples = 20000;   -- 扫描上限，护栏

SELECT id, content
FROM   doc_chunks
WHERE  tenant_id = 42 AND lang = 'zh'
ORDER  BY embedding <=> $1
LIMIT  10;   -- 现在能补够 10 条（除非命中实在太稀疏）

出路二：partial index（过滤值少且固定时）

为某个固定过滤值单独建一张只含匹配行的索引，让 ANN 直接在"已过滤"的集合上跑。

把 WHERE 写进索引定义，索引就只对匹配行建图——过滤变成了预过滤（pre-filter），召回完全恢复，因为 ANN 搜的本来就只有 tenant=42 的行。代价：一个过滤值一张索引。10 个大租户可以各建一张；10 万个租户行不通——那是 §2.3 构建成本和 §3.2 churn 成本的 10 万倍。

-- 只为大租户 42 建：图里只有它的行，搜出来必然都属于它
CREATE INDEX ON doc_chunks
    USING hnsw (embedding vector_cosine_ops)
    WHERE tenant_id = 42;

出路三：先 B-tree 精确排序（选择性高时其实最优）

命中行很少时，根本不需要 ANN：B-tree 过滤出几十行，逐一算精确距离再排序，又快又对。

如果 tenant=42 AND lang='zh' 全表只命中 200 行，对这 200 行做精确距离排序是微秒级的事，还没有任何近似误差。这时 planner 主动放弃向量索引、走 B-tree + 精确排序，是正确的选择——别去强迫它走 HNSW。"索引没被用"不总是 bug（§4.4 详谈）。

4.4planner 为何"有索引却不走"

向量索引被忽略，要么是 §1.4 的契约被破坏，要么是 planner 算下来扫表更便宜——两者都用 EXPLAIN 看得见。

"建了 HNSW 索引，查询还是很慢"是高频求助。根因分两类，都不神秘：

第一类——契约被破坏（回到 §1.4）：

• ORDER BY ... DESC：索引只升序吐，DESC 直接出局（§1.4 的想一想）。
• 没有 LIMIT：要求全量有序，planner 算下来不如全表排序。
• ORDER BY 里是表达式而非纯运算符、或表太小（几百行扫表更快）。

第二类——成本估算（§2 的延伸）：0.8.0 之前 pgvector 把 ANN 扫描的启动成本估得过低（估 ~116，实际可达 ~7200），planner 经常误判，在带 CTE / 复杂谓词的查询里退回 Parallel Seq Scan + Sort。0.8.0 修了成本模型，这类误判大幅减少。诊断永远是同一招：EXPLAIN 看走的是 Index Scan using ..._hnsw 还是 Seq Scan + Sort。

EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM doc_chunks
ORDER BY embedding <=> $1
LIMIT 10;

-- 走索引（想要的）：
--   Index Scan using doc_chunks_embedding_idx on doc_chunks
-- 没走索引（要排查）：
--   Sort  ->  Seq Scan on doc_chunks      ← 全表 + 排序，慢

4.5叠加词法：hybrid 检索与 RRF

稠密向量擅长语义、漏掉精确关键词；叠加一路词法检索（BM25 / tsvector），用 RRF 融合两个排名，是 RAG 召回的生产标配。

底层机制（比文档深一层）：Reciprocal Rank Fusion 给每个文档的得分是 Σ 1/(k + rank_i)，rank_i 是它在第 i 个榜单里的名次，k 取经验值 60。k 的作用是压平头部差距——名次第 1 和第 2 的得分差，远小于"上榜与没上榜"的差，于是同时出现在两个榜单的文档被显著抬升。这就是 hybrid 想要的效果：双榜共识的结果排最前。

-- 两条召回腿各取 top-40，再用 RRF 融合（k=60）
WITH dense AS (
    SELECT id, RANK() OVER (ORDER BY embedding <=> $1) AS rank
    FROM doc_chunks
    WHERE tenant_id = 42
    ORDER BY embedding <=> $1
    LIMIT 40
),
lexical AS (
    SELECT id, RANK() OVER (ORDER BY ts_rank_cd(content_tsv, q) DESC) AS rank
    FROM doc_chunks, plainto_tsquery('simple', $2) AS q
    WHERE tenant_id = 42 AND content_tsv @@ q
    LIMIT 40
)
SELECT COALESCE(d.id, l.id) AS id,
       COALESCE(1.0/(60 + d.rank), 0)
     + COALESCE(1.0/(60 + l.rank), 0) AS score
FROM dense d
FULL OUTER JOIN lexical l USING (id)
ORDER BY score DESC
LIMIT 10;