NDCG Calculator (Normalized Discounted Cumulative Gain)

NDCG (Normalized Discounted Cumulative Gain)measures how good a ranked list is, rewarding relevant results placed near the top. It is the headline quality metric for search ranking, recommender systems and learning-to-rank models. The definition here follows Järvelin & Kekäläinen (2002) and the implementation in scikit-learn's ndcg_score.

Positions are 1-indexed. For a predicted ranking with relevance scores rel₁ … relₙ and cutoff k, the score is built in four steps:

1. Gain. Turn each relevance into a gain. Linear gain is gᵢ = relᵢ; exponential gain is gᵢ = 2^relᵢ − 1 (Burges et al., 2005), which rewards highly relevant hits more.
2. Discount. Divide each gain by a position discount dᵢ = log2(i + 1), so rank 1 has discount log2(2) = 1 and lower ranks are penalised more.
3. DCG@k. Add the discounted gains over the top k: DCG@k = Σᵢ₌₁..ₖ gᵢ / log2(i+1).
4. Normalise. Compute IDCG@k — the DCG of the ideal ranking, the same relevances sorted from best to worst — then NDCG@k = DCG@k / IDCG@k, a value in [0, 1].

When IDCG@k is 0 — every relevance is 0 — NDCG is undefined because it would divide by zero. The tool reports 0 and flags it, the same convention scikit-learn uses. If you set k larger than the number of items, it is clamped to the list length with a notice. As a credibility check, the calculator computes NDCG a second way — the gain·discount vector form scikit-learn uses internally — and confirms the two routes agree to floating-point precision. This version scores one ranking and derives the ideal order by sorting the relevances you enter; mean NDCG across many queries is a separate calculation.

Choosing the cutoff k

The cutoff decides how much of the list you are willing to be judged on. Reporting NDCG over the full list flatters a system, because the log discount makes positions 50 to 100 contribute almost nothing while still inflating both DCG and IDCG. Web search teams normally quote NDCG@10 because that is roughly one results page; recommender feeds use @5 or @20; a RAG retriever is usually evaluated at the number of chunks actually pasted into the prompt — if you stuff 8 passages into context, NDCG@8 is the honest number. Pick one k, write it down, and keep it fixed across every model you compare. Changing k mid-experiment changes the scale of the metric, not just the score.

Binary vs graded relevance

NDCG was designed for graded relevance — TREC-style judgements on a 0–3 or 0–4 scale, where 3 means “perfect answer” and 1 means “marginally useful”. It works with binary 0/1 labels too, and many teams use it that way, but with only two grades the metric loses most of what makes it better than simpler alternatives; at that point Precision@K and Recall@K are easier to explain to non-specialists. The gain choice matters more as the scale widens: with grades 0–4, exponential gain makes a grade-4 document worth 15 while a grade-2 is worth 3, so a single misplaced top-grade result moves the score far more than it would under linear gain. Neither convention is “correct” — but a linear NDCG and an exponential NDCG are different metrics and must never be compared to each other.

What NDCG does not tell you

Three limitations are worth stating plainly. First, unjudged documents are treated as relevance 0. If your judgement pool was built from an older system's results, a genuinely good new result that nobody ever labelled is scored as useless, and the new model is penalised for finding it. Second, NDCG is normalised per query, so it cannot tell you whether a query had ten excellent answers or one mediocre one — a query with a single grade-1 document can still score 1.0 simply by ranking that document first. Third, the score says nothing about diversity, freshness or duplicate results: ten copies of the same relevant page score exactly as well as ten distinct ones. Read NDCG alongside a coverage metric such as mean Average Precision, not on its own.

Ranking metrics are easy to confuse because they all produce a number between 0 and 1 from a ranked list. What separates them is which piece of the list they look at and what kind of label they need.

• DCG — the un-normalised sum of discounted gains. Useful as a debugging intermediate, useless as a reported figure, because its ceiling depends on how many relevant documents the query happens to have. Always divide by IDCG before comparing anything.
• NDCG — DCG scaled to [0, 1] by the ideal ordering. Needs graded relevance to shine, scores every position in the top k, and is the default for web search, learning-to-rank and reranker evaluation.
• MRR — the reciprocal of the rank of the first relevant hit, averaged across queries. It ignores everything below that first hit entirely, which makes it the right metric for one-correct-answer tasks and the wrong one for a feed. The Mean Reciprocal Rank calculator works from the same kind of relevance list this page accepts.
• MAP — the mean of Average Precision, which averages precision at every rank where a relevant document appears. It uses binary labels and rewards finding all the relevant items, so it is stricter than NDCG about recall and blind to relevance grades.
• Precision@K / Recall@K — plain counts inside the top k, with no position discount at all. Swapping ranks 1 and 5 does not change Precision@5, but it does change NDCG@5. They are the metrics to quote when a stakeholder needs a number they can reason about without a formula.

A practical pairing for retrieval work: report NDCG@10 as the headline, Recall@K to prove the retriever is not dropping relevant documents, and MRR when a single correct answer exists. If you are tuning a two-stage pipeline, evaluate the first-stage retriever and the reranker separately — a reranker that raises NDCG by 0.04 may not be worth its latency and per-query API cost, and you can only see that trade-off if the two stages are scored apart.

NDCG has no universal pass mark. A score of 0.62 can be excellent on a hard, ambiguous query set and poor on an easy one, so the absolute value is far less informative than the comparison. The bands below are the reading aid this calculator prints next to your result — treat them as rough orientation, not a grading scale.

• 1.000 — perfect. Your ordering already equals the ideal ordering of the same relevances. On a short list this is common and not especially meaningful.
• 0.90 – 0.999 — excellent. The top positions are almost all in the right order; remaining errors are usually deep in the list where the discount hides them.
• 0.70 – 0.90 — good. Typically a correct top result with some shuffling below it, or one high-grade document ranked a few places too low.
• 0.50 – 0.70 — fair. Relevant material is present but not concentrated at the top; this is where reranking usually pays for itself.
• below 0.50 — poor. Check the labels before blaming the model: an off-by-one in how you paired predictions with judgements produces exactly this.

Two sanity checks are worth running before you trust any figure. Reverse your list — the worst possible ordering — and confirm the score drops sharply; if it barely moves, your relevances are probably all equal. Then re-score with the same list sorted descending, which must give exactly 1.000. The preset buttons above the calculator run both checks in one click. Finally, remember that a difference of 0.01 between two models on a few dozen queries is noise; report NDCG over a few hundred queries, or run a significance test before calling a win.

• Järvelin & Kekäläinen (2002), Cumulated gain-based evaluation of IR techniques, ACM TOIS 20(4) — the canonical DCG and normalized form
• scikit-learn — sklearn.metrics.ndcg_score: the log2(i+1) discount and linear vs exponential gain options this tool matches
• Burges et al. (2005), Learning to Rank using Gradient Descent, ICML — origin of the 2^rel − 1 exponential gain
• Wikipedia — Discounted cumulative gain: cross-check of both gain conventions and the IDCG normalization

The formulas on this page were last cross-checked against these sources on 2026-09-06. NDCG is a stable mathematical definition, so this tool needs no rate or schedule updates — only the worked examples are periodically re-reconciled against scikit-learn.