AI Search

Softadmin®'s AI Search provides the ability to search for text not only by exact matches, but also by meaning. It consists of two parts: an HNSW (Hierarchical navigable small world) index for semantic searching and a full-text index for finding exact matches. It's built with AI in mind, with a focus on providing the chunked search results for large language models.

The AI Search can function without a full-text index, but not without the HNSW index. If no full-text index is created, only the semantic portion of the hybrid search will be available.

If the system is running on SQL Server 2025 or later and has access to SQL Server's built in vector index, consider that instead as it generally will provide shorter query and indexing times. You can still use it on the newer versions, but the AI Search is mainly aimed at systems running older versions of SQL Server.

The AI Search is not available in Cloud edition.

HNSW Index

An HNSW is a network of vector embeddings (see for example the Embedding component) of documents. When a document is indexed, it is chunked (see SoftadminUtil.String_Chunk) and then embedded. The network is then built using the embeddings by connecting chunks that have vectors that are similar. Building the network this way links chunks have a similar meaning together. When we want to find a piece of text in our index we can embed our query into a query vector and then traverse the index efficiently.

The AI Search can have multiple HNSW indexes. Since HNSW indexes scale well, it is recommended to have as few indexes as possible. The only reason to create a new index is when you know that there won't be any queries that want to fetch from both, because searching two indexes is far more expensive than searching one big. A scenario where it is reasonable to split is this: index 1 contains support tickets and index 2 contains source code. It's rare that you don't know which one you want to search through, so splitting it into two indexes is a good idea. Smaller indexes are faster to search through, so when a clear line between types of queries can be drawn you should create a new index.

Chunks

Chunking is necessary since the embedding models usually have a limit to their input. It is also usually desirable to return chunks of texts and not the entire document to AI models. If the AI searches for something in a manual it will be easier for it to process the small chunk that's relevant and not the entire document. Chunk size and overlap is set per index and not entry.

Chunk Settings

Chunking is important because the search returns text chunks and embeddings describe chunks rather than complete documents. Each index has its own chunk size and chunk overlap.

  • Avoid making the chunks too small. Make chunks large enough to contain the context needed to understand a passage. Going below a chunk size of ~300 is not recommended.
  • Making chunks too large has risks as well. The longer a text is the less important specific information in that passage becomes, meaning it's going to be harder to find that exact chunk when searching. The search query usually has to become longer and more detailed to make up for it.
  • Use overlap so that no information is split, cut or lost between chunk splits. (~10% of the chunk size as overlap is a good rule of thumb)

The exact best values depend on the document structure, embedding model, and what the purpose is. A chunk size between 1000 to 2000 with ~10% overlap is good for general purposes. Smaller chunk sizes tend to be better for shorter queries where facts are important (looking up answers in a FAQ for example) while larger sizes are better for longer, more technical documents.

Embedding Settings

You must provide Softadmin® with an embedding model in order for it to be able to embed the texts it needs to index. This embedding model must support variable vector dimensions which almost all modern models can. The vectors must themselves be normalized, which almost all are.

Adding an Index

You can add an index in the AI Search menu item. The HNSW indexes are deployed, but their contents (entries, chunks, embeddings) are not.

Important

Carefully consider how many indexes you create and how they are used. Searching through one large index is significantly faster than searching through several small indexes.

Deleting an Index

You can delete an HNSW index from the AI Search menu item. For huge indexes it is recommended that you delete the index on the production instance before you deploy to reduce the risk of the deploy timing out. For small indexes it will usually be fine to let the deploy delete the index.

Important

If you do not delete the index on the production instance you need to make sure the HNSW index job is not running on that instance when deploying to it (via a service window for example).

Rebuilding

Rebuilding an index is usually something you don't want to do. The only reason is if you suspect that the index has become corrupt or contains bad data. There could also be other things that degrade performance such as frequent deletions which might make some parts of the index hard to reach. Then it might be good to rebuild the index.

You must rebuild the index when changing the embedding model and re-embed all chunks. This is done via the 'Save and redo embeddings' button in the embedding model configuration. This is because the vector embeddings stored will not be comparable to the new vector embeddings, which will result in extremely poor search results. You must do this on all instances.

Full-text Index

In addition to the HNSW indexes, a single full-text index can be used. Unlike the HNSW indexes, the AI Search only uses one full-text index. It can be created from the same menu item as the HNSW indexes. This full-text index is a SQL Server full-text index.

Unlike the HNSW indexes, the full-text index is not deployed and needs to be created on each system instance separately.

Language

Since only one full-text index can be created on a table, language needs to be chosen with care. If you plan to store documents that may be of several different languages the "Neutral" option is recommended. If you only store documents with only a few languages and one appears more often than others you can set the full-text index to that language. The other languages will suffer a bit depending on how much their syntax and grammar rules differ from the main language. One case where you may want to do this is if, for example, you have a 90/10 split between Swedish and Norwegian texts. Then it might be preferable to simply create the full-text index with Swedish as the language.

The index can always be deleted and created anew with a different language. However, doing so will force SQL Server to re-index all text.

After creating an HNSW index (and optionally creating a full-text index) you can start to add entries to the index. The following procedures are used to insert, update and delete entries in the HNSW and full-text indexes:

Searching is done using the SoftadminApi.AiSearchIndex_Search procedure. See the documentation for each procedure for details.