Azure AI Search

About Azure AI Search

Azure AI Search is Microsoft's managed information retrieval service for applications that need full-text, vector, hybrid, multimodal, or AI-grounded retrieval over enterprise content. Microsoft also positions the service as the search foundation behind Foundry IQ, where knowledge bases can organize indexed and remote knowledge sources for agent workflows. It provides persistent search indexes, query APIs, indexing pipelines, ranking controls, AI enrichment, and agentic retrieval. Buyers should treat it as a search and retrieval platform rather than as a transactional database or a complete AI application by itself.

What is Azure AI Search used for?

Azure AI Search is used when an application needs fast retrieval over content that is difficult to search effectively with a transactional database alone. Common scenarios include product and catalog search, document discovery, knowledge portals, support search, internal enterprise search, and search experiences that combine filters, facets, ranking, and text relevance.

The service is also used as a retrieval layer for generative AI. Applications can index proprietary content, retrieve relevant passages, and pass those results to a language model for grounded response generation. Azure AI Search does not replace the model itself. It supplies retrieval, indexing, ranking, searchable context, and a knowledge-base layer for more complex agent scenarios.

How do full-text, vector, and hybrid search differ?

Full-text search is useful when exact words, phrases, filters, faceting, and lexical relevance matter. Vector search represents content and queries as embeddings so semantically similar items can be found even when the wording differs. Hybrid search runs full-text and vector retrieval together and merges the result sets.

Microsoft documents hybrid retrieval as combining keyword and vector results in one request, with Reciprocal Rank Fusion used to merge ranked lists. Semantic ranker can then rescore candidates. For many enterprise and RAG workloads, hybrid search is a practical starting point because exact terminology and semantic similarity can both matter. Teams should benchmark their own content because vector-only and keyword-only designs can fail in different ways.

What changed for agentic retrieval in 2026?

Microsoft made a generally available programmatic path for agentic retrieval available through the 2026-04-01 Search Service REST API. That stable API supports knowledge bases and generally available knowledge source types for extractive retrieval. The Azure portal and Microsoft Foundry portal still expose the full agentic retrieval experience as preview functionality.

The current preview contract is 2026-08-01-preview, not 2026-05-01-preview. Microsoft added private network ingestion for selected indexed knowledge sources, stored defaults for knowledge-base retrieve budgets, per-source reranking controls, server-sent event streaming for retrieve responses, citation URLs for indexed knowledge sources, and cursor pagination for several list operations. These preview features do not carry a production SLA and should be evaluated separately from the generally available 2026-04-01 surface.

How do knowledge bases, knowledge sources, and MCP fit together?

A knowledge base is the top-level object that orchestrates agentic retrieval. It references one or more knowledge sources and defines retrieval behavior. Knowledge sources can be indexed or remote. Microsoft currently documents sources including search indexes, Azure Blob Storage, OneLake, SharePoint, web sources, and newer preview source types.

Each knowledge base can expose a Model Context Protocol endpoint for MCP-compatible agents. At low or medium retrieval reasoning effort, an LLM can plan subqueries and decide which sources to query. At minimal effort, LLM query planning is bypassed for a faster and simpler path. Teams still need to design identity, permissions, source access, latency, failure handling, and data-boundary controls. An MCP endpoint does not remove the need for proper authorization or content governance.

What new 2026 preview controls matter for agent applications?

The 2026-08-01-preview adds controls that are useful for production-style testing even though the contract remains preview. Knowledge bases can store default runtime, output-document, and output-token budgets, while a retrieve request can override those defaults. A knowledge source can also bypass reranking so its original result order is preserved when that behavior is more appropriate.

Retrieve responses can now stream as server-sent events. Microsoft documents events for query planning, source activity, and the final synthesized answer or extracted response, with heartbeat comments for idle connections. The preview also adds service-generated citation URLs for indexed knowledge sources and freshness-aware retrieval controls that can balance recency against relevance. Buyers should validate browser, security, latency, and compliance behavior before treating these capabilities as production dependencies.

How does indexing and AI enrichment work?

