怎样量化评价搜索引擎的结果质量

2011 年 6 月 01 日

前言

搜索质量评估是搜索技术研究的基础性工作,也是核心工作之一。评价(Metrics)在搜索技术研发中扮演着重要角色,以至于任何一种新方法与他们的评价方式是融为一体的。

搜索引擎结果的好坏与否,体现在业界所称的在相关性(Relevance)上。相关性的定义包括狭义和广义两方面,狭义的解释是:检索结果和用户查询的相关程度。而从广义的层面,相关性可以理解为为用户查询的综合满意度。直观的来看,从用户进入搜索框的那一刻起,到需求获得满足为止,这之间经历的过程越顺畅,越便捷,搜索相关性就越好。本文总结业界常用的相关性评价指标和量化评价方法。供对此感兴趣的朋友参考。

Cranfield 评价体系

A Cranfield-like approach 这个名称来源于英国 Cranfield University,因为在二十世纪五十年代该大学首先提出了这样一套评价系统:由查询样例集、正确答案集、评测指标构成的完整评测方案,并从此确立了“评价”在信息检索研究中的核心地位。

Cranfield 评价体系由三个环节组成:

  1. 抽取代表性的查询词,组成一个规模适当的集合
  2. 针对查询样例集合,从检索系统的语料库中寻找对应的结果,进行标注(通常人工进行)
  3. 将查询词和带有标注信息的语料库输入检索系统,对系统反馈的检索结果,使用预定义好的评价计算公式,用数值化的方法来评价检索系统结果和标注的理想结果的接近程度

查询词集合的选取

Cranfield 评价系统在各大搜索引擎公司内有广泛的应用。具体应用时,首先需要解决的问题是构造一个测试用查询词集合。

按照 Andrei Broder(曾在 AltaVista/IBM/Yahoo 任职)的研究,查询词可分为 3 类:寻址类查询(Navigational)、信息类查询 (Informational)、事务类查询 (Transactional)。对应的比例分别为

复制代码
Navigational12.3%
Informational62.0%
Transactional25.7%

为了使得评估符合线上实际情况,通常查询词集合也会按比例进行选取。通常从线上用户的 Query Log 文件中自动抽取。

另外查询集合的构造时,除了上述查询类型外,还可以考虑 Query 的频次,对热门 query(高频查询)、长尾 query(中低频)分别占特定的比例。

另外,在抽取 Query 时,往往 Query 的长短也是一个待考虑的因素。因为短 query(单 term 的查询)和长 Query(多 Term 的查询)排序算法往往会有一些不同。

构成查询集合后,使用这些查询词,在不同系统(例如对比百度和 Google)或不同技术间(新旧两套 Ranking 算法的环境)进行搜索,并对结果进行评分,以决定优劣。

附图:对同一 Query:“社会保险法”,各大搜索引擎的结果示意图。下面具体谈谈评分的方法。

Precision-recall(准确率 - 召回率方法)

计算方法

信息检索领域最广为人知的评价指标为 Precision-Recall(准确率 - 召回率)方法。该方法从提出至今已经历半个世纪,至今在很多搜索引擎公司的效果评估中使用。

顾名思义,这个方法由准确率和召回率这两个相互关联的统计量构成:召回率(Recall)衡量一个查询搜索到所有相关文档的能力,而准确率(Precision)衡量搜索系统排除不相关文档的能力。(通俗的解释一下:准确率就是算一算你查询得到的结果中有多少是靠谱的;而召回率表示所有靠谱的结果中,有多少被你给找回来了)。这两项是评价搜索效果的最基础指标,其具体的计算方法如下。

Precision-recall 方法假定对一个给定的查询,对应一个被检索的文档集合和一个不相关的文档集合。这里相关性被假设为二元的,用数学形式化方法来描述,则是:

A 表示相关文档集合

A 表示不相关集合

B 表示被检索到的文档集合

B 表示未被检索到的文档集合

则单次查询的准确率和召回率可以用下述公式来表达:

(运算符∩ 表示两个集合的交集。|x|符号表示集合 x 中的元素数量)

从上面的定义不难看出,召回率和准确率的取值范围均在 [0,1] 之间。那么不难想象,如果这个系统找回的相关越多,那么召回率越高,如果相关结果全部都给召回了,那么 recall 此时就等于 1.0。

相关的

不相关

被检索到

A∩ B

A∩ B

未被检索到

