探寻搜索的多个维度(finding dimensions for queries)在线视频

在第三部分，我将介绍我自己的一篇论文。

这篇论文是关于如何从互联网上的大数据中挖掘知识的。

在这个工作中，我们试图通过搜索来发现

查询的维度。这个工作是我与窦志成、胡莎、罗宇龙和文继荣共同完成的。

这篇论文发表在CIKM 2011上。

在我们的论文中，

我们将

查询维度定义为一组条目。

每个条目描述

或者总结了

一个查询的

一个方面。在下一张幻灯片中，我会举一个例子。

我们还开发了一个系统

来实现我们所提出的方法。

这个系统叫做

QDMiner。当你们

输入一个查询请求时，QDMiner会

从搜索引擎中提取文档，然后

从搜索结果中挖掘多组查询请求维度。

请注意，

对于一个查询请求，

我们会返回一个或者多个维度。

这里是一些例子，

对于“手表”这个查询请求，

我们会为你们返回这五个维度。

第一个维度包括很多手表的品牌，

如卡地亚、欧米茄和西铁城。

第二个、第三个和第四个

维度

是手表的分类。

第五个维度包括很多不同颜色

的手表。

所有这些对你们都是有意义的，

对么？

对于像世界上跑得最快的动物这样的长查询请求，

我们也会返回三个类似的维度。

对于像CIKM的短查询请求，我们

也能够返回一些相关的维度。

第三维度非常有意思，

是一些跟CIKM相似的会议。

为什么要研究查询请求维度呢？我想给大家讲一个故事。

是这个故事激励我们研究查询请求维度。

实际上，我们这几位作者中的一位

要纪念和妻子结婚

十周年的纪念日。

因此，他想给

他的妻子一个令人惊喜的礼物。

手表就是最好的选择。

然而，这位作者并不了解手表。

他花费了很多时间

在互联网上搜索、阅读。

你们知道，寻找

哪个手表是最适合他的。

最后，我们发现，

这个过程可以由计算机自动完成。

我们可以利用搜索引擎和我们的

文本挖掘技术来帮助计算机

理解一个查询请求，

例如“手表”这样的查询请求。

因此，我们做了这件事情。

我们想要汇总这个查询请求相关的信息，

并为用户提供

一些直接的答案或者一些

事实，

关于查询请求的。

查询请求的维度对模糊查询请求同样有用。

例如，对像“苹果”这样的模糊查询请求，“苹果”可能是指一家公司，

也可能是指一种水果。

这里是我们为“苹果”挖掘的维度，你们可以

看到，第一个维度包括苹果公司的很多不同产品，

第二个维度也

包括一些类型的苹果产品。

第三个维度非常有趣，是水果，

而不是苹果公司。

我们还能够展示一些

不同品种的苹果的图片，

然后我们可以看到这里有很多有趣的图片。

在我们发现了

这个有趣的问题之后，我们研究了

解决这个问题的可行性，我们

观察了很多查询请求的搜索结果，

发现了一些合理的假设。

如你们所见，第一个假设是，

一个查询请求的一些重要方面通常

会由搜索结果中的

列表形式呈现。

第二个假设

是，重要或者有意义的列表通常

会在排序最靠前的搜索结果中出现多次。

在下一部分，我们使用“手表”作为一个运行示例。

因此，首先，当

你在一个搜索引擎中搜索“手表”时，你可以获得一个

像这样的搜索结果，对么？

当你点击某个搜索结果时，

你可以看到一个像这样的页面。

这是第一个页面。在这个页面中，

网站管理员展示了

一些关于手表的重要信息。

在左边，你可以

看到一些手表的分类

列表。

在中间，你可以

看到一些不同的手表。

它们都是由一些重复的模式表示的。

这是第二个搜索结果页面。在这个

页面，你还可以在页面左边获得很多手表的分类信息

或者品牌信息，

在页面中间是手表的详细信息。

这是第三个搜索结果页面。

同样的，在页面左边，你能够获得手表的品牌列表。

页面中间是一些使用重复的模式

表示的手表信息。

页面上还有一些其他列表，

你们知道，像导航栏和不同的价格。

第四个页面来自亚马逊。在页面左边，我们能够

以列表的形式

获得不同的手表分类。

还有一些信息是用自由文本的形式表示的。

第五个页面来自维基百科。在这个

页面中，我们能够从

HTML标签

或者自由文本中发现列表。

为了发现搜索请求的维度，我们设计了四个

模块。

它们是

列表提取、列表加权、列表集群以及维度和

项目排序。我会简要

说明这些模块。

当我们为查询请求获得了一些搜索结果，首先我们能够

从页面中提取所有列表。然后，

我们将对每个列表赋予一定的权重。接下来，我们能够

将重要的列表排在前面。