Search content is stored in indexes with a schema that defines searchable, filterable, sortable, facetable, retrievable, and vector fields. Content can be pushed directly through APIs or ingested with indexers from supported data sources. Azure AI Search also supports AI enrichment pipelines for extracting or transforming information that is not useful in its raw form.

Microsoft's ingestion workflows can chunk documents and generate embeddings through supported Microsoft AI integrations. Large or frequently changing data sets should be designed around incremental indexing, deletion handling, schema changes, and reindexing cost. File knowledge sources are convenient for smaller agentic retrieval workloads, but Microsoft currently limits a file knowledge source to 100 files with a maximum 50 MB per uploaded file, so larger or scheduled ingestion workloads are better suited to blob-based ingestion.

How does Azure AI Search pricing work in September 2026?

Dedicated Azure AI Search services use provisioned capacity billed through Search Units. Replicas increase query capacity and availability, while partitions increase storage and indexing capacity. Free, Basic, Standard, and Storage Optimized tiers have different limits and capabilities. Confidential compute is available at additional cost on supported configurations, but Microsoft states that some features such as semantic ranker, agentic retrieval, skillset execution, and vectorization are limited or unavailable with confidential compute.

Microsoft's Serverless Developer model remains preview and uses Compute Units plus indexed storage. It can scale to zero when idle and is aimed at infrequent or variable traffic. Microsoft now states that Serverless Developer billing begins on September 13, 2026. Usage before that date is not charged. The preview has no production SLA, is limited to supported regions, caps an index at 1 GB, allows 30 indexes per service, and does not support migration to or from other pricing tiers during the preview.

What additional charges can agentic and semantic features create?

Base search capacity is not always the complete cost. Microsoft's current pricing model separates dedicated or serverless search capacity from add-on features such as agentic retrieval, semantic ranker, custom entity lookup, and document image extraction. Foundry IQ knowledge bases require a subscription and a standard agentic retrieval plan for paid agentic use.

Model deployments, connected data sources, enrichment, network transfer, and remote knowledge sources can add more cost outside the core search service. Reasoning effort can also affect model usage and latency. Buyers should therefore estimate the complete retrieval path instead of looking only at Search Units or Compute Units.

How do replicas, partitions, limits, and availability affect architecture?

Dedicated Azure AI Search scales in two dimensions. Replicas add query capacity and redundancy. Partitions add storage and indexing capacity. Microsoft currently allows up to 12 replicas and 12 partitions on most Standard and Storage Optimized dedicated tiers, while Basic supports up to three replicas and, for newer services, up to three partitions. Eligible billable services need at least two replicas for query SLA coverage and at least three replicas for query plus indexing SLA coverage.

Current index limits include a maximum of 4,096 dimensions per vector field and 1,000 simple fields per index on most tiers. Dedicated document capacity can reach billions of documents depending on tier. Microsoft also documents a roughly 16 MB indexing API payload limit for a single document or batch. Serverless Developer has different constraints, including a 1 GB per-index cap and 30 indexes per service. Service creation date and region can affect partition storage limits, so buyers should size against the current limits page for the actual service they will deploy.

How does Azure AI Search differ from a database or vector database?

Azure AI Search is optimized for retrieval, ranking, filtering, faceting, text analysis, vector similarity, and search-oriented indexing. It is not a transactional system of record. Most applications keep authoritative business data in databases or storage services and send a search-optimized representation into Azure AI Search.

A dedicated vector database may be attractive when the requirement is narrowly focused on vector retrieval, portability, or a vector-native operating model. Azure AI Search is stronger when buyers want vector retrieval alongside mature text search, hybrid ranking, filters, faceting, indexers, AI enrichment, Azure security controls, and Microsoft Foundry integrations.

Who should choose something else?

Teams that need only simple keyword lookup over a small data set may not need a dedicated search service. Database-native search or an application framework can be simpler and cheaper. Workloads that require transactional writes, relational constraints, or authoritative record storage should use a database and treat search as a secondary index.

Organizations that require full control over the search engine, custom plugins, or infrastructure portability may prefer self-managed or third-party search platforms. Buyers should also choose carefully if a required agentic capability is still preview, if the needed region or tier is unavailable, if Serverless Developer limits are too restrictive, or if retrieval quality cannot justify the added model and search cost.