先上图

用户数据堆叠

        在上图是目前遇到的最大问题，按照一定的排序规则之后，我们根据收藏点击等指标，将数据选出来出现了显示结果被一个用户霸屏现象，如果是京东淘宝数据，这种情况是比较好解决的，因为数据体量是不同级别的。从技术角度来讲，这些都是正常的，因为这些数据指标和seo都达到了指标，才会被排到了顶部。但是从ctr和业务角度来说，统一用户数据霸屏一定是影响用户体验过程，我这里就不用 用户域和内容域匹配概率 分析了，这个也是浅显的东西。我们就此问题讨论一下然后，提出解决具体解决方案。 说个题外话，此问题本身不是算法自身导致的，而是内容管控问题，一个内容app上升期都会遇到的问题，因此，既然是必然出现的，所以有必要将心得洗(写)出来，大家指正批评。

         类似算法对比

        在实现过程中，鄙人有设计过另外一个排序算法，情景也比较类似。业务如下：我们产品是由一个渠道详情页面的，详情页面有评价内容，列表显示，如果该渠道的评价是由少量用户多次评价出来的，那么在排序过程，按照预定的指标因子对评价内容进行排序的话，会出现相同用户内容堆叠问题。作为排序任务，其实都是遇到了同样的情形：在窗口内容出现的聚类内容不是自己想要的。像评价内容数据打算的话，我当时给定的算法基调是，分桶，按照识别特征分组，接下来游走编码就能缓解这部分为题。反过来思考，es的搜索能这么做吗？频道内容做评价排序的话，我们可以认为是将原本数据数据域维度已经分好块，只是说在子域内的数据需要排序而已。从业务转换为 空间维度 可表示为：es搜索(品类，品牌，词,排序因子,user) 与渠道评价（1,排序因子，user）的复杂度对比。渠道评价内容的排序算法，对排序的桶增加维度，就是 在 搜索模块的算法。复用原有的评价内容排序算法，我们需要对内容的 品牌和 品类识别 填充数据，才能对内容入桶编号，因此评价内容排序算法不能应用到搜索模块。

         需要算出异常用户

        我们目前的计算公式如下：S（I）*ES(I)  ，其中ES(I) 是搜索引擎控制的一个分值，我们可以将这个描述为SEO指标。S（I）则是指标因子

用户发布内容，会优先去踩点，自己的专注领域。一旦在专注领域和指标因子都达标了，那么就会比较有机会上top n，在用户专注度比较高的情况下，就有机会出现搜索内容霸屏情况。通过数据摸索，我发现数据其实规律性比较大，我们用户群聚类，需要得到哪些用户异常行为可能性比较大，原本的用户族群100w级别  可以缩短到1k级别，业务是反应出来是有一个 词搜索 出现 同一用户霸屏现象，其实这个有可能是这个有一批用户会有这样的现象。

         先写到这里了，因为是边处理问题边记的东西，所以不会有太多的文字编排。

        采坑记

在计算异常用户的时候，出现一个细节问题，导致召回率特别高，而精确度不高，能召回表示大方出现问题的可能性比较小，也就是另外一个影响 检查用户是不是异常用户的 因数没有加入？期待改进之后效果  go    2020/10/09

        黎明前的寒冷 2020/10/11

今天调整了思路，采用了针对 词的重要程度区分计算，融合到 前面计算影响因子，这个思路想了很久，感觉应该可以，目前在调试数据。

         胜利是个假象？ 2020/10/12

今天调试的数据来看，召回率没有降低，但是准确率还是没有达到要求，十分失望，应该是降权的阈值设置太小了。

         初见效果？ 2020/10/16

今天上了一版生产环境，效果已经出来了，‘床垫’，检索数据还是往优化方向显示。上图

改进后效果

        初见效果？ 2020/10/19

   周六计算了数据，用于改良上周五，出现的 星夕床垫的出现的用户出现前top 50 概率。

总结： 目前解决思路因为是边做边记录问题的方式，所以解决思路还是没有具体说明：

    1、首先我们需要肯定自己在 搜索图片这块的正确性，也就是按照 交互看数据，以及SEO 的排序方式是合理有效的。

    2、出现 【星夕床垫】用户 在床垫 领域的检索出现霸屏情况也是利用了 我们app产品排序准则，也就是说 竞排机制不太完善，需要改善。

    3、鉴于此情景类似 之前设计的 渠道 评价内容排序场景，复用算法问题经过讨论 认为 维度不同导致需要另外设计一套 用于适配当前情况。

    4、确定思路之后，就是在，写代码检测  坏数据，并且修复。