How would metadata filtering improve retrieval?
- 1 min — what filtering buys: precision, latency, correctness.
- 2 min — pre vs post vs filtered ANN, with failure modes.
- 2 min — metadata quality: extraction, schema, validation.
- 1 min — permissions as the non-negotiable case.
Know the three implementations and their failure modes. Pre-filter (filter then search) is correct but can be slow on low-selectivity filters. Post-filter (search then filter) is fast but can return fewer than k results — or zero — when the filter is selective. Filtered ANN applies the filter during graph traversal and is what mature engines do.
Extraction quality is the hard part: metadata is only useful if it's populated consistently, and hand-maintained tags rot. Use LLM extraction at ingestion for things like document type and effective date, but validate against a schema. And never rely on post-filtering for permissions — a race between filter and result count becomes a data leak.
Org scope: the metadata schema is a cross-team contract — owned by the platform, versioned, with each source system's owner accountable for populating its fields. Pick an engine with native filtered ANN (Qdrant, Weaviate, OpenSearch k-NN, pgvector ≥0.8 iterative scans) rather than building filter logic in application code.
Post-filter
- Search top-k, then drop
- Fast
- Can return < k or 0
- Never for permissions
Filtered ANN
- Filter during traversal
- Always k if they exist
- Slower when selective
- Required for ACLs
What the answer sounds like at each level
Filter by fields like tenant, date or type so search only considers relevant documents.
Explains pre-filter vs post-filter vs filtered ANN, the empty-result failure of post-filtering, and the selectivity-dependent latency of pre-filtering.
Owns the metadata schema as a contract across source teams, mandates filtered ANN for permissions, and measures field fill-rate and extraction accuracy per source.
Follow-ups the interviewer will push
1A filter matches 0.1% of a 50M-vector HNSW index and latency spikes. Why?
Graph traversal keeps visiting nodes that fail the filter, so it explores far more of the graph to find k matches. Fix: for highly selective filters, switch to exact (brute-force) search over the filtered subset — 50k vectors is a few ms — or partition the index by that field. Mature engines pick the strategy by estimated selectivity.
2LLM-extracted 'effective date' is wrong on 8% of contracts. Impact?
Any date-filtered query silently excludes those documents — a recall bug with no error. Validate extraction against a labelled sample per source, keep a confidence score, and fall back to not filtering (then rank by date) when confidence is low.
Red flags interviewers listen for
- Uses post-filtering for access control.
- Unaware that post-filtering can return fewer than k (or zero) results.
- Assumes metadata is clean without measuring fill-rate.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Implementations | Names all three strategies and the selectivity trade-off. |
| Security | States that permissions require pre-filter or filtered ANN, never post-filter. |
| Data quality | Treats metadata as a measured, owned asset rather than assumed truth. |
Sources
- Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs — Malkov & Yashunin, 2016paper
- pgvector: open-source vector similarity search for Postgres — pgvector, 2021docs