Home / Foundations / Semantic Similarity vs Semantic Relatedness

Semantic Similarity vs Semantic Relatedness

Semantic similarity measures how alike two things are in kind, while semantic relatedness measures how strongly they are connected in any way, so cat and dog are similar, but cat and litter are only related. Every similar pair is related, but many related pairs are not similar: coffee and cup, doctor and hospital, hot and cold. The distinction matters for search because embedding models learn from which words appear in similar contexts, and that signal captures relatedness as much as similarity. A vector search for one product can therefore return its accessories, its opposite or a loosely connected item. Weaviate’s academy shows the effect: a vector search for “action” returned the comedy Sister Act among action films, which the course describes as semantically related but unexpected. Filters, hybrid search, rerankers and intent detection help a system return the kind of match a query actually wants.

What is the difference between semantic similarity and semantic relatedness?

Semantic similarity is the degree to which two concepts share properties and could substitute for each other. Semantic relatedness is the degree to which they are associated by any relation, including function, part, cause or opposition, so similarity is a narrow case of relatedness.

Similar things are alike. A cat and a dog are both small domestic mammals kept as pets; in many sentences one could replace the other. A car and an automobile are synonyms, the strongest case of similarity. Similar concepts sit in the same category and share features.

Related things are connected. A cat and its litter box are used together but are nothing alike. A doctor and a hospital are linked by place, a cup and coffee by function, hot and cold by being opposite ends of one scale. Relatedness covers all of these associations, and similarity is just one of them.

Linguists and psychologists have long separated the two, because people judge them differently when asked. Asked whether “coffee” and “cup” are similar, most people say no; asked whether they are related, most say yes. The general idea of meaning-based matching is introduced in semantic matching.

Which word pairs are similar, related, or both?

Word pairs show the difference when they are related but not alike, such as cat and litter or coffee and cup, or when they are opposites, such as hot and cold. Synonyms and category siblings are both similar and related.

Antonyms are the most surprising case. Hot and cold mean opposite things, yet they appear in the same contexts, describe the same property and are often mentioned together. By relatedness they are close; by similarity of meaning they are far apart. For search, mixing them up can be serious: a query for “hot drinks” returning iced drinks is a related result that answers the wrong question.

Researchers built separate benchmarks to measure the two. WordSim-353, from 2002, asked people to rate word pairs without separating the notions, and Agirre and colleagues later split it into similarity and relatedness subsets. SimLex-999, by Hill, Reichart and Korhonen in 2015, was designed to score similarity only, rating pairs such as coffee and cup low even though they are strongly related.

Why do embeddings blur similarity and relatedness?

Embeddings blur similarity and relatedness because they learn from which words and texts appear in similar contexts, and related concepts share contexts as often as similar ones do. Distance in vector space mixes both signals.

The idea goes back to the distributional hypothesis: words that occur in similar contexts tend to have similar meanings. Word2vec and GloVe, covered in word2vec and GloVe, learn exactly this signal. But “litter” appears near “cat” constantly, and “cold” appears in the same sentences as “hot”. The training objective rewards placing them close, regardless of whether they are alike.

Weaviate’s article on vector databases describes embeddings as capturing contextual relationships, such as dog, wolf and cat being related animals, and notes that semantic search returns results across synonyms, paraphrases and loosely related concepts. That breadth is the strength of semantic search, and also its weakness when a query needs a narrower kind of match.

Modern sentence models reduce the problem but do not remove it. Models trained on question and answer pairs learn relevance, which is closer to what search needs, as discussed in Sentence-BERT and transformers and BERT in search. Even so, closely related but wrong passages remain one of the most common retrieval errors.

How does relatedness show up in search results?

Relatedness shows up in search results as items connected to the query but not of the kind the user asked for. Examples include accessories for a product, the opposite of a property, or a film that merely mentions the topic, and users often find them confusing.