A∩B

A∩B

Precision-Recall 曲线

召回率和准确率分别反映了检索系统的两个最重要的侧面,而这两个侧面又相互制约。因为大规模数据集合中,如果期望检索到更多相关的文档,必然需要“放宽”检索标准,因此会导致一些不相关结果混进来,从而使准确率受到影响。类似的,期望提高准确率,将不相关文档尽量去除时,务必要执行更“严格”的检索策略,这样也会使一些相关的文档被排除在外,使召回率下降。

所以为了更清晰的描述两者间的关系,通常我们将 Precison-Recall 用曲线的方式绘制出来,可以简称为 P-R diagram。常见的形式如下图所示。(通常曲线是一个逐步向下的走势,即随着 Recall 的提高,Precision 逐步降低)

P-R 的其它形态

一些特定搜索应用,会更关注搜索结果中错误的结果。例如,搜索引擎的反作弊系统(Anti-Spam System)会更关注检索结果中混入了多少条作弊结果。学术界把这些错误结果称作假阳性(False Positive)结果,对这些应用,通常选择用虚报率(Fallout)来统计:

Fallout 和 Presion 本质是完全相同的。只是分别从正反两方面来计算。实际上是 P-R 的一个变种。

再回到上图,Presion-Recall 是一个曲线,用来比较两个方法的效果往往不够直观,能不能对两者进行综合,直接反映到一个数值上呢?为此 IR 学术界提出了 F 值度量(F -Measure)的方法。F-Measure 通过 Presion 和 Recall 的调和平均数来计算,公式为:

