YG Overflow

0x00 Introduction 前一阵在某个手游厂做了一些关于流水预测的工作，这里记录一下。 流水预测，这个课题字面意思就是为了预测后续一段时间内公司的流水情况，比如大到一个商场，小到一个小区门口的小卖部，都会想知道自己未来比如1个月的流水如何。 0x01 Keywords CLV(customer lifetime value) ; LTV(lifetime value) ; BTYD(Buy Till You Die)  0x02 Problem 把流水分成两部分，一部分来自已有用户的贡献，另一部分是目前未知的新用户带来的流水。 这里讨论的只是对于老玩家流水的预测。 在对老玩家LTV预测的问题上，一个分类维度是是否有合同：Contractual/Non-Contractual。有合同指的是我能知道我当前有那些用户，他们分别会在什么时候流失，即合同终止时间，这个适用于比如会员制的超市。实际情况下，对于互联网时代，更多的是Non-Contractual情况，并不能确定的知道用户/玩家什么时候就流失了。 这里我所遇到的也是 Non-contractual Problem。 0x03 Approaches 1. Naive Method 在手游这个domain，比如要预测未来一天的流水，通常人们采取的做法是：根据一些历史经验，估计出那天的DAU，然后乘上付费玩家占比，再乘上他们的平均付费值 2. BTYD 1987年，MIT的David C. Schmittlein发了一篇文章【1】其中提出了一个生成模型，用来预测未来一段时间内老用户的购买次数。模型称作PNBD (Pareto/NBD)。 这篇文章的Intuition是根据每个用户历史购买信息，计算出这个用户在T时刻的存活概率 P(Alive | Information) * 这个用户在(0,T] 的总计购买次数期望 = 这个用户从出生(0时刻)到T的累计购买次数预测。 这里David基于5条假设来给出他的模型： 对于每个用户个体层面: 每个用户当还存活时的购买过程服从 Poisson Process ，参数为$\lambda$ ($1/\lambda$代表两次购买的平均间隔) 每个用户随着时间推移，还存活的概率服从 Exponential distribution ，参数为$\mu$ (代表死亡率) 在整体层面:

1 Abstract  原文 给的场景是对于大规模集群的运维，当一条issue被上报的时候，通常会带上一些attribute，比如时间，软件版本，所处的国家，城市，具体在哪个机房，浏览器，操作系统等等。 在平时的时候，每天的上报的issue数量应该是差不多的，但有些时候，报错数量会突然上升，对于运维人员定位到问题所在往往很花时间。背后的问题可能是某个attribute或者某几个attributes的组合，文章称为effective combination。 这里通过三个步骤来从所有的attribute combination中找到最后可能引发报错激增的effective combination。 2 Challenge 想要找到所有effective combination的最暴力的做法就是，枚举所有attribute combination，然后以某种方式来衡量它对于总体issue激增的关系。 这里主要的问题在于搜索空间过大，本文最大的创新在于对搜索空间的剪枝。如果一共有m个attribute，那一共的组合方式就是(2^m - 1)种 3 Approach 文章把整个流程主要分成三个步骤（用做剪枝）和一个结果排序 Impact based Pruning: 基于影响的用户量做剪枝（不含时间信息） Change Detection based Pruning: 基于时间线上的突变来剪枝（时间序列处理） Isolation Power based Pruning: 计算一个类似信息熵增益的值来判断这个attribute combination的区分度 Result Ranking: 计算这个attribute combination对于全局的显著性 3.1 Impact based Pruning 对于一个effective combination而言，它必须影响足够多的用户。所以这里定一个threshold来过滤掉一些不可能的参数组合。（排除时间这个维度） 这里的目的是 寻找closed frequent itemsets，文章里的没有对算法进行详细描述，就说用BFS-based closed itemset mining algorithm。 在复现的时候，我先用了现成的找 frequent itemset 的算法（ Apriori /FPMax/ FPGrowt

这是一门由陈天奇大佬讲的机器学习系统课程，UW的网站上放出了这么课的相关信息，本文是这门课的课堂笔记。 但是UW只放出了课件和作业，所以自学起来可能比较凌乱，这里参考了各位大佬的其他材料。 知乎专栏：机器学习系统   CSE 599W:Systems for ML 课程笔记 1-6 chenfei 课程笔记 CSE 599W - Systems for ML - 辛酸阅读记录 1. 课程概览 (lecture 3) Fig1.1 课程概览 这门课，上对接的是Tensorflow, Pytorch, Caffe, MXNet这类机器学习计算框架，下对接的是CPU/显卡/手机/单片机。。。形态各异的硬件设备。 机器学习系统就处在这两者之间。 这门课程把中间地带划分成三大块： User API System Components Architecture 1.1 User API 第一层User API 指的是运算框架比如tensorflow或者pytorch之类的把运算进行封装，使得DL开发者不需要从自动求导写起，并且把用户build的模型转化成计算图(computational graph)。 Fig1.2 Logistic Regression的计算图 计算图，这个概念在接触过tensorflow以及pytorch应该或多或少听说过他俩的一个区别是tf是静态计算图，pytorch是动态计算图 Fig1.3 静态vs动态计算图 1.2 System Components 到了第二层系统组件做的事情就是对于计算图的优化。 比如说会做的有 deadcode检测，内存规划和优化，并行调度， Fig1.4 并行调度优化 1.3 Architecture 第三层就是把优化好的计算图部署到对应硬件上的操作。 现在的做法是各个厂商自己出一套对于model serving的支持，比如Intel的OpenVINO，ARM的ARM NN，NV的TensorRT等。但是各自对于计算图中算子的支持度不同，也无法迁移。 相比TensorFlow等这样的框架孱弱的Inference性能，各大设备厂商的Inference框架性能都比较不错），比如Intel的OpenVINO，ARM的ARM NN，NV的TensorRT等，但是这里面有一个问题，各大设备厂商的框架并不具备通用性，比如对训练框架模型