Azure AI Search: the vector mechanics

The previous card gave you the levers for improving retrieval in the order to pull
them — filter, then hybrid, then rerank, then tune how many results you return.
Those are technology-agnostic. This card is what they become when the technology
is Azure AI Search, because the exam can ask about the setting rather than the
principle.

Two algorithms, and the choice is permanent

When you index a vector field, you choose how it will be searched. There are two
options and they behave very differently.

HNSW — Hierarchical Navigable Small World — builds a layered graph of your
vectors and navigates it at query time. It is an approximate method: it finds
very good matches very quickly, but it does not guarantee it found the best ones.
Microsoft's own guidance is that it suits most scenarios, especially larger
datasets. The cost is memory — HNSW needs all the data points resident for fast
random access, and that consumes your vector index size quota.

Exhaustive KNN — K-Nearest Neighbours — simply compares the query against
every vector. It is slow and it is exact. Microsoft suggests it for small to
medium datasets, or when the need for precision outweighs the need for query
performance. Because it needs no extra structures, it does not consume the
vector index quota.

The asymmetry, which is the actual exam point

Here is the part worth memorising, because it is the kind of detail a question can
turn on.

A field indexed for HNSW can still be queried exhaustively — you pass
"exhaustive": true on the query and get an exact search when you need one.

A field indexed for exhaustive KNN can never use HNSW. Microsoft explains why
in one clause: "the extra data structures that enable efficient search don't
exist." You did not build the graph, so there is no graph to navigate.

So the two choices are not symmetrical. HNSW is the reversible one. Exhaustive
KNN locks you in until you rebuild the index. If you are unsure at design time,
that asymmetry decides it.

There is also a use for exhaustive KNN that has nothing to do with production. It
finds the true nearest neighbours, so it can build the ground truth set you
measure your approximate search against. That is an evaluation set, built with a
search algorithm — which connects this card straight to the evaluation cards later
in the guide.

Which parameter belongs to which stage

Four names come up, and the useful distinction is not what they do but when they
are set.

Index-time, and therefore unchangeable without rebuilding:
m, the number of neighbours each node connects to, and efConstruction, the
number of candidates considered while building — default 400, range 100 to 1,000.

Query-time, and therefore tunable freely:
efSearch, the length of the candidate queue while searching, and k, how many
results you want back.

If a scenario says the team wants to change a value without re-indexing, that
alone tells you which parameters are available to them.

Similarity metrics, and the one to pick

Three are supported: cosine, dotProduct and euclidean. The guidance is
unambiguous — use cosine with Azure OpenAI embeddings, because that is the
metric those models are built around. dotProduct is mathematically identical to
cosine for normalised vectors and marginally faster, which makes it a reasonable
optimisation and a poor default.

Hybrid search is rank fusion

When you run several vector queries at once, or combine vector and keyword search
in a single request, the results are combined using Reciprocal Rank Fusion.

That matters because "hybrid" sounds like a weighted blend you tune. It is not.
It is a rank-fusion step that takes the ordering from each method and merges them.

And on the question of what actually produces the best results, Microsoft answers
it directly: "Try hybrid queries with semantic ranking. In benchmark testing,
this combination consistently produced the most relevant results." If a question
asks for the highest-relevance configuration, that sentence is the answer.

One number that is not what it looks like

The @search.score returned for a cosine search is not the cosine similarity.
Azure applies a transformation — 1 / (1 + cosine_distance) — so that the score
decreases monotonically as matches get worse, which makes it usable for ranking.

This only bites you in one place, and it bites quietly: if you are setting a
quality threshold to discard weak results, you are setting it on a transformed
scale. Convert back to cosine first, or you are picking a number you have not
actually reasoned about.

The trap

Vector queries have no scoring profiles and no term boosting. Those are text
search features, and they do not apply here.

Which means the levers on the vector side are genuinely short: chunk size and
overlap, efConstruction, k, and moving to hybrid plus semantic ranking. That
is a shorter list than most people expect — and it is exactly why the filtering
and metadata work upstream carries so much of the weight.