下一步，我们将把相似的列表聚集在一起。

例如，品牌可能

分布在不同列表中。

但是我们可以把它们通过聚类合并到一起。

最后一步，

你们知道，

是获得一些维度，

并在每个维度内对条目进行排序。

我们做了很多工作在

列表提取方面，这是因为

我们得到的列表越多，我们就更有可能

发现重要和有用的维度。

首先，我们可以从自由文本中挖掘列表，

使用一些正则表达式。

然后，

第二步我们可以利用HTML标签

来提取列表。

例如，UL/OL

表。

此外，我们可以提取列表

通过挖掘重复模式。

你们知道，我们可以挖掘

一些重复的HTML标签组。

然后，我们可以把

不同组中的相似部分排列在一起。

例如，在这个页面中，

我们有

四个条目，我们可以

把图像排列到一起，把条目

名字排列到一起或者放在一起评级。

这里我们展示的是一张表，

包括从手表的搜索结果中挖掘的所有列表。

请看看这张表，从

第一个搜索结果中，我们挖掘了三个

列表。从第二个搜索结果中，我们挖掘了

两个列表。从第三个搜索结果中，我们

挖掘了两个或者更多的列表。由于我们无法

在这里展示所有列表，因此这里为大家展示的是排名在最前面的列表。

第二个模块是列表加权。

并不是所有的列表都是有用或者有意义的。

因此，例如，在这张表里面，我们

获得了一些无用列表。我们怎么来对这些有用列表

之外的列表进行排序呢？

我们提出了一些进行列表加权的公式。

不用担心不理解这些具体的公示。我会解释从直觉上

如何来理解他们。首先，

你们知道，一个有用的列表通常出现在

搜索结果的最上方。这意味着它们与

查询请求更相关。因此，我们利用文档排名来进行列表加权。

第二点

是关于一个条目在一个列表中的特殊程度的。

例如，一些像“帮助”这样的条目

会出现在

任何地方，因此这个条目的

IDF值很低。

IDF是倒排文档频率。

我们从信息检索中借用了IDF这个概念。

然后，我们利用条目的IDF值

来进行列表加权。

最后，我们把这两个因素相乘

以获得最终的列表权重。

这张表展示了我们

为“手表”挖掘的列表以及各个表表的权重。

我们根据列表权重由高到低对列表进行排序，你们可以看见

一些手表品牌

的权重非常高，但是

一些这样的普通条目，如“我的帐号”、“我的购物车” 、

“RSS订阅”的得分非常低。

在这张表中，我们还能够

看到很多不同列表，这些列表描述了

不同的手表品牌。

因此，它们是，每一个条目是

不完整的。如果我们把它们合并起来，我们可以得到一个更加

完整的列表

为查询请求。

这就是我们要做列表聚集的原因。

我们的目标是把相似的列表放到一个组里面

来形成一个维度。实际上，我们

修改了

质量阈值算法。

更详细的信息大家可以在我们的论文中找到。

这里我只描述主要想法。首先，我们合并

包含相似条目的条目。

然后，我们计算每个群集的直径。

然后我们找出直径低于某个阈值

的大群集。然后，

权重更高的列表首先被合并到一起。

这个过程不断循环。

对于手表来说，我们获得了这个群集。

我们用颜色来表示群集。

因此，第一个群集

包括很多品牌的列表。因此我们可以通过把不同的列表

合并在一起来获得一个完整的品牌列表。

第二个群集

是用黄色表示的。

你可以看到，其中都是关于手表的分类的，

如女式手表、男式手表。

但我们获得了所有的群集，很自然可以

根据重要性对它们进行排序。因此，我们提出了一些

方法来

对维度进行加权，一个维度对应于一个群集。

这非常简单，我们仅仅是把一个维度中所有列表

的权重加起来作为维度的权重。当我们

对维度进行排序的时候，我们发现

在每个维度中对条目进行排序非常有用。

人们可以首先看到最重要的条目。

例如，

在手表分类这个群集中，

男式手表、女式手表

的出现次数最多。

因此，我们首先对它们进行排序。

在对其他出现次数很少的分类进行排序之前。因此，当

我们对条目进行排序之前，我们利用

包含某个条目的条目的数量

和条目在列表中的位置。

由于这项工作是很前沿的，因此我们没有已知的

数据集和评价方法。

我们自己建立了两个数据集。第一个数据集是

UserQ。

我们在内部发布了

QDMiner系统并邀请

我们的同事来试用。然后我们

得到了一些

由志愿者发出的查询请求。

最终，这个数据集包括89条查询请求。

第二个数据集是从必应的

搜索日志中抽取的。这个数据集中包括

100多条查询请求。我们把这个数据集称为RandQ，

因为这些查询请求是通过随机抽样获得的。