Weaviate’s academy course on search types gives a clear example. A vector search for “action” over a film collection returned Last Action Hero first and Sister Act second, ahead of Mission: Impossible and Inception. The course lists Sister Act as semantically related but unexpected, a result that makes sense to the model but not to a user who wanted action films.

A second effect is that vector search always returns something. Weaviate’s documentation notes that a search for “SkyBlue” over vectors for “Red”, “Crimson” and “LightCoral” still returns the closest colour, even though none is a good match. Related but irrelevant results fill the list when nothing truly similar exists. The diagnosis of such cases is covered in why vector search returns irrelevant results.

How do you return the kind of match a query wants?

You return the kind of match a query wants by deciding whether it needs similar items, related items or exact matches, then constraining the search with filters, hybrid scoring, reranking or thresholds. The vector neighbourhood alone cannot decide.

Structured data separates kinds. If items carry a type or category, a filter restricts results to substitutes or to accessories, depending on what the interface is for. A “similar products” widget filters to the same category; a “goes well with” widget does the opposite. The mechanics are covered in metadata filtering.

Scoring and thresholds help too. Hybrid search lifts results that share the query’s exact words, which pushes related but differently named items down. A cross-encoder reranker reads query and result together and scores relevance directly, as described in cross-encoder rerankers. Weaviate also offers limits, autocut and distance thresholds to drop weak matches, and diversity selection with MMR, added in 1.37.3 for vector search, to avoid filling results with near-duplicates.

How do you separate similar and related results in Weaviate?

You separate similar and related results in Weaviate by storing an item type and filtering on it, so the same vector search can serve substitutes or complements on demand. A distance threshold drops weak matches.

from weaviate.classes.query import Filter, MetadataQuery

items = client.collections.use("Item")       # name, kind: product | accessory | other

similar = items.query.near_text("cat food", distance=0.5, limit=10,
    filters=Filter.by_property("kind").equal("product"))      # substitutes

related = items.query.near_text("cat food", distance=0.5, limit=10,
    filters=Filter.by_property("kind").equal("accessory"))    # complements

The filtered pattern was run with near_vector on Embedded Weaviate 1.30.5 over five toy items as an API check. The accessory filter returned only cat litter and the scratching post, while the unfiltered search returned both foods and both accessories and left out the garden hose, which was beyond the distance threshold. The near_text form shown requires a configured vectorizer.

Without a type field, a reranker or an intent classifier can play the same role. Product catalogues often already hold the needed structure in their category trees, so mapping categories to substitute and complement relations is usually a one-time task. Routing queries by what they ask for is described in query intent classification.

Why does the distinction matter for RAG and evaluation?

The distinction matters for RAG and evaluation because related but non-answering passages look relevant to a retriever, mislead the language model and inflate relevance metrics if judges are not careful. Relevance is about answering, not association.

In RAG, a passage about a related topic can crowd out the passage that answers the question. The model then writes a fluent answer from the wrong context, and nothing in the output warns the reader. Relevance judgements for test sets should therefore ask whether a passage answers the query, not whether it is about the same subject, as discussed in relevance vs recall.

The broader history of meaning in retrieval, from latent topics to contextual models, is covered in latent semantic indexing, the vector space model and semantic search at Google. Structured relations, which state how things are related rather than inferring it, are covered in knowledge graphs in search. The geometry behind distances is covered in high-dimensional vector space and the curse of dimensionality, and the field’s basics in what is information retrieval. Systems topics such as cache hits and misses depend on the same similarity scores.

Semantic similarity is about being alike, as with cat and dog; semantic relatedness is about any connection, as with cat and litter, coffee and cup, or hot and cold. Embeddings learn from shared contexts, so they place both kinds of pair close together. That is why vector search can return accessories, opposites or loosely connected items, like Sister Act for “action” in Weaviate’s academy example. Decide what each query needs, then use type filters, hybrid search, rerankers, thresholds and intent detection to deliver it, and judge relevance by whether a result answers the query.