一个基于更新频率和卡片等级、浏览量的动态推荐排序算法

需求背景

真实场景会更复杂一些，下面抽象出一个简单的示例来举栗子：
比如现在有一个卡片列表，卡片自身有卡片的创建时间、卡片等级、浏览量几个关键字段。
如果单纯的根据卡片等级去排序，那么很容易导致一些高等级的旧卡片一直霸榜；
按照创建时间去排的话，前面就容易出现一些粗制滥造的卡片；
所以单纯按照某一个字段去排序，效果都不会太好，没办法达成一个动态推荐的目的；
我们最直观的想法就是把这几个因素综合起来，给他们不同的权重，去达到一个综合的排序效果。

数据分析

简单来说，就是希望不同的等级有不同的权重，不同的创建时间有不同的权重，不同的浏览量亦如此，且这些"权重"最后是可以一起算出一个排序参数的。
举个例子，比如首先我们定义的卡片等级分为S A B C D E。
然后需要分析现有的数据分布和一个增长指数。
比如我们可以分析出以下几个指标：

• 等级增长频率：S、A每年[80-200]，每个季度平均有20±，每个季度至少有5个，过去的曲线是线性增长的，随着团队规模和业务比重的增大，预计趋势会保持且增长率会提升
  B每年400左右，每个季度平均有100，至少有40，且都是随着时间上升的
  得出结论，S、A的优质卡片和B的高品级卡片可以占据更大的推荐权重指数
  目前的页大小：60
  目前的浏览量：最多的是几百，平均几十

算法效果预期

1. 首页都是高质量卡片(尽量都是S、A，最次为B，CDE尽量不出现在前几页)
2. 前几页的卡片以一定的频率更新，等级越高的卡片，曝光周期和被顶替难度越大，相反则越小；这个顶替程度根据卡片等级的不同，也会有所不同，比如S和A的卡片量较少，所以理论情况下1-2个月内不会被其他等级的卡片更新所覆盖；B的卡片数量较多一些，2个月后逐步开始覆盖2月前的S、A；至于CDE则在B的基础上再顺推3个月左右才会有顶替的可能(除非半年多没有B级别以上的卡片入库，理论上不可能)；
3. 在这个过程中，排序也会受到卡片浏览量一定的影响，但是权重相对少一些，只有达到几百这个数量才会有明显的影响；由于页面上暂时没有展示浏览量的地方，一些特殊情况下可通过指定浏览量来达到个别卡片顺序灵活调整的目的，如置顶等；

算法参数拟定

综合卡片的等级占比、数量、更新频率和增长趋势，不建议采用固定日期的推荐方式，采用更灵活的属性权重方式来推荐卡片
以当前各等级的更新频率、数量、每页的卡片数以及预期达到的效果，初步拟定的指数排布对比表格如下：

另外，目前额外加入了浏览量作为一个权重较小的比较参数，根据目前的浏览量的量级和分布，取的模暂时定为20，体现的效果为，卡片等级相同、更新时间相近的两个卡片，浏览量较多的卡片排序可能会更靠前。

举个例子，若不考虑浏览量的话，上面的S级卡片发布后，再过184天，一个E级的卡片才能和它的推荐指数一样。
同理，S级卡片发布10天内，低等级的卡片是无法取代的，10天后，A级卡片就可以超过它。
先上代码，再说解析

代码

public Long getRecommendNum(Long lookNum) throws ParseException {
        SimpleDateFormat dateFormat = new SimpleDateFormat(DatePattern.NORM_DATE_PATTERN);
        Date startDate = dateFormat.parse("2021-10-01");
        if (publishTime == null || grade == null) {
            return 0L;
        }
        // 季度方式
        // int quarter = new BigDecimal(DateUtil.between(startDate, publishTime, DateUnit.DAY)).divide(new BigDecimal("91.25"), 0, RoundingMode.CEILING).intValue();
        // 自然天方式
        int afterDay = new BigDecimal(DateUtil.between(startDate, publishTime, DateUnit.DAY)).setScale(0, RoundingMode.CEILING).intValue();
        Integer gradeStep = GRADE_RECOMMEND_STEP_MAP.get(grade);
        long l1 = 100 + afterDay + gradeStep + lookNum / 20;
        return l1;
    }

public static LinkedHashMap<String, Integer> GRADE_RECOMMEND_STEP_MAP = new LinkedHashMap<String, Integer>(8) {
        {
            put(ASSETS_GRADE_S, 276);
            put(ASSETS_GRADE_A, 266);
            put(ASSETS_GRADE_B, 216);
            put(ASSETS_GRADE_C, 112);
            put(ASSETS_GRADE_D, 102);
            put(ASSETS_GRADE_E, 92);
        }
    };

总结

可以看到这个算法本身的逻辑并不难，它的难点在于如何分析出合理的参数，要基于当前系统的数据情况，未来业务的发展预期和想要达到的推荐效果，来得到算法的参数。