标题：文件搜索引擎模型和检索精度提高的研究

北京大学 网络实验室硕士学位论文

北京大学硕士研究生学位论文

题目：一个借助查询历史改善结果排序的文件检索

系统的设计与实现

姓 名：谢 欣

学 号：10208105

院 系：信息科学技术学院

专 业：计算机系统结构

研究方向：计算机网络与分布式系统

导 师：李晓明 教授

2005 年 5 月

版权声明

任何收存和保管本论文各种版本的单位和个人，未经本论文作者同意，不得将本论文转借他人，亦不得随意复制、抄录、拍照或以任何方式传播。否则，引起有碍作者著作权之问题，将可能承担法律责任。

摘 要

随着网络的发展，网络上提供文件共享服务的服务器越来越多，共享的文件数量也随之增加。如何更好的检索、利用这些共享文件成为一个重要的问题。

针对用户对文件检索的需求，本文在文件检索技术领域有如下贡献。

1. 本文首先提出了一个文件检索的模型，明确了在文件检索模型中检索对象、查询串、查询与检索对象的匹配方式三部分的含义。检索对象，即文件条目表示为六元组[name, ext, size, date, site, path]的形式，查询串表示为以空格分隔的字符串的集合，查询与检索对象的匹配则表示为查询串与文件条目的匹配串之间的匹配。

2. 提出了对文件检索系统进行评测的指标。将查询结果视作集合时以查全率、查准率为评测指标。将查询结果视作有序序列时，分析了查询结果的相关性、连接下载速度以及结果的可用性等因素对排序的影响，并提出了对排序进行评测的指标——排序指数。作者还提出对于两个排序策略进行比较时，应当在结果的每个页面内部应用排序策略，而不是在全体结果集合上应用排序策略，并比较平均用户选取条目的页内排名。

3. 通过统计、分析用户对文件搜索引擎的检索和对检索结果中下载地址条目的选取，作者发现了用户行为习惯中的两个重要规律：一、少数查询串占据了全部查询请求的大多数，具体而言，前20%的热门查询串占据了全部查询请求的80%；二、对全体用户而言，假设有n次不同的查询请求使用了同一个查询串，并且它们代表k类不同的查询意图。那么通常k≤3，因而在n较大的情况下，则n/k的值较大，即大量的来自不同用户的请求代表了相同的查询意图。

4. 基于上文所述，作者设计并实现了一个真实的系统。该系统借助查询历史改善结果的排序。与一般基于用户历史信息的检索系统不同的是，本系统借助的历史信息不局限于当前用户的历史信息，还包含提交了相同查询串的其他用户的查询信息。或者说，即使当前用户是第一次使用本系统，本系统也能利用其他用户的历史记录来改进结果的排序和筛选。作者最后还验证了其实际的效果。应用本方法后，平均用户选取条目的页内排名从原来的13.70名前进到了8.93名。试验结果表明文中所做的分析是正确的。

关键词：文件检索系统，查询历史，检索模型

The Design and Implementation of a File Index System which Improve the Order by Query History

XIE Xin (Computer Artecture)

Directed by LI Xiaoming

Abstract

With the rapid expansion of the Internet, there are more sharing file servers. And the number of sharing files is increasing rapidly too. So it’s more important to retrieve these files easily.

For the requirement of file retrieving of the users, we did the following jobs:

1. We proposed a file index model. The model is composed of the expression of an index object, the expression of a query, and how the query word matches the index object. The index object can be expressed as [name, ext, size, date, site, path], the query string is expressed as strings separated by space, and the matching between query and index object is realized by matching the query string and the matching strings of the file item.

2. We also proposed the evaluation indicator for the file index evaluation. The precision and recall are useful when we evaluate the query result. But the result is not a set, but an ordered list. So we indicated the factors in order: the relativity of the item, the connecting and download speed and the availability of the site. We proposed how to evaluate the order: average rank of chosen items. If we just want to compare two ranking strategy, we should not reorder all items in the result set but only reorder the items within each page and compare the average rank of chosen items within page.

3. By analyzing the records of user’s queries and the file items that users chosen from a real file search engine, we discovered two lows. 1). Most query strings are repeating hot query strings. 80% query words are the top 20% hot query strings. 2) If there are n times of queries using the same query strings, and the total number of different intensions is k. Then k should be a very small number (usually, k<4), and n/k is a large value if n is large enough. It means, lots of queries using same query string are with the same intension.

4. Based on the above work, we designed and realized a system, which is based on users’ queries history and improves the rankinge of the items. This system is not only based on the history of the current user, but also other users who submitted the same query words. That means the system can improve the ranking for a usere, even hee/she is new to it. With the new system, the average chosen item within a page is improved from 13.70 to 8.93. Ite verified our research.

Keywords: file search engine, query history, index model

目 录

1第1章引言

11.1研究背景

11.1.1文件检索系统的发展历史

21.1.2文件检索系统的发展现状

31.1.3目前遇到的问题

41.2本文的研究内容

41.3本文贡献

51.4本文组织

6第2章文件检索系统及相关研究

62.1文件检索系统的基本使用方法

72.2常规文件检索系统体系结构

72.3文件搜索引擎与网页搜索引擎的比较

82.4文件搜索引擎对查询结果的排序和过滤

82.4.1排序

82.4.2过滤

92.5基于用户反馈信号的文件检索系统

10第3章文件检索模型

103.1检索对象的表示

103.1.1文件服务器返回的原始信息

113.1.2文件属性的演化

123.1.3文件的最终表示

133.2查询的表示方式

133.3查询与文件的匹配过程

133.4文件检索性能的评测指标

143.5排序准确程度的评测指标

143.5.1影响排序的因素

153.5.2对排序进行评测的方法

183.5.3排序指数

193.6比较排序策略的一个简便方法

20第4章用户行为特点分析

204.1查询串的特点

224.2用户查询意图的特点

254.3用户行为特点的启发

27第5章系统体系结构与主要算法

275.1系统体系结构

285.2主要算法

285.2.1用户点击日志的表示

295.2.2计算文件条目之间的距离

345.2.3对用户点击记录进行聚类

365.2.4对查询结果集合进行分类

37第6章系统实现与评测

376.1系统设计体系结构图

376.1.1用户行为收集部分

386.1.2聚类部分

386.1.3索引部分

386.2其它实现中的问题

386.2.1记录用户对查询结果的选取

396.2.2文件类型属性距离计算方法的实现

416.3系统的评测环境

416.4评测结果

43第7章总结与展望

437.1总结

437.2展望

437.2.1目录

437.2.2压缩文件类型

45参考资料

47附录：文件类型列表

50作者就读期间参加的科研项目和发表的论文

51致谢

图目录

6图 2‑1 文件检索系统使用示例

7图 2‑2 常规文件搜索引擎体系结构图

9图 2‑3 基于反馈信号系统的标准模型

10图 3‑1 Serv-U FTP服务器接收LIST命令后返回的信息

14图 3‑2 文件检索性能评测示意图

16图 3‑3 理想检索系统排序方式

17图 3‑4 系统排序比较

21图 4‑1 用户查询串集中程度分析

22图 4‑2用户查询串分布的函数拟和

25图 4‑3查询串与查询意图种类比值分析

27图 5‑1 系统结构图

32图 5‑2 文件扩展名属性距离计算

35图 5‑3聚类示意图

37图 6‑1体系结构图

40图 6‑2 ext属性距离计算方法的实现

42图 6‑3系统试验效果比较

表格目录

2表格 1‑1主要文件检索系统量化比较

3表格 1‑2主要文件检索系统查询结果数量示例

8表格 2‑1网页搜索引擎和文件搜索引擎比较

12表格 3‑1文件各属性信息说明

12表格 3‑2文件条目的最终表示形式

17表格 3‑3系统排序比较

23表格 4‑1用户查询意图抽样统计

23表格 4‑2查询串查询次数与用户查询意图种类比值

24表格 4‑3 查询意图统计分析

30表格 5‑1 文件条目各个属性数据类型

第1章 引言

1.1 研究背景

1.1.1 文件检索系统的发展历史

万维网（World Wide Web，简记为Web）是因特网上最成功的应用，起源于1989年欧洲粒子物理研究室CERN。Web的最初计划是由CERN的物理学家Tim Berners-Lee于1989年3月提出的，第一个基于文本的原型于18个月后运行。

除web外，网络上还存在着其它形式的服务，如FTP服务器提供的文件共享服务等。本文的研究对象就是文件共享服务。在FTP服务器出现多年后，又出现了P2P文件共享系统，比如Kazaa，天网maze等，他们同样提供了对文件的下载服务。

基于web的网页数量大量增加，推动了以网页为检索对象的搜索引擎的出现。而类似的，FTP和其他文件共享系统中共享文件数量的增加，也促使文件检索系统、尤其是文件搜索引擎的出现和发展。

最早的文件搜索引擎是基于文本显示的Archie。Archie实际上是一个大型的数据库，再加上与这个大型数据库相关联的一套检索方法。该数据库中包括大量可通过FTP下载的文件资源的有关信息，包括这些资源的文件名、文件长度、存放该文件的计算机名及目录名等。可以通过远程登录到Archie主机来使用Archie服务器，用Archie作为登录名。一旦登录成功，一个Archie程序将自动执行，这时每次输入一条命令，告诉Archie想查寻的内容，Archie将检索自己的数据库并显示检索的结果。如果用户对自己想要的东西并不太清楚，Archie还提供“whatis”服务项目，该服务提供成千上万个程序文件、数据文件和文档的简短说明。