对于每个查询请求，我们首先要求一个标记者来为其增加

维度和条目，然后

五个标记者来对

维度的有用性进行排序。

它们可以把维度的有用性标记为不好、一般和好。

我们在这些判断的基础上

做了一些统计。

例如，对于userQ，用户

对每个查询评出了五个“好”的维度。

但是，对于RandQ，

被评为“好”的维度的数量就要少一些，大约有三个

维度被评为“好”。

对于每个查询请求，

在UserQ中都有大约两百个好的条目，

但是在RandQ中只有一百个好的条目。

对于每个维度，条目的数量

也是不同的。但是，差异很小。

我们也对生成的维度做了一些统计。

请大家看表5，表5表示了UserQ。

我们有89次查询请求。

对每次查询请求，我们提取了排名前100的搜索结果。

平均来说，每个文档出现在了44次查询请求的搜索结果中。

对于每个列表，

我们获得了

大约十个条目。

在每次查询请求中，我们最终挖掘出了32个维度。

这个数量比从RandQ中挖掘的条目的数量要多。

这意味着，对RandQ中的知识

进行挖掘更加困难。你们知道，对于每一个

维度，平均来说，

它都能包含七个列表。

在排名最前的五个维度中，

人们把2.3个维度

，即大约一半的维度评为“好”。因此，这些结果还不错。

在评价方面，我们利用了一些已有的

测量方法，同时也对其中的一些进行了修改

以适应我们的场景。首先，我们

对群集使用一些传统的测量项来

测量结果。我们还

修改了NDCG，这是一个

信息检索中测量

对有效性进行排序

的维度。

此外，我们还把一些测量项结合起来测量

最终的有效性。

我们的实验结果显示，

我们提出的方法具有非常

高的聚集质量，非常好的排名质量，

但是只有相对低的召回率。

我们尝试使用了不同数量的提取文档。

我们发现，使用更多的搜索结果可以获得

更好的查询请求维度。

而且，我们还想知道搜索结果质量是否

会影响搜索请求维度的质量。

因此，我们做了一些有意思的

实验。我们使用五个

三种不同的搜索结果。

第一种是“Top”，“Top”是原始搜索结果。

第二种搜索结果是“TopShuffle''”，是指我们第一次获得的排名前K的搜索结果，

但是对它们随机重新排序。

第三种搜索结果是“Random''”，是指我们从原始的

排名前100的搜索结果中随机选择K个。

“Random”类型的搜索结果的质量比“TopShuffle”类型和“Top”类型的搜索结果的质量要差。

让我们来看看左边的曲线。

我们能够看到更好的搜索结果，更好的

查询请求维度，正如我们所期望的。

我们使用了提取列表中的不同信息，

包括自由文本、HTML标签或者重复的

区域。

因此，我们比较这里的不同类型的列表。

当然，我们能把他们结合起来，

就好像这里的“All”类型的搜索结果一样。

如果我们利用所有这三种类型的列表，我们能够获得最好的结果。

我们做了一些实验来测量

列表加权防范，你们知道，

我们在列表加权中使用了两个因素，一个与IDF相关，另一个

与文档排名相关。因此，我们可以单独使用

这两个因素，也可以同时使用它们。因此，我们

在评价中可以使用三种方法。最终，我们发现

这三种方法，你们知道，

在聚集质量方面的表现相当。

但是，如果考虑排名的话，我们可以看到，

同时使用两个因素

要比只使用一个因素要好。

我们可以得出结论，我们的两个假设都得到了支持。你们还记得

这两个假设么？第一个假设是，如你们所知，

一个查询请求的一些重要方面

会排名靠前的搜索结果或者页面中

有表示。第二个假设是，

如你们所知，一个有意义的列表会在排名靠前的

搜索结果中多次出现。这就是这个研究中的两项工作。

未来，我们想要检测或者挖掘

维度的类型。你们知道，

一些维度的描述是自动生成的。例如，

品牌是排在最前面的类别。

这个维度是一些相关的条目，例如。

最后，我想向你们展示

更多我们的查询请求维度的例子。

例如，对于查询请求“西雅图雷蒙德的中国餐馆”，

我们首先可以获得这个

包括很多著名餐馆

西雅图雷蒙德地区的中国餐馆的维度。

我们可以为“迷失或者迷失第五季”挖掘不同的维度。对于“迷失”，

第一个维度包括很多不同的季。

对于“迷失第五季”，第一个维度包括

不同集的名字。

最后，我想

向你们展示“信息检索”的维度。第一个维度

是有关信息检索的不同会议，

第三个维度包括这个领域中的著名研究人员，

第四个维度

是不同的

信息检索模型。第五个维度包括

不同的信息检索措施。

感谢大家的关注！如果有任何问题，请告诉我。