其中参数λε(0,1) 调节系统对 Precision 和 Recall 的平衡程度。(通常取λ=0.5,此时

这里使用调和平均数而不是通常的几何平均或算术平均,原因是调和平均数强调较小数值的重要性,能敏感的反映小数字的变化,因此更适合用来反映检索效果。

使用 F Measure 的好处是只需要一个单一的数字就可以总结系统的检索效果,便于比较不同搜索系统的整体效果。

P@N 方法

点击因素

传统的 Precision-Recall 并不完全适用对搜索引擎的评估,原因是搜索引擎用户的点击方式有其特殊性,包括:

复制代码
A 60-65% 的查询点击了名列搜索结果前 10 条的网页;
B 20-25% 的人会考虑点击名列 1120 的网页;
C 仅有 3-4% 的会点击名列搜索结果中列第 21 到第 30 名的网页

也就是说,绝大部分用户是不愿意翻页去看搜索引擎给出的后面的结果。

而即使在搜索结果的首页(通常列出的是前 10 条结果),用户的点击行为也很有意思,我们通过下面的 Google 点击热图(Heat Map)来观察(这个热图在二维搜索结果页上通过光谱来形象的表达不同位置用户的点击热度。颜色约靠近红色表示点击强度越高):

从图中可以看出,搜索结果的前 3 条吸引了大量的点击,属于热度最高的部分。也就是说,对搜苏引擎来说,最前的几条结果是最关键的,决定了用户的满意程度。

康乃尔大学的研究人员通过 eye tracking 实验获得了更为精确的 Google 搜索结果的用户行为分析图。从这张图中可以看出,第一条结果获得了 56.38% 的搜索流量,第二条和第三条结果的排名依次降低,但远低于排名第一的结果。前三条结果的点击比例大约为 11:3:2 。而前三条结果的总点击几乎分流了搜索流量的 80%。

另外的一些有趣的结论是,点击量并不是按照顺序依次递减的。排名第七位获得的点击是最少的,原因可能在于用户在浏览过程中下拉页面到底部,这时候就只显示最后三位排名网站,第七名便容易被忽略。而首屏最后一个结果获得的注意力(2.55)是大于倒数第二位的 (1.45),原因是用户在翻页前,对最后一条结果印象相对较深。搜索结果页面第二页排名第一的网页(即总排名 11 位的结果)所获得的点击只有首页排名第十网站的 40%,与首页的第一条结果相比,更是只有其 1/60 至 1/100 的点击量。

因此在量化评估搜索引擎的效果时,往往需要根据以上搜索用户的行为特点,进行针对性的设计。

P@N 的计算方法

P@N 本身是 Precision@N 的简称,指的是对特定的查询,考虑位置因素,检测前 N 条结果的准确率。例如对单次搜索的结果中前 5 篇,如果有 4 篇为相关文档,则 P@5 = 4/5 = 0.8 。

测试通常会使用一个查询集合(按照前文所述方法构造),包含若干条不同的查询词,在实际使用 P@N 进行评估时,通常使用所有查询的 P@N 数据,计算算术平均值,用来评判该系统的整体搜索结果质量。

N 的选取

对用户来说,通常只关注搜索结果最前若干条结果,因此通常搜索引擎的效果评估只关注前 5、或者前 3 结果,所以我们常用的 N 取值为 P@3 或 P@5 等。

对一些特定类型的查询应用,如寻址类的查询(Navigational Search),由于目标结果极为明确,因此在评估时,会选择 N=1(即使用 P@1)。举个例子来说,搜索“新浪网”、或“新浪首页”,如果首条结果不是 新浪网(url: www.sina.com.cn ),则直接判该次查询精度不满足需求,即 P@1=0

MRR

上述的 P@N 方法,易于计算和理解。但细心的读者一定会发现问题,就是在前 N 结果中,排序第 1 位和第 N 位的结果,对准确率的影响是一样的。但实际情况是,搜索引擎的评价是和排序位置极为相关的。即排第一的结果错误,和第 10 位的结果错误,其严重程度有天壤之别。因此在评价系统中,需要引入位置这个因素。

MRR 是平均排序倒数(Mean Reciprocal Rank)的简称,MRR 方法主要用于寻址类检索(Navigational Search)或问答类检索(Question Answering),这些检索方法只需要一个相关文档,对召回率不敏感,而是更关注搜索引擎检索到的相关文档是否排在结果列表的前面。MRR 方法首先计算每一个查询的第一个相关文档位置的倒数,然后将所有倒数值求平均。例如一个包含三个查询词的测试集,前 5 结果分别为:

复制代码
查询一结果:1.AN 2.AR 3.AN 4.AN 5.AR
查询二结果:1.AN 2.AR 3.AR 4.AR 5.AN
查询三结果:1.AR 2.AN 3.AN 4.AN 5.AR

其中 AN 表示不相关结果,AR 表示相关结果。那么第一个查询的排序倒数(Reciprocal Rank)RR1 = 1/2=0.5 ;第二个结果 RR2 = 1/2 = 0.5 ; 注意倒数的值不变,即使查询二获得的相关结果更多。同理,RR3= 1/1 = 1。 对于这个测试集合,最终 MRR=(RR1+RR2+RR3)/ 3 = 0.67

然而对大部分检索应用来说,只有一条结果无法满足需求,对这种情况,需要更合适的方法来计算效果,其中最常用的是下述 MAP 方法。

MAP

MAP 方法是 Mean Average Precison,即平均准确率法的简称。其定义是求每个相关文档检索出后的准确率的平均值(即 Average Precision)的算术平均值(Mean)。这里对准确率求了两次平均,因此称为 Mean Average Precision。(注:没叫 Average Average Precision 一是因为难听,二是因为无法区分两次平均的意义)

MAP 是反映系统在全部相关文档上性能的单值指标。系统检索出来的相关文档越靠前 (rank 越高),MAP 就应该越高。如果系统没有返回相关文档,则准确率默认为 0。

例如:假设有两个主题:

主题 1 有 4 个相关网页,主题 2 有 5 个相关网页。

某系统对于主题 1 检索出 4 个相关网页,其 rank 分别为 1, 2, 4, 7;

对于主题 2 检索出 3 个相关网页,其 rank 分别为 1,3,5。

对于主题 1,平均准确率 MAP 计算公式为:

复制代码
(1/1+2/2+3/4+4/7)/4=0.83

对于主题 2,平均准确率 MAP 计算公式为:

复制代码
(1/1+2/3+3/5+0+0)/5=0.45

则 MAP= (0.83+0.45)/2=0.64。”

DCG 方法

DCG 是英文 Discounted cumulative gain 的简称,中文可翻译为“折扣增益值”。DCG 方法的基本思想是:

  1. 每条结果的相关性分等级来衡量
  2. 考虑结果所在的位置,位置越靠前的则重要程度越高
  3. 等级高(即好结果)的结果位置越靠前则值应该越高,否则给予惩罚

我们首先来看第一条:相关性分级。这里比计算 Precision 时简单统计“准确”或“不准确”要更为精细。我们可以将结果细分为多个等级。比如常用的 3 级:Good(好)、Fair(一般)、Bad(差)。对应的分值 rel 为:Good:3 / Fair:2 / Bad:1 。一些更为细致的评估使用 5 级分类法:Very Good(明显好)、Good(好)、Fair(一般)、Bad(差)、Very Bad(明显差),可以将对应分值 rel 设置为:Very Good:2 / Good:1 / Fair:0 / Bad:-1 / Very Bad: -2

评判结果的标准可以根据具体的应用来确定,Very Good 通常是指结果的主题完全相关,并且网页内容丰富、质量很高。而具体到每条

DCG 的计算公式并不唯一,理论上只要求对数折扣因子的平滑性。我个人认为下面的 DCG 公式更合理,强调了相关性,第 1、2 条结果的折扣系数也更合理:

此时 DCG 前 4 个位置上结果的折扣因子(Discount factor)数值为:

i

log2 (i+1)

1/log2 (i+1)

1

1

1

2

1.59

0.63

3

2

0.5

4

2.32

0.43

取以 2 为底的 log 值也来自于经验公式,并不存在理论上的依据。实际上,Log 的基数可以根据平滑的需求进行修改,当加大数值时(例如使用 log5 代替 log2),折扣因子降低更为迅速,此时强调了前面结果的权重。

为了便于不同类型的 query 结果之间横向比较,以 DCG 为基础,一些评价系统还对 DCG 进行了归一,这些方法统称为 nDCG(即 normalize DCG)。最常用的计算方法是通过除以每一个查询的理想值 iDCG(ideal DCG)来进行归一,公式为:

求 nDCG 需要标定出理想情况的 iDCG,实际操作的时候是异常困难的,因为每个人对“最好的结果”理解往往各不相同,从海量数据里选出最优结果是很困难的任务,但是比较两组结果哪个更好通常更容易,所以实践应用中,通常选择结果对比的方法进行评估。

怎样实现自动化的评估?

以上所介绍的搜索引擎量化评估指标,在 Cranfield 评估框架(Cranfield Evaluation Framework)中被广泛使用。业界知名的 TREC(文本信息检索会议)就一直基于此类方法组织信息检索评测和技术交流。除了 TREC 外,一些针对不同应用设计的 Cranfield 评测论坛也在进行进行(如 NTCIR、IREX 等)。

但 Cranfield 评估框架存在的问题是查询样例集合的标注上。利用手工标注答案的方式进行网络信息检索的评价是一个既耗费人力、又耗费时间的过程,只有少数大公司能够使用。并且由于搜索引擎算法改进、运营维护的需要,检索效果评价反馈的时间需要尽量缩短,因此自动化的评测方法对提高评估效率十分重要。最常用的自动评估方法是 A/B testing 系统。

A/B Testing

A/B Testing 系统

A/B testing 系统在用户搜索时,由系统来自动决定用户的分组号(Bucket id),通过自动抽取流量导入不同分支,使得相应分组的用户看到的是不同产品版本(或不同搜索引擎)提供的结果。用户在不同版本产品下的行为将被记录下来,这些行为数据通过数据分析形成一系列指标,而通过这些指标的比较,最后就形成了各版本之间孰优孰劣的结论。

在指标计算时,又可细分为两种方法,一种是基于专家评分的方法;一种是基于点击统计的方法。

专家评分的方法通常由搜索核心技术研发和产品人员来进行,根据预先设定的标准对 A、B 两套环境的结果给予评分,获取每个 Query 的结果对比,并根据 nDCG 等方法计算整体质量。

点击评分有更高的自动化程度,这里使用了一个假设:同样的排序位置,点击数量多的结果质量优于点击数量少的结果。(即 A2 表示 A 测试环境第 2 条结果,如果 A2 > B2,则表示 A2 质量更好)。通俗的说,相信群众(因为群众的眼睛是雪亮的)。在这个假设前提下,我们可以将 A/B 环境前 N 条结果的点击率自动映射为评分,通过统计大量的 Query 点击结果,可以获得可靠的评分对比。

Interleaving Testing

另外 2003 年由 Thorsten Joachims 等人提出的 Interleaving testing 方法也被广泛使用。该方法设计了一个元搜索引擎,用户输入查询词后,将查询词在几个著名搜索引擎中的查询结果随机混合反馈给用户,并收集随后用户的结果点击行为信息.根据用户不同的点击倾向性,就可以判断搜索引擎返回结果的优劣,

如下图所示,将算法 A 和 B 的结果交叉放置,并分流量进行测试,记录用户点击信息。根据点击分布来判断 A 和 B 环境的优劣。

Interleaving Testing 评估方法

Joachims 同时证明了 Interleaving Testing 评价方法与传统 Cranfield 评价方法的结果具有较高的相关性。由于记录用户选择检索结果的行为是一个不耗费人力的过程,因此可以便捷的实现自动化的搜索效果评估。

总结

没有评估就没有进步——对搜索效果的量化评测,目的是准确的找出现有搜索系统的不足(没有哪个搜索系统是完美的),进而一步一个脚印对算法、系统进行改进。本文为大家总结了常用的评价框架和评价指标。这些技术像一把把尺子,度量着搜索技术每一次前进的距离。


感谢张凯峰对 本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者 朋友交流。

2011 年 6 月 01 日 00:0028891

评论 2 条评论

发布
用户头像
为什么后面所有的图片都是一样的..
2020 年 04 月 21 日 20:40
回复
用户头像
谢谢作者,这篇文章对我很有帮助!
2020 年 04 月 21 日 20:03
回复
没有更多评论了
发现更多内容

阿里高工手码”537页Spring源码速成手册“3天直接带你飙向实战

比伯

Java 编程 架构 面试 计算机

甲方日常 74

句子

工作 随笔杂谈 日常

数字之暖:鹅厂云原生的“新路”与“历承”

脑极体

生产环境全链路压测建设历程 19:某快递 A 股上市公司的生产压测案例之下篇

数列科技杨德华

全链路压测 七日更

合约交易系统开发软件定制

系统开发咨询:I76-883I-5I52 邓森

区块链钱包app系统开发源码案例

系统开发咨询:I76-883I-5I52 邓森

阿里JAVA架构师面试136题含答案:JVM+spring+分布式+并发编程!

Crud的程序员

Java 程序员 架构 架构师

分布式缓存架构

raox

极客大学架构师训练营

执子之手,与子长安:探秘华为运动健康实验室

脑极体

区块链和通证经济带来的,是一部分股份制公司的消亡与重生

CECBC区块链专委会

金融 通证经济

音乐后期处理:音乐失真效果制作

懒得勤快

音乐制作 编曲 编曲宿主 mid 音乐后期

【数据结构与算法】分析时间复杂度与空间复杂度

三钻

数据结构与算法

盘点2020 | 所思、所遇、所学、所悟

三钻

程序员 前端 盘点2020

TARS 服务信息上报|全方位服务监控

TARS基金会

微服务 TARS 监控告警

week5-homework-一致性哈希

J

极客大学架构师训练营

TypeScript | 第四章:命名空间和模块

梁龙先森

typescript 前端 七日更

支持百万级TPS,Kafka是怎么做到的?

爱笑的架构师

kafka Kafka知识点 零拷贝 Mmap 七日更

Prometheus的使用:编写自己的exporter

Rayzh

Prometheus 监控告警

世界之书:《一个人的朝圣》与重归信仰

lidaobing

28天写作营 一个人的朝圣

10万级ETL批量作业调度工具Taskctl-Web应用版0元授权永久使用

会飞的鱼

大数据处理 kettle 运维自动化 海豚调度 批量任务

万字详解 阿里面试真题:请你说说索引的原理

Java架构师迁哥

TARS RPC 通信框架|提供多种远程调用方式

TARS基金会

微服务 RPC 远程调用 TARS

后端缓存代码实践

HQ数字卡

缓存击穿 七日更

甲方日常 73

句子

工作 随笔杂谈 日常

数字资产币种钱包APP系统开发方案

系统开发咨询:I76-883I-5I52 邓森

全国首张数字人民币保单成功出单

CECBC区块链专委会

数字人民币保单

第五课技术选型作业

Geek_michael

极客大学架构师训练营

第六周技术选型作业-CAP原理概述

Geek_michael

极客大学架构师训练营

函数进阶· 第3篇《常用内置函数filter()、map()、zip(),怎么用的呢?》

清菡

测试开发

有效破解行业难点 专家称区块链+医疗发展还需找准应用场景

CECBC区块链专委会

区块链 大数据 医疗

计算存储分离在消息队列上的应用

京东智联云开发者

大数据 云原生 中间件 消息中间件

怎样量化评价搜索引擎的结果质量-InfoQ