Metadata filtering
Narrowing retrieval by facts like tenant, date, language, or document type before ranking the remaining candidates by meaning.
See it
What it is
Metadata filtering narrows the documents eligible for retrieval using attributes such as tenant, language, date, product, or access level before similarity ranking decides what is closest. The vectors answer 'which is most alike?'; metadata answers 'which records are allowed into the race?'
Reach for it when one index holds several customers, content types, versions, or permission scopes. Store filterable fields in consistent types at ingestion time, and apply hard security boundaries such as tenant_id in the database query rather than asking the model to respect them in prose.
Gotcha: every filter shrinks the candidate pool. A typo, missing field, or overly narrow date range can turn a good semantic query into zero results. Approximate vector indexes also handle filters differently: an HNSW index that applies the predicate after the search can hand back fewer than the k rows you asked for. Measure recall with the actual index and data distribution instead of assuming a SQL WHERE clause is free.
Ask AI for it
Add metadata filtering to this PostgreSQL and pgvector retrieval query. Require tenant_id, accept optional language, document_type, and published_at bounds, apply those predicates before ORDER BY embedding <=> query_embedding, and return the top 10 authorized rows. Add B-tree indexes for the common filters, parameterize every value, explain the query plan, and test missing metadata, an empty candidate set, and cross-tenant access.