概要
前面的match查询只能告诉我们,搜索的文档里有这些关键词,但无法告知词语之间的顺序,而不同的词语顺序表达的意思可能完全相反。我们想要的,是跟我们期望搜索的语义要相似,这就需要短语匹配和近似匹配来控制了。
短语搜索
短语搜索即把一小段话完完整整地进行搜索,必须保证被搜索的文档内有一模一样的才行,如下:
GET /music/children/_search
{
"query": {
"match_phrase": {
"content": "in the morning"
}
}
}
Elasticsearch对短语搜索必须要满足如下要求:
- in the morning 三个单词必须要全部出现
- the的位置比in大1
- morning的位置比the大1
任何一个不成立,则搜索不到匹配的结果。意思上是说,短语搜索除了关注关键词是否出现,还关心被搜索文档中这几个关键词的位置,我们可以用调度命令看一下词条的位置:
GET /_analyze
{
"analyzer":"standard",
"text": "in the morning"
}
响应结果:
{
"tokens": [
{
"token": "in",
"start_offset": 0,
"end_offset": 2,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "the",
"start_offset": 3,
"end_offset": 6,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "morning",
"start_offset": 7,
"end_offset": 14,
"type": "<ALPHANUM>",
"position": 2
}
]
}
留意一下tokens显示的position信息,position连续说明这三个词紧靠在一起,搜索文档时,也只有命中这三个词的文档,position按次序连接才能匹配得上。
近似匹配
近似匹配是在短语匹配的基础上,短语匹配有些严格,要求位置必须按照搜索字符串来,近似匹配则有一些变通,允许短语之间的位置有变化,变化的程度由参数slop决定。
例如:
GET /music/children/_search
{
"query": {
"match_phrase": {
"content": {
"query": "you me",
"slop": 1
}
}
}
}
slop含义
- query string搜索文本中的几个term,要经过n次移动才能与一个document匹配,这个移动的次数,就是slop。
- slop表示移动的最大次数,离得越近的,分数就会越高。
- term之间交换位置也行的,但是slop得大一些。
我们以字符串"you make me happy"举例,画个移动表格:
pos 1 | pos 2 | pos 3 | pos 4 | |
---|---|---|---|---|
DOC | you | make | me | happy |
query | you | me | ||
slop 1 | you | -> | me |
me只需要移动一步,就能匹配上,所以slop 1能查询到结果。
演示样例有限,我们把搜索串改成"me you",模拟颠倒次序的slop,但slop至少要是3才行:
GET /music/children/_search
{
"query": {
"match_phrase": {
"content": {
"query": "me you",
"slop": 3
}
}
}
}
为什么是3,我们以字符串"you make me happy"再画个移动表格
pos 1 | pos 2 | pos 3 | pos 4 | |
---|---|---|---|---|
DOC | you | make | me | happy |
query | you | me | ||
slop 1 | me/you | <- | ||
slop 2 | you -> | me | ||
slop 3 | you | -> | me |
注意slop 1时,me和you共占用同一个位置,二者交换一下顺序,就需要slop为2。
近似匹配,就是使用了slop参数的短语匹配。
数组类型的slop
我们music索引中的tags字段,设计时是数组类型的,如果我们对这个字段进行近似匹配,结果会是怎么样:
_id为1的文档数据,tags是这样的:"tags": ["enlighten","gymbo","friend"]
按照slop的偏移量,slop为1应该是可以匹配上
GET /music/children/_search
{
"query": {
"match_phrase": {
"tags": {
"query": "enlighten friend",
"slop": 1
}
}
}
}
结果竟然是空,怎么回事呢?我们分析一下该field的tokens信息:
GET /music/_analyze
{
"field": "tags",
"text": ["enlighten","gymbo","friend"]
}
响应
{
"tokens": [
{
"token": "enlighten",
"start_offset": 0,
"end_offset": 9,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "gymbo",
"start_offset": 10,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 101
},
{
"token": "friend",
"start_offset": 16,
"end_offset": 22,
"type": "<ALPHANUM>",
"position": 202
}
]
}
注意一下position的值,数组元素之间,position间隔都是100。
6.x的版本,position_increment_gap参数值默认是100,表示元素之间,步长为100,毕竟没有人近似查询时会关系slop大于100的结果。之前老版本这个值默认是1,出现了很多意外的问题,6.x后算是对此问题的修复。
召回率与精准度的平衡
召回率:假设有100个doc,你搜索一段文本,能返回多个doc,与总doc的比例,就是召回率,recall。
精准度:你搜索一段文本love me,能不能尽可能让包含这两个关键字的doc,或者离得近的doc先返回,排在前面,就是精准度,precision。
这二者看似有些矛盾,想要召回率高,精准度可能就低,反过来也是如此,精准度越是高的,召回率就越低,如何找一个平衡点?
我们一般的原则是优先满足召回率,同时兼顾精准度。比如match和match_phrase同时使用:
GET /music/children/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"content": "you gymbo"
}
}
],
"should": [
{
"match_phrase": {
"content": {
"query": "loves gymbo",
"slop": 2
}
}
}
]
}
}
}
我们可以看到加了match_phrase条件后,_id为3的_score由0.39556286上升到0.65997654。
rescoring优化性能
match查询和短语搜索(近似搜索)区别
match查询:只要简单的匹配到了一个term,就可以理解将term对应的doc作为结果返回,扫描倒排索引,扫描到了就表示有结果匹配了。
短语搜索(phrase match):先扫描所有term的doc list,找到包含所有term的doc list,然后对每个doc都计算每个term的position,是否符合指定的范围。
近似搜索(proxmity match):slop需要进行复杂的运算,来判断能否通过slop移动,匹配一个doc
match query性能要高一些,比phrase match高10倍,比proximity match高20倍。不过Elasticsearch内搜索的效率基本控制在几毫秒内,10、20倍不过也百十来毫秒,哪怕是繁忙的ES集群,也不过一两百毫秒,实际上完全可用。
如何优化proximity match?
一个查询可能会匹配成千上万的结果,但我们的用户很可能只对结果的前几页感兴趣,所以优化的思路就是proximity只要符合match条件的前几十个文档进行评分,而不是全部数据,速度自然能大大加快。
resocre重打分: proximity match,前20个doc进行rescore即可。
语法示例:
GET /music/children/_search
{
"query": {
"match": {
"content": "gymbo you"
}
},
"rescore": {
"window_size": 20,
"query": {
"rescore_query": {
"match_phrase": {
"content": {
"query": "gymbo you",
"slop": 1
}
}
}
}
}
}
- match 查询决定哪些文档将包含在最终结果集中,并通过TF/IDF排序。
- window_size 是每一分片进行重新评分的顶部文档数量,例子中取20个。
小结
本篇主要介绍近似匹配的常规玩法,以及rescoring优化性能的思路。
专注Java高并发、分布式架构,更多技术干货分享与心得,请关注公众号:Java架构社区
可以扫左边二维码添加好友,邀请你加入Java架构社区微信群共同探讨技术
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。