Azure AI Search Architecture

Azure AI Search (formerly Azure Search) is a Platform-as-a-Service (PaaS) offering that provides full-text search, vector search, and hybrid search capabilities over user-defined indexes. It is built on Apache Lucene and integrates with Azure AI services for cognitive skillsets that extract and enrich data during indexing.

Traditional databases (e.g., SQL Server) offer basic LIKE queries but lack relevance ranking, fuzzy matching, faceted navigation, and synonym support. Azure AI Search fills this gap by providing: - Full-text search with tokenization, stemming, and scoring. - Semantic search using machine learning models to understand intent. - Vector search for similarity search over embeddings. - AI enrichment via cognitive skills (OCR, entity recognition, key phrase extraction).

Azure AI Search operates in two main phases: indexing and querying.

Indexing Phase: 1. Data Ingestion: Data sources (Azure Blob Storage, SQL Database, Cosmos DB, etc.) are connected via indexers. An indexer pulls data and optionally applies a skillset. 2. Document Cracking: For blobs, the indexer extracts text from files (PDF, Word, JSON, CSV). For databases, it reads rows. 3. Field Mapping: Source fields are mapped to index fields. The index defines which fields are searchable, filterable, sortable, facetable, and retrievable. 4. AI Enrichment (Skillset): If configured, a skillset invokes Azure AI services (e.g., Computer Vision for OCR, Text Analytics for language detection). Each skill outputs to a field in a temporary enrichment tree. 5. Knowledge Store: Optionally, enriched data can be persisted to Azure Storage (tables or blobs) for downstream analytics. 6. Indexing Engine: The Lucene analyzer tokenizes text, applies language-specific stemming (e.g., English: 'running' -> 'run'), removes stop words, and builds inverted indexes. 7. Scoring Profiles: During indexing, scoring profiles define how to boost certain fields or values (e.g., boost 'title' field weight by 10). 8. Vector Indexing: If using vector search, the indexer generates embeddings (via an Azure OpenAI model or custom) and stores them in a HNSW (Hierarchical Navigable Small World) index.

Query Phase: 1. Query Parsing: The search request (REST or SDK) is parsed. Parameters include search, filter, orderby, facets, highlight, scoringProfile, queryType (simple, full, semantic, vector). 2. Tokenization: The query string is tokenized using the same analyzer as during indexing. 3. Inverted Index Lookup: The Lucene engine looks up each token in the inverted index, retrieving document IDs and term frequencies. 4. Scoring: Each matching document gets a relevance score based on TF-IDF (term frequency-inverse document frequency) and any scoring profile modifications. The default scoring is BM25 (Okapi BM25). 5. Post-Processing: Filters are applied, facets are computed, and results are sorted. For semantic search, a reranking model (Microsoft's MMR) reorders results. 6. Response: The service returns a JSON payload with matching documents, total count (if $count=true), facets, and highlight snippets.

Creating a search service via Azure CLI:

az search service create --name mysearch --resource-group myrg --sku basic --location eastus

Creating an index via REST:

POST https://mysearch.search.windows.net/indexes?api-version=2023-11-01
Content-Type: application/json
{
  "name": "hotels",
  "fields": [
    { "name": "HotelId", "type": "Edm.String", "key": true, "searchable": false },
    { "name": "HotelName", "type": "Edm.String", "searchable": true, "filterable": false },
    { "name": "Description", "type": "Edm.String", "searchable": true, "analyzer": "en.microsoft" },
    { "name": "Latitude", "type": "Edm.Double", "filterable": true, "sortable": true }
  ]
}

Verification via Azure Portal: - Navigate to the search service blade. - Use 'Search Explorer' to test queries. - Monitor indexing via 'Indexer status' which shows success/failure count and last execution time. - Use Azure Monitor metrics for QPS, latency, throttled requests.

Scenario 1: E-commerce Product Search A large online retailer uses Azure AI Search to power their product catalog search. They ingest product data from Azure Cosmos DB (SQL API) into a search index with fields like product name, description, category, price, and tags. They use a custom analyzer to handle product codes and brand names. A skillset extracts key phrases from product descriptions to improve search relevance. They configure scoring profiles to boost products with higher ratings and lower stock levels. The search service is scaled to S2 tier with 6 replicas to handle peak holiday traffic of 10,000 QPS. Misconfiguration: Initially, they set all fields as 'searchable', causing slow queries. They fixed it by making only relevant fields searchable and using filters for price and category.

Scenario 2: Healthcare Document Search A hospital network needs to search through millions of patient records, lab reports, and medical images. They store documents in Azure Blob Storage. Using Azure AI Search, they create an indexer that cracks PDFs and images. A skillset uses OCR (Azure Computer Vision) to extract text from scanned documents, then uses Text Analytics for entity recognition (diseases, medications) and key phrase extraction. The enriched data is stored in a knowledge store (Azure Table Storage) for auditing. They use semantic search to allow doctors to query in natural language like 'patients with adverse reaction to penicillin'. The search service is deployed in a secondary region for disaster recovery. Common issue: The OCR skill misreads handwriting; they mitigate by training a custom model.

Scenario 3: Legal Discovery Platform A law firm uses Azure AI Search to index millions of emails and legal documents. They use vector search to find similar documents by embedding content with Azure OpenAI's text-embedding-ada-002. The vector index allows similarity search for 'find documents similar to this one'. They also use hybrid search for keyword and semantic queries. The service is tiered at S3 with 12 partitions to handle 50 TB of data. They monitor query latency and set up alerts for throttling. A common misconfiguration: they initially set the vector field dimensions incorrectly (used 768 instead of 1536), causing poor search accuracy. They rebuilt the index with correct dimensions.