Neil Zhu，简书ID Not_GOD，University AI 创始人 & Chief Scientist，致力于推进世界人工智能化进程。制定并实施 UAI 中长期增长战略和目标，带领团队快速成长为人工智能领域最专业的力量。
作为行业领导者，他和UAI一起在2014年创建了TASA（中国最早的人工智能社团）, DL Center（深度学习知识中心全球价值网络），AI growth（行业智库培训）等，为中国的人工智能人才建设输送了大量的血液和养分。此外，他还参与或者举办过各类国际性的人工智能峰会和活动，产生了巨大的影响力，书写了60万字的人工智能精品技术内容，生产翻译了全球第一本深度学习入门书《神经网络与深度学习》，生产的内容被大量的专业垂直公众号和媒体转载与连载。曾经受邀为国内顶尖大学制定人工智能学习规划和教授人工智能前沿课程，均受学生和老师好评。
Phrase 匹配
match_phrase 查询是你在想要找到靠近彼此的多个词时需要采用的查询：
GET /my_index/my_type/_search
{
"query": {
"match_phrase": {
"title": "quick brown fox"
}
}
}
如同 match 查询，match_phrase 查询首先分析了查询的字符串来产生 term 的列表。然后对所有的项进行搜索，但是仅仅会保留那些按照每个之间的同样的顺序包含了所有的查询项的文档。对语句 quick fox 的查询不会匹配我们的任何一篇文档，因为没有文档包含词 quick 跟上 fox。
match_phrase查询同样可以被写作match查询而类型是phrase：
"match": {
"title": {
"query": "quick brown fox",
"type": "phrase"
}
}
Term 位置
当一个字符串被分析过后，分析器不仅仅返回了一个项的列表，而且有相应的位置，或者每个项在原始字符串中的次序：
GET /_analyze?analyzer=standard
Quick brown fox
这个会返回：
{
"tokens": [
{
"token": "quick",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "brown",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "fox",
"start_offset": 12,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 3
}
]
}
位置可以存储在倒排的索引中，并且如 match_phrase 这样的位置相关的查询可以使用他们匹配仅仅那些根据制定的次序出现的所有词的文档，而非那些夹杂在中间的词。
什么是一个语句 Phrase
对于一个文档被当成匹配了语句“quick brown fox”，下面的条件肯定成立：
-
quick，brown和fox肯定都会出现的字段中 -
brown的位置肯定是比quick出现的位置大1 -
fox的位置肯定比quick出现的位置大2
如果上面这些条件都没有被满足，那么文档就不会看做是匹配的结果。
内部原理上，
match_phrase查询直接使用了底层的span查询来进行位置相关的匹配。span查询是项一级的查询，所以他们没有分析的过程；直接搜索准确的指定项。
好消息是，大多数人不需要直接使用span查询，就像match_phrase查询通常表现已经足够好了。然而，某种特定的字段比如专利搜索，使用这些底层的查询来执行非常具体的，仔细构造的位置查询。
混合匹配
采用精准的语句匹配可能是太过严格的限制了。可能我们希望包含“quick brown fox”也能够成为查询“quick fox”的匹配结果，甚至这些位置的都不需要完全一致。
我们可以通过设置 slop 参数在语句匹配中引入一种灵活度：
GET /my_index/my_type/_search
{
"query": {
"match_phrase": {
"title": {
"query": "quick fox",
"slop": 1
}
}
}
}
slop 参数告诉 match_phrase 查询多远的项可以被允许仍然将文档当做是匹配的结果。多么远其实是指需要移动项多少次来让查询和文档匹配。
多值字段
当你尝试使用语句匹配在多值字段上时会出现一件有趣的事情。假设我们按照如下方式索引文档：
PUT /my_index/groups/1
{
"names": [ "John Abraham", "Lincoln Smith"]
}
然后执行 Abraham Lincoln 的语句查询：
GET /my_index/groups/_search
{
"query": {
"match_phrase": {
"names": "Abraham Lincoln"
}
}
}
令人吃惊的是，我们文档即使 Abraham 和 Lincoln 来自不同的在 names 数组的人。这个情况的原因其实是 names 数组索引的方式。这其实是由于elasticsearch 中数组索引的机制决定的。
John Abraham 分析结果如下：
- Position 1: john
- Position 2: abraham
然后John Abraham 分析的结果如下：
- Position 3: lincoln
- Position 4: smith
换言之，elasticsearch 产生了和单个字符串 John Abraham Lincoln Smith 完全一直的结果。而我们查询的例子中的正好是 abraham lincoln，这两个项显然存在，并且靠在一起，所以查询匹配了。
幸运的是，有一种解决的方案，称为 position_offset_gap，我们需要在字段映射中进行设置：
DELETE /my_index/groups/
PUT /my_index/_mapping/groups
{
"properties": {
"names": {
"type": "string",
"position_offset_gap": 100
}
}
}
- 首先删除了
groups映射和所有那种 type 的文档 - 然后创建新的使用了正确值的
groups映射
position_offset_gap 设置告诉 elasticsearch 必须增加指定值到当前项的 position 上。所以在我们索引了 name 的数组时，项会变成这样的情况：
- Position 1: john
- Position 2: abraham
- Position 103: lincoln
- Position 104: smith
我们的查询将不会再匹配像上面那种情况的记录了，因为 abraham lincoln 现在相距 100 的距离。你需要增加 slop 为 100 方可让这篇文档被匹配。
eventmachine
gem install eventmachine -v '1.0.7' -- --with-cppflags=-I/usr/local/opt/openssl/include
