More like this query | ElasticSearch 7.7 权威指南中文版

原英文版地址: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-mlt-query.html, 原文档版权归 www.elastic.co 所有
本地英文版地址: ../en/query-dsl-mlt-query.html

重要: 此版本不会发布额外的bug修复或文档更新。最新信息请参考当前版本文档。

» » »

« distance_feature 查询 percolate 查询 »

more_like_this 查询

more_like_this 查询（以下简称 MLT）查找与给定文档集“相似(like)”的文档。为此，MLT 选择这些输入文档的一组代表性词项，使用这些词项形成查询，执行查询并返回结果。用户控制输入文档、如何选择词项以及如何形成查询。

一个最简单的用例是请求与提供的文本相似的文档。在这里，我们要求所有电影的“title”和“description”字段中有类似“Once upon a time”的文本，将所选词项的数量限制为12个。

GET /_search
{
    "query": {
        "more_like_this" : {
            "fields" : ["title", "description"],
            "like" : "Once upon a time",
            "min_term_freq" : 1,
            "max_query_terms" : 12
        }
    }
}

一个更复杂的用例是将文本与索引中已经存在的文档混合。在这种情况下，指定文档的语法类似于Multi GET API中使用的语法。

GET /_search
{
    "query": {
        "more_like_this" : {
            "fields" : ["title", "description"],
            "like" : [
            {
                "_index" : "imdb",
                "_id" : "1"
            },
            {
                "_index" : "imdb",
                "_id" : "2"
            },
            "and potentially some more text here as well"
            ],
            "min_term_freq" : 1,
            "max_query_terms" : 12
        }
    }
}

最后，用户可以混合一些文本、一组选定的文档，但也可以提供不一定出现在索引中的文档。为了提供索引中没有的文档，语法类似于人工文档。

GET /_search
{
    "query": {
        "more_like_this" : {
            "fields" : ["name.first", "name.last"],
            "like" : [
            {
                "_index" : "marvel",
                "doc" : {
                    "name": {
                        "first": "Ben",
                        "last": "Grimm"
                    },
                    "_doc": "You got no idea what I'd... what I'd give to be invisible."
                  }
            },
            {
                "_index" : "marvel",
                "_id" : "2"
            }
            ],
            "min_term_freq" : 1,
            "max_query_terms" : 12
        }
    }
}

它是如何工作的?

假设我们想要找到所有与给定的输入文档相似的文档。显然，输入文档本身应该是该类型查询的最佳匹配。根据 Lucene 评分公式，主要原因是 tf-idf(词频-逆向文档频率) 最高的词项。因此，输入文档中具有最高 tf-idf 的词项是该文档的很好的代表，并且可以在析取(disjunctive)查询(or或OR)中用来检索相似的文档。 MLT查询简单地从输入文档中提取文本，分析它，通常对字段使用相同的分析器，然后选择具有最高 tf-idf 的前 K 个词项来形成这些词项的析取(disjunctive)查询。

要执行 MLT 的字段必须进行索引，并且必须是 text 或 keyword 类型。此外，对文档使用 like 时，必须启用 _source，或者字段必须是stored 或存储(store) term_vector(词项向量)。为了加速分析，在索引时存储词项向量(vector) 会有所帮助。

例如，如果我们希望对“title”和“tags.raw”字段执行 MLT，我们可以在索引时显式存储它们的 term_vector。我们仍然可以在“description”和“tags”字段上执行 MLT，因为 _source 在默认情况下是启用的，但是这些字段的分析速度不会加快。

PUT /imdb
{
    "mappings": {
        "properties": {
            "title": {
                "type": "text",
                "term_vector": "yes"
            },
            "description": {
                "type": "text"
            },
            "tags": {
                "type": "text",
                "fields" : {
                    "raw": {
                        "type" : "text",
                        "analyzer": "keyword",
                        "term_vector" : "yes"
                    }
                }
            }
        }
    }
}

参数

