Classic Search in Azure AI Search

Classic search is an index-first retrieval model for predictable, low-latency queries. Each query targets a single, predefined search index and returns ranked documents in one request-response cycle.

What is Classic Search?

Classic search provides the traditional search engine experience where:

Queries execute against a single index
Results return in one request-response cycle
No LLM-assisted planning or iteration occurs
Ranking is based on BM25 or similarity metrics

In this architecture, your search service sits between data stores containing your content and your client application.

Architecture

Primary Workloads

Classic search has two primary workloads:

Indexing

Indexing loads content into an index and makes it searchable:

Inbound text is tokenized and stored in inverted indexes
Inbound vectors are stored in vector indexes
Content must be in JSON format
Use push method (upload JSON) or pull method (indexers)

Indexing Process:

Document cracking: Extract text and metadata from source documents
Field mapping: Map source fields to index fields
AI enrichment (optional): Apply skills for OCR, entity extraction, vectorization
Tokenization: Break text into terms for full-text search
Storage: Store in inverted indexes (text) and vector indexes (embeddings)

Querying

Querying targets an index populated with searchable content:

Client app sends query request to search service
Set up search client to handle various query types
Query executes against indexed content
Results ranked by relevance score

Query Types Supported:

Full-text search: Keyword-based queries with BM25 ranking
Vector search: Similarity search using embeddings
Hybrid search: Combined text and vector queries
Multimodal search: Query across text and images
Fuzzy search: Handle typos and misspellings
Autocomplete: Type-ahead suggestions
Geo-spatial search: Location-based filtering

Key Characteristics

Single Index

Each query targets exactly one search index

Synchronous

One request, one response cycle

Deterministic

Same query returns consistent results

Low Latency

Predictable response times (milliseconds)

Search Index

A search index is the central concept in classic search:

Index Schema

{
  "name": "hotels-index",
  "fields": [
    {
      "name": "hotelId",
      "type": "Edm.String",
      "key": true,
      "searchable": false
    },
    {
      "name": "hotelName",
      "type": "Edm.String",
      "searchable": true,
      "filterable": true,
      "sortable": true
    },
    {
      "name": "description",
      "type": "Edm.String",
      "searchable": true,
      "analyzer": "en.microsoft"
    },
    {
      "name": "descriptionVector",
      "type": "Collection(Edm.Single)",
      "searchable": true,
      "dimensions": 1536,
      "vectorSearchProfile": "my-vector-profile"
    },
    {
      "name": "rating",
      "type": "Edm.Double",
      "filterable": true,
      "sortable": true,
      "facetable": true
    }
  ]
}

Index Features

Document key: Unique identifier (required)
Searchable fields: Full-text or vector searchable
Filterable fields: Used in filter expressions
Sortable fields: Can order results
Facetable fields: Generate counts by category
Retrievable fields: Returned in search results

Query Execution

Query Flow

Query Example

{
  "search": "luxury hotel with ocean view",
  "searchFields": "hotelName,description",
  "select": "hotelId,hotelName,description,rating",
  "filter": "rating ge 4.5",
  "orderby": "rating desc",
  "top": 10,
  "skip": 0,
  "count": true
}

Query Parameters:

search: Query string for full-text search
searchFields: Fields to search (optional)
select: Fields to return in results
filter: OData filter expression
orderby: Sort expression
top: Maximum results to return
skip: Number of results to skip (pagination)
count: Include total count of matches

Full-Text Search

Full-text search in classic mode uses:

BM25 Ranking

The default relevance algorithm:

Term frequency (TF): How often term appears in document
Inverse document frequency (IDF): Rarity of term across all documents
Field length normalization: Shorter fields weighted higher

Text Analysis

Text undergoes lexical analysis:

Tokenization: Break text into terms
Lowercasing: Normalize case
Stop word removal: Remove common words (“the”, “and”)
Stemming: Reduce to root form (“running” → “run”)

Analyzers

Standard analyzer: Default, language-agnostic
Language analyzers: 56 languages supported (Microsoft and Lucene)
Custom analyzers: Define your own tokenization rules

Vector Search

Vector search finds semantically similar content:

How It Works

Generate embeddings from text or images
Store embeddings in vector fields
Query with embedding of search query
Find nearest neighbors using similarity metric

Similarity Metrics

Cosine similarity: Default for Azure OpenAI embeddings
Euclidean distance: Geometric distance
Dot product: Inner product similarity

Vector Configuration

{
  "vectorSearch": {
    "algorithms": [
      {
        "name": "my-hnsw-config",
        "kind": "hnsw",
        "hnswParameters": {
          "m": 4,
          "efConstruction": 400,
          "efSearch": 500,
          "metric": "cosine"
        }
      }
    ],
    "profiles": [
      {
        "name": "my-vector-profile",
        "algorithm": "my-hnsw-config"
      }
    ]
  }
}

