企业官网建设流程全解析

做推荐系统的人，最怕被问一句“你效果怎么样”。你说准确率，对方一脸茫然；你说AUC，对方觉得你老气；真正能体现用户体感的，还是NDCG这类位置敏感指标。NDCG的全称是Normalized Discounted Cumulative Gain，中文一般翻译成归一化折损累计增益，很多人第一次看到这个名字就被劝退了，但吃透之后你会发现排序评估的世界一下子清晰了。这篇文章用最直白的方式讲清楚NDCG的公式来源、Python实现、离线评估实操流程，以及我踩过的几个坑。适合正在做推荐、搜索、广告排序的同学参考，也适合刚入门想搞懂评估指标的新手慢慢读。

1. 推荐系统为什么需要NDCG这类排序评估指标

1.1 离线评估到底在测什么

推荐系统离线评估不是简单看模型“答对没有”。用户面对的是一个按分数排好序的商品列表，大多数情况下只会认真看前几个。一个模型如果能把用户真正想点的内容排到前两名，比把它排到第50名要好得多。所以离线评估必须同时回答三个问题：有没有命中、命中的质量高不高、命中的位置靠不靠前。Precision和Recall能回答前两个，但回答不了第三个，NDCG正好把三者都照顾到了。

在实际推荐场景里，相关性不一定是0和1。用户对一部电影的评分可能是1到5分，或者点击、收藏、购买本身就可以拆成不同权重。NDCG天然支持多级相关性，你可以直接把真实评分或加权后的相关度代入公式，不需要强行二值化。这是它比很多传统分类指标更贴近推荐业务的原因。

另外，不同用户的历史行为数量差异非常大。有的用户只交互过两个商品，有的用户交互过两百个。如果只用DCG原始分，这两个用户之间完全没法比较。NDCG通过除以当前列表的最优DCG，把分数压到0到1区间，这样不同用户、不同查询之间才具备横向对比的可能。这也是“归一化”三个字最关键的价值。

1.2 NDCG的设计演进：从CG到DCG再到NDCG

我们一步一步推。最原始的指标是累计增益CG，也就是Cumulative Gain，公式就是所有位置的相关性分数直接相加。假设某个推荐列表的真实相关性是[3,2,0,1,4]，那么CG等于3+2+0+1+4=10。问题非常明显：CG完全不关心顺序，把列表倒过来变成[4,1,0,2,3]，CG还是10。这不是我们想要的排序评估指标。

于是有了折损累计增益DCG，也就是Discounted Cumulative Gain。它给每个位置加了一个随排名增加而变小的折扣因子，常见公式是：

DCG@K = sum_{i=1}^{K} rel_i / log2(i+1)

这里的i从1开始计数。第一个位置除以log2(2)，也就是1，相当于不被折损；第二个位置除以log2(3)，大概1.585；第三个位置除以2。越往后，分母越大，单项贡献被压得越低。这就模拟了“用户只看前排”的心理。

后来业界更喜欢用带指数的版本：

DCG@K = sum_{i=1}^{K} (2^{rel_i} - 1) / log2(i+1)

这个版本放大了高相关性结果之间的差距。比如评分4和5，在线性版本下差别不大，但在指数版本下，高分段会被进一步拉开。如果你的相关性是多级评分，指数版更合理；如果只用0和1，两个版本完全等价。选择哪个版本，要在实验报告里写清楚，否则别人复现你的指标会对不上。

但DCG仍然不能跨列表比较，因为不同列表的相关性总和不同。有的用户相关物品多，DCG天然就高；有的用户相关物品少，DCG天然就低。于是我们引入“理想排序”的概念，把当前列表按真实相关性从高到低排序，计算这个理想列表的DCG，也就是IDCG。然后用DCG除以IDCG，得到NDCG。这个比值衡量的是“你排得有多接近最理想状态”，1代表完美排序，0代表差到极致。

1.3 它和MAP、AUC这些指标比，强在哪里

