Elasticsearch能检索出来,但不能正确高亮怎么办?

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: 微信群里的线上实战问题:诸位大哥,es中:keyword类型的字段进行高亮查询,值为 123asd456,查询 sd4,高亮结果是 em 123asd456 em有没有办法只对我查询的sd4高亮?明明查询id的一部分,却高亮结果是整个id串,怎么办?死磕Elasticsearch技术微信群

2、一个Demo描述清楚问题

注:本文示例DSL在7.2版本运行ok,6.X之前早期版本可能需要微调。


PUT findex

{

 "mappings": {

   "properties": {

     "aname":{

       "type":"text"

     },

     "acode":{

       "type":"keyword"

     }

   }

 }

}

POST findex/_bulk

{"index":{"_id":1}}

{"acode":"160213.OF","aname":"X泰纳斯达克100"}

{"index":{"_id":2}}

{"acode":"160218.OF","aname":"X泰国证房地产"}

POST findex/_search

{

 "highlight": {

   "fields": {

     "acode": {}

   }

 },

 "query": {

   "bool": {

     "should": [

       {

         "wildcard": {

           "acode": "*1602*"

         }

       }

     ]

   }

 }

}

高亮检索结果,


 "highlight" : {

         "acode" : [

           "<em>160213.OF</em>"

         ]

       }

也就是说整个串都被高亮了,没有达到预期。


实际需求:搜索1602,相关数据:160213.O、160218.OF都能召回,且仅高亮搜索字段1602。


3、问题拆解

检索选型wildcard是为了解决子串能匹配的问题,wildcard的实现类似mysql的“like”模糊匹配。


传统的text标准分词器,包括中文分词器ik、英文分词器english、standard等都不能解决上述子串匹配问题。


而实际业务需求:


一方面:要求输入子串召回全串;


另一方面:要求高亮检索的子串。


只能更换一种分词Ngram来实现了!


4、什么是Ngram?

4.1 Ngram定义

Ngram是一种基于统计语言模型的算法。


Ngram基本思想:是将文本里面的内容按照字节进行大小为N的滑动窗口操作,形成了长度是N的字节片段序列。每一个字节片段称为gram,对所有gram的出现频度进行统计,并且按照事先设定好的阈值进行过滤,形成关键gram列表,也就是这个文本的向量特征空间,列表中的每一种gram就是一个特征向量维度。


该模型基于这样一种假设,第N个词的出现只与前面N-1个词相关,而与其它任何词都不相关,整句的概率就是各个词出现概率的乘积。


这些概率可以通过直接从语料中统计N个词同时出现的次数得到。常用的是二元的Bi-Gram(二元语法)和三元的Tri-Gram(三元语法)。


4.2 Ngram举例

中文句子:“你今天吃饭了吗”,它的Bi-Gram(二元语法)分词结果为:


你今

今天

天吃

吃饭

饭了

了吗

4.3 Ngram 应用场景

场景1:文本压缩、检查拼写错误、加速字符串查找、文献语种识别。


场景2:自然语言处理自动化领域得到新的应用,如自动分类、自动索引、超链的自动生成、文献检索、无分隔符语言文本的切分等。


场景3:自然语言的自动分类功能。对应到Elasticsearch检索,应用场景就更加明确:无分隔符语言文本的切分分词,提高检索效率(相比:wildcard 查询和正则查询)。


5、实践一把

PUT findex_ext

{

 "settings": {

   "index.max_ngram_diff": 10,

   "analysis": {

     "analyzer": {

       "my_analyzer": {

         "tokenizer": "my_tokenizer"

       }

     },

     "tokenizer": {

       "my_tokenizer": {

         "type": "ngram",

         "min_gram": 4,

         "max_gram": 10,

         "token_chars": [

           "letter",

           "digit"

         ]

       }

     }

   }

 },

 "mappings": {

   "properties": {

     "aname": {

       "type": "text"

     },

     "acode": {

       "type": "text",

       "analyzer": "my_analyzer",

       "fields": {

         "keyword": {

           "type": "keyword"

         }

       }

     }

   }

 }

}

POST findex_ext/_bulk

{"index":{"_id":1}}

{"acode":"160213.OF","aname":"X泰纳斯达克100"}

{"index":{"_id":2}}

{"acode":"160218.OF","aname":"X泰国证房地产"}

# 查看分词结果

POST findex_ext/_analyze

{

 "analyzer": "my_analyzer",

 "text":"160213.OF"

}

POST findex_ext/_search

{

 "highlight": {

   "fields": {

     "acode": {}

   }

 },

 "query": {

   "bool": {

     "should": [

       {

         "match_phrase": {

           "acode": {

             "query": "1602"

           }

         }

       }

     ]

   }

 }

}

注意:三个核心参数


min_gram:最小字符长度(切分),默认为1


max_gram:最大字符长度(切分),默认为2


token_chars:生成的分词结果中包含的字符类型,默认是全部类型。如上的示例中代表:保留数字、字母。若上述示例中,只指定  "letter",则数字就会被过滤掉,分词结果只剩下串中的字符如:"OF"。


