November opens the AI arc of this series. The Azure OpenAI post in August ended at the retrieval layer’s edge, ground the model in your data; today is that layer done properly, because in production RAG the model is rarely the weak link. Retrieval is. Azure AI Search is the retrieval engine, and the difference between a demo and a system is index design plus a relevance tuning loop.

Index Design and Ingestion

An index is a schema: searchable text fields with analyzers matched to language, filterable and facetable metadata (department, document type, security tags, dates), and vector fields carrying embeddings with an HNSW configuration. Chunking strategy decides more quality than any knob after it: split documents on semantic boundaries (headings, paragraphs) into chunks sized for your embedding model with overlap for continuity, and carry title, source, and position as metadata on every chunk, because citations and filters live off that metadata. Integrated vectorization moves the pipeline into the service, indexers pull from blob or ADLS through the skillset that chunks and embeds on ingestion and on schedule thereafter, which for the standard “make our document estate searchable” case removes your custom pipeline entirely; the Data Factory patterns from September remain for sources indexers cannot reach. Security filtering is a design input, not an afterthought: stamp chunks with the group IDs entitled to see them and filter every query by the caller’s groups, the pattern that keeps RAG from becoming a data leak with citations.

Querying: Hybrid or Nothing

The findings from every serious evaluation converge: keyword search wins on exact terms, identifiers, and names; vector search wins on paraphrase and concept; hybrid, both executed and fused with reciprocal rank fusion, beats either alone; and the semantic ranker on top, a reranking model over the fused results, lifts the head of the list where RAG actually reads. So production queries are hybrid with semantic ranking by default, filters applied for tenancy and security, and top k tuned against your context budget rather than defaulted. The evaluation loop is what makes this engineering: a golden set of real questions with judged relevant chunks, retrieval metrics (recall at k above all, an answer the retriever never surfaced is an answer the model cannot give), and every change, chunk size, analyzer, k, ranker settings, measured against the set before it ships. Teams that skip the golden set tune by anecdote and oscillate; teams that build it converge in days.

Running It

Capacity is tiers and replicas and partitions: partitions carry storage and indexing throughput, replicas carry query volume and availability (two or more replicas for the SLA that matters), and vector indexes live in memory, so embedding dimensionality and quantization settings translate directly into the tier you pay for; scalar and binary quantization plus dimension truncation on capable embedding models cut that footprint dramatically with measured, usually small, quality cost, exactly the kind of tradeoff the golden set exists to verify. The estate invariants apply verbatim: private endpoints, Entra auth with keys disabled for both control and data planes, managed identity for indexer connections to storage, diagnostics to Log Analytics with query latency and throttling alerts. And the boundary discipline that keeps the system honest: AI Search retrieves, the model reasons, and the orchestration between them logs retrieved chunks alongside generated answers, because when a RAG answer goes wrong, the first diagnostic question is always whether retrieval fed it the wrong truth or the model ignored the right one, and only that log answers it.

Cheers
Osama