A missing warning is a retrieval-quality problem
An exhibit conservation assistant might retrieve a short repair instruction while missing a nearby document that warns about solvent use. A reviewer cannot safely conclude that the search is comprehensive just because the first results look plausible. Azure AI Search offers approximate vector retrieval using HNSW and exhaustive K-nearest-neighbor search. The query-level vectorQueries.exhaustive option provides a way to request exhaustive KNN, even for an HNSW-indexed vector field. The useful task is a controlled comparison of candidate retrieval under the same authorized document set, not a claim that exhaustive search proves the answer is correct.
Separate the two retrieval algorithms
HNSW is an approximate nearest-neighbor technique that trades some recall for scalable efficient search. Exhaustive KNN compares more directly across the available vector space to identify the exact nearest neighbors for a query under the chosen vector metric. Microsoft documents the optional exhaustive flag in vectorQueries and notes that an HNSW-indexed field can be queried exhaustively. The reverse assumption is unsafe: fields indexed only for exhaustive KNN do not have the graph structures needed for HNSW queries. Verify the index vector profile and API version rather than copying an example from a different deployment.
Hold the evaluation inputs constant
A meaningful comparison begins with the same index snapshot, embedding model, field, query vector, k value, and access filters. If the approximate search uses a smaller k or a different filter than the exhaustive request, its missing document cannot be attributed to HNSW alone. Record embedding dimensions and any vectorizer configuration. Do not mix title vectors from one model with caption vectors from another model unless that is an explicitly designed compatible representation. Keep the conservation-warning examples synthetic or institutionally approved, particularly when repair notes include unpublished acquisition or treatment information.
Create a judgment set rather than a one-off anecdote
Prepare a small set of representative questions, each linked to a reviewer-approved list of relevant safety notices and supporting documents. Include exact accession references, ambiguous terms, uncommon conservation hazards, and ordinary visitor-description questions. Document why each item is relevant using the original source passage, not an AI-generated explanation. This creates a reference set for recall evaluation. A search result absent from the top k may still be retrieved at a larger k; state the cutoff in every comparison. This article provides an evaluation design, not measured recall numbers from a real Azure service.
Issue the exhaustive query deliberately
In a supported API request, the vectorQueries element can specify the target vector fields and a query vector, with exhaustive set to true for exhaustive KNN. Use the same k and the same independent rights filters as in the baseline query. Verify whether text or hybrid components are also being sent; if they are, result fusion and semantic reranking can obscure an apples-to-apples vector comparison. For an initial recall experiment, isolate the vector retrieval behavior before adding text search. Record the exact request shape and API version along with response status.
Compare candidate lists without inventing a score threshold
For each test question, write down which approved warning document IDs appear in HNSW results, exhaustive results, both, or neither. Calculate top-k recall against the annotated judgment set and track the distribution across queries, not just an average. Microsoft documents differing score ranges and ranking mechanisms for text, vector, and hybrid searches. Do not compare a vector similarity score with a semantic reranker score as if they were on one universal scale. A wider candidate list may contain more off-topic records and still require an expert to judge usefulness.
Treat latency and quota as separate operational questions
Exhaustive KNN can consume more work per query than approximate search, especially as collections grow. Record realistic latency, query volume, and service capacity in a controlled staging evaluation before considering it for a production visitor-facing interface. Do not claim a fixed speed penalty: actual performance depends on the index size, vector dimensionality, and service configuration. The goal may be to use exhaustive queries as an audit baseline or for a narrow critical collection rather than for every user query. Performance tests must respect the organization’s cost and availability limits.
Rights filters are nonnegotiable
An exhaustive search must not be allowed to fetch restricted conservation records merely because the operator is measuring recall. Use the same server-enforced authorization filters and index permissions for both queries. Do not rely on a client-supplied filter as a security boundary if the client can remove or rewrite it. Validate access control separately with allowed and prohibited identities. Missing rights-restricted records should be excluded from the comparison’s eligible judgment set instead of being counted as algorithmic false negatives for a public kiosk.
Investigate the cause of each missing result
A document absent from both searches might not have been indexed, might use the wrong embedding version, might be filtered out, or might not be semantically similar to the question. An item present only in exhaustive results may suggest an approximation gap under the controlled conditions. Review the source and ingestion history before making that inference. For critical warnings, add explicit metadata or keyword safety checks rather than assuming vector similarity is the sole route to retrieval. Human conservation review remains the authority for treatment advice, not a retrieval score.
Publish an evidence-focused comparison
A good internal report identifies index version, API version, relevant field, embedding configuration, query set, k, filters, observed candidate IDs, recall measure, latency observations, and unresolved access issues. It should make no claim of improved patient, visitor, or collection safety based solely on search rank changes. If a new search configuration is adopted, rerun the same evaluation after each index refresh or model migration. The exhaustive flag is a diagnostic and retrieval option; it neither corrects bad documents nor certifies that an answer is appropriate for publication without editorial review.
How We Research
This November 11, 2026 article is a documentation-based instructional analysis, not a hands-on test or production benchmark. We compared Microsoft, Create a vector query and Microsoft, Vector relevance and ranking and Microsoft, Search relevance overview, identified the precise parameter or behavior that the documentation supports, and organized the guidance around an illustrative museum workflow. We did not run a live service request, inspect real WordPress content, measure accuracy, or verify delivery against a working customer account. Each pictured scenario is an original conceptual illustration; current settings, permissions, supported API versions, and organization-specific governance must be confirmed before use. The release checks deliberately distinguish technical output from authorization, evidence quality, and actual user outcomes.
Frequently Asked Questions
No. It changes vector candidate retrieval; source relevance and answer accuracy still require review.
Yes, Microsoft documents query-time exhaustive KNN for HNSW-indexed fields.
No. It lacks the graph structures required for HNSW traversal.
Yes. Keep query inputs and authorization constant to isolate retrieval-method differences.
Not necessarily. Measure latency and service capacity for your actual index before production use.