Azure AI Search: Indexing, Vectors, and Relevance Engineering

November opens the AI arc of this series, and it starts with retrieval, because the Azure OpenAI RAG post from August stood on a component that deserves its own deep dive: Azure AI Search, the index behind almost every grounded AI application on Azure and a serious search engine in its own right.

Index Design and Ingestion

An index is a schema: fields typed and attributed as searchable, filterable, sortable, facetable, retrievable, and the attributes are performance and cost decisions, every attribute bloats the index, so mark only what the queries need. Analyzers decide how text tokenizes, language analyzers for prose, keyword for identifiers, custom chains when domain vocabulary demands them, and choosing wrong is invisible until recall disappoints. Ingestion has two shapes: push, your pipeline posting documents through the SDK, full control, the right answer for event driven freshness riding the Event Grid patterns from October; and pull, indexers crawling blob storage, SQL, Cosmos on schedule with change detection, the right answer for the lake and database content the September posts organized. Skillsets attach AI enrichment to indexers, OCR, entity extraction, and critically the split and embed skills that chunk documents and generate vectors inline, with integrated vectorization turning the classic RAG preprocessing pipeline into configuration.

Vector, Hybrid, and Semantic

Vector fields store embeddings under HNSW indexes for approximate nearest neighbor search, and the parameters (m, efConstruction, efSearch) trade recall against latency and memory in the standard ways, defaults first, tune with evidence. The finding that shapes real systems: pure vector search loses to hybrid, running keyword and vector retrieval together and fusing with reciprocal rank fusion, because keywords catch the exact identifiers and rare terms embeddings smear, while vectors catch the paraphrases keywords miss. The semantic ranker adds a reranking pass over the top results with a cross encoder model, measurably lifting the head of the list where RAG reads, worth its per query cost for most knowledge applications. So the default recipe for grounded AI on Azure: chunked content with overlap, hybrid retrieval, semantic reranking, filters scoping tenant and security trimming (security filters on identity claims, enforced in the query, never left to the LLM), top k tuned small because context windows reward precision over volume.

Relevance Is a Loop, Not a Launch

Search quality decays silently, so instrument it: capture queries, results, and clicks or thumbs into the analytics stack, build a golden set of query and expected document pairs from real traffic, and score changes against it before shipping them, the same evidence discipline as everything else in this series. Scoring profiles boost by freshness, popularity, or field weights without touching ranking code; vector weighting in hybrid queries shifts the fusion balance per scenario. Capacity follows the same honesty: replicas buy query throughput and availability (two minimum for production SLA), partitions buy storage and indexing throughput, and the tier ceiling is a migration, not a slider, so size the tier against the corpus you will have next year. Networking and identity are the invariants, private endpoint, managed identity for indexer connections to the data sources, keys off. The retrieval layer is where AI applications actually succeed or fail; the model gets the credit, the index does the work.

Cheers
Osama

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.