Home / Query understanding / Semantic Autocomplete and Query Suggestions

Semantic Autocomplete and Query Suggestions

Semantic autocomplete suggests queries as the user types by combining three layers: prefix completion that extends the typed letters, fuzzy completion that tolerates typos, and semantic suggestions that find related phrases by meaning. Classic autocomplete only matches prefixes, so “trai” becomes “trail running shoes” but “running shoes” never suggests “trail runners” and a typo suggests nothing. Adding trigram matching handles misspellings, and embedding the partial query lets the system propose phrases that mean something similar. Suggestions should come from a dedicated collection of phrases, built from past successful queries and item titles, ranked by popularity and filtered so every suggestion leads to results. Latency matters more than anywhere else in search, because suggestions must keep up with typing. In Weaviate, a suggestion collection can hold each phrase with field and trigram tokenization plus a vector; Weaviate’s documentation lists search-as-you-type among the uses of trigram tokenization.

What is semantic autocomplete?

Semantic autocomplete is a query suggestion feature that proposes complete queries while the user is typing, using meaning as well as letters to choose what to suggest. It helps users finish queries faster and phrase them in ways the system can answer.

Traditional autocomplete is a prefix lookup. The user types “trai” and the system lists stored phrases that start with those letters, such as “trail running shoes” and “trail mix recipe”. It is fast and predictable, but it only knows what the user has literally typed so far.

Semantic autocomplete adds understanding. If the user types “comfy shoes for runs”, it can suggest “cushioned running shoes”, even though no stored phrase starts that way. If the user mistypes “trial runing”, it can still suggest “trail running”. The goal is the same as semantic search, closing the gap between how users phrase things and how the catalogue is described, applied before the query is even finished.

Autocomplete is one of several query-side techniques, alongside rewriting and expansion, covered in query understanding.

Which layers does semantic autocomplete use?

Semantic autocomplete uses prefix completion for typed letters, fuzzy completion for typos and semantic suggestions for related phrasing, whose results are merged and ranked. Each layer catches cases the others miss.

Prefix completion is the backbone. It answers instantly and matches what most users expect from a search box. It is also the most precise layer, because a stored phrase that starts with the typed letters is very likely what the user means.

Fuzzy and semantic layers widen the net. Fuzzy completion uses character-level matching, such as trigrams, to survive misspellings, as covered in typo tolerance and spelling correction. Semantic suggestions embed the partial query and look for nearby phrases, which helps when users describe what they want in their own words. They are most useful once the user has typed a few words, since a fragment of a single word carries little meaning.

Where should suggestions come from?

Suggestions should come from a curated collection of phrases, such as past queries that returned good results, item or document titles and editor-chosen terms, rather than from the documents themselves. Suggesting a query that returns nothing is worse than suggesting nothing.

Past queries are the richest source, because they reflect how real users phrase things. Filter them carefully: keep queries that returned results and led to clicks, remove rare one-off strings, and exclude anything personal or inappropriate. Counts of how often each phrase was searched become the main ranking signal.

Titles and categories fill gaps for new content and for items that are rarely searched yet. Curated terms cover synonyms and brand names. Whatever the source, each suggestion should be checked to return results, and stale phrases should be pruned when content changes. Search analytics, covered in online search metrics and analytics, supply the data.

How do you build semantic autocomplete in Weaviate?

You build semantic autocomplete in Weaviate with a small suggestion collection that stores each phrase with field and trigram tokenization, a popularity count and a vector, then query it three ways. Each query serves one layer.

from weaviate.classes.config import Configure, Property, DataType, Tokenization
from weaviate.classes.query import Filter, Sort

client.collections.create("Suggestion",
    vector_config=Configure.Vectors.text2vec_weaviate(source_properties=["phrase"]),
    properties=[
        Property(name="phrase", data_type=DataType.TEXT, tokenization=Tokenization.FIELD),
        Property(name="phrase_tri", data_type=DataType.TEXT, tokenization=Tokenization.TRIGRAM),
        Property(name="count", data_type=DataType.INT),
    ])
sugg = client.collections.use("Suggestion")

def suggest(typed):
    prefix = sugg.query.fetch_objects(filters=Filter.by_property("phrase").like(f"{typed}*"),
                                      sort=Sort.by_property("count", ascending=False), limit=5)
    fuzzy = sugg.query.bm25(query=typed, query_properties=["phrase_tri"], limit=3)
    semantic = sugg.query.near_text(typed, limit=3) if len(typed.split()) > 1 else None
    return prefix, fuzzy, semantic

