A housing casework assistant uses pgvector in Azure Database for PostgreSQL but must limit results by district and case status. What pattern should it use?
Select an answer to reveal the explanation.
Short Explanation
Semantic search finds ‘sounds like this,’ and district/status filters keep it on the right housing desk—use both so casework results don’t wander across the whole city.
Full Explanation
Housing casework assistants using pgvector should combine vector similarity search with metadata filters on attributes such as district and case status. Pre- or in-query filters constrain the candidate set to cases the worker is allowed or intends to see, then similarity ranks within that set. That pattern preserves semantic usefulness while enforcing municipal case boundaries.
Running unrestricted vector search across all districts and filtering only after showing residents every hit leaks out-of-scope cases and fails confidentiality expectations. Ignoring district and status columns because “embeddings already encode every policy rule” confuses semantic similarity with structured authorization and workflow state—embeddings do not replace metadata filters. Returning a random sample of cases without vectors or filters abandons both relevance and governance.
Exam caveat: filtered vector search behavior depends on how predicates interact with the vector index; designs should ensure filters are applied so results remain both relevant and policy-compliant. Operational check: for a fixed query embedding, compare unfiltered versus district/status-filtered result sets, confirm zero cross-district leakage in the filtered path, and measure recall within the allowed subset before releasing the casework assistant.