伊川网站建设,廊坊市建设局官方网站,微信小程序网站建设公司,特种作业证查询官网一、查询建议介绍
1. 查询建议是什么#xff1f;
查询建议#xff0c;为用户提供良好的使用体验。主要包括#xff1a; 拼写检查#xff1b; 自动建议查询词#xff08;自动补全#xff09;
拼写检查如图#xff1a; 自动建议查询词#xff08;自动补全#xff09;…一、查询建议介绍
1. 查询建议是什么
查询建议为用户提供良好的使用体验。主要包括 拼写检查 自动建议查询词自动补全
拼写检查如图 自动建议查询词自动补全 2. ES 中查询建议的 API
查询建议也是使用_search 端点地址。在 DSL 中 suggest 节点来定义需要的建议查询
示例 1定义单个建议查询词
POST twitter/_search
{query : {match: {message: tring out Elasticsearch}},suggest : { !-- 定义建议查询 --my-suggestion : { !-- 一个建议查询名 --text : tring out Elasticsearch, !-- 查询文本 --term : { !-- 使用词项建议器 --field : message !-- 指定在哪个字段上获取建议词 --}}}
}示例 2定义多个建议查询词
POST _search
{suggest: {my-suggest-1 : {text : tring out Elasticsearch,term : {field : message}},my-suggest-2 : {text : kmichy,term : {field : user}}}
}示例 3多个建议查询可以使用全局的查询文本
POST _search
{suggest: {text : tring out Elasticsearch,my-suggest-1 : {term : {field : message}},my-suggest-2 : {term : {field : user}}}
}二、准备数据
准备一个叫做blogs的索引配置一个text字段。
PUT /blogs/
{mappings: {properties: {body: {type: text}}}
}通过bulk api写入几条文档
POST _bulk/?refreshtrue
{index:{_index:blogs}}
{body:Lucene is cool}
{index:{_index:blogs}}
{body:Elasticsearch builds on top of lucene}
{index:{_index:blogs}}
{body:Elasticsearch rocks}
{index:{_index:blogs}}
{body:Elastic is the company behind ELK stack}
{index:{_index:blogs}}
{body:elk rocks}
{index:{_index:blogs}}
{body:elasticsearch is rock solid}此时blogs索引里已经有一些文档了可以进行下一步的探索。为帮助理解我们先看看哪些term会存在于词典里。 将输入的文本分析一下:
POST _analyze
{text: [Lucene is cool,Elasticsearch builds on top of lucene,Elasticsearch rocks,Elastic is the company behind ELK stack,elk rocks,elasticsearch is rock solid]
}这些分出来的token都会成为词典里一个term注意有些token会出现多次因此在倒排索引里记录的词频会比较高同时记录的还有这些token在原文档里的偏移量和相对位置信息。
三、Suggester 介绍
Term Suggester 对给入的文本进行分词为每个词进行模糊查询提供词项建议并不会考虑多个term/词组之间的关系。。API调用方只需为每个token挑选options里的词组合在一起返回给用户前端即可Phrase Suggester在Term Suggester的基础上会考量多个term之间的关系比如是否同时出现在索引的原文里相邻程度以及词频等等Completion SuggesterFST数据结构类似Trie树不用打开倒排快速返回前缀匹配Context Suggester在Completion Suggester的基础上用于filter和boost
1. Term suggester
term 词项建议器对给入的文本进行分词为每个词进行模糊查询提供词项建议。对于在索引中存在词默认不提供建议词不存在的词则根据模糊查询结果进行排序后取一定数量的建议词。
常用的建议选项
text搜索文本。建议文本是必填选项需要全局或按建议设置。field从中获取候选建议的字段。这是必需选项需要全局设置或根据建议设置。analyzer分析器用来分析建议文本。默认为建议字段的搜索分析器。size每个建议文本将返回的最大数。sort定义每个建议文本术语应如何分类建议。两个可能的值score首先按分数排序然后记录频次然后是词条本身。frequency首先按文档频率排序然后按相似性得分排序然后再按术语本身排序。suggest_mode提示模式控制要包含的建议或控制建议的文本术语和建议的控件。可以指定三个可能的值missing仅对未在索引中的建议文本术语提供建议。这是默认值。popular仅建议在比原始建议文本术语更多的文档中出现的建议。always根据建议文本中的术语建议任何匹配的建议。lowercase_terms在文本分析之后将建议的文本术语小写。max_edits最大编辑距离候选建议可以具有以便被认为是建议。只能是 1 到 2 之间的值。任何其他值都将导致引发错误的请求错误。默认为 2。prefix_length必须匹配的最小前缀字符数才能成为建议的候选者。默认值为 1。增加此数字可提高拼写检查性能。通常拼写错误不会出现在学期开始时。旧名称 “prefix_len” 已弃用
示例 1
POST twitter/_search
{suggest : { !-- 定义建议查询 --my-suggestion : { !-- 一个建议查询名 --text : lucne rock, !-- 查询文本 --term : { !-- 使用词项建议器 --suggest_mode: missing,field : body !-- 指定在哪个字段上获取建议词 --}}}
}返回结果
{took : 2,timed_out : false,_shards : {total : 1,successful : 1,skipped : 0,failed : 0},hits : {total : {value : 0,relation : eq},max_score : null,hits : [ ]},suggest : {my-suggestion : [{text : lucne,offset : 0,length : 5,options : [{text : lucene,score : 0.8,freq : 2}]},{text : rock,offset : 6,length : 4,options : [ ]}]}
}在返回结果里suggest - “my-suggestion部分包含了一个数组每个数组项对应从输入文本分解出来的token存放在text这个key里以及为该token提供的建议词项存放在options数组里)。 示例里返回了lucne”rock这2个词的建议项(options)其中rock的options是空的表示没有可以建议的选项为什么 上面提到了我们为查询提供的suggest mode是missing,由于rock在索引的词典里已经存在了够精准就不建议啦。 只有词典里找不到词才会为其提供相似的选项。
如果将suggest_mode换成popular会是什么效果
尝试一下重新执行查询返回结果里rock这个词的option不再是空的而是建议为rocks。 suggest : {my-suggestion : [{text : lucne,offset : 0,length : 5,options : [{text : lucene,score : 0.8,freq : 2}]},{text : rock,offset : 6,length : 4,options : [{text : rocks,score : 0.75,freq : 2}]}]}回想一下rock和rocks在索引词典里都是有的。 不难看出即使用户输入的token在索引的词典里已经有了但是因为存在一个词频更高的相似项这个相似项可能是更合适的就被挑选到options里了。 最后还有一个always mode其含义是不管token是否存在于索引词典里都要给出相似项。
Term suggester正如其名只基于analyze过的单个term去提供建议并不会考虑多个term之间的关系。API调用方只需为每个token挑选options里的词组合在一起返回给用户前端即可。 那么有无更直接办法API直接给出和用户输入文本相似的内容 答案是有这就要求助Phrase Suggester了。
2. phrase suggester
phrase 短语建议在 term 的基础上会考量多个 term 之间的关系比如是否同时出现在索引的原文里相邻程度以及词频等
看个范例就比较容易明白了:
POST /blogs/_search
{suggest: {my-suggestion: {text: lucne and elasticsear rock,phrase: {field: body,highlight: {pre_tag: em,post_tag: /em}}}}
}返回结果: suggest : {my-suggestion : [{text : lucne and elasticsear rock,offset : 0,length : 26,options : [{text : lucene and elasticsearch rock,highlighted : emlucene/em and emelasticsearch/em rock,score : 0.004993905},{text : lucne and elasticsearch rock,highlighted : lucne and emelasticsearch/em rock,score : 0.0033391973},{text : lucene and elasticsear rock,highlighted : emlucene/em and elasticsear rock,score : 0.0029183894}]}]}options直接返回一个phrase列表由于加了highlight选项被替换的term会被高亮。因为lucene和elasticsearch曾经在同一条原文里出现过同时替换2个term的可信度更高所以打分较高排在第一位返回。Phrase suggester有相当多的参数用于控制匹配的模糊程度需要根据实际应用情况去挑选和调试。
3. Completion suggester 自动补全
针对自动补全(“Auto Completion”)场景而设计的建议器。此场景下用户每输入一个字符的时候就需要即时发送一次查询请求到后端查找匹配项在用户输入速度较高的情况下对后端响应速度要求比较苛刻。因此实现上它和前面两个 Suggester 采用了不同的数据结构索引并非通过倒排来完成而是将 analyze 过的数据编码成 FST 和索引一起存放。对于一个 open 状态的索引FST 会被 ES 整个装载到内存里的进行前缀查找速度极快。 但是 FST 只能用于前缀查找这也是 Completion Suggester 的局限所在。
官网链接
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters-completion.html completiones 的一种特有类型专门为 suggest 提供基于内存性能很高。 prefix query基于前缀查询的搜索提示是最常用的一种搜索推荐查询。 prefix客户端搜索词field建议词字段size需要返回的建议词数量默认 5skip_duplicates是否过滤掉重复建议默认 false fuzzy query fuzziness允许的偏移量默认 autotranspositions如果设置为 true则换位计为一次更改而不是两次更改默认为 true。min_length返回模糊建议之前的最小输入长度默认 3prefix_length输入的最小长度不检查模糊替代项默认为 1unicode_aware如果为 true则所有度量如模糊编辑距离换位和长度均以 Unicode 代码点而不是以字节为单位。这比原始字节略慢因此默认情况下将其设置为 false。 regex query可以用正则表示前缀不建议使用
为了使用自动补全索引中用来提供补全建议的字段需特殊设计字段类型为 completion。
PUT /blogs_completion/
{mappings: {properties: {body: {type: completion}}}
}用bulk API索引点数据:
POST _bulk/?refreshtrue
{index:{_index:blogs_completion}}
{body:Lucene is cool}
{index:{_index:blogs_completion}}
{body:Elasticsearch builds on top of lucene}
{index:{_index:blogs_completion}}
{body:Elasticsearch rocks}
{index:{_index:blogs_completion}}
{body:Elastic is the company behind ELK stack}
{index:{_index:blogs_completion}}
{body:the elk stack rocks}
{index:{_index:blogs_completion}}
{body:elasticsearch is rock solid}查找:
POST blogs_completion/_search?pretty
{size: 0,suggest: {blog-suggest: {prefix: elastic i,completion: {field: body}}}
}结果: suggest : {blog-suggest : [{text : elastic i,offset : 0,length : 9,options : [{text : Elastic is the company behind ELK stack,_index : blogs_completion,_type : _doc,_id : 8nI0YYwBPMQ17EXsspBh,_score : 1.0,_source : {body : Elastic is the company behind ELK stack}}]}]}值得注意的一点是Completion Suggester在索引原始数据的时候也要经过analyze阶段取决于选用的analyzer不同某些词可能会被转换某些词可能被去除这些会影响FST编码结果也会影响查找匹配的效果。
比如我们删除上面的索引重新设置索引的mapping将analyzer更改为english:
DELETE blogs_completion
PUT /blogs_completion/
{mappings: {properties: {body: {type: completion,analyzer: english}}}
}bulk api索引同样的数据后执行下面的查询:
POST blogs_completion/_search?pretty
{size: 0,suggest: {blog-suggest: {prefix: elastic i,completion: {field: body}}}
}居然没有匹配结果了多么费解 原来我们用的english analyzer会剥离掉stop word而is就是其中一个被剥离掉了 用analyze api测试一下:
POST _analyze
{analyzer: english,text: elasticsearch is rock solid
}会发现只有3个token:
{tokens : [{token : elasticsearch,start_offset : 0,end_offset : 13,type : ALPHANUM,position : 0},{token : rock,start_offset : 17,end_offset : 21,type : ALPHANUM,position : 2},{token : solid,start_offset : 22,end_offset : 27,type : ALPHANUM,position : 3}]
}FST只编码了这3个token并且默认的还会记录他们在文档中的位置和分隔符。 用户输入elastic i进行查找的时候输入被分解成elastic和iFST没有编码这个“i” , 匹配失败。
好吧如果你现在还足够清醒的话试一下搜索elastic is会发现又有结果why? 因为这次输入的text经过english analyzer的时候is也被剥离了只需在FST里查询elastic这个前缀自然就可以匹配到了。
其他能影响completion suggester结果的还有诸如preserve_separatorspreserve_position_increments等等mapping参数来控制匹配的模糊程度。以及搜索时可以选用Fuzzy Queries使得上面例子里的elastic i在使用english analyzer的情况下依然可以匹配到结果。
因此用好Completion Sugester并不是一件容易的事实际应用开发过程中需要根据数据特性和业务需要灵活搭配analyzer和mapping参数反复调试才可能获得理想的补全效果。
回到篇首百度搜索框的补全/纠错功能如果用ES怎么实现呢我能想到的一个的实现方式:
在用户刚开始输入的过程中使用Completion Suggester进行关键词前缀匹配刚开始匹配项会比较多随着用户输入字符增多匹配项越来越少。如果用户输入比较精准可能Completion Suggester的结果已经够好用户已经可以看到理想的备选项了。如果Completion Suggester已经到了零匹配那么可以猜测是否用户有输入错误这时候可以尝试一下Phrase Suggester。如果Phrase Suggester没有找到任何option开始尝试term Suggester。
精准程度上(Precision)看 Completion Phrase term 而召回率上(Recall)则反之。从性能上看Completion Suggester是最快的如果能满足业务需求只用Completion Suggester做前缀匹配是最理想的。 Phrase和Term由于是做倒排索引的搜索相比较而言性能应该要低不少应尽量控制suggester用到的索引的数据量最理想的状况是经过一定时间预热后索引可以全量map到内存。
4. context suggester
完成建议者会考虑索引中的所有文档但是通常来说我们在进行智能推荐的时候最好通过某些条件过滤并且有可能会针对某些特性提升权重。 contexts上下文对象可以定义多个 namecontext的名字用于区分同一个索引中不同的context对象。需要在查询的时候指定当前name typecontext对象的类型目前支持两种category和geo分别用于对suggest item分类和指定地理位置。 boost权重值用于提升排名 path如果没有path相当于在PUT数据的时候需要指定context.name字段如果在Mapping中指定了path在PUT数据的时候就不需要了因为 Mapping是一次性的而PUT数据是频繁操作这样就简化了代码。这段解释有木有很牛逼网上搜到的都是官方文档的翻译觉悟雷同。
# context suggester
# 定义一个名为 place_type 的类别上下文其中类别必须与建议一起发送。
# 定义一个名为 location 的地理上下文类别必须与建议一起发送
DELETE place
PUT place
{mappings: {properties: {suggest: {type: completion,contexts: [{name: place_type,type: category},{name: location,type: geo,precision: 4}]}}}
}PUT place/_doc/1
{suggest: {input: [ timmys, starbucks, dunkin donuts ],contexts: {place_type: [ cafe, food ] }}
}
PUT place/_doc/2
{suggest: {input: [ monkey, timmys, Lamborghini ],contexts: {place_type: [ money] }}
}GET place/_search
POST place/_search?pretty
{suggest: {place_suggestion: {prefix: sta,completion: {field: suggest,size: 10,contexts: {place_type: [ cafe, restaurants ]}}}}
}
# 某些类别的建议可以比其他类别提升得更高。以下按类别过滤建议并额外提升与某些类别相关的建议
GET place/_search
POST place/_search?pretty
{suggest: {place_suggestion: {prefix: tim,completion: {field: suggest,contexts: {place_type: [ { context: cafe },{ context: money, boost: 2 }]}}}}
}# 地理位置筛选器
PUT place/_doc/3
{suggest: {input: timmys,contexts: {location: [{lat: 43.6624803,lon: -79.3863353},{lat: 43.6624718,lon: -79.3873227}]}}
}
POST place/_search
{suggest: {place_suggestion: {prefix: tim,completion: {field: suggest,contexts: {location: {lat: 43.662,lon: -79.380}}}}}
}# 定义一个名为 place_type 的类别上下文其中类别是从 cat 字段中读取的。
# 定义一个名为 location 的地理上下文其中的类别是从 loc 字段中读取的
DELETE place_path_category
PUT place_path_category
{mappings: {properties: {suggest: {type: completion,contexts: [{name: place_type,type: category,path: cat},{name: location,type: geo,precision: 4,path: loc}]},loc: {type: geo_point}}}
}
# 如果映射有路径那么以下索引请求就足以添加类别
# 这些建议将与咖啡馆和食品类别相关联
# 如果上下文映射引用另一个字段并且类别被明确索引则建议将使用两组类别进行索引
PUT place_path_category/_doc/1
{suggest: [timmys, starbucks, dunkin donuts],cat: [cafe, food]
}
POST place_path_category/_search?pretty
{suggest: {place_suggestion: {prefix: tim,completion: {field: suggest,contexts: {place_type: [ { context: cafe }]}}}}
}参考
官网