The three query types were run on Embedded Weaviate 1.30.5 over three toy phrases with self-provided vectors as an API check. The prefix “trai” returned “trail running shoes” and “trail mix recipe” in count order, the typo “trial runing” returned “trail running shoes” first through the trigram field, and the vector query returned the closest phrases. Phrases should be stored in lowercase so the Like filter on the field-tokenized property matches typed input.

Size matters. Weaviate’s documentation notes that each Like filter iterates over the entire inverted index for that property, so its time grows linearly with the number of objects. Keeping suggestions in their own small collection, rather than filtering the main corpus, keeps prefix queries fast.

How should suggestions be ranked?

Suggestions should be ranked mainly by how often each phrase is searched and how well it performs, then adjusted for recency, the user’s context and which layer produced it. Prefix matches usually come first.

Popularity is the strongest signal: a phrase searched thousands of times is a safer suggestion than one searched twice. Success signals refine it, favouring phrases whose searches led to clicks or purchases. Recency helps for trending topics and seasonal items. Personal history can promote phrases the user has searched before, if privacy policy allows.

Merging layers needs a rule. A common approach places exact prefix matches first, then fuzzy matches, then semantic suggestions, while removing duplicates across layers. Diversity matters too: five variations of the same phrase waste space, a problem that maximal marginal relevance addresses for results lists.

How fast does autocomplete need to be?

Autocomplete needs to respond faster than any other search feature, because suggestions are requested on almost every keystroke and stale suggestions are useless once the user has typed more. Design choices follow from that budget.

Debouncing reduces load by waiting for a short pause in typing before sending a request, and cancelling outdated requests avoids showing suggestions for an earlier prefix. Caching suggestions for common prefixes removes most of the work, since many users type the same first letters. The general principles are covered in search latency.

The semantic layer is the most expensive, because it needs an embedding of the partial query. Running it only after a word boundary, or only when prefix results are thin, keeps costs down. Embedding cost per request is estimated in the embedding cost calculator.

How does autocomplete relate to other query techniques?

Autocomplete relates to other query techniques by acting before the query is submitted, while expansion, rewriting and decomposition act after it, so together they shape the query on both sides of the search button. They share data and models.

Suggestions steer users towards queries that work, which reduces the need for later fixes. When users ignore suggestions, the system can still rewrite or expand the query, as described in query rewriting and query expansion. Complex questions may still need splitting, as covered in query decomposition.

Intent can shape suggestions too. A prefix that looks like a product code should suggest codes, not descriptive phrases, an idea covered in query intent classification. Generating several query variants, as in multi-query retrieval or HyDE, follows the same logic of reformulating what the user typed.

What can go wrong with semantic suggestions?

Semantic suggestions can go wrong by proposing phrases that are related but not what the user wants, by surfacing inappropriate or private phrases from logs, and by drifting as content changes. Each needs a guard.

Relatedness is the main risk. An embedding of “running shoes” sits near “running socks” and “marathon training”, which may be useful or distracting depending on the user. Restricting semantic suggestions to the same category, or showing them in a separate “related searches” area rather than mixing them with completions, keeps the main list predictable. The distinction is discussed in semantic similarity vs relatedness.

Logs need filtering. Raw query logs can contain names, account numbers or offensive text, so suggestion sources should pass through block lists and minimum-frequency thresholds before anything is shown. Refresh the collection regularly so suggestions for retired items disappear.

How do you measure autocomplete quality?

You measure autocomplete quality by how often users accept suggestions, how many keystrokes suggestions save, and whether accepted suggestions lead to successful searches. Acceptance alone can mislead.

Track the acceptance rate and the position of accepted suggestions, which shows whether the best suggestion is near the top. Keystrokes saved measures how much typing the feature removes. Most important is downstream success: a suggestion that users accept but that leads to poor results is harmful.

Review suggestions that are shown often but rarely accepted, and accepted suggestions that lead to zero results or quick abandonment. These lists point directly to phrases to remove, re-rank or fix. Test semantic suggestions separately, since they are the most likely to surprise users.

Semantic autocomplete suggests queries as users type by combining prefix completion, fuzzy completion for typos and semantic suggestions for related phrasing, then ranking the merged list by popularity, success and context. Build suggestions from a curated phrase collection of successful past queries and titles, never from raw documents. In Weaviate, store each phrase with field and trigram tokenization, a count and a vector in a small collection, since Like filters scan the property’s whole index. Keep responses fast with debouncing and caching, run the semantic layer only when it helps, and judge quality by whether accepted suggestions lead to good results.