返回结果截取片段如下:


   "highlight" : {

         "acode" : [

           "<em>1602</em>13.OF"

         ]

       }

已经能满足检索和高亮的双重需求。


5、选型注意

Ngram的本质:用空间换时间。其能匹配的前提是写入的时候已经按照:min_gram、max_gram切词。


数据量非常少且不要求子串高亮,可以考虑keyword。


数据量大且要求子串高亮,推荐使用:Ngram分词结合match或者match_phrase检索实现。


数据量大,切记不要使用wildcard前缀匹配!


原因:带有通配符的pattern构造出来的DFA(Deterministic Finite Automaton)可能会很复杂,开销很大!甚至可能导致线上环境宕机。


Wood大叔也 多次强调:wildcard query应杜绝使用通配符打头,实在不得已要这么做,就一定需要限制用户输入的字符串长度。


6、小结

为讨论解决线上问题,引申出Ngram的原理和使用逻辑,并指出了wildcard和Ngram的适用业务场景。希望对实战中的你有所启发和帮助!


你在业务中遇到子串匹配和高亮的情况吗?你是如何分词和检索的?欢迎留言讨论。


参考:


1、https://zhuanlan.zhihu.com/p/32829048


2、http://blog.sciencenet.cn/blog-713101-797384.html


3、https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-ngram-tokenizer.html


4、https://elasticsearch.cn/article/171

相关实践学习
使用阿里云Elasticsearch体验信息检索加速
通过创建登录阿里云Elasticsearch集群,使用DataWorks将MySQL数据同步至Elasticsearch,体验多条件检索效果,简单展示数据同步和信息检索加速的过程和操作。
ElasticSearch 入门精讲
ElasticSearch是一个开源的、基于Lucene的、分布式、高扩展、高实时的搜索与数据分析引擎。根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr(也是基于Lucene)。 ElasticSearch的实现原理主要分为以下几个步骤: 用户将数据提交到Elastic Search 数据库中 通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据 当用户搜索数据时候,再根据权重将结果排名、打分 将返回结果呈现给用户 Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索,具有接近实时的搜索,并支持多租户。
相关文章
|
4月前
|
SQL JSON 大数据
ElasticSearch的简单介绍与使用【进阶检索】 实时搜索 | 分布式搜索 | 全文搜索 | 大数据处理 | 搜索过滤 | 搜索排序
这篇文章是Elasticsearch的进阶使用指南,涵盖了Search API的两种检索方式、Query DSL的基本语法和多种查询示例,包括全文检索、短语匹配、多字段匹配、复合查询、结果过滤、聚合操作以及Mapping的概念和操作,还讨论了Elasticsearch 7.x和8.x版本中type概念的变更和数据迁移的方法。
ElasticSearch的简单介绍与使用【进阶检索】 实时搜索 | 分布式搜索 | 全文搜索 | 大数据处理 | 搜索过滤 | 搜索排序
|
4月前
|
存储 API 数据库
检索服务elasticsearch索引(Index)
【8月更文挑战第23天】
68 6
|
4月前
|
存储 负载均衡 监控
检索服务elasticsearch节点(Node)
【8月更文挑战第23天】
62 5
|
4月前
|
存储 监控 负载均衡
检索服务elasticsearch集群(Cluster)
【8月更文挑战第23天】
66 3
|
4月前
|
网络协议 Java API
SpringBoot整合Elasticsearch-Rest-Client、测试保存、复杂检索
这篇文章介绍了如何在SpringBoot中整合Elasticsearch-Rest-Client,并提供了保存数据和进行复杂检索的测试示例。
SpringBoot整合Elasticsearch-Rest-Client、测试保存、复杂检索
|
3月前
|
存储 自然语言处理 关系型数据库
ElasticSearch基础3——聚合、补全、集群。黑马旅游检索高亮+自定义分词器+自动补全+前后端消息同步
聚合、补全、RabbitMQ消息同步、集群、脑裂问题、集群分布式存储、黑马旅游实现过滤和搜索补全功能
ElasticSearch基础3——聚合、补全、集群。黑马旅游检索高亮+自定义分词器+自动补全+前后端消息同步
|
4月前
|
SQL 存储 自然语言处理
检索服务elasticsearch全文搜索
【8月更文挑战第22天】
61 3
|
4月前
|
SQL 存储 监控
检索服务elasticsearch
【8月更文挑战第21天】
39 0
|
4月前
|
存储 缓存 监控
Elasticsearch Filter 缓存加速检索的细节,你知道吗?
【8月更文挑战第15天】在大数据与搜索引擎的广阔天地里,Elasticsearch 凭借其强大的全文搜索能力和可扩展性,成为了众多企业和开发者的首选。而在Elasticsearch的性能优化中,Filter缓存(也称为Filter Cache,自Elasticsearch 7.x版本后更名为Query Cache的一部分)扮演着至关重要的角色。今天,我们就来深入探讨一下Elasticsearch Filter缓存如何加速检索过程,以及在日常工作学习中如何有效利用这一特性。
80 0
|
4月前
|
自然语言处理 Java
ElasticSearch 实现分词全文检索 - 高亮查询
ElasticSearch 实现分词全文检索 - 高亮查询
72 0