我们生活中的数据总体分为两种： 结构化数据和非结构化数据。
结构化数据： 指具有固定格式或有限长度的数据，如数据库，元数据等。
非结构化数据： 指不定长或无固定格式的数据，如邮件， word 文档等。
当然有的地方还会提到第三种，半结构化数据，如 XML， HTML 等，当根据需要可按结构化
数据来处理，也可抽取出纯文本按非结构化数据来处理。非结构化数据又一种叫法叫全文数据。
按照数据的分类，搜索也分为两种：
对结构化数据的搜索：如对数据库的搜索，用 SQL 语句。再如对元数据的搜索，如利用windows 搜索对文件名，类型，修改时间进行搜索等。
对非结构化数据的搜索：如利用 windows 的搜索也可以搜索文件内容， Linux 下的 grep命令，再如用 Google 和百度可以搜索大量内容数据。
对非结构化数据也即对全文数据的搜索主要有两种方法：
一种是顺序扫描法(Serial Scanning)：所谓顺序扫描，比如要找内容包含某一个字符串的文件，就是一个文档一个文档的看，对于每一个文档，从头看到尾，如果此文档包含此字符串，则此文档为我们要找的文件，接着看下一个文件，直到扫描完所有的文件。
将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。
这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引。 这种先建立索引，再对索引进行搜索的过程就叫全文检索(Full-text Search)。
全文检索大体分两个过程，索引创建(Indexing)和搜索索引(Search)。
索引创建：将现实世界中所有的结构化和非结构化数据提取信息，创建索引的过。
搜索索引：就是得到用户的查询请求，搜索创建的索引，然后返回结果的过程。
索引里面究竟存些什么？ (Index)
由于从字符串到文件的映射是文件到字符串映射的反向过程，于是保存这种信息的索引称为反向索引。
全文检索的确加快了搜索的速度，但是多了索引的过程。的确，加上索引的过程，全文检索不一定比顺序扫描快，
尤其是在数据量小的时候更是如此。而对一个很大量的数据创建索引也是一个很慢的过程。然而两者还是有区别的，顺序扫描是每次都要扫描，而创建索引的过程仅仅需要一次，以后便是一劳永逸的了，每次搜索，创建索引的过程不必经过，仅仅搜索创建好的索引就可以了。这也是全文搜索相对于顺序扫描的优势之一：一次索引，多次使用。
如何创建索引？ (Indexing)
第一步： 一些要索引的原文档(Document)。
为了方便说明索引创建过程，这里特意用两个文件为例：
文件一： Students should be allowed to go out with their friends, but not allowed to drink beer.
文件二： My friend Jerry went to school to see his students but found them drunk which is notallowed.
第二步： 将原文档传给分次组件(Tokenizer)。
分词组件(Tokenizer)会做以下几件事情(此过程称为 Tokenize)：
1. 将文档分成一个一个单独的单词。
2. 去除标点符号。
3. 去除停词(Stop word)。
所谓停词(Stop word)就是一种语言中最普通的一些单词，由于没有特别的意义，因而大多数情况下不能成为搜索的关键词，因而创建索引时，这种词会被去掉而减少索引的大小。英语中停词如： “the”,“a”， “this”等。
对于每一种语言的分词组件(Tokenizer)，都有一个停词(stop word)集合。
经过分词(Tokenizer)后得到的结果称为词元(Token)。
在我们的例子中，便得到以下词元(Token)：
“Students”， “allowed”， “go”， “their”， “friends”， “allowed”， “drink”， “beer”， “My”， “friend”，
“Jerry”， “went”， “school”， “see”， “his”， “students”， “found”， “them”， “drunk”， “allowed”。
第 三 步 ：将得到的词元 (Token)传给语言处理组件(Linguistic Processor)。
语言处理组件(linguistic processor)主要是对得到的词元(Token)做一些同语言相关的处理。
对于英语，语言处理组件(Linguistic Processor)一般做以下几点：
1. 变为小写(Lowercase)。
2. 将单词缩减为词根形式，如“cars”到“car”等。这种操作称为： stemming。
3. 将单词转变为词根形式，如“drove”到“drive”等。这种操作称为： lemmatization。
Stemming 和lemmatization 的异同：
相同之处： Stemming 和 lemmatization 都要使词汇成为词根形式。
两者的方式不同：
Stemming 采用的是“缩减”的方式： “cars”到“car”， “driving”到“drive”。
Lemmatization 采用的是“转变”的方式： “drove”到“drove”， “driving”到“drive”。
两者的算法不同：
Stemming 主要是采取某种固定的算法来做这种缩减，如去除“s”，去除“ing”加“e”，将“ational”变为“ate”，“tional”变为“tion”。
Lemmatization 主要是采用保存某种字典的方式做这种转变。比如字典中有“driving”到“drive”， “drove”到“drive”， “am, is, are”到“be”的映射，做转变时，只要查字典就可以了。
Stemming 和 lemmatization 不是互斥关系，是有交集的，有的词利用这两种方式都能达到相同的转换。
语言处理组件(linguistic processor)的结果称为词(Term)。
在我们的例子中，经过语言处理，得到的词(Term)如下：
“student”， “allow”， “go”， “their”， “friend”， “allow”， “drink”， “beer”， “my”， “friend”， “jerry”，
“go”， “school”， “see”， “his”， “student”， “find”， “them”， “drink”， “allow”。
也正是因为有语言处理的步骤，才能使搜索 drove，而 drive 也能被搜索出来。
第四步： 将得到的词(Term)传给索引组件(Indexer)。
索引组件(Indexer)主要做以下几件事情：
1. 利用得到的词(Term)创建一个字典。
在我们的例子中字典如下：
Term Document ID
student 1
allow 1
go 1
their 1
friend 1
allow 1
drink 1
beer 1
my 2
friend 2
jerry 2
go 2
school 2
see 2
his 2
student 2
find 2
them 2
drink 2
allow 2
2. 对字典按字母顺序进行排序。
Term Document ID
allow 1
allow 1
allow 2
beer 1
drink 1
drink 2
find 2
friend 1
friend 2
go 1
go 2
his 2
jerry 2
my 2
school 2
see 2
student 1
student 2
their 1
them 2
3. 合并相同的词(Term)成为文档倒排(Posting List)链表链表。
如何对索引进行搜索？ (Search)
第一步： 用户输入查询语句。
查询语句同我们普通的语言一样，也是有一定语法的。
不同的查询语句有不同的语法，如 SQL 语句就有一定的语法。
查询语句的语法根据全文检索系统的实现而不同。最基本的有比如： AND, OR, NOT 等。
举个例子，用户输入语句： lucene AND learned NOT hadoop。
说明用户想找一个包含 lucene 和 learned 然而不包括 hadoop 的文档。
第二步： 对查询语句进行词法分析， 语法分析， 及语言处理。
由于查询语句有语法，因而也要进行语法分析，语法分析及语言处理。
1. 词法分析主要用来识别单词和关键字。
如上述例子中，经过词法分析，得到单词有 lucene， learned， hadoop, 关键字有 AND, NOT。
如果在词法分析中发现不合法的关键字，则会出现错误。如 lucene AMD learned，其中由于AND 拼错，导致 AMD 作为一个普通的单词参与查询。
2. 语法分析主要是根据查询语句的语法规则来形成一棵语法树。
如果发现查询语句不满足语法规则，则会报错。如 lucene NOT AND learned，则会出错。
如上述例子， lucene AND learned NOT hadoop 形成的语法树如下：
3. 语言处理同索引过程中的语言处理几乎相同。
如 learned 变成 learn 等。经过第二步，我们得到一棵经过语言处理的语法树。
第四步： 根据得到的文档和查询语句的相关性， 对结果进行排序排序。
虽然在上一步，我们得到了想要的文档，然而对于查询结果应该按照与查询语句的相关性进行排序，越相关者越靠前。如何计算文档和查询语句的相关性呢？
不如我们把查询语句看作一片短小的文档，对文档与文档之间的相关性(relevance)进行打分(scoring)，分数高的相关性好，就应该排在前面。
判断文档之间的关系：
首先， 一个文档有很多词(Term)组成组成，如 search, lucene, full-text, this, a, what 等。
其次对于文档之间的关系， 不同的 Term 重要性不同，比如对于本篇文档， search, Lucene, full-text 就相对重要一些，this, a , what 可能相对不重要一些。所以如果两篇文档都包含 search, Lucene， fulltext，这两篇文档的相关性好一些，然而就算一篇文档包含 this, a, what，另一篇文档不包含 this, a, what，也不能影响两篇文档的相关性。
因而判断文档之间的关系，首先找出哪些词(Term)对文档之间的关系最重要，如 search, Lucene, fulltext。然后判断这些词(Term)之间的关系。
找出词(Term)对文档的重要性的过程称为计算词的权重(Term weight)的过程。
计算词的权重(term weight)有两个参数，第一个是词(Term)，第二个是文档(Document)。
词的权重(Term weight)表示此词(Term)在此文档中的重要程度，越重要的词(Term)有越大的权重(Term weight)，因而在计算文档之间的相关性中将发挥更大的作用。判断词(Term)之间的关系从而得到文档相关性的过程应用一种叫做向量空间模型的算法(Vector Space Model)。
下面仔细分析一下这两个过程：
1. 计算权重(Term weight)的过程。
影响一个词(Term)在一篇文档中的重要性主要有两个因素：
Term Frequency (tf)：即此 Term 在此文档中出现了多少次。 tf 越大说明越重要。
Document Frequency (df)：即有多少文档包含次 Term。 df 越大说明越不重要。
\(w_{t,d}=tf_{t,d}\times\log{(n/df_t)}\)
2. 判断判断 Term 之间的关系从而得到文档相关性的过程， 也即向量空间模型的算法(VSM)。
我们把文档看作一系列词(Term)，每一个词(Term)都有一个权重(Term weight)，不同的词(Term)
根据自己在文档中的权重来影响文档相关性的打分计算。
于是我们把所有此文档中词(term)的权重(term weight) 看作一个向量。
Document = {term1, term2, …… ,term N}
Document Vector = {weight1, weight2, …… ,weight N}
同样我们把查询语句看作一个简单的文档，也用向量来表示。
Query = {term1, term 2, …… , term N}
Query Vector = {weight1, weight2, …… , weight N}
我们把所有搜索出的文档向量及查询向量放到一个 N 维空间中，每个词(term)是一维
我们认为两个向量之间的夹角越小，相关性越大。所以我们计算夹角的余弦值作为相关性的打分，夹角越小，余弦值越大，打分越高，相关性越大。有人可能会问，查询语句一般是很短的，包含的词(Term)是很少的，因而查询向量的维数很小，而文档很长，包含词(Term)很多，文档向量维数很大。你的图中两者维数怎么都是 N 呢？
在这里，既然要放到相同的向量空间，自然维数是相同的，不同时，取二者的并集，如果不含某个词(Term)时，则权重(Term Weight)为 0。相关性打分公式如下：
\[score{(q,d)}=\frac{\vec{V_q}\cdot\vec{V_d}}{\mid\vec{V_q}\mid\mid\vec{V_d}\mid}=\frac{\sum_{i=1}^n{w_{i,q}w_{i,d}}}{{\sqrt{\sum_{i=1}^n{w^2_{i,q}}}}{\sqrt{\sum_{i=1}^n{w^2_{i,d}}}}}\]
对上述索引创建和搜索过程所一个总结，如图：
1. 索引过程：
1) 有一系列被索引文件
2) 被索引文件经过语法分析和语言处理形成一系列词(Term)。
3) 经过索引创建形成词典和反向索引表。
4) 通过索引存储将索引写入硬盘。
2. 搜索过程：
a) 用户输入查询语句。
b) 对查询语句经过语法分析和语言分析得到一系列词(Term)。
c) 通过语法分析得到一个查询树。
d) 通过索引存储将索引读入到内存。
e) 利用查询树搜索索引，从而得到每个词(Term)的文档链表，对文档链表进行交，差，并得到结果文档。
f) 将搜索到的结果文档对查询的相关性进行排序。
g) 返回查询结果给用户。
Comments