搜索排序评估方法：作为产品，这个你必须要了解
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了搜索排序评估方法：作为产品，这个你必须要了解相关的知识，希望对你有一定的参考价值。
参考技术A 信息检索领域两个最基本指标是召回率(Recall Rate)和准确率(Precision Rate)，召回率也叫查全率，准确率也叫查准率，概念公式:为了直观的描述这两个概念，我们用是否相关和是否被检索到两个维度的指标来对每一次信息检索之后的内容分类。是否相关指内容和检索条件是不是相关，如检索“酒店”，系统中所有的酒店内容就是相关，而“美食”的内容就是不相关的，一般情况下，相关的内容就是理论上需要完全被检索到的内容，这个数值和检索的策略或算法没有关系。是否被检索到是针对检索结果的描述指标，检索完成后我们才能对系统内容做是否被检索到的区分，这个数值和检索策略或算法相关。通过是否相关和是否被检索到两个维度的指标，我们可以将检索完成后的内容分为四类，如下图：
联系图表，召回率就是检索到的相关内容（A）在所有相关内容中的比例（A+C），而准确率就是检索到的相关内容（A）在所有检索到的内容（A+B）中的比例。
但是如何算图1中的A、B、C、D呢？一般，这需要人工标注，人工标注数据需要较多时间且枯燥，如果仅仅是做实验可以用已知的场景来测试，比如我们已知搜索“A酒店”应该出的搜索结果，那么我们就可以通过不同策略在搜索“A酒店”的表现来计算不同策略的A、B、C、D值，这种方式简便易行，能够针对性的解决问题，但是只能解决已知的问题。当然，还有一个办法，找个一个比较成熟的算法作为基准，用该算法的结果作为样本来进行比照，当然这个方法也有点问题，那就是我们无法得知天花板在哪里，也就是无法预知最佳效果如何。
在实际项目中，我们单方面追求准确率和召回率都是不对的。准确率和召回率是互相影响的，理想情况下肯定是做到两者都高，但是一般情况下准确率高、召回率就低；召回率低、准确率高。如果是做搜索，那就是保证一定召回的情况下提升准确率；如果做反垃圾、反作弊，则是保证一定准确率的条件下，提升召回率。
一般情况，对同一个策略模型，用不同的阀值，可以统计出一组不同阀值下的精确率和召回率关系，我们称之为P-R曲线，如下图：
图中横坐标是召回率，用R（Recall）表示；纵坐标是准确率，用P（Precision）表示。有时候，我们在P和R做出平衡，因此我们需要用一个值来体现策略在P值和R值两方面的整体表现。最普通也最容易理解的是F1值，F1值的计算公式如下：
用F1值来体现准确率和召回率的综合表现非常直观且易于理解，但是也有一个明显的缺陷，F1值的计算中，P和R的权重是一样的，也就是对召回和准确的要求是一样。在大多数情况下，我们在召回率和准确率上有不同的要求，因而我们也常用F2和F0.5来评价策略的效果，F2 = 5P * R / (4P + R)，表示更重视召回率，F0.5（F2 = 1.25P * R / (0.25P + R)，表示更重视准确率。
前面给大家介绍了F值，细究不难发现，它只能表示单点的效果而无法表示策略的整理效果，下面介绍的内容，将是一些能评估策略整体效果的评估方法。
ROC的全名叫做Receiver Operating Characteristic，是评价分类器（需要说明）的指标，一般分类识别相关的策略我们使用ROC值来评价。我们用上面第一个图的方式来说明这个值，我们将ABCD稍作变换如下图：
正确正例（True Positive，TP）表示将正例（预测）分为正例的内容；错误正例（False Positive，FP）表示将负例分为正例的内容；错误反例（False Negtive，FN）将正例分为负例的内容；正确负例（True Negtive，TN）表示将负例分为负例的内容。其中，ROC关注两个指标：
ROC的主要分析方法是一个画在ROC空间的曲线（ROC curve）：在ROC 空间中，每个点的横坐标是FPR，纵坐标是TPR，这也就描绘了分类器在TP（真正的正例）和FP（错误的正例）间的平衡关系。我们知道，对于二值分类问题，实例的预测值往往是连续值，我们通过设定一个阈值，将实例分类到正类或者负类。比如我们通过数据挖掘计算酒店不接待客户的预测值是一个0-1的分布，然后设定一个阈值0.5，如果大于0.5，我们则认为酒店存在不接待用户的情况。因此我们可以变化阈值，根据不同的阈值进行分类，然后根据分类结果计算的TPR值和FPR值得到ROC空间中相应的点，连接这些点就形成ROC曲线。ROC曲线会经过（0,0）（1,1）两个点，实际上(0, 0)和(1, 1)连线形成的ROC曲线代表的是一个随机分类器。一般情况下，这个曲线都应该处于(0, 0)和(1, 1)连线的上方，否则，分类器的策略就是有问题的。
用ROC curve来表示分类器的效果很直观好用，也能够观测在不同TPR和FPR下分类策略的表现。但是，我们仍然希望能够用一个特定的值来表示分类器策略的好坏，于是Area Under roc Curve(AUC)就出现了。顾名思义，AUC的值就是处于ROC曲线下方的那部分面积的大小。
可以预见的是，AUC的值介于0.5（随机分类器的AUC值）到1.0之间，通常情况下，我们认为较大的AUC代表了较好的效果。
MAP也是评估检索策略效果的方式之一，与AUC不同的是，除了考虑召回结果的整体准确率之外，MAP也考量召回结果条目的顺序。MAP是Mean Average Precision@K的缩写，要了解MAP，我们需要逐步了解Prec@K和AP@K的概念。
Prec@K表示设定一个阈值K，在检索结果到第K个正确召回为止，排序结果的相关度。假设某次的检索结果如下：
注：绿色表示搜索结果与搜索词相关，红色表示不相关。
在这个案例中Prec@1=1、Prec@3=2/3、Prec@5=3/5。也许你已经发现了，Prec@K也只能表示单点的策略效果，为了体现策略的整体效果，我们需要使用AP@K。
Average Precision@K是指到第K个正确的召回为止，从第一个正确召回到第K个正确召回的平均正确率。下面我们用两个排序案例来理解AP@K。假设存在以下两个排序，我们直观的理解，结果1是优于结果2的，那么这种优劣会如何体现在AP@K值中呢？
对于结果1，AP@K=(1.0+0.67+0.75+0.8+0.83+0.6)/6=0.78，对于结果2，AP@K=(0.5+0.4+0.5+0.57+0.56+0.6)/6=0.52，可以看到，效果优的排序结果的AP@K值大于效果劣的那一组。
对于一次查询，AP@K值可以判断优劣，但是如果涉及到一个策略在多次查询的效果，我们需要引入另一个概念MAP@K（Mean Average Precision@K），简单的说，MAP@K的计算的是搜索查询结果AP@K值的均值。假设某个策略在两个不同查询下的输出结果如下：
在以上案例中，查询1的AP@K=(1.0+0.67+0.5+0.44+0.5)/5=0.62，查询的2的AP@K=(0.5+0.4+0.43)/3=0.44，则我们计算这个策略的MAP@K=(0.62+0.44)/2=0.53。对使用MAP@K进行评估的系统，我们认为MAP@K值较高的策略效果更好。
搜索引擎一般采用PI（per item）的方式进行评测。简单地说就是逐条对搜索结果进行分等级的打分，回顾MAP指标，我们对每个条目的值是的评价是用0或1表示，相较于MAP指标，D CG能够让我们让多值指标来评价。
在DCG指标的计算中，假设我们现在在谷歌上搜索一个词，然后得到5个结果。我们可以对这些结果进行3个等级的区分：Good（好）、Fair（一般）、Bad（差），然后赋予他们分值分别为3、2、1，假定通过逐条打分后，得到这5个结果的分值分别为3、2 、1 、3、 2。如果要我们评价这次查询的效果，可以用Cumulative Gain值来评估。
CG是在这个查询输出结果里面所有的结果的等级对应的得分的总和。如一个输出结果页面有P个结果，CG被定义为：
不难看出，CG并不考虑在搜索结果的排序信息，CG得分高只能说明这个结果页面总体的质量比较高并不能说明这个算法做的排序好或差。在上面谷歌的例子中，CG=3+2+1+3+2=11，如果调换第二个结果和第三个结果的位置CG=3+1+2+3+2=11，并没有改变总体的得分。
因此，如果我们要评估返回结果质量还要考量输出排序的话。首先，我们要说明什么是好的排序？一般来说，好的排序要把Good的结果排到Fair结果上面、Fair结果排到Bad结果上面，如果有Bad的结果排在了Good上面，那当然排序就不好了。
在一个搜索结果列表里面，比如有两个结果的打分都是Good，但是有一个是排在第1位，还有一个是排在第40位，虽然这两个结果一样都是Good，但是排在第40位的那个结果因为被用户看到的概率是比较小的，他对这整个搜索结果页面的贡献值是相对排在第一位那个结果来得小的。
为了能够完成评估排序的目的，我们需要采用DCG（Discounted Cumulative Gain）值。
DCG的思想比较容易理解，等级比较高的结果却排到了比较后面，那么在统计分数时，就应该对这个结果的得分有所打折。一个有P（P≥2）个结果的搜索结果页面的DCG定义为：
为什么要用以2为底的对数函数？这个并没有明确的科学依据，大概是根据大量的用户点击与其所点内容的位置信息，模拟出一条衰减的曲线。
那么在上面百度的例子中：DCG=3+(1+1.26+1.5+0.86)=7.62。但是DCG在评估策略效果的过程中，因为不同搜索模型给出的结果有多有少，仍然会造成无法对比两个模型的效果。为了避免这种情况，我们进一步优化这个指标，成为nDCG（normalize DCG），顾名思义，就是将一个策略的效果标准归一化，以方便不同策略的效果对比。公式如下：
公式中的iDCG（ideal DCG）就是理想的DCG。iDCG如何计算？首先要拿到搜索的结果，然后对这些结果进行排序，排到最好的状态后，算出这个排列下的DCG，就是iDCG。因此nDCG是一个0-1的值，nDCG越靠近1，说明策略效果越好，或者说只要nDCG<1，策略就存在优化调整空间。因为nDCG是一个相对比值，那么不同的搜索结果之间就可以通过比较nDCG来决定哪个排序比较好。在上面的例子中，理想的排序应该是3 、3 、2 、2 、1，那么iDCG=3+3+1.26+1+0.43=8.69，nDCG=DCG/iDCG=7.62/8.69=0.88。
以上给大家介绍一些常见的评价方式，但是这几种评估方式并不一定能覆盖所有场景，一般情况下，我们需要根据自己的需要适当的对这些评估方式做些许的改进来更加符合具体场景的要求，比如在nDCG中调整评分的层级或分数，甚至根据自身用户的特征调整衰减函数的计算方式等等。但在所有的评估改进中，一般无法忽略召回率、正确率和排序三个基本维度的效果。我们不能照搬前人成果，活学活用，才是产品经理应该做的事情。
你必须要知道的软件测试3个主流方式
在产品项目的最后推进过程中，会经过一系列的测试来判断以及优化产品，在测试中使产品的属性特征最优化，最终达到吸引更多客户的目的；本文作者分享了三种软件测试的主流方式，我们一起来了解一下。
在产品概念阶段，开展“电梯测试”是为了确定定位策略，将产品特征转化成显著的客户利益；在产品设计阶段，只有产品模型，测试目的是如果使产品的属性特征最优化，从而更吸引客户。
当产品最终完成但还没有引入市场时，实施产品测试是为了控制产品质量，维持产品生命。在产品正式上市前进行小范围的市场测试，目的在于识别竞争对手的实力和弱势（如果产品有做进一步改进的潜力的话，还可进行改进测试），确定产品在目标市场中的位置。
产品测试的目的随着被测试产品的发展或生命周期的不同阶段而不同，决定采用哪种测试研究方式是建立在研究的目的之上的，所以并没有一种测试可以称得上是最好的。
阿尔法α（Alpha）、贝塔β（Beta）、伽马λ（Gamma）测试常用来表示软件测试过程中的三个阶段，用于在开发流程中和上市前夕测试新产品：
- α是第一阶段，一般只供内部测试使用；
- β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；
- λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。
由于样本选择缺乏统计基础，这种市场研究方式不提供具体的统计置信度，即这种方式不是严格意义上的定量分析，但它确实能够提供客户在使用产品后的详细反馈；此处，客户面对的是最终产品，或非常接近最终形态和功能的产品，测试有助于对产品进行验证和改进修正。
以下为大家详加介绍阿尔法、贝塔、伽马和试销主流测试方式：
一、阿尔法测试
阿尔法测试类似于可用性测试（在软件领域称之为软件测试），通常由内部测试人员完成；在极为少见的情况下，阿尔法测试是由客户过外部人员完成的，阿尔法测试发布的版本被称之为阿尔法版本（在软件领域常被称之为DAT开发测试[张乐飞1] 环境应用）。
阿尔法测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，试图发现错误并修正，阿尔法测试由程序员或测试员完成。
阿尔法测试的关键在于——尽可能逼真地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式。
阿尔法测试的目的是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持），尤其注重产品的界面和特色。
阿尔法测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始，有关的“测试用例”应该在阿尔法测试前准备。
软件测试是在软件交付用户使用或投入运行前，对软件需求规格说明、设计规格说明和编码的最终复审，是软件质量保证的关键步骤，软件测试是为了发现错误而执行程序的过程。
软件测试在软件生命周期中横跨两个阶段：通常在编写出每一个模块之后就需要对它做必要的测试（称为单元测试），编码和单元测试属于软件生命周期中的同一个阶段；在结束这个阶段后对软件系统还要进行各种综合测试，如集成测试、系统测试、性能测试和配置测试等，这是软件生命周期的另一个独立阶段，即测试阶段。
只有当阿尔法测试达到一定的可靠程度时，才能开始贝塔测试，阿尔法测试即为非正式验收测试，经过Alpha测试调整的软件产品称为贝塔版本。
二、贝塔测试
贝塔测试是一种验收测试，所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。
通过了验收测试，产品就会进入发布阶段，贝塔测试后发布的版本被称为贝塔版本（在一些企业称之为UAT用户测试[张乐飞2] 环境应用）；可以说，贝塔测试是“预发布测试”。
软件的贝塔测试版本将会被在网上发布，提供给广大用户，从而使该程序进人“真实世界”测试，并为下一个发布版本提供部分预览。贝塔测试的主要目的在于，获得不同客户群体的反馈以及检查在不同类型的网络和硬件下产品的兼容性。
贝塔测试由软件的最终用户们在一个或多个客户场所进行。与阿尔法测试不同，开发者通常不在贝塔测试的现场，因贝塔测试是软件在开发者不能控制的环境中的“真实”应用。
用户贝塔测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在贝塔测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
在B2B环境中，贝塔测试通常包含以下4个方面。
- 确定一小群“种子”客户，这群客户常被称为领先客户或领先用户。
- 构建一个测试计划，并确定产品开发、市场营销、销售和产品管理中的关键角色和职责。测试计划要包含试验的持续时间和试验后处置结果。
- 客户与产品公司之间的合同包含项目计划，以便客户能明白目标、持续时间和延期补偿。另外，保密条款也应该包括在内。
- 客户应该了解要测试什么及如何反馈结果。团队需要确保能收集客户数据，能组织任何最后的访谈，并能把产品带回实验室。
验收测试要通过一系列黑盒测试。验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。
通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始；验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。
无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。
验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
大型通用软件在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。
三、伽马测试
伽马测试是终级测试，测试之后，该软件几乎就是上市的最终版本了；此时，不再进行软件的功能开发或改进。
在这一阶段唯一可能修改的是限定范围内的代码错误，当该软件已经准备好发布且能够满足各类要求后，就开始进行伽马测试，测试时无须进行其他任何内部测试。
除了在开发周期时间极短、上市速度要求极快的高压情境下（由于伽马测试并不常见，因此在此不做太多赘述）。
最后下面是我整理出来的一份软件测试工程师发展方向知识架构体系图。
希望大家能在这个成长过程中收益良多。可以说，这个过程会让你痛不欲生，但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难，只要迈出了第一步，你就已经成功了一半，古人说的好“不积跬步，无以至千里。”等到完成之后再回顾这一段路程的时候，你肯定会感慨良多。
由于CSDN上传图片大小有限，有需要的朋友可以关注我的公众号：程序员二黑，回复1，即可获取原图。
下面是一份配套的软件测试资源包：
上面是一些配套资源，这些资源对于软件测试的的朋友来说应该是最全面最完整的备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。关注我的微信公众号：程序员二黑，即可免费获取！
最困难的时候，也就是我们离成功不远的时候！如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们的群：785128166 大家一起讨论交流学习。
如果您觉得文章还不错，请 点赞、分享、在看、收藏 一下，因为这将是我持续输出更多优质文章的最强动力！
精彩推荐
以上是关于搜索排序评估方法：作为产品，这个你必须要了解的主要内容，如果未能解决你的问题，请参考以下文章