MAP要求相关性必须是二值的，对分级评分不太友好，而且它对“完全没命中”的查询惩罚很重。AUC只看全局排序的相对关系，主要衡量正负样本两两对比的正确率，但AUC对头部排序不敏感。你把一个正样本从第1位移到第10位，AUC可能变化非常小，用户体感却是天壤之别。NDCG则给每个位置分配了不同梯度，位置越靠前，权重越大，这正好和“用户只关心前排结果”的实际行为一致。

不是说AUC没用。在召回阶段、二分类评估时，AUC仍然是很好的全局指标。只不过到了精排调优和上线前评估阶段，NDCG更能反映真实体验。成熟的团队通常把AUC和NDCG一起看：AUC看整体排序质量，NDCG看头部排序质量。

2. NDCG公式与Python实现：从零写一个可用版本

2.1 写代码前必须抠清楚的三个细节

很多初学者看到网上各种实现，以为随便抄一个就行，结果算出来的数和论文对不上。最常见差异有三个：一是位置i从0开始还是从1开始；二是log的底数是2还是自然常数e；三是相关性rel_i直接用原始分还是用2^{rel_i}-1。

先说位置。如果用Python的enumerate，索引idx从0开始，第一个位置idx=0。如果希望第一个位置权重为1，分母应该是log2(idx+2)。因为log2(0+2)=log2(2)=1。如果你看到代码里写log2(i+1)，那是用从1开始计数的i，两者本质一样。还有种错误写法是i从0开始但分母写log2(i+1)，那样第一个位置会除以log2(1)=0，直接报错或算出无穷大，这是新手最容易踩的红线。

log底数其实不用纠结。分子分母的折扣是同一个比例关系，换底只会让分子分母同时乘以一个常数，最终NDCG不变。但为了习惯和可读性，多数教程用log2，我也建议你统一用log2，避免代码评审时被问。

第三个点影响最大。若相关性是0到5之间的多级分数，指数版本和线性版本算出来的NDCG数值差距很大。不要在一个实验里混用两种公式。如果你从别人代码里复制了指数版，但要处理二值标签，注意2^{1}-1=1，2^{0}-1=0，结果没问题；但如果处理多级评分还沿用线性版，可能没有充分利用多级信息。

2.2 最小可运行的Python实现

下面这段代码可以直接跑，没有任何第三方依赖：

import math def dcg_at_k(relevances, k=None): if k is not None: relevances = relevances[:k] return sum(rel / math.log2(idx + 2) for idx, rel in enumerate(relevances)) def idcg_at_k(relevances, k=None): sorted_rel = sorted(relevances, reverse=True) return dcg_at_k(sorted_rel, k) def ndcg_at_k(relevances, k=None): dcg = dcg_at_k(relevances, k) idcg = idcg_at_k(relevances, k) if idcg == 0: return 0.0 return dcg / idcg

这段实现的逻辑是：传入一个已经按模型预测分数排好序的真实相关性列表，比如[3,2,0,1,4]，表示模型把第三个物品排第一、第二个物品排第二、第一个物品排第三……然后函数会取前K个位置，计算DCG；再对相同列表按真实相关性降序排序，计算IDCG；最后相除得到NDCG。

如果列表长度不足K，切片操作会返回全部，不会越界。如果IDCG为0，说明当前用户的所有候选真实相关性都为0，这种情况下没有可排序的“正样本”，直接返回0比较安全。你也可以选择跳过这个用户，但必须在实验文档里说明，因为跳过和记0会让最终平均分有差异。

2.3 支持多级相关性的指数版本

如果业务用的是评分、收藏、购买等多级反馈，更推荐使用指数版本：

def dcg_at_k_exponential(relevances, k=None): if k is not None: relevances = relevances[:k] return sum((2 ** rel - 1) / math.log2(idx + 2) for idx, rel in enumerate(relevances)) def ndcg_at_k_exponential(relevances, k=None): dcg = dcg_at_k_exponential(relevances, k) sorted_rel = sorted(relevances, reverse=True) idcg = dcg_at_k_exponential(sorted_rel, k) if idcg == 0: return 0.0 return dcg / idcg

举个例子，假设某用户真实相关性列表是[3,2,0,1,4]，K=5。线性版本下，DCG等于：

3/log2(2) + 2/log2(3) + 0/log2(4) + 1/log2(5) + 4/log2(6)

