You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

74 lines
9.7 KiB
Markdown

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# 040 | 搜索系统评测,有哪些基础指标?
我在之前几周的专栏文章里主要讲解了最经典的信息检索Information Retrieval技术和基于机器学习的排序学习算法Learning to Rank以及如何对查询关键字Query进行理解包括查询关键字分类、查询关键字解析以及查询关键字扩展。这些经典的技术是2000年后开始流行的各类搜索引擎的核心技术。
在进一步介绍更多的搜索引擎技术前我觉得有必要专门抽出一周时间来好好地看一下搜索系统的评测Evaluation以及我们经常使用的各类指标Metric。俗话说得好“如果你不能衡量它你就不能改进它”If You Can't Measure It, You Can't Improve It。意思其实就是说对待一个系统如果我们无法去衡量这个系统的好坏没有相应的评测指标那就很难真正地去琢磨怎么改进这些指标从而达到提升系统的目的。
虽然我们这里是在搜索系统这个重要场景中讨论评测和指标,但实际上我们这周要讨论的很多细节都可以应用到很多类似的场景。比如,我们后面要讨论的推荐系统、广告系统等,在这些场景中几乎就可以无缝地使用这周要讲的很多内容。
## 线下评测
假设你今天开发了一个新软件,比如说是一个最新的手机软件,你怎么知道你的用户是不是喜欢你的软件呢?你怎么知道你的用户是不是愿意为你的软件掏钱呢?
**评测的核心其实就是了解用户的喜好**。最直接的方法,当然是直接询问用户来获得反馈。例如你可以对每一个下载了你手机软件的用户强行进行问卷调查,询问他们对待新软件的态度。
然而,我们很快就会发现这样的方法是行不通的。姑且不说用户是否会因为这样强行的方式产生反感,我们是不是能通过这些调查问卷获得用户的真实反馈,这本身就是一个问题。这里面涉及到调查问卷设计的科学性问题。
即便这些调查问卷都能完整准确地反映出用户对手机软件的看法,真正实施起来也会面临种种困难。如果这款手机软件的用户数量有百万甚至千万,那我们就要进行如此大规模的问卷调查,还要处理调查后的数据,显然这样做的工作量非常大。而这些调查问卷是没法反复使用的,因为下一个版本的软件更新后,用户的态度就会发生改变,这样的方式就没法系统地来帮助软件迭代。
那么如何才能形成一组数据来帮助系统反复迭代,并且还能够减少人工成本,这就成了一个核心问题。
在信息检索系统开发的早年研究人员和工程师们就意识到了这个核心问题的重要性。英国人赛利尔·克莱温顿Cyril Cleverdon可以算是最早开发线下测试集的计算机科学家。
赛利尔生于1914年在英国的布里斯托Bristol图书馆工作了很长时间。从1950年开始赛利尔就致力于开发信息检索系统以提高图书馆查询的效率。1953年他尝试建立了一个小型的测试数据集用于检测图书管理员查找文档的快慢。这个工作最早发表于1955年的一篇论文参考文献\[1\])。
这之后,英美的一些早期信息检索系统的研发都开始顺应这个思路,那就是为了比较多个系统,首先构造一个线下的测试数据集,然后利用这个测试集对现有的系统反复进行改进和提升。如果你想对早期测试集的构造以及信息有所了解,建议阅读文末的参考文献\[2\]。
那么,当时构造的这些测试数据集有些什么特点呢?
**这些测试数据集都会包含一个查询关键字集合**。这个集合包含几十到几百不等的查询关键字。一方面,这些关键字的选取大多来自于经验。另一方面,从赛利尔就开始认识到,需要保证有一些信息一定能够通过这些关键字来找到。其实,这里就是在测试我们后面要讲的“召回”。
在有了这些查询关键字以后,**这些测试数据集往往有几百到几千不等的文档**。这些文档中的某一部分,研究人员在构造数据集的时候就知道了会包含所对应查询关键字需要的信息,也就是我们后面要说的相关文档。
你可以看到几十到几百的查询关键字以及几千个文档很明显不能代表所有可能使用系统的用户的行为。你甚至可以说这都无法代表绝大多数用户的行为。然而这种测试集的好处是查询关键字和文档本身是和要测试的系统无关的。也就是说今天我们要测试系统A还是明天要测试系统B都可以反复利用同样一组测试数据集。这样做的好处相比于我们之前提到的问卷调查是显而易见的。
另外,我需要强调的是,“用户”这个概念在测试数据集中被“抽象”出去了。当我们在讨论文档相对于某个查询关键字的相关度时,我们假定这种相关度是恒定的,是对于所有用户都适用的。因此,究竟是哪位用户在使用这个系统并不重要。只要研发的系统能够在这些“标准化”的查询关键字和文档的集合表现优异,我们就相信这个系统能够满足所有用户的需要。
因为测试数据集并不是用户与产品交互产生的真实回馈结果,所以我们往往又把测试数据集叫作“线下评测数据”。
## 基于二元相关度的评测指标
从线下收集评测数据以后,我们最容易做到的就是利用“二元相关度”所定义的一系列评测指标来衡量手中系统的好坏。
什么叫“二元相关度”呢?简单来说,就是指**针对某一个查询关键字而言,整个测试集里的每一个文档都有一个要么“相关”要么“不相关”的标签**。在这样的情况下,不存在百分比的相关度。而每个文档针对不同的关键字,有不同的相关信息。
假定某个系统针对某个关键字,从测试数据集中提取一定量的文档而不是返回所有文档,我们就可以根据这个提取的文档子集来定义一系列的指标。
有两个定义在“二元相关度”上的指标就成了很多其他重要指标的基石。一个叫**“精度**”Precision也就是说在提取了的文档中究竟有多少是相关的。另一个叫“**召回**”Recall也就是说 在所有相关的文档中,有多少是提取出来了的。
“精度”和“召回”的相同点在于分子都是“即被提取出来了又相关的文档数目”。这两个指标所不同的则是他们的分母。“精度”的分母是所有提取了的文档数目而“召回”的分母则是所有相关的文档数目。如果我们返回所有的文档“召回”是1“精度”则是相关文档在全集中的比例。因此我们注意到这两个指标其实都假定提取的文档数目相比于全集而言是相对比较小的子集。
很快大家从实践中就体会到“精度”和“召回”就像是“鱼与熊掌不可兼得”。一个系统很难做到“精度”和“召回”都能够达到很高的数值。也就是说我们往往需要在这两个指标之间做一些平衡。于是研究人员开始寻找用一个数字来表达“精度”和“召回”的“平均水平”。来自英国的学者范·李杰斯博格C. J. van Rijsbergen最早在论文中采用了 “**调和平均数**” Harmonic Mean来计算 “精度”和“召回”的平均(参考文献 \[3\])。这个方法被后人称为“**F值**” ,并且一直沿用至今。
这里对“精度”和“召回”还需要注意一点因为这两个指标都是基于“二元相关度”的。因此这两个指标都不是“排序指标”Ranking Metrics。换句话说这两个指标其实并不能真正评价排序系统。
比如我们针对某个关键字提取10个文档如果有3个相关文档被取出来不管是“精度”还是“召回”都无法分辨这三个文档在最后序列中的位置是头三位还是后面的三位很遗憾“精度”和“召回”都无法解决这个问题。“二元相关度”的这个问题也就指引研究人员去开发真正能对排序进行评估的指标。
## 小结
今天我为你讲了搜索系统的评测和常用指标。这是现代搜索技术中一个非常重要的一个环节,那就是如何评价我们构建的系统。我们详细讲解了线下测试的由来以及这样的测试相比于调查问卷的优势。
一起来回顾下要点:第一,简要介绍了可重复使用的线下测试集的历史,以及这样的测试集都有什么特点与局限。第二,详细介绍了两个非常流行和重要的基于“二元相关度”的评测指标,那就是“精度”和“召回”。
最后,给你留一个思考题,我们讲了排序的好坏不能简单地从“精度”和“召回”的数值看出,那能不能动一些手脚呢?如果我们就依赖“二元相关度”,有没有什么方法来看“排序”的好坏呢?
欢迎你给我留言,和我一起讨论。
**参考文献**
1. R.G. THORNE, B.Sc., A.F.R.Ae.S. The Efficiency Of Subject Catalogues and The Cost of Information Searches. _Journal of Documentation_, Vol. 11 Issue: 3, pp.130-148, 1995.
2. K. SPARCK JONES, C.J. VAN RIJSBERGEN. Information Retrieval Test Collections. _Journal of Documentation_, Vol. 32 Issue: 1, pp.59-75, 1976.
3. C.J. VAN RIJSBERGEN. Foundation of Evaluation. _Journal of Documentation_, Vol. 30 Issue: 4, pp.365-373, 1974.