面试题库

14 天 RAG：从检索到可信回答

D5 向量索引与库选型：HNSW 与倒排文件、量化省内存、带过滤的查询与多租户隔离

• 为什么加了 WHERE 条件的向量检索会漏结果？有哪几种修法，代价分别是什么？Why does a vector search with a WHERE clause return fewer results than expected, and what are the fixes and their costs?

  国内高频海外高频深入#filtering#iterative-scan#recall

  分析过程 · 先想清楚再作答

  1. 这题是本天的核心，也是最能筛掉「只跑过 demo」的人的一题。题眼在「漏」这个字：能不能说清楚漏的是条数还是排序，直接决定你被归到哪一档。
  2. 先讲机制，一句话就够：近似索引的过滤发生在索引扫描之后。索引先按距离取回 ef_search 个候选，然后才拿 WHERE 去筛这一批。条件命中率越低，活下来的越少——命中 1% 的条件配默认的 40 个候选，平均只剩零点几条。
  3. 然后把漏召回拆成两类，这是拿分点：一类是**结果条数不够**，十条只给了一两条；另一类是**条数够但排序不对**，十条都在只是排错了。两类的修法完全不同，混为一谈说明没真跑过。
  4. 修法一是迭代扫描（pgvector 0.8.0 起）：候选被过滤掉太多时自动回索引里继续扫，直到凑够。它只解决第一类。两种模式的取舍要说清楚——严格顺序保证结果按距离排好，宽松顺序允许略微乱序换更高召回，代价都是延迟明显上升。
  5. 修法二是预过滤，即让过滤条件先生效：条件很挑剔时给过滤列建普通索引走精确检索，取值只有少数几个时建部分索引，取值很多时按值做列表分区。代价分别是失去近似索引的加速、索引数量随取值爆炸、以及 DDL 与运维复杂度上升。
  6. 可预期的追问：怎么判断该用哪一种？给一条可执行的判据——先看返回条数够不够。不够是第一类，先试迭代扫描；够了但召回低是第二类，只能加大 probes 或 ef_search，或者干脆改成预过滤。

  How to reason about it · think before answering

  1. This is the question that separates people who ran a demo from people who ran this in production. The tell is whether you distinguish missing rows from mis-ordered rows.
  2. State the mechanism in one sentence: with approximate indexes, filtering is applied after the index scan. The index first collects ef_search candidates by distance, and only then applies the WHERE clause to that batch.
  3. Do the arithmetic out loud: a condition matching 1% of rows against a default candidate list of 40 leaves well under one row on average. That is why the query looks broken even though the rows exist.
  4. Split the failure into two kinds. Too few rows returned is one; enough rows but the wrong ones ranked first is the other. They have different fixes, and conflating them signals inexperience.
  5. Fix one is iterative scanning, available since pgvector 0.8.0: when too many candidates are filtered out, keep scanning more of the index until enough results are found. Strict ordering keeps exact distance order, relaxed ordering trades slight reordering for better recall, and both cost latency.
  6. Fix two is making the filter apply first: a plain index on the filter column for highly selective conditions, a partial index when there are only a few distinct values, list partitioning when there are many. The costs are losing the approximate speedup, index count exploding per value, and DDL plus operational complexity.
  7. Expected follow-up: how do you pick? Check the returned row count first. Too few means iterative scanning; enough rows with low recall means raising probes or ef_search, or switching to pre-filtering.

  答题要点

  • 近似索引的过滤发生在索引扫描之后，条件命中率低时候选几乎被筛光，所以返回条数不够。
  • 漏召回分两类：条数不够，和条数够但排序不对。判断顺序永远是先看返回条数。
  • 迭代扫描只修第一类，严格顺序保序、宽松顺序召回更高，代价是延迟明显上升。
  • 预过滤是另一条路：过滤列建索引走精确检索、取值少建部分索引、取值多按值分区，代价依次是失去索引加速、索引数量爆炸、运维复杂度上升。
  • 第二类只能靠加大 probes 或 ef_search，迭代扫描对它完全无效。

  Key points

  • With approximate indexes the filter runs after the index scan, so a selective condition wipes out most candidates and the query returns too few rows.
  • There are two failure modes: too few rows, and enough rows in the wrong order. Always check the returned count first.
  • Iterative scanning fixes only the first. Strict ordering preserves distance order, relaxed ordering gives better recall, and both raise latency noticeably.
  • Pre-filtering is the alternative: index the filter column for exact search, use a partial index for a few distinct values, partition by value for many. Costs are losing the approximate speedup, index sprawl, and operational complexity.
  • The second failure mode is only fixed by raising probes or ef_search; iterative scanning does nothing for it.