大概算一下是3+1.2619+0+0.4307+1.5470=6.2396。理想排序是[4,3,2,1,0]，IDCG等于4+1.893+1+0.4307+0=7.3237，NDCG约0.8520。如果换成指数版本，数值会明显改变，高分段之间的差距会被拉开，所以实验报告里必须写清楚用哪个版本。

从可维护性角度，我建议把公式版本直接体现在函数名里，或者加一个参数mode='linear'/'exp'，而不是让使用者自己猜。很多团队代码里出现过“为什么NDCG对不上”的争论，最后排查原因往往是有人混用了两种版本。

2.4 工程化：批量计算多个用户的NDCG

实际评估时不可能一个用户一个用户手动算，我们需要对多个用户批量求平均。下面这个函数接收一组评估记录，每条记录包含用户ID、物品ID、真实相关性和模型预测分数：

from collections import defaultdict def evaluate_ndcg_by_user(records, k=10, exp=False): user_items = defaultdict(list) for user_id, item_id, rel, score in records: user_items[user_id].append((rel, score)) ndcg_list = [] for user_id, item_list in user_items.items(): # 按模型预测分数从高到低排序 sorted_items = sorted(item_list, key=lambda x: x[1], reverse=True) # 取前k个物品的真实相关性 relevances = [rel for rel, score in sorted_items[:k]] if exp: ndcg = ndcg_at_k_exponential(relevances, k) else: ndcg = ndcg_at_k(relevances, k) ndcg_list.append(ndcg) if not ndcg_list: return 0.0 return sum(ndcg_list) / len(ndcg_list)

注意这里每个用户相关物品的数量不一定相同。有的用户只有5个候选，有的用户有200个候选，取前K时K可以大于用户候选数，函数会返回该用户全列表的分数。最终平均时，如果直接对所有用户等权平均，活跃用户数量多并不会导致单用户被重复计算，因为我们在用户级别先平均了。这一点和按样本平均不同，需要根据业务来选。

如果数据量很大，用纯Python处理几十万用户可能会有点慢，可以改用numpy或pandas按用户分组后调用ndcg_at_k，或者使用sklearn.metrics.ndcg_score做批量计算。sklearn的实现要求输入是二维矩阵，行为样本/用户，列为物品，而且对零标签的处理和我们手写版本略有差异，使用前一定要用小样本校验一遍。

3. 实操过程：在推荐系统的离线评估流程中集成NDCG

3.1 从原始评估数据到相关性序列

在真正动手算之前，必须把数据流理清楚。离线评估一般会有一个评测集，里面记录了每个用户在某个时间点后的真实行为。最简单的格式是这样的：

真实标签可以来自显式评分，也可以由隐式反馈生成，比如点击=1，未点击=0。拿到数据后，评估流程固定四步：按用户分组、组内按预测分数降序排序、截取前K个物品、提取这些物品的真实相关性作为relevances列表。

这里有个容易被忽略的点：NDCG只关心排序，不关心模型预测分数本身的值。分数是0.95还是0.99，对同一排序结果没有影响，只有相对大小才有意义。所以你不必担心分数分布是否可解释，只要排序稳定即可。

在排序之前，务必要统一用户内的去重逻辑。如果同一个用户对一个物品有多条预测和标签记录，会产生重复排序，导致NDCG被污染。线上模型一般只输出一个分数，但离线数据拼接时可能出现一对多关系，这时候应该按时间戳取最新记录，或按业务规则去重，而不是简单保留第一条。

3.2 一个可以直接照做的NDCG计算样例

我们用上面的样例数据手算一遍。假设模型对U001的五个物品预测分数排序后，真实相关性序列是[5,4,1,3,0]，也就是说分数最高的物品真实评分5，第二高的真实评分4，第三高的真实评分1，第四高的真实评分3，第五高的真实评分0。K取3，我们用线性版本。

先算DCG@3：

5/log2(2) + 4/log2(3) + 1/log2(4) = 5 + 2.524 + 0.5 = 8.024

然后算理想排序下的IDCG@3。真实相关性从高到低是[5,4,3,1,0]，截取前3个是5、4、3：

