别人说要做个大模型时，我先问：它上线后改变什么动作？

“我们做一个优质作者模型吧。”

这类需求很容易让人立刻进入方案。要收哪些特征，用分类还是排序，模型规模多大，离线指标做到多少。

我现在更想先问一句：

这个分数上线以后，会改变谁的什么动作？

如果答案不清楚，再聪明的模型也可能只是一份更贵的报表。

“优质作者”不是一个天然标签

假设业务希望提前找到有潜力的游戏内容作者，给他们更多扶持。

第一步不是选模型，而是把“优质”说清楚。

是内容播放高，能稳定更新，能带来游戏下载，还是能长期影响玩家社区？这些目标可能相关，也可能互相冲突。

如果直接把当前收入高的作者标成正样本，模型大概率会找到已经成功的人。它可能准确复现平台今天如何分配流量，却没有识别出那些还没被看见、但值得提前扶持的人。

如果用播放量做标签，模型可能偏爱容易获得点击的内容；如果用下载做标签，又要处理游戏差异、投放影响和归因窗口。标签看起来只是数据字段，实际上已经写入了一次业务判断。

所以我会继续问：模型吃进去的是什么，吐出来的是什么；训练标签代表哪种成功；预测错了以后，哪一种错误更贵。

漏掉一个未来可能成长的作者，和把资源给到一个后来没有成长的作者，对业务的代价并不一样。没有这个判断，所谓损失函数只是一行看起来专业的配置。

一个分数怎样进入真实世界

再假设模型已经能给每位作者一个潜力分。

接下来谁会使用它？

运营会联系高分作者吗？平台会给额外流量吗？扶持预算按什么规则分配？如果作者被模型选中，却没有任何资源和动作发生，我们最后验证的只是模型能不能描述过去。

即使真的给了资源，也不能只看高分作者后来表现更好。

他们可能本来就更好，也可能因为模型分高得到更多曝光后才变好。要知道模型有没有带来增量，需要设计对照和分层，观察相同资源条件下，使用模型是否比现有方法多找到了一批真正成长的作者。

模型指标、策略指标和业务指标需要一层层接起来。

离线准确率变高，不代表扶持策略更有效；被联系的作者回复更多，不代表最终内容供给更好；内容供给变多，也不一定带来用户和业务结果。

如果这些关系没有说清楚，团队很容易在一个漂亮的离线数字上达成共识，然后共同错过真正的问题。

不说“做不了”，而是把分歧变成实验

不做 Yes 工程师，不是听到需求就反对。

一句“这个模型没用”，和一句“做个大模型就能解决”，证据强度可能差不多。前者只是把盲目答应换成了盲目否定。

更好的做法，是把分歧写成两个可以比较的假设。

业务认为，现有人工筛选漏掉了大量早期潜力作者，模型可以更早发现他们。技术侧可能认为，可用标签太接近当前结果，模型只会重复已有分发。

那就先做一个低成本基线，用现有特征和简单规则跑历史回测，检查高分人群里是否真的存在“当时还不突出、后来明显成长”的作者；再看模型相对人工规则增加了什么，错误集中在哪里。

如果连简单基线都没有增量，继续扩大模型通常不会凭空产生业务价值。如果基线已经显示出信号，再决定补数据、改标签还是上更复杂的方法，讨论会具体得多。

实验不是用来证明某一方更聪明。它是让团队不用靠职位和音量决定事实。

我真正需要补的，也在这里

我对业务链路和产品动作比较敏感。

当有人提出一个模型需求，我会本能地追问它解决什么问题，输出由谁使用，最后影响哪个结果。这种判断帮助我避免把技术名词当成产品价值。

但我也需要承认自己的边界。

发现问题定义含糊，不等于已经能判断技术方案；知道业务要增量，不等于能证明某个模型做不到。要让反对意见有分量，我还需要更硬的证据：可信的基线、样本和误差分析、数据与标签质量、线上实验设计，以及结果归因。

否则，“我有业务判断”也可能变成另一种漂亮故事。

我希望自己成为的，不是一个更会拒绝需求的人。

而是一个能和业务、算法、工程一起把问题重新定义清楚的人：我们到底在预测什么，为什么值得预测，预测结果会改变什么，以及怎样知道它真的比原来更好。

模型从来不是最后一个问题。

最后一个问题是，它进入真实世界以后，谁因此做出了不同的动作。