WWW的出现改变了Archie在文件搜索方面的统治地位，在美观、方便的WWW页面上搜索FTP文件成为用户的自然需求，即人们需要有一种基于Web的FTP搜索引擎。在功能上，基于Web的FTP搜索引擎与Archie基本一样，都是对用户提交的查询串进行匹配找到可以下载的FTP站点文件的链接。

1.1.2 文件检索系统的发展现状

目前应用较为广泛的文件检索系统以表现形式分类主要有基于web的文件搜索引擎和内嵌于共享软件的文件检索系统两种形式。一般FTP搜索引擎以web形式居多，P2P软件则以软件内嵌的形式居多。

Web形式的著名的文件搜索引擎有：

· 天网千帆文件搜索引擎（http://www.mytianwang.cn）

· 星空文件检索系统（http://sheenk.com/ftpsearch/search.html）

· Philes (http://www.philes.com)

· Alltheweb (http://www.alltheweb.com)

P2P文件共享系统有

· 天网maze (http://maze.pku.edu.cn)，

· kazaa(http://www.kazaa.com)

下面我们对一些著名的文件检索系统作一以简单比较：

表格 1‑1主要文件检索系统量化比较

搜索引擎名称

文件条目总数（条）

站点数量（个）

天网FTP搜索引擎

13,000,000

46065

www.philes.com

209,698,206

没有统计

www.alltheweb.com

没有统计

没有统计

www.filesearching.com

76,039,149

没有统计

www.souborak.com

18,216,064

2388

ftpsearch.laplink.com

37,813,040

2,683

星空搜索

没有统计

没有统计

天网maze文件共享系统

160,000,000

100,000

从使用方式上讲，不论哪种形式的检索系统，基本上都是相同的。一般是用户在查询框中输入查询词，搜索引擎返回包含该查询词的文件条目信息。文件条目信息通常包括文件名称、大小、时间、下载地址等。

从工作原理上讲，现在主流的文件搜索引擎采用了和web搜索引擎类似的系统：首先启动多个网络爬虫，对待检索的文件服务器进行抓取，得到全部文件的描述信息（如文件或目录的名称，时间、大小、路径等）。然后对全部ftp文件建立索引（通常是倒排表索引），索引建立完成后则可以启动服务。当用户提交查询给检索系统时，系统返回包含该查询词的所有文件条目。

1.1.3 目前遇到的问题

从搜索引擎系统本身的结构上讲，文件搜索引擎和基于web的网页搜索引擎的结构非常相似。但从研究和搜索精度的角度来讲，文件搜索引擎和网页搜索引擎的差距是非常明显的。抛开商业、应用等因素，只从理论和技术等方面分析其原因，能够发现web上的网页和文件系统（此处以FTP为例）中的文件所能提供的信息量的差别是很大的。

Web上的网页既可以看成是一个文本文档，又有着丰富的格式描述信息，还有彼此的链接关系。而文本检索本身已经比较成熟，此领域又有深入的研究。网页之间的链接关系又使图论在此能够得到深入的应用。

相对于web上的网页，文件共享服务器能提供的文件信息则少的多。全部信息只是名称、大小、时间、路径等；而且各个站点彼此又是完全独立的，没有任何联系。文件名本身的命名又带有很多的个人习惯，没有太多的规律可循。所有这些特点使得一般的文档检索方法以及常规搜索引擎的处理办法在对文件的处理上都不再适用，因此文件搜索引擎检索的效果普遍不高。

而与之相对应的是，目前文件共享服务的数量和规模都在大幅度的增加，用户的需求也在不断的膨胀。作者曾于2005年4月对在中国教育科研网上公布的全部免费IP地址进行过一次全网的FTP服务扫描，共发现了370,222个开放的FTP服务器。在当时天网千帆文件搜索引擎的文件索引量也已经达到了2700万。可见目前对文件共享服务的应用和需求都是非常广泛的。

目前在这些常用文件搜索引擎中进行检索时，往往得到了大量的检索结果。比如下表显示了在上面提到的几个主要文件服务器中检索常用软件“winzip”和操作系统“linux”时返回的结果数量。

表格 1‑2主要文件检索系统查询结果数量示例

搜索引擎名称

查询winzip的返回结果数量

查询linux时的返回结果数量

天网FTP搜索引擎

1943

32,479

www.philes.com

2249

超过24,000

www.alltheweb.com

1700

68,000

www.filesearching.com

超过2000

超过2,000

www.souborak.com

超过1000

超过1,000

ftpsearch.laplink.com

3200

超过20,000

星空搜索

2274

60,027

天网maze文件共享系统

594

5202

从表中可见，返回的结果数量都相当之大，而到目前为止，文件检索尚没有一个行之有效的排序方式（比如pagerank之于web搜索引擎），只是单纯的返回在文件名称中包含用户的查询词的条目，因此搜索结果中有大量并不是用户所需要的结果。而用户面对如此大量的查询结果，从中选取真正准确的文件条目也是非常繁琐的事情。

所以说，对常规的文件检索系统进行改进，提高其检索准确度是目前文件搜索引擎发展的当务之急。

1.2 本文的研究内容

本文中的研究主要围绕以下几个方面开展：

首先对文件检索系统本身进行研究，建立文件检索模型，并提出评测方法；在对真实文件检索系统进行数据记录的基础上，分析用户对文件搜索引擎的使用行为的习惯和特征，挖掘其中的规律；最后根据发现的用户行为的规律，尝试提出新的文件检索系统，来提高检索的精度。

1.3 本文贡献

本文在文件检索技术领域有如下贡献。

本文首先提出了一个文件检索的模型，明确了在文件检索模型中检索对象、查询串、查询与检索对象的匹配方式三部分的含义。检索对象，即文件条目表示为六元组[name, ext, size, date, site, path]的形式，查询串表示为以空格分隔的字符串的集合，查询与检索对象的匹配则可以表示为查询串与文件条目的匹配串之间的匹配。

提出了对文件检索系统进行评测的指标。将查询结果视作集合时以查全率、查准率为评测指标。将查询结果视作有序序列时，指出了查询结果的相关性、连接下载速度以及结果的可用性等影响排序的因素，并提出了对排序进行评测的指标——排序指数。作者还提出对于两个排序策略进行比较时，应当在结果的每个页面内部应用排序策略，而不是全体结果集合应用排序策略，并比较平均用户选取条目的页内排名。

通过统计、分析用户对文件搜索引擎的检索和对检索结果中下载地址条目的选取，作者发现了用户行为习惯中的两个重要规律：一、少数查询串占据了全部查询请求的大多数，具体而言，前20%的热门查询串占据了全部查询请求的80%；二、对全体用户而言，假设有n次不同的查询请求了同一个查询串，并且它们代表k类不同的查询意图。那么通常k≤3，因而在n较大的情况下，则n/k的值较大，即大量的来自不同用户的请求代表了相同的查询意图。

基于上文所述，作者设计并实现了一个真实的系统。该系统借助查询历史改善结果的排序。与一般基于用户历史信息的检索系统不同的是，本系统借助的历史信息不局限于当前用户的历史信息，还包含提交了相同查询串的其他用户的查询信息。或者说，即使当前用户是第一次使用本系统，本系统也能利用其他用户的历史记录来改进结果的排序和筛选。作者最后还验证了其实际的效果。应用本方法后，平均用户选取条目的页内排名从原来的13.70名前进到了8.93名。试验结果表明文中所做的分析是正确的。

本文的创新之处主要在于以下几点：

提出了一个对排序算法进行实际评测的指标——排序指数。并提出了比较两个排序策略的方法：在得到相同的结果集合后，应用排序算法时，应该在每页内部应用各自的排序算法，而不是在全体结果集合中应用排序算法，并比较各自的平均用户选取条目页内排名。并列举了一个反例说明了在全体结果集合中应用排序算法可能出现的评测错误。

发现了用户对文件检索系统使用的两个规律：少数查询串占据了全部查询请求的大多数；大量的来自不同用户的请求代表了相同的查询意图。

设计并实现了一个基于用户历史信息的文件检索系统，该系统有别于同类系统的最大特点在于：该系统对查询历史的使用不局限于当前用户的历史，而是能够借用其它用户的查询历史。这样，即使面对一个全新的用户，我们同样能够借助以前其它用户的查询历史来改进排序。

1.4 本文组织

本文首先介绍了文件检索领域的相关背景和现状信息；第2章首先考察了文件检索系统基本情况以及相关的研究工作；第3章建立了一个文件检索系统的模型；第4章分析了用户行为特征并发现了两个重要规律；第5章提出了一个系统。该系统借助查询历史改善结果的排序；第6章讨论了系统实现和实现中的主要问题，并对系统进行了评测，证明了该模型和方法的正确性；在最后一章作者做了工作总结和展望。

第2章 文件检索系统及相关研究

2.1 文件检索系统的基本使用方法

我们这里以天网千帆文件搜索引擎为例，看一下文件检索系统的基本使用方法。假设用户希望下载即时通讯软件“QQ”，于是输入该查询串，得到的结果如下图所示：

图 2‑1 文件检索系统使用示例

检索系统根据用户输入的查询串，返回所有包含该查询词的文件条目。由于满足条件的文件条目可能非常多，因此会被分为多个页面。用户再从返回的结果中进行选取，点击自己认为准确、快捷的下载地址进行下载。

2.2 常规文件检索系统体系结构

此处我们以常见的FTP搜索引擎的体系结构来表示文件检索系统的基本结构。它和一般的基于web的搜索引擎的结构类似。下图是其基本的体系结构。

Site List

DataBase

File Item DataBase

Index DataBase

Query

Crawler

Indexer

Query Server

图 2‑2 常规文件搜索引擎体系结构图

图中各个部分的介绍如下：

Site list Database：站点列表数据库。其中存放着可能提供文件共享服务（如FTP服务）的各个站点的列表；

Crawler：进行网络抓取的程序，抓取文件共享系统中的文件信息；

File item Database：存放全部的文件条目的数据库；

Indexer：索引建立程序。根据用户的文件条目建立索引；

Index Database：索引库，通常为倒排表结构；

Query Server：提供查询服务的程序；

Query：用户的查询串。

整体工作流程如下：首先Crawler从Site list Database中逐一取出站点，然后对每个站点进行文件信息的抓取。抓取的结果存入File item Database中。当File item Database中有足够多的文件条目信息后，对其建立索引（倒排表）。然后启动Query Server，待用户提交查询串query后，在Index Database中对其进行检索，并返回查询结果。

2.3 文件搜索引擎与网页搜索引擎的比较

和文件搜索引擎关系最为密切的要属网页搜索引擎了，但二者在研究、应用等方面的差异较大，我们在此做一比较：

表格 2‑1网页搜索引擎和文件搜索引擎比较

比较内容

网页检索

文件检索

相关研究

非常深入

很少

提供的信息

丰富：文本、链接、tag等

很少：名称、大小、时间、路径

常见处理方法

文本分析；超链分析；tag分析

单纯字符串匹配

搜索的查准率

比较高

低；冗余信息很多

从上面的比较看出，网页检索和文件检索的差异还是非常大的。和网页检索相比，文件检索不论在相关研究还是本身能够提供的信息方面，都和网页检索相差较远。

2.4 文件搜索引擎对查询结果的排序和过滤

目前的文件搜索引擎对于查询结果的处理普遍比较简单。最常见的方法是不作任何处理，直接进行输出。其它处理方式有：

2.4.1 排序

文件搜索引擎对于结果的排序方式非常简单，目前能够见到的有如下四种排序方式：按文件大小排序、按文件修改时间排序、按文件名称长短排序、以及按照站点IP地址与查询者IP地址之差（将IP地址直接转化为整数数值进行计算）的绝对值排序。

这些排序方式都是按照文件的某种单一属性进行的排序。其排序效果并不是很理想。

2.4.2 过滤

某些文件搜索引擎提供了按照文件类型进行过滤的方式进行处理，它可以限制搜索结果只显示指定类型的文件扩展名的结果，而忽略那些尽管包含用户的查询串、但并不是所指定的文件类型的文件。

从查询效果上来讲，这些排序、处理方式都过于简单了，效果也并不理想。

2.5 基于用户反馈信号的文件检索系统

一般的，基于用户反馈信号的系统结构如下图所示：

图 2‑3 基于反馈信号系统的标准模型

System

Feed back Data

对应于我们的检索系统，可以进行如下的理解。系统首先进行初始的检索，得到初始查询结果S0并输出给用户。用户对输出结果进行判断，并将判断结果通知系统，系统根据用户的反馈和初始结果S0进行再运算，得到新的结果S1……如此k次迭代，结果将会达到用户满意的程度。

在网页搜索引擎中，确实有基于反馈信号的系统存在：用户提交查询串，在检索系统返回初始的结果后，用户再对部分结果进行相关性评分，并将评分结果反馈给系统，系统根据反馈信息和原始结果重新生成新的结果后，再次输出给用户。如此反复几次后，最终得到的结果将是对此用户而言，相关度非常高的结果。

但是在实际应用中，尤其是在搜索引擎系统中，用户常常倾向于较简单的操作，多数用户都不愿进行过于繁琐的打分等反馈操作，因此真正的多次迭代很难发生。用户需要的是一种更为简单的方式，并且尽可能将迭代次数k减到最小。

在极限情况下，假设用户只需要进行k=0次迭代就可以得到满意的结果。那么这就意味着我们必须能够“预测”用户的真实意图。而本文所研究的重点，就是如何构造这样一个能够预测用户意图的基于反馈的文件检索系统。

第3章 文件检索模型

建立一个文件检索模型是进行各种后续研究的基础。

我们知道，一个检索模型主要包括三个方面：检索对象的表示、查询的表示、以及查询与检索对象的匹配过程。下面我们分别来看这三个方面。

3.1 检索对象的表示

文件检索系统的检索对象是文件，为了确定其表示形式我们首先考察一下文件共享服务器能够给用户提供的全部信息。

3.1.1 文件服务器返回的原始信息

对于文件共享系统来讲，其表现形式是多种多样的。但究其内容却大同小异，最早的文件共享服务器是FTP服务器，各种后来出现的文件共享系统基本上都参考了FTP的模式，因此此处我们以FTP为例来对文件的表示形式进行剖析。

当我们登陆FTP后，发送列文件目录命令LIST，返回的结果大致如以下形式：

图 3‑1 Serv-U FTP服务器接收LIST命令后返回的信息

返回结果从左至右共有9列，其中有3列共同构成时间，所以共有7类信息，它们分别是：文件权限位，文件链接数，所有者名称，所有者所在组的名称，文件大小，最后修改时间（占3列）和文件名称。除去显示的这些信息之外，其实还有两项隐含信息，在返回的结果中没有显示，就是当前的站点名称和当前的路径地址信息。

以上列出的是应用非常广泛的FTP服务器Serv-U输出的信息。不同的文件共享服务器输出的信息可能不尽相同，比如很多P2P软件并不包含前四项信息（文件属性、链接数、文件所有者和所有者所在组）。一方面考虑到这四项信息的实际检索意义不大，另一方面为了保证模型的统一性和有效性，我们仅仅考虑通用的文件属性。

通用的属性有文件名称、最后修改时间、文件大小，另外再加上文件所在的路径。因此对于文件条目，我们将其表示为如下形式（为了便于在后文写入公式中，我们此处用英文表示）：

item = [name, time, size, path]

对于FTP来说，很多时候我们只能够得到文件的最后修改日期，而得不到具体时间（指时分秒信息），所以我们将最后修改时间改为最后修改日期，因此得到：

item = [name, date, size, path]

3.1.2 文件属性的演化

上面的表现形式只是文件的原始属性，为了便于检索等操作，我们需要对其进行适当的演化。

首先，文件名称通常可以分为文件主名和扩展名两部分。文件主名一般表示文件所代表的具体内容信息，其信息接收者通常是人；而扩展名则往往表明文件的存储格式和类别，其信息接收者往往是计算机，用于确定该文件的打开（读取）方式。由于这二者的含义是不同的，并不适合放在一起进行处理。因此我们将这二者拆开分别进行处理。文件主名表示为main name，扩展名为ext。在下文中，为了简略，在后面的文章中，为我们仍然使用name来代替main name，来表示文件主名。

再者，文件（或目录）所在路径包含站点名称和文件路径两个部分。站点名称可以看作以点号“.”分割的字符串，而路径则是以斜线（“/”）分割的字符串。由于二者的表现形式不同，其代表的含义也有所不同，我们在这里也对其采取分开表示的方式进行处理。并分别称为site和path。

最终，我们得到在文件共享系统中，每个文件对象（item）的全部属性如下：

item = [name, ext, size, date, site, path]

具体含义为：

表格 3‑1文件各属性信息说明

属性

中文说明

注释

name

文件主名

不包含扩展名

ext

文件的扩展名

文件可能会没有扩展名

size

文件的大小

date

文件的最后修改日期

site

站点名称

域名或IP地址

path

路径

不含站点名称部分

下面我们再来看各个属性项的数据类型：

name, ext的数据类型都是字符串形式；size则为整数形式；date虽然默认情况下是一个字符串，但其实表示为一个整数更加利于处理，在具体转换方法上可以表示为对某个固定日期的天数之差；site和path则分别为字符串。

除去上文所述，还有两点要特殊说明一下：

在实际的FTP服务器中，除了文件之外，还有目录，并且目录也是一种特殊形式的文件。但在很多P2P文件共享系统中，并不包含目录信息，所以在此我们并没有对目录进行考虑。

对于文件的扩展名，要注意的是并不是所有的文件都有扩展名，因此一个文件的扩展名是可能为空的。

3.1.3 文件的最终表示

经过以上分析，一个文件条目最终可以表示为一个6元组的形式：

item = [name, ext, size, date, site, path]

具体说明如下表：

表格 3‑2文件条目的最终表示形式

属性

数据类型

能否为空

说明

name

string

N

文件主名（注：不包含扩展名）

ext

string

Y

文件的扩展名

size

number

N

文件的大小

date

number

N

文件的最后修改日期

site

string

N

站点名称（域名或IP地址）

path

string

N

路径（不含站点名称部分）

而一个文件共享服务器就可以看作是多个这样的文件条目的集合。整个网络中的共享文件服务器则可以看成是一个更大的集合。

3.2 查询的表示方式

对文件检索系统的查询是以查询串的形式出现的。其表现形式为：用户输入一个查询串，提交给系统，系统在所有文件条目中对其进行匹配。该查询串可能为一个字符串或以空格分隔的多个字符串，如果是多个字符串，表示需要包含其中的每个字符串。

我们称用户提交的查询为“查询串”query，其数据类型为字符串。如果查询串中包含空格，表示需要系统进行匹配查询串中的全部子字符串。

3.3 查询与文件的匹配过程

当用户提交了查询串后，系统根据查询串进行匹配、检索。在实际进行字符串匹配的时候，如果单纯只是进行文件名（name和ext部分）的匹配有时是不够的，效果不够理想，因此我们有必要重新构造一个专门用于匹配的字符串。我们称其为“匹配串”。匹配串用于和查询串进行匹配。

在简单实现时，匹配串可以用包含扩展名的文件名来替代；但为了得到更好的效果，我们会做一些改变，比如对某些类型的文件采用包含路径（或路径的一部分，如上层目录）、文件名、扩展名的字符串作为匹配串等方式等。

查询与文档进行匹配时，将查询串中的全部子字符串与匹配串进行匹配。匹配成功的那些文件条目作为待返回的结果集合。最后将待返回的结果集合中的文件条目按照某种顺序进行排序，并返回给用户。

要注意的是，最后返回的结果不是文件条目的集合，而是文件条目的有序序列。

3.4 文件检索性能的评测指标

参考一般的文本检索系统，最常用的评测指标有查全率和查准率。

假设有查询请求I，对文件条目集合进行检索，其中相关的文档集合为R，我们设|R|为集合中元素的个数。对于一个检索策略，我们得到的结果为集合A，类似的，用|A|表示集合A中元素的个数。同时，我们用|Ra|表示R和A的交集的个数，图示如下：

Relevant Docs

R

Answer Set

A

Ra

图 3‑2 文件检索性能评测示意图

查准率

查准率用于表示得到结果集合中相关条目的比例。

A

Ra

ecision

=

Pr

查全率

查全率表示了全部相关文档被返回的比例。

R

Ra

call

=

Re

3.5 排序准确程度的评测指标

上面两个是最常用的评测指标，不过在这两个评测指标中，是将查询结果视作集合的方式来进行处理的。但很多时候，由于查询结果过多，人们也很关心查询结果的最终排序。因此我们有必要将查询结果视作有序队列，而不是看作纯粹的集合。

3.5.1 影响排序的因素

查询结果的相关性

对于同一个查询串，不同的条目的相关性是不同的。比如在上一章的例子中，对于检索软件QQ的用户，一个文件名为qq2005.exe的文件很可能比一个名称为qqsvr-info.ini的文件更接近用户的真实需求，与用户的需求的相关性更高。

因此在排序时，则应当尽量将相关性高的文档尽可能排在靠前的位置。

连接下载速度

由于用户使用文件搜索引擎的最终目的是要下载文件，因此用户对于查询结果的地址的连接、下载速度也是至关重要的。很难想象一个只有几K的下载速度的地址对于一个需要下载几百兆文件的用户有什么作用。因此好的文件检索系统在对结果的排序上应该能够考虑不同地址的连接速度，将速度快的地址尽量排在结果的前面。

结果的可用性

与web中的HTTP服务器不同，文件服务器的可用性往往没有web服务器那么高，服务往往也不是那么稳定。很多文件服务器只是个人用户的机器，并不能提供7×24小时的服务。有的时候是因为机器没有开机、或者服务器没有启动，造成了该下载结果并不可用。因此还应该判断服务器当时的可用情况。假设全部查询结果的文件条目为A，数量为|A|，其中当前能够连接、下载的条目集合为Aa，那么结果的可用性为：

Aa

Available

A

=

3.5.2 对排序进行评测的方法

如上面所述，有很多因素会影响对查询结果条目的排序。而逐一对如上的各个指标进行独立的评测是非常繁琐的事情，下面我们尝试给出一个综合性指标。

3.5.2.1 前提假设

对于结果的显示方式，我们给出如下的几点前提假设。

1. 用户看到的输出结果是以有序序列的列表形式分页显示的。

对于用户的行为，为了方便起见，我们也作如下的假设

1. 每个用户对结果的查看是按照结果列表的页面由前向后顺次查看的；

2. 用户在自己已经查看的结果条目中会至多选择一个最适合的结果条目并点击下载。

我们知道在真实使用中，一个用户可能会点击多个结果，这里我们为了简单起见，认为每个用户只点击一次；如果发生多次点击，我们不妨将其实作多次独立的查询请求。

3.5.2.2 用户点击的结果条目位次的平均值

搜索引擎的查询结果通常以列表的形式分成多页返回给用户，结果页面中的每个条目被赋予一个顺序的编号。如果我们采用合适的技术（比如在web页面上使用Javascript技术）记录下用户在结果页面中的选取操作，我们就能够得到用户选取的结果的编号。经过一段时间后，我们就得到了大量的用户记录。这样，就能够计算平均选取条目排名。

1

*

m

i

i

iR

rank

n

=

=

å

公式中我们假设共有m个结果条目，Ri表示第i个条目被用户点击的次数，n为总查询的次数。在查询结果集合不变的情况下，这个指标看上去可以很好的刻画排序的准确性。但其实其中是存在着问题的，我们举一个反例说明如下。

假如有两个真实系统，它们唯一的区别在于排序策略不同。如果二者各自用自己的排序算法对全部结果条目进行了排序，并分页返回给用户。那么用上述的指标，能否准确反应出哪个系统的排序更优呢？

答案是否定的，我们通过下面的例子来说明。

假设对于一个查询一共只有4个查询结果，而每个页面只能显示2个结果，因此它们会被拆分成2个页面来进行显示。对于一个理想的检索系统，其排序方式应该如下图所示：

Page

1

100

%

90

%

Page

2

80

%

70

%

图 3‑3 理想检索系统排序方式

图中上下各位两个页面，每个页面中的两个颜色块同时表示了检索结果条目。颜色越深表示约接近用户的理想结果。颜色块上同时用文字示意了和最理想结果的接近程度分别为100%，90％，80％和70％。

对于这种标准的排序方式，不论用户是否翻页，用户都会选择第一个查询结果。这样，公式的计算结果为1。

再假设我们有这么两个检索系统，它们的检索结果集合是完全相同的，但它们的排序结果都不是最优的，系统I和系统II 的区别在于对第2个结果和第3个结果的排序是相反的。具体排序方式如下图所示：

Page

1

100

%

90

%

Page

2

80

%

70

%

Page

1

90

%

Page

2

80

%

70

%

100

%

System I

System II

图 3‑4 系统排序比较

从图中我们很容易看出，系统I的排序方式要优于系统II。

但对实际用户来讲，因为只有很少的用户愿意进行翻页。因此我们假设全部用户数量为S，进行了翻页操作的用户数量为40%。那么我们可以得到如下的表格：

表格 3‑3系统排序比较

系统

每个条目的点击次数

平均用户选取条目排名

rank

条目1

条目2

条目3

条目4

I

0

S

0

0

2

II

60％S

0

40%S

0

1.8

表中两个系统的评测结果分别是：

rank1=2

rank2=(60%*1+40%*3)*S/S = 1.8

从表格中可以发现，系统II的平均用户选取条目排名（1.8）竟然优先于系统I（2）。似乎系统II的排名比系统I更好。但事实显然不应该是这样的。

为什么会发生这种事情呢？这里主要的原因是：

每个页面被用户查看到的概率

多数用户并不愿意翻页，那些在靠后的页面所得到的浏览次数远远小于前面的页面。因为每个结果页面被用户查看到的可能性是不同的，因此我们需要首先考察一下每个页面被用户查看到的概率。我们可以设第k页被用户翻到的概率是P(k)，因为我们假设用户是从前向后翻看结果的，那么函数P(k)是k的单调递减函数，并且P(1)=1。

3.5.3 排序指数

我们假设对于某个查询串q，共有n次查询请求，那么如果在第k页的某个条目获得了r次用户点击，它代表的是在查看第k页的全部用户中有比例为

()

r

nPk

的用户认同该结果，而不是

r

n

的用户认同。因为P(k)≤1，所以

()

r

nPk

≥

r

n

。上式直观的表述，可以认为靠后的页面中的结果条目获得的用户点击所代表的权重大于前面页面所获得的点击的权重。

这样，我们就可以修正上面的公式为如下形式，并称其为排序指数s。

1

1

*

()

()

m

i

i

m

k

j

iR

i

P

k

s

nPj

=

éù

êú

êú

=

éù

êú

êú

=

å

å

公式中k表示每页显示的结果条目数量。排序指数s越大，表示用户点击的平均条目越靠后，排序效果越不好；反之则排序越好。

现在我们用新公式重新计算上例，结果为：

1

1*02*3*04*0

110.40.4

1.429

(10.4)

n

rank

n

+++

==

+

2

1*0.6*2*03*0.4*4*0

110.40.4

2.571

*(10.4)

nn

rank

n

+++

==

+

可见，在新算法下，能够很好的解决如上的翻页问题了。

3.6 比较排序策略的一个简便方法

假如我们有两个不同的排序算法，我们希望比较两者的优劣，该怎么计算呢？当然，我们可以按照上面的公式来计算，但在实际应用中，一来这样比较繁琐，二来不是很容易得到函数P(k)的具体实现。

我们建议可以按照下面的方法简单而有效的对排序算法进行比较。

首先两个比较系统查询获得的结果集合要保持一致，然后排序算法不在全体集合中应用，而只是在每个页面内部应用，这样就避免了上文中翻页带来的问题。在进行评测的时候，对每个页面的点击记录视作单独的记录。并分别计算下面的页内平均用户点击排名。

1

*

k

i

i

iR

s

k

=

=

å

然后比较两个算法的页内平均用户点击排名，s较小的算法效果较优。

第4章 用户行为特点分析

为了尽可能利用用户的反馈信息，我们首先来分析一下用户的行为特点。

4.1 查询串的特点

我们以天网千帆文件搜索引擎为研究实例，取其2005年3月16至2005年3月22日这一周的查询日志，看看用户的查询有什么特点。

这一周内共计查询628758次，共有127677个不同的查询串。我们假设用户的查询串序列为S1={q1 ,q2 , … , qn}，其中这n 项查询串中共有m 个不同的查询串，按其查询次数进行降序排序得到序列S2={Q1 , Q2 , … , Qm}，而S3={C1 , C2 ,…, Cm}是与S2 对应的查询次数序列。我们使用公式1 来统计S2 中前某个百分比（如x%）的查询串所对应的查询次数占总查询次数的比率Y。

*/100

1

1

mx

i

i

m

i

i

c

Y

c

êú

ëû

=

=

=

å

å

计算结果如下图所示。可以看出，用户的查询串是非常集中的。例如，前20%的查询串的查询次数约占了总查询次数的80%。

00.10.20.30.40.50.60.70.80.91

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

图 4‑1 用户查询串集中程度分析

横坐标为上文计算公式中的x，即序列S2中从队首取的部分序列占总序列长度的比例纵坐标为计算公式中的y，即其所占总查询次数的比例

可见，少数查询串占据了全部查询请求的多数部分。我们对上图的曲线进行函数拟和，发现该拟和函数具有幂函数的特性，具体形式为：

1435

.

0

9952

.

0

x

y

=

拟和函数的曲线如下图，图中红色部分为拟和函数，可见拟和效果还是非常好的。

0.10.20.30.40.50.60.70.80.91

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

y vs. x

fit 3

图 4‑2用户查询串分布的函数拟和

这种幂函数具有这样一个特征，即在x 越接近0 的地方，y 值增长越快，在x接近1 的地方y 的变化趋于平缓。这表明了查询串的分布具有很强的局部性：绝大多数用户查询的关键词落在了相对很小的一个集合上。具体到我们的应用，我们对这个规律稍微改换说法，我们将其描述为：

规律一：大多数的查询串都是被反复查询的。

4.2 用户查询意图的特点

在使用文件检索系统的时候，每个用户都会提交查询串query给系统，每个查询串对应一个用户的查询意图intension，表示用户希望下载的某种文件。从规律一我们知道，文件检索系统会经常接收到很多相同的查询串，但它们可能来自于不同的用户。我们希望能够了解这些相同的查询串是否代表了相同的意图；如果不是的话，那么其中有没有什么规律可循。

假设有n次查询请求都提交了同样的查询串query，它们共代表了k种不同的查询意图。我们来考察k和n的关系。

对于每个查询，我们可以认为如果用户选择了相同的下载地址，那么这些查询表示的是相同的查询意图。但对于不同的查询地址，这就要分情况来看了，既有可能代表不同的查询意图，也有可能表示的是相同的查询意图。这是因为，对于文件搜索，用户对查询结果的选取受到诸多因素的影响。以查询软件为例，对于微小版本的差异，有的用户可能并不是很在意，因此可能会选择了不同的查询结果；另外，不同地区的用户对同一个站点能够达到的连接、下载速度并不相同，很多用户会选取离自己较近的下载地址。因此我们不能单纯的认为只有选择相同查询结果的用户才具有相同的查询意图，而应该说选取了相近查询结果的用户具有基本一致的查询意图。

为了了解k值的具体情况，我们在天网文件检索系统中通过程序记录了用户对于查询结果的选取情况。并选取了其在2005年3月1日至3月15日的结果进行统计。我们首先采用了人工的方法通过观察用户对查询结果的点击来对查询意图进行归类，得到如下表所示的结果。

表格 4‑1用户查询意图抽样统计

排名

查询串

意图种类k

意图说明

1

电影

3

下载视频影片下载电影剧情介绍下载电影歌曲

2

美女

3

下载美女图片

下载美女视频片断

下载关于美女的文本故事

5

friends

2

下载电视剧《friends》的视频

下载电视剧《friends》的音频录音

10

新概念英语

1

下载英语课程《新概念英语》的录音

20

评书

2

下载评书录音

下载评书讲本

50

java

2

下载Java相关的编程资料

下载JDK

100

极品飞车

3

下载游戏“极品飞车”安装文件

下载游戏“极品飞车”序列号

下载游戏“极品飞车”存档

从上面的抽样统计来看，可以发现：对于相同的查询串，所代表的意图虽然不一定是唯一的，但是意图的种类是很少的。我们再看一下这些查询串的查询次数与查询意图种类的比值：

表格 4‑2查询串查询次数与用户查询意图种类比值

查询词排名

1

2

5

10

20

50

100

n

2234

2122

1486

776

495

330

222

k

3

3

2

1

2

2

3

n/k

744.67

707.33

743.00

776.00

247.50

165.00

74.00

由上表可见，n/k的比值均比较大（大于70），因此我们猜测：

假设有n次检索请求检索了同一个查询串，并且它们代表k种不同的意图。在n较大的情况下，n/k为一个较大的数值。

如果这个规律成立，那么也就意味着大量的用户查询串代表的是相同的查询意图。

上面我们只是通过人工抽样的方法得到的一些感性认识，还不清楚是否是一个一般规律，因此我们还需要进行更大规模的数据考察。

我们选取了2005年3月18日至2005年5月15日的用户查询串和查询结果的用户选取记录，通过运行程序来做一个分析。程序采用聚类的方法（其聚类算法实现细节参见下节）进行分析。在去除了少量没有任何实际点击的查询请求后，程序共分析了272个不同的查询串。

首先查看这些查询串所代表的不同查询意图的种类，程序运行结果如下表所示。

表格 4‑3 查询意图统计分析

查询意图种类k

1

2

3

4

5

>5

对应的查询串的个数

33

157

81

0

1

0

从上表可见，查询意图只有1－3个的查询串占全部记录数据的绝大部分，超过5种不同意图的查询串在统计的日志中根本就没有出现。

我们再来看一下n和k的比例的分布，统计结果如下图。图中横坐标表示查询串被查询的次数n，综坐标为n/k的比值。要说明一点就是为了使图像中的点线显示清晰，我们忽略了很少量的查询次数非常高的词（这些点对应的横坐标值非常大），但事后的手工验证仍然证明了它们符合本文的规律。

1

10

100

1000

01002003004005006007008009001000

图 4‑3查询串与查询意图种类比值分析

其中横坐标为查询串查询次数n，综坐标为n/k比值（为指数标度）

从图中可以看到，当n>100时，n/k的值都在30以上。

由上面的分析我们能够知道，尽管查询串不同，但一般说来，它们所代表的查询意图的数量并不是太多的，通常在1-3种，并且在n较大的情况下（如n>100），通常n/k的比值较大（本例中大于30）。因此我们得到了第二个重要的规律：

规律二：假设有n次不同的请求查询了同一个查询串，并且它们代表k种不同的查询意图。在n较大的情况下（n>100），n/k的值较大（n/k>30）。

4.3 用户行为特点的启发

利用上面的用户行为特点中的两个规律，以及前面关于相关反馈方法的思路，可以考虑采用如下思路来实现一个借助查询历史信息改善结果排序的文件检索系统。

从上面的特征我们知道，大多数的查询请求不仅其查询串本身是重复的，而且其所代表的查询意图也是重复的。这样我们就可以由“较早的相同的查询串的结果选取记录”作为用户的反馈信号。这样一来，后来提交同样查询串的用户不需要任何主动干预，就可以得到经过反馈信号处理过的重新排序的查询结果了。当然，由于用户意图并不唯一，我们并不能确定究竟本次查询的用户是哪种查询意图，但因为k值通常都相当小（小于等于3），因此对用户而言，很容易从这为数极少的查询意图中找到满足自己意图的结果。

具体而言，我们可以考虑如下的思路。

首先记录下每次用户对查询结果的选取。我们认为，用户在查询结果中点击的下载地址，就是用户认为比较理想的下载地址。通过一段时间的记录，我们就得到了对于大量查询串的较理想的匹配结果。对于一个查询串q，我们有一个用户认为较好的文件条目的集合S，我们将其表示为一个二元组(q,S)。这样，我们就得到了大量的这样的二元组。

依据规律2，我们知道每个查询串可能代表几个不同的查询意图，那么不同的查询意图对应的理想下载地址肯定不同（否则就是相同的查询意图了），我们可以采用聚类的方法对每个S中的文件条目进行聚类。聚类后，对于每个q，我们会得到k种不同的类别，这k个类别就也就反映了不同的查询意图，而每个类别中的文件条目，就可以看作这个类别的训练集。每个类别中的条目个数，也直接反映了这个类别的权重。

当再次有用户查询同样的查询串q时，我们首先采用原始的检索方法，得到一个结果集合，然后用聚类得到的k个类别和训练集对其进行分类处理。一些条目被分到这k个类别中，另外一些可能不属于任何类别。不属于任何类别的条目往往也是用户不太需要的条目，可以考虑抛弃或排在结果的最后输出。

第5章 系统体系结构与主要算法

5.1 系统体系结构

基于以上分析，我们设计了如下的检索系统来改善文件检索系统的排序。

Query String

(

q

)

Normal Index

System

(

I

)

Index Result

(

S

0

)

Feedback data

DataBase

Site List DataBase

query

Clustering

The training

set for query

item q

Items not

belong to

any group

Result after

Categorizati

on

(

S

)

Categorization

,

Ordering

Fileitems that user

clicked

图 5‑1 系统结构图

下面我们来详细介绍这个模型。

我们首先查看模型中的各个组成部分。

Query String (q)：用户输入的查询串；

Normal Index System(I)：常规的文件检索系统；

Index Result(S0)：初始查询结果集；

Feedback Data DB(F)：该数据库中记录了已有的每个查询请求和它对应的不同的k种查询意图，以及每种意图的作为训练集的文件条目。

Fileitem DB(D)：该数据库中保存了每次用户进行检索后对查询结果的选取情况。具体而言，当用户进行查询后，检索系统返回结果，当用户在结果页面中对文件条目进行点击并下载时，本模型会记录用户的点击选取行为。库中的每条记录含有当前的查询串和用户点击的这条记录的具体文件信息：文件名称、扩展名称、最后修改日期、文件大小、文件所在站点和文件所在的路径。

本检索系统的工作流程如下：

数据库F中需要足够的数据记录系统才能够进行工作。因此在系统运行之初，系统便开始自动记录用户的点击，并将记录填充进数据库D。数据库D每隔一段时间，对每个查询串q进行一次聚类操作，这样便得到了每个查询串所代表的k种查询意图。

现在我们假设F中已经包含有了足够的记录信息。当用户输入查询串q后，一方面，模型中最上面的流程开始工作，常规的检索系统进行检索，得到一个原始的查询结果S0。另一方面，如模型图示中的中层的流程，q被送入数据库F。数据库F返回对应的k种意图和其点击记录集合。这些记录将作为下一步分类工作的训练集。

有了S0和这k种类别，下面将利用这k种类别的训练集对S0进行分类。分类后我们将S0分成了k+1类，其中新增加的这个类别是那些不属于任何类别的文件条目item集合。对于不属于任何类别的条目，我们认为它是用户不太关心的结果，可以把它抛弃或放入输出结果的最后。

这里有一点要注意，就是k种类别的地位是不同的，类别本身也是有权重的，权重可以由聚类时每个类别中的条目数量来决定。这样在最后输出时可以按照权重本身对类别进行排序。由于k的取值通常都比较小（小于等于3），用户最终看到的结果往往是接近用户的真实查询意图的。

然后就可以按照一般的条目列表方式或者聚类的树型结构将结果输出给最终用户。

5.2 主要算法

5.2.1 用户点击日志的表示

用户点击日志就是用户所点击的文件条目item。由前面的对文件检索的建模，我们知道可以表示为：

item = [name, ext, size, date, site, path]

我们将其改写为如下格式：

[

]

path

site

date

size

ext

name

x

x

x

x

x

x

有时候为了简便，我们也会表述为如下形式：

[

]

6

5

4

3

2

1

x

x

x

x

x

x

对于查询串q，价格共有n个记录，因此我们得到如下的矩阵：

1,11,21,31,41,51,6

,1,2,3,4,5,6

,1,2,3,4,5,6

..................

..................

iiiiii

nnnnnn

xxxxxx

xxxxxx

xxxxxx

éù

êú

êú

êú

êú

êú

êú

ëû

5.2.2 计算文件条目之间的距离

不论是进行聚类处理还是进行分类处理，都需要进行大量的对两个文件条目(item)之间的距离d的计算。或者说，需要通过上文中的二模矩阵，得到下面的表示条目之间距离的单模矩阵：

0

(2,1)0

(3,1)(3,2)0

(4,1)(4,2)(4,3)0

(5,1)(5,2)(5,3)(5,4)0

(6,1)(6,2)(6,3)(6,4)(6,5)0

(7,1)(7,2)(7,3)(7,4)(7,5)(7,6)0

.....................0

(,1)(,2)(,3)(,4)(,5)(,6)...(,

d

dd

ddd

dddd

ddddd

dddddd

dndndndndndndnn

-

1)0

éù

êú

êú

êú

êú

êú

êú

êú

êú

êú

êú

êú

êú

êú

ëû

图中我们用d(i,j)表示项xi和xj之间的距离，有d(i,j)≥0。

当d(i,j)=0时表示二者完全相同；

当d(i,j)>0时表示二者不同，并且d的值越大表示文件条目xi和xj之间的差异越大。

对于条目i和j之间距离的d(i,j)的计算，我们采用如下加权公式：

(,)

1

1

(,)

ifjf

p

xx

ff

p

f

d

f

dxx

ij

f

d

d

=

=

S

=

S

由前文文件检索模型可知，此处p=6。我们分别计算文件条目i和j的6项对应属性的距离，再进行加权求和最后再进行标准化处理。

由于文件条目的6项属性的数据类型和含义不完全相同，因此具体的计算方法区别较大，在计算时需要分别考虑。

下图为各个属性的数据类型和计算方法。

表格 5‑1 文件条目各个属性数据类型

属性

数据类型

距离计算方法

name

String

Minimal edit distance

ext

String

Nominal Variables

size

Integer

Interval-scaled variables

date

Integer

Interval-scaled variables

site

String

N/A

path

String

Subsection string

具体方法为：

5.2.2.1 name属性距离的计算方法

name表示文件的不包含扩展名的主名的名称，数据类型为字符串型。对于这种字符串类型数据的处理，一般情况下可以按照文档的相似度的方式进行。但由于文件名通常都比较短小，命名多数情况下也不规范。这里并不建议按照文档的形式来处理。

我们这里采用的处理方法是按照最小编辑距离的方法来处理。

编辑距离是指两个字符串通过插入字符、删除字符、改写字符而变为相同字符串所需要的操作次数。

比如：

d(“abc”,”abd”) = 1

d(“abc”,”ab”) = 1

d(“abc”, “abcdf”) = 2

d(“serverU”,” ser-u”) = 4

利用动态规划的方法计算编辑距离，时间复杂性可以达到O(n2)，空间复杂性为O（n2）。

计算方法为一个递归算法：

d('', '') = 0

d(s, '') = d('', s) = |s| （|s|表示s的长度）

d(s1+ch1, s2+ch2)

= min(

d(s1, s2) + （if ch1=ch2 then 0 else 1）,

d(s1+ch1, s2) + 1,

d(s1, s2+ch2) + 1

)

5.2.2.2 ext属性距离的计算方法

ext指文件的扩展名，虽然数据类型为字符串，但因此常见的文件类型是有限的，因此可以看成是枚举类型，在聚类算法中则称为标称变量。在进行距离计算时可以按照聚类算法中对于此类数据类型的标准处理方法进行处理，即其距离只是一个二值函数：取值相同则距离为0；否则距离为1。但考虑到文件扩展名是有实际含义的，而且很多时候这些不同的扩展名之间还有着丰富的联系，因此我们能够将其处理的更加精确。

一般的，我们可以按照文件的扩展名对文件类型进行分类。比如可以将文件分成：程序、图片、音乐、影视、源码等类别。在每个类别内部，可能又有更深的层次，比如源码可能又分为C/C++源码，JAVA源码等，而C/C++源码又可以进一步分为头文件和实现文件等……这样就形成了一棵树。不过要注意的是，这棵树不是平衡的，某些叶节点可能比较深，另外一些可能比较浅。

为了形成这棵树，我们还需要说明如下。

首先，我们假设每种扩展名只对应于树中的一个节点；

其次，我们设置一个根节点，根节点本身不包含如何任何文件类型；

再有，对于没有扩展名的文件，我们为其赋予一个特殊的值，并且直接位于根节点之下；对于不能识别的扩展名我们也做同样处理。

这样，最后形成了一棵类似下图的树：

root

program

video

music

picture

source

other

Real

format

.

avi

.

rm

.

rmvb

C

/

C

++

language

.

java

.

h

implemen

tation

.

c

.

cpp

图 5‑2 文件扩展名属性距离计算

这样，计算任意两个文件条目类型属性的距离演变成了计算树中任意两个叶节点之间的关系。对于树中任意两个叶节点的距离，则表示为其相似程度的倒数。而相似程度的计算，可以按照如下算法。树中每个节点均存在一条从根节点到达它所在位置的唯一路径P。两个节点的相似程度可以表示为它们各自路径P中公共节点的个数的函数。

在实现上，我们选取如下的函数：

假设需要计算两个ext值分别为e1和e2的点xi、xj在此属性上的距离。设e1对应的路径为p1，e2对应的路径为p2。p1和p2的公共节点个数为k（根节点除外），则我们取：

2,2,2

1

1

(,)

2

ij

k

dxx

+

=

5.2.2.3 size属性距离的计算方法

size属性表示文件条目的文件大小，以字节为单位，数据类型为整数。由于文件大小的取值范围跨度很大，一般能够从几十字节到几十亿字节，因此不适合按照一般区间标度变量的方法来计算，可以按照比例标度型变量来处理。首先对size的值取对数：

,3,3

log()

ii

yx

=

不过在实际应用中要注意的是，因为size的取值范围是非负整数，可能取0，因此不能直接取log，可以考虑首先将x＋1再取log。

,3,3

log(1)

ii

yx

=+

然后将yi3转化为对应的z-score值Zi3

,33

,3

3

i

i

ym

z

s

-

=

其中

.

...)

31,32,3,3

1

n

m (yyy

n

++

=+

31,332,3333

1

(||||...||)

n

symymym

n

=-+-++-

进行标准化处理之后，再求二者之差：

3,3,3,3,3

(,)

ijij

dxxzz

=-

5.2.2.4 date属性距离的计算方法

date属性表示文件的最后修改日期，前面已经说过，我们将原来的字符串格式统一转化为整数，比如按照距离公元元年元旦的日期数。对于整数，属于区间标度变量。为了更好的计算各个项目该属性之间的距离，我们并不直接计算各个条目的差，而是先对其进行标准化处理。将Xi4转化为对应的z-score值Zi4

,44

,4

4

i

i

xm

z

s

-

=

其中

.

...)

41,42,4,4

1

n

m (xxx

n

++

=+

41,442,44,44

1

(||||...||)

n

sxmxmxm

n

=-+-++-

进行标准化处理之后，再求二者之差：

444,4,4

(,)

ijij

dxxzz

=-

5.2.2.5 site属性距离的计算方法

由于在实际文件共享系统中，site值最常见的情况就是IP地址，而两个IP地址之间的距离的比较是没有实际意义的，因此我们忽略两个site属性的之间的距离，或者可以表示为：

5,5,5

(,)0

ij

dxx

=

5.2.2.6 path属性距离的计算方法

path表示文件从根目录开始到其节点所经过的路径。其重要特点就是路径是分段的，是由多个字符串连接而成的。比如路径：/Resource/Software/Tools/network/可以看成是由分段的子字符串Resource，Software，Tools和network构成的。

在对path进行比较的时候，我们将每个路径拆分成多个子字符串，然后比较其中公共子字符串的个数占全部子字符串的比例。

6,6,6

(,)

com

ij

ij

s

dxx

ss

=

+

公式中si和sj分别表示xi和xj的path属性的分段的个数，Scom为公共子字符串的个数。

5.2.3 对用户点击记录进行聚类

在本体系中需要对用户的点击日志进行聚类，以便能够得到这k个不同的用户查询意图。

聚类常用的方法有Partitioning 方法，Hierarchical 方法和Density-based方法。根据我们的具体情况，这里选用自底向上的Hierarchical方法。

对本方法的图示说明如下：

a

b

c

d

e

a

,

b

step

0

step

1

step

2

step

3

step

4

d

,

e

c

,

d

,

e

a

,

b

,

c

,

d

,

e

agglomerative

(

AGNES

)

图 5‑3聚类示意图

假设共有5个对象a,b,c,d,e，我们将其根据彼此的相关程度进行聚类。

首先，将每个待聚类的元素独立划分为一个自己的类别，如果有n个元素，则开始时共有n类。然后将距离最近的两个元素归为一类，此时有n-1类；此后再将距离次近的归为一类，类别共n-2类；如此不断重复……如果没有结束标志，则最终将会把所有类别都归为一类。所以必须要设置结束标志。

这其中有几点要说明：

5.2.3.1 结束标志的设定

结束标志可以从几个方面来综合考虑。首先是距离因素，设定当距离最近的两个类的距离大于某个类别间的距离阀值D时不再进行合并操作，设置距离标志D可以防止最后生成的类别过少。另外由规律2可知相同的查询串通常只表示很少的查询意图，因此可以设定一个最大类别数G，这个表示可以防止最后生成的类别数过多。通过这两个结束标志的综合运用，可以使最终的类别数量控制在较理想的范围中。

5.2.3.2 具有多个元素的类别之间距离的计算

当类别包含多个元素时，计算它们之间的距离有三种不同的方法：计算距离最近的两点之间的距离、最远的两点之间的距离、或者用中心点来计算距离。我们这里选用中心点来计算二者的距离。这个中心点可能是类别中真实存在的一个元素，但也可能是一个并不真正包含的虚拟的元素。

5.2.3.3 孤立点的处理

事实上，一些查询串可能会对应一两个或很少的孤立查询记录，这些查询记录和其余大量的查询记录的相似度很低。通过人工查看的方法，我们发现很多这些孤立查询记录其实都是看上去不太正常的记录，比如对于一些大小为0的文件进行下载，或者下载一些快捷方式文件等。我们认为这些孤立点是因为用户不小心或不了解所致。而这些文件条目实际上并不应该被下载，而应该被抛弃。因此我们需要对这些孤立点进行丢弃。

5.2.3.4 训练集的生成

由于在进行完聚类后我们会对查询再进行分类，因此我们考虑利用聚类中的文件条目作为分类时的训练集。在聚类完成后我们将保留每个查询串的每个类别足够的文件条目。

5.2.4 对查询结果集合进行分类

常用的分类算法有k nearest neighbor(kNN), Naïve Bayes, 还有support vector machines等。我们采用kNN算法。

其具体步骤为：

首先需要有一个训练集。对于每个可能的类别，各自有一些属于该类别的对象。给定一个待分类的对象，系统在训练集中查找与其最相似的k个对象(称为邻居)，并根据这些邻居所属的类别情况来给该对象的候选类别评分，最后按照分值来确定待分类对象的类别。

第6章 系统实现与评测

6.1 系统设计体系结构图

实际系统的体系结构图如下。考虑到一些实现问题，和上一章的系统模型略有区别。

Index Part

Clust

ering Part

Collection Part

ClickLog

D

ata

B

ase

Training Set

D

ata

B

ase

ClickLog

Server

Clustering

Query q

Normal

Index

System

Items

Categorization

Filter

Categories

Click log

Items

Training

s

et

Click log

图 6‑1体系结构图

下面我们来详细介绍此系统设计。

6.1.1 用户行为收集部分

Collection Part部分为用户点击记录收集部分，是实时运行的。

在用户进行查询后，文件检索系统返回包含查询串的结果。用户从中选取自己认为正确的文件条目。用户的选取操作就是一次鼠标的点击操作。这个点击动作自动触发到我们的后台CGI程序，程序先将用户的下载请求转向到真正的下载地址，后台再发送一个记录点击操作的服务请求。该服务请求由ClickLog Server接收，并记录到ClickLog Database中。我们称用户的每次点击对应的文件条目为ClickLog。经过这样反复多次后，ClickLog Database中记录了大量的ClickLog，每个ClickLog包含一个查询串和对应的文件条目item。

6.1.2 聚类部分

此部分为聚类操作部分，每隔一段时间运行一次。在实际系统中可以根据用户数量来设定为每小时或每天一次。

这部分首先从ClickLog Database中读取全部的ClickLog条目，然后对每个查询串依次进行处理。取出每个查询串对应的ClickLog记录，进行聚类，聚类后得到k个类别。如前文所述，其中可能存在一些孤立点，然后按照标准对这些孤立点进行考察，需要的话要抛弃掉其对应的孤立类别。

聚类操作完成后，将聚类的结果存入Training Set Database中。

至此，我们就得到了实现免用户干预的、基于反馈信息的检索系统所需要的反馈数据。

6.1.3 索引部分

完成了上面两个部分的工作，就可以进行真正的反馈了。对于用户的查询串q，首先使用常规检索系统进行检索，就可得到一个文件条目Item的集合。然后在Training Set Database中取出对应于查询串q的k个类别的训练集。利用这些训练集条目为刚刚通过常规查询得到的Item集合进行分类。此处我们限定每个文件条目至多属于1个类别。分类后可能得到k+1个类别（某些Item可能不属于任何类别），以及每个条目和其所属类别的相似程度。利用分类的类别和相似度，系统可以重新根据此信息进行输出。对于那些不属于任何类别的文件条目，通常也是用户所不太关心的结果，可以选择抛弃或排在结果页面的最后。

6.2 其它实现中的问题

6.2.1 记录用户对查询结果的选取

对于用户对查询结果的选取的记录，一般有两种方法，采用client端技术和server端技术。为了方便用户的使用，不改变用户的任何使用习惯，我们采取server端技术来记录用户的选择，这样用户在使用时就不需要丝毫的改变，而我们也能够得到足够的记录信息。

具体说来，传统网页上的链接一般如下：

qqtail.sln

我们采用javascript技术将其进行改造，改造后的形式如下：

QQTail.sln

注意其中有2处javascript脚本。第一处是onClick信息，当用户点击了该链接时，自动重新转向到了我们的服务器上，服务器有一个接收该请求的CGI程序clicklog，这个程序自动转向到实际的FTP下载地址，然后向ClickLog Server发送一个记录请求，ClickLog Server就记录下整个查询串和文件条目信息。

脚本中的另一处是onMouseOver，这个是为了处理当用户已经点击该链接后却又突然想复制该链接而使用的。

只所以在此处使用了javascript而不是直接改变链接地址，是为了便于那些并不希望通过直接点击，而是希望使用下载工具或想复制下载地址的用户的方便。通过现在这种改造，用户看到的页面和链接地址都是和原始信息是完全一致的。

6.2.2 文件类型属性距离计算方法的实现

前面谈到对于常见的文件扩展名，我们将其各自赋予一个属性值，属性值代表了在文件类别树中从根结点到该文件类型所在节点的所有节点编号的集合。节点的编号示例如下图所示，每个节点的子节点的编号都是从1开始的，并没有全局性的编号。

root

1

2

3

4

5

6

1

2

1

2

1

2

1

2

1

2

图 6‑2 ext属性距离计算方法的实现

比如对应图中左下角的灰色节点来说，对应的路径为2.1.1；右下角的灰色节点对应的路径则为5.1.2.2。

这样，如果比较两个节点的相似度，我们只需计数它们的路径中相同的节点个数即可。比如路径为2.1.1的节点和2.2的节点，它们的路径中有一个相同的节点2，或者说相似度为1层；路径为2.1.1的节点和2.1.2的节点，它们的相似度为2层；路径为5.3的节点和路径为7的节点相似度则为0。

具体文件类型分类列表见附录1。

配置文件格式，扩展名分类文件的配置文件的格式举例如下：

111

mp3|wav|wma|

112

midi|mid|

文件说明：

作用：通过读取文件得到每个扩展名对应的路径。

文件格式：每3行为一个记录。每个记录中第一行是空行；第2行是路径，格式为每层节点编号用制表符分割；第3行是扩展名列表，每个扩展名都以竖线“|”结束。

距离计算方法的实现：

在系统实现时，定义了一个ExtVector类，它代表了一个具体的节点路径，ExtVector继承自vector，这里的vector是标准STL的vector，并且实现了如下方法来计算两个路径之间的距离：

double operator – (const ExtVector& e1, const ExtVector& e2);

6.3 系统的评测环境

我们采用天网千帆文件搜索引擎为测试系统。天网千帆文件搜索引擎为北京大学网络实验室开发的一个FTP文件搜索引擎，有较大的用户访问量。在2005年4月，我们先后运行了普通文件搜索引擎和我们设计的新型文件搜索引擎，并记录了用户的查询记录和用户对查询结果的选取信息。

为了保证评测效果的准确性，在使用了新系统后，我们没有通知任何用户，也没有改变任何用户界面，使测试尽量在用户不知情的情况下进行。对于分类后不能归入任何类别的文件条目，为了保证总体查询结果数量不变，我们也没有进行抛弃，而是放在排序的最后返回给用户。这里采用的排序方法是在页内按照各个初始结果集合S0中各个条目距离其类别的距离远近进行排序，对不同的类别之间并不进行排序。在结果的表现形式上与普通搜索引擎无异。

比较试验共进行了8天，其中4天为普通文件检索系统，另外4天则为我们的新系统。我们分别比较了用户对前2页查询结果页面中点击的文件条目在该页面中的排序的情况，共取得了8组比较数据。

6.4 评测结果

具体比较结果参见下图。图中横坐标表示8组比较数据，纵坐标为各组试验数据的在页面中点击的条目的排序的平均值。图中上部的曲线（虚线）为普通文件检索系统的结果，下面的曲线（实线）为新系统的试验结果。

图 6‑3系统试验效果比较

从图中可以明显的看到：在新系统下，用户所点击的文件条目在页面中的排序比普通系统有了较大幅度的提前。

在我们的试验系统中，普通文件检索系统用户点击的条目在页面中的排名为13.70，而使用了新系统后，点击条目的平均排名为8.93。排名前进了13.70-8.93=4.77名。检索效果有了较大幅度的改进。

由此可验证本文所述新型文件检索系统的正确性。

第7章 总结与展望

7.1 总结

作者在本文中首先对文件检索系统进行了一些基础性的研究工作，提出了文件检索系统的检索模型，并提出了评测的指标。然后在对用户使用文件检索系统的行为和习惯进行记录的基础上，发现了用户行为习惯中的两个重要规律。利用这两个规律，作者提出了一个免用户干预的、基于用户查询记录的新型文件检索模型，该模型可以有效的提高文件检索系统的精度。最后作者实现了一个真实的系统并利用该系统对本模型的有效性进行了验证。

7.2 展望

由于研发时间仓促，系统的有些功能还没有来得急加入，有的地方还有待加强，特别如下文所述的几处。

7.2.1 目录

本文的全部算法都没有考虑目录的特殊性，而在实际的FTP系统中是存在目录共享的。在本文提到的试验系统中，对目录是不加区分的看成文件来处理，这样在处理效果上就不是很理想了。

目录和文件的区别主要表现在这几个方面：

首先，目录不存在扩展名属性ext，这样造成了无法利用这个属性来进行判断，而ext属性在距离计算中又是非常重要的一个因素。

其次，目录的大小filesize往往比较大。因为目录是用来容纳文件的，因此目录的大小必然比其内部的任何文件都要大。这样，就不能直接将目录和文件的大小进行相似度计算。

7.2.2 压缩文件类型

压缩文件，比如我们通常见到的zip文件，rar文件等。是一种特殊形式的文件。如文中我们所言，文件的扩展名常常表示文件的类型，比如是图片文件、音乐文件、视频文件等。而压缩文件本身是为了节省存储空间而通过对其它文件进行压缩而生成的。此类文件的意义在于其所压缩的文件，而本身的文件类型是没有意义的。这样就造成了文件类型属性ext判断的失效。

在另一个属性上，文件大小，对于压缩文件也是意义不明显的。因为压缩方式的区别，造成压缩比例的差异，同样大小的原始文件，可能压缩为不同大小的压缩文件；压缩后同样大小的文件，其原始文件可能也是不同的。因此直接用文件大小这个属性来比较压缩文件也是不准确的。

如上这些特性，造成了压缩文件不适于按照一般的文件类型来进行比较，应该进行专门的处理。

参考资料

[Ruthven, et al., 2003] I. Ruthven and M. Lalmas, A survey on the use of relevance feedback for information access, Knowledge Engineering Review. Vol 18. Issue 2. pp 95-145. 2003.

[Chang, et al., 1996] Chen-Chuan K. Chang, Hctor Garca-Molina, and Andreas Paepcke. Boolean Query Mapping Across Heterogeneous Information Sources. IEEE Transactions on Knowledge and Data Engineering, 8(4): 515-521, Aug, 1996.

[Zhang and Dong, 2002] Dell Zhang, Yisheng Dong. A novel Web usage mining approach for search engines, computer networks, 2002, vol.39: 303-310.

[Allison, 1999] Allison, L. Dynamic programming algorithm (DPA) for edit distance, In Algorithms and Data Structures Research & Reference Material. School of Computer Science and Software Engineering, Monash University, Australia 3168. 1999

[Beeferman, et al., 2000] D. Beeferman, A. Berger, Agglomerative clustering of a search engine query log, in: Proceedings of ACM KDD, 2000, Boston, MA, USA.

[Salton, et al, 1983] G. Salton, M. McGill, Introduction to Modern Information Retrieval, McGraw-Hill, New York, 1983.

[Lewis, 1995] D. D. Lewis. Evaluating and optimizing autonomous text classification systems. In Proceedings of SIGIR-95, 18th ACM International Conference on Research and Development in Information Retrieval, pages 246–254, Seattle, US, 1995.

[Ripeanu, 2001] M. Ripeanu, peer-to-peer Architecture Case Study: Gnutella, Network, University of Chicago Technical Report TR-2001-26.

[RFC 959] RFC 959, File Transfer Protocol (FTP)

[陈华等，2003] 陈华，李晓明，高级文件搜索引擎核心功能的实现技术，全国搜索引擎与Web挖掘进展会议，2003.3 15-27

[天网] 天网千帆文件搜索引擎 http://www.mytianwang.cn

[天网maze] 天网maze文件共享系统http://maze.pku.edu.cn

[王建勇等, 2001] 王建勇、单松巍、雷鸣、谢正茂、李晓明，海量web搜索引擎系统中用户行为的分布特征及其启示，《中国科学》E辑，2001年8月，第31卷，第四期，372-384页

[陈华等,2004] 陈华，王继民，韩近强，谢欣，互联网上FTP文件的分布特征及启示，《计算机工程与应用》， 2004年第40卷，129-133

附录：文件类型列表

· 音频文件：1

· 常用：1.1

· 声音记录1.1.1

· mp3|wav| wma|

· 音阶1.1.2

· midi| mid|

· cda|

· mp1|

· m3u|

· mjf|

· voc|

· xm|

· s3m|

· stm|

· mod|

· dsm|

· far|

· ult|

· mtm|

· mp2|

· mpa|

· 669|

· aac|

· mp4|

· vqf|

· pls|

· xpl|

· lrc|

· rmi|

· snd|

· aif|

· wax|

· rms|

· aiff|

· aifc|

· mpga|

· 视频文件2

· 电影常用格式2.1

· real格式2.1.1

· rmvb| rm|

· 高清晰2.1.2

· avi|

· 短篇格式2.2

· mpg| mpeg| asf| wmv| mpe| dat| asx|mkv|

· 字幕2.3

· vob|

· ram|

· rmm|

· rmj|

· wvx|

· m1v|

· wmp|

· ivf|

· smi|

· mpv|

· ssm|

· mpv2|

· mp2v|

· smil|

· rv|

· rp|

· rf|

· rt|

· wm|

· ra|

· kbk|

· la1|

· lar|

· lavs|

· lmsff|

· 图形文件3

· web常用格式3.1

· jpg|bmp|gif| png| jpe|

· 矢量3.2

· wmf|

· pcx|

· tif|

· psd|

· tga|

· pic|

· pcd|

· dib|

· rle|

· iff|

· lbm|

· jif|

· dcx|

· ico|

· tiff|

· ilbm|

· 代码文件4

· C/C++ 4.1

· c|h| cpp|hpp|

· JAVA 4.2

· java|class|

· PASIC 4.3

· pas|

· BASIC 4.4

· bas|

· 汇编 4.5

· asm|

· perl 4.6

· perl|

· js|

· inc|

· cxx|

· tli|

· tlh|

· hxx|

· inl|

· def|

· odl|

· idl|

· py|

· 压缩文件5

· 常用格式5.1

· rar|zip|

· linux压缩格式5.2

· gz|tar|tgz|b64| gz| z|

· arj|

· cab|

· arc|

· bhx|

· hqx|

· lzh|

· mim|

· taz|

· uue|

· xxe|

· tz|

· uu|

· 网页文件6

· 静态6.1

· htm|html|shtml|

· 动态6.2

· php|asp| php3|jsp|

· web程序6.3

· htw|htx|

· css|

· url|

· 程序相关文件7

· 可执行文件7.1

· windows程序7.1.1

· exe|msi|

· Dos文件7.1.2

· com|bat|

· unix程序7.1.3

· out|

· 系统文件7.2

· ocx|dll|drv|

· 文本文件8

· txt|asa|wri|log|scp|

· 系统配置文件9

· 配置文件9.1

· ini|inf|conf|

· 注册表文件9.2

· reg|

· office文档10

· Word文挡10.1

· doc|rtf|wbk|

· Excel文档10.2

· xls|xlb|xlc|

· PowerPoint文档10.3

· ppt|

· 帮助文档11

· hlp|

· Flash文档12

· swf|fla|

· Acrobat文档13

· pdf|pdx|apf|fdf|rmf|xfdf|

· Caj文档14

· caj|kdh|

其它不可识别格式1

作者就读期间参加的科研项目和发表的论文

参加的科研项目

1. 国家“九七三”项目（G1999032706）

发表文章

1. 谢欣，刘菲菲，李晓明，“天网千帆——一种新型文件搜索引擎”，《华南理工大学学报》自然