5/log2(2) + 4/log2(3) + 3/log2(4) = 5 + 2.524 + 1.5 = 9.024

最后NDCG@3等于8.024除以9.024，约0.889。因为第三位把一个评分3的物品换成了评分1的物品，NDCG从1降到了0.889，这个下降幅度就体现出位置折扣的作用。

如果K从3变成5，第三位的错误会被后面正确排序的部分补充，NDCG可能略有不同。所以报告NDCG一定要带K值，只说NDCG等于0.89不说K，等于没给信息。

3.3 K值怎么选，结果怎么读

K的选择和业务形态强相关。如果是首页信息流，用户基本只看前10个，K可以取5或10；如果是搜索结果页，K取1到5更有意义；如果是站内信或推送，可能只看前3。不要盲目对标其他团队的K，你的产品形态和用户耐心决定了哪个K更有参考价值。

NDCG@K的数值本身没有绝对好坏。一个NDCG@10=0.6的模型不一定是差模型，因为数据集里每个用户相关物品出现的概率差异很大。更合理的做法是做A/B对比：固定同一测试集、同一K、同一公式版本，只看新旧模型NDCG的相对变化。提升0.05可能已经是很明显的排序优化。

还要注意，NDCG对“相关物品数量”非常敏感。如果一个用户只有1个相关物品，这个物品排第2，NDCG@10可能只有0.63；另一个用户有9个相关物品，即使全部排在头部，NDCG也可能接近1。最终平均值会偏向“相关物品多的用户”，这是NDCG的天然特性，不算bug，但解读结果时要有数。

4. 常见问题与排查技巧实录

4.1 相关性标签定义冲突

很多同学在复现论文或开源代码时，发现NDCG数值对不上，第一个要查的就是相关性标签定义。同一个数据集，有的代码把真实评分大于等于4视为相关，评分1到3视为不相关；有的代码直接用评分本身作为多级相关性。这两种做法算出来的NDCG完全不同。

如果是隐式反馈，比如曝光未点击和曝光点击，通常把点击设为1，未点击设为0。但这里有个隐含问题：未点击不代表用户不喜欢，可能只是没看到。所以有些团队会对未曝光物品做随机负采样，参与训练但不参与NDCG评估；有些团队会把曝光未点击都当作负样本。不同的负样本策略会让NDCG基准值有巨大差异。

我建议在代码里把标签生成逻辑写成一个独立函数，并在实验记录里保存标签配置。不要到后面才想起来“我这个0和1到底怎么来的”，否则线上问题排查会非常痛苦。

4.2 为什么排序已经正确，NDCG却不是1

这是个高频问题。如果你按模型分数排序后得到的相关性列表和理想排序完全一致，但NDCG不是1，大概率是下面几个原因之一：

一是K截断方式不一致。比如DCG用了前K个，IDCG却用了完整列表，这样IDCG永远大于等于DCG，排序正确时也很难等于1。解决办法是DCG和IDCG必须用同一个K。

二是位置索引写错。最常见的是用枚举索引直接除以log2(idx+1)，导致第一个位置的权重出现问题，经常算出来偏大或偏小。检查一下你的分母是不是log2(idx+2)。

三是IDCG的计算方式错误。如果你对同一个relevances列表直接调用dcg_at_k，但函数内部又会把列表截断，而IDCG的列表没有先排序，那IDCG甚至可能小于DCG。一定要先排序，再截断。

四是使用了指数版本，但相关性分数没有先转换成对应的指数增益。比如rel=1时2^1-1=1，rel=0时2^0-1=0，看似正常，但如果某个rel是负值，比如相关性可以是-1，指数版本会算出负的增益，NDCG可能变成负数，这种情况很少见，但要心里有数。

4.3 遇到全零样本怎么办

评估集里有些用户可能一条真实交互都没有，或者在你选定的K个候选里没有任何相关物品。这时DCG和IDCG都是0，所以NDCG是0/0的形式。有人直接返回0，有人返回1，有人直接跳过。不同处理方式会让平均值产生偏差。

