Microsoft announced general availability of integrated vectorization in Azure AI Search, and it changes a fairly annoying part of building RAG (Retrieval-Augmented Generation) applications. If you have built a search index backed by vector embeddings before, you know the pain: you write a pipeline to pull documents from a source, chunk them into manageable pieces, call an embedding model, and then push the vectors back into your index. Integrated vectorization folds all of that into the indexing pipeline itself, so you stop maintaining a separate Azure Function or console app just to keep your embeddings in sync.
Why vectorization matters in the first place
Vectorization converts your data into numerical embeddings so that a search engine can compare meaning rather than just matching keywords. This is what lets a RAG application find the right paragraph in a 200-page policy document even when the user’s question does not share a single word with the source text. Getting data ready for vector search involves several steps: cracking documents open (extracting text from PDFs, Office files, images), splitting the text into chunks that fit within an embedding model’s context window, generating the embeddings, and mapping everything correctly into an index schema.
In most projects I have worked on, this pipeline was custom-built with Azure Functions or a batch job, and it always ended up being one of the more fragile pieces of the architecture. Chunking logic changes, embedding model versions change, and someone forgets to re-run the pipeline after a schema change. Integrated vectorization does not eliminate that complexity, but it moves it into a managed, declarative pipeline that Azure AI Search owns and runs for you.
What integrated vectorization actually does
Integrated vectorization is a capability of Azure AI Search that combines document chunking and embedding generation directly into the indexer pipeline, going from source file to a queryable index in one flow. As part of the indexing pipeline, it splits your original documents into chunks, calls Azure OpenAI to create embeddings for each chunk, and maps the resulting vectors into your index fields automatically.
The resulting index can be used as the retrieval layer for any RAG application, whether you are building on Azure AI Studio, Azure OpenAI Studio, or a custom application calling the Azure AI Search REST API directly. This matters because it decouples your retrieval infrastructure from any one orchestration framework. You are not locked into a specific SDK to get a working vector index.
What shipped to general availability
The following capabilities are now GA as part of the Azure AI Search REST API version 2024-07-01:
- Azure OpenAI embedding skill and vectorizer, for automatic vectorization of text at both ingestion and query time.
- Index projections, which map one source document to multiple chunks, improving relevance when a single document spans several concepts.
- Split skill functionality with overlap support, for chunking data into smaller pieces with configurable overlap between chunks.
- Custom vectorizer support, so you can connect to embedding endpoints other than Azure OpenAI.
- Shared private link support for Azure OpenAI accounts, part of the AI Search management API version 2023-11-01, for private connectivity from a virtual network.
- Customer-managed keys for indexes that use vectorizers, so query-time vectorization operations are encrypted with your own keys.
The chunk overlap setting in the split skill is worth calling out specifically. Without overlap, you risk splitting a sentence or a table row exactly at a chunk boundary, and the embedding for either half loses meaning. A modest overlap, typically ten to twenty percent of chunk size, keeps context intact across boundaries without inflating your index size too much. It is a small setting that has an outsized effect on retrieval quality.
Getting started from the Azure portal
The Import and vectorize data wizard in the Azure portal is the fastest way to try this out. It walks you through document chunking, Azure OpenAI embedding creation, index definition, and field mapping, all without writing a line of code. With this GA release, the wizard now also supports Azure Data Lake Storage Gen2 as a source, in addition to Blob Storage, Azure SQL, and Cosmos DB.
The wizard is genuinely useful for prototyping and for straightforward scenarios where your data source is one of the supported connectors. If your requirements go beyond that, you can define the same indexing pipeline through code using skillsets and indexers, which gives you full control over chunking strategy, enrichment steps, and error handling. I would treat the wizard as a way to validate the approach quickly, then move to code-based pipelines once you need production-grade error handling or custom chunking logic that the wizard does not expose.
What is still in preview
Image and multimodal embeddings, along with Azure AI Studio model catalog embeddings, remain in public preview. If your RAG scenario needs to search across images, diagrams, or scanned documents using multimodal embeddings, plan for that functionality to still carry preview caveats around SLAs and breaking changes.
Pricing and customization, in practical terms
Split skill chunking, native data parsing, and index projections are included at no extra cost within your Azure AI Search service pricing tier’s built-in indexer limits. The cost that actually grows with usage is the Azure OpenAI embedding calls, which are billed separately under your Azure OpenAI resource. When estimating cost for a large document corpus, model the embedding token cost separately from the AI Search service cost, because that is where the bill scales with data volume.
For customization beyond the wizard, the AI Search Power Skills GitHub repository has sample custom skills, including one for calling an external embedding endpoint if you want to use a model other than Azure OpenAI. Document Intelligence can also be wired in ahead of chunking if you need table structure preserved or need OCR on scanned pages before the text ever reaches the splitter.
When this approach fits and when it does not
Integrated vectorization is a strong fit when your data comes from a directly supported source (Blob Storage, ADLS Gen2, Azure SQL, Cosmos DB) and your chunking needs are reasonably standard. It is also a good fit when you want a RAG retrieval layer up quickly, without a team dedicating weeks to build and maintain a custom ingestion pipeline.
Where it is a weaker fit is when your chunking logic is domain-specific, for example, needing to keep legal clauses or code blocks intact as a single unit regardless of size, or when your source data lives in a system without a native indexer connector. In those cases a custom Azure Functions-based pipeline still gives you more control, at the cost of more code to maintain and monitor. The trade-off is really velocity versus control, and for most net-new RAG projects I would start with integrated vectorization and only fall back to a custom pipeline once you hit a concrete limitation.
Early customer results
SGS and Co, a design and graphic services company, built an internal visual search application on Azure AI Search using integrated vectorization to search sourcing and research assets across global production teams. Their team specifically called out that automated batching and chunking removed the need for separate compute instances to manage vectorization during live syncs.
Intertech, the software arm of Denizbank in Turkey, consolidated multiple GenAI applications onto a single centralized RAG system built on Azure AI Search, using integrated vectorization to unify document processing across ticketing systems, internal procedures, and other documentation sources. Consolidating onto one retrieval system instead of maintaining separate pipelines per application is a pattern worth considering if your organization has several RAG projects starting independently.
A note on binary quantization
Alongside this GA announcement, Azure AI Search also shipped binary quantization to general availability, which reduces the storage footprint of vector indexes significantly. If you are running integrated vectorization at scale, it is worth evaluating binary quantization for your index configuration separately, since vector storage costs can add up quickly with large document sets and high-dimensional embeddings.
Leave a Reply