真实面经题目 · 原创解析
这题考察的是推荐排序模型目标与业务阶段的匹配。LGB 做点击率预估通常是 pointwise 思路：把每个曝光样本建成点击/不点击标签，预测 pCTR 或相关概率，优点是训练样本构造简单、可解释、工程成熟、延迟低、支持非线性特征组合，对稀疏表格特征和中小规模排序链路很实用；缺点是优化目标和最终排序指标 NDCG/MAP 不完全一致，也可能受曝光位置偏差和样本校准影响。LambdaMART 属于 learning-to-rank，常用 pairwise/listwise 的梯度思想直接优化排序相关指标，适合有 query/session/list 结构、强相对排序标签和 TopK 质量目标的场景；但它对样本分组、标签质量、训练成本、在线 serving、增量更新和校准都有更高要求。选型不能说谁绝对更好，而要看目标是概率预估、广告/推荐价值计算、可校准 CTR，还是列表相对顺序和 NDCG 提升。
我会先区分目标。LGB 做 CTR 预估通常是 pointwise：每条曝光样本有点击标签，模型输出 `pCTR = P(click | user,item,context)`，再和其他信号组合排序。它的优点是样本构造简单、训练和线上推理成熟、特征重要性可解释、延迟低，并且输出概率可以校准，用在广告 eCPM、推荐融合或多目标排序里很方便。LambdaMART 更偏 Learning to Rank，它按同一个 query/session/user 请求下的 item 列表构造 pair/list，利用 lambda gradient 让更相关的 item 排到前面，目标更贴近 NDCG/MAP 这类排序指标。它适合有明确 group、分级相关性标签、TopK 顺序比概率更重要的场景。为什么不一定用 pairwise？因为推荐/广告线上常需要可校准的 pCTR/pCVR，样本量大且反馈有位置偏差，pairwise 构造成本高、训练复杂、serving 和增量更新不一定划算。实际可以先用 LGB 做强 baseline，再根据离线 NDCG、在线 CTR/CVR/时长、延迟和维护成本评估是否引入 LambdaMART 或把 LTR 放到 rerank 阶段。
LGB 点击率预估通常把每个曝光样本视为独立样本，标签是是否点击，优化 logloss、AUC 等点级指标，输出可解释为点击概率。这个概率可以继续参与多目标打分，例如 `score = w1*pCTR + w2*pCVR*value + w3*quality`。LambdaMART 关注的是同一个 query、用户请求或 session 下 item 之间的相对顺序，通过 pairwise/listwise 方式近似优化 NDCG、MAP 等排序指标。前者更像概率建模，后者更像列表排序优化。
LightGBM 对稠密/离散统计特征、交叉特征、用户画像、item 统计、上下文特征很友好，训练速度快，特征重要性和 split 规则便于分析。在线推理延迟可控，模型部署简单，适合作为召回后粗排/精排的强 baseline。更重要的是，CTR 预估输出可以做概率校准，用于广告价值计算、阈值控制、多目标融合和业务解释。对于很多推荐系统，先把 pCTR 做准，比直接优化某个离线排序指标更可控。
pointwise 模型把样本相对独立处理，训练目标与 TopK 列表质量并不完全一致。点击标签还会受到曝光位置、展示样式、流量分布和选择偏差影响，模型可能学到位置偏差或热门偏差。AUC/LogLoss 好不一定代表 NDCG、MRR 或线上体验更好。此外，若最终排序强依赖同一请求内 item 之间的相对比较，单点概率可能无法充分表达列表结构和多样性约束。
LambdaMART 基于梯度提升树和 LambdaRank 思想，对排序交换带来的 NDCG 等指标变化赋予梯度权重，重点优化排错对列表指标的影响。它适合搜索排序、推荐 rerank、候选列表质量提升等场景，尤其当标签有多级相关性、同一 group 内 item 可比较、业务关注 TopK 顺序时效果更自然。相比纯 pointwise，它能显式利用“同一请求下 A 应该排在 B 前面”的信息。
Pairwise/listwise 方法依赖 group 构造，必须知道哪些 item 属于同一次请求或同一 query，并有可靠的相对标签。推荐曝光日志往往受策略影响强，未曝光 item 没有反馈，直接构造 pair 会有偏差；pair 数量可能膨胀，训练成本高；标签噪声和位置偏差会被放大。线上方面，LambdaMART 输出通常是排序分而非可校准概率，若广告价值计算或多目标融合需要 pCTR，还要额外校准或与 CTR 模型组合。
如果业务要估计点击概率、做广告 eCPM、融合 CVR/价格/时长、做阈值过滤或解释为什么某 item 被选，LGB CTR 是更自然的选择。如果业务已经有稳定候选集，核心问题是同一列表 TopK 顺序，且有分组标签和排序指标目标，可以尝试 LambdaMART。很多系统会组合使用：LGB/深度模型做 pCTR/pCVR，LambdaMART 或 LTR 模型放在 rerank 层优化相对顺序，再由策略层处理多样性和约束。
LGB CTR 侧看 AUC、LogLoss、校准曲线、ECE、分桶点击率、分场景稳定性；排序侧看 NDCG@K、MAP、MRR、Recall@K、TopK CTR 预估质量。线上要看 CTR、CVR、时长、留存、GMV/收入、负反馈、延迟和资源成本。若 LambdaMART 离线 NDCG 提升但线上 CTR 不涨，可能是标签构造、位置偏差、候选分布或多目标冲突导致。选型要以线上业务指标和成本收益为准。
无论选 LGB 还是 LambdaMART，都要处理推荐日志偏差。CTR 模型要做曝光样本清洗、位置特征或去偏、负采样策略、时间穿越检查和概率校准；LambdaMART 要保证 group 构造正确，同组内标签可比较，避免把不同流量位、不同策略下的 item 强行成对比较。线上 serving 还要考虑特征实时性、模型大小、树数量、p99 延迟、回滚和版本一致性。模型选择不是论文指标，而是能否稳定进入推荐链路。
AUC 衡量正负样本整体区分能力，不直接等价于 TopK 列表质量。线上排序还受候选集、位置、展示样式、多目标融合、校准和策略约束影响。模型可能在整体样本上区分好，但在头部候选之间区分不够，或者概率不准导致分数融合错误。
通常不建议直接当 pCTR。LambdaMART 输出是排序分，目标是相对顺序，不保证概率校准。如果业务需要点击概率参与 eCPM、预算或阈值决策，需要单独做概率校准，或保留 CTR 模型输出作为概率信号，LambdaMART 只负责 rerank。
如果把不同请求、不同位置、不同流量策略下的样本随便配对，pair 标签就不可靠。同一请求内点击 item 和未点击 item 可以构造偏好，但点击受位置和曝光影响，未点击不一定是不喜欢。需要控制 group、位置偏差、曝光机会和时间切分，否则模型会学到策略偏差。
当特征以统计和交叉特征为主、样本规模中等、迭代速度和可解释性重要、线上延迟严格，LGB 是很强的 baseline。它也常用于粗排、冷启动特征验证或和深度模型做融合。深度模型在稀疏 ID 表达、序列行为和大规模 embedding 上更强，但工程成本更高。
可以。常见方式是 LGB 输出 pCTR/pCVR 作为特征或基础分，LambdaMART 在 rerank 阶段结合这些概率、相关性、质量、多样性等特征优化列表顺序。也可以用 LGBRanker 形式训练 LTR 模型。但要确保分数语义清楚，评估时拆分概率校准收益和排序收益。
