ElasticSearch中completion补全建议如何搭配highlight高亮？是否支持全文检索？

你当前使用的completion suggester查询配置如下：

{
  "suggest": {
    "sourceText_suggestion": {
      "prefix": "12",
      "completion": {
        "field": "sourceText",
        "fuzzy": {
          "fuzziness": 2
        },
        "contexts": {
          "companyUid": ["1000467"]
        }
      }
    }
  }
}

问题1：completion补全查询如何配置高亮 #

completion suggester的高亮不支持和普通全文检索一样在查询根节点配置highlight，需要把高亮配置写到completion参数内部，仅支持pre_tag和post_tag两个配置项，不支持片段截断、多字段高亮等普通高亮的高级特性。
配置示例：

{
  "suggest": {
    "sourceText_suggestion": {
      "prefix": "12",
      "completion": {
        "field": "sourceText",
        "fuzzy": {
          "fuzziness": 2
        },
        "contexts": {
          "companyUid": ["1000467"]
        },
        "highlight": {
          "pre_tag": "<em class='highlight'>",
          "post_tag": "</em>"
        }
      }
    }
  }
}

查询返回后，每个补全候选结果会单独返回highlight字段，里面是包裹了高亮标签的文本，直接取该字段渲染即可，不需要取普通的text字段做二次匹配。

问题2：completion能否支持全文任意位置词汇匹配 #

结论：原生completion suggester做不到，也不建议硬改配置实现该需求。
completion suggester底层基于FST（有限状态转换器）实现，索引阶段就会把所有待补全的内容构建成前缀匹配路径的内存结构，核心优势是前缀匹配的延迟极低，天生只支持从文本/分词项起始位置开始的前缀匹配，无法直接命中文本中间位置的随机词汇。如果强行通过通配符、修改分词规则的方式让completion支持中间匹配，会直接绕过FST的性能优化，内存占用、查询延迟都会指数级上升，完全丢失completion本身的性能价值。

可根据业务场景选择替代方案：

• 绝大多数业务场景下，直接使用match_phrase_prefix查询配合edge ngram分词器即可实现全文任意位置词汇的前缀联想，支持完整的高亮、过滤、权重排序能力，实现成本低，性能够用。
• 如果是亿级以上数据规模、对联想响应延迟要求极高的场景，可以离线抽取全量文本中所有分词结果、分词的有效前缀作为补全候选，再写入completion字段构建索引，该方案需要额外维护候选生成逻辑，维护成本较高，仅适合大规模场景。

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