Keyword Match vs. Semantic Relevance: How to Tell Whether a Ranking Is Good

Two ways to decide that a result fits a query, and a simple method for judging which ranking is better: measure it against people's judgments.

Synthetic dataExamples on this page use synthetic data created for illustration.

On this page
  1. Two ways to say “relevant”
  2. Measure against judgments
  3. A worked example
  4. Pitfalls
  5. A routine that works
  6. Combining the two
  7. In short

Search and recommendation systems have to answer two different questions. First: how do we decide that an item fits a query? Second, and harder: once we have a ranking, how do we know it is any good?

Two ways to say “relevant”

Keyword matching looks for the query’s words in the item. Better versions weigh the words: a word that appears often in this item but rarely elsewhere counts for more. BM25 is the best-known formula of this kind. It is fast, and you can always point at the words that caused a match. Its weakness is vocabulary mismatch: a search for “car” will miss a page that only says “automobile”.

Semantic matching turns texts into vectors of numbers so that similar meaning gives nearby vectors. It handles paraphrase and related concepts well. Its weaknesses are the mirror image: it can drift to things that are merely on the same topic, it often blurs negation, exact names and numbers, and it is harder to explain why an item matched.

Neither is simply better. Real systems often combine them. What decides between them is not argument but measurement.

Measure against judgments

The standard method is plain:

  1. Collect realistic queries.
  2. For each, have people grade the returned items, for example from 0 (not relevant) to 3 (exactly what was wanted).
  3. Compute a number for each approach and compare.

Counting how many good items are returned is a start. Precision and Recall do this. But two rankings can return the same good items and still differ a lot, because users read from the top. A good metric should reward putting the best items first.

A worked example

The grades below are synthetic. Two rankings return the same five items for one query, in different orders. The grades are listed by position.

Position12345
Ranking A32010
Ranking B03201
Two bar charts of the same five results. In Ranking A the highest-graded result is first and nDCG is 0.985; in Ranking B it is second and nDCG is 0.689.
Same results, different order: precision at 3 is identical, nDCG is not.

Both rankings have two relevant items in the top three, so precision at 3 is 2/3 for each. They are clearly not equally good: A puts the best item first.

Discounted cumulative gain (DCG) adds up the grades but discounts lower positions:

DCG@k=∑i=1krelilog⁡2(i+1)\text{DCG@}k = \sum_{i=1}^{k} \frac{rel_i}{\log_2(i+1)}

Dividing by the best possible DCG for the same items gives normalized DCG (nDCG), a score between 0 and 1.

DCG@5Ideal DCG@5nDCG@5
Ranking A4.694.760.985
Ranking B3.284.760.689

The ideal ordering for these items is grades 3, 2, 1, 0, 0. Ranking A is almost ideal; B is far from it. Precision could not see the difference. nDCG does.

Pitfalls

  • Too few judged queries. Ten queries can mislead. Aim for dozens, and look at the spread, not only the average.
  • Judges disagree. Write down what each grade means, and check how often two people give the same grade.
  • Clicks are not judgments. People click what is shown first. Click data mostly measures position.
  • Tuning on the test set. If you adjust the system until the judged set looks good, the score stops meaning anything. Keep some queries aside; this is Overfitting by another route.
  • Not measuring after a change. A rule tweak that helps one query often hurts another. Re-run the same set every time.

A routine that works

  1. Write 30 to 50 realistic queries.
  2. Judge the top results for each, with a short written guide.
  3. Score each approach with precision, recall and nDCG.
  4. Read the worst failures by hand. They tell you more than the averages.
  5. Keep the judged set, and re-run it after every change.

Combining the two

Many production systems do not choose. They retrieve candidates with both methods, merge the lists, and let a ranking step decide the order. A simple way to merge is reciprocal rank fusion: each list gives an item 1 / (60 + position) points, and the points are added. An item that is near the top of both lists beats an item at the very top of only one. Because the merge is arithmetic on positions, it needs no tuning of scores that live on different scales, and every point can be explained (“it was third in the keyword list and second in the meaning list”).

Whichever way the two are combined, the same judged queries decide whether it helped. Run the keyword method alone, the meaning method alone, and the combination over the same judged set, and compare their nDCG. If the combination does not beat the better of the two, it is adding complexity without adding quality.

In short

Keyword matching is transparent and brittle; semantic matching is flexible and opaque. Which one fits your case is an empirical question, and the only reliable answer is a small, honest, repeatable measurement.

References

  1. Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze. Introduction to Information Retrieval . Cambridge University Press, 2008. ISBN 978-0521865715.
  2. Kalervo Järvelin, Jaana Kekäläinen. Cumulated Gain-Based Evaluation of IR Techniques . ACM Transactions on Information Systems, 2002. DOI: 10.1145/582415.582418
  3. Stephen Robertson, Hugo Zaragoza. The Probabilistic Relevance Framework: BM25 and Beyond . Foundations and Trends in Information Retrieval, 2009. DOI: 10.1561/1500000019
  4. Gordon V. Cormack, Charles L. A. Clarke, Stefan Buettcher. Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods . Proceedings of the 32nd International ACM SIGIR Conference, 2009. DOI: 10.1145/1571941.1572114