如果你的目标是评估排序能力，我倾向于跳过这些无法判断的用户，并在报告中注明覆盖用户数。因为一个没有相关物品的用户，无论模型怎么排，NDCG都是0，把它计入平均值会拉低整体分，而且不能反映排序质量的真实差异。但如果你的业务是想评估“个性化推荐是否有用”，把所有无交互用户都记为0也有一定道理。

关键是一旦选定策略，线上线下要一致。不要让训练时用A策略，评估时用B策略，否则结果自欺欺人。另外，在代码里用if idcg == 0: return 0.0时，最好加日志记录被特殊处理的用户数，方便后续审计。

4.4 和MRR、Recall、HitRate怎么配合

NDCG不是万能的，它偏向于“排序好不好”，但不能回答“有没有把相关物品找出来”。一个模型可能只排出了10个相关物品中的一个，但它排到了第1位，NDCG@10会很高；可这个模型召回极差。所以工业界不会只用NDCG做决策。

我现在比较常用的组合是：NDCG@10看头部排序质量，Recall@10看召回覆盖能力，HitRate@10看用户是否至少命中一个。如果NDCG提升但Recall下降，说明模型可能过度聚焦少数热门物品，需要警惕马太效应。如果NDCG没变但Recall提升，说明模型找到了更多相关物品，只是排序还没有把它们放到头部，这时候可以考虑调整损失函数里的位置权重。

用表格整理一下：

5. 从NDCG到更工程化的评估体系

5.1 使用numpy和sklearn加速批量计算

纯Python版本适合理解原理，但当你需要评估几万用户、每个用户几百个物品时，循环会有点慢。这时候可以用numpy做向量化，或者直接使用sklearn的ndcg_score函数。

sklearn的调用方式很简洁：

import numpy as np from sklearn.metrics import ndcg_score # y_true: 形状为 (n_users, n_items) 的真实相关性 # y_score: 形状为 (n_users, n_items) 的模型预测分数 y_true = np.array([ [1, 0, 0], [0, 1, 1] ]) y_score = np.array([ [0.9, 0.5, 0.3], [0.4, 0.8, 0.7] ]) print(ndcg_score(y_true, y_score, k=2))

sklearn的实现会自动按每行的预测分数降序排列，取前K个计算，然后再算出IDCG。但有一点要注意：sklearn要求y_true为非负值，如果包含-1会报错；另外它默认对每个样本等权平均，和你的业务可能不完全一致。

向量化实现可以自己写，核心就是把排序、取K、计算DCG都用到numpy的索引操作。但如果你的数据规模在百万级以内，分组后用Python函数加多进程也能接受。别急着优化，先保证指标计算正确，再考虑速度。

5.2 离线评估和线上业务保持一致

NDCG在离线算得很漂亮，但上线后效果不明显，这是推荐系统里最常见的困惑之一。原因往往不在指标本身，而在于离线评估和线上环境不一致。

比如离线评估时，你给每个用户只送了候选集里的200个物品，模型在这200个物品里排序，NDCG算的是这200个物品内的排名。但线上用户的真实曝光范围是几十万商品，用户可能根本没有机会看到那200个候选。所以离线NDCG高，只能说明你在这200个候选里的排序不错，不能说明全局推荐能力强。

更稳的做法是记录线上推荐列表的曝光数据，用曝光未点击和曝光点击作为评估集。这样NDCG评估的是“真实展示给用户的列表中，用户是否点击了更喜欢的物品”，虽然包含位置偏差，但更贴近业务。当然，这种做法也会引入偏差，需要结合随机排序的小流量实验来修正。

5.3 可以继续扩展的变体思路

NDCG本身还可以做不少扩展。比如加用户权重，活跃用户的权重更高，避免被大量低活跃用户稀释；比如按业务目标构造多级相关性，点击给1分，收藏给2分，购买给5分；再比如对列表做去重后计算，避免同一品牌或同类型商品霸屏。

拿我自己的经验来说，最稳的评估方式不是只盯一个NDCG，而是固定一组指标：NDCG@10加Recall@10加业务侧的模拟点击率，三个指标一起看。NDCG提升3个点，线上可能只是一个小数点的事，但它能帮你把排序方向摆正。NDCG这个指标值得花时间吃透，因为几乎所有和排序相关的模型，最后都要用它来说话。