Home / How it works / Semantic Matching: How Meaning Is Compared Between Texts

Semantic Matching: How Meaning Is Compared Between Texts

Semantic matching is the comparison of two pieces of text by meaning rather than by shared words, producing a score for how closely they say the same thing. It lets “how do I get my money back” match “refund policy” although they share no words. Most systems do it by turning each text into an embedding vector and measuring cosine similarity between the vectors. A bi-encoder model embeds the texts separately, which is fast enough to search millions of documents. A cross-encoder reads both texts together and scores the pair directly, which is more accurate but too slow for anything beyond reranking a shortlist. Semantic matching has known weak spots. Negation, numbers, swapped roles and rare codes can look similar to a model when they mean different things. Production search therefore pairs semantic matching with keyword search, filters and reranking.

What is semantic matching?

Semantic matching is the task of deciding how close two texts are in meaning, whatever words they use. In search, one text is the query and the other is a document or passage.

Lexical matching, the basis of keyword search, counts shared words. It finds “reset password” for the query “reset password” but misses “I forgot my login”. Semantic matching sees that the two express the same need. That is the core idea of semantic search, explained in how semantic search works.

The term covers related tasks with different goals. Semantic textual similarity scores how alike two sentences are. Paraphrase detection decides whether two sentences say the same thing. Query-document matching decides whether a passage answers a question, which is asymmetric: a short question and a long answer can match without being similar. The difference matters, as covered in asymmetric vs symmetric semantic search.

How does semantic matching differ from keyword matching?

Semantic matching differs from keyword matching by comparing meaning through learned representations, while keyword matching compares the words themselves, possibly after stemming or synonym expansion. There is a spectrum between them.

Exact matching needs identical words. Normalisation, such as stemming and synonym lists, catches word forms and known alternatives, as described in synonyms and related terms. Embeddings go further, matching paraphrases and related ideas without any list. Cross-encoders go furthest, weighing how each word of the query relates to each word of the passage.

“Semantic keyword search” usually means combining the two ends: keyword matching for exact terms plus semantic matching for meaning. That combination is hybrid search, compared in semantic search vs keyword search. Each level catches matches the others miss, which is why systems layer them.

How is semantic similarity calculated?

Semantic similarity is usually calculated by embedding both texts with the same model and taking the cosine similarity of the two vectors. Higher similarity means closer meaning in the model’s view.

A sentence embedding model, such as one from the Sentence-BERT family, turns each text into a fixed-length vector of a few hundred numbers. The model was trained on pairs of related and unrelated texts, so related texts end up pointing in similar directions. Cosine similarity measures the angle between the vectors, from 1 for the same direction down to minus 1 for opposite. Dense vectors and cosine vs dot product vs Euclidean distance cover the details.

Vector databases store document vectors in an index so a query vector can find its nearest neighbours quickly. In Weaviate, a near_text query embeds the query with the collection’s model and returns the closest objects with their distances. Scores are meaningful for ranking within one model, not as absolute measures, as explained in relevance scores.

Which models can perform semantic matching?

Semantic matching can be performed by bi-encoders, which embed each text separately, and by cross-encoders, which process both texts together; late-interaction models sit between them. Each fits a different stage of search.

Bi-encoders are the workhorse of retrieval. Because documents are embedded once in advance, a query needs only one model call plus a vector lookup, so millions of documents can be searched. Cross-encoders feed the query and a document through the model together and output a relevance score. That captures fine interactions such as negation or word order, but needs one model call per pair, so it is used to rerank the top few dozen results. Late-interaction models such as ColBERT keep token vectors and compare them, trading storage for precision.

Model choice matters more than any other setting. Benchmarks such as the STS Benchmark, which rates sentence pairs from 0 to 5, and the retrieval tasks in MTEB show how models compare. Leaderboard positions change often, and a model that tops a general benchmark may not lead on your documents. Testing on your own data is still essential, as covered in choosing an embedding model.

Where does semantic matching go wrong?

Semantic matching goes wrong when two texts share topic and most words but differ in a small, decisive detail, such as a negation, a number, a name or who did what to whom. Embeddings tend to place such pairs close together.

A sentence embedding summarises the whole text, so one changed word has little effect on the vector. “Recipes with sugar” and “recipes without sugar” share almost everything, and a bi-encoder may rank one for the other. Research such as Ettinger’s 2020 study of BERT found that language models handle negation poorly. Numbers and identifiers are similar: “XK-200” and “XK-2000” look alike to a model but are different products.

The fixes are well known. Keep exact identifiers in keyword search, through hybrid search. Store dates, prices and versions as properties and filter on them. Rerank top results with a cross-encoder, which reads word order and negation more reliably. Why vector search returns irrelevant results walks through more cases.

How do you measure semantic matching quality?

You measure semantic matching quality by checking how well a model’s similarity scores agree with human judgments, either on sentence pairs or on query-document relevance. The right test depends on the task.

For similarity between sentences, benchmarks such as the STS Benchmark compare a model’s scores with human ratings on a 0 to 5 scale, usually reporting a rank correlation. For search, what matters is whether relevant documents rank first, so retrieval metrics such as nDCG and recall on judged queries are the better test. A model can do well on sentence similarity and poorly on question answering, because the two tasks reward different things.

Build a small set of your own pairs that include the hard cases from your domain: negations, near-identical product codes, and documents that are on topic but do not answer. Score candidate models and settings on it before choosing. How to evaluate semantic search covers the full method.

What are semantic filtering and a semantics database?

Semantic filtering means keeping or removing items based on meaning, such as a similarity threshold or a model’s classification, and a “semantics database” usually refers to a vector database that stores and searches by meaning. Both terms extend semantic matching.

Semantic filtering can use a distance cut-off, dropping results farther than a set distance from the query, or a classifier or language model that labels items by topic before they are filtered exactly. Distance cut-offs are fragile because scores vary by model and query. Labelling items at import and filtering on the label is usually more predictable. Searching vs filtering explains when each fits.

A vector database such as Weaviate stores objects with their embeddings and indexes them for nearest-neighbour search, while also keeping text for keyword search and properties for filters. That combination is what makes semantic matching usable at scale. Vector search and similarity search describe the retrieval side.

How is semantic matching used in a search system?

Semantic matching is used at several stages of a search system: bi-encoder retrieval finds candidates, hybrid fusion adds exact terms, and cross-encoder reranking orders the final list. Each stage applies matching at a different cost.

Documents are split into passages, embedded and indexed, as described in chunking for semantic search. At query time the query is embedded, its nearest passages are found, keyword results are fused in, and the shortlist is reranked. Semantic search architecture shows how the pieces connect, and top-k retrieval covers how many candidates each stage passes on.

Multilingual models extend matching across languages, so a Spanish query can match an English document, as covered in multilingual and cross-lingual semantic search. The index itself, covered in semantic indexing and vector indexes, uses approximate search to make it fast. Exact vs approximate search explains the trade, and sparse vectors and dense vs sparse vectors cover the keyword side.

Semantic matching compares texts by meaning rather than words, usually by embedding both and measuring cosine similarity. Bi-encoders embed texts separately and scale to large collections, while cross-encoders read pairs together and suit reranking. Matching fails where texts share topic but differ in a decisive detail: negation, numbers, roles or rare codes. Pair semantic matching with keyword search for exact terms, filters for structured facts, and reranking for precision. In Weaviate, near_text and hybrid queries apply these layers in one system.