Hybrid Search

Combine full-text and vector search in one request:

{
  "search": "luxury beachfront hotel",
  "vectorQueries": [
    {
      "kind": "vector",
      "vector": [0.01, 0.02, ...],
      "fields": "descriptionVector",
      "k": 50
    }
  ],
  "select": "hotelName,description,rating",
  "top": 10
}

Benefits:

Best of both worlds: precision (keyword) + recall (semantic)
Results merged using Reciprocal Rank Fusion (RRF)
Improved relevance over either method alone

Filters

Narrow results using OData syntax:

filter=rating ge 4.5 and category eq 'Luxury'
filter=geo.distance(location, geography'POINT(-122.12 47.67)') le 10
filter=tags/any(t: t eq 'pet-friendly')

Generate counts by category:

{
  "search": "hotel",
  "facets": ["category", "rating,interval:1"]
}

Response:

{
  "@search.facets": {
    "category": [
      {"value": "Luxury", "count": 42},
      {"value": "Budget", "count": 38}
    ],
    "rating": [
      {"value": 4, "count": 15},
      {"value": 5, "count": 27}
    ]
  }
}

Relevance Tuning

Scoring Profiles

Boost specific fields or values:

{
  "scoringProfiles": [
    {
      "name": "boost-recent",
      "functions": [
        {
          "type": "freshness",
          "fieldName": "lastRenovationDate",
          "boost": 2.0,
          "interpolation": "linear",
          "freshness": {
            "boostingDuration": "P365D"
          }
        }
      ]
    }
  ]
}

Semantic Ranking

Apply machine learning for better relevance:

{
  "search": "pet friendly hotel with parking",
  "queryType": "semantic",
  "semanticConfiguration": "my-semantic-config",
  "queryLanguage": "en-us"
}

When to Use Classic Search

Classic search is ideal for:

Traditional Search Applications

Website search boxes
E-commerce product search
Document management systems
Knowledge base search

Predictable Performance Requirements

Need consistent, low-latency responses
Service-level agreements (SLAs) on query time
High query volumes

Cost-Sensitive Scenarios

No LLM costs
Lower complexity than agentic retrieval
Predictable pricing model

Simple Retrieval Needs

Single-index queries
Deterministic results required
No need for query planning or iteration

Performance Optimization

Index Design

Mark fields as searchable, filterable, or sortable only when needed

Query Optimization

Use filters to reduce search scope before full-text search

Caching

Cache frequently used queries at application level

Replica Scaling

Add replicas to handle higher query loads

Comparison with Agentic Retrieval

Feature	Classic Search	Agentic Retrieval
Query target	Single index	Multiple knowledge sources
Query planning	None	LLM-assisted
Execution	Single request	Parallel subqueries
Response	Document list	Structured answer + references
Latency	Low (ms)	Higher (seconds)
Cost	Lower	Higher (LLM costs)
Use case	Traditional search	Agent workflows, complex Q&A

Next Steps

Create an Index

Build your first search index

Query Syntax

Learn full-text query syntax

Vector Search

Add semantic search capabilities

Hybrid Search

Combine text and vector search

Getting Started

Core Concepts

Agentic Retrieval

Indexing

Queries

​Classic Search in Azure AI Search

​What is Classic Search?

​Architecture

​Primary Workloads

​Indexing

​Querying

​Key Characteristics

Single Index

Synchronous

Deterministic

Low Latency

​Search Index

​Index Schema

​Index Features

​Query Execution

​Query Flow

​Query Example

​Full-Text Search

​BM25 Ranking

​Text Analysis

​Analyzers

​Vector Search

​How It Works

​Similarity Metrics

​Vector Configuration

​Hybrid Search

​Filters and Facets

​Filters

​Facets

​Relevance Tuning

​Scoring Profiles

​Semantic Ranking

​When to Use Classic Search

​Performance Optimization

Index Design

Query Optimization

Caching

Replica Scaling

​Comparison with Agentic Retrieval

​Next Steps

Create an Index

Query Syntax

Vector Search

Hybrid Search

Build docs developers (and LLMs) love

Classic Search in Azure AI Search

What is Classic Search?

Architecture

Primary Workloads

Indexing

Querying

Key Characteristics

Search Index

Index Schema

Index Features

Query Execution

Query Flow

Query Example

Full-Text Search

BM25 Ranking

Text Analysis

Analyzers

Vector Search

How It Works

Similarity Metrics

Vector Configuration

Hybrid Search

Filters and Facets

Filters

Facets

Relevance Tuning

Scoring Profiles

Semantic Ranking

When to Use Classic Search

Performance Optimization

Comparison with Agentic Retrieval

Next Steps