1模型评估我们在建立模型之后，接下来就要去评估模型，确定这个模型是否有用。
在实际情况中，我们会用不同的度量去评估我们的模型，而度量的选择取决于模型的类型和模型以后要做的事。
1.1二分类评估二分类模型的评估。
1.1.1业界标准叫法二分类评估；分类算法。
1.1.2应用场景信息检索、分类、识别、翻译体系中。
1.1.2.1新闻质量分类评估对于新闻APP，其通过各种来源获得的新闻，质量通常良莠不齐。
为了提升用户体验，通常需要构建一个分类器模型分类低质新闻和优质新闻，进而进行分类器的评估。
1.1.2.2垃圾短信分类评估垃圾短信已经日益成为困扰运营商和手机用户的难题，严重影响人们的生活、侵害到运营商的社会公众形象。
构建二分类器模型对垃圾短信和正常短信进行分类，并进行二分类评估。
1.1.3原理1.1.3.1混淆矩阵混淆矩阵（Confusion Matrix）。
来源于信息论，在机器学习、人工智能领域，混淆矩阵又称为可能性表格或错误矩阵，是一种矩阵呈现的可视化工具，用于有监督学习，在无监督学习中一般叫匹配矩阵。
混淆矩阵是一个N*N的矩阵，N为分类（目标值）的个数，假如我们面对的是一个二分类模型问题，即N=2，就得到一个2*2的矩阵，它就是一个二分类评估问题。
混淆矩阵的每一列代表预测类别，每一列的总数表示预测为该类别的数据的数目，每一行代表了数据的真实归属类别，每一行的数据总数表示该类别的实例的数目。
图1 2*2混淆矩阵图阳性（P，Positive）：阴性（N，Negative）：真阳性（TP，True Positive）：正确的肯定，又称“命中”（Hit）；被模型预测为正类的正样本。
真阴性（TN，True Negative）：正确的否定，又称“正确拒绝”（correct rejection），被模型预测为负类的负样本。
伪阳性（FP，false Positive）：错误的肯定，又称“假警报”（false alarm）；被模型预测为负类的正样本。
伪阴性（FN，false Negative）：错误的否定，又称“未命中”（miss）；被模型预测为正类的负样本。
灵敏度（Sensitivity）或真阳性率（TPR，Ture Negative Rate）：又称“召回率”（recall）、命中率（Hit Rate）。
在阳性值中实际被预测正确所占的比例。
TPR=TP/P=TP/(TP+FN)伪阳性率（FPR，false positive rate）：又称“假正类率”、“错误命中率”、“假警报率”。
FPR=FP/(FP+TN)特异度（SPC，Specificity）或真阴性率：在阴性值中实际被预测正确所占的比例。
SPC=TN/N=TN/(FP+TN)=1-FPR假发现率(FDR,false discovery rate)：FDR=FP/(FP+TP)=1-TPR准确度（ACC）：预测正确的数占样本数的比例。
ACC=(TP+TN)/(P+N) 阳性预测值(PPV,positive predictive value)或精度(precision)：阳性预测值被预测正确的比例。
PPV=TP/(TP+FP)阴性预测值(NPV,negative predictive value)：阴性预测值被预测正确的比例。
NPV=TN/(TN+FN)图2 一个模型的2*2混淆矩阵图示例我们可以看出，这个模型的准确度是88%，阳性预测值比较高而阴性预测值较低，对于灵敏度和特异度也是相同。
这是因为我们选的阈值导致的，若我们降低阈值，这两对数值就会变得接近。
1.1.3.2ROC曲线ROC曲线（Receiver Operation Characteristic Curve），中文名叫“接受者操作特征曲线”，其实是从混淆矩阵衍生出来的图形，其横坐标是Specificity（特异度），纵坐标是Sensitivity（灵敏度）。
图3 ROC曲线图随着阈值的减小，更多的值归于正类，敏感度和特异度也相应增加。
而那条45度线是一条参照线，ROC曲线要与这条参照线比较。
如果我们不用模型，直接把客户分类，我们得到的曲线就是这条参照线，然而，我们使用了模型进行预测，就应该比随机的要好，所以，ROC曲线要尽量远离参照线，越远，我们的模型预测效果越好。
ROC曲线反映了错误命中率和灵敏度之前权衡的情况，即灵敏度随着错误命中率递增的情况下，谁增长的更快，快多少。
灵敏度增长的越快，曲线越往上屈，反映了模型的分类性能越好。
当正负样本不平衡时，这种模型评价方式比起一般的精确度评价方式好处尤为明显。
ROC曲线快速爬向左上，表示模型准确预测数据。
一般情况下，ROC曲线都应该处于参照线的上方。
1.1.3.3AUC（ROC曲线下面积Area Under ROC Curve）图3 AUC曲线图ROC曲线是根据与45度参照线比较判断模型的好坏，但这只是一种定性的分析，如果需要定量的计算判断，就用到了AUC，即：ROC 曲线下面积。
参考线的面积是0.5，ROC曲线越往左上方靠拢，AUC就越大（这里的面积是0.869），模型评估的性能越好，完美分类的AUC值是1。
1.1.3.4基尼系数基尼系统经常用于分类问题，公式：Gini=2*AUC-1。
基尼系数大于60%，就算好模型。
图3 LIFT提升图LIFT=(TP/(TP+FP))/((TP+FN)/(TP+FN+FP+TN))LIFT越大，模型的预测效果越好。
LIFT值应一直大于1，如果LIFT 值等于1，模型就没有任何提升了。
横轴是预测为正例的比例，即：(TP+FN)/(TP+FN+FP+TN)图3 Gains增益图与LIFT类似，区别在于纵轴的刻度不同，横轴相同。
Gains=TP/(TP+FP)=LIFT*((TP+FN)/(TP+FN+FP+TN))1.1.3.7K-S（Kolmogorov-Smirnov chart）图K-S图是用来度量阳性和阴性分类区分程度的。
若我们把总体严格按照阳性和阴性分成两组，则K-S值为100，如果我们是随机区分阳性和阴性，则K-S值为0。
所以，分类模型的K-S值在0到100之间，值越大，模型表现越好。
1.2多分类评估多分类模型的评估。
1.2.1业界标准叫法多分类评估。
1.2.2应用场景1.2.2.1商品图片分类淘宝、京东等电商含有数以百万级的商品图片，“拍照购”等应用必须对用户提供的商品图片进行分类。
1.2.3原理同1.1.3节。
1.2.3.1混淆矩阵如果有150个样本数据，这些数据分成3类，每类50个。
分类结束后得到的混淆矩阵如下：每一行之和为50，表示50个样本。
第一行说明类1的50个样本有43个分类正确，5个错分为类2，2个错分为类3。
第一行第一列中的43表示有43个实际归属第一类的实例被预测为第一类，同理，第二行第一列的2表示有2个实际归属为第二类的实例被错误预测为第一类。
1.2.4不同应用场景使用的方法及参数1.2.4.1混淆矩阵混淆矩阵一般只能用于分类输出模型中。
对于混淆矩阵，一般情况下，我们只关心其中一个定义度量。
例如：在医药公司，一般会更加关心最小化误诊率，也就是高特异度。
而在磨损模型中，我们更关心的是灵敏度。
1.2.4.2ROC和AUC曲线ROC曲线的一个应用场景是在人脸检测中，很多相关的研究或者企业评价他们的检测性能程度是通过ROC曲线来评定的。
ROC和AUC曲线常被用来评价一个二值分类器的优劣。
1.3Spark模型预测Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎。
是一种计算框架。
1.3.1业界标准叫法Spark。
1.3.2应用1.3.2.1腾讯社交广告平台—广点通广点通是最早使用Spark的应用之一。
腾讯大数据精准推荐借助Spark快速迭代的优势，围绕“数据+算法+系统”这套技术方案，实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法，最终成功应用于广点通pCTR投放系统上，支持每天上百亿的请求量。
基于日志数据的快速查询系统业务构建于Spark之上的Shark，利用其快速查询以及内存表等优势，承担了日志数据的即席查询工作。
在性能方面，普遍比Hive高2-10倍，如果使用内存表的功能，性能将会比hive快百倍。
1.3.2.2Yahoo—Audience Expansion（读者扩张）Yahoo将Spark用在Audience Expansion中的应用。
Audience Expansion是广告中寻找目标用户的一种方法：首先广告者提供一些观看了广告并且购买产品的样本客户，据此进行学习，寻找更多可能转化的用户，对他们定向广告。
Yahoo采用的算法是logistic regression。
同时由于有些SQL负载需要更高的服务质量，又加入了专门跑Shark 的大内存集群，用于取代商业BI/OLAP工具，承担报表/仪表盘和交互式/即席查询，同时与桌面BI工具对接。
目前在Yahoo部署的Spark 集群有112台节点，9.2TB内存。
1.3.2.3淘宝—搜索和广告业务阿里搜索和广告业务，最初使用Mahout或者自己写的MR来解决复杂的机器学习，导致效率低而且代码不易维护。
淘宝技术团队使用了Spark来解决多次迭代的机器学习算法、高计算复杂度的算法等。
将Spark运用于淘宝的推荐相关算法上,同时还利用Graphx解决了许多生产问题，包括以下计算场景：基于度分布的中枢节点发现、基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。
1.3.2.4优酷土豆—视频推荐和广告业务优酷土豆在使用Hadoop集群的突出问题主要包括：第一是商业智能BI方面，分析师提交任务之后需要等待很久才得到结果;第二就是大数据量计算，比如进行一些模拟广告投放之时，计算量非常大的同时对效率要求也比较高，最后就是机器学习和图计算的迭代运算也是需要耗费大量资源且速度很慢。
最终发现这些应用场景并不适合在MapReduce里面去处理。
通过对比，发现Spark性能比MapReduce提升很多。
首先，交互查询响应快，性能比Hadoop提高若干倍;模拟广告投放计算效率高、延迟小(同hadoop比延迟至少降低一个数量级);机器学习、图计算等迭代计算，大大减少了网络传输、数据落地等，极大的提高的计算性能。
目前Spark已经广泛使用在优酷土豆的视频推荐(图计算)、广告业务等。
1.3.3原理1.3.3.1Spark生态圈如下图所示为Spark的整个生态圈，最底层为资源管理器，采用Mesos、Yarn等资源管理集群或者Spark自带的Standalone模式，底层存储为文件系统或者其他格式的存储系统如Hbase。
Spark作为计算框架，为上层多种应用提供服务。