唯一需要的参数是 like，所有其他参数都有合理的默认值。有三种类型的参数：一种用于指定文档输入，另一种用于词项选择以及查询的形成。

文档输入参数

`like`	MLT查询唯一需要的参数是 `like`，它遵循一个通用的语法，用户可以指定自由格式的文本和/或一个或多个文档(参见上面的例子)。指定文档的语法与 Multi GET API 使用的语法类似。指定文档时，除非在每个文档请求中被覆盖，否则将从 `fields` 中提取文本。文本被字段指定的分析器分析，但是这个分析器也可以被覆盖（重新指定）。覆盖字段的分析器的语法与 Term Vectors API 中的 `per_field_analyzer` 参数的语法相似。此外，为了提供不一定出现在索引中的文档，也支持人工文档(artificial documents)。
`unlike`	`unlike` 参数与 `like` 一起使用，以便不选择在一组选定的文档中找到的词项。换句话说，我们可以要求 `like: "Apple"` 这样的文档，但`unlike: "cake crumble tree"` 。(译者注: 像Apple, 但是不像 cake crumble tree) 语法和 `like` 一样。
`fields`	要从中提取和分析文本的字段列表。

词项选择(term selection)参数

`max_query_terms`	将被选择的查询词项的最大数量。增加该值可以以查询执行速度为代价而获得更高的准确性。默认为 `25`。
`min_term_freq`	最小词项频率，低于该频率的词项将从输入文档中忽略。默认为 `2`。
`min_doc_freq`	最小文档频率，低于该频率的词项将从输入文档中忽略。默认为 `5`。
`max_doc_freq`	最大文档频率，高于该频率的词项将从输入文档中忽略。这对于忽略高频词(如停止词)很有用。默认为无限制(`Integer.MAX_VALUE`，其值为 `2^31-1` 或者 2147483647)。
`min_word_length`	最小单词长度，小于该长度的单词将被忽略。旧名称 `min_word_len` 已废弃。默认为 `0`.
`max_word_length`	最大单词长度，大于该长度的单词将被忽略。旧名称 `max_word_len` 已废弃。默认为无限制 (`0`)。
`stop_words`	停止词数组。这个集合中的任何单词都被认为是“不感兴趣的”并被忽略。如果分析器允许停止词，你可能想要告诉 MLT 显式地忽略它们，因为为了文档相似性的目的，假设“停止词从不有趣”似乎是合理的。
`analyzer`	用于分析自由格式文本的分析器。默认为与 `fields` 中的第一个字段相关联的分析器。

查询形成(query formation)参数

`minimum_should_match`	形成析取查询后，该参数控制必须匹配的词项的数量。语法与 minimum should match 相同。 (默认为 `"30%"`)。
`fail_on_unsupported_field`	控制如果任何指定字段不属于支持的类型(`text` 或 `keyword`)，查询是否应该失败(抛出异常)。将此项设置为 `false` 以忽略该字段并继续处理。默认为 `true`。
`boost_terms`	所形成的查询中的每一项都可以被它们的 tf-idf 分数进一步增强。这将设置使用此功能时要使用的 boost(增强) 因子。默认为停用 (`0`)。任何一个正数的值都将激活具有给定增强因子的词项增强。
`include`	指定输入文档是否也应包含在返回的搜索结果中。默认为 `false`。
`boost`	设置整个查询的增强(boost)值。默认为 `1.0`。

可替代的(Alternative)

为了更好地控制相似文档查询的构造，值得考虑编写定制的客户端代码，将示例文档中的选定的词项组合成具有所需设置的 bool 查询。在 more_like_this 中从一段文本中选择“感兴趣的”单词的逻辑也可以通过 TermVectors API访问。例如，使用 TermVectors API，可以向用户提供在文档文本中找到的主题关键词的选择，允许他们选择感兴趣的单词进行深入研究，而不是使用 more_like_this使用的更“黑盒(black-box)”的匹配方法。

« distance_feature 查询 percolate 查询 »