Posts

Showing posts from 2020

干过一些流水预测的活儿

Image
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$ (代表死亡率) 在整体层面:

根因分析之iDice 文章复现

Image
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 CSE 599W: Systems for ML 笔记 (上篇)

Image
这是一门由陈天奇大佬讲的机器学习系统课程,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等,但是这里面有一个问题,各大设备厂商的框架并不具备通用性,比如对训练框架模型