Rescoring / Search Type
Rescoring
重新计算可以通过使用次要(通常是更昂贵的)算法来重新排序查询和 post_filter 阶段返回的顶部(例如100-500)个文档,而不是对索引中的所有文档应用昂贵的算法来帮助提高精度。
在返回其结果以由处理整个搜索请求的节点排序之前,在每个分片上执行 rescore 请求。
目前 rescore API 只有一个实现:查询 rescorer,它使用查询来调整评分。 在将来,可以提供备选的分配器,例如,成对分配器。
Note:
当使用排序时不执行 rescore 阶段。
Note:
当向用户展示分页时,您不应该在逐步浏览每个页面(通过传递不同的值)时更改window_size,因为这可能会改变顶部匹配,导致结果在用户逐步浏览页面时发生混乱。
Query rescorer
查询rescorer仅对查询和post_filter阶段返回的Top-K结果执行第二个查询。 将在每个分片上检查的文档数量可以由window_size参数控制,默认为from和size。
默认情况下,原始查询和rescore查询的分数线性组合,以产生每个文档的最终_score。 原始查询和rescore查询的相对重要性可以分别使用query_weight和rescore_query_weight进行控制。 两者默认为1。
例如:
组合得分的方式可以用 score_mode 控制:
Score Mode | Description |
| 添加原始分数和 rescore 查询分数。 默认值。 |
| 将原始分数乘以 rescore 查询分数。 用于函数查询 rescores。 |
| 平均原始分数和 rescore 查询分数。 |
| 取最初的分数和 rescore 查询分数。 |
| 取最初的分数和 rescore 查询分数。 |
Multiple Rescores
也可以按顺序执行多个资源:
第一个获得查询的结果,第二个获得第一个的结果等。第二个 rescore 将 “see” 由第一个 rescore 完成排序,因此可以在第一个 rescore 上使用大窗口 将文档拖动到较小的窗口中,以便第二个文件。
Search Type
在执行分布式搜索时可以执行不同的执行路径。分布式搜索操作需要分散到所有相关的分片,然后收集所有的结果。当使用分散/集合类型执行时,有几种方法可以做到这一点,特别是使用搜索引擎。
执行分布式搜索时的一个问题是从每个分片检索多少结果。例如,如果我们有 10 个分片,则第一个分片可以保存从 0 到 10 的最相关的结果,其他分片结果排在其下。为此,当执行请求时,我们需要从所有分片中获取 0 到 10 的结果,对它们进行排序,然后如果我们想要确保正确的结果,则返回结果。
与搜索引擎相关的另一个问题是每个分片独立存在的事实。当在特定分片上执行查询时,它不考虑来自其他分片的项频率和其他搜索引擎信息。如果我们想要支持准确的排名,我们需要首先收集所有分片中的术语频率,以计算全局术语频率,然后使用这些全局频率对每个分片执行查询。
此外,由于需要对结果进行排序,取回大的文档集,或者甚至滚动它,同时保持正确的排序行为可能是非常昂贵的操作。对于大型结果集滚动,最好按 _doc 进行排序,如果返回文档的顺序不重要。
Elasticsearch非常灵活,允许控制在每个搜索请求的基础上执行的搜索类型。可以通过在查询字符串中设置search_type参数来配置类型。类型是:
Query Then Fetch
参数值:query_then_fetch。
请求分两个阶段处理。 在第一阶段,查询被转发到所有涉及的分片。 每个分片执行搜索并生成对该分片本地的结果的排序列表。 每个分片只向协调节点返回足够的信息,以允许其合并并将分片级结果重新排序为全局排序的最大长度大小的结果集。
在第二阶段期间,协调节点仅从相关分片请求文档内容(以及高亮显示的片段,如果有的话)。
Note:
如果您未在请求中指定 search_type,那么这是默认设置。
Dfs, Query Then Fetch
参数值:dfs_query_then_fetch
与 “Query Then Fetch” 相同,除了初始分散阶段,其计算分布项频率用于更准确的计分。
Last updated