Metadata Filtering

Metadata filtering narrows a vector search to only vectors matching specific structured conditions — combining exact-match filtering with similarity search, rather than searching the entire collection on semantic similarity alone.

Why This Matters

Without metadata filtering:
  Semantic search across ALL documents for "refund policy"
  → might return results from multiple product lines, regions,
    or outdated document versions, all just because they're
    semantically similar

With metadata filtering:
  Semantic search for "refund policy", filtered to:
    { "product_line": "electronics", "region": "US", "status": "current" }
  → only searches (and returns from) the genuinely relevant subset

Example Query

results = collection.query(
    vector=embed("refund policy"),
    top_k=5,
    filter={
        "product_line": "electronics",
        "region": "US",
        "status": "current"
    }
)

The metadata fields (product_line, region, status) are stored alongside each vector at ingestion time — a genuinely important design decision, since you can't filter on metadata you never stored.

Common Metadata Use Cases

• Access control — restrict search to documents a specific user is permitted to see
• Freshness/versioning — exclude outdated or superseded content
• Multi-tenancy — restrict search to one customer/organization's data in a shared system
• Category/type filtering — narrow to a relevant document category before ranking by similarity

Practical Use Case: Multi-Tenant RAG

A SaaS product offering document Q&A to multiple customers must ensure Customer A's search never returns Customer B's documents — this is almost always implemented via metadata filtering (a tenant_id or customer_id field), and getting this wrong is a genuine, serious security/privacy failure, not just a relevance issue.

Common Mistakes

• Not enforcing access-control filtering at the database query level, instead relying on filtering results after retrieval in application code — a serious risk if that post-processing step is ever skipped or has a bug
• Not storing metadata that will later be needed for filtering, requiring a costly re-ingestion to add it later
• Over-filtering to the point where relevant results are excluded because metadata was recorded inconsistently

Interview Relevance

"How would you ensure a multi-tenant RAG system never leaks one customer's data to another?" — metadata filtering enforced at the database query level (not just in application logic after the fact) is the expected core answer, given the serious security implications of getting this wrong.

Practice Question

Design the metadata fields you'd store alongside each document chunk for a multi-tenant document Q&A system that also needs to filter by document freshness.

Related Notes

• Vector Search
• Hybrid Search
• RAG Security