最好的trick就是保证数据精准前提下，如无必要，不要采样。既然数据是模型的上限，就不应该破坏这个上限。
聊聊什么是精准。
很多号称数据清洗的工作，都是工程体系太弱的后果，其实不是算法的问题。比如，没有曝光日志，用了服务端日志，伪曝光做了负样本；没有准确的曝光日志，比如卡片漏出了一个头用户根本没看到就记录了曝光日志，充当了负样本;场景里有引流模块，把用户在场景外的点击强插到前面，这个物品的样本是应当丢掉的，或者在特征上做一些处理，防止把高点击率归因给物品，造成整个模型的溃败。
在精准上，有一个不能称之为trick的常识，就是处理好点击事件的delay。构造CTR样本就是拿曝光日志去join点击日志，无论这这个日志是在批处理平台还是流式计算平台，由于用户点击天然比曝光事件滞后，加上系统本身的延迟，点击日志会比曝光日志晚到，如果按照一个时间戳截断两个日志，会有一些正样本被误认为负样本。如果是天级的样本，23点之后的样本有一些是错的。如果是小时级或流式，曝光日志要delay等待点击日志多久，要好好评估一下，看看等待多久能让绝大多数样本正确。
聊聊什么是必要。
数据量太大，你train不动了，这时候做负样本的下采样，但是绝对没有正向的效果，这也可能是工程体系不够强大的表现。采样稍有不慎，还会造成负向效果。做了采样均值就变了，还要重新矫正预估值，麻烦。
某个用户行为多，要采样怕影响整体分布？采样了才影响整体分布吧，如果数据本身是精准的，我不相信这能有用。
还有人讲，说负样本太多，要采样。假如是1:1k，其实也没什么问题。假如是1:1w，那有一亿个样本里才有1w的正例，这个正例本身就太少太偏，业务上这个指标有意义吗？这个预估不能拆成两个预估的乘积吗？如果都不行，我觉得可能用点规则效果更好。
数据弥足珍贵，如无必要，不要采样，既然数据是模型的上限，就不应该破坏这个上限。好好利用每一条用户反馈，不出错，不乱搞，结硬寨，打呆仗，这往往就是最好的策略。