Instruction 02

Comparing Traditional Search with Vector Search in Azure AI Search

Traditional search relies on exact matches, typically requiring a structured architecture for storing and retrieving data — making it excellent for keyword searches, or any situations where you need to find specific information.

However, to do this, your query must closely match the stored documents. Other search types, such as fuzzy and full-text search, allow you to search by matching portions of text instead of the entire text. This means you only need to get part of the text correctly in your query to get relevant results.

Traditional search offers limited options. You retrieve information based solely on your queries. Some search types may allow you to customize how much “noise” can be included in the response, but that’s it. It either works for your use case or it doesn’t. For this reason, its uses are limited. In scenarios where queries are precise or within the search type’s acceptable range, it works well.

Vector search is far more flexible in its responses:

• Based on your use case, you can tune its indexing, embedding, and query parameters.
• You can adjust the chunk size, fine-tune the embedding model, rank results, refine queries in the pipeline to return enhanced results, increase or constrain the number of results and their accuracy, and much more.

Azure AI Search presents all these capabilities in simplified APIs, available through any of its access portals.

Understanding the Nearest Neighbor Technique

Vector search uses a technique called Nearest Neighbor to perform data retrieval. This means it matches prompts or queries with embedded documents based on the distance between the two. The closest matches are returned in descending order — this is the same method by which ranking is done (ranking assigns scores to documents returned in relation to the given query).

Azure AI Search uses the Hierarchical Navigable Small World (HNSW) and Exhaustive K-nearest neighbors (KNN) algorithms for its vector search. While HNSW is optimized for low-latency applications with distributed data, KNN is optimized for smaller datasets and uses more processing power. This ensures you have options to choose the best technique for your application.

You can configure your vector search parameters to use either algorithm. HNSW consumes vector index size quota, so the size of your index will determine your cost.

Azure AI Search also uses Approximate Nearest Neighbor (ANN) — this is a group of algorithms aimed at reducing the search space to increase the speed of the search process. It prioritizes scalability and speed over perfect accuracy. Azure AI Search provides various parameters to customize your vector search for ANN, such as latency, memory, and disk usage.

Filtering Vector Search

Azure AI Search supports filtering in vector search. A field needs to be filterable — and either vectorized or non-vectorized — to allow filtering.

Vector search is all about relevance. Many techniques are available for making one search result better than another, and filtering is one such technique, allowing you to focus your search and results on a specific domain. By doing so, irrelevant documents are excluded from the search results, increasing the chances of retrieving more relevant results in a shorter time. It’s also less resource-intensive, helping you stay within your quota and incur lower costs.

Azure AI Search supports filtering by allowing you to create filters and configure their mode of operation. You can choose whether to filter before a query is executed or afterward.

Note: In Azure AI Search, indexed documents are limited in customizations allowed. Documents can be customized before indexing. For example,you can only add new data after indexing, but not alter vectorized fields.

Assessing Resource Usage on Azure AI Search

Azure AI Search measures vector indexes in bytes, and they share the same space as your storage provisions. Your service’s memory also affects your vector index quota.

Your vectors also share the same memory as your system, meaning that a large vector index will consume a lot of memory during a vector search, potentially affecting other processes on your partition. Because of this, vector quotas are increased or reduced depending on your available memory and vector index size.

Vectors increase per partition — the more partitions you add to your service, the higher your vector quota.

Your vector index size is determined by the amount of data, the algorithms you use, and the overhead from updating documents in the index. The chosen algorithm — for instance, HNSW — will use more memory compared to ANN. Each algorithm has its own data types and structures, which contribute to how much memory your vector index uses during a vector search.

Tips on Resource Usage and Behavior in Azure AI Search

Don’t forget to delete a deployment when you’re not using it — make it a habit to check your quota in the Azure AI portal regularly to monitor resource usage and save costs.

Also, note that it usually takes a while for models to be ready after creating them. The same applies to permissions on resources. It may be almost instant, or take anywhere from 15 minutes to an hour. So, when you create a resource, deploy a model, enable permissions, and are still unable to access them, be sure to wait a while before trying again.

A specific requirement of Azure AI Search and Azure OpenAI is that both resources must be available in the same region. Before checking this, be absolutely certain you’ve provided all the necessary requirements for your actions through any of the access points, as some error responses may be vague, or even misleading. Visit https://learn.microsoft.com/en-us/azure/search/cognitive-search-common-errors-warnings for troubleshooting help.

In the next segment, you’ll build an app that uses embedding, semantic search, and vector search in Azure AI Search.