1、问题

在使用搜索引擎(Elasticsearch或Solr)作为应用的后台搜索平台的时候,会遇到停用词(stopwords)的问题。

在信息检索中,停用词是为节省存储空间和提高搜索效率,处理文本时自动过滤掉某些字或词,这些字或词即被称为Stop Words(停用词)。停用词大致分为两类。一类是语言中的功能词,这些词极其普遍而无实际含义,比如“the”、“is“、“which“、“on”等。另一类是词汇词,比如'want'等,这些词应用广泛,但搜索引擎无法保证能够给出真正相关的搜索结果,难以缩小搜索范围,还会降低搜索效率。实践中,通常把这些词从问题中过滤,从而节省索引的存储空间、提高搜索性能。

但是在实际语言环境中,停用词有时也有用的。比如,莎士比亚的名句:“To be or not to be.”所有的词都是停用词。特别当停用词和通配符(*)同时使用的时候,问题就来了:“the”、“is“、“on”还是停用词码?

2、解决方案

实际运用中,没有一个解决方案是100%完美的。很多时候需要我们根据实际用例作相应的调整和折中,来达到期望的结果。在这个时候,需要用80/20原则,把目标专著在提高用户体验上。

2.1、对不同的搜索对象区别对待

过滤停用词是为节省存储空间和提高搜索效率。实践中,不同的应用场景和对象对存储空间和搜索效率的需求不一样。比如,文章的标题,一般都很短,而且有大量的限定词区别词的定义,它对节省存储空间和效率的要求不高,但是常常需要停用词来限定名词的意义。我们可以考虑保留停用词。而对于文章体的全文本,存储空间和效率的要求很高,使用停用词过滤可以大大减少存储空间,提高搜索效率。

对Elasticsearch,下面是我们用到的索引定义:消息标题是text类型,没有使用停用词,而消息文本是standard_text类型,这个类型在设置里定义了使用英语标准的停用词过滤。

{
"demo": {
"settings": {
"index": {
"number_of_shards": "",
"number_of_replicas": "",
"analysis": {
"analyzer": {
"standard_text": {
"type": "standard",
"stopwords": "_english_"
}
}
}
},
"mappings": {
"msg": {
"_routing": { "required": true },
"properties": {
"title": {
"type": "text"
},
"body": {
"type": "text",
"analyzer": "standard_text"
}
}
}
}
}
}

2.2、match查询

考虑一个例子:“and”。作为停用词,在“and”会在索引创建的时候被过滤掉:POST store/_analyze {  "field": "body", "text": ["and"] }

得到的分析结果是:{  "tokens": []  }

但是,如果我们用title字段来分析的时候,结果会得到保存:POST store/_analyze {  "field": "title", "text": ["and"] }

{ "tokens": [{
"token": "and",
"start_offset": ,
"end_offset": ,
"type": "<ALPHANUM>",
"position":
}
]
}

但是当我们需要搜索文本的时候,会出现很多不如意的地方。比如,如果我们需要查消息体内chris && and && john这三个词的时候,因为and被过滤了,而查询条件又是与操作,导致没有任何信息符合。有人说,能不能把and从查询条件中去除啊?可以,虽然有点麻烦,总是可以做。但是,有几个新问题需要解决:

  • 你需要拿到所有语言的停用词才能做这个预处理。
  • 万一这些语言的停用词变了呢?我们还需要及时更正。

幸运的是Elasticsearch的match查询提供了一个功能解决这个问题,同时我们不需要在应用程序中预处理停用词:zero_terms_query和cutoff_frequency。

  • zero_terms_query

如果使用的分析器删除查询中的所有标记(如停用词),默认行为完全不匹配任何文档(none)。 可以使用zero_terms_query选项改变默认,none(默认),或all对应于match_all查询。

当查询使用"operator" : "and"的时候,需要把zero_terms_query设置为all。如果"operator" : "or",默认选项是我们需要的:

GET demo/msg/_search
{
"query": {
"match" : {
"body" : {
"query" : "chris and john",
"operator" : "and",
"zero_terms_query": "all"
}
}
}
}
  • cutoff_frequency

match查询支持cutoff_frequency,允许指定绝对或相对的文档频率:

    • OR:高频单词被放入“或许有”的类别,仅在至少有一个低频(低于截断)单词满足条件时才积分;
    • AND:高频单词被放入“或许有”的类别,仅在所有低频(低于截断)单词满足条件时才积分。

该查询允许在运行时动态地处理停用词,相对领域独立,并且不需要停用词文件。它防止评分/迭代高频词,只在更重要(更低频率)的词与文档匹配时才考虑。但是,如果所有查询条件都高于给定的cutoff_frequency,查询会自动转换为纯联合(和)查询以确保快速执行。

cutoff_frequency可以是相对于文档的总数的小数[0..1),也可以是绝对值[1, +∞)。

GET demo/msg/_search
{
"query": {
"match" : {
"body" : {
"query" : "chris and john",
"cutoff_frequency" : 0.001
}
}
}
}

2.3、common 查询

大致说,common查询会分析查询文本,确定哪些单词“重要”,并使用这些单词进行搜索。 只有在文件与重要文字相匹配后才考虑“不重要”的字眼。“common查询”背后的动机是充分利用停用词清除的功能(更快的搜索),而不会完全消除停用词(因为它们有时可能有助于得分)。

执行此查询时会分几步:

  1. 查询会被发送到索引的每个shard;
  2. 在每个shard,Elasticsearch都会查看每个术语的文档频率
  3. 如果一个词的文档频率低于0.1%(0.001),那么它被认为是“低频”。 否则,它将被移到次要的“高频”列表中
  4. “低频”列表被重写为(逻辑AND)。 在这个例子中,它会包含“bonsai”,“cool”
  5. 然后将任何高频的文档分到剩余的高频列表中(“this”,“is”)

看看下面例子:

{
"common": {
"body": {
"query": "this is bonsai cool",
"cutoff_frequency": 0.001
}
}
}

在系统内,它被重写为:

{
"bool": {
"must": [
{ "term": { "body": "bonsai"}},
{ "term": { "body": "cool"}}
],
"should": [
{ "term": { "body": "this"}}
{ "term": { "body": "is"}}
]
}
}

3、通配符

我们还有一个问题,match查询不支持通配符。Elasticsearch对通配符支持包括两个情况:

  • keyword:wildcard,prefix
  • text:wildcard,prefix,match_phrase_prefix

第一种情况下,keyword的字段不会对索引和查询时文本做预处理。因此,在对该字段索引和查询的时候,应用程序必须做简单的一致性处理 ,比如把单词字母都变成小写。

第二种情况,text在索引时是通过分析器处理和过滤的,比如每个词都会正规化。而查询时,wildcard,match_prefix,match_phrase_prefix每个方法对查询文本的处理都不一样,需要分开对待:

  • wildcard:查询时Elasticsearch不会通过分析器处理,因此,应用程序必须对查询文本做简单的一致性处理。
  • prefix,match_phrase_prefix:查询时Elasticsearch会通过分析器处理。这时候停用词会被过滤掉。

参考文献

[1] https://www.elastic.co/blog/stop-stopping-stop-words-a-look-at-common-terms-query

05-08 08:35