算法团队该背模型指标还是业务指标？聊聊 KPI 设计里的「归因困境」

背景

做了 15 年算法，从推荐排序到风控评分都带过团队。有一个问题我几乎每换一家公司都会被问一次，而且每次都能把会议室吵热：

「算法团队到底该背什么指标？是 AUC / NDCG / GAUC 这些模型指标，还是 CTR / 转化率 / GMV 这些业务指标？」

这个问题看着像「管理问题」，实际是个「归因 + 激励」问题。我见过三种典型做法，各有坑：

做法一：只背模型指标（AUC、NDCG）

• 优点：归因干净，模型涨就是算法的功劳；评估周期短，离线跑完就能看。
• 坑：模型指标和线上体验之间隔了太多层（召回→粗排→精排→重排→业务规则→前端展示），AUC 涨 0.5% 但用户感知为零的情况非常常见（站内已有讨论帖 #518 和文章 #737 都讲过）。更隐蔽的问题是——算法同学会不自觉地「优化指标本身」而非用户价值。

做法二：只背业务指标（CTR、转化率、GMV）

• 优点：离用户价值最近，不容易「自嗨」。
• 坑：归因不干净。转化率受运营活动、流量结构、竞品动作、季节因素影响，算法只能解释其中一小部分。季度末算法同学拿到的成绩单，可能 80% 是运营的功劳，但年底 review 时说不清。另外，业务指标波动大、周期长（7 日 / 30 日留存），反馈回路太慢，模型迭代节奏被拖垮。

做法三：双指标体系（模型指标 + 业务指标，各占权重）

• 优点：兼顾短期迭代节奏和长期业务对齐。
• 坑：权重怎么定？5:5？7:3？谁定？而且一旦背了业务指标，算法团队就会忍不住去「动业务规则」来凑数——比如调推荐池的多样性参数、给特定品类加权，这些操作对模型本身没提升，但短期 CTR 好看。

我的倾向

我倾向于做法三，但加两条硬约束：

1. 模型指标是「过程 KPI」，业务指标是「结果 KPI」——过程 KPI 决定月度节奏（迭代快不快、模型健康不健康），结果 KPI 决定季度评价（业务值不值）。两者不是简单加权，而是「过程不达标直接扣结果分的权重」。
2. 业务指标的归因必须走 A/B 实验，不能看大盘——大盘受太多外部因素干扰，只有实验组 vs 对照组的增量才能归因给算法。这要求实验平台必须成熟（样本量够、分流干净、观察周期够长），否则宁可只背模型指标，也别背一个归因不清的业务指标。

想听大家聊聊

• 你们团队实际怎么定算法团队的 KPI？模型指标和业务指标各占多少？
• 遇到过「模型指标涨了但业务指标没动」或反过来的情况，最后怎么归因、怎么 review？
• 如果业务方坚持要算法背 GMV，但你们的实验平台还不成熟（比如分流有偏、样本量不够），你怎么应对？
• 有没有团队尝试过「算法不背任何业务指标、只背模型指标 + 系统稳定性」的方案？效果如何？

欢迎带具体场景来聊，越具体越好。