Elasticsearch自动提示场景「前缀优先」搜索排序修正方法

当前结果不符合预期，核心是两个配置缺陷导致的：

1. 索引分词用了普通ngram分词器，会从文本任意位置切取连续子串生成索引项，完全不携带子串的位置信息——无论搜索词出现在文本的开头、中间还是末尾，只要匹配到对应的ngram项，ES默认的BM25评分逻辑不会做任何位置上的倾斜。
2. 评分权重设置错位：原本给primaryTerm.raw加的2倍权重没有位置区分，keyword类型的raw字段只要值包含搜索词就会命中，不管搜索词在字段的哪个位置；再加上BM25默认的长度归一化规则，文本越短得分越高，最终就出现短文本末尾带搜索词的得分，远高于长文本开头带搜索词的得分的倒挂现象。

一、调整索引Mapping配置 #

需要把“前缀命中”和“任意位置命中”的场景拆成独立的索引字段，从索引层面把两种匹配的位置信息隔离开，具体改动点：

1. 在analysis模块的tokenizer下新增前缀专用的edge_ngram分词器（和普通ngram的核心区别是只从文本最开头切取连续子串，天生适配自动提示的前缀匹配场景）：

   "prefix_tokenizer": {
     "type": "edge_ngram",
     "min_gram": 1,
     "max_gram": 40,
     "token_chars": [
       "letter",
       "digit",
       "whitespace",
       "punctuation",
       "symbol"
     ]
   }
   

2. 在analysis模块的analyzer下新增前缀专用的分析器，过滤逻辑和现有配置保持一致：

   "prefix_analyzer": {
     "tokenizer": "prefix_tokenizer",
     "filter": ["lowercase", "asciifolding"]
   }
   

3. 修改primaryTerm的字段定义，新增两个独立的子字段：
   • prefix：使用刚才的prefix_analyzer做索引分析，搜索时仍沿用现有autocomplete_search（keyword分词+小写过滤）。这个字段只有当搜索词是文本前缀时才会命中，完全不会匹配文本中间/末尾包含搜索词的场景
   • contains：沿用现有custom_analyzer（全位置ngram），专门用来匹配文本任意位置包含搜索词的场景
     调整完成后的primaryTerm字段结构示例：

   "primaryTerm": {
     "type": "text",
     "analyzer": "custom_analyzer",
     "search_analyzer": "autocomplete_search",
     "fielddata": "true",
     "fields": {
       "raw": {
         "type": "keyword",
         "normalizer": "custom_normalizer"
       },
       "prefix": {
         "type": "text",
         "analyzer": "prefix_analyzer",
         "search_analyzer": "autocomplete_search"
       },
       "contains": {
         "type": "text",
         "analyzer": "custom_analyzer",
         "search_analyzer": "autocomplete_search"
       }
     }
   }
   

注：Mapping配置修改完成后需要全量重建索引，新的字段配置才会正式写入索引生效。
原理说明：edge_ngram的切词规则是从文本的第0个字符开始，向后逐个增加长度切分子串，完全不会从文本的中间或末尾开始切。比如文本ACT ADVOCATES的prefix字段，只会切出以A开头的"a""ac""act"等子串，根本不会生成"advocate"这个索引项，因此用户搜"advocate"时，这个字段完全不会命中prefix的匹配规则；而文本ADVOCATE AND PATENTS...的prefix字段，会从A开头切出"advocate"对应的子串，顺利命中。

二、重写查询的评分权重逻辑 #

把原来的bool.should子句按优先级从高到低设置权重，优先级越高的匹配场景权重越高，确保前缀命中的条目得分始终高于任意位置命中的条目。你原本用query_string的查询逻辑可以直接适配，不需要更换查询类型，修改后的Java查询代码参考：

String query = "{\"bool\": { \"should\": [" +
    // 最高优先级：字段值和搜索词完全精确匹配，权重设为10
    "{\"query_string\": {\"query\":\"advocate\",\"fields\": [\"primaryTerm.raw^10\" ]}}," +
    // 次高优先级：搜索词是字段内容的前缀，权重设为5
    "{\"query_string\": {\"query\":\"advocate\",\"fields\": [\"primaryTerm.prefix^5\" ]}}," +
    // 最低优先级：字段任意位置包含搜索词，默认权重
    "{\"query_string\": {\"query\":\"advocate\",\"fields\": [\"primaryTerm.contains\" ]}}" +
  "]}}";

搜索advocate时，排序会完全符合预期：

1. 以advocate开头的条目，会同时拿到prefix字段的5倍加权，得分远高于其他场景
2. 中间/末尾包含advocate的条目，只会拿到contains字段的基础分，自然排在前缀命中的条目后面
3. 完全等于advocate的条目，因为拿到10倍的raw字段权重，会排在所有结果的最顶部

内容的提问来源于stack exchange，提问作者Nitika Jain